čtvrtek 29. dubna 2010

FAT – FACTORY TESTY V DWH

1. Co jsou Factory testy?
FAT – Factory Acceptance Test - je jeden z řady mnoha testů, které se provádějí před nasazením DWH nebo jeho nové verze do provozu.

FAT plynule navazuje na Unit a Extract testy (EAT) a dále pokračuje uživatelskými testy (UAT) jež zahrnují systémové integrační testy, testy bezpečnosti systému (SAT), ověření správnosti statických dat (SDAT) a regresní testy (RAT). Celý proces testování je završen podepsáním akceptačního protokolu. V tomto článku se zaměřím pouze na jednu část tohoto testovacího řetězce, na popis FAT.

FAT je první test, který umožňuje ověřit nasazované řešení jako celek. Do této chvíle se ověřovala správná funkčnost jednotlivých modulů řešení, ale teprve test celého systému DWH nám umožní říci, že dodávané řešení je kompletní a s požadovaným chováním.

V průběhu FAT je potřeba se zaměřit na následující části DWH:
• Migrace
• Datový model
• ETL Moduly
• Procesy
• Výstupy - reporty, uživatelské rozhraní (EUL) a dávkové rozhraní
• Dokumentace

FAT se provádějí v rámci vývojového týmu tj. maximálně se využívají stávající vývojáři DWH a jejich vývojové nástroje. Jak externí síly lze využít administrátory databáze pro přípravu testovacího prostředí.


1.1 Test migrace
Každé nové řešení DWH je nutno nasadit do běžného – produkčního provozu. Je celkem jedno, zda se jedná o první nasazení DWH nebo jen doplnění nové funkčnosti do již existujícího DWH, vždy se však musí nově vyvinuté řešení nasazovat prostřednictvím migračních modulů, které jsou seskupovány do migračních procesů. Vždy je od migrace vyžadováno, aby proběhla rychle a bez problémů, v přesně definovaném časovém úseku. Aby bylo tohoto dosaženo, je nutno migrační proces otestovat již v rámci FAT.

Cílem tohoto testu je ověřit že:
• do migrace jsou zařazeny všechny požadované moduly
• moduly provádějí požadovanou činnost
• moduly obsahují požadované informační části (autor, popis, datum změny …)
• moduly se vzájemně nechtěně neovlivňují
• moduly jsou prováděny v požadovaném pořadí
• moduly jsou dokončeny v požadovaném čase
• migrace se zastaví v případě výskyty chyby v některém z modulů
• všechny aktivity modulů jsou auditovány

Vzhledem k tomu, že test migrace vyžaduje vždy přípravu nového prostředí DWH, migraci nelze spouštět opakovaně, provádí se tento test ve FAT pouze jednou. Ověření správnosti opravy chyb nalezených v tomto testu se nechává do testů UAT.


1.2 Datový model
Cílem tohoto testu je ověřit správnost nasazovaného datového modelu DWH. V průběhu tohoto testu je nutno provést kontrolu:

Tabulek
– zda vytvořené tabulky jsou správně pojmenované a jejich jména splňují metodické požadavky, tabulky jsou umístěny ve správném databázovém prostoru a obsahují požadované oddíly (partition).

Sloupců tabulek – zde je třeba ověřit správnost názvu sloupce, jeho datový typ a délku, omezení sloupce

Primární a unikátní klíče tabulek – název klíče musí odpovídat definovaným standardům a klíče musí obsahovat správné sloupce a to ve správném pořadí

Indexy – názvy indexů musí odpovídat standardům a musí být umístěny ve správném databázovém prostoru.

Poznámka: Ač jsou view a triggery standardně požadovány za součást datového modelu, zde je nutno je zahrnout do testů ETL modulů neboť jejich definice je většinou výstupem programátorské práce a jsou i součástí ETL procesů. View používané v EUL je nutno testovat jako součást testů uživatelského rozhraní.


1.3 ETL moduly
ETL modul je logická komponenta DWH, která zajišťuje přenos dat ze zdroje do cíle (zdroj i cíl může být zároveň DWH) podle zadaného algoritmu.
Smyslem tohoto testu, je ověřit kompletnost realizovaných ETL modulů vůči logickému mapování uvedenému v zadávací dokumentaci.

