Seminarna Praca - HI-3, Datove Sklady

Ekonomická univerzita v Bratislave
Fakulta hospodárskej informatiky
Dátové sklady-ich história, štruktúra, význam
Predmet: Hospodárska informatika I

Vyučujúci: JURÍK, Pavol, Ing., PhD.
Vypracovali: Martin Jankech, Juraj Antal, Samuel Veštúr, Peter Záborský
Študijný program: HI
Forma štúdia: Denná
Akademický rok/semester:2018/2019, letný
Ročník: 1.
1. Ako správne rozumieť základnej terminológii
1.1 Dátový sklad
Pojem dátový sklad (DW - Data Warehouse) sa počas posledných niekoľkých rokov
nezmazateľne zapísal do povedomia užívateľov informačných systémov (IS). Dátový sklad je
správne chápaný ako nevyhnutná nadstavba prevádzkových IS, pomocou ktorej pracovníci
manažmentu ľahko a rýchlo získavajú vo veľmi prehľadnej podobe informácie pre sumárnu
analýzu dát, odhaľovanie skrytých súvislostí, sledovanie trendov v rôznych oblastiach a pod.
Pod pojmom "dátový sklad" môžeme chápať "Komplexné dáta uložené v štruktúre, ktorá
umožňuje efektívnu analýzu a dopytovanie. Dáta do dátového skladu sú čerpané z primárnych
informačných systémov a ďalších zdrojov.
[Brzák, Manažerska Informatika, 69]
Využitie dobre navrhnutého dátového skladu nie je len záležitosť pre pracovníkov
vrcholového manažmentu. Je naliehavo potrebné priblížiť možnosti využitia dátových
skladov aj používateľom mimo vrcholový manažment a to úplne všeobecne v rôznych
podnikoch a na rôznych úrovniach.
[Brzák, Manažerska Informatika, 69]
Dátový sklad je pomenovanie pre systémy umožňujúce analytické spracovanie dát
prostredníctvom nástrojov OLAP (OnLine Analytical Processing). Tieto nástroje tvoriace
užívateľské rozhranie potom slúžia k analýze historických dát, z ktorých sú potom vytvárane
obsiahle štatistické zostavy.
[Sodomka,Klčová, Informační systémy v podnikové praxi, 407]
Za jedného zo zakladateľov DWH považujeme Williama Inmona, ktorý definuje dátový sklad
nasledovne: Dátový sklad je integrovaný, subjektovo orientovaný, stály a časovo rozlíšený
súhrn dát, usporiadaný pre podporu potrieb manažmentu.
[Stuchlý, Informační systémy v Marketingu, 42]
Integrovaný – dáta sú ukladané v rámci celého podniku a nie iba v rámci jednotlivých
oddelení do jedného systému.
Subjektovo orientovaný – dáta sú rozdeľované podľa ich typu, nie podľa aplikácií, v
ktorých vznikli. Napríklad informácie o zamestnancovi sú uložené iba jedenkrát a to v
databáze dátového skladu, na rozdiel od produkčného systému, kde sú rozptýlené do rôznych
súborov podľa toho, pre ktorú aplikáciu majú byť použité.
[Stuchlý, Informační systémy v Marketingu, 42-43]
Stály – dátové sklady sú koncipované prevažne ako „read only“ čo v praxi znamená, že tu
žiadne dáta nevznikajú a nie je možné ich ani užívateľskými nástrojmi meniť. Dáta sú do DWH
načítané z produkčných databáz, alebo iných externých zdrojov a existujú tu po celú dobu
života dátového skladu.
Časovo rozlíšený – aby bolo možné uskutočňovať analýzy za určité obdobie je nevyhnutné,
aby bola do DWH uložená aj história dát. Načítané dáta si musia so sebou niesť informáciu o
dimenzii času. Sú k dispozícii dáta aj za niekoľko minulých rokov.
Z tejto definície vyplýva že DW poskytuje nie len prostriedky pre ukladanie dát , ale tak isto
sadu nástrojov pre ich analýzu. Nemôže však byt chápaný iba ako prostriedok pre analýzu,
ktorý ponuka užívateľom súhrnný pohlaď na dáta vyprodukovane ich informačnými
systémami. V skutočnosti ide o komplexní nekončiaci proces , v ktorého priebehu treba
príslušne dáta transformovať z operatívnych zdrojov, očistiť, uložiť do odpovedajúcich
štruktúr a zaistiť ich doručenie užívateľom v štruktúre , forme a čase , ktorý by bol pre nich
užitočný.
[Sodomka,Klčová, Informační systémy v podnikové praxi, 407-408]
Vďaka systematickému prístupu k budovaniu dátového skladu sa dajú tak isto nachádzať
vzťahy medzi dátami, ktoré boli získane z rôznych zdrojov a ktoré by inak užívateľ
pravdepodobne nikdy neodhalil. Dátový sklad môže zabezpečiť online prístup všetkým
užívateľom k informácia, ktoré ide prostredníctvom analytických nástrojov efektívne vyťažiť.
Uloženie dát v dátovom sklade sa v porovnaní s ukladaním dát v prevádzkových IS riadi
trochu odlišnými pravidlami. Hlavným dôvodom je, že v dátovom sklade je potrebné mať
k dispozícii dáta vyčistené a tiež do štruktúry uložené inak ako v prevádzkovom IS.
Zdanlivým paradoxom je, že objem dát, uložených v dátovom sklade, môže byť aj podstatne
väčší ako v prostredí prevádzkového IS. Vďaka stavu na poli HW sa táto skutočnosť postupne
stáva.
menej závažnou a do popredia vystupujú prínosy, ktoré toto navýšenie poskytuje.
[Brzák, Manažerska Informatika, 69-70]
V porovnaní s databázou (transakčného systému) je dátový sklad v podstate výhradne

orientovaný na vyhľadávanie a pridávanie dát tak , aby mohol umožniť analytickú funkciu.
V dátových skladoch sú uložene predovšetkým historické dáta (pomer historických
a aktuálnych dát sa obvykle odhaduje na 7:3). To umožňuje jedinečný , prostredníctvom iných
podnikových systémov nedostupný pohlaď a dáta. Ich analýzy potom na základe historického
porovnávania nadobúdajú zmysel. Pritom nám nesmie uniknúť kľúčová úloha dátového
skladu , ktorým je podpora plánovania a riadenia firmy , a to nie len na strategické úrovni.
Významná je aj podpora operatívneho riadenia tzv. operatívnych dátových skladov (ODS-
Operation Data Store).Tie umožňuje automatizovať niektoré rozhodovacie procesy , napr. pri
riadení logistiky u obchodných reťazcoch.
Operatívny dátový sklad predstavuje hybridnú formu dátového skladu. Je prvkov DW,
pomocou ktorej sa vlastný dátový sklad „približuje “ smerom k transakčným systémom. ODS
sa oproti DW líši v tom, že pomocou neho ide vykonávať operácie s dátami , ktoré sú vlastne
pre transakčne systémy.
Dáta uložené v ODS využívajú prevažne tí zamestnanci , ktorí potrebujú k svojej operatívnej
činnosti integrované dáta z niekoľkých transakčných systémov (napr. ERP a CRM). ODS je
ale voči transakčným systémom v rovnakom vzťahu ako DW- tvorí cieľové prostredie.
1.2 Dátové sklady nie len pre vrcholový manažment
V ďalšom sú uvedené prínosy, ktoré riešenie formou dátového skladu prinesie užívateľom
mimo vrcholový manažment. Ide najmä o tú časť užívateľov, pre ktoré boli v existujúcich IS
určené rozličné výstupné zostavy a prehľady. Pri rozšírení používania dátových skladov bude
mať títo užívatelia možnosť oceniť najmä nasledujúce skutočnosti:
[Brzák, Manažérska Informatika, 78]
 Jednoduchá a rýchla dostupnosť informácie

 V porovnaní so štandardnými výstupmi v prostredí prevádzkového IS dostane užívateľ
u kritických výstupov požadovanú informáciu v zlomkovom čase. Navyše pri takto
získanej informácie má možnosť využiť ďalšie funkcií (drill down, drill up, drill
across, porovnávanie a pod.), ktoré by pri štandardnom spôsobe spracovania boli
uskutočniteľné len ťažko, čiastočne alebo vôbec.
 Podpora grafického výstupu
 Užívateľ má k dispozícii požadovanú informáciu ako v podobe číselnej tabuľky, tak aj
vo vybranej grafickej podobe. Grafickú podobu má k dispozícii priamo v prostredí
prezentačného nástroja bez nutnosti prenášania údajov do prostredia, ktoré zobrazenie
formou grafov podporuje.
 Samostatné vykonávanie úprav v existujúcich prehľadoch
Vo vopred pripravených prehľadoch má užívateľ možnosť vykonávať celý rad úprav ako v
zmysle usporiadanie získané informácie, tak v zmysle zmien výberových kritérií. Vďaka
odlišnému spôsobu uloženia dát v dátovom sklade sa u podstatnej časti takýchto úprav nemusí
vykonávať opakované vyhľadávanie údajov. Avšak aj pri opakovanom vyhľadávaní sú
požadované informácie k dispozícii neporovnateľne rýchlejšie.
[Brzák, Manažérska informatika, 79]
1.3 Business Intelligence

V súvislosti s využitím analytickým a reportovacích nástrojov sa často používa ďalší termín
Business Inteligence (BI). V roku 1989 s nim po prvý krát prišiel Howard Dresner , ktorý
neskôr pôsobil ako riaditeľ výskumu a viceprezident spoločnosti Gartne. Dresnerova definícia
znie nasledovne: Business Inteligence predstavuje súhrn nástrojov umožňujúcu užívateľom
ucelený prístup k dátam v podnikových informačných systémoch a ich analýzu za účelom
lepšieho porozumenia podnikania a zákazníkov.
Tento užší pohlaď býva niekedy obohatení o vymedzenie BI ako sady inteligentných IT
nástrojov používaných pri plánovaní a analýzach. My sa však budeme držať obvyklého
výkladu vychádzajúceho z definície Howarda Dresnera a BI budeme chápať ako ucelený
prístup k práci s ucelenými dátami, slúžiaci hlavne k sledovaniu trendov , podpore lojality
zákazníka ,hľadania nových príležitostí iných činností. Ktoré významne ovplyvňujú
strategické riadenie a budovanie znalosti báze organizácie. Pojem BI využijeme podobne ako
renomovane výskumne agentúry k označeniu platforiem , na ktorých základe vzniká
manažérsky informačný systém. Pojem „Business Inteligence“ ide najlepšie preložiť ako
„podnikové spravodajstvo“.
Business intelligence (BI) sú aplikácie IS/IT určené pre vedúcich pracovníkov a špecialistov
podniku primárne pre účely analytických a plánovacích činností. Na rozdiel od ostatných
aplikácií (napr. ERP) sú takmer výlučne orientované a optimalizovaných na uvedený
charakter činností. Sú preto založené na špecifických technológiách, ktorých základom je
multidimenzionálne uloženie dát, resp. multidimenzionálne databázy.
Aplikácie BI pokrývajú analytické a plánovacie funkcie väčšiny oblastí podnikového riadenia,
teda predaju, nákupu, marketingu, finančného riadenia, controllingu, majetku, ľudských
zdrojov, výroby.
Do aplikácií business intelligence zaraďujeme:
 manažérske aplikácie – EIS ( Executive Information Systems)
 dátové sklady (data warehouses)
 dátové tržiská (data marts)
 dolovanie dát (data mining)
 reporting
[Pour a kolektív, Informační systémy a elektronické podnikání, 68-69]
1.3.1 Základné riešenia aplikácií Business Intelligence
 OLAP technológie
 multidimenzionálne databázy
Základný princíp na ktorom sú aplikácie BI založené je niekoľkodimenzionálna tabuľka
umožňujúca veľmi rýchlo a pružne meniť jednotlivé dimenzie a meniť tak pohľady užívateľa
na modelovanú ekonomickú realitu. Ide tak v podstate o princíp ń-dimenzionálnej Rubikovej
kocky´ naplnenej najdôležitejšími podnikovými dátami.
[Pour a kolektív, Informační systémy a elektronické podnikání, 69]
1.4 Manažérsky informačný systém

Ďalší termín, ktorý sa používa v vzťahu k DW a BI, je manažérsky informačný systém(MIS-
Management Information System). V súvislosti s MIS sa môžeme stretnúť tak isto
s akronymom EIS (Executive Information System) ktorý ide správne vyložiť ako označenie
pre informačný systém exekutívy- výkonne zložky managementu. EIS býva niekedy radení
ako vrstva nad MIS , niekedy je používaný ako synonymum pre MIS. Skratka EIS však môže
znamenať také označenie pro akýkoľvek podnikový informačný systém – Enterprise
Information System. Keď hovoríme o EIS v súvislosti s podporov výkonnej zložky
managementu , potom pôjde o to isté čo v prípade MIS.
„Manažérsky informačný systém predstavuje IS/ICT podporu pre vrcholové rozhodovanie,
ktoré môže mať podobu zjednotených , predmetovo orientovaných databáz navrhnutých za
týmto účelom alebo jednoduchých analýz vykonávaných v databázach transakčných
systémov“
Z vyššie uvedenej definície vyplývajú tri zásadne poznatky
1. Moderné MIS neslúži iba k podpore strategického rozhodovania. Výsledky analýz dát
z prevádzkových aplikácii sú veľmi často používané aj pri operatívnej činnosti.
Stávajú sa tak neoddeliteľnom súčasťou podpory riadenia podnikových procesov
2. Moderné MIS vyžaduje odlišný pohlaď na jeho zakomponovanie do podnikovej
architektúry, budovania aj funkčne požiadavky.
3. Moderný MIS je širšie vymedzený pojem ako dátový sklad.
1.5 Niektoré ďalšie frekventovane pojmy

