23. února 2018

Power BI – Globální slicery

Dnešní blog bude opět informativní rychlovka. Musím, prostě musím, se ale s vámi podělit. Přišla novinka, na kterou jsem nejen já čekal dlouho a horlivě.
Jedná se o možnost ovládat více stránek jedním slicerem (v CZ verzi průřezy).
V čem byl v minulosti problém? Pokud jste chtěli, aby uživatel měl možnost filtrovat data například přes produktovou hierarchii a rozbili informaci na více stránek,museli jste slicery kopírovat ze strany na stranu.
To by samo o sobě nebylo špatné. Pokud by první stránka byla o prodejích (obrat), druhá o maržích. Pokud uživatel zvolí na první stránce ve slicerech kategorii
„Spotřební elektronika“ a časové období „poslední 4 týdny“ z defaultního jednoho. Na druhé stránce bude muset znovu vybrat spotřební elektroniku a 4 týdny...
Čím více slicerů, tím více radosti!
To platilo až do poslední aktualizace Power BI Desktopu.
Nyní máme možnost na záložce View zobrazit lištu Sync Slicers
Když pak vyberete slicer například s kategorií, zobrazí se seznam stránek jako na obrázku. První sloupec s zatržítky je o tom, na kterých stránkách chcete slicer aktualizovat.
Druhý sloupec je o tom, zda na stránce má být slicer vůbec vidět. Můžete ho ale i nechat další stránku ovládat bez zobrazení.
Stačí tedy zatrhat vše v prvním sloupečku (kde je to relevantní) a na ostatní stránky se již změny budou propagovat. Přeji hodně zábavy.
Závěr
Dnešní blog je opravdu informativní rychlovka, která ale snad potěší. Minimálně funkce synchronizace slicerů snad potěší. U slicerů se můžeme těšit i na další novinky.
Bude se jednat o tzv “sticky slicers” Po publikaci reportu do Power BI service si uživatel bude moci vybrat, zda chce nastavení slicerů z posledního zobrazení uložit pro příští seanci/session.
Zatím se dá tohle v desktopu zakázat pro konkrétní sešit a nastavení ještě není na straně service dostupné. Jakmile to ale bude venku, budu vás informovat.
Bude to řešit problematiku: Mám 50 uživatelů a každý chce vidět jiný default. Máme se tedy na co těšit i nadále.
Link na rozcestník dalších článků o Power BI http://www.neoral.cz/2016/10/power-bi-rozcestnik.html

14. února 2018

Power BI - monitoring využití reportů

Aktualizovaný rozcestník Power BI článků najdete zde: http://www.neoral.cz/2016/10/power-bi-rozcestnik.html
Dnešní článek jsem rozepsal už před delší dobou. Nicméně vyskytla se chybka na Power BI service, takže vše se
nelogovalo tak, jak by mělo. Zdroj: https://powerbi.microsoft.com/en-us/support/
Aneb v časovém okně 19.1. až 7.2. nedocházelo k logování použití reportů. Mám takový pocit, že se tahle
informace objevila až v pondělí ráno po tom, co jsem psal v pátek do Microsoftu, že mám s tímto konkrétně
problém :)
O co se jedná? O BI nad vaším Power BI :) Aneb sledování toho, zda vaše reporty vůbec někdo používá. To je
otázka na kterou je dobré znát odpověď, i když někdy nemusí být příjemná.
Aby logování probíhalo, je potřeba si prvně zkontrolovat zda logujete. V admin portálu Power BI postupujte
následovně
Zpoždění logování je cca 24hodin. Potom ve Workspace kliknete na tlačítko usage metrics.
A připraví se report. Tento je předfiltrovaný na konkrétní report/dashboard u kterého jste na usage metrics
kliknuli.
Pokud chcete informace o tom, co se děje  celém Workspace na jedné hromadě, můžete si uložit kopii tohoto
reportu přes Save as dialog.
A tuto kopii můžete editovat.
V definici reportu můžete vyhodit konkrétní Guid reportu a tím pádem dostanete přehled o celém Workspace.
Můžete se pověnovat vizuální podobě tohoto reportu přímo z prohlížeče.
Nebo můžete použít funkci Analyze in Excel a podrobně se podívat, jaký obsah ve vašem osobním/sdíleném
workspace je využíván a který obsah naopak ne.
Závěr

