Veselé Vánoce a šťastný nový rok přeje BI/DW Blog

Hromadné změny v BI Answers reportech

Při praxi vývoje BI nadstaveb pro různé zákaznické systémy se stále častěji setkávám s požadavkem vytvořit napřed relativně malé řešení s pokud možno okamžitým výsledkem a teprve potom toto řešení dále rozvíjet.

Relativně malé řešení však může obsahovat cca i 20, 30 sestav, které nemusejí vznikat vždy v kontextu celkového plánovaného řešení. Přitom základní koncepce, struktura a pojmenování katalogu, jeho větví, struktura cílových oblastí pro BI dotazy (z Answers) jsou důležité atributy pro další rozvoj takového řešení.

Totiž: Sestavy vytvořené v BI Answers, mají v sobě zapsány názvy katalogu a jeho větví a současně i názvy cílových oblastí, ze kterých se provádějí dotazy. Tyto názvy se vyskytují u každé položky dotazu v sestavě.

Co se stane, pokud se přejmenuje, přestrukturuje katalog, názvy jeho větví, který už obsahuje množství sestav?

1. Na dashboardech nebude zobrazena žádná sestava. Pokud vyberete možnost „Upravit panel“, všechny sestavy na něm umístěné uvidíte se žlutým vykřičníkem. A pokud vyberete možnost „Upravit dotaz“, obrazovka se sice přepne do BI Answers, ale neotevře se vám daná sestava, jak bývá zvykem. V BI Answers je pak vidět upravený název větve katalogu se všemi sestavami. O této nové větvi však panely nic neví, proto sestavy nezobrazí. Co zbývá? Projít všechny panely a sestavy na nich a „zahnízdit“ tam znovu všechny sestavy, ale již z nově pojmenovaného, nebo přestrukturovaného katalogu.
   
   
2. Sestavy, které se nově zahnízdí na panelech a obsahují volání (navigaci) na jinou sestavu, nefungují, tedy nefunguje toto volání. Proč? Navigace obsahuje původní název dané větve katalogu. To znamená, každou takovou sestavu otevřít a nově připojit volanou sestavu.

Tuto cestu jsem již absolvoval a je poměrně časově náročná. Je možné tímto způsobem strávit i několik neproduktivních hodin. Existuje i jiné řešení? Ano, hromadná změna přímo ve větvi katalogu, jehož se změna týká.

Napřed umístění sestav na panelech:
Pro takové akce je dobré napřed stopnout službu „Oracle BI Presentation Server“. Poté v souborovém systému, kde je katalog fyzicky umístěn, najít příslušnou větev …/_portal. Na ní jsou soubory (bez koncovky), které představují jednotlivé panely. Pokud daný soubor s názvem příslušného panelu otevřete v textovém editoru, vyskytují se tam původní cesty k sestavám (včetně výzev panelů). Zde je možné pak přejmenovat původní cestu na novou cestu. Po nastartování „Oracle BI Presentation Server“ se již všechny sestavy zobrazí správně. Avšak volání sestav ze sestavy stále nefunguje. K tomu je třeba provést obdobný krok.

Poté navigace v sestavách:
V adresáři katalogu, ve kterém jsou příslušné sestavy znovu soubory bez koncovek), je třeba v daných sestavách najít původní volání sestavy a opravit cestu na nový adresář. Např.


Po takových úpravách jsou znovu funkční jak panely, tak volání sestav. Pro ještě větší urychlení je možné libovolným freewarem nechat prohledat celý adresář a nechat nahradit původní název, novým. To je pak cesta s odezvou několika málo minut.

Co se ale stane, pokud v nástroji “BI Administration Tool” změníte název prezentačního katalogu? Zdánlivě nic. Panely stále zobrazují sestavy a data. Pokud však budete chtít editovat sestavu a budete na ní navigovat přímo z panelu “Upravit dotaz”, přepne vás to sice do Answers, ale v levé části vidíte pouze nápis:”Buď nemáte oprávnění k použití cílové oblasti XXX v rámci aplikace BI Answers, nebo cílová oblast neexistuje.“ Jak z toho ven?