EDW(Enterprise Data Warehouse ) predstavuje v podstate synonymum pre Dátové sklady,
pretože vo svojom význame zdôrazňuje dlhoročné budovanie firemného dátového skladu,
v ktorom sa integrujú atomizované a agregovane dáta z mnohým oborov podnikové činnosti.
Data Markt- dátové trhovisko- je určené pre špecifickú skupinu užívateľov , nar
marketingové oddelenie. Obsahuje agregovane dáta, ktoré čerpá z EDW, OTLP systémov
alebo z nezávislých zdrojov . Jeho budovanie trvá niekoľko týždňov a niekoľko mesiacov.
VDW(Virtual Data Warehouse )- virtuálny dátový sklad- môže mať viacej možných
významov. Označujú sa tak napríklad aplikácie umožňujúce náhľady do hlavnej databázy
EDW s cieľom získania informácií pred vykonaním vlastnej analýzy, typizáciou a uložením
dotazu. Môže ísť ale aj o synonymum pre dátové trhovisko.
K problematike dátových skladov patrí bezpochyby aj dolovanie dát – Data Mining.
Predstavuje ucelenú metodiku odkrývania skorej nejasných či neznámych vzoriek a vzťahov
v rozsiahlych databázach, ktorá svojimi výsledkami obohacuje manažérke rozhodnutia
o doposiaľ neznámej, overenej a pritom použiteľnej znalosti.
V oblasti elektronického obchodovania sa využíva takzvaný Web Mining, ktorý umožňuje

získavať dáta o prehliadaní stránok užívateľmi a analyzovať tak ich chovanie. Web Mining
vykonáva hlbokú analýzu weblogov , cookies , či vyplnených formulárov. Vo svojich
kalkuláciách dokáže zohľadňovať ďalšie informácie, ako napríklad , odkiaľ návštevníci
prichádzajú , ako účinne sa webovými stánkami pohybujú , či dokonca ako verziou
prehliadača disponujú. Profesionálny Web Miner je schopný identifikovať a odfiltrovať
automaticky generované návštevy fulltextových vyhľadávačov, ktoré sú veľmi časté a svojou
prítomnosťou skresľujú výpoveď o chovaní návštevníka.
Technológia dolovania dát je často nesprávne zamieňaná s dátovými skladmi. V analytických

systémoch je DW obvyklým zdrojom pre dolovanie dát, a je teda tomuto procesu podriadený.
Dátový sklad nemusí ale vždy predstavovať vhodný zdroj pre dolovanie dát. Veľmi záleží na
tom, aké úpravy boli pri plnení skladu na dátach vykonané. Ich čistením mohlo napríklad
dôjsť k strate údajov súvisiacich s pôvodom zdroja. Tieto potom môžu pri hľadaní skrytých
súvislostí citeľne chýbať.
2. História
Prvá implementácia automatizovanej podpory manažérskeho rozhodovania spadá do polovice
60.rokov minulého storočia. V roku 1964 prišla spoločnosť IBM na trh s mainframovou
platformou System/360. Tá znamenala do tejto doby nevídaný technologický pokrok, ktorý
umožnil spoločnostiam integrovať všetky jeho aplikácie do jedného informačného systému.
Prakticky neobmedzené schopnosti uskladňovania dát a možnosť okamžitého prístupu
dovolili na tejto platforme nasadiť prvé manažérske informačné systémy.
Skutočné dátové sklady sa začali budovať na začiatku osemdesiatych rokov minulého
storočia. Boli využívané predovšetkým pre podporu strategického rozhodovania. Priamy
prístup k nim mal iba veľmi obmedzený počet užívateľov a vtedajšie technológie nedovolili
ich plnenie inak ako štvrťročných alebo mesačných intervaloch.
Hlavným problémom prvých dátových skladov bola obťažná integrácia dát z rôznych
prevádzkových systémov a nízka kvalita vstupných dát , neodpovedala požiadavkám na
spracovanie. Väčšina dotazov odosielaných do dátového skladu bola vtedy predom známa.
Ďalší ťažkosti prinášali dlhé odozvy na zadávanie dotazov.
V Českej republike sa napríklad dátové sklady začali zavádzať v prvej polovici
deväťdesiatych rokov minulého storočia. V tej dobe išlo skôr o manažérske nadstavby nad
ERP systémom, využívané iba pre vrcholové riadenie.
V tej dobe boli na český trh uvedené tiež komerčné DW produkty, ako napríklad SAS pre
oblasť bankovníctva alebo odborové aplikácie spoločnosti Pragodata, vybudované na bázi
manažérskeho informačného systému spoločnosti Pilot Software. Manažérske riešenie Pilot
bolo v spolupráci s centralizovaným dátovým skladom Oracle úspešne aplikované napr.
V Českým energetických závodoch.
Behom nasledujúceho obdobia sa výrazne premenilo podnikateľské prostredie. Podstatne
zosilneli nároky na rýchlosť spracovania (odozvy na zadané dotazy) a významne sa zvýšilo
percento predom neznámych dotazov. V dôsledku automatizácie procesov na nižšom stupni
riadení organizácie bolo rovnako potrebné zaistiť priamy prístup k dátovému skladu väčšiemu
počtu užívateľov.
Všetky spomenuté faktory potom spoločne priniesli značný nárast požiadaviek na výkonnosť
technológií (hardware, sieťová infraštruktúra a databázová platforma), ktoré sú
k vybudovaniu dátového skladu potrebné.
Informačné technológie prešli za tú dobu tiež dynamickým vývojom. Dnes sú už natoľko
pokročilé, že nepredstavujú žiadnu prekážku, a to ani pri realizácií veľmi náročných
DW(Datawarehouse) projektov. Problémom zostáva ich dostupnosť pre široké spektrum
organizácií. Sú totiž náročné na finančné investície a schopnosť ľudí naučiť sa jej správne
využívať.
3. Ako funguje dátový sklad

Dátový sklad získava svoju obsahovú náplň predovšetkým z transakčných systémov. Ako
interné dátové zdroje k analýzam slúžia historické dáta o zákazníkoch, zásobách, finančných
transakciách či výrobných dodávkach. Nejde opomenúť ani externé zdroje, ktorými sú
zvyčajne dáta obsahujúce podobu katalógov, zoznamu s kontaktnými informáciami,
obchodnými údajmi a pod.
Dátový sklad je postavený na databázovej platforme (DBMS – Database Management
System). Jej vlastnosti – robustnosť, spoľahlivosť, bezpečnosť atď. – ovplyvňuje chod celého
riešenia. Databáza OLTP systému uchováva záznamy o jednotlivých uskutočneniach (typicky
sumarizovaná) a potom ukladaná do dátového skladu, nad ktorým sa neskôr podľa potrieb
vykonáva okamžité spracovanie OLAP analýz.
Dáta sú uchovávané v databáze skladajúcej sa z riadkov a stĺpcov. Riadok zodpovedá
záznamu (record, tuple); stĺpec odpovedá atribútom (poliam v zázname). Každý stĺpec má
určený dátový typ. Dátových typov je obmedzené množstvo, typicky šesť alebo viac (napr.
znak, reťazec, dátum, číslo...). Každý atribút (pole) záznamu môže uchovávať jedinú hodnotu.
Vzťahy nie sú explicitné, ale skôr plynú z hodnôt v špeciálnych poliach, tzv. cudzie kľúče
(foreign keys) v jednej tabuľke, ktoré sa rovnajú hodnotám v inej tabuľke.
[Sodomka,Klčová, Informační systémy v podnikové praxi, 411-412]
Takto teda funguje typický jednoduchý dátový sklad. Jeho užívateľské rozhranie tvorí OLAP
nástroje a tie pracujú nad jeho databázovou platformou v niektorej z týchto typických podôb:
 ROLAP (Relational OLAP) prevádza analýzy na základe relačných tabuliek, čo je
vhodné u rozsiahlych databáz alebo historických dát, ktoré nie sú často spracovávané.
ROLAP reprezentuje priamy prístup k dátam relačného primárneho systému, čo
znamená, že dáta prezentované v zobrazovacom nástroji sú získavané priamo
z pôvodných dátových zdrojov. Pre uloženie dát sa teda používa štandardná relačná
databáza a dáta z nich sú vyberané pomocou SQL dotazov.
 MOLAP (Multidimensional OLAP) funguje prostredníctvom viacrozmerného
spôsobu uloženia dát, čo napomáha vysokému výkonu vo fázy dopytovania. Produkty
kategórie MOLAP využívajú špecifické viacrozmerné databázy. Informácie sú v tejto
špeciálnej databáze, navrhnuté ako množina multidimenzionálnych matíc,
aktualizovaný a doplňovaný v určitom pravidelnom intervale.
 HOLAP (Hybrid OLAP) zabezpečuje ukladanie dát čiastočne v relačnej a čiastočne
vo viacrozmernej databáze, čo vďaka uloženiu agregácie vo viacrozmerné a veľkého
objemu dát v relačnej databáze umožňuje vysoký výkon systému. HOLAP predstavuje
prístup kombinujúci obe predošlé technológie. V tomto prípade sú dáta čerpané
priamo z primárnych zdrojov, pričom ich časť je ukladaná do multidimenzionálnych
matíc (model MOLAP). V zásade sa do viacrozmernej databázy ukladajú agregované
údaje, ich získavanie býva najviac časovo náročné.
 DOLAP (Desktop OLAP) sú využívané predovšetkým užívateľmi ktorý pracujú
v teréne. Ty sa môžu pripojiť k centrálnemu úložisku, stiahnuť si potrebné dáta na svoj
lokálni počítač a vykonávať potrebné analýzy.
Tabuľka1.Technológie a nástroje dátových skladov.
Technológie, nástroje Popis Funkcie a vlastnosti
RDBMS Relačná databázová platforma Robustnosť, spracovanie
(Relational Database tvoriaca veľkého objemu dát,
Management System) jadro dátového skladu (napr. MS integrácia OLAP, podpora
SQL tvorby ETL aplikácií.
Server)
OLTP Prevádzkový (transakční) Slúži ako interní zdroj dát
(Online Transaction informačný systém pre dátové sklady.
Processing) (ERP,CRM,SCM)
OLAP Užívateľské rozhranie databáze Nástroje využívané
(Online Analytical dátového skladu k analýze, resp. reportingu
Processing) z databázy dátového skladu.
ROLAP Aplikácia OLAP nástrojov Vhodné pre rozsiahle
(Relation OLAP) sprevádzaná na základe relačných databázy alebo dáta, ktoré sú
tabuliek. často analyzované.
MOLAP Aplikácia OLAP nástrojov na Vysoký výkon vo fázy
(Multidimensional základe viacrozmerného spôsobu dokazovania, vhodné pre
OLAP) uloženia dát. malé a stredne veľké objemy
dát.
HOLAP Dáta sú pri aplikácií OLAP Vysoký výkon je daný
(Hybrid OLAP) uložené čiastočne v relačnej a viac uloženým agregácií vo
rozmernej databáze. viacrozmernej a veľkého
objemu dát v RDBMS.
DOLAP Umožňuje stiahnuť a analyzovať Využiteľné predovšetkým
(Desktop OLAP) dáta na lokálnom pracovisku. pre pracovníkov v teréne.
ETL Nástroje plniace dátový sklad Rieši natívni prístup
(Extraction, z OLTP systému a iných zdrojov k databázam rôznych
Transformation, v pravidelných intervaloch. výrobcoch, spojenie rôznych
Loading) tabuliek, čistí dáta a pod.
Metadata Dáta o dátach popisujúce činnosť Zjednodušená údržba
rôznych nástrojov(ETL,OLAP) dátového skladu a popis jeho
dát.
Data Mining Špeciálne postupy a algoritmy Získavanie znalostí
určené k analýze rozsiahlych potrebných pre rozhodovací
dátových súborov. managementu a strategické
riadenie firmy.
3.1 Dátová pumpa (Transformation)

Máme štruktúru atomických dát DW (dátový sklad) a zvolené, ktoré atribúty budú v DW
uložené. Ďalšou úlohou je definovať pravidlá pre prenos, filtrácia a transformácia zdrojových
dát do DW alebo DM (Dátová tržnica) , teda definovať funkcie dátové pumpy.
[Šarmanová, Informační Systémy a Datové sklady, 105]
Každému zdrojovému údajmi priradíme jeho integračné funkciu do DW. Najjednoduchšie
prípad je samotná kópie zdrojovej hodnoty do DW, pokiaľ nie je potrebné niektoré z
nasledujúcich kontrol, úprav, transformáciou.
Definícia všetkých funkcií čistiacich, integrujúcich, transformačných - pre každý atribút sa
vykoná
• kontrola správnosti údajov a prípadné čistenie dát chybných (cleaning) - oprava chýb:
ak sú dáta v zdrojovej databáze dobre kontrolované, nie je táto funkcia potrebná, ak tam
existujú dáta chybné, sú teraz 2 možnosti opravy: buď odhaliť chybu a odstrániť ju až
pomocou dátovej pumpy v DW, alebo spoluprácou so správcom DB (Databáza) doplniť
kontroly už zdrojového IS, chybné historické a existujúce dáta však je nutné v dátovej pumpe
opraviť vždy.
• riešenie chýbajúcich hodnôt - opäť sa rozhodujeme medzi niekoľkými možnosťami: údaje
takmer nevyplnené môžeme ignorovať, nezaradiť do DS, ak sú to dôležité údaje pre DW a
máme tu možnosť doplniť ich z iného zdroja, ak nie sú údaje úplne prázdne a atribút je pre
DW dôležitý, označí ich špeciálnou hodnotou.
3.2 Funkcie dátového skladu

