Érdekes dokumentum (white paper) jelent meg a héten „Designing SQL Server 2005 Analysis Services Cubes for Excel 2007 PivotTables” címen. A dokumentum bemutatja mindazon Analysis Services szolgáltatásokat, amelyeket érdemes figyelembe vennünk, ha Excel 2007-et használunk az Analysis Services kockák riportálására.

A dokumentum nem mutatja be az Excel 2007 összes üzleti intelligecia szolgáltatását. Csak azokra koncentrál, amelyeket az Analysis Services kocka tervezésénél célszerű figyelembe venni.

Ízelítő a dokumentum tartalmából:

• szerveroldali formázások
• Display Folders (measure-ök, hierarchiák csoportba rendezése)
• Named Sets
• Member properties
• Dátum alapú beépített szűrések (Ma, tegnap, előző hónap, …)
• Actions,
• KPI,
• Nyelv - váltás (translation)
• ...

Felhasznált irodalom

• Designing SQL Server 2005 Analysis Services Cubes for Excel 2007 PivotTables

A Microsoft 1998-ban tette be a lábát az OLAP adatbázis kezelők piacára, amikor SQL Server 7.0-ás termékcsaládjába becsomagolta az 1996-ban vásárolt OLAP motort. Az OLAP Services névre, majd Analysis Services-re keresztelt OLAP szerver egyre jobban fejlődött.

Az Analysis Services verzióról verzióra egyre robosztusabbá vált és egyre több üzleti elemzést támogató szolgáltatásokat kapott. Sokáig azonban nem rendelkezett sem a lekérdezést, sem a riportingot, sem az elemzést támogató front-end alkalmazással.

Ezt használták ki azon gyártók, akik elkezdtek saját front-end alkalmazásokat fejleszteni az Analysis Services-hez. (Ilyen volt például a ProClarity, a Novaview, vagy a hazai fejlesztésű OLAPNaviGo)

A 2000-es verzióhoz már több mint 20 üzleti intelligencia front-end alkalmazás létezett. Ha egy vállalat úgy döntött, hogy Analysis Services alapokon valósítja meg üzleti intelligencia rendszerét, akkor bizony ki kellett értékelnie a front-end alkalmazások egy részét is, és ezek közül ki kellett választania a vállalat számára a legmegfelelőbbet.

Mára már más a helyzet. Tavaly óta, - amikor is a Microsoft felvásárolta a ProClarity-t– már a Microsoftnak is van saját front-end alkalmazása. Sőt. Az Excel 2007 pivot tábláját is felhozták olyan szintre, hogy az már önmagában is megállja a helyét, mint önálló OLAP front-end.

De a kérdés továbbra is megmaradt: Milyen front-endet válasszon az Analysis Services fölé? Ma már választhat 2 Microsoft termék közül is, de továbbra is nyitva áll az idegen szállító termékének választási lehetősége is.

A jó döntéshez jó információkra van szükség, ami továbbra is szűkösen áll rendelkezésre. Itt van példának a „Pivot Table Data Crunching for Microsoft Office Excel 2007” című könyv, amely több, mint 300 oldalon keresztül mutatja be az Excel 2007 Pivot tábláját, és ebből csak 13 oldal foglalkozik az Excellel, mint üzleti intelligencia front-enddel. (És ebben benne van a „What is OLAP” rész is... )

Épp ezért úgy döntöttem, hogy készítek egy módszertan amely alapján össze lehet majd hasonlítani az üzleti intelligencia front-endeket. Megvizsgáltam, hogy milyen szempontoknak kell megfelelnie egy jó BI front-endnek és ezek alapján összeállítottam egy 123 szempontot tartalmazó módszertant.

Az elkészült módszertan 123 szempontjának egy részét felhasználva összehasonlítottam az Excel 2007-et és a ProClarity-t. Megvizsgáltam, hogy az egyes termékek hogyan felelnek meg a műszaki, gazdasági és döntéstámogatási szempontoknak és a kapott eredményt belegyúrtam egy 30 oldalas tanulmányba.

A tanulmányt a BI és adattárház blog hírlevelére feliratkozottak már megkapták. Ha Ön is szeretné megkapni, akkor iratkozzon fel most a BI és adattárház blog hírlevelére (Keresztnév és e-mail cím elégséges) és azonnal megkapja az „Excel 2007 vagy ProClarity?” című BI front-end összehasonlító tanulmányt.

Az Excel 2007 alapú BI reporting rendszer bevezetése című tanulmánybanírtam néhány szempontot, amelyet figyelembe kell vennie, ha Excel 2007-et szeretne a felhasználók kezébe adni üzleti intelligencia front-endnek. Az egyik ilyen szempont egy központi connection string kezelő rendszer kialakítása volt, amit ott be is mutattam. Egy dolgot azonban nyitva hagytam: Hogyan lehet rábírni az Excel 2007-et, hogy használja is a központi connection stringeket. Ez következik most.

Ha egy kicsit kutakodunk, akkor a kapcsolat tulajdonságai között, a definíció fülön találunk olyan jelölőnégyzetet, hogy „Minden esetben kapcsolatfájl használata” (Always use connection file)

Remek. Pont ez kell nekünk. Már be is jelölöm, hiszen pont arra van szükségünk, hogy az Excel ne a saját maga által bekeselt connection stringet használja, hanem minden esetben a kapcsolat fájlt. (Azt a fájlt, ami a connection stringet tartalmazza) Ám a következő figyelmeztetést kapom:

The connection in this workbook will no longer be identical to the connection defined in the external file located at … (A munkafüzetben lévő kapcsolat különböző lesz a külső fájlban definiált kapcsolattól)

Igen, pont ezt szeretném. Majd folytatódik a figyelmeztetés:

The link to that external file will also be removed. (A külső fáljra mutató hivatkozás is törölve lesz)

Mi? Akkor honnan fogja tudni az Excel hogy hol van a connection fájl? Sehonnan…

Sokat kerestem a megoldást az Interneten arra, hogy az Excel 2007 mindig a kapcsolati fájt használja, de nem találtam. Aztán rájöttem, hogy a megoldást nem a kapcsolatfájl tulajdonságai között kell keresnem, hanem a kapcsolatfájl létrehozásánál. Ott ugyanis létezik egy „Mindig ezzel a fájllal kísérelje meg az adatfrissítést” nevű opció, aminek használata esetén az Excel 2007 a mindig a kapcsolatfájlt fogja használni.

Összefoglalás: Egy központilag menedzselt connection string rendszer sok-sok energiát és felesleges felhasználói kommunikációt takarít meg Önnek. Használja. Az Excel 2007 partnere lesz ebben, ha a kapcsolatfájl létrehozásánál megadja, hogy az Excel „Mindig ezzel a fájllal kísérelje meg az adatfrissítést”

Sikeres bevezetést!

