Informační systémy provozované v dnešních firmách mají společné především to, že slouží k automatizaci provozních činností a obchodních procesů. Z těchto důvodů se také označují jako provozní systémy či jako transakční systémy (což reflektuje, že jejich podstatou je zpracování transakcí OLTP - OnLine Transaction Processing). Příkladem takového systému je například SAP R/3. Tyto systémy plní velice dobře to, k čemu byly navrženy, vytvořeny a implementovány - umožňují evidovat zákazníky, vystavovat objednávky, rezervovat místenky či zboží ve skladě, plánovat výrobu, kontrolovat plnění zakázek, evidovat transakce na účtu zákazníka, vystavovat faktury, párovat došlé platby od zákazníků a převádět data do účetnictví.

Používáním těchto systémů vzniká velké množství dat, které mohou být zdrojem velmi cenných informací. Problémy ale nastávají pokud se pomocí stejných systémů mají vzniklá data následně zpracovat tak, aby je bylo možné použít pro rozhodování či analýzy - porovnat prodeje jednotlivých výrobků v různých regionech za posledních 12 měsíců, předpovědět počet zakázek na příští dva měsíce, posoudit trend v příjmech s eliminací sezónních výkyvů, seskupit zákazníky do segmentů se společnou charakteristikou, zjistit jací zákazníci mají tendenci přejít ke konkurenci atp. Provozní systémy nedokáží tyto úlohy řešit z několika zásadních důvodů:

• Nedostatečná historie dat. Provozní systémy udržují z kapacitních důvodů data stará pouze několik měsíců, starší data se přehrávají do archívu, kde mají velice omezenou využitelnost.


• Nedostatečné techniky a nástroje pro zpracování dat. Provozní systémy většinou disponují sadou připravených reportů, které jsou navíc orientovány spíše na sledování procesů a jednotlivých transakcí než na globální pohled.


• Nemožnost zpracovat data z jiných aplikací. V žádné společnosti není používán pouze jeden systém byť existují velmi mohutná řešení jako je např. SAP R/3. Řada dat navíc vzniká mimo provozní systémy třeba i jako původně pouze osobní aplikace. Důležitá data rovněž pocházejí z externích zdrojů - ať se jedná např. o údaje z finančních trhů anebo data o průzkumu trhu.


• Nepříznivý dopad na výkonnost provozních systémů. Zpracování dat v provozním systémech k souhrnným přehledům a analýzám představuje další zátěž a vede k prodlužování doby odezvy transakčních systémů pro běžné uživatele.

Výše uvedené důvody vedou k zásadnímu konceptu datových skladů:

• Požadavky na provozní systémy a na zpracování dat pro rozhodování (tyto systémy se v zahraničí označují jako Information Delivery - dodání informací) jsou natolik rozdílné, že vyžadují dva druhy systémů - provozní systémy a datový sklad.


• Datový sklad je fyzicky a logicky oddělen od provozních systémů a představuje další krok v budování informačních systémů.


• Data z provozních systémů se převádějí do datového skladu, kde se po transformaci ukládají způsobem, který vyhovuje analytickému a prezentačnímu zpracování výstupů.

Podstata datového skladu

Datový sklad představuje uložení dat které má následující charakteristiky:

• Integruje data z různých zdrojů do jednoho systému


• Obsahuje historii - jsou k dispozici data i za několik minulých let


• Data jsou uložená na různých úrovních sumarizace


• Data se periodicky načítají z provozních systémů (většinou v noci a o víkendech)


• Uživatelé data pouze čtou, tj. neprovádí jejich zadávání ani je nemění


• Data uspořádána podle jednotlivých subjektů


• Data z datového skladu se využívají pomocí širokého spektra metod pro prezentace a analýzy dat

Rozdíly mezi provozními systémy a datovým skladem

Skutečnost, že datové sklady jsou systémy, které jsou zásadně odlišné od provozních (transakčních) systémů vyplývá z následující srovnávací tabulky).

Hlavní účel

Provozní systémy Datový sklad

• Automatizace operací nebo procesů


• Poskytování optimálních informací pro rozhodování

Koncepční rozdíly

Provozní systémy Datový sklad

• Dostat data do systému


• Uživatelé mají možnost zadávat data, měnit data, rušit data a číst data


• Zajišťují automatizaci rutinních činností


• Aplikace jsou v podstatě statické (požadavky na funkčnost aplikace jsou poměrně stálé)


