Készülök a jövő heti Önkiszolgáló BI workshopra és felmerült a következő probléma:

Szeretnénk létrehozni ügyfeleinkből egy olyan csoportot, amelybe csak a jó ügyfelek tartoznak. Tegyük fel, hogy a jó ügyfél az, akinek a jövedelme > 200000 Ft, az vásárlásainak száma > 2 és szeme színe = kék

Az ilyen típusú ügyfélcsoportot a PowerPivottal háromféleképpen is létre tudjuk hozni:

-          nevesített halmazokkal (Azokat válogatjuk bele a halmazba, akik a feltételnek megfelelnek)

-          számított oszloppal (létrehozunk az oszlopalapú adatbázisban egy jó ügyfél? számított oszlopot amibe I-t írunk, ha megfelel a feltételeknek, N-et ha nem és utána szűrünk a riporton az I-sekre)

-          Importálás közben a relációs motorral kiszámítatva (Importálás előtt SQL oldalon hozzuk létre a jó ügyfél? oszlopot és a PowerPivotban csak szűrünk rá)

Mindhárom megoldás jó, de teljesítmény szempontjából (Lekérdezés teljesítménye szempontjából) nagyok a különbségek. A legjobb az „Importálás közben a relációs motorral kiszámítatva” aztán következik a „Számított oszloppal” és végül a „nevesített halmazokkal”

Sajnos a megvalósítás egyszerűsége szempontjából viszont pont fordított a sorrend. Ha a felhasználóink informatikai affinitása minimális, akkor az Excelen (Pivot tábla) keresztül a varázslóval építsük fel a nevesített halmazokat. Ha SQL-hez nem értenek de az Excelben tudják használni az (If, then, else) függvényeket, akkor számított oszlopot használjuk a PowerPivot adatbázisában. Ha pedig értenek annyira az SQL-hez, hogy meg tudjanak fogalmazni egy CASE-es lekérdezést, akkor import során számítassuk ki a szűrőfeltételeket.

Ha tehát a teljesítmény a fontos, akkor importálás előtt hozzuk létre az ügyfélcsoportot, ha az egyszerű kezelhetőség, akkor a pivot táblán keresztül hozzuk létre a nevesített halmazt.

OLAP-os fejlesztéskor sokszor felmerült a kérdés, hogy hol hozzuk létre a számított mezőket: a kocka alatt lévő relációs táblákban vagy a kockában magában? OLAP oldalon az általunk használt legjobb gyakorlat az volt, hogy ha a számítás elvégezhető aggregálás előtt, akkor a relációs nézetben a helye! Mondok egy példát: Ha van egy nettó Ft és egy áfa összege FT oszlopunk a relációs táblában, akkor a bruttó Ft-t nem az OLAP oldalon számoltuk, hanem a relációs táblában, vagy az OLAP és a relációs tábla közti nézetben.

Miért? Mert a csillagsémát relációs riporting eszközök is használhatják, így nekik is szükségük lehet rá.

Mi a helyzet a PowerPivottal? ott is igaz a fenti mondás?

A PowerPivot esetében már nem ilyen tiszta a kép. Azt ugyanis nem biztos, hogy IT-sok fejlesztik és nem biztos, hogy módosítani tudják az üzleti felhasználók a forrást, nem biztos hogy van alatta egy csillagsémás adattárház, … Így egyáltalán nem biztos, hogy ez opció. De tudnunk kell arról, hogy a PowerPivot sokkal jobban tudja tömöríteni a relációs oldalon előre kiszámolt mutatókat, mint az általa betöltés közben számítottakat. Így technikai értelemben a sorszintű számításoknak a relációs táblában/nézetben van a helyem de üzemeltetési és egyéb szempontok miatt nem biztos, hogy oda tudjuk/ kéne tenni

Nemrég PowerPivot oktatást tartottam és a felhasználók egy részénél „furcsán” (olyan Excel 2003-as formában) jelent meg az PowerPivot menükészlete. Megmondom őszintén ekkor láttam életemben először ilyet és tanácstalanul álltam a probléma előtt. Most már tudom, hogy mindez a Windows XP operációs rendszernek volt köszönhető, és most már tudom azt is, hogy létezik egy olyan dokumentum, amely leírja az XP-s és Windows 7-es office 2010-es menüpontok közti kapcsolatot. Mutatom:

Az önkiszolgáló BI workshopon azzal fogom kezdeni, hogy rákérdezek: Használ valaki XP-t? És annak aki igennel válaszol adok egy kinyomtatott XP menü – Office 2010 szalag megfeleltető lapot.

További infó:

-          The PowerPivot UI in Windows XP

Mutatom hogy lehet összetett, több dimenziót érintő szűrést megvalósítani az Excel KOCKA.HALM() függvényével:

=KOCKA.HALM("PowerPivot Data"; "CrossJoin({[Dátum].[hónap].[január]},{[Termék].[Termékcsop].[A]})")

Vagy ahogy most tanultam az Excel kocka függvény konvertálójától:

=KOCKA.TAG("PowerPivot Data";{"[Dátum].[hónap].[január]"\"[Termék].[Termékcsop].[A]"})

Gyakran lesz rá szükség, ha amorf riportok készítésekor be akarjuk nyomni a szűrőfeltételeket a táblázat fejlécébe.

Aligha. Csak a fordítók magyarították az ORDER kulcsszót „Rendelés”-re, a MEMBERS-t tagokra és így tovább:

A példák úgy helyesek ahogy az angol nyelvű oldalon láthatóak:

A hibát jeleztem.

Forrás: KOCKA.HAML függvény

Ilyen kérdést csak egy OLAP-os tud feltenni, aki hozzászokott, hogy egy attribútumnak van minimum egy kód és egy megnevezés párja. Azaz például a vevő attribútumnak van egy vevő kódja és egy vevő megnevezése. Csakhogy a fenti kérdésnek az oszlopalapú adatbázisokban nincs értelme. Ott ugyanis nincsenek attribútumok, csak oszlopok. Ha betöltjük az adatbázisba a kódoszlopot és a megnevezés oszlopot, akkor – OLAP-os logikával – létrehozunk két attribútumot: A vevőkódot és a vevő megnevezését.  Az oszlopalapú adatbázis-kezelő pedig mindkét „attribútumnak” ad egy belső kulcsot (indexet).

Tehát: Ha technikai - , vagy a 2012-es PowerPivot verziótól kezdve rendezési - szempontból nincs rá szükség, akkor teljesen felesleges betölteni az attribútumok jelentés nélküli természetes kulcsait az adatbázisba, mert csak a helyet foglalják. Elég csak a megnevezéseket betölteni, mert az oszlopalapú adatbázis-kezelő majd ad neki egy kulcsot és belülről úgyis ezekre fog hivatkozni.

Az SQL Server 2012 RC 0-val párhuzamosan megjelent a PowerPivot for Excel RC 0-ás változata is. Mind a 32, mind a 64 bites verziók letölthetőek a Download SQL Server 2012 PowerPivot for Excel 2010 RC0 című oldalról. Lesz rendezés, KPI támogatás és még egy csomó minden amiről természetesen majd beszámolok itt, vagy a BI projekt blogban

Nagyon régen megvettem már. Emlékszem, hogy annak idején nem volt türelmem kivárni amíg megérkezik a papíralapú változat és megvettem elektronikusan is. Kiolvasni azonban csak nyáron tudtam L

A PowerPivot for Excel 2010 című könyv az Excel felhasználóknak szól s mint ilyen, meglehetősen kevés technikai részletet tartalmaz. Felépítése logikus, nyelvezete egyszerű, tartalma olvasmányos. Nekem kicsit hiányoztak belőle a technikai részletek, a háttér információk, de az általam ismert PowerPivot könyvek közül messze ez a legjobb. Ha egyet javasolhatnék csak biztos ez a könyv lenne az.

Felírom magamnak ide, hogy

Az oszlopalapú adatbázis mérete elsősorban az adatbázisban tárolt KÜLÖNBÖZŐ (distinct) elemek számától függ.

Ez az egyszerű mondat nagyon sok mindent megmagyaráz. Lehetne rajta finomítani, kivételekkel megspékelni, de lényeg ez.

A múltkor elmélkedtem a BI projekt blogon, hogy OLAP adatbázis használata esetén vajon melyik a jobb adatmodell: a csillagsémás, vagy a normalizált hópehely, és akkor arra jutottam, hogy MS OLAP használata esetén jobb a csillagsémás. De mi a helyzet a PowerPivot oszlopalapú adatbázis-kezelőjének használata esetén?

Nos. Ahogy az a PowerPivot Data Modelling for Performance című cikkből kiderül, a Microsoft oszlopalapú adatbázis-kezelőjének használata esetén is jobb teljesítményt ad a csillagsémás adatmodell a normalizált hópehely adatmodellel szemben. Helyszükségletben nincs nagy különbség a csillagsémás és a normalizált adatmodell között (köszönhetően a tömörített tárolásnak) ugyanakkor a csillagsémás adatmodell rövidebb válaszidőkkel szolgálja ki a lekérdezéseket.