Most a család után utazom és úgy döntöttem, hogy kocsi helyett inkább vonattal megyek. Igaz, hogy így hosszabb az út, meg vonatszagú lesz az ember mire megérkezik, de legalább van ideje olvasni és írni. Ahogy így utazgattam eszembe jutott az első téma, amiről már 2 éve szeretnék cikket írni. Elő a laptop s már írom is:

A harmadik dimenzió.

Bár a téma több mint két éves, a bemutatandó probléma mind üzleti, mind technológiai szempontból érdekes. Érdekes azoknak akik, olyan üzleti problémákat kívánnak megoldani az Analysis Services segítségével, mint egy háromdimenziós grafikon előállítása.

De itt nem a térbeli „háromdimenziós” grafikon előállítására gondolok. Ha egyszer meg fogom írni a „Hogyan válasszunk tanácsadó céget PowerPoint prezentáció alapján” című cikket, (persze ahogy magam ismerem soha) akkor abban azt fogom Önnek tanácsolni, hogy kerülje az olyan szállítókat, akik az alábbihoz hasonló gyönyörű térbeli grafikonokkal hirdetik technológiájuk jóságát.

S, hogy miért? Mert a térbeli grafikonokból nem lehet következtetéseket levonni, hiszen nem lehet belőlük leolvasni az arányokat és sokszor az elöl álló oszlop eltakarja a mögötte állókat. Persze van amikor pont ez a cél, de az már nem az analízis témakörébe tartozik.

Ennyi kitérő után térjünk vissza a háromdimenziós grafikonokhoz problémájához.

Háromdimenziós grafikonok üzleti jelentősége.

A háromdimenziós grafikonok üzleti jelentőségét egy konkrét példán keresztül fogom bemutatni. A 30-as évek elején megjelent az USA-ban egy tanulmány mely Minesota állam árpa terméseredményeit mutatta

1. Termékcsoport (10 árpafaj)
2. Év (1931, 1932)
3. Gazdaság (6 gazdaság)

Bontásban. (tipikus többdimenziós (OLAP) probléma)

A tanulmány később bekerült egy statisztikai könyvbe, amely aztán híressé tette és adatait sokan használták jellemzően új statisztikai módszerek bemutatására. Mígnem a 90-es években valaki rá nem eresztett egy speciális 3 dimenziós grafikont, az úgynevezett Trellis display-t. Az eredmény nagy meglepetés volt, és erről még írok később, de előtte nézzük meg, hogy hogyan is néz ki egy ilyes speciális (Trellis) grafikon:

Trellis display

A grafikon 6 panelből áll, mindegyik panel egy-egy site terméseredményit mutatja idő és árpafajta bontásban. Ami meglepő, hogy Morris telkét leszámítva mindegyik telek terméseredménye 1932-ben szignifikánsan nagyobb volt, mint 1931-ben. És ami még fontosabb, hogy Morris 1931-es terméseredménye kísértetiesen hasonlít a többiek 1932-es terméseredményéhez. Vajon valamilyen különleges természeti esemény következett be Morris telkén mindkét évben vagy csak egész egyszerűen felcserélték a számokat?

Miután megvizsgálták a körülményeket (időjárás, katasztrófák, stb…) kiderült, hogy a hiba az adatokban van. Egész egyszerűen felcserélték az éveket, és ezt majd 60 évig nem vették észre! Aztán valaki ráeresztett egy speciális háromdimenziós grafikont az adatsorra, amely egyből felszínre hozta a hibát.

Nézze meg a grafikont, még egyszer és valószínűleg ön is látni fogja! (Néha egy kép többet ér 1000 szónál.)

Más

Amikor az Excel vagy ProClarity című üzleti intelligencia front-end összehasonlító tanulmánytírtam, külön megvizsgáltam, hogy az Excel és a ProClarity milyen adatvizualizációs szolgáltatásokat nyújtanak és ezen belül milyen grafikon készítési támogatással rendelkeznek.

Kíváncsi voltam arra is, hogy az Excel vagy a ProClarity hogyan képes megjeleníteni egy ilyen, a fenti példában szereplő 3 dimenziós grafikont. A kutakodás eredménye az lett, hogy sehogy nem. Sajnos a fenti Trellis display típusú grafikont egyik eszközzel sem tudtam elkészíteni. De a helyzet azért nem katasztrofális.

Excel

Az Excellel a fenti példában szereplő trellis display-hez hasonló grafikont vonal diagrammal tudtam készíteni. Az eredmény:

ProClarity

Az Excelben elkészített grafikont a ProClarity-vel is el tudtam készíteni. Íme

Ha a fenti Excellel, vagy ProClarity-vel készített grafikonokat 90 fokkal elforgatjuk, akkor megkapjuk a trellis displayt. A ProClarity egyébként a háromdimenziós grafikonok területén annyival tud többet, mint az Excel, hogy segítségével készíthetünk olyan háromdimenziós (nem térbeli) torta diagramokat, mint az alábbi:

Bár ez a grafikon típus a nem alkalmas arra, hogy kiemelje az árpahozamok felcserélését, de remekül szemlélteti, hogy hogyan ábrázolhatjuk adatainkat 3 dimenzióban (nem térben)

MDX

És a végére egy kis csemege. Tudta Ön, hogy az MDX támogatja a háromdimenziós lekérdezést?

Sok-sok évvel ezelőtt olvasgattam az MDX szabványt és meglepődve vettem észre, hogy nem csak két tengelyt (dimenziót) lehet meghatározni egy lekérdezésekben, hanem hármat is:

Select

      [Year] oncolumns,

      [Site] onrows,

      [Species] onpages

from [Barley Yield]

Az már mindenkinek triviális, hogy az on rows, illetve on columns kifejezéseket használjuk arra, hogy meghatározzuk melyik dimenzió jelenjen meg soron illetve oszlopon, de mire használhatjuk az on pages kifejezést? Ha eddig teljesen elolvasta a cikket, akkor már sejtheti a választ: háromdimenziós grafikonok készítésére. Persze ennek kihasználásához már saját front-end alkalmazást kell fejlesztenie, de jó ha tudja, hogy az MDX ebben támogatni fogja.

Update 2009. január 14. Most nézem, hogy a PerformancePoint Planning Excel addin kliens alkalmazása is pont ilyen háromdimenziós (on columns, on rows, on pages) MDX lekérdezésekkel kérdezi le az OLAP szervert...

Update 2008. március 6. Egy kedves olvasóm (Sándor Imre) jelezte, hogy az Excellel is elő lehet állítani trellis display-t, vagy más néven dot plot grafikont. Igaz, hogy ehhez makrót kell írni, vagy le kell tölteni egy Excel Add-int, de meg lehet csinálni. Imre meg is csinálta és elküldte nekem az eredményt. íme:

dot plot grafikon Excelben