• Podporují každodenní firemní aktivity


• Orientované na výkonnost


• Proces implementace a využívání je poháněn technologií (tj. impulsem k inovaci systému je nové systémové prostředí, nová verze databáze atp.)


• Dostat informace ze systému


• Uživatelé mají možnost pouze číst data


• Umožňují kreativitu uživatelů při práci s daty (analýzy, prezentace)


• Aplikace jsou dynamické (požadavky na funkčnost aplikací se mění)


• Podporují dlouhodobé strategie firmy


• Poskytují konkurenční výhodu


• Proces implementace a využívání je poháněn potřebami organizace (tj. impulsem k inovaci systému jsou nové potřeby uživatelů)

Technologické rozdíly

Provozní systémy Datový sklad

• Zpracovávají velké objemy malých transakcí


• Transakce neustále přidávají a aktualizují data


• Důležitým hlediskem je omezení redundance dat


• Integrita dat se zajišťuje datovým modelem a aplikacemi


• Datové modely jsou optimalizované pro online aktualizace a rychlé zpracování transakcí


• Používají se převážně normalizované relační datové modely


• Zpracovávají malý počet komplexních dotazů


• Data se načítají dávkově


• Důležitým hlediskem je rychlý přístup datům pro účely analýz a prezentací


• Integrita dat se zajišťuje při dávkových načítacích procesech (transformace dat)


• Datové modely jsou optimalizované pro rychlé zpracování výstupů


• Používá se kombinace datových modelů (normalizované a denormalizované relační modely, sumarizované tabulky, star schema datové modely, snow flake datové modely, multidimenzionální datové modely)

Načítání dat do datového skladu

Do datového skladu se data nezadávají, ale načítají se z provozních systémů. Načítání se většinou provádí v čase, kdy nejsou provozní systémy příliš zatíženy, aby se neprodlužovala doby odezvy pro uživatele těchto systémů. Při plnění DW je nutné realizovat tyto hlavní kroky:

• Extrakce vstupních dat


• Transformaci vstupních dat


• Načtení dat do DW

Extrakce vstupních dat

Nástroje DS musí umožňovat extrakci dat z provozních systémů, což ve většině případů znamená komunikovat určitým způsobem (ODBC, nativní drivery, textové soubory) s relační nebo síťovou databází či případně systémem souborů.

Transformace vstupních dat

Data v datovém skladu jsou uložena jiným způsobem než ve zdrojových systémech. Provozní systémy používají v naprosté většině normalizovaný entito-relační datový model. U datového skladu se naproti tomu používá kombinace několika datových modelů (schéma hvězda, schéma sněhová vločka, normalizovaný entito-relační model, denormalizovaný entito-relační model, multidimenzionální datový model). Transformace dat se skládá z těchto dílčích operací:

• Validace - ověření správnosti dat


• Čištění - odstranění či změna nesprávných dat


• Integrace - dosažení konzistence dat pocházejících z různých systémů (datové typy, formáty…)


• Derivace - vytvoření derivovaných dat na základě vstupních dat


• Denormalizace - snížení potřeby spojování tabulek při využívání DS


• Sumarizace- vytvoření požadovaných souhrnů z detailních dat

Prostředí DS musí poskytovat dostatek nástrojů a metod pro zvládnutí všech těchto kroků, vzhledem k povaze těchto procesů nepostačuje pouze SQL jazyk, ale je nutné používat specializované prostředky. Velmi důležitou fází je validace a čištění, protože základní podmínkou využitelnosti DS je to, že obsahuje důvěryhodná a správná data. Jakkoliv sofistikované metody na využití dat jsou v podstatě bezcenné, pokud nepracují se správnými daty.

Uložení dat

Data je možné ukládat na základě různých strategií:

• Pokaždé se uloží celý obsah DS znovu (použitelné pouze u velmi malých objemů dat či pro úvodní načtení)


• Ukládají se pouze přírůstky a změněná data (v tomto případě musí být k dispozici systém zajišťující rozpoznání změněných údajů).

Architektura datového skladu

Prosadily se dva základní koncepty datového skladu:

• Nezávislé datamarty (virtuální datový sklad)


• Integrovaný datový sklad

Nezávislé datamarty

Při této koncepci se pro řeší potřeby jednotlivých útvarů či aplikací víceméně odděleně a vytváří se samostatná datová úložiště tzv. datamarty, která se někdy označují jako útvarové datové sklady. Celková struktura je patrná z následujícího obrázku.