Obdobným způsobem – viz výše. Je nutné v každé sestavě změnit název prezentačního katalogu. V příslušných souborech se musí znovu změnit tag:

kde XXX je název nového prezentačního katalogu. Tento název je součástí dotazů v každé sestavě, takže je nutné v sestavách provést všechny změny, které by kopírovaly změny jak v samotném katalogu (adresářovém), tag v prezentačním katalogu (změna v nástroji BI Administration Tool).

Ještě jedno upozornění: Předem doporučuji celý katalog zazálohovat.

A na závěr – nezapomeňte, že uvedené změny se mohou týkat i uložených filtrů.

Věřím, že někomu moje zkušenost pomůže urychlit mnohdy časově náročné neproduktivní práce, které můžou vzniknout bohužel I rychlou, nekoncepční práci, kterou však zákazník mnohdy vyžaduje.

Petr Jurászek (konzultant společnosti IT Systems)

Metadata a navsteva u zubara

Kazdy z nas vie, ze je treba chodit na pravidelne prehliadky k zubarovi, ale nie uplne vsetci to aj robime. Problem, ktory moze a v konecnom dosledku nemusi vzniknut za rok-dva nas malokedy trapi dnes - vzdy mame nieco urgentnejsie na programe.

To iste podla vyskumov Gavilan Research Associates plati aj o metadatach. Primarna uloha BI/DW projektov (tak isto ako lubovolneho ineho projektu ;) je “dodat” v definovanom case a rozpocte. V takom momente si casto povieme - naco mam robit logicky model, ked mozem nakreslit rovno fyzicky, preco sa tu mam rozpisovat v popisu tabulky, ked aj tak vsetci vedia, ze su tam zostatky na uctoch alebo naco mam pracne vyklikavat transformacie, ked SQL dotazom to urobim na dve doby!!!

Vsetkym tymto situacia a rozhodnutiam rozumiem, ale po par rokoch pouzivania riesenia sa zacnu ukazovat “kazy”. Konkretne sa objavuju v momente ked sa menia ludia, legislativa alebo systemy. V tom momente sa cas a energia usetrena na pociatku obrovskym sposobom negativne zuroci a napr. zmena sposobena patchom zdrojoveho systemu moze trvat mesiace kym sa vyhodnotenia mozne dopady na zavisle systemy, lebo je potrebne prechadzat SQL dotazy, ktorym nikto nerozumie nad tabulami, ktore netusime co znamenaju.

Problemy suviace s metadatami podla cetnosti vyskytu

Systemy alebo aplikacie najviac postihnute problemami s metadatami

Urcite nebudem nikoho presvedcat, ze ma od zajtra vsetko robit cisto a dokumentovat kazdu entitu, na ktoru narazi. Co moze uplne bohate stacit je naucit sa plnohodnotne pouzivat modelovacie nastroje. Vacsina z nich umoznuje automaticke generovanie dokumentacie, ale malokto si da tu pracu. A co je asi najcastejsi moment - nestiha sa jadro projektu a tak na jeho dopracovanie sa pouzije nielen kalkulovana rezerva, ale aj cas kedy sa malo dokumentovat a testovat t.j. myslite na metadata pri tvorbe projektoveho planu nech mozete za sebou nechat dielo, ktore moze zit dlhy a zdravy zivot.


BTW kedy ste boli naposledy u zubara? (^_^)

Peter Hora (Semanta)

Oracle BI Apps 7.9.5.2 s ODI – mazání DWH po oblastech

Oracle BI Applications ve verzi 7.9.5.2. (verze používající Oracle Data Integrator) nabízí 4 moduly:

• Financials
• Human Resources
• Procurement and Spent
• Order Management

Při konfiguraci a ladění více modulů jistě narazíte na problém, kdy je třeba u jednoho z modulů provést opakovaný initial load zatímco druhý modul již je naplněn a nakonfigurován, třeba i uživateli testován.

O tom, zda se provádí initial load nebo inkrementální load si ETL rozhoduje samo na základě logovacích tabulek, kde každý proces zapisuje údaje o svých bězích. Proto, pokud potřebujeme opakovaně provést initial load, je zapotřebí promázání patřičných cílových tabulek a také reset logovacích tabulek.

