Jak ale data ze zdrojových systémů získáme? Máme si pro ně sáhnout přímo do jejich fyzického úložiště? Máme je raději načítat z oficiálního datového rozhraní, které poskytuje zdrojový systém? Nebo raději požadovat pravidelné předávání datových extraktů provozovatelem systému?

Přístup k datům na úrovni fyzické databáze vypadá na první pohled lákavě. Jistě, ve fyzické databázi přece najdeme všechna data, která se v provozním systému objevují, nicméně tvůrce této databáze ji zcela jistě nenavrhoval s úmyslem dalšího vytěžování. Naopak, vše si uzpůsobil tak, aby struktura dat co nejvíce vyhovovala způsobu zpracování na straně aplikace. Data proto mohou být rozdrobena do množství dílčích tabulek, nesouvisející data jsou naopak slučována do univerzálních struktur, jiná data jsou uložena v XML struktuře atd. Právě tato nečitelnost a složitost primárních dat je důvodem pro tvorbu odvozených a jednoduchých datových struktur na straně datového skladu. Pro tvůrce datového skladu to však přináší povinnost těmto primárním strukturám porozumět. Jakákoliv dokumentace je v takovém případě klíčová, a to nejen dokumentace fyzických struktur dat, ale i jejich vztahu k logickým entitám používaným pro sledování předmětných procesů na straně aplikace. Bez dokumentace bude práce s takovými daty jen cestou pokusů a omylů.

 V souvislosti s fyzickou strukturou zdrojových dat a její dokumentací nelze pominout různá omezení smluvního či legislativního charakteru. Dodavatel aplikace si může smluvně podmiňovat využití fyzických dat, či dokonce poskytnutí dokumentace třetím stranám s jeho souhlasem. A dále, ve fyzické databázi se mohou vyskytovat data, která používají z organizačního či legislativního hlediska vyšší stupeň ochrany. Pokud se nepočítá s jejich zpracováním na straně datového skladu, neměla by data být přístupná ani v rámci načítání.

Dodavatel primárního systému se využití jeho fyzických datových struktur brání v mnoha případech oprávněně. Základním argumentem většinou bývá další rozvoj a opravy aplikace, se kterými souvisí nepředvídatelnost budoucích změn a jejich závažnosti na straně fyzických dat. Ano, z pohledu řízení datového skladu se jedná o značnou neurčitost v chování okolních prvků, ovšem z praktického hlediska lze závažnost problému odhadnout. V provozu usazené aplikace budou pravděpodobně produkovat méně závažných změn než aplikace nově nasazované či evidentně provozované v často se měnícím prostředí. Naprosto důležitá je zde včasná informovanost o chystaných změnách a účinná analýza jejich dopadu na další řešení datového skladu.

Závažnost výše uvedených problémů může být důvodem k jinému přístupu, a to prostřednictvím dohodnutého rozhraní. Toto rozhraní může vytvořit dodavatel primárního systému, a to například ve formě databázových pohledů či aplikačních služeb nabízejících požadovaná data. Tento dodavatel pak garantuje neměnnost daného rozhraní (či alespoň informovanost o nutných změnách). Vypadá to velmi jednoduše: celý proces získávání dat je dobře řiditelný, jsou zde jasně rozdělené zodpovědnosti atd. Ale! Může to obnášet další a často nezanedbatelné náklady na celé řešení, proces vyžaduje úzkou spolupráci s dalším subjektem, je obtížnější budoucí rozšiřování v případě nárůstu požadavků datového skladu na šíři a obsah načítaných dat, jedná se o další potenciálně chybovou komponentu ve zpracování dat.

Třetí zmiňovaný přístup ke zdrojovým datům, pravidelné předávání dat v dohodnuté struktuře provozovatelem primární aplikace, přináší obdobné nevýhody jako v předchozím případě. K tomu musíme přičíst ještě nepružnost, obtížné synchronizování s načítáním do datového skladu a často nízkou frekvenci aktualizace předávaných dat, tj. dat vstupujících do datového skladu. Na druhou stranu, je možné si vymínit strukturu, která datovému skladu vyhovuje, dobře se zpracovává, sama různá data konsoliduje, doplňuje apod. Přenáší se tím množství práce, původně určené právě pro načítání datového skladu, na provoz primárního systému. To je pro tvůrce datového skladu sice pohodlné, ale principiálně nesprávné.

Je evidentní, že ani jeden ze způsobů přístupu ke zdrojovým datům jednoznačně doporučit nelze. Se všemi bude spjato množství problémů, výše zmíněných či nezmíněných, na které dříve nebo později narazíme a budeme se s nimi muset vypořádat. Snad jediný společný jmenovatel, lék či prevence těžkostí se dá formulovat takto: bez podpory dodavatele primární aplikace datový sklad možná vybudujeme, ale data do něj budeme napouštět a připouštět jen velmi, velmi obtížně. Uváděné obtíže lze, při dobré vůli všech zúčastněných, řešit. Rozhodně nepřipusťme, aby byly vnímány jako zásadní překážka pro realizaci datových skladů a business intelligence.

Autor působí jako team leader
oddělení BI a integrace ve společnosti Aquasoft.