Dnešní blog byl taková užitečná rychlovka. Monitorování toho, co uživatelé používají vám dává zpětnou vazbu o
vašich Power BI výstupech. Tak přeji pěkná čísla, aby vaše reporty vaši uživatelé používali :)

9. února 2018

Analýza nákupního košíku

Pokud jste nedočkaví článku, můžete přeskočit moji krátkou vsuvku po odmlce na sekci článek.
Vsuvka je o tom, proč byla odmlka a co bude s blogem dál :) Rozcestník souvisejících článků o Power BI najdete zde http://www.neoral.cz/2016/10/power-bi-rozcestnik.html
Vsuvka autora mimo téma (ale koneckonců je to blog:) )
Po delším výpadku v psaní blogu jsem zpátky a budu opět pravidelně přispívat. I s psaním blogu je to podobné,
jako se vším ostatním. Na „chvíli“ vypadnete a pak se těžko naskakuje. Psaní článků pravidelně je poměrně
časově náročné a když to člověk přičte k práci, rodině a tréninku triatlonu (letošním cílem je Moraviaman na
tratích železného muže v Otrokovicích a to si žádá přípravu). Něco musí jít trochu do pozadí. A trošku jsem se
méně věnoval komunitě. Ubylo článků na blogu a také přednášek bylo o něco méně, než 2016. Promítla se i
lehká motivační krize když několik měsíců čekáte na update, který nepřichází. Novoroční předsevzetí (ano
opravdu v únoru), je opět zamakat na doručování informací ze světa Business Inteligence. Většina článků bude
věnována Power BI. Nechci moc tříštit úsilí. Při rozhvoru na jedné komunitní akci mě inspirovala kamarádka
(tímto Magdu zdravím:) ) Jestli nechci zkusit dát na blog i číslo účtu, že jí v minulosti blog pomohl při hledání
informací. Že kdybych ho tam měl, možná by mi tam i něco poslala. Dlouho jsem o tom přemýšlel a říkám si
nakonec, proč ne. Pokud byste cítili silnou potřebu podpořit mé snahy o doručování novinek a praktických
zkušeností z BI světa. Zde je: 670100-2201291528/6210
Také ho přidám do kontaktní sekce. Nic to ale nemění na tom, že tento blog je nekomereční záležitost. Píši jej
dobrovolně ve volném čase bez nároku na odměnu, jako podporu české a slovenské BI komunity.
Dost bylo vsuvek, pojďme na samotný obsah článku.
Článek
O analýze nákupního košíku jsem měl přednášku na třech konferencích. SQL Saturday v Praze, G2B Teched v 
Brně a Show IT v Bratislavě. Stejné téma, možná lehce jiné pojetí a různá publika. Třikrát a dost. V Praze
vzniknul tento záznam https://www.youtube.com/watch?v=QkMJCW7cjEs takže, pokud Vám to uteklo, můžete
se podívat. Tento článek přináší doprovodné materiály a zdrojové kódy. Co bylo obsahem přednášky pro Ty z 
Vás, co jste ji neviděli.
Proč vlastně tohle téme
Pracuji v Dixons Carphone, což je společnost zabývající se retailem. Analýza toho, co se kupuje pohromadě je
tedy v rámci firmy celkem zajímavé téma. Když se mluví o analýze nákupního košíku běžně, většinou se člověku
vybaví technologie jako Machine Learning, Data mining. Což jsou skvělé přístupy a s tím spojené technologie,
ale ne každá společnost v týmu má lidi, kteří tyto metody a principy ovládají. Hlavní důvod přednášky byl, když
to řešíme my, možná i někdo jiný. Tak proč se nepodělit o svůj přístup a řešení.
Pár bodů k zamyšlení
Můžu a chci sledovat chování zákazníků (myšleno jako konkrétní člověk se jménem, příjmením adresou atd).
První věcí k zamyšlení je o jaké formě prodeje se vlastně bavíme. Online vs. obchod. U online nákupu jsme
schopni jednotlivé zákazníky rozlišit, protože nám tak nějak o sobě musí něco sdělit. Alespoň pokud si chce
zboží vyzvednout :). U nákupu v kamenném obchodě je to složitější. Tam pokud si člověk nevyřídí kartičku na
sbírání bodů zákazníka bez kamerového systému nerozlišíme.
Další faktor je četnost nákupů zákazníka. Asi bude rozdíl, jestli prodáváte potraviny. Nebo třeba elektroniku. U
online obchodů ze dvou nákupů velkých spotřebičů za rok asi hůř budete dělat závěry, než když u jednoho
zákazníka, který pravidelně kupuje deset rohlíků a dva lahváče.
Technologická perspektiva je o tom, jaké technologie máte k dispozici a jaké technologie ovládají vaši
kolegové/zaměstnanci. Neméně důležité je: kdo a jakou formou má získávat ze systému informace. Jestli se
bude jednat o stroj (našeptávač v eshopu), nebo člověk odpovědný za nacenění produktů/marketingové akce
atd.
Chci vůbec ukládat informace o zákazníkovi jako individualitě v BI systému?  V e-shopu se tomu nevyhnu, ale v 
datovém skladu by mi možná stačily informace o transakci. Jaké položky byly pořízeny na jedné transakci můžu
sledovat jak pro eshop, tak kamenný obchod. A je mi „jedno“ jestli se zákazník jmenuje Pepa, nebo Karel, nebo
třeba Unknown (v případě kamenného obchodu). To že v BI citlivé informace nechceme, na to může mít i vliv
nařízení GDPR.
Jaké byly požadavky
Výsledek řešení prezentovaný v tomto blogu je výstupem na základě požadavků byznysu. Ty byly následujcí
  • interaktivní report přístupný uživatelům pro interaktivní analýzu
  • sledování základních KPI pro primární produkt a produktů co se prodali s produktem primárním
  • (attached). Metriky například Částka s daní, Částka bez daně, Marže, Počet kusů a další
  • security model, omezení produktové hierarchie na úrovni primárního produktu (o row level security v 
  • Power BI jsem psal zde http://www.neoral.cz/2016/04/power-bi-role-zabezpeceni.html)
  • možnost měnit vstupní parametry v průběhu analýzy (časové období, kanál prodeje, parametry
  • produktové hierarchie a další)
  • čím dříve to bude, tím lépe
Jaké jsem zvolil technologie a proč
SQL Server jako vrstva která drží surová data, struktury bylo potřeba jen trochu uzpůsobit potřebám
analytického modelu.
Power BI moje volba číslo jedna, když je požadavek na interaktivní report
SSAS (SQL Server Analysis Services) díky svým analytickým možnostem a obavám z výkonnosti řešení a objemu
dat. Dalo by se použít jen Power BI, ale mohli bychom narazit na 1GB limit. SSAS umožňují také možnost dle
potřeby postavit SSRS report, nebo ad hoc připojení přes Excel.
Logický datový model
Schéma hvězda, kde se vše točí kolem prodejů. Možnost analyzovat přes Datum, primární produkt (Product),
související produkt (attached product) a další dimenze.
Dotaz pro získání informací o prodejích
Dochází zde k namnožení záznamů aby na transakci ke každému primary produktu byla vygenerována ještě
Attached část. Ale tak, aby nedošlo k ovlivnění celkového výsledku. (Total sales musí sedět na to co se skutečně
prodalo).
;WITH DATA_CTE AS
(
SELECT
f.CHAIN_KEY
,f.CHANNEL_KEY
,f.TRANSACTION_DATE_KEY
,f.COST_CENTRE_KEY
, f.PRODUCT_KEY
,f.TRANSACTION_KEY
,SUM(f.SALES_INC_VAT) as SALES_INC_VAT
,SUM(f.SALES_EX_VAT) as SALES_EX_VAT
,SUM(f.TAB_MARGIN) as TAB_MARGIN
,SUM(f.UNITS) as UNITS
FROM dbo.UVW_FACT_SALES f
GROUP BY
f.PRODUCT_KEY
,f.TRANSACTION_KEY
, f.CHAIN_KEY
,f.CHANNEL_KEY
,f.TRANSACTION_DATE_KEY
,f.COST_CENTRE_KEY
)
SELECT
/*header*/
p.CHAIN_KEY
,p.CHANNEL_KEY
,p.TRANSACTION_DATE_KEY
,p.COST_CENTRE_KEY
/*primary*/
,p.PRODUCT_KEY
,p.TRANSACTION_KEY
,CASE WHEN p.PRODUCT_KEY = a.PRODUCT_KEY THEN p.SALES_INC_VAT ELSE NULL END as SALES_INC_VAT
,CASE WHEN p.PRODUCT_KEY = a.PRODUCT_KEY THEN p.SALES_EX_VAT ELSE NULL END as SALES_EX_VAT
,CASE WHEN p.PRODUCT_KEY = a.PRODUCT_KEY THEN p.TAB_MARGIN ELSE NULL END as TAB_MARGIN
,CASE WHEN p.PRODUCT_KEY = a.PRODUCT_KEY THEN p.UNITS ELSE NULL END as UNITS
/*attached*/
,a.PRODUCT_KEY AS ATTACHED_PRODUCT_KEY
,CASE WHEN p.PRODUCT_KEY <> a.PRODUCT_KEY THEN a.SALES_INC_VAT ELSE NULL END as ATTACHED_SALES_INC_VAT
,CASE WHEN p.PRODUCT_KEY <> a.PRODUCT_KEY THEN a.SALES_EX_VAT ELSE NULL END as ATTACHED_SALES_EX_VAT
,CASE WHEN p.PRODUCT_KEY <> a.PRODUCT_KEY THEN a.TAB_MARGIN ELSE NULL END as ATTACHED_TAB_MARGIN
,CASE WHEN p.PRODUCT_KEY <> a.PRODUCT_KEY THEN a.UNITS ELSE NULL END as ATTACHED_UNITS
FROM DATA_CTE AS p /*primary*/
LEFT JOIN DATA_CTE AS a /*attached*/
 ON p.TRANSACTION_KEY = a.TRANSACTION_KEY


Trocha DAX výrazů v datovém modelu
Se měla právě postarat, aby byla zachována správnost výsledků. Dva příklady
Primary Sales Ex Vat:= CALCULATE(SUM(‘Sales’[SALES_EX_VAT]);all('Attached Product’))
Daný vzorec říká, že metrika má ignorovat dimenzi Attached Product.
Attached Sales Ex Vat:= CALCULATE(SUM(‘Sales’[ATTACHED_SALES_EX_VAT]);ALLSELECTED('Product');EXCEPT('Attached Product';'Product'))
Attached metriky mají ve výpočtu ignorovat dimenzi primární produkt. Attached je to, co vznikne po množinové
operaci Except mezi Attached Produkty a produkty primárními v daném kontextu.
Ukázky z hotového reportu uvidíte nejlépe na videu. Stejně jako popis případných nejasností. Těžko vložit
veškeré myšlenkové pochody a několik týdnů vývoje a ladění do pár řádků v blogu. Navíc tenhle je už dlouhý.
Materiály
Nicméně, pokud byste se rádi pokusili o reverse engineering, máte možnost. Řešení prezentované veřejně na
konferencích jsem připravil na demo databázi Contoso Retail DW. Ke stažení
zde: https://www.microsoft.com/en-us/download/details.aspx?id=18279
Contoso prodává elektroniku stejně jako Dixons, takže nejvhodnější kandidát. Poté jsem musel vytvořit pohledy,
které názvy sloupců a struktury učesaly do stejné podoby, jako byly nad daty produkčními.
Pohledy, stejně jako SSAS Tabular projekt a prezentace ze všech zmiňovaných konferencí jsou ke stažení
zde https://drive.google.com/open?id=1VbliCEwxQbPdyZRwmA7Lz8Q-QUhLOqzS
Závěr
Po delší odmlce jeden praktický článek na téma požadavky, výběr technologie a řešení. Nejdu příliš do detailu.
Pokud si to chcete raději shlédnout, koukněte na záznam ze SQL Saturday
Praha https://www.youtube.com/watch?v=QkMJCW7cjEs Veškeré materiály jsou k dispozici na linku
zde https://drive.google.com/open?id=1VbliCEwxQbPdyZRwmA7Lz8Q-QUhLOqzS

Ústřední myšlenkou je, že výběr technologie je dán požadavky na řešení. Analýza nákupního košíku se dá
provádět i s pro širokou SQL komunitu s dostupnými nástroji, jako je SQL Server a Power BI.