A Dot Plotter add-in, amelyikkel a grafikon készült letölthető Jon Peltier oldaláról. És bár Excel 2007-tel még nem fut, de Excel 2003-mal tökéletesen használható. Köszönet Imrének még egyszer.

Itt vannak ezek az Excel fájlok, amelyeket be kell tölteni az adattárházba, és amelyektől egy adattárház fejlesztő vagy üzemeltető folyamatosan retteg. Vajon jól töltötte ki az üzleti terület őket? A számok helyére tényleg számokat írtak? Véletlenül nem szúrtak be üres sorokat a tábla közepére? És még sorolhatnám, de ezekről már olvashatott az Excel fájlok betöltésének buktatói című bejegyzésben.

Tényleg röhejes, de ezek az apró Excel fájlocskák azok, amelyek legjobban veszélyeztetik a betöltés sikerességét. Persze kikerülhetjük őket egy nagy projekten, ahol a projekt elbírja egy olyan alkalmazás kifejlesztésének költségét, ami lehetővé tesz az üzleti felhasználóknak, hogy a forrásrendszerrel nem rendelkező adatokat ne Excelbe, hanem az erre a célra kifejlesztett alkalmazásba rögzítsék, de egy kis BI projekt ezt nem bírja el. Marad az Excel.

Nem elég hogy attól kell rettegnünk, hogy az üzleti felhasználó nehogy elírjon valamit az Excelben, itt van még ez a Jet OLE DB provider aki szintén rátesz egy lapáttal. A Jet OLE DB provider ugyanis megpróbálja kitalálni helyettünk az Excel táblák oszlopainak adattípusait. Ez néha azonban nem sikerül neki, hiszen az eljárás úgy működik, hogy kiolvassa az adott oszlop első 8, azaz nyolc sorát és abból eldönti a teljes oszlop adattípusát. Ha az első nyolc sor szöveget tartalmaz, és azok egyike sem haladja meg a 256 karakternyi hosszat, akkor beállítja azt 255 hosszú unicode stringre

Ekkor jövünk mi adattárház fejlesztők, akik be akarják olvasni az adatokat az Excelből és létrehozunk egy új Integration Services adatbetöltő csomagot. A betöltő első feladata az lesz, hogy felolvassa az Excelből a sorokat és bepumpálja őket a memóriába, majd kitegye őket egy adatbázisba. El is kezdi böcsülettel a munkáját. Ez első 8 sorral megbirkózik, hiszen azok tartalmát analizálta. De mi történik ha a 9. sor 255 karakternél hosszabb? Dob egy hátast és leáll az adattárház betöltése. (Megjegyzem teljesen jogosan, hiszen az első 8 sor alapján csak 255 karakterhosznyi területeket foglalt le neki a memóriában, ahová a 256 hosszú szöveg már nem fér el)

Advanced editor

