Excel 2007 alapú BI riporting rendszer bevezetésének lépései

A most következő cikkből megtudhatja, hogy hogyan kell kialakítani egy jó BI riporting rendszert az Excel 2007 segítségével. Mit jelent az, hogy jó? Ezt majd definiáljuk később, de előtte nézzük meg, hogy mit kell elkerülnie ha Excel 2007-et akar BI frontendként használni adattárháza vagy OLAP alapú adatpiaca fölé.

Hogy néz ki egy átlagos BI rendszer? SQL server, fölötte egy OLAP szerver, fölötte egy olyan BI front-end amely legjobban megfelel az üzleti felhasználók követelményeinek: Excel, ProClarity, vagy valamilyen harmadik szállító terméke. (Ha nem olvasta még az Excel 2007 vagy ProClarity? című BI front-end összehasonlító tanulmányt, akkor azt töltse le innen)

Ezek a mondatok mind azt sugallják, hogy elegendő az adattárház vagy az OLAP alapú adatpiac fölé telepíteni egy Excelt és az üzleti felhasználók máris elkezdhetik elemezni az adattárházban tárolt adatokat.

Mi ezzel a modellel a baj?

  1. A modell feltételezi, hogy az üzlet felhasználó TUDJA, hogy hol találhatja a számára szükséges információt. Melyik szerveren(?), adatbázisban(?) adatkockában(?). Amíg egy maroknyi felhasználóval kell dolgoznunk, addig őket be lehet tanítani arra, hogy a szerver neve: 192.168.0.1, az adatbázis neve, … de amikor el akarjuk érni, hogy ötven vagy száz felhasználó használja az adattárházat, akkor ugyanez a betanítás már nem fog hatékonyan működni.
  2. A modell feltételezi, hogy az elkészített Excel riport forrás adatbázisa, forrás szervere soha többé nem fog megváltozni. Ez mindamellett, hogy nagyon optimista állítás elveszi tőlünk annak lehetőségét, hogy valamilyen kritikus hiba esetén átirányíthassuk az üzleti felhasználókat egy backup szerverre, vagy egy backup adatbázisra.

Ha a fenti hiányosságokat ki akarjuk küszöbölni, akkor nem elég pusztán telepíteni az Excel 2007-et, hanem ki kell alakítanunk egy olyan riporting környezetet, amely „rendszerként” képes kiszolgálni az üzleti felhasználók (és az üzemeltetők) igényét. Ehhez pedig nélkülözhetetlen az Excel 2007 connection string kezelésének ismerete…

Excel 2007 connection string kezelése

Az Excel 2007 lehetőséget biztosít arra, hogy az adatkapcsolatot leíró információkat, azaz a connection string-et egy külön „odc” kiterjesztésű fájlban, úgynevezett kapcsolatfájlban tároljuk. Ezzel függetleníthetjük Exceles riportjainkat a forrásrendszerektől:

Excel 2007 connection string kezelése

Excel 2007 connection string kezelése

Azaz az Excel csak a formázott riportot tartalmazza és egy linket arra a fájlra, amelyik leírja, hogy hol található az a szerver, adatbázis, … amelyből fel kell majd tölteni a riportot adatokkal.

Mindezek ismeretében kezdjünk hozzá a riporting rendszer kialakításához.

Riporting RENDSZER kialakítása Excel 2007-tel

Egy jó vállalati riporting rendszertől a következőket kell elvárnunk:

  1. Az üzleti felhasználóknak ne kelljen ismerniük az adattárház/adatpiac pontos nevét vagy IP címét, és egyszerűen elérjék a kívánt tartalmat
  2. Az üzemeltetők az üzleti felhasználók segítsége nélkül át tudják irányítani a riportokat egy másik – például egy backup – adatbázisra
  3. Az üzleti felhasználók szabadon választhassanak, hogy a tesztadatbázist, vagy az éles adatbázist akarják-e használni

I. Az üzleti felhasználóknak ne kelljen ismerniük a szervergép pontos nevét

Az előbbiekben megismert kapcsolatfájlok pont ezt a célt szolgálják. A connection stringhez hozzárendelnek egy felhasználóbarát megnevezést, így az üzleti felhasználóknak nem kell ismerniük a connection string pontos felépítését, elég ha megjegyzik annak nevét. Például hogy az „Értékesítés.odc” –t kell választaniuk, ha az Ertekesites nevű adatkocka adatait akarják lekérdezni az xxx szerverről.

Elég tehát egyszer elkészíteni egy ilyen kapcsolat fájlt – amelyhez az Excel minden segítséget megad – és utána hivatkozhatunk a kapcsolatra annak nevével.

A kihívás abban van, hogy honnan tudja egy új üzleti felhasználó azt, hogy hol vannak ezek a kapcsolatfájlok. Illetve nem is ebben, hanem abban, hogy hogyan tudjuk az Excel tudomására hozni, hogy hol vannak a kapcsolatfájlok, hiszen a felhasználók logikusan az Excel meglévő kapcsolatai között fogják keresni azt.

Ahhoz, hogy a meglévő kapcsolatok között megjelenjenek a kapcsolatfájlok 2 dolgot tehetünk.

  1. Ha SharePoint 2007 szervert használunk és használjuk annak My site funkcióját és a connection sztringeket egy sharepoint Data Connection Library listában tároljuk, akkor a felhasználónak meg fog jelenni a connection string a hálózati kapcsolatfájlok között
  2. Ha nem használunk SharePoint-ot, akkor – és a továbbiakban csak ezzel foglalkozunk - , csak akkor fog megjelenni a kapcsolat fájlunk, ha azt bemásoljuk minden egyes felhasználó „my data sources” (adatforrás) könyvtárába.