Výhody tohoto uspořádání jsou následující:

• Snažší a rychlejší implementace


• Rychlejší přínosy pro uživatele

Nevýhody:

• Může docházet k nekonzistencím mezi jednotlivými datamarty


• Komplikované načítací procesy (velký počet, náročné na údržbu) S rostoucí velikostí datového skladu převažují nevýhody nad výhodami a proto byl vytvořen druhý přístup.

Integrovaný datový sklad

Při této koncepci se data z provozních systémů ukládají do centrálního datového úložiště, ze kterého se následně odvozují datamarty pro potřeby jednotlivých útvarů či aplikací..

Výhody tohoto uspořádání jsou následující:

• Konzistentní obsah datového skladu


• Menší počet načítacích procesů z provozních systémů (primární načítací procesy)


• Jednodušší správa načítacích procesů


• Snažší vytváření nových datamartů (detailní data jsou již k dispozici v DS)

Nevýhody:

• Složitější realizace


• Pomalejší implementace (lze eliminovat vhodnou metodologií)


• Sekundární načítací procesy (z centrálního DS do datamartu)

Vzhledem k tomu, že požadavek na konzistentnost obsahu datového skladu je naprosto zásadní (DS musí poskytovat "jedinou verzi pravdy") tento přístup v současnosti převládá.

Komponenty architektury datového skladu

• Centrální datový sklad - Slouží jako společný zdroj vyčištěných a ověřených detailních dat (z provozních systémů i externích zdrojů). Následně jsou odvozovány datamarty pro jednotlivé útvary či aplikace. Data jsou uložena buď v relační databázi s možnými datovými modely Star Schema, Snow Flake Schema a entito-relační model, anebo (v případě potřeby zpracovávat obrovské objemy dat) v uložení pro paralelní zpracování dat s využitím bitmapového indexování.


• Útvarové a aplikační datamarty - Slouží pro zajištění rychlé doby odezvy a selektivního přístupu k historickým datům (data sumarizovaná na roční bázi jsou obvykle požadována za několik let zpětně, kdežto například týdenní sumarizace pouze za poslední rok). Představují vrstvu uložení dat, které je odvozená buď z centrálního datového skladu anebo z provozních dat. Obsahují buď sumarizovaná data, anebo vybraná detailní podle potřeb jednotlivých útvarů či aplikací. Formáty uložení dat je nutné z důvodů různých aplikací kombinovat (jiné uložení dat vyžaduje např. multidimenzionální analýza, jiné statistické analýzy a analýzy časových řad a zcela jiné dolování dat). Základní formáty jsou sumarizované relační uložení, multidimenzionální databáze (MDDB) a databáze pro dolování dat.Fyzicky mohou být datamarty uloženy na různých počítačích.


• Úložiště provozních dat (Operational Data Store) - V některých případech je před centrální datový sklad předřazeno úložiště operativních dat, které obsahuje transformovaná data za poslední období např. měsíc. Následně se data převádějí do centrálního datového skladu, kde je držena celá požadovaná historie.Tato komponenta není nezbytnou součástí DS a k její realizaci víceméně dochází pouze z důvodů použití určité technologie pro realizaci DS.


• Primární načítán - Procesy primárního načítání provádí plnění centrálního datového skladu daty z provozních systémů a z externích zdrojů. Tyto procesy musí umožňovat:


• Extrakce prakticky z libovolného formátu dat


• Transformaci dat (validace, čištění, integrace, derivace, denormalizace, sumarizace)


• Načtení do výstupního formátu


• Podporu pro správu a údržbu


• Sekundární načítání - Procesy sekundárního načítání slouží k plnění datamartů na základě nových anebo změněných dat v centrálním datovém skladu. Požadavky jsou obdobné jako u primárních procesů.


• Archív - Pokud to použitá technologie umožňuje, je požití archívu velmi užitečné, jelikož eliminuje velikost poměrně drahých diskových kapacit. Uživatelé ve většině případů totiž požadují okamžitý přístup k detailním datům pouze za krátké období (typicky rok), starší data je tedy uložit do archívu. Podmínkou použití je, že aplikační prostředí DS musí umožňovat transparentní použití archívu.


• Obchodní a technická metadata - Metadata jsou pomocná data o vlastních datech, která tvoří obsah datového skladu. Metadata lze rozdělit na dvě skupiny:


• Technická metadata (definují atributy, které popisují fyzické vlastnosti položek - odkud pocházejí, jak byly transformovány, kdo je za to zodpovědný, kdy byly naposledy načteny atp.)


• Obchodní metadata (jsou důležitá pro uživatele DW, obsahují informace jako jsou definice dat, hodnoty atributů a domén, obchodní pravidla, vztahy mezi daty atp.) Ukládání a využívání metadat umožňuje automatické načítání dat a údržbu DS.


• Nástroje na využívání DW - Nástroje, které lze používat bez nutnosti vytvářet aplikace, tvoří jeden z hlavních způsobu, jak uživatelé využívají DS. Sada nástrojů musí být co nejširší, aby mohli uživatelé získat co nejvíce přínosů z DS - zdroje integrovaných, ověřených a aktuálních dat z celé organizace a externích zdrojů.


• Aplikace - Pro splnění požadavku uživatelů na snadnost používání musí být součástí řešení DW prostředí, které umožní vytvářet aplikace pro jednotlivé skupiny uživatelů (manažerské informační systémy, aplikace umožňující multidimenzionální analýzu, specializované aplikace jako např. aplikace pro Customer Relationship Management, credit scoring pro hodnocení uchazečů o úvěr atp.). Pro plnou funkčnost je nutné, aby do aplikací byly integrovány i nástroje na využívání DS.

Využití datového skladu

Přínosy z realizace DS jsou tím, větší, čím větší jsou možnosti na analýzy a prezentace dat.

Nejdůležitější metody jsou následující:

• Operativní dotazy (tj., předem nepřipravené dotazy na určité hodnoty)


• Sestavy (jak standardní generované dávkově, tak operativní vytvářené podle potřeby)


• Multidimenzionální analýza (OLAP, tj. rychlé prohlížení dat sumarizovaných na různých úrovních z různých pohledů neboli dimenzí)


• Statistické analýzy (např. zjišťování závislosti veličin, identifikace důležitých proměnných, vytváření segmentů)


• Finanční analýzy (např. ekonometrické modelování, termínové modely)


• Analýzy časových řad a tvorbu předpovědí (např. předpovědi budoucích hodnot a identifikace sezónních výkyvů)


• Vizualizaci dat (prohlížení dat v dynamicky provázaných grafech pro např. identifikaci neobvyklých a extrémních hodnot a závislostí mezi daty)


• Dolování dat (data mining, specializované techniky pro zpracování velkých objemů dat a hledání skrytých vzorů a souvislostí)


• Geografické informační systémy (převádění hodnot proměnných na geografickou prezentaci - např. zabarvení okresů podle počtu zákazníků)


• Manažerské informační systémy - EIS (připravené aplikace pro vedoucí pracovníky se snadným ovládáním kombinující OLAP, reporting, přehledné zobrazení kritických veličin, jednoduché předpovědi)


• Aplikace vytvořené podle konkrétních potřeb.

Co je důležité při realizaci datového skladu

Při rozhodování jakým způsobem realizovat DS je vhodné zvažovat následující aspekty:

• Rozšiřitelnost a škálovatelnost řešení


• I když DS bude zpočátku nevelký rozsahem a objemem dat, je nutné mít na paměti jeho budoucí růst a jedy nutné mít možnost přecházet na výkonnější platformy (bez nutnosti přepracovávat aplikace)


• Dostupnost pro hardwarové a softwarové platformy.


• Podpora pro architekturu klient/server a pro webové technologie


• Nástroje pro extrakci dat (databázové systémy, systémy souborů a datové soubory)


• Nástroje pro transformace dat (validace, čištění, integrace, derivace, denormalizace, sumarizace)


• Způsoby uložení dat v centrálním datovém skladu a v datamartech


• Otevřenost na vstupu - z jakých datových zdrojů (formátů) lze data načítat


• Otevřenost na výstupu - jak lze přistupovat k datového skladu z externího prostředí


• Využití metadat


• Prostředky pro zajištění bezpečnosti dat


• Nástroj na správu datového skladu


• Nástroje na využití datového skladu


• Prostředí pro vytváření aplikací

Způsob implementace datového skladu

Z rozdílů mezi transakčními systémy a DS vyplývá nutnost rozdílného způsobu realizace.

U provozních systémů platí pro způsob realizace:

• Lze využívat standardizovaná řešení předem vytvořená na základě funkční analýzy řešené problematiky.