Jól felkészült adattárház fejlesztők ilyenkor rohannak az advanced fülre és kézzel átírják a memóriába belépő adatok típusát egy nagyobb adattípusra. De nem megy. Nem megy, mert használjuk az SSIS beépített hibás rekord átirányítóját, (OLE DB Destination Error Output) aminek adattípusát nem tudjuk megváltoztatni. (A hibaág is pont úgy viselkedik, mint a betöltés során használt memória, tehát az is 255 hosszú, és oda se tudja kipumpálni a 256 hosszú mezőt

Nem kell hibalista

Persze megszüntethetjük a hibakezelést és mondhatjuk, hogy ne irányítsuk át a hibás sorokat egy hibaállományba (és ekkor meg is oldódna a probléma), de akkor szegény adattárház üzemeltetőnek kéne kitalálni, hogy melyik sor nem ment be az adattárházba. Na ekkor írnánk alá frissen épített adattárházunk halálos ítéletét.

Verjük át a Jet OLE DB provider-t!

Hibakezelés tehát kell. Mi mást csinálhatnánk? Verjük át a Jet OLE DB provider-t! Az első betöltéskor töltsük fel az oszlopokat 255-nél hosszabb szövegekkel és írjuk meg erre a fájlra a betöltőt. Mit csinál a Jet OLE DB provider? Analizálja a kialakult helyzetet, és rájön, hogy kevés lesz neki a 255 hosszú hely a memóriában. Hopsz. Át is írja rögvest NText-re, amibe már minden belefér.

Bár ez a megoldás elsőre elég balkáninak tűnik (és lesz is egy jobb), de sajnos csak ez az üdvözítő út létezik arra, hogy explicit határozzuk meg azon adattárház töltő SSIS csomagok adattípusát, amelyek használják a hibás sorok átirányítását hibalistára. Ha nem tudjuk előre, hogy az Excelbe beírt adatok meg fogják-e haladni a 255-ös hosszt, de gyanítjuk, hogy igen, akkor bizony ezt kell tennünk. Ha úgy gondoljuk, hogy az Excelekben tárolt adatok hosszának maximuma nem fog eltérni az Excelben aktuálisan tárolt adatok hosszának maximumától, akkor van más megoldás is.

Túrjunk bele a registry-be

Bár a registry matatástól mindenki fél, azt kell hogy mondjam, hogy ez a hivatalosan támogatott útja annak, hogy a Jet OLE DB provider működését megváltoztassuk. A registry-ben ugyanis megadhatjuk azt, hogy mekkora legyen az a minta, amit a Jet OLE DB provider letapogat az adattípus meghatározásához. Ez az érték alapértelmezettként 8 sor. Ezt felülírhatjuk 0-16 ig, ahol az 1-től 16-ig terjedő számok határozzák meg a letapogatandó sorok számát, tehát a 16 az 16 sort jelent. A nulla pedig azt jelenti, hogy a Jet OLE DB provider az adattípus meghatározásához kb. 16000 sort fog beolvasni. (Nem tudom a pontos számot, mert nem találom meg az interneten, de nagyságrendileg ennyire emlékszem)

A minta nagyságát, amit a Jet OLE DB provider vizsgál az adattípus meghatározásához az itt leírt módon változtathatjuk meg a registry-ben

Összefoglalva:

Mivel az Excel fájlokban tárolt információknak nincs rögzített adattípusa és hossza, mint mondjuk egy táblának, ezért a Jet OLE DB provider megpróbálja kitalálni azt. Mintát vesz az oszlop első 8 sorából és az ezek alapján kikövetkeztetett adattípust adja vissza az Integration Services-nek. Az Integration Services hibaága ezt az adattípust kőbevésettnek tekinti, és ennek megfelelően készíti fel saját memória területeit az adatok befogadására. Ha a Jet provider rosszul határozta meg az adattípust, akkor a betöltés le fog halni.

Hogy ezt elkerüljük, két dolgot tehetünk:

1. Megnöveljük a minta méretét, amit a Jet provider letapogat, és így megnöveljük a valószínűségét a helyes adattípus eltalálásának
2. Gondoskodunk róla, hogy a minta tartalmazzon egy olyan adatot, amely reprezentálja a teljes oszlopot, így biztosra mehetünk abban, hogy a Jet provider helyesen határozza meg az adattípust

Kapcsolódó anyagok:

• Miért importál NULL sorokat a DTS az Excelből?
• Excel fájlok betöltésének buktatói - és hogyan kerülje el őket?

Egy érdekes dolgot tapasztaltam nemrég az egyik ügyfelemnél: A kontrollerek valahogy teljesen máshogy, nekünk szokatlan módon számolták a tény terv eltérést. Mindjárt megmutatom hogy hogyan, de előtte essen néhány szó arról ahogy rendszerint számoljuk.

Ha tervet és tényt kell összehasonlítanunk, akkor rendszerint a tervből kivonjuk a tényt, és megkapjuk azt, hogy mennyivel vagyunk elmaradva, vagy mennyivel teljesítettük túl a tervet. Azt, hogy költségekből, vagy bevételből teljesítettük túl a tervet már nem vizsgáljuk: Ha 100 forinttal teljesítettük túl a bevételt annak örülünk. Ha 100 forinttal teljesítettük túl a költségtervet, annak már nem.

Agyunkban tehát átfordítjuk, hogy ha a tény 100 forinttal nagyobb mint a terv, akkor az a bevételek esetén jó, a költségek esetén már nem. Mutatom:

Tény/Terv eltérések számolása a mutató jelentésétől függetlenül

A -60 millió eltérésnek bevétel oldalon nem örülünk, ahogy a +50 milliónak sem a költségoldalon.

Nem mindenki gondolkozik így ahogy mi. Az egyik ügyfelem kontrollere például azt mondta, hogy nem akarja a döntéshozókra bízni az átkódolást.

„Szeretném, ha a döntéshozó a riportra ránézve egyből látná, hogy hol van a probléma"

És ennek megfelelően máshogy számította a terv tény eltérést. Azt mondta, hogy „ami pozitív, annak örülni kell, ami negatív annak nem. Függetlenül a mutató tartalmától"Íme a fenti riport az ő gondolkodásmódjuknak megfelelően:

Tény/Terv eltérések számolása a mutató jelentésétől függően

Mint láthatja, a terv és tény eltérését nem egyféleképpen számolják. Nem is Tény/Terv eltérésnek hívják, hanem Jobb/(Rosszabb) -nak és mindig úgy számolják a mutatót, hogy annak eredménye pozitív értéket mutasson, ha örülni kell neki és negatívat, ha nem.

Jó vagy rossz ez a fajta megközelítés? Döntse el Ön. De a szemléletmód, ahogy ezek a kontrollerek gondolkodnak mindenképpen előremutató.

Úgy tálalják az információt a döntéshozók elé, hogy azok egyből ki tudják szűrni azokat a pontokat, ahol be kell avatkozni. Nem kell dekódolni, nem kell keresgélni és nem azon kell gondolkodni, hogy melyik eltérés okozhat gondot. Ami negatív az rossz. Pont. És egy egyszerű szűréssel kiválaszthatják az összes olyan mutatót, amely az adott hónapban nem érte el a kívánt szintet.

Más. Holnap lesz az OpenSource BI konferencia. Remélem találkozunk.

Felkerült a CodePlex oldalára egy ingyenesen letölthető nagyon hasznos kis Excel bővítmény, amely segítségével kalkulációkat (számított mezőket) szúrhatunk a Pivot táblába, megnézhetjük az Excel által összeállított és az Analysis Services-nek elküldött MDX lekérdezéseket, átírhatjuk az Excel alapértelmezett beállításait, és ami a legfontosabb: megjeleníthetjük és kereshetünk a kocka metaadatai között.

A most következő cikkben átfutjuk a bővítmény fontosabb szolgáltatásait és beszélünk egy kicsit arról is, hogy mire használhatóak, miért fontosak ezek.

Néhány szó OLAP PivotTable Extensions bővítményről

Az OLAP PivotTable Extensions egy Excelbe épülő bővítmény (Add-in). Telepíteni külön kell. Telepítése után jobb egérrel kattintva a pivot tábla területén elérhetővé válnak az OLAP PivotTable Extensions funkciói. Ezek:

Saját számított mező beszúrása

Bár úgy emlékszem az Analysis Services már a 7.0-ás változat óta támogatja az úgynevezett session calculated membereket, de Excelből eddig nem volt lehetőségünk ezen „saját" számított mezők létrehozására. Beszúrni persze beszúrhattunk Excel függvényeket tartalmazó számításokat a pivot tábla szélére, de ezek az első frissítéskor felülíródtak.

Az OLAP PivotTable Extensions bővítmény lehetőséget biztosít a felhasználóknak, kontrollereknek, hogy saját számított mezőt hozzanak létre, amely pont úgy viselkedik mint egy a kockában létrehozott számított mező. (Azzal a különbséggel, hogy csak a létrehozója látja) Lehet rá szűrni, lehet őket rendezni, fel lehet tenni lapozó területre, stb.

Sajnos a bővítmény nem tartalmaz semmilyen segédeszközt a számított mezők létrehozásához. Saját számított mezőt létrehozhatunk a measure és más dimenziókban is, de mindent kézzel, és az MDX szintaktikának megfelelően kell megadnunk.

A saját számított mezők létrehozásakor a háttérben egy session calculated member-t generál az Excel

MDX megtekintése

Hányszor, de hányszor kérdezték már tőlem, hogy hogyan lehet megtekinteni azt az Excel által összeállított MDX lekérdezéseket. Hát most már az fogom mondani, hogy telepítsék az OLAP PivotTable Extensions bővítményt. Ennek segítségével ugyanis megtekinthetik az Excel által generált MDX-et:

OLAP PivotTable Extension - MDX lekérdezések megtekintése

A pivot tábla alapértelmezett beállításának megváltoztatása

Mit összebrékeltünk korábban, hogy az Excel jelenítse meg az OLAP adatkockák számított mezőit. Próbálkoztunk egy csomó mindennel, de nem sikerült. Maradt a tréning, ahol a felhasználók szájába kellett rágni, hogy mikor bekapcsolják az Excelt, az első lépésük az legyen, hogy a számított mezők elrejtését kapcsolják ki. Az Excel 2007 ugyanis alapértelmezettként elrejti az Analysis Services kockák számított mezőit.

OLAP PivotTable Extension - Az alapértelmezett elrejtés kikapcsolása

Ez a hiba már az Excel béta fázisában napvilágot látott, mégsem történ semmi (pedig egy alapértelmezett funkció átbillentése YES-ről NO-ra nem hiszem, hogy nagy feladat lenne) Most azonban hála a CodePlex-es fiúknak, felül tudjuk írni ezt a hibás gyári beállítást.

Leírások megjelenítése

Az egyik legkedvesebb szolgáltatása a bővítménynek! Lehetőséget biztosít a kocka, a mutatószámok, számított mezők, dimeneziók, stb. leírásának megtekintésére és megkeresésére.

Hiába tároltuk a description mezőkbe az üzleti metaadatokat, mint például egy számított mező képletét, egy mutatószám alternatív megnevezéseit, ha azt a felhasználók nem láthatták, mert az Excel nem mutatta meg.

Még ma is a fülemben csengenek azok a telefonhívások, amikor azt kérdezték a felhasználók, hogy

• hogyan számoljuk az indított híváshossz mutatószámot? Vagy
• Az összbevételbe beleszámoljuk az egyéb bevétel is? Vagy
• Az 1-15 éves kategóriákba beletartoznak az 1 évesek is, vagy ők már nem?

És sorolhatnám. Mind-mind olyan kérdések, amelyek megválaszolásához minden információ rendelkezésre állt a kockában, felhasználók azonban eddig nem láthatták őket.

Minőségbiztosítóként pedig pöröltem is a szállítókkal, hogy igenis bele kell írni az adatbázisba az üzleti metaadatokat is. Ők mindig azzal érveltek, hogy minek, hiszen úgy sem jeleníti meg őket az Excel. Nem, tényleg nem, de más kliensek meg tudták jeleníteni őket, és most már az add-in telepítése után az Excel is képes lesz rá. Méghozzá kereshetően:

OLAP PivotTable Extension - Keresés a leírások között

Leírások kereshetősége

A megjelenítésen kívül arra is szükségünk van, hogy keresni tudjunk az üzleti metaadatok között:

• Hogy hívjuk azt a mutatót, amit korábban (a mutatószámok egységesítése előtt) úgy neveztünk, hogy Árbev (Ft)
• Melyik dimenzióban találok információt a felhasználóról? stb.

Mind-mind olyan kérdések, amelyekre a felhasználók saját maguk megtalálhatják a választ, ha

1. Az üzleti metaadatokat eltároltuk a kockákban
2. A kliens alkalmazás, mint például az Excel alkalmas ezen metaadatok kereshető megjelenítésére

Összefoglalva: OLAP PivotTable Extension nevű Excel bővítmény nagyon hasznos kis eszköz. Segítségével kereshetünk a leírások között (Description), megnézhetjük az Excel által generált MDX utasításokat és saját számított mezőket hozhatunk létre. Bárcsak az Excel 2010 alapból tudná ezeket.

Felhasznált irodalom:

• OLAP PivotTable Extensions

Régóta akartam már írni a témáról, és most Chris Webb cikke megadta hozzá a kezdő lökést.

Az Excel 2007 néha jól jeleníti meg a szakadozott hierarchiákat, néha nem. Első ránézésre nem is érti az ember, hogy amit egyszer jól csinál másszor miért nem. Aztán ha kicsit utánajár a témának, akkor még jobban elkeseredik. A leírt működés ugyanis nem egy hiba következménye, hanem az Excel alapból nem támogatja a szakadozott hierarchiák megjelenítését. Miért működik akkor néha mégis jól? Ennek járunk most utána.

Az Excel alapértelmezettként nem támogatja a szakadozott hierarchiák kezelését. (Szakadozott egy hierarchia, ha annak legalább egy elemének szülője nem közvetlenül az elem fölötti szinten helyezkedik el:)

Szakadozott (ragged) hierarchia

Szóval az Excel alapértelmezettként nem támogatja az ilyen szakadozott hierarchiák megjelenítését. Helyette kiegyensúlyozza őket,(kiolvassa a dimenzió tábla megye szintjére írt, vagy nem írt értéket) és az alábbi módon jeleníti meg hierarchiát:

Kiegyensúlyozott hierarchia

Miért nem támogatja az Excel 2007 a szakadozott hierarchiák megjelenítését?

Ennek rendkívül egyszerű oka van: Az Analysis Services felé küldött connection string-be beégeti az MDX compatibility = 1 beállítást. Ennek következtében az Analysis Services nem a szakadozott hierarchiát küldi vissza az Excelnek, hanem a teljesen kiegyensúlyozottat. (A szakadozott hierarchiát az MDX compatibility=2 beállítás adná vissza)

Írjuk át a connection stringet!

A connection stringet át tudjuk írni, de az Excel sajnos nem fogja figyelembe venni az MDX compatibility 2-re történő átállítást.

Akkor miért jeleníti meg néha helyesen az Excel 2007 a szakadozott hierarchiát?

Nem tudom. Az Excel belülről oldja meg a problémát. Tapasztalatból tudjuk, hogy az Excel 2007 jól jeleníti meg a hierarchiát, ha

1. Ha nincs testvére a levél szinten elhelyezkedő elemnek (pl Budapestnek) ÉS
2. a szülő szint HideMemberIf tulajdonságot OnlyChildWithParentsName-re állítottuk az Analysis Servces-ben ÉS
3. a Levél szinten elhelyezkedő elemet húztuk fel a lyuk kitömésére a dimenziótábla feltöltésekor. (Elvileg megtehetnénk, hogy Magyarországot húznánk le megye szintre, de ebben az esetben az Excel már nem fog megbirkózni a placeholder elem elrejtésével.)

Vegye figyelembe a fentieket az adatbázis tervezésekor és takarítson meg jó néhány óra szemöldökráncolást

Olvasom Kasper De Jonge 10 jótanácsát a PowerPivothoz, és  olvasom, hogy mennyire fontos a meglévő kapcsolatok használata az adatbázisokhoz történő kapcsolódáskor.

Nincs ez máshogy az Excel 2007 esetén sem. Ha a felhasználók arról panaszkodnak, hogy lassú a Pivot tábla, akkor gyanakodjon arra, hogy a felhasználók ugyanahhoz az adatkockához, adatbázishoz több kapcsolatot is létrehoztak. Ha ez így van két dolgot tehet:

1.       A kapcsolatok menüpontban átköti a Pivot táblákat egy kapcsolatra (connection-re) és törli a nem használt connection-öket, és

2.       Elmagyarázza nekik, hogy amikor több munkalapon is ugyanahhoz az adatforráshoz kapcsolódnak, akkor új kapcsolat létrehozása esetén használják a meglévő kapcsolatokat

Ki ne szeretné tudni, hogy mit csiripelnek róla, a termékéről vagy a szolgáltatásáról a Twitteren? Mit mondanak róla, milyen gyakran tesznek említést róla, és ha már megemlítik a céget vagy annak egy termékét, szolgáltatását akkor azt milyen jelzőkkel illetik?

A Microsoft "Analytics for Twitter" néven kiadott egy ingyenes Excel bővítményt, amellyel a fenti kérdések mindegyikére választ kaphatunk:

Microsoft Analytics PowerPivot Add-in for Twitter

Az alkalmazás az Excel 2010-be épül be és az adatok tárolására PowerPivot bővítmény mögött működő Vertipaq oszlopalapú adatbázis-kezelőt használja. Adatfrissítéskor meghívja a Twitter keresőmotorját, amely RSS formátumban adja vissza az elmúlt napok Twitter forgalmát.

Az Excel ezt követően beolvassa az RSS adatokat az oszlopalapú adatbázis-kezelőbe és összeköti azokat az általunk elkészített Excelben tárolt hangulat szótárral. Innentől kezdve lehetővé válik annak elemzése is, hogy mennyire gondolkodnak pozitívan, vagy negatívan a Twitterezők rólunk, termékünkről, szolgáltatásunkról.

Hangulat szótár

Ami talán a legérdekesebb mindebben, az az elv, ahogy a bővítmény működik illetve az igény, amit a bővítmény kiszolgál. Remekül szimbolizálja ugyanis azt, amit a Microsoft önkiszolgáló üzleti intelligencia néven említ és azt a stratégiát, amelyet ennek jegyében néhány éve a zászlójára tűzött:

Adott egy információ (twitter forgalom) amely nem található meg az adattárházban - és rövid időn belül valószínűleg nem is fog bekerülni az adattárházba, mert drága, mert hosszú idő beletenni, mert csak néhány felhasználónak van szüksége rá, stb. - , így az üzleti felhasználók nem férnek hozzá.

Ugyanakkor az üzleti felhasználónak szüksége van ezekre az információkra. Gondoljon például a tavalyi „csörögjetek ránk" Vodafon - T-Mobile adok-kapokra.

Egy ilyen szituációban szüksége van a marketingnek, PR-nak egy eszközre, amelyen keresztül elemezheti a Twitteren csiripelők hangulatát, illetve annak változását. Sőt. Ebben az esetben már nem csak nekik, hanem a döntéshozóknak is látniuk kell, hogy mekkora a hype a történet körül, mekkora és milyen visszhangja van az esetnek.

A Microsoft önkiszolgáló üzleti intelligencia stratégiája pedig pont az ilyen igények kielégítését célozza meg: „Ha nincs egy Twitter forgalom elemző alkalmazásod, ha a Twitter forgalmad nem található meg az adattárházban, ha nincs erőforrásod egy ilyen alkalmazás kifejlesztésére, akkor vedd kezedbe az ügyet. Szedd le az adatokat a webről, gyúrd össze saját adataiddal, készíts belőle egy gombnyomásra frissíthető mini adatpiacot és mindezt tedd elemezhetővé mások számára is. Mindezt természetesen a jól ismert eszközöddel: Az Excellel."

Ingyenesen letölthető egy Excel bővítmény, amelyen keresztül az SQL Server következő verziójában szerkeszthetőek lesznek a központi törzsadat kezelő rendszerben (Master Data Services, MDS) tárolt adatok.

Master Data Services Excel Add-in

Miért örülünk ennek a bővítménynek? Mert

1)      Megnyílik még egy csatorna az MDS felé amin keresztül az üzleti felhasználók elérhetik a törzsadatokat, szerkeszthetik a hierarchiákat, stb.