Tehát ha nem használunk SharePoint 2007-et, akkor az adattárház connection stringjét (kapcsolat fájl) el kell helyeznünk minden egyes felhasználó My Data Sources könyvtárában. Így megoldhatjuk, hogy az üzleti felhasználóknak nem kell ismerniük az adattárház pontos elérési útját, hiszen ha megnyitják az Excelt, akkor ezek automatikusan fel fognak tűnni a meglévő kapcsolatok között.

Első ránézésre ez jó megoldásnak tűnhet, hiszen könnyen oda tudunk másolni minden felhasználó My data sources könyvtárába néhány connection stringet, ám üzemi körülmények között ez a megoldás csúnyán elbukna… Miért? Mert tovább lassítja az amúgy is hosszú bejelentkezési procedúrát és bejelentkezés után már nem lenne kontrollunk a connection sztingek felett ami megsértené a II. követelményt, miszerint:

II. Az üzemeltetők az üzleti felhasználók segítsége nélkül át tudják irányítani a riportokat egy másik – például egy backup – adatbázisra

Ahhoz, hogy ennek pontnak is megfeleljen BI riporting rendszerünk, el kell érnünk, hogy egy központi helyen tároljuk a connection stringeket (kapcsolat fájlokat), és mindenki ezeket használja.

Lehetőségeink:

  • Másoljuk fel a connection fájlt egy megosztott mappába! jó gondolat csak sajnos az Excel 2007 csinál róla egy lokális másolatot és utána azt fogja használni. Elvetve
  • Bírjuk rá az Excelt, hogy a kapcsolati fájlokat ne a My data Sources könyvtárban, hanem egy általunk meghatározott könyvtárban keresse! Szintén jó gondolat, csak nem sikerült megvalósítani. Elvetve
  • Maradt az utolsó és már bizonyított megoldás:

Másoljuk fel a connection stringet egy megosztott mappába és tegyünk minden egyes adattárház felhasználó gépére egy parancsikont (shortcut), ami a megosztott mappára mutat.

Ezzel elérhetjük, hogy egyetlenegy connection stringünk legyen a szerveren és azt használja minden egyes üzleti felhasználó. Így ha költözik a szerver vagy ideiglenesen át kell irányítanunk a felhasználókat egy backup adatbázisra vagy szerverre, akkor elég egy helyen átírni a connection stringet és minden üzleti felhasználó automatikusan az „új” szerver adatait fogja látni, amikor frissíti riportjait.

Már csak arról kell gondoskodni, hogy az Excel mindig ezeket a megosztott kapcsolatfájlokat használja és ne cache-elje el magának a connection stringet… Mivel ezzel jó sokat szívtam, ezért erről részletes technikai leírást fogok adni a BI blogban. (és utána belinkelem ide a megoldást). Íme: Minden esetben kapcsolatfájl használata/Always use connection file

A lényeg az, hogy meg lehet csinálni. Most már csak arról kell gondoskodni, hogy

III. Az üzleti felhasználók szabadon választhassanak, hogy a tesztadatbázist, vagy az éles adatbázist akarják-e használni

Szerencsére erre minden eszközt megad az Excel 2007. Nem kell mást csinálnunk mint a riport alatt ki kell cserélni a kapcsolatfájlt. (Kapcsolat tulajdonságainál) De erről már 2006-ban is írtam a hogyan váltsunk nyelvet kliens oldalon című blogbejegyzésben

Összefoglalás: Az Excel 2007 önmagában nem egy BI riporting rendszer, de a fentiek segítségével Ön is ki fog tudni alakítani egy könnyen üzemeltethető riporting rendszert. Többé nem kell majd elmagyarázni a felhasználóinak, hogy úgy tudsz kapcsolódni az adattárházhoz, hogy a szerver nevéhez beírod azt, hogy pampampam... És több nem kell majd megkérni őket, hogy azokban a riportokban, amelyeket továbbra is használni akarnak változtassák meg a szerver nevét mert...

bónusz tipp: Ha elkezdi a fentiek szerint kialakítani BI riporting rendszerét, akkor óhatatlanul el fog majd gondolkoznia azon, hogy szerverenként (adatbázisonként) hozzon létre egy-egy kapcsolatfájlt vagy adatkockánként. Kétségtelen, hogy egyszerűbb karbantartani egy fájlt, amely csak a szerver és adatbázis nevét tartalmazza, mint kockánként egy-egy fájlt, de ha kockánként hozza létre a kapcsolati fájlt, akkor

  1. a későbbiekben könnyebb lesz egy olyan rendszert kialakítani, amelyben a sikertelenül betöltött kockákról átirányíthatja a felhasználókat egy backup adatbázisra (ahelyett, hogy az összes riportot irányítaná át)
  2. Ha ki akarja cserélni a riport alatt a kapcsolatfájlt, akkor nem kell hozzá tudnia, hogy melyik kockából táplálkozott az aktuális riport. Most még úgy gondolja, hogy ezt nyílván tudja, de képzeljen el egy 2 éve készített több mint tíz adatkockából összeállított Exceles dashboard-ot…

Szóval hozzon létre kockánként egy-egy kapcsolatfájlt, így később sok energiát takarít majd meg.

Sikeres bevezetést!

Kővári Attila - BI projekt

Új hozzászólás