Citlivým miestom dátového skladu sú tzv. ETL (Extraction, transformation,Loading)
nástroje. Pomocou nich sú do dátového skladu čerpane dáta, preto je pre nich zaužívane
označenie dátová pumpa.
ETL nástroje obsahujú vlastný jazyk a používajú vlastne dátové štruktúry. Riešia hlavne
prístup k vzájomne nekompatibilným databázam a proces zabezpečujúci prevod , čistenie
a ukladanie dát.
Proces plnenia dátového skladu alebo ETL proces začína extrakciou dát z primárnych
zdrojov. Vzhľadom k tomu jednotlivé primárne dátové zdroje nepracujú z týmto dátovým
modelom, často krát nepoužívajú ani tieto dátové typy, sú niektoré údaje v dátových zdrojoch
obsiahnuté iba implicitne. Preto je nutné ich odvodenie z iných údajov.
Počas úvodnej fázy ETL procesu (extraction) sú ďalej vyhľadávané a odstraňovane
nekonzistencie vo vstupných dátach. Extrahované dáta môžu byt pred ich transformáciou
uložené v dočasných úložiskách. Komponenty dočasného úložiska dát (DSA-Data Staging
Area) bývajú využívane najčastejšie pri tých DW riešeniach , ktorých zdrojom sú veľmi
vyťažene transakčne systémy. Nasadením DSA sa zníži potreba využiť transakčné systémy
pri ETL procesu a ty sa potom môžu plne venovať obsluhe podnikových procesov. DSA ide
využiť i v prípade , keď je nutné dáta pred spracovaním previesť do požadovaného
databázového formátu , napríklad z textovej podoby.
Po extrakcii nasleduje transformácia (transformation), ktorá prevedie dáta získané
z jednotlivých dátových zdrojov do unifikovaného dátového modelu, nad ktorým je možno
vytvárať agregácie a zoskupené dáta potom uložiť do dátového skladu(loading).
ETL nástroje tak zásobujú dátový sklad iba vybranými dátami určenými pre ďalšie skúmanie.
Tie sa však vo vnútri dátového skladu uchovávajú a doplňujú dlhodobo tak , aby bolo možné
analyzovať ich historicky vývoj.
Samotne ETL nástroje sú kritickým miestom celej implementácie a môžu predstavovať 60%
až 80% nákladov na vývoj dátového skladu. Aby bolo možne transformovať a čistiť veľké
objemy dát , nezaobíde sa dátová pumpa bez detailnej customizácie , poprípade optimalizácie
podľa potrieb užívateľskej organizácie. Údržba každého z rôznych nástrojov (ETL,OLAP
atď.) vyžaduje vlastný popis dát alebo údaje o samotných dátach dátového skladu. Tie sú
riedené zdieľaným spôsobom prostredníctvom tzv. metadát(dáta o dátach)
Pokiaľ majú iné aplikácie využívať služby dátového skladu, musí byť presne popísane, čo
dátový sklad obsahuje. Každý z nástrojov obsahuje vlastný spôsob popisu dát (databáze
systémový katalóg, ETL nástroje- popisy vstupných a výstupných polí a popisy transformácii,
OLAP nástroje – popisy dimenzii a faktov), tímy sú pravé metadáta.
3.3 Konceptuálne modelovanie DW (Dátový sklad)

Úlohy konceptuálneho modelovania
Pri konceptuálnom modelovaní dátového skladu sa nevychádza zo zadania zadávateľa a jeho
potrieb evidencie, ako u IS. Situácia je iná a môžeme ju charakterizovať nasledujúcimi bodmi:
• DW vychádza z existujúcich databázových schém, konceptuálne modely zdrojových IS sú
pre DW zadaním. Úlohou je na základe mnohých zdrojov (databázových schém) vytvoriť
integrované schéma budúceho DW. To nie je len zjednotením zdrojových schém, ale úlohou
konceptuálneho modelovania je rozhodnutie, ktoré dáta budú súčasťou DW a ktoré nie.
• Po výbere atribútov je nutné definovať pravidlá pre dátovú pumpu: ako sa pri prenose
vybraných atribútov bude každý atribút filtrovať, integrovať atď.
• Ďalšou úlohou je koncepčné rozhodnutie, či sa bude tvoriť jediné schéma pre jednotný DW,
alebo jedno pre každý Data Mart, dátovú tržnicu (DM). Tento proces sa niekedy označuje
skratkou ETL (extrakcia, Transformácia, Loading) a pomenováva tak čiastkové úlohy.
4. Multidimenzionálna databáza
Pre dáta analytického typu sa nehodí, aby bola ukladaná do relačných databáz. Aby mohli
poskytovať rôzne analýzy a prehľady slúžiace pre strategické rozhodovanie, je nutné, aby sme
sa na tieto dáta mohli dívať z viacerých hľadísk súčasne, malo by teda byť možné vytvárať
tzv. Multidimenzionálne pohľady, čo je pre dáta uložené v relačnej databáze veľký problém.
Nástroje koncového užívateľa musí umožňovať analýzu v zmysle nachádzania súvislostí,
ktoré nie sú z primárnych dát na prvý pohľad zrejmé. Naviac je nutné prechádzať ohromné
množstvá dát, vypočítavať súčty (ktoré v relačných databázach nie sú automaticky uložené),
rýchlo meniť pohľady na dáta, rýchlo a čo možno automatizovane ich ukladať do
prehľadných tabuliek a grafu.
Základné princípy, na ktorých sú aplikácie BI založené, je niekoľkodimenzová tabuľka

umožňujúca veľmi rýchlo a pružne meniť jednotlivé dimenzie a meniť tak pohľady užívateľa
na modelovanie ekonomickej reality. Ide tak v podstate o princíp "n-dimenzionálnej
Rubikovej kocky" naplnené najdôležitejšími podnikovými dátami.
Žiadosť pohľadu na dáta z viacerých hľadísk (dimenzií) súčasne prináša požiadavku na

optimalizované fyzické ukladanie dát, pričom sa jedná o dáta historické, agregované
a ukladané v jednoduchej štruktúre vhodné pre analýzu. Pre takéto uloženie a operácie
z dátami sa vžil v 80.rokoch minulého storočia názov OLAP- On Line Analytical
Processing. Zo zavedením pojmu BI a súčasne s rozvojom nástrojov a technológií pre
podporu analytických činností v organizácií, sa však výraz OLAP trošku zúžil.
[Gála, Podniková informatika, 93]
Užší význam definuje OLAP čisto technologicky, teda ako „ Informačné technológie
založené predovšetkým na koncepcií multidimenzionálnich databázach. Ich hlavným
princípom je niekoľko dimenzionálna tabuľka umožňujúca rýchle a pružne meniť jednotlivé
dimenzie a meniť tak pohľady užívateľov na modelovanie ekonomickej reality.“
[Jiří Horák , Bronislava Horáková, Datové sklady a 0využití datové struktury typu
hvězda pro prostorová data, 5]
4.1 Základné princípy OLAP systémov

Z predchádzajúceho textu vyplýva, že informačné systémy môžu pracovať s 2 základnými
typmi, informáciu operátu aktívnymi a analytickými. Prvý typ, operatívne informácie, slúži
pre každodenné spracovanie dát jednotlivých prevádzkových útvaroch podniku. Tieto
systémy pracujú s dynamickými dátami uloženými väčšinou v relačných databázach. Dáta
zobrazujú momentálny stav podniku a počas dňa sa môžu aj niekoľko krát meniť ,napr.
účtovníctvo podniku, obchodné prípady a pod. Keďže sa jedná o aplikáciu, ktorá pracuje
v reálnom čase (riadenie výroby, účtovníctvo, sklady...), sú označované ako tzv. OLTP
systémy, z anglického On Line Transaction Processing. Výstupom z týchto systémov sú
dáta, ktoré sú uložene väčšinou v relačnej databáze a ktorú nazývame primárnymi alebo
produkčnými dátami.
Druhá kategória, systémy pracujúci s analytickými informáciami, patria medzi aplikácie
využívajúce primárne dáta vytvorené v OLTP systémoch. Pre svoju špecifickú prácu s dátami
sa pre tieto systémy vžil názov OLAP - On Line Analytical Processing. Analytické (niekedy
tiež dispozitívnych) informácie poskytujú na základe informácií získaných z primárnych dát.
Tieto informácie sa odlišujú aj svojou štruktúrou, dáta sú zbavená zbytočných detailov,
obsahuje rôzne agregácie, ale čo je najdôležitejšie, zachytávajú faktor času, teda históriu dát.
4.2 Základné vlastnosti OLAP
 Informácie poskytujú na základe vstupu získaných z primárnych dát.
 Ich dáta sú uložené multidimenzionálne.
 Obsahujú rôzne úrovne agregácií dát.
 Zachytávajú faktor času a umožňujú realizovať časové zrovnanie, časové rády .
Na základe technológií OLAP sú založené tzv. OLAP databázy, ktoré predstavujú jednu
alebo niekoľko súvisiacich OLAP kociek. Tie na rozdiel od dátových skladov, už zahrnujú
predspracované agregácie dát podľa definovaných hierarchických štruktúr dimenzií a ich
kombinácií. Technológie OLAP sa praktický realizuje v niekoľko variantách, a to MOLAP,
ROLAP, HOLAP a DOLAP
 Pre MOLAP (Multidimensional OLAP) je charakteristické špeciálne uloženie dát

v multidimenziálnych OLAP kociek.
 ROLAP (Relational OLAP) rieši multidimenzionalitu uložených dát v relačnej
databáze.
 HOLAP (Hybrid OLAP) je kombinácia predchádzajúcich prístupov, kedy detailné
dáta sú uložené v relačnej databáze a agregované hodnoty sú uložené v binárnych
OLAP kockách.
 DOLAP (Desktop OLAP) je najmladšia architektúra OLAP databáz, ktorá sa
objavila koncom 90.rokov. DOLAP umožňuje pripojiť sa k centrálnemu úložisku
OLAP dát a stiahnuť si potrebnú podmnožinu kocky na lokálni počítač. Všetky
analytické operácie sú prevádzané nad túto lokálnou kockou, takže užívateľ nemusí
byť pripojený k serveru. Toto je výhodné pre mobilné aplikácie a podporu
mobilných užívateľov všeobecne.
4.3 MOLAP
Implementácia BI na úrovni binárnych OLAP databáz
Aby analytické systémy mohli poskytovať požadované analytické funkcie a podporu
v rozhodovaný, je nutné, aby sa na ich dáta mohlo pozerať z viacero hľadísk súčasne. Malo by
teda byť možné vytvárať tzv. multidimenzionálne pohľady, čo je pre dáta transakčných
aplikácií veľký problém. Je nutné prechádzať veľké množstva dát, vypočítavať agregácie,
rýchlo meniť pohľady na dáta a ukladať ich do prehľadných tabuliek a grafov.
Multidimenzionálne databázy sú preto optimalizované pre uloženie a interaktívne

využívanie multidimenzionálnych dát. Výhodou multidimenzionality, resp. OLAP technológií
(v užšom chápaní), je rýchlosť spracovania a efektívnej analýzy multidimenzionálnych dát
(tzv. drilling, slice, and dice apod.). Základným princípom je tak niekoľko dimenzionálna
tabuľka umožňujúca veľmi rýchlo a pružne meniť jednotlivé dimenzie.
Obr.2 Princíp multidimenzionálnej databáze