Požadavek je, aby pro testování byla ve zdroji dostupná data rozsahem blížící se skutečnosti. U každého ETL modulu je nutno ověřit:

Opakovatelnost – modul musí být opakovaně spustitelný nad stejným vzorkem dat. V případě, že tomu tak není, je nutno tuto informaci udržovat v dokumentaci modulu.
Pokud data na vstupu i v cíli nebyla změněna a nezměnilo se podmínky běhu, nesmí mapování, při opakovaném běhu, provádět žádné změny na cílových datech

Logování – každá modul musí o své činnosti zaznamenávat informace (začátek a konec běhu, počet zpracovávaných záznamů, počet vložených a změněných záznamů)

Ošetření chyb – modul musí v případě chyby, i jediné, ukončit svoji činnost a ohlásit příčinu chybu.

Funkcionalita – podle určení modulu je nutno otestovat zda modul vkládá, mění nebo jen maže záznamy ve svém cíly podle zadaného algoritmu popsaného v zadávací dokumentaci.

Reversibilita – modul musí umět záznam, které je označen jako logicky zrušený, tento záznam nastavit jako aktivní.

Výkonnost – doba zpracování dat modulu musí být přiměřená jako pro zpracování plné množiny dat na vstupu, tak i přírůstkového množství. FAT však nejsou primárně určeny k výkonnostním testů, neboť i dostupné systémové prostředky výpočetní techniky bývají omezené, ale již zde se dá přehledově určit, zda je implementace logického mapování navržena optimálně s dostatečnou výkonnostní rezervou. Zde nalezené problémy je ještě možno včas a s minimálními náklady odstranit.

Spolupráce s ostatními moduly – modul nesmí negativně ovlivňovat současně běžící jiné moduly tj. např. nesmí zamykat celé tabulky, pokud to není vyžadováno funkcí mapování.


1.4 Procesy
Procesy spojují jednotlivé ETL moduly do jednoho celku, který doplňují o podpůrné funkce jako je vytváření a mazání partition, počítání statistik a mnohé další.ETL moduly jsou propojeny logickými operátory, které umožňují jejich paralelní běh. Při testech procesů je nutno se zaměřit na:

Kompletnost – proces obsahuje všechny ETL moduly spouštěné ve správném pořadí a se správnými parametry.

Závislosti – pro každý proces musí být nastaveno za jakých podmínek je možné proces spustit tj. jaká vstupní data musí být k dispozici, které další procesu musí být dokončený nebo naopak nesmí běžet současně.

Reakce na vstupní data – proces musí být schopen na základě typu vstupních dat (plný/přírůstkový) spouštět příslušné modulu

Oznámení – proces při dokončení nebo v případě chyby zasílá oznámení příslušným adresátům s doplňujícími informacemi např. o počtu zpracovaných záznamů.


1.5 Výstupy - reporty,uživatelské rozhraní EUL a dávkové rozhraní
Reporty a uživatelské rozhraní je klíčový prostředek pro zpřístupnění dat koncovým uživatelům. Testy této oblasti budou maximálně soustředěny v dalších kolech UAT. V prostředí FAT je však možno zkontrolovat:

Kompletnost - jsou připraveny všechny požadované reporty nebo jejich vzory. EUL obsahuje všechny datové položky, které mají být zpřístupněny. Aktivní prvky reportů vykonávají svou činnost.

Datovou kvalitu – reporty zobrazují správné datové položky v odpovídajícím formátu. Data pro EUL jsou aktualizována.

Testy dávkového výstupního rozhraní zahrnují oba výše uvedené body. Je nutno zkontrolovat jak úplnost – v dávce jsou zahrnuty všechny soubory, tak i obsahově.


1.6 Dokumentace
Obsah dokumentace je sice schvalován při vytváření požadavků pro vývoj, přesto v průběhu vývoje může dojít k realizaci změnových požadavků nebo k odchylkám (samozřejmě schváleným uživateli) od původního zadání. Všechny tyto změny musí být podchyceny v aktuální podobě v dokumentaci projektu. Nejlépe se kompletnost a především pochopitelnost dokumentace pro i jiné účastníky projektu, ověří v průběhu FAT tak, že jednotlivé testovací případy nevytváří ani zadavatel, ani programátor, ale tester, doposavad do problematikou dané oblasti se nezabývající.


