PowerPivot architektúra dokumentum

Megjelent talán az első white paper a PowerPivot-ról, amelyből megismerhetjük a PowerPivot for Excel és a PowerPivot for SharePoint architektúráját.

 

Image001

A PowerPivot for Excel architektúrája

 

Akik rendszeresen olvassák a PowerPivot-tal foglalkozó blogokat, azok sok újdonságot nem fognak benne találni, aki viszont nem, azoknak egy jó kiindulási alap a PowerPivot megismeréséhez.

További Report Builder 3.0 újdonságok

Bár a Report Builder leglátványosabb újdonsága kétség kívül a kartogramok készítésének támogatása, de emellett sokat változtattak az architektúrán annak érdekében, hogy egyszerűbben, gyorsabban tudjunk vele dolgozni:

-          változtattak az adatkapcsolatok definiálásán annak érdekében, hogy még a riportkészítés kezdeti stádiumában kiderüljön, ha egy üzleti felhasználónak nincs jogosultsága az adatokhoz,

-          változtattak a jogosultság kezelésen is, így több felhasználó nevében is tesztelhetőek lesznek az elkészített riportok,

-          változtattak az adatok gyorsítótárazásán is, aminek következtében lényegesen gyorsabban képesek az üzleti felhasználók riportokat készíteni, mint eddig

-          A riportok elérhetőek ATOM kompatibilis formátumban is, így külső alkalmazások, mint például a PowerPivot képesek a riport adatait közvetlenül felhasználni. Nincs szükség az adatforrások vagy a kapcsolódási sztringek ismeretére, hiszen mától a riport adatai közvetlenül fogyaszthatóvá válnak

-          Az Excel 2010-nél megismert szikragrafikonok a Report Builder segítségével is létrehozhatók

-          Újrafelhasználhatóvá váltak a riportkészítéshez használt komponensek, minek következtében nem kell minden riportkomponenst újra és újra elkészíteni. Ha valaki elkészített egy riportot, akkor annak komponenseit, mint például táblázatok, grafikonok, kijelzők elmentheti mint megosztott komponenst, így azt később ő maga és mások is fel tudják használni az új riportok előállításához

-          A komponensek mellett az adathalmazok (DataSets) is megoszthatóvá és újrafelhasználhatóvá váltak. Ha például egy elemző vagy egy kontroller összeállít egy bonyolult lekérdezést és ezt elmenti mint megosztott adathalmaz, akkor azt akár több komponens forrásaként is felhasználhatja: készíthet rá grafikonokat, táblázatokat, kijelzőket.

2013-ig évi 807 %-kal növekszik a mobilalkalmazások piaca

Megvan. A mobil üzleti intelligenciával foglalkozó cikkhez kerestem adatokat annak alátámasztására, hogy a mobil alkalmazások piaca illetve maguk az okostelefonok elterjedése is nagyon gyors lesz. Most megtaláltam. Eszerint a mobilalkalmazások piaca az elkövetkező 3 évben átlagosan évi 807%-kal fog bővülni, és az okostelefonok felhasználóinak száma 2013-ra eléri az 1 milliárdot. (A mai kb. 100 millió felhasználó tehát 3 éven belül meg fog tízszereződni!)

Image001

Forrás: Mobilport, via Doransky

PowerPivot az adatszakértőknek

Olvasom Bőgel György blogjában, hogy "… egy új vállalati szakma (pozíció, feladatkör) van kibontakozóban, amit „data scientist”-nek neveznek. Ennek az „adattudósnak” vagy „adatszakértőnek” három dologhoz kell értenie: (1) az adatfeldolgozási szoftverekhez¸(2) a matematikai statisztikához és a (3) meséléshez (storytelling). …"

Nos. A PowerPivot ezeknek az adattudósoknak fog nagy segítséget adni azzal, hogy emberi közelségbe hozza az adatfeldolgozást és az adatbányászatot.

SCD (Slowly Changing Dimension) implementáció az SQL Merge utasítással

Találtam Kimball Design tippjei között egy remek példát az SQL Merge utasítás használatára. (Az SQL Merge utasítást, - az SSIS Slowly Changing Dimension taszkjához hasonlóan – az adattárházak töltésére használhatjuk) A példa megcsinál mindent, ami a Kimball módszertannal épített adattárházak töltéséhez szükséges: Update-eli Type 1 szerint historizált attribútumokat, új rekordot szúr be, ha egy Type 2 szerint historizált attribútum megváltozik, lejáratja a régi rekordokat és az új rekordoknak új érvényességi dátumot ad, stb.

Ötlet a Change Data Capture (CDC) alkalmazására adattárházas környezetben

Annak idején az SQL Server 2008 BI és adattárház újdonságainak bemutatásakor kicsit nehezményeztem, hogy a Change Data Capture a forrásrendszer adatbázisába ír vissza. Ott hozza létre a változás táblákat, ami miatt adattárházas alkalmazása meglehetősen nehézkes. (Gyakorlatilag megoldhatatlan).

Most azonban hogy újra foglalkoznom kellett a témával, rájöttem, hogy talán nem is így kéne használni.

Megj.: Azért került képbe a Change Data Capture, mert egy olyan forrásrendszerből kell dolgoznom, amelyből rendszeresen törölnek. A Change Data Capture egyik legfontosabb jellemzője pedig az, hogy elkapja nekünk a törléseket is

Ötlet: Ha az megoldható lenne, hogy a szükséges táblák adatait a replikáljuk az adattárház staging területére, és a replikált táblákra rá tudnánk ereszteni a Change Data Capture-t, akkor a probléma megoldható lenne. Sajnos az ötlet csak ötlet maradt, mert nálunk nem lehet megoldani a replikációt L. Mindenesetre felírom ide magamnak, hogy legközelebb eszembe jusson.