K tomu nám slouží v ODI package připravené na ruční/jednorázové spuštění. K dispozici máme:

• Reset All DataWarehouse – package spouštěná bez parametrů vymaže všechny datové i logovací tabulky napříč celým řešením.
  
  
• Reset Subject Area – package je spouštěna se dvěma parametry (proměnnými), které specifikují modul (HR, OM, SCA, FIN) a příslušnou subject area. Požadované hodnoty parametrů zjistíme z tabulky C_MODULE_PACKAGE – sloupce OBI_MODULE a OBI_SUBJECT_AREA. Pro promazání jednoho modulu je tak třeba pustit package víckrát pro všechny OBI_SUBJECT_AREA.

Příklad zjištění parametrů pro modul HR:

SELECT DISTINCT OBI_MODULE, OBI_SUBJECT_AREA
FROM DATA_BIAPPS.C_PACKAGE_MODULE
WHERE OBI_MODULE = 'HR'

Jakub Genža (consultant Capgemini Sophia)

Vícenásobné řazení sloupců v tabulce na Dashboardu

Asi většina z vás umí nastavit interaktivní řazení sloupců v tabulce publikované do Dashboardu.


Po zapnutí volby „Povolit řazení sloupců v panelech“ a vypublikování reportu na Dashboard mohou začít uživatelé interaktivně řadit data v tabulce – stačí kliknout myší na záhlaví sloupce.


Ale co když uživatelé budou potřebovat řadit data podle více sloupců? Do teď jsem všem tvrdil, že to bohužel nejde (a nebyl jsem sám). Kliknutím na jiný sloupec v tabulce se eliminuje předchozí nastavení a data se seřadí pouze podle nového sloupce.


Chtěl-li si uživatel řadit data podle více sloupců, musel si proto report otevřít v BI Answers.


Včera, po třech letech prodeje a konzultace k Oracle BI (exSiebel BI), jsem čirou náhodou objevil, že i přímo na Dashboadu lze interaktivně řadit data podle více sloupců.

Možná je to uvedeno někde v dokumentaci nebo popsáno na jiném blogu, ale nikdy jsem si toho nevšiml a ani kolegové z branže to neznali.

Jak jsem na to přišel? Udělal jsem report, nastavil jsem mu řazení podle třech sloupců a vypublikoval na Dashboard – a tam jsem si všiml, že v záhlaví tabulky je uvedeno řazení u každého sloupce.


Napadlo mne, když to lze zobrazit, tak to musí jít i nastavit. A jak např. ve Windows Exploreru vyberete více hodnot najednou, případně konkrétní hodnoty?



Jasně, je to pomocí kláves Shift a Ctrl.

Proto, chcete-li řadit data na Dashboardu podle více sloupců, držte klávesu Ctrl, klikněte myší na sloupec a poté Ctrl pusťte. Toť vše :)



Erik Eckhardt.

Oracle University připravuje školení IMPLEMENT AND ADMINISTER DATA WAREHOUSE

Od 18.1.2010 pořádá Oracle University čtyř denní školení Oracle DB: IMPLEMENT AND ADMINISTER DATA WAREHOUSE.
Školení je určeno pro databázové a systémové administrátory a vývojáře BI aplikací, kteří navrhují a spravují datové sklady (přesnou agendu školení najdete zde).

Máte-li o školení zájem, pak přímo kontaktuje Oracle University na education_cz@oracle.com.



eec.

Úprava RKM pro automatické nastavení typu SCD sloupce dimenze

Na projektu používáme ODI pro implementaci ELT procesů plnících datový sklad. Datový model udržujeme ve UML case nástroji (Enterprise Architect).

Před zahájením implementace transformací zajišťujících plnění datového skladu je nutno do ODI načíst metadata popisující tabulky, které slouží jako zdroj nebo cíl transformace. K tomu slouží v ODI reverse engineering knowledge moduly (RKM), které jsou dodávány pro různé databázové platformy.

