středa 23. prosince 2009
pondělí 21. prosince 2009
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?
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.
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?
- 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.
- 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:
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)
čtvrtek 17. prosince 2009
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
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? (^_^)
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)
pondělí 14. prosince 2009
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:
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:
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'
- Financials
- Human Resources
- Procurement and Spent
- Order Management
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)
čtvrtek 10. prosince 2009
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.
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.
pondělí 7. prosince 2009
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.
Š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.
čtvrtek 3. prosince 2009
Ú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.
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 sloupceVzhledem 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)
pondělí 30. listopadu 2009
Instalace Oracle BI EE na Windows 7 pro testovací účely
Při pokusu instalovat Oracle BI EE v prostředí Windows 7 skončíte na této chybě:
To je sice pravda, ale je možné nainstalovat. Instalace sice není certifikovaná, ale pro potřeby pokusů a demonstrací je plně funkční. Postup instalace je následující:
Další tipy
Vzhedem k tomu, že instalace neslouží k produkčnímu prostředí, ale k testování a demonstracím, je vhodné po startu počítače nespouštět zbytečně všechny služby, ale ponechat si možnost ručního spuštění. Je sice možné řešit startováním ( a zastavováním) jednotlivých sližeb, ale je šikovné si na to udělat startovací a zastavovací skripty (Pozor – oba se musí spouštět jako správce!):
Soubor BI_start.cmd
net start "Oracle BI Server"
net start "Oracle BI Java Host"
net start "Oracle BI Presentation Server"
C:\OracleBI\oc4j_bi\bin\oc4j.cmd -start
Soubor BI_stop.cmd
net stop "Oracle BI Java Host"
net stop "Oracle BI Presentation Server"
net stop "Oracle BI Server"
Připojení k databázi Oracle pomocí Oracle Instant Client
Při připojení pomocí Oracle Instant Client nešlo využít definice jednotlivých serverů v souboru TNSNAMES.ora, ale bylo potřeba zadat celou cestu přímo do definice Connection Pool (tedy v Data source Name je to, jak je definováno v tnsnames.ora):
To je sice pravda, ale je možné nainstalovat. Instalace sice není certifikovaná, ale pro potřeby pokusů a demonstrací je plně funkční. Postup instalace je následující:
- Uživatel ve Windows musí mít práva administrátora
- Zkopírujte instalační DVD na HDD počítače
- Najděte setup.exe, v properties mu nastavte "Spustit v režimu kompatability" Vista (nebo jiný podporovaný OS)
- Spustit setup.exe - Spustit jako správce (pravé tlačítko myši + vybrat z menu)
- Standardně instalovat
Další tipy
Vzhedem k tomu, že instalace neslouží k produkčnímu prostředí, ale k testování a demonstracím, je vhodné po startu počítače nespouštět zbytečně všechny služby, ale ponechat si možnost ručního spuštění. Je sice možné řešit startováním ( a zastavováním) jednotlivých sližeb, ale je šikovné si na to udělat startovací a zastavovací skripty (Pozor – oba se musí spouštět jako správce!):
Soubor BI_start.cmd
net start "Oracle BI Server"
net start "Oracle BI Java Host"
net start "Oracle BI Presentation Server"
C:\OracleBI\oc4j_bi\bin\oc4j.cmd -start
Soubor BI_stop.cmd
net stop "Oracle BI Java Host"
net stop "Oracle BI Presentation Server"
net stop "Oracle BI Server"
Připojení k databázi Oracle pomocí Oracle Instant Client
Při připojení pomocí Oracle Instant Client nešlo využít definice jednotlivých serverů v souboru TNSNAMES.ora, ale bylo potřeba zadat celou cestu přímo do definice Connection Pool (tedy v Data source Name je to, jak je definováno v tnsnames.ora):
Jan Jůza (CCA)
čtvrtek 26. listopadu 2009
Nové Oracle By Example pro OWB 11gR2
Nedávno do OBE (Oracle By Example) byly přidány nové příklady na Oracle Warehouse Builder verze 11gR2. První dva ukazují některé nové vlastnosti R2 verze (nové uživatelské prostředí, COBOL Copybook, ...), zbylé tři jsou do R2 verze předělány. Máte-li zájem, podívejte se na linky níže:
eec.
- Improved User Interface, Usability, and Productivity With OWB 11g R2
- Handling Flat File and COBOL Copybook Sources in Mappings
- Using Data Transformation Operators with Source and Target Operators
- Working with Pluggable Mappings
- Examining Source Data Using Data Profiling
eec.
pondělí 23. listopadu 2009
4. Oracle Czech BI/DW Experts Bootcamp
V pátek 20.11.2009 proběhl již 4. Oracle Czech BI/DW Experts Bootcamp, kterého se zúčastnilo 14 vybraných konzultantů a architektů od 12 Oracle partnerů:
Agenda setkání:
Prezentace z 1. workshopu - Tipy, triky a zkušenosti z BI/DW projektů:
Erik Eckhardt (Oracle)
- Jaroslav Vlček (Adastra)
- Jan Jůza (CCA)
- Karel Hübl (GEM system)
- Michal Tomek (Neit Consulting)
- Lukáš Hrnčíř (Neit Consulting)
- Václav Bíba (Ness Logos)
- Petr Zeman (OKsystem)
- Jiří Doubravský (Pike Electronic)
- Jakub Genža (CapGemini)
- Jiří Zamouřil (Oracle Consulting)
- Martin Gerneš (Oracle Consulting)
- Michal Zima (Teura)
- Martin Cabák (Reporters)
- Peter Hora (Sementa)
Agenda setkání:
- Zahájení / představení
- Novinky - Co se stalo od posledního 3. Bootcampu
- 1. workshop - Tipy, triky a zkušenosti z BI/DW projektů
(prezentace níže) - Novinky - Exadata v2
- 1. workshop - Pokračování
- Novinky - RTD
- 2. workshop - Co se vyřešit nepodařilo
- Novinky - 11g verze (FMW, OWB, ODI, BI) a GoldenGate
Prezentace z 1. workshopu - Tipy, triky a zkušenosti z BI/DW projektů:
Erik Eckhardt (Oracle)
- Zvýšení produktivity vývoje s ODI - Tvorba, úpravy a spouštění více jak +900 datových přenosů
- Efektivní datové integrace s ODI
- OBI 10.1.3.4.1 – Problém s filtry pro numerické datové typy
- Essbase - trigger pro instalaci HSS
- Posílání reportů z linuxového Publisheru na windowsový fileserver
- 64bitová Essbase pro Linux
- Tipy, triky a zkušenosti z projektu „Převod analýz z Excelu do Oracle BI”
- Použití kombinace funkcí Time Series (AGO a TODATE)
- Doplnění legendy do reportu přes XML
- Vliv nevhodného pojmenování časového údaje na použití v promptu
- Zkušenosti s implementací OBIEE v clusteru
- Jak v OBI změnit defaultní menu pomocí currencies.xml (zkusenost z BIAPPS)
- Jak v BIAPPS/ODI resetovat/vymazat jen jeden z modulů, ne celý warehouse (není zdokumentováno)
- Jak odstranit v Answers při filtrování odkaz "Omezené volby", který může vygenerovat dost narocný dotaz
- BI Delivers versus autentifikace proti DB
- Transformace datových a report požadavků do designu metadat a designu reportů
- Integrace OBI EE, SSO, OAM, OID
- Operátorská konzole pro OWB a ODI
- Komentáře a diskuze pro Oracle BI
pondělí 16. listopadu 2009
ODI a datový typ TIMESTAMP
Pokud v ODI datové pumpě přenášíte datový typ TIMESTAMP například z Oracle do Oracle, ale i z Oracle do jiné databáze, pak až do verze 10.1.3.5.3 ODI vždy „ořízlo“ počet desetinných míst u sekund na 3. Pokud jste tedy potřebovali využít přesnost například TIMESTAMP(6), pak o poslední 3 desetinná místa jste při přenosu dat přišli.
Na tuto chybu jsme narazili nedávno a byla na Oracle Metalinku zaevidována jako BUG 8917148. Odstraněna byla v patchi 9064641, který najdete tamtéž. Je označen jako Generic Cumulative Patch a upravuje číslo verze ODI na 10.1.3.5.4. Je možné jej aplikovat již od verze 10.1.3.5.0
Na tuto chybu jsme narazili nedávno a byla na Oracle Metalinku zaevidována jako BUG 8917148. Odstraněna byla v patchi 9064641, který najdete tamtéž. Je označen jako Generic Cumulative Patch a upravuje číslo verze ODI na 10.1.3.5.4. Je možné jej aplikovat již od verze 10.1.3.5.0
Petr Zeman (konzultant společnosti OKsystem s.r.o.)
čtvrtek 12. listopadu 2009
Oracle 11gR2 - Hybrid columnar compression
Před několika týdny byla uvolněna nová verze databáze Oracle 11G R2 a ta, mimo jiná „vylepšení“, obsahuje jednu velmi zajímavou funkčnost, která se týká způsobu uložení dat. Na první pohled to vypadá jako převratná novinka ve světě uložení dat, ale Oracle není první, kdo se pustil do vertikálního konceptu. Na druhou stranu můžeme být jen rádi, že Oracle stále sleduje současné trendy vývoje v oblasti relačních databází pro systémy pro podporu rozhodování a v ničem nezůstává pozadu proti specializovaným produktům pro DWH/BI ostatních konkurentů. Prvním důkazem je nám všem dobře známá Exadata, která je pravou Datawarehouse Appliance, a samozřejmě její víc než zajímavé vylepšení, a to nejen technologické, tak zejména z hlediska poměru ceny za TB, v podobě Exadata 2. Druhým průlomovým krokem je funkcionalita, o které bych se rád zmínil v tomto článku, a to hybridní vertikální komprese.
Relační databáze, které jsou dnes dostupné na trhu, podporují vesměs jeden z následujících dvou konceptů uložení:
Řádkové uložení je zřejmě nejvíce používaným způsobem uložení dat, tak jak jej známe ze všech verzí Oracle, MS SQL, PostgreSQL, MySQL a dalších. Data jsou ukládána po jednotlivých blocích a v rámci každého bloku jsou organizována po řádcích, stejně tak bloky jsou organizovány po řádcích. Každý řádek v rámci jednoho bloku obsahuje na začátku pointer, který označuje začátek řádku. To proto, protože řádky nemají fixní délku díky atributům s proměnnou délkou. Pokud je blok naplněn, další řádek se již zapisuje do dalšího volného bloku. Tento storage model je vhodný zejména pro OLTP systémy, kdy potřebujeme s vysokou selektivitou získat mnoho atributů z jednoho řádku. Pak se typicky provádí scan přes všechny řádky, případně indexy, filtruje se požadovaný záznam a vrací výsledek zpět. V případě OLAP/DSS systémů je výsledkem dotazu zpravidla restrikce (filtrování) dat, jejich následná agregace a projekce (vrácení pouze jednoho nebo několika atributů), jako např. aktuální počet zákazníků, nebo celkový objem transakcí za určité období. V tomto případě, i když potřebujeme z tabulky transakcí pouze datum a objem transakce, musíme projít všechny záznamy přes všechny atributy, což dotaz výrazně zpomaluje. Na druhou stranu čím více atributů z tabulky potřebujeme dostat, tím se řádkové uložení stává užitečnější.
Sloupcové uložení dat
Sloupcové, nebo také vertikální uložení dat, je koncept navržený výhradně pro DSS systémy. Místo toho, aby byly tabulky uloženy po jednotlivých řádcích, jsou uloženy po sloupcích. Hodnoty atributů jednotlivých řádků jsou tak uloženy vedle sebe, každá hodnota má navíc pointer, ukazující řádek, do kterého hodnota patří. Výhod tohoto způsobu uložení dat je hned několik – pokud použijeme v dotazu restrikci na určitý rozsah hodnot atributu (range restriction), pak se provádí nejprve scan jen jednoho atributu, po nalezení požadovaných hodnot se provádí tzv. rekonstrukce řádku, kdy se spojují nalezené hodnoty přes řádkový pointer na ostatní atributy a vrací se výsledek. V případě dotazů nad několika málo atributy je tento koncept vysoce efektivní proti řádkovému a přináší značné úspory v I/O operacích (čtení z disku). Problémy však nastanou, kdy je potřeba vrátit více atributů, pak se provádí nákladná rekonstrukce řádku přes více atributů a to zpracování velmi zpomaluje. Tento problém se však některé databáze snaží eliminovat pomocí tzv. „affinity graphs“, které seskupují atributy do skupin podle četnosti v dotazech. Další velkou výhodou vertikálního uložení dat je velmi rychlý update, pokud aktualizujeme jen jeden atribut přes všechny řádky. Poslední, ne nevýznamnou výhodou, je komprese, kdy pomocí vertikálního uložení dat můžeme dosáhnout mnohem vyššího kompresního poměru, proti řádkovému uložení. Důvodem je ukládání atributů po blocích a tím i možnost existence stejných hodnot v rámci jednoho bloku. Kompresí se také výrazně zrychluje čtení z disku, kdy se čte menší objem dat, tedy je menší náročnost na I/O a odpověď na dotaz je o to rychlejší. Tento koncept byl poprvé popsán již v roce 1979.
Příkladem relační databáze, používající vertikální koncept je Sybase IQ, která je na trhu už od 90 — tých let minulého století, dále pak novější a méně známé produkty, jako PARAccel, Infobright nebo Vertica.
PAX
Za tajemnou zkratkou PAX se skrývá název Partition Attributes Accross, což je koncept uložení dat, který byl poprvé popsán v roce 2001. Jedná se v podstatě o kombinaci dvou předchozích modelů, tedy řádkového a sloupcového s tím, že PAX eliminuje nevýhody obou a vytváří jakýsi hybrid, tedy „hybrid columnar storage“, na kterém je založena novinka v Oracle 11gR2.
Princip modelu spočívá v tom, že data jsou, podobně jako v případě řádkové uložení, ukládána po blocích, ale v rámci každého bloku jsou již organizována po sloupcích. V rámci bloku se vytváří tzv. minibloky, kde každý miniblok obsahuje hodnoty jednoho atributu pro řádky, které jsou součástí bloku. Tímto způsobem se eliminuje problém sloupcového uložení, kdy se musí provádět náročná rekonstrukce řádků při požadavku na větší počet atributů v dotazu, protože hodnoty atributu jsou uloženy spolu s ostatními atributy řádku v jednom bloku a tedy i rekonstrukce řádku je velmi jednoduchá. Při dotazu obsahujícím restrikci (filtr) na určitý sloupec jsou z disku čteny jen hodnoty tohoto sloupce, je provedena restrikce a následně rekonstrukce řádků. Neprovádí se tedy scan přes všechny atributy, jako v případě řádkového uložení, ale jen rychlý výběr hodnot jednoho sloupce. U tabulek s větším počtem atributů to může být velmi efektivní. Stejně tak zůstane zachována výhoda komprese u sloupcového uložení, kdy hodnoty atributu jsou uloženy vedle sebe. Teoreticky může být hodnota komprese zvýšena způsobem seřazení záznamů, kdy sloupec, podle kterého setřídíme data, bude mít nejspíše nejlepší kompresní poměr.
Oracle a PAX
V současné době existují pouze dohady, jakým způsobem je přesně implementován hybridní sloupcový model uložení v Oracle, pravděpodobně však inspirací je právě koncept PAX. Kompresí nad takto uloženými daty je pak možno dosáhnout 10x -40x kompresní poměr, podle charakteru dat (čím více opakujících se hodnot, tím vyšší kompresní poměr). Hovoří se také o možnosti vybrat si jen část dat, která bude uložena tímto způsobem a zbytek zůstane v klasickém řádkovém uložení. Zůstává otázkou, zda tento hybrid přinese i nějaký benefit v podobě zrychlení odezvy na některé typy dotazů. Z titulu komprese a tím menšího počtu I/O to pravděpodobné bude, z hlediska sloupcového uložení to záleží na skutečnosti, zda implementace je více sloupcová nebo více řádková. Více se snad dozvíme z dalších materiálů, které budou publikovány Oraclem k tomuto tématu.
V úvodu článku jsem se zmínil, že Oracle není jedinou databází, která přichází na trh s hybridní sloupcovou organizací dat. Dalším produktem, který se již brzy objeví na trhu je nová verze Vertica 3.5 a její koncept nazvaný Flex Store, který řeší něco podobného. Ovšem Vertica začala úplně z jiné strany než Oracle, jde od sloupcového uložení směrem k hybridnímu, Oracle od řádkového k hybridnímu. Budou tedy všechny databázové systémy pro podporu rozhodování v budoucnosti jen „hybridy“ ?
Relační databáze, které jsou dnes dostupné na trhu, podporují vesměs jeden z následujících dvou konceptů uložení:
- Řádkové uložení, neboli N-ary Storage Model (NSM)
- Sloupcové uložení, neboli Decomposition Storage Model (DSM)
Řádkové uložení je zřejmě nejvíce používaným způsobem uložení dat, tak jak jej známe ze všech verzí Oracle, MS SQL, PostgreSQL, MySQL a dalších. Data jsou ukládána po jednotlivých blocích a v rámci každého bloku jsou organizována po řádcích, stejně tak bloky jsou organizovány po řádcích. Každý řádek v rámci jednoho bloku obsahuje na začátku pointer, který označuje začátek řádku. To proto, protože řádky nemají fixní délku díky atributům s proměnnou délkou. Pokud je blok naplněn, další řádek se již zapisuje do dalšího volného bloku. Tento storage model je vhodný zejména pro OLTP systémy, kdy potřebujeme s vysokou selektivitou získat mnoho atributů z jednoho řádku. Pak se typicky provádí scan přes všechny řádky, případně indexy, filtruje se požadovaný záznam a vrací výsledek zpět. V případě OLAP/DSS systémů je výsledkem dotazu zpravidla restrikce (filtrování) dat, jejich následná agregace a projekce (vrácení pouze jednoho nebo několika atributů), jako např. aktuální počet zákazníků, nebo celkový objem transakcí za určité období. V tomto případě, i když potřebujeme z tabulky transakcí pouze datum a objem transakce, musíme projít všechny záznamy přes všechny atributy, což dotaz výrazně zpomaluje. Na druhou stranu čím více atributů z tabulky potřebujeme dostat, tím se řádkové uložení stává užitečnější.
Sloupcové uložení dat
Sloupcové, nebo také vertikální uložení dat, je koncept navržený výhradně pro DSS systémy. Místo toho, aby byly tabulky uloženy po jednotlivých řádcích, jsou uloženy po sloupcích. Hodnoty atributů jednotlivých řádků jsou tak uloženy vedle sebe, každá hodnota má navíc pointer, ukazující řádek, do kterého hodnota patří. Výhod tohoto způsobu uložení dat je hned několik – pokud použijeme v dotazu restrikci na určitý rozsah hodnot atributu (range restriction), pak se provádí nejprve scan jen jednoho atributu, po nalezení požadovaných hodnot se provádí tzv. rekonstrukce řádku, kdy se spojují nalezené hodnoty přes řádkový pointer na ostatní atributy a vrací se výsledek. V případě dotazů nad několika málo atributy je tento koncept vysoce efektivní proti řádkovému a přináší značné úspory v I/O operacích (čtení z disku). Problémy však nastanou, kdy je potřeba vrátit více atributů, pak se provádí nákladná rekonstrukce řádku přes více atributů a to zpracování velmi zpomaluje. Tento problém se však některé databáze snaží eliminovat pomocí tzv. „affinity graphs“, které seskupují atributy do skupin podle četnosti v dotazech. Další velkou výhodou vertikálního uložení dat je velmi rychlý update, pokud aktualizujeme jen jeden atribut přes všechny řádky. Poslední, ne nevýznamnou výhodou, je komprese, kdy pomocí vertikálního uložení dat můžeme dosáhnout mnohem vyššího kompresního poměru, proti řádkovému uložení. Důvodem je ukládání atributů po blocích a tím i možnost existence stejných hodnot v rámci jednoho bloku. Kompresí se také výrazně zrychluje čtení z disku, kdy se čte menší objem dat, tedy je menší náročnost na I/O a odpověď na dotaz je o to rychlejší. Tento koncept byl poprvé popsán již v roce 1979.
Příkladem relační databáze, používající vertikální koncept je Sybase IQ, která je na trhu už od 90 — tých let minulého století, dále pak novější a méně známé produkty, jako PARAccel, Infobright nebo Vertica.
PAX
Za tajemnou zkratkou PAX se skrývá název Partition Attributes Accross, což je koncept uložení dat, který byl poprvé popsán v roce 2001. Jedná se v podstatě o kombinaci dvou předchozích modelů, tedy řádkového a sloupcového s tím, že PAX eliminuje nevýhody obou a vytváří jakýsi hybrid, tedy „hybrid columnar storage“, na kterém je založena novinka v Oracle 11gR2.
Princip modelu spočívá v tom, že data jsou, podobně jako v případě řádkové uložení, ukládána po blocích, ale v rámci každého bloku jsou již organizována po sloupcích. V rámci bloku se vytváří tzv. minibloky, kde každý miniblok obsahuje hodnoty jednoho atributu pro řádky, které jsou součástí bloku. Tímto způsobem se eliminuje problém sloupcového uložení, kdy se musí provádět náročná rekonstrukce řádků při požadavku na větší počet atributů v dotazu, protože hodnoty atributu jsou uloženy spolu s ostatními atributy řádku v jednom bloku a tedy i rekonstrukce řádku je velmi jednoduchá. Při dotazu obsahujícím restrikci (filtr) na určitý sloupec jsou z disku čteny jen hodnoty tohoto sloupce, je provedena restrikce a následně rekonstrukce řádků. Neprovádí se tedy scan přes všechny atributy, jako v případě řádkového uložení, ale jen rychlý výběr hodnot jednoho sloupce. U tabulek s větším počtem atributů to může být velmi efektivní. Stejně tak zůstane zachována výhoda komprese u sloupcového uložení, kdy hodnoty atributu jsou uloženy vedle sebe. Teoreticky může být hodnota komprese zvýšena způsobem seřazení záznamů, kdy sloupec, podle kterého setřídíme data, bude mít nejspíše nejlepší kompresní poměr.
Oracle a PAX
V současné době existují pouze dohady, jakým způsobem je přesně implementován hybridní sloupcový model uložení v Oracle, pravděpodobně však inspirací je právě koncept PAX. Kompresí nad takto uloženými daty je pak možno dosáhnout 10x -40x kompresní poměr, podle charakteru dat (čím více opakujících se hodnot, tím vyšší kompresní poměr). Hovoří se také o možnosti vybrat si jen část dat, která bude uložena tímto způsobem a zbytek zůstane v klasickém řádkovém uložení. Zůstává otázkou, zda tento hybrid přinese i nějaký benefit v podobě zrychlení odezvy na některé typy dotazů. Z titulu komprese a tím menšího počtu I/O to pravděpodobné bude, z hlediska sloupcového uložení to záleží na skutečnosti, zda implementace je více sloupcová nebo více řádková. Více se snad dozvíme z dalších materiálů, které budou publikovány Oraclem k tomuto tématu.
V úvodu článku jsem se zmínil, že Oracle není jedinou databází, která přichází na trh s hybridní sloupcovou organizací dat. Dalším produktem, který se již brzy objeví na trhu je nová verze Vertica 3.5 a její koncept nazvaný Flex Store, který řeší něco podobného. Ovšem Vertica začala úplně z jiné strany než Oracle, jde od sloupcového uložení směrem k hybridnímu, Oracle od řádkového k hybridnímu. Budou tedy všechny databázové systémy pro podporu rozhodování v budoucnosti jen „hybridy“ ?
Radan Návrat (DWH architect v T-Systems)
pondělí 9. listopadu 2009
Dokumentační nepřesnost, týkající se „Security groups“ v metadatech BI Serveru
Jistě je všem, kteří s OBIEE již nějakou dobu pracují znám koncept Security Groups, které jsou definovány v metadatech BI serveru a které slouží k definovaní restrikcí v metadatech (objektové omezení pro objekty prezentační vrtsvy a „data level“ omezení definovaním tzv. security filtrů).
Standardní dokumentace OBIEE, konkrétně dokument „Server Administration Guide“ upřesňuje (v kapitole 15 „Security in Oracle BI“, odstavec Working with Groups , část „Group Inheritance“ uplatnění tzv. „least restrictive“ pravidla v případě, že uživatel je přirazen k více skupinám s „konfliktně“ nadefinovanými přístupovými privilegii:
„If there are multiple groups acting on a user or group at the same level with conflicting security attributes, the user or group is granted the least restrictive security attribute. Any explicit permissions acting on a user take precedence over any privileges on the same objects granted to that user through groups.“
Zjednodušeně řečeno, je-li definována security skupina GROUPA, která má např. právo „Read“ na subjektovou oblast SA1 prezentační vrstvy metadat a security skupina GROUPB, která má „Read“ privilegium na subjektovou oblast SA1 explicitně odebránu, pak je-li uživateli USER1 přidělena jak skupina GROUPA, tak GROUPB, pak tento uživatel má (díky „least restrictive“ pravidlu) „Read“ právo na subjektovou oblast SA1.
Toto pravidlo ovšem neplatí v případě definic tzv. „data level security“ pomocí „security filtrů“ :
Zde naopak platí „most restrictive „ pravidlo – tj. např. mám-li definovánu na úrovni business modelu logickou faktovou tabulku Fact1, a 2 security skupiny GROUPA a GROUPB, přičemž pro GROUPA nadefinuji pro tuto logickou faktovou tabulku „security filter“ a pro skupinu GROUPB tento filtr definován nebude. Pokud se uživatel USER1, kterému je přiřazena jak skupina GROUPA, tak skupina GROUPB dotazuje (v nástroji Answers) na metriky faktové tabulky, jsou mu data této faktové tabulky vždy omezena filtrem, definovaným pro skupinu GROUPA (i když zároveň patří i do skupiny GROUPB, která nad touto faktovou tabulkou žádný filtr nadefinován nemá).
Takže se v případě security filtrů nenechte zmást popisem ve standardní OBIEE dokumentací, chování BI serveru tomu neodpovídá.
Standardní dokumentace OBIEE, konkrétně dokument „Server Administration Guide“ upřesňuje (v kapitole 15 „Security in Oracle BI“, odstavec Working with Groups , část „Group Inheritance“ uplatnění tzv. „least restrictive“ pravidla v případě, že uživatel je přirazen k více skupinám s „konfliktně“ nadefinovanými přístupovými privilegii:
„If there are multiple groups acting on a user or group at the same level with conflicting security attributes, the user or group is granted the least restrictive security attribute. Any explicit permissions acting on a user take precedence over any privileges on the same objects granted to that user through groups.“
Zjednodušeně řečeno, je-li definována security skupina GROUPA, která má např. právo „Read“ na subjektovou oblast SA1 prezentační vrstvy metadat a security skupina GROUPB, která má „Read“ privilegium na subjektovou oblast SA1 explicitně odebránu, pak je-li uživateli USER1 přidělena jak skupina GROUPA, tak GROUPB, pak tento uživatel má (díky „least restrictive“ pravidlu) „Read“ právo na subjektovou oblast SA1.
Toto pravidlo ovšem neplatí v případě definic tzv. „data level security“ pomocí „security filtrů“ :
Zde naopak platí „most restrictive „ pravidlo – tj. např. mám-li definovánu na úrovni business modelu logickou faktovou tabulku Fact1, a 2 security skupiny GROUPA a GROUPB, přičemž pro GROUPA nadefinuji pro tuto logickou faktovou tabulku „security filter“ a pro skupinu GROUPB tento filtr definován nebude. Pokud se uživatel USER1, kterému je přiřazena jak skupina GROUPA, tak skupina GROUPB dotazuje (v nástroji Answers) na metriky faktové tabulky, jsou mu data této faktové tabulky vždy omezena filtrem, definovaným pro skupinu GROUPA (i když zároveň patří i do skupiny GROUPB, která nad touto faktovou tabulkou žádný filtr nadefinován nemá).
Takže se v případě security filtrů nenechte zmást popisem ve standardní OBIEE dokumentací, chování BI serveru tomu neodpovídá.
Michal Zima (Teura s.r.o.)
čtvrtek 5. listopadu 2009
Instalace Hyperion Shared Services (HSS) na Oracle databázi s českou lokalizací
V dokumentaci Oracle Hyperion Enterprise Performance Management System Installation Start Here Release 11.1.1 jsou uvedeny následující požadavky na konfiguraci Oracle databáze pro instalaci HSS:
Potíže s tím spojené jsou tyto:
create or replace trigger hyperion.nls_bugfix_trigger
after logon on database
declare u VARCHAR2(30);
begin
select user into u from dual;
if u = 'HYPERION' then
execute immediate 'alter session set nls_territory = ''AMERICA'' ' ;
execute immediate 'alter session set nls_language = ''AMERICAN'' ' ;
execute immediate 'alter session set nls_length_semantics = ''CHAR'' ' ;
end if;
end;
/
Testováno na verzi 11.1.1.2. Netestováno, zda problém přetrvává i na 11.1.1.3 (původní myšlenka viz. zde).
- Database character set = AL32UTF8 nebo UTF8 nebo UTFE
- grant CREATE SESSION, CREATE VIEW, RESOURCE
- nls_length_semantics = ’CHAR’
- nls_language = ‘AMERICAN‘
- nls_territory = ‘AMERICA‘
Potíže s tím spojené jsou tyto:
- Bez těchto parametrů (s výjimkou prvního) nelze HSS rozběhnout. Typický příznak: během instalace a zejména při spuštění HSS služby se opakovaně (na konzoli, v logu) objevuje chyba ORA-01722: invalid number.
- Řada instancí Oracle v českých zemích nemá tyto parametry.
- Změnit parametry nls_* na databázi (alter system) není obvykle dost dobře možné.
- Změnit parametry nls_* na klientovi (tj. stroj, kde běží HSS), podle mých dosavadních pokusů nestačí. HSS se totiž připojují přes driver JDBC Merant 5.2, který je vůči nastavení environmentu i javovským locale typu -Duser.language=en -Duser.region=US zcela imunní.
create or replace trigger hyperion.nls_bugfix_trigger
after logon on database
declare u VARCHAR2(30);
begin
select user into u from dual;
if u = 'HYPERION' then
execute immediate 'alter session set nls_territory = ''AMERICA'' ' ;
execute immediate 'alter session set nls_language = ''AMERICAN'' ' ;
execute immediate 'alter session set nls_length_semantics = ''CHAR'' ' ;
end if;
end;
/
Testováno na verzi 11.1.1.2. Netestováno, zda problém přetrvává i na 11.1.1.3 (původní myšlenka viz. zde).
Michal Tomek (konzultant společnosti Neit Consulting)
pondělí 2. listopadu 2009
Oracle BI – GO URL a české znaky
Jako součást jednoho projektu jsme implementovali GO URL API pro volání PDF a XLS reportů s parametry. V takovém případě se nevyhnete použití češtiny. České znaky jsou součástí řetězců, které jsou předávané jako hodnoty jednotlivých parametrů a zde byla čeština použita i v názvech samotných sestav v katalogu. V URL samozřejmě češtinu použít nelze.
Řešením je použít tzv. URL encoding. Při instalaci Oracle BI na platformě MS Windows a použití klienta na téže platformě (MS Internet Explorer 8) je třeba použít variantu UTF-8. Následující tabulka ukazuje, který znak nahradit jakou sekvencí:
Český znak UTF-8 sekvence
ě %C4%9B
š %C5%A1
č %C4%8D
ř %C5%99
ž %C5%BE
ý %C3%BD
á %C3%A1
í %C3%AD
é %C3%A9
ď %C4%8F
ť %C5%A5
ň %C5%88
ú %C3%BA
ů %C5%AF
Š %C5%A0
Č %C4%8C
Ř %C5%98
Ž %C5%BD
Á %C3%81
Ú %C3%9A
Na závěr malý příklad:
PŮVODNÍ URL:
http://biserver/analytics/saw.dll?Go&Path=/Shared/Kontrola/Reporty/Pokuty+Osob&NQUser=Administrator&Action=Navigate&Format=PDF&P0=2&P1=eq&P2="D01%20Datum".Datum&P3=13.9.2009&P4=like&P5="D15%20Důvod%20pokuty".Text&P6=%25500%25
UPRAVENÉ URL:
http://biserver/analytics/saw.dll?Go&Path=/Shared/Kontrola/Reporty/Pokuty+Osob&NQUser=Administrator&Action=Navigate&Format=PDF&P0=2&P1=eq&P2="D01%20Datum".Datum&P3=13.9.2009&P4=like&P5="D15%20D%c5%afvod%20pokuty".Text&P6=%25500%25
Řešením je použít tzv. URL encoding. Při instalaci Oracle BI na platformě MS Windows a použití klienta na téže platformě (MS Internet Explorer 8) je třeba použít variantu UTF-8. Následující tabulka ukazuje, který znak nahradit jakou sekvencí:
Český znak UTF-8 sekvence
ě %C4%9B
š %C5%A1
č %C4%8D
ř %C5%99
ž %C5%BE
ý %C3%BD
á %C3%A1
í %C3%AD
é %C3%A9
ď %C4%8F
ť %C5%A5
ň %C5%88
ú %C3%BA
ů %C5%AF
Š %C5%A0
Č %C4%8C
Ř %C5%98
Ž %C5%BD
Á %C3%81
Ú %C3%9A
Na závěr malý příklad:
PŮVODNÍ URL:
http://biserver/analytics/saw.dll?Go&Path=/Shared/Kontrola/Reporty/Pokuty+Osob&NQUser=Administrator&Action=Navigate&Format=PDF&P0=2&P1=eq&P2="D01%20Datum".Datum&P3=13.9.2009&P4=like&P5="D15%20Důvod%20pokuty".Text&P6=%25500%25
UPRAVENÉ URL:
http://biserver/analytics/saw.dll?Go&Path=/Shared/Kontrola/Reporty/Pokuty+Osob&NQUser=Administrator&Action=Navigate&Format=PDF&P0=2&P1=eq&P2="D01%20Datum".Datum&P3=13.9.2009&P4=like&P5="D15%20D%c5%afvod%20pokuty".Text&P6=%25500%25
Petr Zeman (softwarový konzultant, OKsystem s.r.o.)
čtvrtek 29. října 2009
ODI a OutOfMemoryError
Nedávno se mi na jednom projektu stalo, že jsem v ODI na svém počítači vyvinul transformační pumpy (Interface), které se na jiném počítači již nedařilo otevřít.
Během otevírání ODI Interface (ve fázi načítání grafického zobrazení transformace) vždy došlo k chybě "Diagram can not be loaded ...... java.lang.OutOfMemoryError ....".
Po bližší analýze jsem zjistil, že na daném PC je nainstalovaná jiná verze Javy, která konzumuje mnohem více paměti než ta moje.
Řešením bylo zvětšit defaultní hodnoty ODI parametrů (ODI_INIT_HEAP, ODI_MAX_HEAP) které ovlivňují kolik paměti budou mít ODI komponenty k dispozici.
Parametry se mění v souboru .../oracledi/bin/odiparams.bat (instalace na Windows), .../oracledi/bin/odiparams.sh (instalace na Linux / Unix).
Erik Eckhardt
Během otevírání ODI Interface (ve fázi načítání grafického zobrazení transformace) vždy došlo k chybě "Diagram can not be loaded ...... java.lang.OutOfMemoryError ....".
Po bližší analýze jsem zjistil, že na daném PC je nainstalovaná jiná verze Javy, která konzumuje mnohem více paměti než ta moje.
Řešením bylo zvětšit defaultní hodnoty ODI parametrů (ODI_INIT_HEAP, ODI_MAX_HEAP) které ovlivňují kolik paměti budou mít ODI komponenty k dispozici.
- ODI_INIT_HEAP - Initial java machine heap size used by OracleDI modules (defaultní hodnota po instalaci je 32MB)
- ODI_MAX_HEAP - Maximum java machine heap size used by OracleDI modules (defaultní hodnota po instalaci je 256MB)
Parametry se mění v souboru .../oracledi/bin/odiparams.bat (instalace na Windows), .../oracledi/bin/odiparams.sh (instalace na Linux / Unix).
Erik Eckhardt
pondělí 26. října 2009
Oracle Day 2009
19.11.2009 proběhne v Top Hotel Praha největší Oracle konference která kdy v ČR byla pořádána. Dopolední část je více zaměřená na business a strategii, odpolední část je rozdělena do paralelních sekcí se zaměřením na technologie (Databáze, Middleware, Bezpečnost), aplikace (OAUG) a vybraná průmyslová odvětví (Veřejný sektor, Zdravotnictví a pojišťovnictví, Obchod a průmysl, Finanční sektor).
Samotnou sekci zaměřenou pouze na DW/BI zde nenajdete, ale jednotlivé DW/BI technologie a aplikace jsou obsaženy v následujících sekcích:
Exadata
- Databáze (Sun Oracle Database Machine - Extrémní výkon pro OLTP I DWH)
- Finanční sektor (EXADATA V2 - eXtremní výkon pro finanční aplikace a datové sklady)
- Middleware (Když Service Bus nestačí přidejte Data Integrator)
- OAUG (Zkušenosti s Oracle Hyperion)
- OAUG (Využití Oracle JD Edwards v provozu a reportingu společnosti KRPA)
- Finanční sektor (Představení nové generace aplikací Oracle Financial Services Analytical Applications)
- Obchod a průmysl (Analytické aplikace: Předpřipravené řešení pro rychlé získání dat, analýz a výstupů z ERP a CRM systémů)
Registrační stránka a detailní informace o konferenci najdete zde.
Erik Eckhardt
čtvrtek 22. října 2009
Nové demo na BI Demo Serveru
Během léta jsem pracoval na POC pro jednu telekomunikační společnost. Jelikož problematika POC byla docela zajímavá (sledování poruchovosti provozovaných služeb a jejich následné řešení jednotlivými servisními středisky) domluvil jsem se zákazníkem možnost umístění vytvořeného POC na náš BI Demo Server.
POC vychází z reálného datového modelu, pouze veškeré hodnoty ukazatelů jsou zkresleny a číselníky/dimenze jsou anonymizovány - tzn. podobnost s vašimi reálnými službami a servisními středisky je čistě náhodná.
Erik Eckhardt.
POC vychází z reálného datového modelu, pouze veškeré hodnoty ukazatelů jsou zkresleny a číselníky/dimenze jsou anonymizovány - tzn. podobnost s vašimi reálnými službami a servisními středisky je čistě náhodná.
Erik Eckhardt.
pondělí 19. října 2009
Oracle Warehouse Builder 11gR2
Spolu s druhým releasem Oracle Database 11g byl v září uvolněn i druhý release Oracle Warehouse Builder 11g. Narozdíl od prvního release verze 11, která byla víceméně stejná jako verze OWB10gR2, je v současné verzi řada vylepšení a novinek (detailní seznam viz. níže).
Mezi ty nejdůležitější určitě bude patřit nativní podpora heterogenních zdrojů, Code-Template Mapping, webové služby a generování metadata repository pro Oracle Business Intelligence Enterprise Edition.
Tři výše uvedené jsou v současné chvíli prvním krokem integrace klasického OWB a ODI (v únoru 2009 jsem psal o vzniku nové edice s názvem Oracle Data Integrator Enterprise Edition, která licenčně spojuje Oracle Data Integrator a placenou DB Option OWB Enterprise ETL, která od té doby přestala být samostatně prodejná).
Zajímá-li vás roadmapa pro Oracle Warehouse Builder, pak ji najdete zde, Statement of Direction nejdete zde.
OWB11gR2 si můžete stáhnout z OTN
Bohužel stejně jako Oracle Database 11gR2 je i OWB11gR2 v současné době dostupné pouze na platformě Linux - tzn. chcete-li začít vyvíjet v novém OWB musíte mít jako OS klientské stanice Linux a nebo spustit OWB na některém z vašich Linux serverů a např. přes VNC nebo jiný remote desktop se k němu přihlásit.
Seznam nových vlastností OWB11gR2, seskupeno podle kategorií:
Upozornění: Z pohledu licencování mohou být některé nové vlastnosti použity pouze v případě, že vlastníte licenci Oracle Data Integrator Enterprise Edition. Seznam licencovaných vlastností najdete zde.
Kompletní seznam nových vlastností OWB11gR2 je dostupný zde, dokumentaci najdete zde.
Erik Eckhardt.
Mezi ty nejdůležitější určitě bude patřit nativní podpora heterogenních zdrojů, Code-Template Mapping, webové služby a generování metadata repository pro Oracle Business Intelligence Enterprise Edition.
Tři výše uvedené jsou v současné chvíli prvním krokem integrace klasického OWB a ODI (v únoru 2009 jsem psal o vzniku nové edice s názvem Oracle Data Integrator Enterprise Edition, která licenčně spojuje Oracle Data Integrator a placenou DB Option OWB Enterprise ETL, která od té doby přestala být samostatně prodejná).
Zajímá-li vás roadmapa pro Oracle Warehouse Builder, pak ji najdete zde, Statement of Direction nejdete zde.
OWB11gR2 si můžete stáhnout z OTN
Bohužel stejně jako Oracle Database 11gR2 je i OWB11gR2 v současné době dostupné pouze na platformě Linux - tzn. chcete-li začít vyvíjet v novém OWB musíte mít jako OS klientské stanice Linux a nebo spustit OWB na některém z vašich Linux serverů a např. přes VNC nebo jiný remote desktop se k němu přihlásit.
Seznam nových vlastností OWB11gR2, seskupeno podle kategorií:
Upozornění: Z pohledu licencování mohou být některé nové vlastnosti použity pouze v případě, že vlastníte licenci Oracle Data Integrator Enterprise Edition. Seznam licencovaných vlastností najdete zde.
Native Support for Heterogeneous Databases
OWB now provides extensive built-in support for non-Oracle databases. JDBC connectivity is added alongside previous support for ODBC and database gateways, and OWB now supports in-database ELT operations on non-Oracle databases. Other enhancements improve access to data from non-Oracle sources such as mainframe and flat file data.
Features in this area include:
SOA Integration Enhancements for ETL and Data Quality
The ETL and data quality functionality in OWB can now be integrated into SOA-style architectures.
Features in this area include:
Data Warehousing and Business Intelligence Enhancements
The data warehousing-specific support in OWB has improved. These improvements provide smarter dimensional object operators for ETL and support for more storage types for dimensional objects.
Features in this area include:
Developer Usability Enhancements
The Design Center user interface in OWB has been extensively redesigned to improve developer productivity and make advanced features more accessible.
Features in this area include:
Administrator Usability Enhancements
OWB administration tasks are simplified and improved by a number of features in this release. Administration has been extended to support new feature areas such as heterogeneous database support and Web services integration.
Features in this area include:
ETL Mapping Enhancements
ETL mappings have been enhanced to add new transformation capabilities and to improve the productivity of developers working with flat files and designing and debugging ETL mappings.
Features in this area include:
Process Flow Enhancements
OWB process flows have been enhanced to integrate with new activity types, out of the box, and to support integration of OWB ETL and data quality with SOA solutions.
Features that enhance process flows include:
Kompletní seznam nových vlastností OWB11gR2 je dostupný zde, dokumentaci najdete zde.
Erik Eckhardt.
čtvrtek 15. října 2009
Vytváranie Essbase kocky pomocou Essbase Studio 11g
Súčasťou EPM platformy v11 je nástroj Essbase Studio, ktorý poskytuje prostredie pre modelovanie dát, definíciu hierarchií a návrh Essbase kocky.
Úvod
Prv, ako si predstavíme Essbase Studio, uvediem pár slov ku štruktúre Essbase kocky. Essbase kocka pozostáva z dimenzií. Členovia dimenzie sú usporiadaní do hierarchickej štruktúry. Prvky jednej úrovne sa konsolidujú na vyššiu úroveň na základe definovaného konsolidačného operátora (Sčítanie, Odčítanie, Násobenie, Delenie, Percenta, Ignore). Tu je príklad Essbase Outline – definície Essbase kocky v nástroji Essbase Administration Services:
V nasledujúcom texte popíšem, ako sa dá zadefinovať štruktúra Essbase kocky a nahrať do nej dáta z Oracle DB. Ako demo dáta si zoberiem schému používateľa „andemo“, ktoré sú použité v deme Oracle BI Dashboards (štruktúra dát popísaná ďalej v texte).
Pre potreby tohto dema je potrebné mať naštartovanú databázu, kde je uložené Essbase repozitoty a nasledovné Windows Services z Hyperion platformy:
Štart Essbase Studio
Essbase Studio je súčasťou Essbase platformy a po inštalácii sa nachádza v skupine Oracle EPM System –> Essbase –> Essbase Studio. Najprv treba naštartovať Essbase Server (nie je definovaný ako Windows service) a potom spustiť Essbase Studio Console. Prihlásiť sa možno ako používateľ admin s heslom password. Po prihlásení sa objaví obrazovka s troma panelami:
1. Pripojenie k dátovému zdroju Oracle DB
Upozornění: Pro vyzkoušení si níže uvedeného příkladu si můžete data (Excel) a jejich popis stáhnout zde.
Úplne prvý krok je pripojenie sa k dátovému zdroju, z ktorého budeme čerpať nielen dáta ale aj položky, z ktorých budú pozostávať dimenzie. V pravej časti Source navigatora sú dve záložky „Data Sources“ a „Minischemas“. Označíme si Data Sources – pravý klik New – Data Source
Connectio Name – označenie pripojenia, u mňa „MyORCL“
Datasource Type – typ databázy, okrem Oracle DB su podporované nasledovné zdroje: MS SQL, IBM DB2, Oracle BI Server, Essbase, Dimension Server (je súčasťou EPM Architekt), text file.
V nižšej časti zadáme identifikátory Oracle databázy, posledný riadok „Database Name“ označuje schému používateľa.
V nasledujúcom kroku vyberieme tabuľky, ktoré budú použité na definovanie dimenzií pre Essbase kocku. Na úrovni DB je definovaná star schema pozostávajúca z nasledovných tabuliek: PRODEJ je faktová tabuľka, GEOGRAFIE, OBDOBI, PRODKANAL su dimenzionálne tabuľky. Tieto tabuľky budú základom Essbase modelu.
V ďalšom kroku si dáme vytvoriť Minischému, ktorá nám v grafickej podobe zobrazuje vzťah medzi tabuľkami, prípadne môžme tento vzťah dodefinovať. V tomto kroku máme možnosť využiť Introspection, ktorá odhaľuje hierarchie v dimenzionálnych tabuľkách. Výsledok nám môže ušetriť čas, avšak automaticky detekované dimenzie nie sú vždy korektné.
V tomto kroku ukončíme definovanie dátového zdroja, kliknutím na „Finish“ sa v strednej časti obrazovky („Work area“) zobrazí Minischéma.
Keďže na úrovni databázy nie sú nadefinované foreign keys, treba tieto vzťahy dodefinovať ručne v grafickom editore drag&drop od stĺpca faktovej tabuľky na stĺpec dimenzionálnej tabuľky. Pritom sa objavi editor, kde skontrolujeme a potvrdíme postupne tieto join podmienky:
PRODEJ.PRODKANAL_ID = PRODKANAL. PRODKANAL_ID
PRODEJ.GEOGRAFIE_ID = GEOGRAFIE.GEOGRAFIE_ID
PRODEJ.OBDOBI_ID = OBDOBI.KVARTAL_ID
2. Definovanie metadát
Presunieme sa do ľavej časti – Metadata navigator, kde si vytvoríme nový adresár (Folder) „Andemo“, v ktorom budú uložené všetky metadáta týkajúce sa nášho projektu. V adresári „Andemo“ vytvoríme podadresár „DimElements“, kde budú uložené položky použité pri definícii Essbase kocky. Postup:
A/ V časti Data Sources – pripojenie MyORCL označíme všetky štyri tabuľky a drag&drop ich prenesieme do Metadata Navigatora do adresára DimElements.
B/ Vymažeme stĺpce, ktoré nebudeme potrebovať, výsledok na nasledujúcom obrázku. Pri výbere si môžeme pomôcť náhľadom na dáta, v časti Data Sources si označíme tabuľku, pravý klik – View Sample Data
C/ DimElement môže byť odvodený od hodnoty stĺpca, pričom je možné využiť sadu preddefinovaných funkcií (toto je len ukážka)
Ďalším krokom je definícia dimenzií. V adresári „DimElements“ vytvoríme adresár „Hierarchies“, v ňom New –> Hierarchy. Prvú hierarchiu si pomenujeme Obdobie a Drag&Drop si do tabuľky v dolnej časti prenesieme DimElement Rok a Kvartal. Kvartal odsunieme o úroveň vpravo (tlačítko so šipkou). Takto definovanú hierarchiu si môžeme pozrieť pomocou tlačítka „Preview“. Definíciu hierarchie uložíme „Save“. Podobne vytvoríme hierarchie Geografie (EU_Celkem -> Stat) a ProdKanal (má iba jednu úroveň ProdKanal).
Na záver pridáme „Measure Hierarchy“ s názvom Predaj. Postup ten istý, Naklad a Vynos su na tej istej úrovni. Do tejto dimenzie pridáme novú položku Zisk. Klikneme tlačítko Add – > User-defined sibling, názov Zisk a posunieme túto položku na prvé miesto tabuľky, Vynos a Naklad odsunieme doprava. Spôsob výpočtu zisku nadefinujeme neskôr. Definíciu hierarchie Predaj uložíme kliknutím na „Save“.
3. Vytvorenie Cube Schema a Essbase modelu
Ďalším krokom je definovanie Cube Schema. Cube obsahuje definície jednotlivých hierarchií a nameraných hodnôt (measures), na základe ktorých sa buduje Essbase model. V Metadata Navigatore si označíme adresar Andemo -> pravy klik na myš –> New –> Cube Schema. Objaví sa Wizard, kde označíme Predaj ako Measure Hierarchy a Obdobie, Geografie, ProdKanal ako Hierarchies:
V ďalšom kroku označíme: Create Essbase Model a klikneme na tlačítko Finish.
V jednom kroku sa nám vygeneruje Cube Schema aj Essbase Model, ktorý môžme vidieť v strednej časti.
Vygenerovaný Essbase Model môžeme nasadiť na Essbase server pomocou Cube Deployment Wizardu (opäť pravý klik na myš, keď sme nastavený na Essbase modeli). Najprv vytvoríme pripojenie ku Essbase serveru.
Ďalej zadáme meno aplikácie a meno databázy, ktoré budú vygenerované spolu s Essbase kockou. Ďalšie voľby v Deployment Wizarde:
Kliknutím na „Model Properties“ môžeme definovať vlastnosti špecifické pre Essbase, ako sú:
Toto je miesto, kde nadefinujeme vzťah pre výpočet zisku: VÝNOS s konsolidačným operátorom + (addition), NÁKLAD s konsolidačným oprátorom – (subtraction). To znamená, že Zisk sa bude počítať ako VÝNOS – NÁKLAD. ZISK je zadefinovaný s operátorom + (addition), čo znamená, že táto hodnota sa bude prenášať aj na najvyššiu úroveň hierarchie, čo je Predaj.
Kliknutím na tlačítko „Close“ prebehne validácia zadaných hodnôt. Ak je všetko v poriadku, dostaneme sa späť do obrazovky Cube Deployment Wizard. Kliknutim na tlačítko „Finish“ prebehne deployment na Essbase server.
Úspešný Deployment môžeme skontorlovať cez Essbase Administratrion Services. Takto vyzerá vygenerovaný Outline pre našu aplikáciu Andemo:
A toto je náhľad na dáta pomocou SmartView.
Prípadné chyby z deployemntu môžete nájsť v adresári HYPERION_HOME\logs\esbstudio \server.log. V tomto súbore je zaznamenaný aj vygenerovaný SQL príkaz pre zdrojovú DB. Takže, ak by náhodou bola databáza po deploymente prázdna, treba sa zamerať na tento SQL príkaz.
Úvod
Prv, ako si predstavíme Essbase Studio, uvediem pár slov ku štruktúre Essbase kocky. Essbase kocka pozostáva z dimenzií. Členovia dimenzie sú usporiadaní do hierarchickej štruktúry. Prvky jednej úrovne sa konsolidujú na vyššiu úroveň na základe definovaného konsolidačného operátora (Sčítanie, Odčítanie, Násobenie, Delenie, Percenta, Ignore). Tu je príklad Essbase Outline – definície Essbase kocky v nástroji Essbase Administration Services:
V nasledujúcom texte popíšem, ako sa dá zadefinovať štruktúra Essbase kocky a nahrať do nej dáta z Oracle DB. Ako demo dáta si zoberiem schému používateľa „andemo“, ktoré sú použité v deme Oracle BI Dashboards (štruktúra dát popísaná ďalej v texte).
Pre potreby tohto dema je potrebné mať naštartovanú databázu, kde je uložené Essbase repozitoty a nasledovné Windows Services z Hyperion platformy:
Štart Essbase Studio
Essbase Studio je súčasťou Essbase platformy a po inštalácii sa nachádza v skupine Oracle EPM System –> Essbase –> Essbase Studio. Najprv treba naštartovať Essbase Server (nie je definovaný ako Windows service) a potom spustiť Essbase Studio Console. Prihlásiť sa možno ako používateľ admin s heslom password. Po prihlásení sa objaví obrazovka s troma panelami:
- Source Navigator (vpravo)
- Workarea
- Metadata Navigator
1. Pripojenie k dátovému zdroju Oracle DB
Upozornění: Pro vyzkoušení si níže uvedeného příkladu si můžete data (Excel) a jejich popis stáhnout zde.
Úplne prvý krok je pripojenie sa k dátovému zdroju, z ktorého budeme čerpať nielen dáta ale aj položky, z ktorých budú pozostávať dimenzie. V pravej časti Source navigatora sú dve záložky „Data Sources“ a „Minischemas“. Označíme si Data Sources – pravý klik New – Data Source
Connectio Name – označenie pripojenia, u mňa „MyORCL“
Datasource Type – typ databázy, okrem Oracle DB su podporované nasledovné zdroje: MS SQL, IBM DB2, Oracle BI Server, Essbase, Dimension Server (je súčasťou EPM Architekt), text file.
V nižšej časti zadáme identifikátory Oracle databázy, posledný riadok „Database Name“ označuje schému používateľa.
V nasledujúcom kroku vyberieme tabuľky, ktoré budú použité na definovanie dimenzií pre Essbase kocku. Na úrovni DB je definovaná star schema pozostávajúca z nasledovných tabuliek: PRODEJ je faktová tabuľka, GEOGRAFIE, OBDOBI, PRODKANAL su dimenzionálne tabuľky. Tieto tabuľky budú základom Essbase modelu.
V ďalšom kroku si dáme vytvoriť Minischému, ktorá nám v grafickej podobe zobrazuje vzťah medzi tabuľkami, prípadne môžme tento vzťah dodefinovať. V tomto kroku máme možnosť využiť Introspection, ktorá odhaľuje hierarchie v dimenzionálnych tabuľkách. Výsledok nám môže ušetriť čas, avšak automaticky detekované dimenzie nie sú vždy korektné.
V tomto kroku ukončíme definovanie dátového zdroja, kliknutím na „Finish“ sa v strednej časti obrazovky („Work area“) zobrazí Minischéma.
Keďže na úrovni databázy nie sú nadefinované foreign keys, treba tieto vzťahy dodefinovať ručne v grafickom editore drag&drop od stĺpca faktovej tabuľky na stĺpec dimenzionálnej tabuľky. Pritom sa objavi editor, kde skontrolujeme a potvrdíme postupne tieto join podmienky:
PRODEJ.PRODKANAL_ID = PRODKANAL. PRODKANAL_ID
PRODEJ.GEOGRAFIE_ID = GEOGRAFIE.GEOGRAFIE_ID
PRODEJ.OBDOBI_ID = OBDOBI.KVARTAL_ID
2. Definovanie metadát
Presunieme sa do ľavej časti – Metadata navigator, kde si vytvoríme nový adresár (Folder) „Andemo“, v ktorom budú uložené všetky metadáta týkajúce sa nášho projektu. V adresári „Andemo“ vytvoríme podadresár „DimElements“, kde budú uložené položky použité pri definícii Essbase kocky. Postup:
A/ V časti Data Sources – pripojenie MyORCL označíme všetky štyri tabuľky a drag&drop ich prenesieme do Metadata Navigatora do adresára DimElements.
B/ Vymažeme stĺpce, ktoré nebudeme potrebovať, výsledok na nasledujúcom obrázku. Pri výbere si môžeme pomôcť náhľadom na dáta, v časti Data Sources si označíme tabuľku, pravý klik – View Sample Data
C/ DimElement môže byť odvodený od hodnoty stĺpca, pričom je možné využiť sadu preddefinovaných funkcií (toto je len ukážka)
Ďalším krokom je definícia dimenzií. V adresári „DimElements“ vytvoríme adresár „Hierarchies“, v ňom New –> Hierarchy. Prvú hierarchiu si pomenujeme Obdobie a Drag&Drop si do tabuľky v dolnej časti prenesieme DimElement Rok a Kvartal. Kvartal odsunieme o úroveň vpravo (tlačítko so šipkou). Takto definovanú hierarchiu si môžeme pozrieť pomocou tlačítka „Preview“. Definíciu hierarchie uložíme „Save“. Podobne vytvoríme hierarchie Geografie (EU_Celkem -> Stat) a ProdKanal (má iba jednu úroveň ProdKanal).
Na záver pridáme „Measure Hierarchy“ s názvom Predaj. Postup ten istý, Naklad a Vynos su na tej istej úrovni. Do tejto dimenzie pridáme novú položku Zisk. Klikneme tlačítko Add – > User-defined sibling, názov Zisk a posunieme túto položku na prvé miesto tabuľky, Vynos a Naklad odsunieme doprava. Spôsob výpočtu zisku nadefinujeme neskôr. Definíciu hierarchie Predaj uložíme kliknutím na „Save“.
3. Vytvorenie Cube Schema a Essbase modelu
Ďalším krokom je definovanie Cube Schema. Cube obsahuje definície jednotlivých hierarchií a nameraných hodnôt (measures), na základe ktorých sa buduje Essbase model. V Metadata Navigatore si označíme adresar Andemo -> pravy klik na myš –> New –> Cube Schema. Objaví sa Wizard, kde označíme Predaj ako Measure Hierarchy a Obdobie, Geografie, ProdKanal ako Hierarchies:
V ďalšom kroku označíme: Create Essbase Model a klikneme na tlačítko Finish.
V jednom kroku sa nám vygeneruje Cube Schema aj Essbase Model, ktorý môžme vidieť v strednej časti.
Vygenerovaný Essbase Model môžeme nasadiť na Essbase server pomocou Cube Deployment Wizardu (opäť pravý klik na myš, keď sme nastavený na Essbase modeli). Najprv vytvoríme pripojenie ku Essbase serveru.
Ďalej zadáme meno aplikácie a meno databázy, ktoré budú vygenerované spolu s Essbase kockou. Ďalšie voľby v Deployment Wizarde:
- Load task Type – vyberieme Build outline and load data
- Load Data Options – má zmysel pri inkrementálnom load-e, pri prvom loade použijeme Add to existing data.
Kliknutím na „Model Properties“ môžeme definovať vlastnosti špecifické pre Essbase, ako sú:
- Na úrovni modelu sa definuje typ aplikácie (Block Storage, ktorý je default, resp. Aggregate Storage)
- Na úrovni hierarchie sa definuje Dimension storage: Dense/Sparse (len v prípade Block Storage)
- Na úprovni členov dimenzie Consolidation (operátor pre konsolildáciu členov na vyššiu úrovaň) a Data Storage. Viď obr. nižšie.
Toto je miesto, kde nadefinujeme vzťah pre výpočet zisku: VÝNOS s konsolidačným operátorom + (addition), NÁKLAD s konsolidačným oprátorom – (subtraction). To znamená, že Zisk sa bude počítať ako VÝNOS – NÁKLAD. ZISK je zadefinovaný s operátorom + (addition), čo znamená, že táto hodnota sa bude prenášať aj na najvyššiu úroveň hierarchie, čo je Predaj.
Kliknutím na tlačítko „Close“ prebehne validácia zadaných hodnôt. Ak je všetko v poriadku, dostaneme sa späť do obrazovky Cube Deployment Wizard. Kliknutim na tlačítko „Finish“ prebehne deployment na Essbase server.
Úspešný Deployment môžeme skontorlovať cez Essbase Administratrion Services. Takto vyzerá vygenerovaný Outline pre našu aplikáciu Andemo:
A toto je náhľad na dáta pomocou SmartView.
Prípadné chyby z deployemntu môžete nájsť v adresári HYPERION_HOME\logs\esbstudio \server.log. V tomto súbore je zaznamenaný aj vygenerovaný SQL príkaz pre zdrojovú DB. Takže, ak by náhodou bola databáza po deploymente prázdna, treba sa zamerať na tento SQL príkaz.
Gabriela Hečková (Oracle Slovensko)
pondělí 12. října 2009
OpenWorld 2009
Včera začala v San Franciscu každoroční konference Oracle OpenWorld. Všechny keynotes jsou dostupné zde, kompletní agendu konference najdete zde a jednotlivé DW/BI technologické přednášky níže:
eec.
- Vše o BI (včetně ukázek BI 11g)
- Vše o ODI
- Vše o EXADATA
- Vše o GoldenGate (heterogenní real-time integrace / streams)
eec.
Přihlásit se k odběru:
Příspěvky (Atom)