2)      És mert az Exceles felületen keresztül sokkal könnyebben megoldható több sor egyidejű (tömeges) módosítása (pl.: 10 új termék azonos termékcsoportba sorolása), mint a webes felületen keresztül

További infók:

-          What's New in Master Data Services (MDS) in Denali CTP3

-          Master Data Services Excel Add-in

Lezárult az I. önkiszolgáló BI workshop. Amitől féltem attól nem kellett volna, amire nem is gondoltam, az bekövetkezett... Féltem attól, hogy sokan leszünk és nem fogok bírni annyi emberrel. Féltem attól, hogy messzi lesz a vászon és a hátsó sorokból nem fogják látni. Féltem attól, hogy a wifi nem fogja bírni. És féltem attól, hogy az Excel összeomlik valakinél és emiatt nem tud majd követni minket. És végül féltem attól, hogy a heterogén társaság miatt valakinek túl sok lesz az anyag, valakinek pedig túl kevés.

Pedig, mint utólag kiderült nem ettől kellett volna félni, hanem attól amiről most fogok írni.

A workshop közepén valaki jelezte, hogy baj van a PowerPivottal: Hibaüzeneteket dobál. Aztán ahogy a többiek is utolértek minket egyre többen jelezték, hogy nekik is ugyanazt a hibaüzenetet dobja a PowerPivot. Aztán valaki, akinek hibád dobott a PowerPivot észrevette, hogy nála máshogyan jelennek meg a menük... És kezdett összeállni a kép. Aki a hét elején rakta fel a PowerPivotot, annak ment, aki a workshop előtti napokban annak nem. Biztos más-más verziót használnak...