Prvky dimenzií sú väčšinou usporiadané v hierarchickej štruktúre, tzn. Že sa rozdeľuje na
skupiny prvkov, podskupiny, až na jednotlivé prvky. Produkty BI zaisťujú automatickú
agregáciu hodnôt (ekonomických premenných), a to podľa definovaných hierarchických
úrovní dimenzií. Jednoduchým príkladom takejto štruktúry a odpovedajúcich agregácií môže
byť dimenzia „teritória‘‘
[Gála, Podniková informatika, 94-95]
Ak by totiž bolo nutné on-line vypočítať súčty pri zobrazovaný tabuľky či grafu zo stotisíc ale
milión hodnôt, odozva systému by mohla byť neúnosné veľká. Hierarchia uloženia
agregovaných dát potom užívateľovi umožňuje sa pružne po požadovaných úrovniach
agregácie pohybovať (na úrovni kontinentu, zemi, regiónu,....) aby bolo nutné vždy znovu
požadované agregácie počítať. Tento princíp sa označuje ako drill-down (pohyb-
sprístupnenie dát na nižšiu úroveň agregácie- detailnejších dát ) alebo drill-up (v opačnom
smere).
4.4 ROLAP
implementácia BI na úrovni relačnej databáze
ROLAP (Relačná OLAP) znamená implementáciu DW pomocou relačných tabuliek (tabuľky
dimenzionálne a tabuľky faktov) organizovaných do hviezdicových schém.
Dátové modely produkčných systémov sú komplexné, obsahujú mnoho tabuliek a ich väzieb.
Takto organizované dáta sú z hľadiska ich vytvárania a aktualizácie veľmi efektívne, ale pre
bežného užívateľa sa stávajú veľmi nepriehľadné. Pre vyššie uvedený nedostatok sa objavila
snaha o zjednodušenie takého uloženia dát a jeho prispôsobenie pre tvorbu BI riešení. Vznikol
tak relační dimenzionálni model, ktorému sa tiež bežne hovorí Schéma hviezdy (STAR
scheme), resp. Schéma snežnej vločky (SNOWFLAKE scheme)
Obr.3 schéma tabuliek dimenzií (Hviezdicová schéma)
Obr.4 schéma tabuliek dimenzií (Snežnej vločky)
V centre schémy je tzv. tabuľka faktov, takže tabuľka sledovaných ekonomických a ďalších
ukazovateľov identifikovaných kľúčom zložených z kľúčov tzv. dimenzionálnych tabuliek,
v nich sú uložené prvky jednotlivých dimenzií. Dimenzionálne tabuľky slúžia pre uloženie
textových informácií o hodnotách uložených v tabuľke faktov. Typicky si to ide predstaviť
ako číselník. V niektorých prípadoch sa preto dimenzionálne tabuľky upravujú, resp.
normalizujú. To v tomto prípade znamená, že sa dimenzionálna tabuľka rozdelí podľa
hierarchickej úrovne dimenzií do viacerých tabuliek, aby sa rovnaké dáta v tabuľke
neopakovali. Schéma, ktorá takto vznikne, nazývame SNOWFLAKE (schéma snežnej
vločky)
[Gála, Podniková informatika, 96-97]
4.5 DOLAP
(Desktop OLAP, dátový sklad na klientskom počítači) Databázista si ľahko predstaví
realizáciu schémy v relačnom dátovom modeli. Bohužiaľ pre multidimenzionálne analýzy by
boli výsledné normalizované tabuľky príliš ťažkopádne. Tabuľky agregovaných hodnôt by sa
pri každej zmene základných dát museli počítať. Počet stupňov hierarchie dimenzií je pevný z
analýzy a nie je rýchlo dynamicky meniť zobrazovanie sum "hore a dole" podľa tejto
hierarchie.
5. Metadáta
5.1 Metadáta dátového skladu
Metadáta sú definované ako dáta o dátach a tejto súvislosti aj s implementáciou riešení
Business Inteligence. Metadáta sú teda popisom všetkých informačných systémov a ich
jednotlivých častí. Z pohľadu riešenia Business Intelligence zahŕňajú hlavne dátové modely,
popisy funkcii, pravidiel, reportu, či požiadaviek na reporty a pod.
[Gála, Podniková Informatika,105]
Prirodzene aj v DW budú potrebné metadáta, dokonca je ich ešte viac. V operatívnych
databázach sú metadáta koncovým užívateľom v podstate skryté, pracujú s nimi len vývojári a
správcovia databázy. Používatelia pracujú s IS prostredníctvom používateľského rozhrania len
ako s čiernou skrinkou. O obsahu dátového skladu = o jeho dátových štruktúrach však musia
byť užívatelia - analytici vopred informovaní, aby mohli DS správne a efektívne využívať.
Preto musí pracovať aj s jeho metadátami, rýchlo pomocou nich vyhľadať požadované dáta aj
ich interpretáciu.
[Šarmanová, Informační Systémy a Datové sklady ,131]
Podľa obsahu môžeme metadáta pre DS rozdeliť na niekoľko druhov:
5.1.1 Metadáta pre správu DS
Sú informácie, ktoré slúžia analytikom, návrhárom pri vývoji DW a správcom DW pri
prevádzke. Sú to:
• metadáta zdrojových dát pre potrebu analýzy a návrhu DS
- rozmiestnenie databáz na serveroch,
- štruktúry zdrojových databáz,
- štruktúry a opisy entít a ich väzieb,
- definícia a opis atribútov, ich dátových typov, domén vrátane merných jednotiek, kľúčov,
indexov,
- informácie o vlastníctvo dát a prípadných väzbách medzi zdrojovými dátami (kto komu
poskytuje
dáta);
[Šarmanová, Informační Systémy a Dátové sklady ,131-132]
• metadáta dátového skladu - katalóg DS obsahuje

- zoznam serverov,
- rozmiestnenie databáz DW na serveroch,
- definícia tabuliek a pohľadov,
- definícia a opis atribútov, primárnych a cudzích kľúčov, indexov,
- rozdelenie atribútov na dimenzie a ich hierarchie, fakty a popisné atribúty, obmedzenia na
dotazy,
- definícia tabuliek dimenzií a tabuliek faktov;
[Šarmanová, Informační Systémy a Dátové sklady ,132]
• metadáta pre dátovú pumpu - mapovanie zdrojových dát z operatívnych databáz do

cieľových atomických dát v primárnom dátovom sklade
- pre každý atribút DW pravidlá pre jeho kopírovanie, integračné funkcie, transformačné
pravidlá,
zmeny formátov, verifikácia, odvodzovania, obmedzenie na otázky;
- merné jednotky a konverzný koeficienty používané medzi jednotkami, najmä keď sú to
vzorca alebo koeficienty premenné v čase;
- informácie o časovanie prevodov dát z DB do DW;
- obchodné pravidlá a postupy, vzťahy pre výpočet ekonomických ukazovateľov, používané
vzorca
a postupy výpočtu;
• metadáta pre dáta a funkcie na pozadí DW

- podporné dočasné dátové štruktúry pre transformácie, pre zobrazenie užívateľom,
- funkcie extrakčné a transformačné, funkcie pre zabezpečenie kvality; poradie ich spúšťania,
parametre programov,
- opis stratégie plnenia DW, definícia dočasných podporných tabuliek a ich funkcie;
• architektúra DW - v prípade, že existujú dátové tržnice, potom
- štruktúra DW a dátových tržníc DM,
- definícia podmnožín DM z DW,
- poradie plnenie DW a DM;
• prístupové práva a zabezpečenie DW

- informácie o užívateľských rolách a ich právach,
- informácie o jednotlivých užívateľoch a ich úlohách
5.1.2 Metadáta pre koncových užívateľov

slúžia používateľom, či už špecializovaným analytikom alebo koncovým a náhodným
užívateľom. Patria k nim metadáta pre vytváranie dotazov a pre správnu interpretáciu
výsledkov:
• obsah dátového skladu - dátové štruktúry v užívateľsky prívetivej forme s možnosťou
výberu; dimenzie a ich hierarchie, fakty a ich agregované hodnoty,
• kvalita dát - pri všetkých údajov musia existovať informácie o ich kvalite, aké sú a ktoré
dáta sú spoľahlivé, upozornenie na dáta chybné, chýbajúce,
• preddefinované otázky a zostavy - používaných dotazov, katalóg výstupných zostáv a
grafov, význam jednotlivých prvkov v zostavách a vo výsledkoch analýz, význam popisov,
metód a analýz pre užívateľov,
• obchodné pravidlá a postupy - pretože je možné používať rôzne vzťahy pre výpočet
ekonomických ukazovateľov, musia mať užívatelia informáciu o použitých vzorkách a
postupoch výpočtu(Napríklad pre výpočet nákladov alebo zisku a pod.),
• stavové informácie - v dennej prevádzke pri dennom doplňovaní skladu môže byť sklad
v rôznom štádiu vývoja a užívateľ musí byť informovaný o tom, či obsahuje sklad len dáta
staré, či je práve plnený a nové dáta ešte nie sú dostupné alebo už obsahuje aj dáta aktuálne,
• pravidlá prečisťovanie skladu - pravidlá, kedy je možné dáta zo skladu odstrániť, či
archivovať ,aby používatelia vedeli, do kedy budú ktoré dáta v sklade dostupné,
• história plnenie skladu - história všetkých plnení skladu od počiatočných jednorazových
zdrojov až po súčasne periodickeé doplňovanie dátami; pre všetky prenosy by mali byť
evidované prenášané objemy dát, protokoly o zistených chybách v dátach, doby nutnej pre
prenosy a výpočty agregáciou; záznam o histórii má byť synchronizovaný so stavovými
informáciami; užívateľom dostupný by mal byť tiež časový plán plnenia, aby boli
informovaní o tom, kedy budú k dispozícii čerstvé dáta.
5.1.3 optimalizačné Metadáta
môžu okrem iného slúžiť na optimalizáciu návrhu a výkonu dátového skladu. Tieto
metadáta zahŕňajú
• definície agregáciou a ich umiestnenie - opis navigácia medzi D-tabuľkami a F-
tabuľkami rozsiahleho skladu v ROLAP pre urýchlenie prístupu k požadovaným
dátam;
• obmedzenia na otázky - pre rýchlejšie plnenie DW, menšiu kapacitu, rýchlejší
prístup k dátam,
• štatistiky dátového skladu - sledovanie početnosti rôznych typov otázok nad
dátovým skladom; táto informácia je spätnou väzbou pre správcov skladu a ten
môže na ich základe identifikovať ako dáta často sledované, tak dáta dlhodobo
nepoužívané; výsledkom môže byť úprava obsahu DW.
5.1.4 Metadáta ako základ pre automatizáciu podporných procesov

môžu slúžiť ako podklad pre neskoršiu automatizáciu rady funkcií, doteraz realizovaných
na mieru DW. Evidujú sa priebežne a zaznamenávajú
• metadáta pre extrakcie a transformácie - priraďovanie zdrojových dát cieľovým
procesom môže slúžiť ako podklad pre generovanie skriptov extrakcie, integrácie a
transformácie,
• kvalita dát - používatelia môžu zadávať prípustné hodnoty pre rôzne atribúty, to slúži na
odhalenie chýb s prípadnou následnou automatickou opravou,
• generovanie otázok - zaznamenaná štruktúra dát slúži na generovanie užívateľských
SQL dotazov,
• koncové nástroje - generovanie nástrojov pre zobrazenie štruktúry tabuliek alebo
obsahu sumačná tabuliek
5.2 Štandardizácia metadát

zdieľanie a výmena metadát je jedným z dôležitých problémov pri návrhu dátových skladov,
preto existuje snaha o štandardizáciu metadát.
Tieto snahy je možné pozorovať v troch úrovniach:
• vytvárajú sa všeobecne použiteľné skladiská metadát, tzv. Repozitára = špecializované
databázy pre uchovanie dát o systéme (príkladom sú Platinum Repository, Microsoft
Repository, UnisysUREP, ...); tie potom môžu byť použité u ktoréhokoľvek DW a teda
prístup k nim by bol jednotný zo všetkých takýchto dátových skladov;
• definujú sa štandardy pre výmeny dát od dodávateľských združení (príkladom sú CWMI -
Common Warehouse Metadáta Interchange od OMG - Object Management Group -
IBM,Oracle, Unisys, ... a Mdis - Meta Data Interchange Specification od MDC - Meta Data
Coalition- Microsoft); aj keď má každý spolupracujúci DW vlastné metadáta, stačí vytvoriť
konverzné programy do a z štandardizovaných metadát a opäť je možné komunikovať s
ostatnými dátovými skladmi;
• otvorené API rozhranie k produktom - väčšina dodávateľov riešení dátových skladov
poskytuje otvorené rozhranie pre prístup produktov tretích strán a aplikácií k ich metadátam
(príkladom sú Hyperion Integration Server, IBM Meta Data Interchange Language).
[Šarmanová, Informační Systémy a Dátové sklady ,133-134]
1. Budovanie dátového skladu

Pri praktickej realizácii DW projektov sa väčšinou uplatňujú prvky ako z konceptu Inmona tak
Kimballa. Budovanie DW sa opiera o podobné kroky , ako akýkoľvek iný IT projekt . Jeho
úspešná realizácia je však ďaleko viac kriticky závislá na tom, ako dôkladne sa prevedie
prípravná fáza.
[Sodomka, Klčová, Informační systémy v podnikové praxi, 416]
Prípravná fáza budovania DW by mala byť zahájená formulovaním strategických zámerov, a
to na základe celopodnikovej a informačnej stratégie organizácie. Tento krok by mal byť
potvrdený silnou podporou projektu zo strany vrcholového manažmentu a jeho
zodpovednosťou za realizáciu. Už v tomto okamihu je vhodné prizvať ku spolupráci partnerskú
organizáciu , a to predovšetkým preto, aby management korigoval smerom k reálnej predstave
o vplyve DW na podnikanie firmy.
Nasleduje stanovenie požiadavok užívateľských skupín na jednotlivých úrovniach riadenia a
analýza pripravenosti organizácie a stavu IS/ICT. Tento krok sa rovnako len ťažko obíde bez
spolupráce s dodávateľom alebo externého poradcu. Ľudia, ktorí nie sú zaťažený rutinou
každodennej prevádzky, môžu ľahšie viesť workshopy aby zistili, ako na tom firma v
skutočnosti je. Ich cieľom je nájsť s užívateľom spoločný jazyk a preložiť jeho potreby do
uskutočniteľnej podoby.
Do dátového skladu sa väčšinou nepreberajú všetky dáta prevádzkového informačného
systému, ale iba určité podoblasti, ktoré majú byť predmetom ďalšieho skúmania. V primárnej
databáze dátového skladu sú dáta stále uložené relačným spôsobom a ide vlastne o akýsi obraz
vybranej časti prevádzkového systému s tým rozdielom, že sa tu uchovávajú dáta vrátane
histórie.
[Brzák, Manažerská informatika, 71]
Nakoniec je navrhnutý logický model DW, stanoví sa plán projektu a vyberie sa vhodné
riešenie. Ak by sa zanedbala prípravná fáza, potom hrozí že práve navrhnutý logický model
DW nebude odpovedať potrebám firmy. Tým sa obvykle výrazne obmedzí ďalšie rozširovanie
DW a možnosti archivácie dát.
Kľúčovým faktorom úspechu DW projektu je správne nastavenie jeho priorít a očakávania
užívateľov. Nasledujúcich šesť až deväť mesiacov po rozbehnutí projektu totiž nedochádza v
organizácii väčšinou k žiadnym podstatným zmenám. Obzvlášť vo veľkým podnikoch sa
dolaďuje integrácia systémov a sklad sa plní dátami. Projekt musí však aj behom tohto obdobia
pokračovať podľa plánu.
Budovanie dátového skladu je treba chápať ako kontinuálny proces , ktorý funguje na princípe
prírastku. Tie sa dajú v pravidelných intervaloch identifikovať a vyhodnotiť, čo je základný
predpoklad k postupnému vytvoreniu jednotnej a integrovanej platformy pre manažérsky
informačný systém.
Začína sa najprv u dvoch výstupných zostáv (reportov) za oddelenie, následne sa pripojujú