Pro implementaci transformací (v ODI se nazývá interface) zajišťujících plnění dimenzí druhého typu (SCD2) datového skladu je nezbytné v rámci metadat korektně nastavit SCD chování sloupce cílové tabulky (podrobnosti viz. tento článek). Tuto operaci je obvykle nutné provést manuálně po importu metadat cílového schématu. V rámci ODI není tato operace vyřešena úplně ergonomicky – pro každý sloupec je nutné spustit editor sloupce, poté vybrat záložku „Description“ a zde zvolit požadovaný typ historie, což je relativně časově náročné. Pokud se na tento krok zapomene nebo v něm vývojář udělá chybu, jsou transformace plnící danou dimenzi nefunkční nebo se chovají neočekávaně.

Manuální nastavení typu historie sloupce

Vzhledem k tomu, že typ historie sloupce dimenze evidujeme již v datovém modelu, rozhodli jsme se upravit dodávaný RKM tak, aby došlo k automatickému nastavení typu historie sloupců dimenze v ODI.

Nejprve je nutno zpropagovat informaci o typu historie sloupce z modelu v case nástroji do metadat databáze. Rozhodli jsme se na začátek komentáře sloupce vkládám 4 místný kód určující typ historie daného sloupce – např. [SK] pro umělý klíč, [NK] pro přirozený klíč, což jsme provedli jednoduchou úpravou šablony pro vygenerování zakládacího skriptu dimenze. Před vygenerováním kódu z case nástroje je provedena validace modelu, která mimo jiné kontroluje nastavení typu historie pro sloupce dimenze. V databázi tak komentář všech sloupců dimenze začíná kódem typu historie, který využíváme následně při reverse engineeringu metadat do ODI. Alternativně je možno vytvořit vlastní „meta“ tabulku obsahující potřebná metadata, nebo využít jmenných konvencí.

Nyní již k samotné úpravě RKM. Nejprve jsem zduplikoval dodávaný „RKM Oracle v 10.1.3.4“. RKM fungují tak, že nejprve naplní pomocné tabulky s prefixem SNP_REV a na základě těchto tabulek se nastaví metadata v ODI. Vzhledem k tomu, že pomocná tabulka SNP_REV_COL již obsahuje potřebný sloupec SCD_COL_TYPE, stačilo pouze upravit krok 41 „Get columns“.

V založce „Command on target“ jsem přidal plnění sloupce SCD_COL_TYPE:

insert into SNP_REV_COL
(
I_MOD,
TABLE_NAME,
COL_NAME,
DT_DRIVER,
COL_HEADING,
COL_DESC,
POS,
LONGC,
SCALEC,
COL_MANDATORY,
CHECK_STAT,
CHECK_FLOW,
SCD_COL_TYPE
)

values
(
<%=odiRef.getModel("ID")%>,
:TABLE_NAME,
:COL_NAME,
:DT_DRIVER,
:COL_HEADING,
:COL_DESC,
:POS,
:LONGC,
:SCALEC,
:COL_MANDATORY,
'1',
'1',
:SCD_COL_TYPE
)

V záložce „Command on source“ jsme přidali určení typu historie sloupce na základe prefixu komentáře:

...
from ALL_TAB_COLUMNS c,
ALL_COL_COMMENTS cc,
ALL_OBJECTS o
...

case
when substr(cc.comments,1,4)='[SK]' then 'SK' --Surrogate key
when substr(cc.comments,1,4)='[NK]' then 'NK' --Natural key
when substr(cc.comments,1,4)='[OC]' then 'OC' --Overwrite on change
when substr(cc.comments,1,4)='[IR]' then 'IR' --Insert row on change
when substr(cc.comments,1,4)='[CR]' then 'CR' --Current record flag
when substr(cc.comments,1,4)='[ST]' then 'ST' --Starting timestamp
when substr(cc.comments,1,4)='[ET]' then 'ET' --Ending timestamp
else null
end scd_col_type
...

Tím je úprava RKM hotova. Vše ostatní zařídí krok 111 „Set metadata“. Díky této drobné úpravě nemusíme manuálně editovat metadata cílového schématu datového skladu, což zvyšuje efektivitu vývojého procesu a eliminuje riziko vzniku zbytečných chyb.

Karel Hubl (GEM System International)