Paff. Szerencsére a közönség nagyon kreatív volt, és megosztották egymással az információkat: „hozd létre azt a belső számított mezőt, amit hiányol és nem fog hibaüzenetet dobni"; „használj a vessző helyett pontosvesszőt a függvényekben, mert úgy néz ki, hogy elkezdték magyarítani a DAX-ot" és még sorolhatnám. Ott volt B tervnek a „szünetben mindenki rakja újra a PowerPivotot" de erre végül nem került sor.

Otthon elemezve a történetet persze kiderült a turpisság: A Microsoft frissítette a héten a PowerPivot.com oldalt és ezzel párhuzamosan leszedték a végleges PowerPivot verziót és felrakták helyette a 2012 RC0-át (magyarul a bétát) Máig nem értem, hogy a főoldalon a Download PowerPivot link miért egy béta termékre mutat. No mindegy. A lényeg, hogy aki a múlt héten töltötte le a PowerPivot-ot az még a végleges verziót kapta, aki a workshop előtti napokban, az már a bétát. Mindenesetre a közönség nagyszerű volt és remekül megoldotta a problémát. Köszönet ezúton is.

Ha már a közönségnél tartunk. Összesen 19-en jöttek el és a társaság - mint mindig - most is nagyon vegyes volt. Voltak Cognos, Microstategy, Oracle, stb. BI felhasználók, voltak a szállító oldalról, voltak a megrendelő oldalról, voltak informatikusok és voltak elemzők is.

Nagyon tanulságos volt látni, ahogy az éles adatok beindították a résztvevők fantáziáját. És nagyon tanulságos volt arról is beszélgetni, hogy ki miért jött a workshopra. Voltak, akik áthidaló megoldást kerestek, amíg lesz pénz adattárházra, voltak akiknek elegük volt az Excelek simogatásából és valamilyen automatizálható megoldást kerestek, és a többség természetesen az adataihoz akart hozzáférni és ehhez keresett megoldást. Vagy maga, vagy az ügyfelei számára. Örültem, hogy ezeket a problémákat említették, mert a workshop pont ezekre kereste a választ.