ďalšie a pritom bežia ďalšie projektovanie fázy. Po identifikácii prírastku je vhodné previesť
prezentáciu výsledkov a overiť praktické využitie (napríklad v trojmesačných časových
intervaloch).
Budovanie dátového skladu ohrozujú predovšetkým prehnané počiatočné očakávania, chybné
nastavenie priorít , nevhodné rozloženie projektu v čase a neschopnosť vyhodnotiť pravidelné
prírastky tak , aby boli užívateľom úplne zrejmé prínosy z DW.
Netreba zabúdať ani na bezpečnostné hľadisko pri budovaní DW. Vzhľadom k tomu , že dátový
sklad obsahuje všetky dôležité informácie o podniku, oplatí sa dobre ošetriť všetky prístupy ku
nemu, a to až na úroveň riadka. Pritom treba zabezpečiť prístupy nie len pred neoprávneným
vniknutím zvonka , ale taktiež z vnútra organizácie.
Pri budovaní DW je výhodné mať k dispozícii primárnu databázu. Údaje v tejto primárnej
databáze sú do značnej miery zhodné s dátami v prevádzkových databázach IS. Pre vytvorenie
primárnej databázy je niekoľko závažných dôvodov:
 do primárnej databázy sú ukladané „čisté“ a plne verifikované dáta
 ukladané dáta môžu pochádzať z rôznych IS (zjednotenie zdrojov)
 do primárnej databázy môžu byť ukladané aj historické dáta
 vytvorením primárnej databázy je v prostredí dátových skladov k dispozícii potrebná
detailná úroveň informácií
 primárna databáza môže byť vedená aj v odlišnom prostredí (server, databázový stroj)
Vytvorením primárnej databázy tak získame v dátovom sklade jednotnú dátovú základňu pre
ďalšie využitie.
1. Architektúra dátových skladov
6.1 Jednoúrovňová architektúra (BUS architektúra)
Zakladateľom a priekopníkom tejto architektúry dátového skladu sa stal v roku 1996 Ralph
Kimball. Jej základné rysy sú:
 dátový sklad firmy môže byť vybudovaný inkrementálnym prístupom – postupným
budovaním nezávislých dátových trhov
 primárnym komponentom dátového skladu je nezávislé dátový trh s odpovedajúcimi
dimenziami sledovania javu vo firme
 všetky dátové trhy sú navrhnuté s využitím metód dimenzionálneho modelovania
 každé dátové trhy odpovedá aplikačnej doméne vo firme (vlastné metadáta, vlastné
OLAP nástroje a pod.).
 za dátový sklad sa považuje zjednotenie dátových trhov firmy s odpovedajúcimi
dimenziami
[Bebr – Doucek, Informační systémy pro podporu manažerské práce, 174-175]
Požiadavku zaistiť koherenciu dát v rôznych organizačných jednotkách firmy sa do BUS
architektúry dátového skladu (resp. dátového trhu) premieta v Úpravených dimenziách´ (
CD – Conformed Dimensions) a Úpravených faktoch´ (CF – Conformed Facts). Význam
týchto dimenzií a faktov odráža potrebu sledovať niektoré veličiny v lokálnych dátových
trhoch bez ohľadu na to, či sú bezprostredne potrebné pre prácu určitej inej organizačnej
jednotky.
[Bebr – Doucek, Informační systémy pro podporu manažerské práce, 175]
Kľúčovým hľadiskom pre správnu implementáciu dátového skladu s BUS architektúrou je
spôsob, akým sú v ňom zahrnuté dimenzie spravujúce dáta o celofiremných prierezových
procesoch. Riešenie tejto otázky má značný vplyv na charakter dátového modelu, najmä na
jeho granularitu a celkový počet dimenzií obsiahnutých v dátových modeloch.
V praxi to znamená, že počas prípravy dimenzionálneho dátového modelu je nutné spraviť
analýzu prierezových procesov, z nich odvodiť spoločné – odpovedajúce CD dimenzie a tie
potom zahrnúť do celkovej koncepcie riešenia dielčích dátových trhov vo firme ako celku.
V tejto fáze projektu obvykle komplikuje riešenie dátového skladu rozdielnosť používania
a interpretácia niektorých pojmov, názvov a termínov v rámci firmy. Na analytikov
a projektantov dátového skladu kladie táto skutočnosť vyššie nároky a pre úspešné zvládnutie
projektu zavádzania dátového skladu by bolo vhodné, aby mali veľmi dobrú znalosť
vnútorného firemného prostredia. Celofiremný CD predstavuje dáta o rovnakej skutočnosti
(entite) vo všetkých jej výskytoch vo firme. Obecne povedané, predstavuje skutočnosť že
dimenzie sú identicky rovnaké v každom jednotlivom dátovom trhu čo sa týka štruktúry aj
obsahu. Príkladom môžu byť dimenzie regiónu, času, výrobnej značky a podobne.
Fungovanie, dôveryhodnosť a konzistencia dát v takto definovanom dátovom sklade sú
značne závislé na kvalite správy jednotlivých dimenzií.
6.2 Správa dimenzií
Celofiremné dimenzie (CD – Conformed Dimensions) sú v dátovom sklade reprezentované

dátovými tabuľkami, ktoré musia mať zhodný význam čo sa týka štruktúry ako aj obsahu vo
všetkých dátových trhoch firmy. Významným problémom je správa takýchto dimenzií najmä
v heterogénnom prostredí, kde rôzne časti interného informačného systému firmy fungujú na
rôznych technológiách. Pre tieto situácie a účely je obvykle definovaný samostatný dátový
trh, v ktorom sú uložené dáta o jednotlivých CD firmy – dátový trh pre správu CD. Takýto
dátový trh sa skladá z rôznych vrstiev a krokoch:
6.2.1 Vstup dát do DATA STAGING AREA
Do záchytnej oblasti pre dáta (DSA) sú transformované dáta z primárneho IS firmy. Pri
transformácii sú dáta vyčistené a je zaistená ich koherencia.
6.2.2 Vstupná DSA
Do tejto vrstvy vstupujú dáta zo záchytnej oblasti pre dáta a sú v nej uložené. Charakter tejto
vrstvy umožňuje prípadný reštart alebo návrat k pôvodnému stavu konfigurácie CD vo firme
pred započatím transformácie dátového skladu.
6.2.3 Procesná vrstva
Obsahuje definovanú množinu procesov ktoré sú spojené s tvorbou a aktualizáciou
jednotlivých dátových trhov firmy. Pokiaľ nedošlo k zmene dimenzií, sú dáta pre novo
vytvorený dátový trh ukladané do DSA a do distribučnej vrstvy. Pokiaľ došlo naviac k zmene
CD alebo jej rozšírení, musia byť zmeny zahrnuté do celkovej CD Repository.
6.2.4 CD Repository
Obsahuje dáta o všetkých jednotne definovaných dimenziách pre celú firmu.
6.2.5 Výstupná DSA
Obsahuje dáta pre novo vytvorené dátové trhy alebo pre zmeny vo fungujúcich trhoch. Dáta
sú tu uchovávané po dobu ich distribúcie z distribučnej vrstvy do dátových trhov. Táto vrstva
môže byť využívaná aj pre predkalkulácie rôznych agregovaných hodnôt obsiahnutých
v cieľových dátových trhoch (dátových rezoch) a tým môže znižovať nároky na technické
vybavenie u koncových klientov.
6.2.6 Distribučná vrstva
Obsahuje konečné dáta, určené k distribúcii do jednotlivých dátových trhov.
6.3 Dvojúrovňová architektúra

Zakladateľom a priekopníkom tejto architektúry dátového skladu bol Bill Inmon. Jej základné
rysy sú nasledujúce:
 centrálnym prvkom pre ukladanie firemných dát interného IS je nezávislý dátový
sklad
 do dátového skladu sú dynamicky ukladané transformované a konsolidované primárne
dáta z TSP úrovne interného IS
 z dátového skladu je odvodený obsah všetkých závislých dátových trhov vo firme
Typický dátový sklad využívajúci dvojúrovňovú architektúru sa skladá z niekoľkých
základných komponentov:
 súčasné detailné dáta – slúžia ako zdroj pre prípadné nové zostavenie
agregovaných dát rôznych úrovní (prípadne celého dátového skladu)
 staršie detailné dáta – slúžia ako zdroj pre prípadné nové zostavenie starších
verzií agregovaných dát rôznych úrovní (prípadne zostavenie staršej verzie celého
dátového skladu), dáta sú ukladané formou archívu
 sumarizované dáta (vysoko, jemne) – vo forme dátových trhov slúžia ako
podklady pre špecializované manažérske aplikácie
 metadáta – obsahujú popis transformácií od primárnych dát z TPS vrstvy do
jednotlivých komponentov dátového skladu a ich následné transformácie do
dátových trhov
V prípadne finančných inštitúcií ako sú napríklad banky kde každá banka disponuje obvykle
niekoľkými produkčnými systémami ktoré podporujú jednotlivé činnosti banky. Pre potreby
operatívneho rozhodovania je nutné, aby v takýchto inštitúciách bola k dispozícii pre podporu
rozhodovania integrovaná báza dát z týchto rôznych produkčných systémov. Rozhodnutie sa
musí vykonávať cez všetky služby portfólia banky, nielen cez jednu z nich alebo cez určité
vybrané. Takúto požiadavku sa prejaví pridaním nových komponentov do architektúry
dátových skladov – operatívneho úložiska dát ktoré predstavuje rozšírenie dátového skladu
smerom k produkčným OLTP systémom. Operatívne úložisko dát poskytuje základ pre
uchovanie dát produkčných systémov v krátkom časovom intervale a ich sprístupnenie
manažérskym aplikáciám bez nutnosti zaťažovať vlastný produkčný systém ďalšími
operáciami ako sú priebežné agregácie a pod.
6.4 Porovnanie architektúr Dátových skladov
6.4.1 Jednoúrovňová BUS architektúra

Toto poňatie dátového skladu firmy je postavené na budovaní nezávislých dátových trhov
a poskytuje rýchlejšie dosiahnutie aspoň čiastočného zavedenia prvku pre podporu
manažérskej práce do chodu firmy.
Výhody:
 Budovanie prichádza zdola – jednotlivé organizačné jednotky firmy si samy
špecifikujú požiadavky na dátové trhy
 Investícia do takýchto riešení sa ľahšie presadzujú a sú výrazne menšie, a to ako
finančné tak aj čo sa týka investovaného času vlastných zamestnancov
 Pomerne rýchlo môžu byť lokálne dátové trhy využívané pre podporu manažérskej
práce a rozhodovacích procesov
 Nad jednotlivými trhmi je možné budovať prezentačnú vrstvu na báze ľubovoľných
technológií (OLAP aj OLTP – napr. aj v MS Excel)
Nevýhody:
 Pokiaľ sa pred návrhom nevykoná celková analýza CD pri prierezových procesoch,
nie s=u dátové trhy konzistentné a nie je možné ich bez významných rizík zjednotiť do
celofiremného dátového skladu
 Po celú dobu fungovania sú v riešení obsiahnuté potencionálne nekonzistencie dát vo
vnútri takto poňatého dátového skladu
 Časté používanie rôznych rozhraní pre prezentačnú vrstvu
 Pomerne zložitá správa celofiremných CD
Podľa názoru Billa Inmona: Postupne vedie k chaosu v rámci firmy a ďalšie integrácie do
celkového dátového skladu sú diskutabilné.
6.4.2 Dvojúrovňová architektúra
Výrazným rysom tejto architektúry je dominantná úloha centrálneho firemného dátového
sklad, ktorý získava primárne dáta z TPS systémov – vo firme sa vytvára jednotná verzia
firemnej pravdy. Z tohto zdroja sú ďalej generované závislé dátové trhy ktorých zdrojom je
práve centrálny dátový sklad.
Výhody:
 Vytvorením primárneho nezávislého dátového skladu sa vytvára jednotná verzia
firemnej pravdy
 Jasná a jednotná koncepcia budovania aplikácií pre podporu manažérskej práce
 Možnosť nasadenia prakticky ľubovoľného počtu dátových trhov pre podporu
manažérskej práce vo firme (základom analýzy sú dáta obsiahnuté v dátovom sklade,
nie v produkčných systémoch)
Nevýhody:
 Z počiatku zložitejšie budovanie – je potreba spraviť analýzu centrálneho dátového
skladu a informačných potrieb ktoré má uspokojovať
 Výsledky práce sa dostavia neskôr než u tvorby dátových prvkov jednoúrovňovou
architektúrou
 Vyššie finančné náklady
7. Dátové trhy (Data Mart, DMA)
Princíp dátových trhov je obdobný ako v prípade dátových skladov. Rozdiel je v tom že
dátové trhy – Data Marty, sú určené iba pre obmedzený okruh užívateľov (oddelenia, divízie,
pobočky, závod, ...). Podstatou sú tak decentralizované dátové sklady, ktoré sa budú postupne
integrovať do celopodnikových riešení. V niektorých prípadoch slúžia ďalej Data Marty aj pre
vytvorenie celopodnikového dátového skladu ako medzistupeň pri transformácii dát
a produkčných databáz.
7.1 Dátový sklad ako množina dátových trhov
„Dátový sklad nie je nič iné ako zjednotenie dátových trhov,“ je veta s ktorou prišiel
zakladateľ dátových skladov Ralph Kimball. Tvrdenie R.Kimballa znamená, že namiesto
vytvárania jedného dátového skladu postupne budujeme jednotlivé dátové trhy. Logickým
zjednotením týchto dátových trhov potom vzniká dátový sklad.
[Gala, Podniková informatika, 103]
7.2 Integrovaný dátový sklad
Počiatkom 90-tych rokov vznikli dva rozdielne pohľady na vnútorné usporiadanie dátových
skladov v súvislosti s dátovými trhmi vzhľadom na vnútornú architektúru dátových skladov.
Hlavnými predstaviteľmi týchto názorov boli Bill Immon, ktorý formuloval svoju teóriu
dvojúrovňovej architektúry dátového skladu, a Ralph Kimball ktorý bol duchovným otcom
architektúry jednoúrovňovej.
[Bebr, Informační systémy pro podporu manažerské práce, 173]
Pri koncepcii integrovaných dátových skladov sa dáta z prevádzkových systémov ukladajú do
centrálneho dátového skladu. Nad týmto dátovým skladom sú potom budované dátové trhy,
ktoré slúžia pre podporu rozhodovacích procesov jednotlivých útvarov podniku. Táto
architektúra bola navrhnutá Billom Inmonom s myšlienkou vytvoriť architektúru, ktorá by
minimalizovala redundantné dáta a zároveň počet interface medzi produkčnými systémami
a dátovým skladom.
Je teda zrejmé, že R. Kimball preferuje cestu od dátových trhov k dátovým skladom, zatiaľ čo
B. Inmon práve opačnú. Obidve poňatia majú svoje výhody a nevýhody, a záleží vždy na
konkrétnych podmienkach a potrebách podniku, ktorý dátový sklad a trhy vytvára.
[Gala, Podniková informatika, 103]
8. Dátové kocky
Dátové sklady a OLAP nástroje sú založené na multidimenzionálnom dátovom modely. Tento

