Denodo Platform od DATERy je vždy něco navíc

Obecně není mnohdy složité aplikovat platformu či komponenty jako řešení určitého technického požadavku ze strany zákazníka, mnohdy víc problematické je splnit onu uživatelsko-aplikační úroveň. Tzn. aby uživatelé s nástrojem pracovali nikoliv protože musí (pokyn od vedení v duchu „stálo to bambiliony, tak se s tím pracovat musí a tečka“), ale aby vnímali přidanou hodnotu pro jejich práci ruku v ruce s usnadněním běžných/rutinních/opakujících se činností. V tomto duchu jsme přistoupili k realizaci řešení na jednom projektu, neboť ze schůzek se zákazníkem byla navnímána různá úroveň znalosti a zkušeností uživatelů při práci s databázemi, databázovými nástroji a obecně BI. Právně pro ně jsme připravili několik „pomocných“ view, které jim usnadňují realizaci datových modelů v Denodo Design Studio (jedna z komponent Denodo Platform).

Z úvodního blogu již víme, k čemu Denodo Platform slouží, a tak není nic složitého připojit několik datových zdrojů (JDBC, ODBC, .xlxs apod.) a začít s nimi pracovat jako Data Lake. Po připojení zdroje vám admin zpřístupní pro váš účet či roli (tomuto tématu bude věnován samostatný blog) v terminologie Denodo tzv. base či derived view (opět detailnímu technickým rozdílům mezi různými typy view se budeme zabývat v některém z dalších blogů) a tím pro něj práce v podstatě končí. Jak ale uživatelům usnadnit práci v novém nástroji v kontextů požadavků zákazníka, kdy mělo dojít k přejmenování tříd a atributů pro derived view nebo provázat různé datové zdroje, aby došlo k obohacení původních reportů?

První (výše uvedený) požadavkem zákazníka bylo v podstatě provést překlad, kdy na úrovní base view budou třídy a atributy zachovány v technické terminologii (např. kod), ale právě pro potřeby BI dojde k jejich přejmenování (překladu) na řekněme uživatelsky více stravitelnou formu (např. projekt). A to se týkalo nejen atributů, ale i jednotlivých tříd. Pokud uživatelé z BI platformy mají přístup jak k derived, tak base view, z logiky věci narazí na otázku, který atribut odpovídá jakému v rámci obou view. Dalším příkladem může být stav, kdy připojíte další zdroj, v něm máte tabulku a na ní atribut kod. Ale uživatelé pracují s derived view, kde je již atribut projekt a to názvoslovně proti sobě neštimuje. Potřebujete tedy zjistit původní název, abyste mohli alespoň v teoretické rovině říct, že join mezi tabulkami z různých zdrojů, který uděláte na těchto sloupcích, dle názvů dává smysl a vrátí vám nějaký smysluplný výstup. Samozřejmě, že i přes shodu názvu, obsahově atributy primární a cizí klíč nemusí tvořit a tudíž je potřeba hledat dále.

Další problematiku mohou představovat právě primární a cizí klíče. Pokud není dobře zpracovaný samotný zdroj, při importu tabulek se nepodaří načíst vazby mezi nimi. Máte sice hromadu tabulek „na jednom místě“ v Denodo Platform (konkrétně ve Virtual DataPort), ale vazby primárního a cizího klíče napříč tabulkami nejsou známi. Toto pocítí zejména uživatelé z BI, kteří mají za úkol vytvářet datové modely. Ty jsou v drtivé většině realizovány spojením více tabulek, tedy správnou kombinací dvou atributů (onen primární a cizí klíč). Násobně tato problematika vypluje na povrch, pokud chcete spojit tabulky napříč datovými zdroji. Jak má uživatel vědět, které ID se váže na které do jiného datového zdroje? 

Pomiňme fakt, že k nalezení správných sloupců pro vazbu mezi tabulkami z různých datových zdrojů (samozřejmě, pokud vůbec takovou možnost lze najít) většinou potřebujete metodika, který dá palec na správnost výběru atributů …  je možné vyřešit problematiku chybějících vazeb mezi tabulky v Denodo Platform jednoduše, a to pomocí tzv. asociací. Je volbou uživatele, jestli přistoupí k realizaci asociací formou drag and drop či implementací skriptu ve VQL Shell konzoli. Vždy je ale dobré k tomuto přistoupit po připojení datového zdroje, protože vytvoření asociací, přestože na začátku tato aktivita zabere nějaká čas, se vrátí v jednoduchosti realizace datového modelu z více tabulek ostatními uživateli.

Dosti bylo teorie a pojďme si ukázat praktické řešení obou problematik. Pro řešením prvního úkolu jsme přistoupili k realizaci pomocného view, které v podstatě představuje překladač z base do derived view a obráceně. Společné i pro řešení druhého úkolu je obecně použití, které není podmíněno znalostmi SQL. Uživatel otevře předpřipravené view translator a vyplní textové pole hledaným view či konkrétním atributem. Po stisku tlačítka Execution panel je vrácen řádek obsahující název base/deried view a hledaného atributu na obou view.

Stejného výstupu zkušenější uživatel (nebo ten, kdo rád píše SQL syntaxe) docílí vepsáním opět názvu base/derived a atributů prostřednictvím skriptu ve VQL Shell konzoli. Jelikož se jedná standardní zápis do SQL skriptu, stačí vše potřebné dopsat do WHERE klauzule. Výstup je pak naprosto identický (logicky) jako metodou drag and drop.

Když už se uživatel dokáže vyznat v názvosloví atributů (jejich překladu), logicky řeší posléze propojení datových zdrojů a tříd. Realizace asociací mu pomůže při vytváření datových modelů formou drag and drop. Pokud uživatel klikne v levém stromovém menu na view projekt_blog a vybere možnost join, automaticky se mu ukáží všechna další view (zde konkrétně kraje), do kterých vede asociace. 

Poté stačí jen uchopit vybrané view a přenést ho „pracovní plochu“. Uživateli se automaticky zobrazí (doplní) vazba mezi těmito view (spojnice obou view vyjádřená čárou). Nástroj přináší uživatelský komfort bez zbytečného hledání, zda vůbec nějaká vazba mezi těmito view existuje … vrací se nám tak investovaná práce do realizace asociací. Je samozřejmě na každém uživateli, jestli bude dále pracovat s touto asociací, jestli jí doplní o nějakou podmínku nebo je jí smaže a vytvoří vazbu novou.

Avšak jak usnadnit práci uživatelům, kteří píší SQL skripty a vazbu nechtějí hledat přes join a grafickým zobrazením asociace s identifikací klíčů. I zde jsme vystavěli pomocné view, které vychází z již realizovaných asociací. Uživateli pak stačí do WHERE klauzule napsat oba názvy view, načež je mu vráceno id z každého view, které slouží jako primární a cizí klíč.