Př.: Datový model: F_SALES_BY_STORE_PD. SALES_AMT (Tržba) a D_STORE.STO_SELLING_AREA (m2 prodejní plocha prodejny). Zajímá nás „Tržba na m2 prodejní plochy prodejny“ (dále jen Tržba/m2).
BMM vrstva v OBI vypadá následovně:
Klasický modelu, kdy:
- Fact-Sales má LTS: F_SALES_BY_STORE_PD a
- STO_SELLING_AREA je atributem dimenze Dim – Store, která má LTS D_STORE
Sestava vrací nesprávný výsledek, kdy sečtená tržba, je vydělena prodejní plochou pouze jedné z prodejen. Není nikde řečeno, že STO_SELLING_AREA je potřeba napříč vícero prodejnami sečíst.
Tržba / Prodejní plocha (m2) = "- Základní metriky"."Tržba" / Prodejna."Prodejní plocha (m2)"
Řešením by mohlo být vytáhnutí STO_SELLING_AREA z dimenze do Fact-Sales ať již vytvořením view na úrovni db, nebo na úrovni BMM vrstvy (nová tabulka pro stávající LTS). Nyní již lze nastavit agregační pravidlo SUM pro STO_SELLING_AREA. Vyhráno ovšem není. Nejsou ošetřeny situace, kdy má smysl STO_SELLING_AREA sečíst a kdy ne (potřebujeme totiž sumu prodejních ploch prodejen takovou, kdy každá prodejna přispívá svoji prodejní plochou do celkového součtu ve zkoumaném období právě jednou)
Řešením skutečně zahrnuje přidání atributu STO_SELLING_AREA do Fact-Sales. Je však potřeba mít STO_SELLING_AREA namapován na nový LTS tvořený tabulkou D_STORE s nastavením Content = Store Detail.
Nyní na úrovni metadat nově vytvořená logická metrika definovaná
použitá v sestavě generuje správný SQL dotaz, skládající se ze dvou subdotazů:
A jsme v cíli, i když … šlo by to vylepšit z hlediska business logiky. Předvedený způsob realizace výpočtu je nespravedlivý k prodejnám, které mají otevřeno méně dní než ostatní, nebo pro prodejny, které zahájily svoji činnost někdy v průběhu sledovaného období.
Václav Bíba (Teura)
Žádné komentáře:
Okomentovat