model zobrazuje dáta vo forme dátovej kocky (viď obrázok).
Dimenzie kocky reprezentujú rozdielne kategórie pre analýzu dát. Kategórie ako napríklad
čas, geografické umiestnenie alebo rôzne výrobkové rady sú typickými dimenziami v
dátových kockách. Kocky však nie sú obmedzené len na tri dimenzie. Dimenzie sú zvyčajne
usporiadané do hierarchií tak, že mapujú stĺpce v relačných databázach.
[ Brzák, Manažerská informatika, 78]
Hierarchie dimenzií sú zoskupované do úrovní obsahujúcich hodnoty danej dimenzie. Každá
úroveň v dimenzii môže byť sumarizovaná, aby vytvorila hodnoty pre vyššiu úroveň. Napr. v
dimenzii času sumarizáciou hodnôt v úrovni deň získame hodnoty pre vyššiu úroveň mesiac.
[Brzák, Manažerská informatika, 77-78]
Miery sú kvantitatívne hodnoty v databáze, ktoré majú byť analyzované. Typickými mierami
bývajú predaje, náklady a rozpočty. Miery sú analyzované oproti rôznym kategóriám dimenzií
dátovej kocky. Napr. analýza predajov (miera) určitého výrobku (dimenzie) v rôznych
krajinách (konkrétna úroveň dimenzie -geografická poloha) počas dvoch určitých rokov
(úroveň dimenzie čas).
9. Chyby pri budovaní Dátových skladov
1. Nesprávna reťaz sponzorstva - správna reťaz zahŕňa dve kľúčové osoby nad manažérom,
ktorý zodpovedá za DW: sponzora (dodáva peniaze do projektu) a ťahúňa z aplikačného
prostredia - ten by mal mať tri vlastnosti: už predtým získaný rešpekt, vlastný zdravý
skepticizmus nad technológiami a byť rozhodný a pružný.
2. Stanovenie nevhodných očakávaní - nie všetko bude vyhovovať užívateľovi, DW sa
väčšinou napĺňajú agregovanými dátami, ak chce používateľ zdrojové dáta, odpoveď je
frustrujúca -frustrácia sa hodí na hlavu DW manažérovi.
3. Politicky naivné správanie - často sa tvrdí, že DW umožní robiť manažérovi lepšie
rozhodnutia. Správny manažér sa stane nedôverčivý, DW robí lepšie rozhodnutia ako ja?
4. Predimenzovanie DW – neodporúča sa prísť s dotazníkom, čo by malo byť v DW. Možno
tak získať príliš veľa požiadaviek a príliš málo skutočne potrebného.
5. Zámena návrhu databázy DW za návrh transakčného systému - ide o dva úplne odlišné
ciele. U DW sa pýtame viac na agregované dáta, trendy, sumy a podobne, otázky sú často len
raz, databáza je často neštandardná (ukladanie agregáciou narúša 3NF) pre jednoduchšiu
navigáciu potencionálnemu užívateľovi, DW obsahuje aj odvodená dáta, napr. spočítané
časové rady a podobne.
6. Voľba manažéra pre DW - skôr technicky než užívateľsky orientovaného.
7. Interné údaje starého štýlu (záznamy) - a nie externé dáta typu video, obrázky, zvuk (napr.
Používateľ chce vidieť obrazovú kópiu pôvodného papierového dokumentu a ten nie je k
dispozícii).
8. Prekrývanie a omyly v definíciách dát - jeden z najzauzlenejších problémov, ktorý sa
vypomstí riadiacemu pracovníkovi, ktorý nedodá a neodsúhlasí korektné definície dát.
9. Viera v sľuby týkajúce sa výkonu - skutočnosť neskôr ukáže, že prostriedky neboli dobre
odhadnuté a sú potrebné ďalšie investície. Zvlášť sa podceňujú náklady na sieť.
10. Stanoviť si krátky termín na vývoj DW - domnienka, že akonáhle je DW hotový, všetky
problémy skončili. DW je cesta, nie vzdialenosť. Užívatelia chcú stále nové dáta.
11. Zameranie sa na ad hoc dolovania dát a periodické zostavy - ani to nemusí viesť
k pokroku. Manažéri často nemajú čas všetko čítať, lepšie je vyvíjať systémy reagujúce na
zmeny toku dát do DW.
[Šarmanová, Informační systémy a datové sklady, 153]
9. Dolovanie dát (Data Mining)

Dolovanie umožňuje pomocou špeciálnych algoritmov automaticky objavovať v dátach
strategické informácie. Je to analytická technika pevne spojená s dátovými skladmi ako veľmi
kvalitným dátovým zdrojom pre tieto špeciálne analýzy.
Dolovanie dát je možné charakterizovať ako proces extrakcie relevantných vopred neznámych
alebo nedefinovaných informácií z veľmi rozsiahlych databáz. Dôležitou vlastnosťou
dolovania dát je, že sa jedná o analýzy odvodené z obsahu dát, nie vopred špecifikované
užívateľom, a jedná sa predovšetkým o odvodzovanie prediktívnych informácii, nielen
deskriptívnych. Dolovanie dát slúži manažérom k objavovaniu nových skutočností, čím
pomáhajú zamerať ich pozornosť na podstatné faktory podnikania, umožňujú testovať
hypotézy, odhaľujú v stále sa zrýchľujúcom a zložitejšom obchodnom prostredí skryté
korelácie medzi ekonomickými premennými a pod.
Existujú rôzne druhy nástrojov pre dolovanie dát. Niektoré z nich sú určené špecialistom so
znalosťami štatistiky, niektoré riadiacim pracovníkom. Cieľové určenie úloh dolovania dát je
však podobné väčšine úloh Business Intelligence, teda poskytovať strategické informácie
širokému spektru manažérov v organizácii. To, čo odlišuje dolovanie dát od iných štatistických
nástrojov, je práve zameranie na odlišných užívateľov. Štatistické úlohy dolovania dát sú
vykonávané automaticky podľa určených algoritmov, a tak ich cieľovým užívateľom môže byť
aj manažér bez špeciálnych znalostí štatisticky, nielen špecialista, ktorý nadväzne vyhotovuje
reporty pre manažéra.
Dolovanie je založené na množstve matematických a štatistických techník. Príkladom sú
rozhodovacie stromy, čo je prediktívny model, ktorý zobrazuje dáta v podobe stromu, kde
každý koreň určuje kritérium pre následné rozdelenie dát do jednotlivých listov. Neurónové
siete sú tiež využívané pre tvorbu prediktívnych modelov. Generické algoritmy simulujúce
biologickú evolúciu v riešení zadaných úloh. Clustering a klasifikácia je technika slúžiaca na
rozdelenie dát do skupín s obdobnými charakteristikami, klasifikácia potom definuje podstatné
atribúty skupín v podobe klasifikačných kritérií. Je evidentné, že techniky dolovania dát by
vyžadovali ďaleko väčší priestor, ale v tomto prípade sa len odvoláme na špecializovanú
literatúru, napr. [Rud, 2001]
9.1 Dolovanie z dát (Data mining), nástroje pre obchod a

marketing.Metodológia SEMMA.
Data mining je spôsob učenia sa z minulosti tak, aby sa v budúcnosti prijímali lepšie
rozhodnutia. Úlohou Data miningu je odhaliť neznáme informačné vzťahy v údajoch, ktoré sú
zachytené v obrovských dátových skladoch s cieľom získať konkurenčnú výhodu.
[Peter Stuchlý, Informačné systémy v marketingu, 45]
9.1.1Charakteristické oblasti použitia pre Data mining
V podstate akýkoľvek proces je možné študovať, pochopiť a vylepšiť s použitím Data

miningu. Túto techniku je možné aplikovať vo vzájomne veľmi odlišných oblastiach, ako je
napríklad riadenie procesu výroby, ľudské zdroje, atď. Data mining je užitočný všade tam,
kde je možné zhromažďovať údaje. V súčasnosti je Data mining úspešne aplikovaný v
rezortoch, ktoré:
 sú orientované na služby zákazníkom,
 poskytujú finančné služby,
 majú výrobný charakter.
9.1.2Definovanie cieľa pre Data mining
Prvým a najdôležitejším krokom v každom projekte modelovania je stanovenie jasného cieľa

za účelom vyvinutia procesu, ktorým tento cieľ dosiahneme. Efektívnym spôsobom ako určiť
cieľ projektu cieleného modelovania, alebo analýzy profilov je položiť si otázku, resp.
definovať problém, ktorý chceme riešiť. Ku všetkým týmto otázkam môžeme pristupovať
prostredníctvom analýzy profilov, segmentácie a cieleného modelovania. V súvislosti s
uvedeným je možné položiť napr. nasledovné otázky z perspektívy zákazníka a marketingu:
 Chceme prilákať nových zákazníkov? Modelovanie odozvy v kampaniach na

získavanie nových zákazníkov prinesie viac zákazníkov pri rovnakých
marketingových nákladoch.
 Chceme aby títo nový zákazníci boli profitabilný? Modelovaním hodnoty po dobu
existencie je možné nájsť s vysokou pravdepodobnosťou predpoveď profitability
zákazníkov pre dlhé obdobie.
 Chceme sa vyhnúť vysoko rizikovým zákazníkom? Zákazníci alebo potencionálny
zákazníci s vysokou pravdepodobnosťou stratovosti pre podnik nám pomôžu
identifikovať modely rizika alebo správania sa. Vo finančných službách vzniká strata
neplatením pôžičiek. Straty poisťovní pramenia z poistných plnení uplatňovaných
poistenými osobami.
 Chceme pochopiť charakter našich budúcich zákazníkov? Tento prístup spočíva v
segmentácii zákazníckej základne pomocou analýzy profilov. Z viacerých dôvodov sa
jedná o hodnotný postup. Umožňuje poznať charakteristiky najviac ziskových
zákazníkov. Ako náhle sú definované segmenty, môžeme ich charakteristicky priradiť
potenciálnym zákazníkom (osobám alebo podnikom) a tak vytvoriť modely pre
prilákanie viac profitabilných zákazníkov. Ďalšou výhodou segmentácie najviac a
najmenej ziskových zákazníkov je možnosť ponúknuť rôzne úrovne služieb.
 Chceme zo svojich neprofitabilných zákazníkov urobiť viac profitabilných? Pre
zvýšenie ziskovosti existujúcich zákazníkov je možné aplikovať cielené modely
krížového predaja a navyšovacieho predaja.
 Chceme si udržať svojich profitabilných zákazníkov? Modely pre výpočet
pravdepodobnosti odchodu či udržania si zákazníkov môžu identifikovať zákazníkov s
vysokou pravdepodobnosťou zníženia alebo ukončenia ich terajšej aktivity. Vďaka
nájdeniu týchto zákazníkov skôr ako od nášho podniku odídu, môžeme podniknúť
akciu na ich udržanie. Obvykle je lacnejšie si zákazníkov udržať ako ich znovu
získavať späť.
 Chceme zlepšiť spokojnosť zákazníkov? Na dnešnom konkurenčnom trhu je
spokojnosť zákazníka kľúčom k úspechu. Kombináciou trhového výskumu a
profilovanie zákazníka je efektívnou metódou merania spokojnosti zákazníkov.
 Chceme zvýšiť tržby? Zvýšenie tržieb je možné dosiahnuť niekoľkými spôsobmi.
Model získavania nových zákazníkov prinesie zvýšenie zákazníckej základne, čo sa
prejaví na zvýšení tržieb. Pre zvýšenie tržieb je možné použiť aj modely krížového
a navyšovacieho predaja.
 Chceme znížiť výdaje? Lepšie cielenie pomocou modelov pre získanie nových
zákazníkov a riadenie vzťahu so zákazníkmi vedie k redukcii výdajov tým, že vylepší
efektívnosť marketingového úsilia.
[Peter Stuchlý, Informačné systémy v marketingu, 46-47]
9.1.3Metodika procesu Data mining
Data mining nie je hotovým riešením, ktoré je dosiahnuteľné jednoduchým stlačením tlačidla.
Použitie techník Data miningu je spojené s vynaložením úsilia predovšetkým na strane
metodických a odborných zamestnancov podniku, ktorí sú znalcami svojej problematiky a
svojich údajov. Ako príklad je možné uviesť úplný postup procesu Data mining, ktorý je
popísaný metodológiou SEMMA a pozostáva z 5 základných krokov:
1) Sampling – výber vzoriek údajov. Tento krok nie je nevyhnutný, je však odporučený.
Databázy, ktoré sú v Data miningu predmetom skúmania, majú gigabyte-ové objemy.
V tejto situácií je potrebné uvážiť, či je pre danú analýzu potrebné použiť celú množinu
údajov, alebo bude postačujúca reprezentatívna vzorka údajov.
2) Exploration – prieskum, diagnostika a charakteristiky údajov. Zmyslom tohto kroku je