2. Příprava testů
Přípravu FAT nelze nijak podcenit a je nutno se na tyto testy začít připravovat se začátkem vývoje. Je nutné zajistit připravenost testovacích dat, testovací infrastrukturu a rozdělit testovací oblasti mezi budoucí testery. Osvědčilo se křížové rozdělení jednotlivých oblastí mezi vývojáře, tak aby žádný vývojář netestoval oblast kterou vyvíjel. Časová souslednost je znázorněna na časovém diagramu na obr. 1


  • Příprava TC – testovací případy jsou připravovány již v průběhu vývoje

  • Provádění TC (Datový model) – testy datového modelu mohou být prováděny již v průběhu vývoje, neboť úplný datový model je nutný předpoklad pro zahájení fáze vývoje

  • Provádění TC (Migrace) – test migrace je první test provádění v rámci FAT

  • Provádění TC (ETL moduly) – testy infrastrukty lze provádět již v průběhu vývoje, ale jinak se jedná o hlavní náplň FAT

  • Provádění TC (Procesy) – testy procesů probíhají po celo dobu FAT

  • Provádění TC (Výstupy) – testy uživatelského rozhraní a dávkové výstupy lze provádět až po nahrání všech dat ETL moduly...
Na podporu FAT a přípravu testovacích případů je výhodné využít některých z bug tracking systémů neboť se tím docílí vyšší produktivity testů.


3. Shrnutí
Provedením všech požadovaných kroků FAT a vyhledáním maximálního počtu chyb v DWH již ve FAT a jejich odstranění, umožní zdárné dokončení celého vývojového cyklu DWH a zvýší prestiž dodavatele řešení.


Jiří Zamouřil (Oracle Consulting)

pondělí 26. dubna 2010

ODI - Změna sloupce (update key) na jehož základě probíhá aktualizace nebo vkládání záznamů do cílového DataStore

„Update key“ je sloupec na jehož základě ODI provádí podmínku při porovnávání záznamů pro aktualizaci nebo vkládání do cíle. Například při použití Znalostního modulu „IKM Oracle Incremental Update (MERGE)“ je „Update key“ použit v klausuli ON příkazu MERGE.


Jako „Update key“ ODI standardně použije Primární klíč (když neexistuje, tak Unikátní klíč) definovaný v modelu cílového DataStore.

V některých případech se Vám může stát, že nechcete využívat přednastavený Primární klíč tabulky, ale chcete si nadefinovat vlastní. Jestliže cílová tabulka má ve svém modelu již nějaký klíč definován, pak je volba zapnutí „Update“ klíče na sloupcích zakázána.


Změna se provádí tak, že kliknete na název tabulky v sekci Target DataStore a vlevo dole si z menu vyberete jiný předdefinovaný klíč (musí existovat v modelu cílového DataStore) a nebo nastavíte hodnotu „Undefined“.


Hodnota „Undefined“ Vám zpřístupní volbu zapnutí „Update“ klíče na sloupcích cílové tabulky.


Výsledný MERGE poté použije nový „Update key“ v klausuli ON.



Erik Eckhardt

pondělí 19. dubna 2010

Implicit Fact Column - Jak ovlivnit zpracování joinu více dimenzí bez faktů

Nedávno jsem dostal od jednoho našeho partnera otázku ohledně zpracování reportu, který je definován pouze nad sloupci z různých dimenzí (žádný sloupec z faktové tabulky) a v Metadata repository existuje více faktových tabulek, které mají vazbu na tyto dimenze. Kterou faktovou tabulku BI Server použije pro JOIN dimenzí a jak mu přednastavit tu správnou?

Odpověď je jednoduchá - v Prezentační vrstvě Metadata repository lze nastavit tzv. Implicit Fact Column – sloupec, který bude automaticky přidán do dotazu v případech, kdy dotaz obsahuje pouze sloupce ze dvou nebo více dimenzí, ale žádné ukazatele. Implicit Fact Column je interní sloupec, který není vidět na reportu - je použit pro specifikování standardní cesty joinu dimenzí, kdy existuje více možných alternativ.

Nastavuje se pro jednotlivé Cílové oblasti na Prezentační vrstvě. Z menu Properties... stisknete tlačítko Set... Implicit Fact Column a vyberete ukazatel z požadované faktové tabulky.