Lesz újabb workshop? Lesz. De már újabb önkiszolgáló BI eszközökkel. A PowerPivotnak is lesz új verziója és az önkiszolgáló BI eszközök is szépen szaporodnak. Jön az önkiszolgáló ETL, adattisztítás, adatbányászat, stb. És jön az SQL 2012 is.

Mikor lesz folytatás? Kb. félév múlva. Aki értesítést kér az időpontról az iratkozzon fel itt.

A résztvevőknek köszönöm, hogy megtiszteltek bizalmukkal és eljöttek egy ismeretlen tanfolyamra. Aki pedig nem tudott eljönni, annak kárpótlásul mondom, hogy olvassa tovább a BI projekt blogot, (vagy a technikaibb BI jegyzetek-et) mert sokat fogok még a közeljövőben az önkiszolgáló üzleti intelligenciával foglalkozni.

A Master Data Services legnagyobb újdonsága a 2012-es verzióhoz kiadott Excel bővítmény, mely lehetőséget biztosít a törzsadatok Excelen keresztül történő karbantartására. Az Excelnél megszokott rugalmassággal, vágólapról történő tömeges beszúrás lehetőségével, képletek engedélyezésével, stb. Mindezt úgy, hogy a Master Data Services biztosítja a háttérben az adatok validálását, auditált és verziózott tárolását.

Nagyon jó! Végpróbáltam vele pár szcenáriót és üzleti metaadatok, hierarchiák, forrásrendszerrel nem rendelkező adatok, szótárak, stb. karbantartására ideális felület. Egy webes felületen sose kapnánk meg azt a szabadságot és rugalmasságot, amit az Excel biztosít. És ez nem ergonómiai kérdés, hanem technológiai.

Nekünk BI-osoknak nagyon sok lehetőséget tartogat az MDS és ez az Excel bővítmény. Érdemes megnézni őket így együtt.

A Reporting Services 2012 Excel és Word Export funkciója lehetővé teszi a 2007-es Office-ban megismert xlsx és docx formátumú fájlok generálását azok minden előnyével. Kezdve a tömörített formától az 1 millió soron és 16 ezer oszlopon keresztül a 16 millió színig.

Kapcsolódó anyagok:

·         Export to Excel upgrades in SSRS Denali CTP3

Videó, 27 oldalas ingyenes tanulmány, workshop: Ezekkel az anyagokkal tudok szolgálni azoknak, akiket érdekelnek az önkiszolgáló üzleti intelligencia vagy a PowerPivot for Excel újdonságai.

PowerPivot 2012 videó

A Microsoft feltette a TechNetklub TV-re az április 25.-i SQL termékbejelentő konferencián készült felvételeket, amely közt megtalálható a Powerpivot újdonságait bemutató előadás is. Az 50 perces videó gerincét a PowerPivot for Excel újdonságainak bemutatása adja, de megismerheti belőle a Power View animált grafikonjait is.
A videó itt megtekinthető:

Önkiszolgáló üzleti intelligencia az SQL 2012-ben >>

A PowerPivot 2012 újdonságai (tanulmány)

Írtam egy 27 oldalas tanulmányt is a 2012-es PowerPivot for Excel újdonságairól, amely bemutatja a PowerPivot összes újdonságát (kivéve a PowerPivot lekérdező nyelvének, a DAX-nak az újdonságait)

Az anyagot úgy próbáltam meg összeállítani, hogy az újdonságok bemutatása mellett essen szó arról is, hogy az újdonságoknak milyen előnyei vannak, hol használhatjuk őket, milyen korábbi hiányosságokra adnak megoldást.

A tanulmányt a hírlevélre feliratkozók az alábbi linken már le is tölthetik, vagy megtalálhatják a tanulmányok között. Aki nincs feliratkozva, az egy e-mail cím megadásával itt megteheti.

A PowerPivot for Excel újdonságai (pdf) >>

Workshop

Aki nem csak a 2008 R2-es verzióhoz képesti összehasonlításra kíváncsi, hanem szeretné azt is megtanulni, hogy MIRE tudjuk használni a PowerPivotot a való életben, hogyan építhetünk fel a segítségével komplett döntéstámogató rendszereket, az jöjjön el az önkiszolgáló BI workshopra, ahol elkészítjük többek között az alábbi kimutatást is:

Az önkiszolgáló BI workshop résztvevőivel ezt a kimutatást is elkészítjük