ustáliť predstavu o otázkach, na ktoré môže analýza konkrétnych údajov poskytnúť odpovede.
Prieskum údajov umožní zoznámiť sa s rozložením príslušných hodnôt v dátovom priestore a
získať obraz o rozložení extrémnych, alebo najčastejšie sa vyskytujúcich hodnôt a rozpoznať
existenciu sekvencií, asociácii alebo zoskupení. Inak povedané cieľom tohto kroku je ustáliť
otázky okolo riešeného problému.
3) Modification – manipulácia a transformácia údajov. Príkladom je:
 odstránenie nedefinovaných hodnôt,

 doplnenie popisov premenných,
 doplnenie nových informácií,
 vytvorenie zoskupení a pod.
[Peter Stuchlý, Informačné systémy v marketingu, 47-48]
4) Modelling - konštrukcia abstraktných modelov. V podstate ide o hľadanie odpovede na

položené otázky napr.: „Čo je príčinou vzorov nájdených v údajoch?“ (vzorom môže byť
pokles tržieb). Odpoveď môže byť získaná napríklad konštrukciou štatistického modelu,
ktorým je formulovaná a otestovaná explicitne vyjadrená hypotéza (problém v kvalite
produktov H1, cene H2, starostlivosti H3). Výber vhodnej metódy je závislý na charaktere
vzorov, ktoré boli v údajoch rozpoznané pri ich prieskume (napr. nelineárny charakter
interakcií, alebo veľký rozptyl v charakteristikách skupín a pod.). Metódy, ktoré sú
podstatné v tomto kontexte sú:
 neurónové siete,
 stromové modely,
 štatistické metódy.
5) Assesment - porovnanie a posúdenie vytvorených modelov. V tomto kroku sa na základe

porovnania získaných alternatív vyberie (podľa zvoleného kritéria) jeden model, ako výsledné
riešenie.
9.1.4Typické problémy riešené s využitím Data miningu sú napríklad:
1. segmentácia zákazníkov do skupín s podobnými vzormi správania sa,

2. efektívna profilácia zákazníkov pre riadenie individuálnych vzťahov s nimi,
3. identifikácia zákazníkov, ktorí prinášajú najväčší zisk a identifikácia dôvodov prečo,
4. identifikácia príčin prechodu zákazníkov ku konkurencii,
5. zistenie faktorov, ktoré významne ovplyvňujú nákupné správanie (vzory),
6. plánovanie efektívneho riadenia a správania informačných systémov,
7. predikcia neoprávnených transakcií s (odcudzenými) platobnými kartami, alebo hlásení
pochybných poistných udalostí,
8. plánovanie potrieb energie, dodávok vody, telekomunikačných služieb,
9. pochopenie budúceho správania zákazníkov na základe ich histórie a charakteristík,
10. zistenie kritických faktorov vo výrobe (letectvo, automobily, elektronika, hutnícky
priemysel, atď.).
1. Implementácia dátového skladu

Implementácia projektu dátového skladu do firmy obsahuje vždy niekoľko úskalí. Prvým
z nich je, kedy zvoliť optimálnu dobu pre zahájenie projektu – teda určiť, kedy je vhodné
obdobie pre začlenenie dátového skladu do architektúry úloh firmy.
[Richard Bébr, Petr Douček, Informačné systémy pre podporu manažérskej práce,183]
Na túto otázku je všeobecná odpoveď pomerne jednoduchá – vtedy, keď má firma dostatok
dát, aby mohla taký sklad najprv naplniť a pozdejšie efektívne využívať na podporu práce
manažérov. Ale tým nie sú všetky prípady, kedy je vhodné začať s budovaním dátového
skladu. Ďalším prípadom, kedy je tvorba dátového skladu vhodná, je situácia, kedy síce firma
nespracováva veľké objemy dát, ale má zložitú a členitú organizačnú štruktúru. V kombinácii
spracovania veľkých objemov dát a členitých organizačných štruktúr sa stáva zavedenie
dátového skladu úplnou nevyhnutnosťou. Ďalšiu situáciu vhodnú pre budovanie dátového
skladu, je vízia vytvorenia dátového potenciálu firmy, hoci sú v súčasnej dobe spracované
dáta inými spôsobmi.
Projekt implementácie dátového skladu je projekt ako každý iný v oblasti informačných
systémov a informačných komunikačných technológií. Pre riadenie jeho priebehu je potrebné
využívať odpovedajúce nástroje vrátane špecializovaných metodík, určených výhradne pre
dátové sklady. Sú nimi metodiky vykonávania analýzy jednotlivých skladovaných dimenzií
a metodika návrhu uloženia dát v dátovom sklade vrátane premietania týchto návrhov do
metainformačného systému firmy. Ostatné postupy riadenia projektu sú spoločné so všetkými
ostatnými projektami IS/ICT. Detaily projektového riadenia sú popísané v [DOU04].
Metodika zavádzania
Metodika, určená pre každý projekt v oblasti IS/ICT, má komplexný charakter, ktorý
umožňuje riešiť celý rad problémov, s ktorým je projekt IS/ICT vždy spojený. Bez ohľadu na
to, o akú konkrétnu metodiku sa jedná alebo o aký projekt sa jedná, musí každá z nich
vyriešiť minimálne nasledujúcu skupinu problémov.
 Analýzu rizík projektu,
 Životný cyklus projektu – periodizáciu projektu: rozčlenenie projektu do jednotlivých
menších organizačných častí – etáp, fáz, skupín činností a činností a tým rozdelenie
celého projektu do menších, viac kontrolovateľných a riaditeľných časových úsekov ,
 Určenie organizačných štruktúr, a ich vzájomných vzťahov,
 Priradenie právomocí a zodpovednosti k organizačným štruktúram a rolám,
 Formátov dokumentu, spôsobu akceptovania výsledkov, zmenového riadenia vrátane
zmeny obsahu zmlúv, podpisovanie dodatkov zmlúv, eskaláciu riešenia problémov,
dokumentáciu projektu, jej správu, správu projektovej kancelárie – výsledkov
projektu, spôsobu testovania výsledkov projektu, riadenie kvality, riadenie
bezpečnosti, spôsobu auditu a veľa, veľa ďalších činností
Celkovo možno návrh a implementáciu dátového skladu rozdeliť na nasledujúce etapy

jeho životného cyklu
 Návrh dátového skladu
 Vývoj a implementácia
 Využitie a prevádzka
[Richard Bébr, Petr Douček, Informačné systémy pre podporu manažérskej práce,184-185]
Návrh
 Výber a prípadne kombinácia rôznych metodík a technológii:

Objednávateľ a budúci užívateľ sa zoznamujú s možnosťou nasadenia rôznych
technológií, využiteľných pri riešení dátového skladu, s ich výhodami
a nevýhodami a skúmajú ako by vyriešili svoju situáciu ich kombináciou. Pre
túto fázu je vhodné využiť služby poradenskej a konzultačnej firmy, ktorá
nemusí byť dodávateľom zamýšľaného projektu – je často lepšie, pokiaľ nie je.
Výhoda prizvania poradenskej firmy je, že firma má skúsenosti s podobnými
projektami a pracovala s viacerými technológiami. To je jeden z dôvodov
prečo môžu poskytnúť nezaujatý pohľad na riešenie dátového skladu.
 Definícia cieľov, ktoré majú byť nasadením dátových skladov dosiahnuté:
V tejto fáze sú jednak definované ciele v spolupráci objednávateľa a užívateľa
s riešiteľom projektu (prípadne s konzultačnou firmou) a jednak sú
identifikované konkrétne problémy firmy a spôsoby ich riešení; sú stanovené
očakávané prínosy projektu a spôsoby ich merania; k definícii cieľu dátového
skladu je nutné pristupovať zodpovedne a je nutné tieto ciele špecifikovať tak,
aby ich bolo možné po ukončení projektu skontrolovať – respektíve aby bolo
možné po ukončení projektu použiť metriky, na ktorých základe bude možné
jednoznačne rozhodnúť, či je cieľ projekt dátového skladu splnený alebo nie
 Formulácia konceptuálneho dátového modelu a vyhodnotenie príležitostí
dát stavajúceho informačného systému: Zostaví sa konceptuálny model
dátového skladu a na jeho základe sa určí konkrétna technológia, ktorá bude
pre vlastné riešenie použitá a architektúra riešenia. Hlavným cieľom fáze je to,
že si objednávateľ a užívateľ dostatočne uvedomí svoje požiadavky, ktoré
kladú na riešenie a špecifikáciu skutočnej informačnej potreby jednotlivých
manažérov príslušných organizačných úrovní. Pre túto časť projektu je dôležité
nasadenie odborníkov, ktorí nie sú ovplyvnení vnútrofirmovým vnímaním
skutočností, informačných potrieb a tokov.
Vývoj a implementácia
etapa vývoja a implementácie sa skladá z nasledujúcich fáz:
 Analýza stavajúceho užívateľského prostredia: má za úlohu zmapovať jednotlivé časti
informačného systému firmy a vytvoriť metainformačný model dátovej základni. Na
základe vymedzenia určitých problémových oblastí obsahuje analýzu dát, súčasnej
infraštruktúry, funkčnú analýzu, analýzu informačných potrieb užívateľov a ich
znalostí.
 Logický a fyzický návrh databázového skladu: V tejto fáze je definovaný logický
a fyzický dátový model. Dôležitou súčasťou transformácie logického modelu do
štruktúry databázy (fyzického vyjadrenia) je jeho optimalizácia s ohľadom na
užívateľské požiadavky, vymedzené v prvej etape projektu – v návrhu, a ďalej
testovanie dosiahnutého výsledku na reprezentatívnom vzorku dát.
 Transformácia dát do databázy dátového skladu: Po definícii dátových štruktúr sa
musí definovať spôsob naplnenia a ďalšieho periodického plnenia databázy vrátane
zohľadnenia postupu extrakcie a konsolidácie dát. Tieto postupy sú zachytené
a uchovávané vo forme metadát, slúžiacich na zaistenie následného fungovania
dátového skladu.
 Vývoj a implementácia aplikácií. V tejto fáze sa uplatňuje prototypový vývoj
aplikácií, ktoré umožňujú navrhnúť také užívateľské rozhranie, ktoré bude vyhovovať
potrebám užívateľov a bude zároveň plne uspokojovať ich požiadavky na funkčnosť.
Aplikácie sú následne testované a overované vzhľadom k uspokojovaniu
požadovaných informačných potrieb ich budúcim užívateľom.
 Riadenie projektu dátového skladu na úrovni procesov vývoja a implementácie: Sú
používané štandardné postupy riadenia projektu s modifikáciami špecifických činností
pre projekty dátových skladov (pokiaľ je potrebné – v oblasti analýzy a návrhu).
Využitie a fungovanie
Nasledujúce fázy využitia a fungovania sú:
 Integrácia celkového riešenia: Dochádza k integrácii jednotlivých čiastkových riešení
(aplikácií) a nástrojov do formy celku. Celok je potom zahrnutý do architektúry úloh
firmy
 Výber vhodného analytického programového vybavenia pre monitorovanie
a fungovanie dátového skladu.
 Integrácia nového riešenia do stávajúcej štruktúry z technického hľadiska: Dátový
sklad je zahrnutý do rutinného fungovania v celom informačnom systéme firmy. Je do
nej úplne integrovaný a v metainformačnom systéme firmy sú nastavené rutinné
mechanizmy napríklad jeho plnenie a archivácia.
 Riadenie dátového skladu na úrovni procesu fungovania (využívanie funkčnosti),
