COMPUTERWORLD
pod kapotou
(Velko)sklady dat

V historii řady databázových technologií je zajímavé pozorovat, jak jsou často vynuceny změnou požadavků, v tomto případě na databázové systémy. Klíčové problémy, které se objevily u běžných transakčních databázových systémů, je možné shrnout následovně:

  • nedosažitelnost dat skrytých v transakčních systémech,
  • dlouhé prodlevy, když se nedostatečně silné systémy pokoušely provést komplikované dotazy,
  • složitá, uživatelsky nepříjemná rozhraní k databázovému software,
  • cena v administrativě a složitosti v podpoře vzdálených uživatelů,
  • soutěžení o počítačové zdroje mezi transakčními systémy a systémy podporujícími rozhodování.

DW se staly dlouhodobou cestou k řešení těchto problémů. Dostupnost a rozšiřitelnost pamětí kombinovaných s levnějšími paralelními procesory a novým analytickým softwarem dovolily vyvinout v r. 1996 tisíce DW. Vyšší články řízení obdržely přátelštější a silnější dotazovací a analytické prostředky.

Z pionýrů v technologii DW jmenujme firmu IBM, která publikovala jeden z prvních článků v časopise IBM Journal o této problematice již v r. 1988. Jsou však DW pouze zvláštním druhem databáze? K. Strange (Gartner Group) označuje jako DW architekturu, obvykle založenou na relačním SŘBD, která se používá pro údržbu historických dat získaných z databází operativních dat, která byla transformována, sjednocena a zkontrolována před jejich použitím v databázi DW.

Uvedená definice obsahuje klíčovou idea DW, sice sjednocení či integraci dat. Často nejde pouze o integraci dat z vlastních operativních databází, ale i o připojení dalších externích dat.

K. Shahin (CEO Kenan Systems Corporation) upozorňuje na analogii s průmyslem. Většina výrobních podniků bez ohledu na výsledný produkt rozlišuje tři stádia dodávky: výrobu, skladování/distribuce a prodej. V souvislosti s dodáváním dat uživateli můžeme v IS/IT rozlišit stejná stádia (obr. 1).

Výroba či produkce dat se objevuje v klasických transakčních systémech využívajících databáze, tj. systémech, které se často označují OLTP (On-line Transaction Processing Systems). Tyto systémy jsou optimalizovány pro údržbu velkého množství dat sloužících

 

 

 

 

 

Obr. 1 Tři stádia dodávání dat

hlavně pro operativní účely. Použití těchto dat je pro uživatele poměrně obtížné, zvláště chce-li nad nimi provádět analýzy. Výsledkem může být mnoho složitých dotazů např. v SQL, ruční kombinace jejich výsledků apod. Podobně jako výrobky, je žádoucí data pro odbyt “vytáhnout z výroby a přebalit”. A toto je právě záměrem skladování dat, tj. vzniku DW.

Z hlediska databázových dotazů se nad DW objevují dotazy nového typu. Jestliže nad operativními daty byly běžné dotazy selektivní, např. “Poskytni údaje o zákaznících z firem, které mají minimální roční obrat 100 mil. Kč”, pro DW jsou charakteristické dotazy intenzivní na data, jako např. “Kolik podvozků bylo dodáno do Východočeského kraje za poslední čtvrtletí v množství větším než 2000 a jak velký byl dosažen zisk v porovnání se stejným obdobím v minulém roce”.

S pokračující redukcí středních článků řízení, které poskytovaly rozbory dat ručně, by měl DW poskytnout podobné, nebo spíše mnohem kvalitnější služby, tj. umožnit získávat strategické či strategicko-taktické informace. Čím strategičtější je myšlení, tím větší je potřeba dotazů intenzivních na data. Informace, které nabízejí DW, nejsou získány z běžných operativních dat přímo. Někdy z nich ani nejsou dostupné, uvážíme-li např. potřebu použít historická data, která se již nenacházejí v operativní databázi. Záměrem DW je poskytnout ne operativní data, byť v zajímavých logických souvislostech, nýbrž tato data přeměněná ve strategické informace.

DW se používají pro prezentaci dat, testování hypotéz, objevování nových informací, tj. to, čemu se dnes říká dolování dat (data mining). Opět ale ne přímo, spíše prostřednictvím dalšího specializovaného software či složitějších architektur.

DW poskytují jistou novou hodnotu pro znalosti uživatele danou šíří pohledu (DW obvykle integrují data z více zdrojů), vyčištěním dat (zohlednění sémantických rozdílů, transformací jednotek apod.), hloubkou pohledu (možnosti různých úrovní agregace). Agregace vedou k tomu, že jsou data předkládána uživateli na rozdíl od relační technologie nenormalizovaná. Nenormalizovaná je i jejich implementace