• Na základě analýzy funkčních požadavků je možné vytvořit:


• Celkový datový model ve fázi návrhu · Kompletní řešení ve formě standardizovaného produktu či systému.


• Vstup dat do systému je plně pod kontrolou produktu (tj. není nutné načítat dat z jiných systémů, rozhodně ne ve velkém rozsahu).


• Vytvořené řešení je možné následně implementovat u různých zákazníků převážně pomocí nastavování parametrů, naplnění číselníků a voleb u připravené aplikace.

U datových skladů platí oproti tomu pro způsob realizace:

• Datový sklad je pro každou organizaci individuální, což znamená, že nelze mít připravenou aplikaci datový sklad, kterou implementuje u různých zákazníků tím, že nastavujeme její parametry.


• To je dáno tím, že:


• Každá organizace má individuální kombinaci systémového prostředí (HW platformy, databázové systémy) a provozních systémů (které slouží jako zdroj dat pro DS).


• Každá organizace má individuální požadavky manažerů a analytiků na analýzy, prezentace dat a aplikace (např. jiný styl řízení znamená jiné kritické veličiny, které je potřeba sledovat a analyzovat)


• Požadavky uživatelů na zpracování se neustále mění, neboť chtějí zpracovávat a další data či kombinace dat, používat další metody atp. (typickým příkladem je marketingové oddělení, jehož náplní je neustálé hledání nových způsobů jak zpracovat data o zákaznících, produktech a službách a dozvědět se o nich něco nového)


• DS nelze chápat jako jednu velkou aplikaci, ale jako proces poskytování dat, nástrojů na jejich zpracování a měnících se aplikací.


• Realizace DS tady probíhá postupně, po jednotlivých etapách či projektech, kdy každá iterace zpřístupní určitou množinu dat, dodá sadu použitelných nástrojů a konkrétní aplikaci, kterou je nutné individuálně vytvořit.


• Přestože se postupuje po etapách, tak uživatelé dostávají rychle celou škálu možností jak, uspokojující jejich potřeby na práci s daty. To je dáno především tím, že:


• Nástroje pro práci s daty v DW jsou okamžitě použitelné a svou funkčností umožňují uživatelům provádět řadu věcí, pro které je nutné v transakčních systémech vytvářet aplikace


• Vývojové prostředí pro aplikace DW umožňuje velmi rychlou realizaci. Časově nenáročnější částí projektů DS je převedení dat z provozních systémů do DS (načtení, transformace, uložení), u většiny případů tato část vždy zabírá 70-80% realizace projektu..

Jakmile jsou data v DS, lze jednak používat nástroje a jednak velmi rychle vytvořit požadovanou aplikaci podle specifických potřeb organizace.

Datové sklady v českých podmínkách

Situace v České republice z pohledu datových skladů není příliš progresivní. Ve vyspělých zemích byl koncept datových skladů již běžně akceptován a ve většině firem datový sklad již existuje, či je alespoň plán na jeho realizaci. V české republice naproti tomu existuje málo společností, které se orientují v této problematice alespoň na tolik, že vědí co to datový sklad je a uvažují o jeho realizaci. Co se týká vlastní realizace, tak implementace datového skladu je výjimkou. Například v bankovním sektoru je známa pouze jedna banka, která má implementován datový sklad. V českých podmínkách se nejčastěji hovoří o manažerských informačních systémech (což je v podstatě pouze jeden ze způsobů využití datového skladu), které jsou chápány jako aplikace v Excelu či další modul provozních systémů. Případně je realizován EIS jako OLAP aplikace (tj. v podstatě datamart). Řada firem žije i nadále v přesvědčení, že provozní systémy vyřeší všechny jejich potřeby včetně dodání informací pro rozhodování. Ke změně jejich názoru možná přispěje i skutečnost, že přední dodavatel provozních systémů, firma SAP nyní začíná dodávat nejen systém R/3 ale i řešení pro datový sklad. Doufejme, že společnosti, které se zabývají datovými sklady, znásobí své úsilí natolik, že nám podaří v brzké době dohnat zpoždění, které má naše republika v této oblasti nejen vůči vyspělým zemím , ale i proti státům jako je Polsko či Maďarsko. Článek byl zpracován s využitím materiálů firmy SAS Institute, která patří mezi přední poskytovatele řešení pro Data warehousing, Business Intelligence, CRM a Information Delivery nejen na českém trhu, ale i v celosvětovém měřítku.