Minden adattárház és üzleti intelligencia bevezetése előtt álló szervezetben fontos tudatosítani, hogy téves az a felfogás, miszerint az adattárház építése szinte kizárólag az informatikai terület feladata. Valójában egy adattárházban az intézményi felhasználók számára szükséges intézményi adatokat kell tárolni üzleti szempontok szerint, és az informatika nem ismerheti pontosan az intézményi felhasználók igényeit. Az adattárház építése tehát az informatikai és intézményi területek közös feladata. Szorosan együtt kell dolgozniuk, hogy egy sikeres adattárház valósulhasson meg, amely ténylegesen hasznos a teljes szervezet számára, és amely végcélként a megfelelő döntéstámogatással, iránymutatással segít majd meghatározni a helyes stratégiai irányt.

Ezáltal kiemelten fontos előfeltétel, hogy az intézményi felhasználók megértsék és tudatában legyenek, hogy
Az igények priorizálása azért kiemelten fontos, mivel egy adattárház megépítése és használatának teljeskörű kialakítása hosszú folyamat, így az intézményi területek számára fontos vagy éppen kritikus információ prioritásának meghatározása segíti az informatikai területet az adattárház hatékony inkrementális kialakításában, a leendő felhasználók szempontjai szerinti legértékesebb információ biztosításával indulva.
A törzsadatokat tekintve általános helyzet, hogy számos intézményi terület használja különböző rendszerekben ugyanazon törzsadatot, a törzsadatokat rendszerenként tartják karban, és nincsen egységes törzs, valamint folyamatos adattisztítás. Amint az ilyen típusú törzsadatokra épülő több rendszer adatát szeretnénk az adattárházba integrálni, úgy elengedhetetlen a törzsadat konszolidáció megvalósítása. Az előkészítési fázisban fogjuk beazonosítani a konszolidálandó törzsadatokat, illetve kialakítani az alkalmazandó konszolidációs eljárásokat intézményi szempontok szerint.
A törzsadat-konszolidációnak két alapvető fajtája létezik:
• lineáris konszolidáció
o egyetlen hierarchiával kezelhető
o egyértelműen azonosítható minden forrásadat konszolidált helye
o forrásadatok csak egy szempontból elemezhetőek
Lineáris törzsadat konszolidáció
• mátrix konszolidáció
o több hierarchiába sorolható a törzsadat
o forrásadat több szempontból elemezhető
Mátrix törzsadat konszolidáció
Az adattárház, mint információs rendszer legfőbb feladata az információszolgáltatás, és mint a szervezet fő információszolgáltató rendszere ki kell, hogy elégítse a felmerülő intézményi riportigényeket. A megbízhatóságnak egy intézményi döntés folyamatában nagyon nagy szerepe van. Az adattárház a már leírt jellemzői segítségével legyen képes megfelelni az elvárásoknak. A tisztított adatokból a metaadatbázis segítségével az információkérésnek megfelelően értelmezett adatot a megfelelő aggregáltsági szinten legyen képes szolgáltatni. Az adattárház legyen a forrásadatok tematizált, csillagstruktúrába transzformált, idősoros lenyomata, üzleti nézete.
Az állomásoztatási terület támogassa az alábbi folyamatokat:
o Adatkinyerés
o Adat átalakítás
o Adattöltés
o Job felügyelet
A prezentációs terület támogassa az alábbi folyamatokat:
o Adattárház böngészés
o Hozzáférés és biztonság
o Lekérdezés felügyelet
o Szabványos riportok
o Aktivitásfigyelés
Az adattárház a dimenzió adatok esetében biztosítson érvényességkezelést, a tényadatok esetében pedig vonatkozási idő megjelölést. Az adattárház a gyakran használt, nagy futásidejű lekérdezések esetében biztosítson aggregátumokat. Flexibilis architektúrája révén tegye lehetővé a folyamatos adatforrásként való üzemelést a szervezet üzleti igényeinek, valamint az adatforrások megváltozása esetén is.
A rendszer a felsővezetői döntéseket kell, hogy támogassa, azaz a rendszernek munkaidőben kell elérhetőnek lennie. Ennek következtében az adattárházban megengedhető, hogy az esti órákban történjen a töltés és az előre ütemezett riportok lefutása (batch window), a nappali órákban pedig a lekérdezés. Az adattárháznak és a reporting rendszernek a rendelkezésre állása célszerűen tehát heti 5 nap, naponta reggel 6-tól (adattárház megnyitása) este 10 óráig (adattárház zárása).
A rendszer legyen karbantartható az alapfunkcionalitás fenntartása mellett és/vagy legyen felkészítve a karbantartás miatti esetleges leállás következményeire.
Az olyan funkcionalitást biztosító komponensek, amelyek forrásrendszer specifikusak (tipikusan az adatkinyerő és adattisztító komponensek) különüljenek el az általánosan alkalmazható komponensektől, annak érdekében, hogy az előbbiek könnyen cserélhetőek legyenek.
Az adattárházban az adatok historikusan vannak tárolva. Azonban nem minden adatot kell ugyanannyi ideig megőrizni, illetve nem minden adat kerül ugyanolyan gyakran elemzésre. Vannak olyan adatok, amelyek, akár 10 év után is érdeklősére tartanak számot, míg mások már 1 év után érdektelenek. Az adatok egy részét nagyon gyakran lekérdezik, míg másokat ritkábban. Az adatok fontosságát az intézményi területnek kell meghatározni (tehát mennyi ideig van rá szükség). Az adatok használatának intenzitását az adattárház üzemeltetés tudja kimérni.
Ezek kiindulási alapja az adat életciklus menedzsmentnek (Information Lifecycle Management – ILM). Hogy egy adott adat típusnak mennyi ideig kell elérhetőnek lennie, meghatározza az adatok archiválásának idejét. Az adatok felhasználásának intenzitása meghatározza, hogy milyen gyorsaságú storage megoldásnak kell kiszolgálnia az adattárházat. A gyakran lekért adatok tárolhatóak gyors nagy sávszélességet biztosító storage-on, míg a ritkán lekérdezett adatokat ki lehet tenni lassabb (ezért olcsóbb) storage megoldásokra.
Egy üzleti intelligencia rendszer tekintetében alapvetően két típusú felhasználói jogosultság korlátozási módot különböztetünk meg:
· objektum és
· adat szintű hozzáférés korlátozást.
Az objektum szintű jogosultság korlátozás az adattárház, illetve a BI rendszer egyes elemeihez, objektumaihoz (pl. adatbázisok, sémák, táblák, riportok, adatforrások, stb.) kapcsolódó jogosultság beállítást, míg az adat szintű hozzáférés korlátozás az egyes objektumok által tartalmazott adatokra vonatkozó szűrések beállítását jelenti. Tehát az első esetben az a kérdés, hogy egy adott jelentés hozzáférhető legyen-e bizonyos felhasználói csoportok számára vagy sem, míg a második esetben az, hogy egy bizonyos adatkör által tartalmazott adatokat milyen részben, milyen szűrésekkel láthassanak az egyes felhasználói csoportok a rá épülő lekérdezésekben, jelentésekben?
Inmon modell szerinti architektúra
Az ETL folyamattal szembeni követelmény a napinál nem gyakoribb betöltés, amelyből következően az adatok betöltése batch[1] üzemmódban kell történjen. Az adatok a forrásrendszerekből, fájlokból első körben az állomásoztató területre kerülnek, ahol megtörténik az adatok konszolidálása, tisztítása és transzformációja.
Az állomásoztatási területet célszerű két részre bontani. Az első részbe kerülnek betöltésre a forrásadatok, míg a második rész a forrásadatoknak az aktuális adattárház tartalommal való összehasonlítására és frissítésre szolgál.
Az állomásoztató területről az adatok bekerülnek az adattárház permanens adattárolási rétegébe, amely adattárház architektúrától függően lehet egyrétegű (csak adatpiac réteg van) vagy kétrétegű (adatpiaci és enterprise data warehouse réteg is van, a fenti ábra ilyet ábrázol). Ha kétrétegű a permanens adattárolási réteg, akkor az ETL folyamatok feladata a két réteg közötti adat transzformáció elvégzése.
Az adattárház adataihoz olvasási jogot az elemzési réteg számára csak a permanens adattárolási rétegből szabad biztosítani, az állomásoztató terület adataihoz az elemzési réteg alkalmazásainak nincs hozzáférése. Az elemzési rétegben helyezkednek a reporting alkalmazások.
Célszerű, ha az elemzési réteg alkalmazásai egy egységes keretben, egy portál alkalmazásban jelennek meg (jelen esetben ez az InfoView alkalmazás, mely része a szállítandó SAP BusinessObjects terméknek).
A meta-adattár feladata a technikai és intézményi meta-adatok tárolása.
[1] A batch betöltés olyan betöltés, amikor a betöltendő adatokat nagy egységekben (batch-ekben) dolgozzák fel, tehát nagymennyiségű adatot mozgatnak meg egyszerre
Lényeges-e a dashboard külleme?
Cikkünkben, egy fontos kérdést fejtegetünk, mely a dashboard készítésről szól, egészen pontosan, arról, hogy lényeges kérdés-e a vezetői műszerfalak külleme?!
Természetesen Fontos! Hiszen, ha van lehetőségünk látványos megoldást kínálni, miért tennénk másképp? Létezik olyan dashboard, ami azt sugallja, hogy 1995-öt írunk, és meglepő, de amikor ugyan ebből az eszközből valóban naprakész és látványos megoldást lehet készíteni, akkor ez valóban az a tényező, amit csak mértékkel lehet fejlesztőeszközre fogni.
Az ígért HVG-s megjelenés megtekinthető honlapunkon is!
Az online hirdetések dübörögnek mégis úgy gondoljuk, fontos és nélkülönözhetetlen bizonyos magazinokban a megjelenés, ahhoz hogy termékünket minél többen ismerjék meg a haza piacon! Két fő szempontot vettünk figyelembe, adott lap olvasottságát és célcsoportját! Így kapott helyet az AnalytiX mobil eszközre optimalizált megoldása a HVG Smartphone and Tablet és a Sport Auto magazinban!Kellemes olvasást kíván a Processorg marketing csapat!
Hirdetéseinket megtekinthetik az adott linken:
HVG Smartphone and Tablet cikk és címoldal
Sport Auto magazin cikk
Cikkünk különbözik az általános és már-már jól megszokott leírásoktól. A következő sorokban, a gyakorlat áll a főszerepben! Az alábbi hivatkozásra kattintva olvashat a rendszer telepítésének folyamatairól, tapasztalatainkról, amelyek segítenek majd Önnek is a szoftver iPad-en való alkalmazása során.