Daný požadavek lze řešit pomocí Outer Joinu, který je dostupný v Business Modelu metadata repository. Ten je ale potom použit při každém dotazu a může mít vliv na rychlost dotazů vracených z databáze.
Alternativou je simulovat Outer Join s použitím „fiktivní“ faktové tabulky a nechat BI Server provést join mezi faktovou tabulkou a „fiktivní“ faktovou tabulkou provádějící kartézský součin.
Postup
Nejdříve vytoříme faktovou tabulku „DUAL“ jako select: SELECT 1 AS SHOW_ALL FROM DUAL a přidáme sloupec „SHOW_ALL“ do sloupců tabulky.
Potom nastavíme Complex Physical Join
mezi tabulkami dimenzí, kde chceme simulovat Outer Join.
Vytřenou tabulku „DUAL“ přeneseme do Business Modelu a nastavíme Complex Joiny mezi tabulkami dimenzí.
Pro sloupec „SHOW_ALL“ je třeba nastavit agregační pravidlo, např. SUM a přidat sloupec do Presentation vrstvy, aby jej mohli uživatelé použít při tvorbě a definici reportů.
Ukázka reportu o prodeji podle prodejních kanálů a jednotlivých zemí. Bez použití hodnoty „SHOW_ALL“ vidíme pouze hodnoty za země a prodejní kanály kde byly nějaké obchody uskutečněny. Přidáním sloupce „SHOW_ALL“ dostaneme i přehled o tom, kde se prodeje neuskutečnili. Aby sloupec SHOW_ALL v reportu nepřekážel, tak jej:
- u kontingenční tabulky dáme do oblasti Vyloučeno
- u obyčejné tabulky nastavíme atribut skrýt ve formátu sloupce
Petr Podbraný (Oracle)
1 komentář:
Moc dobrý nápad. S chutí jsem jej použil. Ovšem, když jsem s fiktivní tabulkou svázal s časovou dimenzi, repository se stal nekonzistentní, protože zdrojová tabulka dimenze označené jako "time dimension" měla physical outer join. Vyřešil jsem to takto: Do zdrojové tabulky časové dimenze jsem přidal sloupec ONE integer s konstatní hodnotou 1 a tabulku jsem pak s fiktivní tabulkou propojil přes physical foreign key na tomto sloupci (ONE=SHOW_ALL).
Funguje to spolehlivě.
Okomentovat