údržby a ďalšieho rozvoja dátového skladu: Jedná sa o činnosti, ktorú sú vynútené
fungovaním dátového skladu V tejto fázy sa fungovanie dátového skladu neodlišuje
od fungovania iných častí informačného systému.
 Spetá väzba, verifikácia dátového skladu (návrhy, tvorby, implementácia
a fungovanie): Revízia výsledkov, dosiahnutie projektom implementácie dátového
skladu. Fáza obsahuje činnosti, ktoré sú spojené so zhromažďovaním požiadaviek
správcu a užívateľa na úpravy v dátovom sklade, prípadne so zmenami na jeho
funkčnosť nástrojov a aplikácií. Tieto požiadavky sú vyhodnocované a na základe
vyhodnotenia sa potom vykonávajú úpravy v stávajúcom dátovom sklade.
Proces tvorby dátového skladu je neustále v kruhu sa opakujúcom smere navzájom
prepojených činností (etapy a fázy životného cyklu projektu dátového skladu). Tento
prístup k tvorbe sa využíva aj v prípade zavedenia dátových trhovísk. Proces je len kratší
a nie je tak náročný v jednotlivých činnostiach.
[Richard Bébr, Petr Douček, Informačné systémy pre podporu manažérskej práce,187-
188]
Aj napriek vhodne zvolenej metodike riešenia a voľby technologických nástrojov je
kľúčovým momentom zdaru projektu implementácia dátových skladov a dátových tržísk
podpora projektov, poskytovaná vrcholným vedením firmy.
[Richard Bébr, Petr Douček, Informačné systémy pre podporu manažérskej práce,188
2. typy nástrojov
Vysoké objemy dát v DS a komplikovanejší charakter ich využívania oproti operatívnym

databázam
vedú k iným fyzickým modelom databáz a iným technológiám prístupu k dátam.
Používajú sa buď technológie špecifické pre dátové sklady, alebo sa aplikujú technológie
známe aj inde.
Ťažiskovou požiadavkou je maximálne zrýchlenie prístupu k dátam. Toho sa v súčasnosti
dosahuje
niekoľkými spôsobmi a ich kombináciami:
• inkrementálnym plnením skladu a výpočtovou agregáciou
• prepočítaním a uložením predpokladanej agregácie
• rozdelením dátového skladu na menšie dátové trhovisko
• použitím špeciálnych indexovacích technológií
• využitím paralelného prístupu k dátam
[Jana Šarmanová, Informačné systémy a dátové sklady, 135]
Inkrementálne plnenia dátového skladu
Uvádzali sme si, že dátový sklad sa na začiatku naplní jednorazovo dátami z archívov a iných
starších zdrojov, prípadne z aktuálnych operatívnych databáz. Potom sa pomocou dátovej
pumpy dopĺňa periodicky novými dátami, vzniknutými v operatívnych databázach od
posledného plnenia. Perióda môže byť rôzne dlhá, od denného cyklu (napríklad u obchodných
dátach) až po veľmi dlhý interval.
[Jana Šarmanová, Informačné systémy a dátové sklady, 135-136]
Zvlášť u denných dát treba dobu plnenia - prácu dátové pumpy - optimalizovať.
Výpočet agregovaných hodnôt zaberá veľmi dlhý čas. Ako sa celková veľkosť dát stále
rozširuje, sú to stále väčšie objemy pre sumovanie. Veľa času sa môže ušetriť na vhodnom
inkrementálnom spôsobe výpočtu agregátnych funkcií: suma nová = suma predošlá + suma
prírastku minimum novej = min (minimum predchádzajúce, minimum prírastku)
obdobne sa spočíta počet a maximum.
Nie je nutné znovu sumovať všetko. Len nové priemery je nutné spočítať podielom nových
súm a počtov. Počty, sumy, extrémy prírastkov sa spočítajú priebežne počas konverzie dát a
predchádzajúce hodnoty sú uložené v DS.
Indexové technológie
Indexov v DS sa používa niekoľkých typov. Niektoré z nich poznáme od IS, iné sú nové.
• B + stromy (majú všeobecné použitie v relačných SRBD)
• Binárne indexové matice (používajú sa v DS a OLAP)
• Join indexy (riešenie je súčasťou multidimenzionálnej analýzy)
• R stromy a rastrové indexy
B + stromy (Balanced tree)
Indexuje sa jeden alebo viac stĺpcov pomocou viacúrovňovej údajovej štruktúry, obsahujúcu
koreňový uzol s ukazovateľmi na uzly v ďalšej úrovni. Najnižšia úroveň obsahuje bloky listov
na každý riadok indexovej tabuľky. Ak sú listy previazané ukazovateľmi, umožňujú
sekvenčné prechádzanie tabuľkou, pátraniach na intervaly, triedenie podľa indexového kľúča
bez prechádzania celým B stromom - potom ich nazývame B + stromy.
Ďalšími možnosťami sú
􀂃 orezávanie indexových hodnôt v nelistových blokoch u dlhých reťazových stĺpcov,
􀂃 uchovanie u sekundárnych indexov nielen hodnôt indexového stĺpca, ale aj primárneho
kľúča pre
otázky zahŕňajúce oba atribúty (avšak index je efektívny, ak sú jeho záznamy oveľa kratšie
oproti záznamom dátové tabuľky!),
􀂃 kombinovanie viacerých indexov na základe zložených selektívnych podmienok pomocou
dotazov AND / OR, vytváranie niekoľkých dočasných indexov, jednoduchých, tie logicky
spojiť podľa selektívnej podmienky a ešte záverom pristúpiť k dátovým riadkom,
􀂃 SQL optimalizátory spracujú u hviezdicovej schémy najprv obmedzujúce podmienky nad
tabuľkami dimenzií a až nakoniec ich pripoja k tabuľke faktov.
Tieto technológie používa väčšina súčasných výrobcov SRBD - IBM, Oracle, Informix,
Sybase, atď.
Binárne indexové matice
Pripomeňme si binárne matice z predmetu Teória spracovania dát.

Pre sekundárne atribúty s malou doménou (malým počtom možných hodnôt) sa niekedy
z dôvodov ušetrenia kapacity používa indexovanie pomocou binárnych matíc. V indexovom
súbore nie je v záhlaví jediný indexový atribút, ale všetky jeho možné hodnoty. Pri každom
zázname sa zaznamenáva hodnota atribútu polohy jednotkového bitu v postupnosti, ktorá má
toľko bitov, koľko je hodnôt. Binárne matice sú zvlášť výhodné v prípade, že sa hodnoty
sekundárnych atribútov nemenia, keď sa nemenia záznamy, prípadne sa len pridávajú sériovo
na koniec súboru.
Ďalšou výhodou binárnych matíc je jednoduchá realizácia kombinovaných otázok pomocou
logických operátorov negácia, konjunkcia a disjunkcia. Pomocná indexová štruktúra teda
používa bit ako príznak príslušnosti hodnoty atribútu k danej entite. Počet stĺpcov bitmapu
zodpovedá kardinalite indexovaného stĺpca. Použitie bitmapových indexov nie je výhodné pri
operáciách INSERT a UPGRADE. Pretože sa však v DS iba číta, je jeho využitie výhodné.
Túto technológiu používa napríklad Oracle, Sybase atď.
Indexy pre podporu spojenia (Join Index)

Pre veľmi zložité otázky, zahrňujúce mnoho operácií spojenia (join) na veľkých databázach
nie sú používané klasické algoritmy spojené dostatočne rýchlo. Pritom v dátových skladoch sa
vykonáva takých spojení veľké množstvo - tabuľka faktov sa spája s radou dimenzionálnych
tabuliek, aby z nich získala jednak požadované hodnoty dimenzií a užívateľsky pohodlnejšie
opisy atribútov. Preto bola špeciálne pre podporu operácie spojenia vytvorená nová údajová
štruktúra - index pre podporu spojenia. Ide o pomocnú tabuľku skladajúcu sa z dvoch alebo
viacerých stĺpcov. Tá obsahuje index adresy príslušných záznamov v 2 alebo viacerých
spájaných tabuľkách podľa indexovaného spojenia.
Majme F-tabuľku F s adresami riadkov adr_F a dimenzionálnu D-tabuľku D s adresami
riadkov adr_D, spojenie sa vykonáva pomocou atribútu id_D.
Potom indexový súbor má stĺpce id_D, adr_F, adr_D, zotriedené pre binárne hľadanie podľa
id_D. Keď sa vyhľadá hodnota id_D, príslušné adresy na vyhľadanom riadku označí čísla
riadkov súčasne v oboch tabuľkách F aj D. Navyše vytvorením B + stromu nad týmto
indexom získame rýchly prístup pri zložitejších otázkach.
Kombinovaný index
Spojením princípov bitmapových indexov a indexov pre spojenie dostaneme kombinovaný

index. Je obdobou predchádzajúceho indexu, ale tabuľka faktov je spojená s dimenzionálnou
tabuľkou tak, že k opisnému sekundárnemu atribútu je skonštruovaný bitmapový index. Tak
je možné pristupovať k faktom spojeným s dimenziou a obmedziť hodnoty atribútu pomocou
bitových operácií.
R stromy
Pre podporu priestorových údajov bola navrhnutá špeciálna modifikácia B stromu,

zabezpečujúca efektívnejšie prístupy k rovinným (2D) alebo priestorovým (3D) objektom v
relačnej alebo objektovo-relačnej databázy. Proti B stromom sú v listoch okrem id_riadku aj
informácie o ohraničení príslušného objektu. V blokoch vyšších úrovní sa uchovávajú
informácie o ohraničenom zjednotení objektov nižšej úrovne. Pre prípad 2D (rovinné objekty)
ide napríklad o súradnice [x, y] pre pravý dolný a ľavý horný roh jedného objektu či
zjednotenie niekoľkých objektov.
Používanejším variantom R stromov sú rastrové indexy (tiež mriežkové indexy). Mapovací
priestor je rozdelený mriežkou, jej jednotlivé bloky sú očíslované a teda triedené. Vytvorením
druhej hustejšej mriežky sa bloky prvej úrovne opäť rozdelia a tak sa vytvára variant B
stromu vhodný pre prístup k priestorovým údajom.
Paralelizmus
Pre efektívnu prevádzku DS sa používajú ďalej paralelné technológie. Pre paralelný prístup sa
používajú dve metódy:
1. rozdelenie databázy do paralelne prístupných častí (partitioning)

• horizontálne delenie - pomocou selekcie tabuľky sa vytvoria disjunktné množiny riadkov, tie
sa umiestnia do zvláštnych fragmentov; hlavným kandidátom na rozdelenie sú vybrané
dimenzie a čas; negatívnym faktorom sú "horúce miesta", fragmenty nadmerne využívané
oproti ostatným fragmentom (Napríklad posledné časové obdobie); výhodou je možnosť
rozdelenia príslušných indexov, čo zvyšuje rýchlosť odozvy;
• vertikálne delenie - tabuľka faktov je projekcia rozdelená na viac fragmentov, tie sa
pomocou operácie spojenia spájajú pomocou redundantného primárneho kľúča; výhodou je
rýchlejší prístup k dátam pre užívateľov, ktorí majú záujem len o pridelené dáta (kratšie
záznamy, vyšší počet záznamov na stránke).

2. symetrický multiprocesing / masívne paralelný procesing (SMP / MPP) skutočné paralelné
spracovanie jednej aplikácie na viacerých procesoroch súčasne rozdelením úlohy do vlákien;
u SMP sa používajú zhodné procesory pristupujúce k spoločnej operačnej pamäti, MPP môže
obsahovať rôzne procesory s vlastnou operačnou pamäťou a ta sú spolupracujúcimi počítači.
U DS má zmysel paralelne spracovávať predovšetkým dva oddelené typy procesov - dátovú
pumpu a
OLAP dotazy, alebo samostatné otázky rôznych užívateľov.

Seminarna Praca - HI-3, Datove Sklady

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Seminarna Praca - HI-3, Datove Sklady

Uploaded by

Copyright:

Available Formats

Ekonomická univerzita v Bratislave

Fakulta hospodárskej informatiky

Dátové sklady-ich história, štruktúra, význam

Predmet: Hospodárska informatika I

V porovnaní s databázou (transakčného systému) je dátový sklad v podstate výhradne

 Jednoduchá a rýchla dostupnosť informácie

1.3 Business Intelligence

1.3.1 Základné riešenia aplikácií Business Intelligence

1.4 Manažérsky informačný systém

[Sodomka,Klčová, Informační systémy v podnikové praxi, 410]

1.5 Niektoré ďalšie frekventovane pojmy

V oblasti elektronického obchodovania sa využíva takzvaný Web Mining, ktorý umožňuje

Technológia dolovania dát je často nesprávne zamieňaná s dátovými skladmi. V analytických

3. Ako funguje dátový sklad

3.1 Dátová pumpa (Transformation)

3.2 Funkcie dátového skladu

3.3 Konceptuálne modelovanie DW (Dátový sklad)

Základné princípy, na ktorých sú aplikácie BI založené, je niekoľkodimenzová tabuľka

Žiadosť pohľadu na dáta z viacerých hľadísk (dimenzií) súčasne prináša požiadavku na

4.1 Základné princípy OLAP systémov

 Pre MOLAP (Multidimensional OLAP) je charakteristické špeciálne uloženie dát

Multidimenzionálne databázy sú preto optimalizované pre uloženie a interaktívne

[Gála, Podniková informatika, 94]

Obr.3 schéma tabuliek dimenzií (Hviezdicová schéma)

• metadáta dátového skladu - katalóg DS obsahuje

• metadáta pre dátovú pumpu - mapovanie zdrojových dát z operatívnych databáz do

• metadáta pre dáta a funkcie na pozadí DW

• prístupové práva a zabezpečenie DW

5.1.2 Metadáta pre koncových užívateľov

5.1.4 Metadáta ako základ pre automatizáciu podporných procesov

5.2 Štandardizácia metadát

1. Budovanie dátového skladu

Začína sa najprv u dvoch výstupných zostáv (reportov) za oddelenie, následne sa pripojujú

6.1 Jednoúrovňová architektúra (BUS architektúra)

6.2 Správa dimenzií

Celofiremné dimenzie (CD – Conformed Dimensions) sú v dátovom sklade reprezentované

6.3 Dvojúrovňová architektúra

6.4 Porovnanie architektúr Dátových skladov

6.4.1 Jednoúrovňová BUS architektúra

7. Dátové trhy (Data Mart, DMA)

7.1 Dátový sklad ako množina dátových trhov

Dátové sklady a OLAP nástroje sú založené na multidimenzionálnom dátovom modely. Tento

9. Chyby pri budovaní Dátových skladov

9. Dolovanie dát (Data Mining)

9.1 Dolovanie z dát (Data mining), nástroje pre obchod a

[Peter Stuchlý, Informačné systémy v marketingu, 45]

9.1.1Charakteristické oblasti použitia pre Data mining

V podstate akýkoľvek proces je možné študovať, pochopiť a vylepšiť s použitím Data

9.1.2Definovanie cieľa pre Data mining

Prvým a najdôležitejším krokom v každom projekte modelovania je stanovenie jasného cieľa

[Peter Stuchlý, Informačné systémy v marketingu, 46]

 Chceme prilákať nových zákazníkov? Modelovanie odozvy v kampaniach na

[Peter Stuchlý, Informačné systémy v marketingu, 46-47]

9.1.3Metodika procesu Data mining

[Peter Stuchlý, Informačné systémy v marketingu, 47]

[Peter Stuchlý, Informačné systémy v marketingu, 47]

2) Exploration – prieskum, diagnostika a charakteristiky údajov. Zmyslom tohto kroku je

[Peter Stuchlý, Informačné systémy v marketingu, 47]

3) Modification – manipulácia a transformácia údajov. Príkladom je:

 odstránenie nedefinovaných hodnôt,

[Peter Stuchlý, Informačné systémy v marketingu, 47-48]

4) Modelling - konštrukcia abstraktných modelov. V podstate ide o hľadanie odpovede na

[Peter Stuchlý, Informačné systémy v marketingu, 48]