Třetím krokem je “prodej dat”, kdy pohled na data by měl být orientován vysoce uživatelsky. Jde vlastně o to využít metody statistiky, modelování trendů apod. tak, aby se tyto techniky staly uživateli z hlediska jeho dotazů transparentní. Odpovídající systém je potom typu OLAP (On-Line Analytical Processing). Tyto systémy jsou optimalizovány pro rychlý výběr dat, sumarizace, analytické zpracování velkých objemů dat. Cílem je poskytnout hodnotné informace z velkých objemů dat.

V souvislosti s DW se také často hovoří o multidimenzionální databázi (MDD). Nejde o stádium dodávání dat, ale o typ databázové technologie. V předchozím pokračování Databázové abecedy jsme uváděli podrobněji, že data lze organizovat v multidimenzionálním datovém modelu, který je zcela odlišný od relačního modelu. Model trochu připomíná techniku spreadsheet, ovšem ve více než dvou rozměrech. Někdy se jako MDD označuje přímo i specializovaný software - multidimenzionální SŘBD (MDSŘBD), který implementuje data pomocí vícerozměrných polí, jejichž dimenze odpovídají dimenzím podnikání organizace. Zjednodušuje se pohled na data pro analýzy typu OLAP a při přímé implementaci vede MDD obecně k rychlejšímu zpracování než provozování OLAP nad relační databází (tzv. relační OLAP či ROLAP). Většina známých výrobců standardních SŘBD však ráda zdůrazňuje výhody přístupu ROLAP, protože tak vhodně využívají svůj pokročilý relační software (viz např. Univerzální server Informixu spolu s MetaCube OLAP). Mezi specializované databáze optimalizované pro multidimenzionální analýzu patří RedBrick Warehouse, mezi nástroje specializované aplikačně (analýza financí nebo trhu) patří IRI/Oracle Express či Arbor Essbase.

Pro úplnost uveďme ještě pojem datové tržiště (data mart). Tak je označována architektura, kdy DW (někdy zvaný atomický) slouží jako základna pro extrakci množin dat resp. jejich agregací (jde vlastně o formu replikace dat) do dílčích MDD. Tyto MDD jsou replikacemi, které nesou všechny výhody a nevýhody replikačním zpracováním nabízené.

Multidimenzionální databáze může pro DW sloužit ve dvou rolích:

  • může tvořit “front-end” pro DW a poskytovat uživateli služby pro realizaci analytického zpracování. Této variantě budeme říkat DW/OLAP.
  • může tvořit “front-end” jednomu nebo několika systémům OLTP jako alternativa za DW, tj. jako prostředek poskytnout data s OLTP uživatelům novým “analytickým” způsobem. Tuto variantu nazveme OLTP/OLAP. Jde vlastně o případ datového tržiště.

Oba přístupy ovšem mají své stinné stránky. V prvním případě mohou uživatelé čekat dlouho na realizaci kompletního projektu, protože dlouho trvá vybudování DW. Druhá varianta je zase založena na budování MDD přímo z operativních dat, tj. dívat se na ně jako na DW. Toto řešení ztrácí původní funkci, tj. jde o vytváření jakéhosi lokálního supermarketu, který je třeba přeměnit na sklad.

Jiné řešení, jak nevytvářet pro OLAP systém DW, je realizovat více dílčích OLAP systémů, např. zvlášť pro finance, jiný pro obchod apod. Použije-li se pravidlo 80-20, uvádí se, že dobrý OLAP systém by měl obsahovat pouze 20% dat z DW, které ale pokrývají 80% potřeb. Připomeňme, že MDD v uvedených souvislostech by ale měla být schopna realizovat také funkce náležející DW, tj. integraci dat, čištění dat, restrukturalizaci dat apod.

Je patrné, že DW a OLAP systémy jsou dvě rozdílně věci, přičemž většina uživatelů požaduje spíše OLAP než DW. MDD je vzhledem k svému databázovému modelu, který prezentuje uživateli, pro OLAP tím nejlepším řešením. Nevýhodou specializovaných MDD s funkcemi OLAP je ovšem jedinečnost, která je vlastní každému jednotlivému výrobci. Z toho plyne i obtížná integrace těchto nástrojů či databází, které zpracovávají.

Nezbytná je tedy standardizace nástrojů OLAP. Připomeňme tzv. OLAP Council založený v r. 1995 v USA firmami Arbor Software, Comshare, IRI Software a Pilot Software. Účelem této organizace je mimo jiné propagovat standardy MDD.

Z hlediska databází je zajímavé, jak se DW navrhují či jaké změny v databázovém stroji jsou nutné, aby DW pracoval efektivně. V prvním případě jde o nové metodologie návrhu dat, v druhém se využívá paralelismus, ale hlavně speciální typy indexů.



<seznam dílů seriálu>   <COMPUTERWORLD>