Az önkiszolgáló BI workshop további eredménytermékei és részletei megtekinthetőek az alábbi linken. (Szeretném felhívni a figyelmét, hogy a kedvezményes regisztrációs lehetőség május 31.-én lezárul, és a következő workshopra kb. fél évet kell majd várni :-()

Önkiszolgáló BI workshop Excel felhasználóknak >>

Telepített Excel 2013

Elkezdtem gyűjteni azokat az újdonságokat amelyek érdekesek lesznek BI szempontból. Ezek közül a kettő legfontosabb, hogy a PowerPivot is és a Power View is bekerül majd az Excel 2013-ba

PowerPivot: bekerül az Excel 2013-ba

A PowerPivotból megismert oszlopalapú adatbázis kezelő (ma xVelocity néven fut, korábban Vertipacknak hívták) része lesz az Excel 2013-nak. Natívan. Nem kell külön telepíteni. Elég egy checkboxot bepipálni és kész. Ez több szempontból is fontos újdonság.

• Egyfelől tovább csökkent az önkiszolgáló BI belépési küszöbének magassága, hiszen innentől kezdve minden Excel 2013 felhasználó gépére telepítésre kerül egy önkiszolgáló BI eszköz. Akár kéri akár nem.
• Másfelől az Excel mögött ezentúl mindig lesz egy többmillió sor kezelésére képes adatbázis-kezelő. Ha például egy mezei Pivot táblával olvasunk be sorokat, akkor az Excel kapásból felajánlja, hogy beteszi nekünk az adatokat az oszlopalapú adatbázisba. Így sokak életének válik majd úgy részévé a BI és az oszlopalapú adatbázis kezelés, hogy nem is tudnak majd róla.

Power View: bekerül az Excel 2013-ba

A másik nagy újdonság hogy a bemutatókon mindig látható Power View-val készített animált buborék diagramok is beköltöznek az Excelbe. Az Excel 2013-tól kezdve tehát nem lesz szükségünk SharePointra ha használni szeretnénk a Power View adatvizualizációs szolgáltatásait.

Mindkét újdonság nagyban hozzá fog járulni az önkiszolgáló BI terjedéséhez és felhasználói tábor növekedéséhez. Akár átoknak, vagy akár áldásnak tartjuk. A kérdés innentől kezdve nem az lesz, hogy akarjuk-e hogy használják az üzleti felhasználók, hanem az, hogy hogyan éljünk majd együtt vele.

Megjegyzés: Elkezdtem szervezni a 3. önkiszolgáló BI workshopot, amely valamikor novemberben lesz megtartva. Pontos időpont még nincs, de itt kérhet értesítést róla.

Felhőben futó Excel

Elkezdtem kísérletezni az a felhőben futó Excellel is. Ezzel kapcsolatban leginkább arra vagyok kíváncsi, hogy miként változtatja majd meg a felhőben futó Excel a BI tájképet. Milyen hatással lesz a klasszikus és az önkiszolgáló BI-ra, az elemzési és az információ megosztási világra, hoz-e új alternatívát a kis és középvállalatok számára, előrelendíti-e a mobil BI elterjedését, stb.

Látok már biztató újdonságokat és látok olyanokat is, amelyeknek szerintem nagyobb lesz a füstje, mint a lángja. De ezekről hamarosan beszámolok majd itt a BI projekt blogon.

Örömmel jelentem be, hogy november 13.-án újra lesz önkiszolgáló BI workshop Excel felhasználóknak. Az idei 3. workshopon - mint eddig mindig - most is többmillió sorral fogunk az Excelben dolgozni. Egészen pontosan 3,5 millió sor éles adatot fogunk az Excelbe tölteni és arra elemzéseket, dashboardokat fogunk készíteni. Lesznek KPI-ok, interaktív térképes kimutatások, animált buborékdiagramok, kombinált grafikonok, terllis display és még egy csomó hasznos dolog.

Az önkiszolgáló BI workshopon mindig a legújabb technológiákat használjuk, így könnyen lehet hogy ez lesz az utolsó lehetősége, hogy Excel 2010-zel tanuljon dashboardokat és elemzéseket készíteni. Nemsokára megjelenik az Excel 2013 és attól a pillanattól kezdve ez a képzés csak kihelyezett tréning formájában lesz elérhető.

Nézze meg a workshop honlapját, nézze meg milyen problémákra találtak megoldást a korábbi résztvevők és ha úgy gondolja, hogy ez a tanfolyam Önnek szól, akkor jelentkezzen az Önkiszolgáló BI Workshopra

Ha már volt(ál) az önkiszolgáló BI workshopon, vagy tetszik a kezdeményezés akkor segíts(en) a hír terjesztésében.

• Megosztom e-mailen
• Megosztom a facebookon
• Elcsiripelem a twitteren

Adott két cég:

• Az egyik egy több telephellyel rendelkező kisvállalat néhány 100 millió forintos forgalommal, amely az értékesítési adatait szeretné elemezhetővé tenni az értékesítők és tulajdonos számára.
• A másik egy költségvetési szerv, amely adatszolgáltatási kötelezettségeinek színvonalán szeretne javítani úgy hogy a korábbi Exceles adatszolgáltatását szeretné valamilyen korszerűbb webes, interaktív elemzést és lekérdezést lehetővé tevő szolgáltatásra cserélni.

Mi a közös ezekben a cégekben?

• Egyikőjük sem akarna (tudna) fizetni egy ilyen BI megoldásért
• Egyikőjük sem akarna (tudna) telepíteni ehhez BI szoftvereket, mert nem értenek hozzá, nincs rá kapacitásuk, nincs rá engedélyük stb.
• De mindkettőjük használ Excelt

Mit tehetnek ezek a vállalatok? Keresnek egy olyan ingyenes felhőszolgáltatást, amely elérhetővé teszi az Ad-hoc elemzést pivot tábla szerűen, webes felületen. A most következő cikkben mutatok egy ilyet és bemutatom azt is, hogy hogyan készítehetik el mindezt.

Gyógyfürdők forgalmának ad-hoc elemzése webes felületen

A példához hazai gyógyfürdők forgalmát fogjuk elemezni és az elemzés eredményeit egy dashboard-on keresztül mindenki számára elérhetővé tenni. Az alapadat, - mint az önkiszolgáló BI wokshop esetében is - valós, éles adat.

A dashboard a böngészőben így néz ki:

Excel dashboard webes felületen

A dashboard tartalmaz:

1. egy lefúrható pivot táblát, melynek oszlopai és sorai a jobb oldali mezőlistán keresztül szerkeszthetőek (Pont mint az Exceles Pivot tábla esetében)
2. és szeletelőkkel (bal oldali gombok) szinkronizált grafikonokat.

Az ad-hoc elemzést lehetővé felület böngészőben így néz ki:

Ad-hoc elemzés pivot táblákban webes felületen

Próbálja ki!

Az alábbi linkre kattintva Ön is kipróbálhatja, hogy hogyan működik a dashboard és az ad-hoc elemzés webes felületen:

Ad-hoc elemzés pivot táblákban webes felületen >>

Játsszon az adatokkal. Elemezzen. Nézze meg, hogy hogyan alakult az iszappakolásos kezelések száma az elmúlt egy évben, mennyit fizettek érte a betegek, mennyibe került mindez az államnak. Vagy keressen egy Önnek érdekesebb elemzési problémát. Próbálja ki.

Hogyan készült a dashboard?

1. Excel 2010-be beolvastam a gyógyfürdő forgalmi adatokat
2. felépítettem rá a pivot táblát és a dashboard-okat
3. felmentettem az Excel fájlt a SkyDrive mappámba
4. Megosztottam a fájlt úgy, hogy mindenki számára elérhetővé váljon

Ennyi. Ez tényleg ennyire egyszerű. A háttérben futó technológia nyilván nem az, de a felhasználó számára az tökéetesen rejtve marad.

Hölgyeim is uraim: Nagy változások előtt áll BI szakma kis és középvállalati szegmense. Olyan szolgáltatások válnak egyszerűen és ingyenesen elérhetővé, amelyek korábban csak a nagyvállalatok privilégiumainak számítottak.

Érdemes ezekkel a technológiai újdonságokkal lépés tartani, mert előbb vagy utóbb begyűrűznek a nagyvállatokhoz is. Akár akarjuk, akár nem.

Szeretném megosztani ezen a csatornán is, hogy november 13.-án egésznapos workshopot tartok PowerPivotból. Az Önkiszolgáló BI workshop néven futó rendezvényen ára, tematikája és egyéb részletei elérhetőek a workshop oldalán. Link: PowerPivot és Excel dashboard workshop

A workshopon többek között olyan webes dashboardokat fogunk építeni, mint az alábbi KPI-okat tartalmazó kartogram. Mindezt az Excel és a PowerPivot segítségével.

Akit érdekel hogyan lehet egy Excel Pivot táblát a webre publikálni és a webre publikált Pivot táblát böngészőből interaktívan használni, az mindenképpen jöjjön el a 2012. október 16.-i BI openre, mert ott élőben meg is fogom mutatni. Konkrétan ezt a két Pivot táblát fogjuk felépíteni és a webre publikálni:

Excel dashboard webes felületen

Ad-hoc elemzés pivot táblákban webes felületen

A rendezvény ingyenes, de regisztrációhoz kötött. Részletek a rendezvény honlapján.