Erik Eckhardt

čtvrtek 15. dubna 2010

Rozšíření uživatelského menu v Oracle BI

Zadání
Nedávno náš zákazník vyjádřil přání, aby uživatelé měli k dispozici odkaz na vlastní dokumentaci – a to nejlépe, aby tento odkaz byl uživatelům k dispozici v kteroukoliv chvíli při práci v Oracle BI.
Jako ideální oblast pro umístění odkazu se jeví uživatelské menu obsahující základní odkazy na Dashboards, Answers a další.


Řešení
Podoba uživatelského menu je definována v souboru ...\OracleBI\web\msgdb\messages\commonuitemplates.xml. Pokud bychom rádi zařadili nový odkaz za odkaz na BI Answers, najdeme tag označený takto: kmsgUIAnswers.

Za něj vložíme požadovaný HTML kód, který definuje nový odkaz (tučně zvýrazněno):


Tím vytvoříme požadovaný odkaz na dokumentaci, který je uživatelům stále na očích. Dle potřeb lze samozřejmě využít i pro tvorbu odkazu na jakoukoliv jinou aplikaci, intranetový portál a podobně.


Jakub Genža (Sophia Solutions, s.r.o.)

pondělí 12. dubna 2010

Oracle Warehouse Builder 11g Release 2 (11.2.0.1.0) Standalone Software je k dispozici

Týden po uvolnění Oracle Database 11g Release 2 pro MS Windows je k dispozici i samostatná verze OWB 11g Release 2 (11.2.0.1.0). Stáhnout si ji můžete zde.

čtvrtek 8. dubna 2010

Oracle Data Integrator - Tipy, triky a zkušenosti z integračních projektů

Registrujte se nyní zdarma na tento seminář - klikněte ZDE.


Oracle Data Integrator (dříve Sunopsis) je strategická platforma společnosti Oracle pro jakékoli datové integrace v heterogenním prostředí (více informací o ODI najdete zde).

V České republice jsme poprvé ODI představili v červnu 2008 na semináři Oracle Coffee. V té době u nás existoval pouze jeden zákazník a jeden partner, který uměl Data Integrator nasadit.

V současnosti je situace zcela jiná, ODI umí implementovat více jak 15 Oracle partnerů a právě probíhá šest integračních projektů, na kterých je ODI využíván jako hlavní integrační nástroj pro přesuny, konsolidace a transformace dat z heterogenních zdrojů do heterogenních cílů.

Přijďte na seminář a seznamte se s jedním z projektů, který je již ve fázi produkce. Dozvíte se různé tipy&triky o tom jak:

  • pracovat s více Master repository
  • přenášet kód z vývoje do produkce
  • vyvíjet vlastní Znalostní moduly
  • rozšiřovat ODI o vlastní komponenty
  • vyvíjet v Javě
  • automaticky vytvářet a spouštět stovky datových přenosů najednou
  • rozšířit výpis logu Operátora o vlastní poznámky
  • a další

Seminář je určen především těm, kteří mají alespoň základní znalosti a povědomí o ODI, tzn. účastnili se prezentace, hands-on workshopu nebo jej již používají/implementují.

Úroveň odbornosti: 4 z 5

Zaregistrujte se, prosím, co nejdříve, počet míst je omezen!

budova Oracle Czech
Škrétova 12
Praha 2
čvrtek 22.4.2010
8:00 - 10:30



úterý 6. dubna 2010

Oracle Database 11g Release 2 pro MS Windows je již ke stažení

Na OTN je od pátku ke stažení Oracle Database 11gR2 (přesně 11.2.0.1.0) i pro MS Windows, link najdete zde (Standalone verze OWB 11gR2 zatím dostupná není).



eec.

čtvrtek 1. dubna 2010

Návštěvnost BI/DW Blogu za Q1/2010

Seznam článků za Q1/2010 (leden - březen 2010), seřazeno dle kategorie

BI Publisher

BI Publisher - FAQ

DWH

DWUG

GoldenGate

Novinky

OBI - EE

OBI EE - DEMO

OBI EE - FAQ | OBI SE ONE - FAQ

OBI SE ONE

ODI / Sunopsis

ODI - FAQ

OWB