ADATTÁRHÁZ TERVEZÉSE ILLETVE KIVITELEZÉSE MICROSOFT SQL SERVER KÖRNYEZETBEN

Átírás

1 Budapesti Műszaki és Gazdaságtudományi Egyetem Távközlési és Médiainformatikai Tanszék ADATTÁRHÁZ TERVEZÉSE ILLETVE KIVITELEZÉSE MICROSOFT SQL SERVER KÖRNYEZETBEN Szakdolgozat Konzulensek: Gáspár-Papanek Csaba, BME- TMIT Laki István, Abesse Zrt. Szatmári Tamás 2009.

2 TARTALOM Kivonat... 4 Abstract ) Elméleti alapok Üzleti Intelligencia Adattárház Üzleti modell Technológiai háttér ) Adattárház tervezése Kimball négy lépéses tervezési folyamata Adattárház tervezése a gyakorlatban A logikai séma tervezése Egyéb lépések tervezési megfontolások Fizikai séma megtervezése ) ETL folyamat tervezése Extraction Adatok kinyerése Transformation Átlakítás Load Áttöltés További lépések ) A példa projekt A forrásadatbázis és a vevők igényeinek felmérése

3 4.2 Logikai séma tervezése Tervezési megfontolások Fizikai séma megtervezése SQL server szolgáltatásainak használata SQL Server Management Studio(SSMS) SQL server Integration service (SSIS) SQL Server Analysis Service(SSAS) Visual Studio Business Intelligence development studio(bids) Megjelenítés lehetőségek Integration service folyam megtervezése A dimenziótáblák áttöltése Ténytábla áttöltése Csomagok, Debug és ütemezés OLAP kocka tervezése és processzálása Adatforrás beállítása A kocka processzálása Származtatott mértékek Reportok megjelenítése, konklúzió További fejlesztési lehetőségek Összefoglalás Irodalomjegyzék

4 KIVONAT Az elmúlt időszakban az adattárház döntéstámogatásra való felhasználása egyre népszerűbb. Hatékony technológiát ad a vezetők kezébe, melynek segítségével kompakt mutatószámokat kaphatnak a szervezet egészéről, valamint lehetőséget biztosít, hogy valós időben megvizsgálhassák az eltéréseket egy célérték és a mutatószám között. A szakdolgozat elején szeretném bemutatni az adattárházzal kapcsolatos főbb alapfogalmakat, melyek a későbbi leírásoknál felhasználásra kerülnek. Az elméleti részben végigvezetem az olvasót egy adattárház általános tervezési lépésein, majd az adat feltöltéséhez szükséges ETL folyamaton. A második részben egy konkrét megvalósítást szeretnék szemléltetni, melyhez a külső konzulens jóvoltából egy munkaórákat bejelentő rendszer adatbázishátterének az adattárház felépítését fogom kivitelezni. A példa projekt leírásánál természetesen igyekszem az elméletben leírt struktúra szerint haladni, ezért a logikai és fizikai séma tervezése után az ETL folyamat megvalósítására is nagy hangsúlyt fektetek. A legvégén az adattárház igazi erősségére rámutatva egy OLAP kockát tervezek a rendszerbe, mely felületen lesz majd elérhető. 4

5 ABSTRACT Using the data warehouse as a decision support system became more and more popular in the recent times. It gives an effective technology into the hands of the managers, so it allows getting compact indicators of the whole company, as well as it provides the opportunity to examine the difference between the goals and the realized values in real-time. In the beginning of my thesis I would like to introduce the main concepts in connection with data warehouse, which will be used later. In the theoretical part I will guide the reader through the steps of a general design of a data warehouse, and then through the ETL process, which is necessary to upload the system with data. In the second part, I would like to illustrate a specific implementation. In this project with the help of the external consultant -, I construct a set up of a data warehouse of a project time reporting system. Of course, I try to describe the model project according the theoretical part, so I emphasize the implementation of the ETL system after that I finished the logical and physical schema design. In the end - pointing out the real strength of a data warehouse - I design an OLAP cube system, which is available through an Excel interface. 5

6 1) ELMÉLETI ALAPOK 1.1 ÜZLETI INTELLIGENCIA A Business Intelligence üzleti intelligencia (BI) célja az üzleti döntéshozást megkönnyítendő adathalmazok feldolgozása, ezekből kimutatások, statisztikák létrehozása, gyakorlatilag a szervezet összes szintjén az üzleti döntéshozás valós időben való megkönnyítése. Ezeket az adathalmazokat természetesen a normál ügymenetből származó adatokkal tölti fel, mivel azonban a felhasználás célja eltér, ezért megengedhetők különböző módosítások mind logikailag, mind fizikailag az eredeti adatstruktúrákhoz képest. A szakirodalom szerint [1] a következő alrendszerek figyelhetők meg: Vezetői információs rendszerek (Executive Information Systems) Döntéstámogató rendszerek (Decision Support Systems, DSS) Vállalati információs rendszerek (Enterprise Information Systems) Online Analitical Processing (OLAP) Adat- és szöveg-bányászat Adatvizualizáció Geográfiai információs rendszerek (Geographic Information Systems, GIS) A BI rendszereknek egy nagyon lényeges architektúrája az adattárház felépítés, mely egy lényeges szeletét adja a témának és a legtöbb alrendszert kiszolgálhatja. A forrásadatokat természetesen a napi ügymenet adja, mely sokszor eltérő struktúrájú rendszerekben található meg. A legegyszerűbb megvalósítás esetén Database Bridge segítségével közvetlenül az adatokat tartalmazó rendszeren futtatjuk az elemzéseket, mely nagyobb lekérdezések esetén jelentősen visszavehet az eredeti rendszer teljesítményéből. Egy vezető sem vállalná a lassabb ügyfélkiszolgálást egy éves szintű elemző riport kedvéért. Éppen ezért általában az adatokat bizonyos időközönként átmentik egy másik, elemző rendszerbe, ezt nevezzük gyakorlatilag adattárháznak. Egy másik lényeges szempont, hogy egészen más jellegű rendszerre van szüksége az adatokat betápláló operátornak és az adatokon elemzéseket végrehajtó döntéshozónak. Ezért is szerencsés különböző hardware platformra helyezni az adatokat. 6

7 1.2 ADATTÁRHÁZ Idézet Ralph Kimballtól: Data Warehouse: "The conglomeration of an organization's data warehouse staging and presentation areas, where operational data is specifically structured for query and analysis performance and ease-of-use." [2] Tehát magyarul az adattárház fogalma itt egy adott szervezet azon adatgyűjtő és szolgáltató részeit foglalja magában, ahol a működési adatokat újrastrukturálják riportkészítési, jó teljesítményű és egyszerűen kezelhető elemzésekhez. A két legfontosabb szakértője a témának: Ralph Kimball és Bill Inmon. Éppen ezért két megközelítés alakult ki az adattárház kialakulása szempontjából. Az első modell szerint azonnal adattárházat tervezünk, mely azonnal szolgáltatásokat fog nyújtani az vállalat egésze számára. A másik megközelítés szerint ez nem eladható, a beruházás megtérülése túlságosan kitolódik, ezért modulárisabban kell kezelni a bevezetést [3]. Eszerint először elszigetelt Adatpiacok (Data Mart - DM) jönnek létre, melyekből később, miután működésük bonyolulttá és áttekinthetetlenné válik, kialakul a homogén adattárház (Data Warehouse - DW) struktúra. Ez alapján a két definíció: Adatpiac: Speciális üzleti igényekre, specializált elemzésekre létrehozott, tematikus, a vállalat egy bizonyos csoportja által használt rendszer, mely önmagában is elláthat adattárház feladatokat, azonban a kapacitás és az információszükséglet lényegesen kisebb. Adattárház: A vállalt üzleti folyamatiban integrált, a teljes infrastruktúrát lefedő rendszer. Általában nem felejtő, historikusan tárolt adatokból dolgozik. A 1. ábrán, egy klasszikus adattárház felépítése látható. Az első téglalapban a vállalat egyes osztályainál elérhető forrásrendszereket látunk, különböző formátumokban. A későbbi részletezésre kerülő áttöltő folyamat a staging area-ra helyezi az adatokat, ahol elvégez néhány szükséges átalakítást. A következő két lépcső az adattárház majd az adatpiac. Látható, hogy az adattárház egységes felépítésű, mint az adatpiacok tematikusan találhatók meg. Végül erre kerül az OLAP réteg, mely a későbbiekben kerül részletezésre, az adat analitikus 7

8 feldolgozását segíti. Az utolsó lépcsőben a felhasználók elérhetik a feldolgozott adatokat. 1. ábra Data Warehouse helye a BI struktúrában (forrás: bipminstitute.com) 1.3 ÜZLETI MODELL A legelőször eldöntendő kérdés egy BI rendszer vagy adattárház megtervezésekor, hogy milyen információkat szeretnénk kinyerni az adathalmazból, mire van szükség a vállalati hierarchiában. A legtöbbször a rendszer bevezetése beruházással, munka- és időráfordítással jár, ezért fontos szempont, hogy a döntéshozók lássák a folyamatokba beépülő új információk tényleges szükségességét. Kimball szerint [2] az adattárháznak a következő célokat kell elérnie az üzletmenet szempontjából: Az adatokat könnyen elérhetővé kell tennie Az adatbázisnak konzisztensnek és az elemzések szempontjából kellően naprakésznek kell lennie 8

9 Az adattárháznak adaptívnak, skálázhatónak és könnyen módosíthatónak kell lennie Biztonságosnak kell lennie a legfontosabb üzleti titkokat tartalmazhatja Támogatnia kell a döntéshozást A felhasználóknak el kell fogadniuk az új megoldást Ahogy a felsorolásból is látszik az adattárház tervezés több mint informatikai feladat, együtt kell működnie szorosan a menedzsmenttel. 1.4 TECHNOLÓGIAI HÁTTÉR Az adattárház felépítése és használata során több technológiát felhasznál az adatbáziskezelés témaköréből, a következőkben ezeket a fogalmakat magyarázom, hogy a későbbiekben könnyedén használhassuk a tervezési folyamatban. OLTP: On Line Transaction Processig, azaz online tranzakciófeldolgozás. Az adatoknak egy alapvetően tranzakció orientált tárolási formája, melyekbe a vállalati adatfolyam részeként először kerülnek az adatok. Alapvető cél, hogy az adatokat rekordonként gyorsan, biztonságosan, hatékonyan tudjuk felvinni. OLTP rendszerek alatt értjük általában az adatbázis rendszerek hagyományos alkalmazásait. Gyakorlatilag az adattárházat adatokkal ellátó rendszer, ami biztosítja az adatok inputját. Például: ügyfélkezelés, raktárnyilvántartás, HR rendszer stb. A 1. ábra esetén a Source System-ek OLTP felépítésűek. OLAP: On Line Analitical Processing, az online analitikai feldolgozás. Elemzési szempontokat szem előtt tartó tárolási forma, melyből az OLTP rendszerhez képest kevesebb energiával lehet az adatokat tömbösített formában kinyerni, a nevéből is adódóan alapvetően analitikus céllal. Az OLAP technológia a döntéstámogatás modern eszköze, segíti az adatok elemzését, kezelését, dinamikus megjelenítését. Célja, hogy az adatokat egy más féle struktúrába tárolja el, ezzel megkönnyítve azok elérését. Mindehhez az ember gondolkozásához közel álló dimenzionális szemléletet használja fel. Így nagyobb rálátást és magasabb absztrakciós szintet enged a vezetőknek. 9

10 A két megközelítés közötti lényeges különbséget több szempont alapján elemeztem. (2. ábra) A multidimenzionális szemlélet lényege a csillagséma, mely a későbbiekben részletezésre kerül. A dimenziók kiemelése miatt a fenti adatstruktúrát OLAP kockának is nevezhetjük. Adatmodell szempontjából megkülönböztetünk Multidimenzionális (MOLAP), Relációs (ROLAP) és Hibrid (HOLAP) megoldású OLAP kockákat. Tulajdonságok OLTP OLAP Orientáció tranzakciók adatanalízis Felhasználó vállalat adminisztációt döntéshozók és őket információval támogató végző alkalmazottai alkalmazottak Feladat napi folyamatok döntéstámogatás,hosszútávú követése információgyűjtés és szolgáltatás Adatbázis tervezése Egyed-Kapcsolat tárgy-orientált, csillagséma modell, alkalmazás orientált Adatok aktuális, up-to-date történeti adatok, időben archiválva Aggregált adatok nem jellemző; részletes felösszegzett, egyesített adatok felbontás Adatok nézete részletezett, relációs felösszegzett, multidimenzionális Felhasználók hozzáférése olvasás/írás legtöbbször olvasás, adattárház adatait nem módosítják Hangsúly adatbevitelen információkinyerésen Feldolgozandó tízes nagyságrendű akár milliós rekordszám rekordszám rekord alkalmanként Felhasználók száma viszonylag sok kevés, közép és felsővezetők ált. Prioritás állandó rendelkezésre rugalmasság, felhasználói önállóság állás és megbízhatóság 2. ábra Az OLTP és az OLAP rendszerek összehasonlítása Maga az OLAP technológia rengeteg féleképpen, sok fizikai és logikai sémán megvalósítható. Azonban minden megoldásban vannak bizonyos közös elvárások. Ezeket legjobban a FASMI (Fast Analysis of Shared Multidimensional Information) teszttel lehet kifejezni. 10

11 Az OLAP rendszerek egyik első definícióját Codd adta meg, mely 7 kritériumot említett. Az idők folyamán ez a leírás veszített az időszerűségéből, ezért alkották meg a FASMI tesztet, mely napjaink kihívásaihoz mérten fogalmazza meg az OLAP rendszerekkel szembeni követelményeket. A FASMI teszt esetén a következő kritériumoknak kell megfelelni: Fast: Gyors Analysis: A felhasználó számára szükséges üzleti és statisztikai elemzések elkészítésére alkalmas. Shared: Megosztott Multidimensional Information: Összes adat és származtatott adat elérhető Az OLAP és az OLTP definíciók a felhasználás módjára és adattárolás logikai struktúrájára vonatkoztak. Fontos megjegyezni azonban, hogy ezek a definíciók nem kötik meg a kezünket a fizikai sémahasználat esetén. Az adattárházak esetén két bevett tervezési sémát használnak. OLAP szinten, szinte minden gyártó csillagsémát alkalmaz, míg az adattárház felépítése esetén például az Oracle 3NF sémát preferál. 3NF: Ez egy erősen normalizált séma, melynek célja, hogy az adatbázisban fellelhető anomáliákat kiküszöbölje. Anomáliának nevezzük az adatstruktúrában megtalálható tartalmi ellentmondásokat. Módosítási anomália esetén egy adott entitás egy tulajdonsága megváltozik, ekkor a összes erre utaló attribútumot meg kell változtatni. A beszúrási ellentmondás esetén egy reláció definíciója miatt az adott mező nem lehet NULL értékű, pedig a valóságban nincs értelmezve az adott attribútum. Végül a törlési anomália arra a problémára utal, amikor egy eltávolítandó tulajdonnság törlésével olyan információt veszítünk, amire a későbbiekben még szükségünk lenne, például hiába mondta le az előfizetést egy vevő, az adataira későbbi marketing célból szükségünk lehet. A denormalizált táblákra igaz, hogy egyetlen másodlagos attribútum sem függ funkcionális értelemben teljesen tranzitívan egyetlen kulcstól sem. Egy attribútum akkor másodlagos, ha nem eleme a reláció kulcsának. 11

12 Funkcionális teljes függőség: adott az R reláció és az X összetett értelmezési tartomány. Y értelmezési tartománya funkcionálisan teljesen függ X-től, ha Y funkcionálisan függ X-től, de nem függ funkcionálisan X egyetlen valódi részhalmazától sem. Tranzitív függőség: adott az R reláció; Z értelmezési tartomány tranzitívan függ X értelmezési tartománytól, ha Z funkcionálisan függ X-től, Y-tól és Y függ X-től. [7] ROLAP (Relációs OLAP) kockának nevezünk egy OLAP strukturát, amennyiben a 3NF felépítést követi. Csillagséma: Alapvetően denormalizált séma, melynek feladata a dimenzionális szemlélet fizikai leképezése. Emiatt használja a legtöbb technológia az OLAP rendszerekben található adatok tárolására. (3. ábra) A séma közepén található a ténytábla, melyhez idegen kulcsok segítségével kapcsolódnak a dimenziótáblák. A hópehely sémával ellentétben, itt a dimenziótáblák nincsenek továbbnormalizálva. Egy dimenziótáblához több ténytábla is csatlakozhat. Mivel a Microsoft alapvetően a csillagsémát használja az adattárház tervezésének szinte első lépésétől kezdve, ezért a továbbiakban ezt a megközelítést tekintem mérvadónak. MOLAP (multidimenzionális OLAP) kockának nevezünk egy OLAP strukturát, amennyiben a csillagséma felépítését követi. A HOLAP (Hybrid OLAP) jelentése pedig a ROLAP és a MOLAP megoldás ötvözése. 12

13 3. ábra Csillagséma példa Miután definiáltuk az OLAP kockát, megmutattuk milyen célra érdemes alkalmazni, fontos, hogy lássuk milyen műveleteket lehet elvégezni egy ilyen adatstruktúrán. Ezen műveletek gyors és egyszerű implementálása adja az OLAP megoldás igazi értelmét: Szeletelés: 1dimenzió adott értéken történő rögzítése, ekkor a dimenziószám csökken. Ilyenkor egy adott tulajdonságot rögzítünk, például csak egy konkrét projekthez kapcsolódóan vizsgáljuk a többi tulajdonságot. Részkocka kiválasztása: Értékek megkötése egy adott intervallumra. Például csak egy konkrét időszak listázása Lefúrás: Hierarchia szint csökkentése, például az évek szintjéről lefúrunk a hónapok szintjére Felfelé görgetés: hierarchia szint növelése, hónapok felől távolodunk az évek felé Forgatás: A megjelenített eredményt elforgatja, gyakorlatilag a sorok és oszlopok kicserélése 13

14 2) ADATTÁRHÁZ TERVEZÉSE Az adattárház két meghatározó irányzata közül a Kimball félét fogom részletesen elemezni. Először egy elméleti megközelítést szeretnék bemutatni, mely kiemeli a fontos lépéseket, majd ugyanennek a folyamatnak a gyakorlatba ültetett verzióját részletezem, mely már sokkal konkrétabb problémákkal foglalkozik. Az ETL folyamat definiálása és leírása után a konkrét példa projekten is ezen elveket fogom bemutatni. 2.1 KIMBALL NÉGY LÉPÉSES TERVEZÉSI FOLYAMATA Üzleti folyamat definiálása: A megrendelő kérésére a vállalat információs folyamatainak a legmegfelelőbb helyére kell az adattárházat beépíteni. Fontos, hogy a döntéshozás szempontjából az összes lényeges információforrás szerepeljen a forrásrendszerek között, hiszen csak így kivitelezhető a vállalat egészére nézve releváns információkat szolgáltató döntési támogatási (DSS) rendszer. Határozzuk meg a munkadarabot (Grain). Ez a fogalom gyakorlatilag az, amit a ténytábla egy sora reprezentál. Ezen lépés alábecsülése később súlyos problémákat okozhat. Egy adott összetett struktúrában, amit például egy fával reprezentálunk, mindig a leveleket összefogó fogalmat kell kiválasztanunk. A lehető legelemibb entitás. Dimenziók kiválasztása. Egy egyszerű kérdésre kell a tervezőnek és a megrendelőnek válaszolnia: Milyen szempontok szerint elemeznék az adatokat a felhasználók? Numerikus adatok kiválasztása. Vagyis, amiket a ténytábla tartalmazni fog. A Mit mérünk? kérdésre adandó válasz. [2] 2.2 ADATTÁRHÁZ TERVEZÉSE A GYAKORLATBAN Látni fogjuk, hogy a gyakorlatban sincs másképp, mint ahogy Kimball leírta, gyakorlatilag ugyan ezeken a lépéseken kell végigmenni. A logika séma tervezésénél célunk, hogy olyan struktúrát építsünk fel, ami a vállalat üzleti folyamataiba tökéletesen beleilleszthető, a döntéshozás minősége 14

15 növelhető. A fizikai sémánál ezzel szemben a logikai sémát finomítjuk, olyan modellt igyekszünk alkotni, amelyben nagy mennyiségű adat is biztonsággal és nagy hatékonysággal mozgatható, tárolja az adatokat historikusan, valamint nem utolsó sorban könnyű legyen karban tartani és adminisztrálni A LOGIKAI SÉMA TERVEZÉSE Természetesen az első lépés az üzleti igények felmérésénél kezdődik, ekkor kapjuk meg azokat a megfogalmazott kérdéseket, amikre az adattárház információi alapján szeretnének választ kapni. Ez alapján fogjuk tudni majd a szükséges riportokat elkészíteni. Ezután egy listára össze kell gyűjteni azokat a mérőszámokat, amik szükségesek a riportok megválaszolásához. A következő kérdésekre kell választ adnunk: Mi a mutató neve, Mi a definíciója, Mi a mértékegysége, Hogyan összegezzük fel az idő és más dimenziók mentén, Mi a képlete. Fontos megjegyezni, hogy a különböző adatforrásból, különböző megközelítéssel tárolt adatok sokszor jelenthetik ugyanazt az információt. Az adattárháznak egy fontos feladata, hogy ezeket a mértékeket egységesítse, így létrehozva egy átjárható mértékegységet az egyes osztályok között. A következő lépésben a dimenziók listáját kell összeállítani, majd ezeket, ha lehet hierarchiába rendezni. Fontos szempont, hogy, mind a dimenziók, mind a mérőszámok a felhasználók számára érthetők és egyértelműek legyenek, valamint, hogy fedjék le az összes elemzési igényt, sőt a struktúra adjon lehetőséget esetleg későbbi szempontok beillesztésére is. [8] Összefoglalva tehát a logikai séma tervezési lépésénél a vevőkkel történő konzultáció után meghatároztuk a szükséges mérőszámokat és ezek tulajdonságait, valamint a mérőszámok elemzéséhez szempontokat nyújtó dimenzió attribútumokat. 15

16 2.2.2 EGYÉB LÉPÉSEK TERVEZÉSI MEGFONTOLÁSOK A logikai és a fizikai séma megtervezése között szükséges elvégezni néhány egyéb lépést. A busmatrix létrehozásánál a forrásrendszerek, felhasználói csoportok és a különböző funkciókra hivatott datamart-ok közötti kapcsolatokat határozzuk meg. Vagyis, milyen forrásrendszerből ki és mit láthat. (4. ábra) 4. ábra Busmatrix példa A következő lépés az adatprofilozás, melynek során különböző statisztikákat hozunk létre az adatokról. Ez szükséges a későbbi ETL folyamat minél hatékonyabb létrehozására, hiszen a Transaction folyamat erősen függ az adatok tisztaságától és minőségétől. Adatprofilozó vizsgálatokra alkalmas az a Microsoft által fejlesztett Integrated Service. Pl.: adathosszeloszás-elemzés, kitöltöttségvizsgálat, kulcsképesség-elemzés, mintakeresés, oszlopstatisztikák, értékeloszlás-analízis, összefüggés-elemzés, stb. [5] Szintén ez az elemzés fog választ adni az adattárház attribútumainak a típusára. Hiszen, például két összeszorzandó adat esetén, ha az egyik tört szám, akkor az adattárházunkban is 16

17 lebegőpontos számként fogjuk ábrázolni, míg egész számok esetén nem pazarolunk számára ennyi helyet. A mapping dokumentum mutatja meg, hogy az egyes adatelemek milyen átalakításon fognak keresztülmenni a forrásrendszer és a DW között. Ekkor kell matematikai képlet és adattípus szinten implementálni a megrendelők által leírt származtatott adatokat és a különböző elv szerint tárolt, de ugyanazt az információt rejtő mezők konverzióját. Ekkor kell a felhasználók által elsődlegesen nem használt, éppen ezért az igényfelmérésből esetleg kimaradt egyéb leíró információkat is a sémához illesztenünk. Összefoglalva ezen köztes lépésben különböző tervezői megfontolásokat teszünk, amelyek nélkül nem tudjuk a fizikai sémát hatékonyan megtervezni. A busmatrix és a mapping dokumentum mellett, kevésbé formalizálható tényezőket is át kell gondolnunk, amik a vevők igényeiből, vagy a forrásadatbázis egyediségéből fakadhatnak FIZIKAI SÉMA MEGTERVEZÉSE A fizikai séma megtervezésénél elsősorban Microsoft technológiának a későbbi használatát tartjuk szem előtt, tehát már az adattárház megtervezésénél csillagsémában gondolkozunk. A logikai séma megtervezésénél és a busmatrix leírásánál már látszik, hogy mik lesznek az összetartozó dimenziók, dimenziótáblák, illetve hogyan csoportosítjuk a mértékeket, amikből létrehozhatjuk majd a ténytáblákat (fact table). A ténytábla a csillagséma közepén található, ebben tároljuk az összes mérőszámot. A dimenzió és a ténytáblák között az eddig használt idegen kulcsokat lecseréljük, egy mesterségesen létrehozott surrogate key-t adunk a táblákhoz. Ennek több oka van. Az eddig használt természetes azonosítóknál, mint például a személyi szám, rövidebb és éppen ezért gyorsabban indexelhető egy egyszerű szekvencia. A másik ok a verziózásban rejlik. Amennyiben valamelyik attribútum az DW létrehozása után változhat és ezt a változást követni szeretnénk, akkor a ténytábla és a dimenzió között gyakorlatilag egy másik rekordhoz kell a kapcsolatot létrehozni, 17

18 bár az eredeti OLTP rendszerből származó azonosító nem változott. Tipikus példa a megnősült vevő esete, akinek a házassággal megváltozik a vásárlási szokása (és ezt szeretnénk kimutatni), azonban a személyi szám természetesen nem. A surrogat key kiválóan használható hiányos (például hiányzó cikkszámú) rekordok esetén, amelyek egyébként az összstatisztikák számításához elengedhetetlenek. Szintén a verziózáshoz nélkülözhetetlenek bizonyos egyéb audit információk, például, hogy az adott adat milyen intervallumban dátum tól ig volt érvényes, de ide tartozik a rekordonként a forrásrendszert megjelölő attribútum is. Létrehozzuk az idődimenziót. Ekkor a dátum közvetlen eltárolása helyett egy külön táblában, nekünk tetsző részletességgel tárolhatjuk az dátum információkat, melyeket később egy surrogate key segítségével kapcsolhatunk majd a ténytáblához. Ennek használata sok esetben nem egyértelmű, egyszerű dátumhasználat esetén és kis adattárházaknál eltekinthetünk a használatuktól. Több érv szól azonban használatuk mellett. Az egész számokat több szempontból is hatékonyabban kezeli az SQL server, mint a dátummezőket (partícionálás, indexelés, stb.) Lehetnek olyan rekordok, ahol a dátummezők hiányosan van kitöltve, ekkor a legegyszerűbb mindig ugyanazt a számot hozzárendelni, amit az idődimenzióban is jelezhetünk. Sokszor szükségünk lehet arra, hogy elszakadjunk a szokásos Gergely naptár felépítésétől, például 13. havi kifizetések esetén. Létrehozunk view-kat named query-k helyett. Amikor bizonyos származtatott dimenziókat hozunk létre, kétféleképpen tehetjük meg. Vagy az adattárházra definiálunk view-kat, vagy a Microsoft SQL Server saját BIDS fejlesztőkörnyezetében definiálunk nézeteket, ahol virtuális dimenziókhoz rendelhetünk sql query-ket. Alapvetően mindkét megoldás elfogadott, azonban az előbbi több szempontból előnyösebb: A view-kat egyéb alkalmazások is elérhetik, például a reporting service sajnos az SQL server 2008-as verzióban nem látja a analysis service BIDS környezetében definiált named query-ket. Meg kell határozni az adattárház kezdeti indexstatégiáját. Mivel a kiinduló esetben felmértük a vevő igényeit, láthatjuk milyen lekérdezések lesznek a legtöbbször lefuttatva. Érdemes ezen információk mentén optimalizálni a működést. Erre a legegyszerűbb segédeszköz az SQL serverbe épített Index Tuning Wizard. 18

19 Ezután gyakorlatilag nekiállhatunk a kész adattárház struktúrájának implementálásához. Több hasznos segédeszközt is használhatunk, a dolgozat későbbi részében bemutatott példa projekt esetén a Microsoft Visio segédeszközét preferáltam a tervezéshez. 3) ETL FOLYAMAT TERVEZÉSE Az adattárház struktúrájának megtervezése után a következő lényeges lépés az ETL folyamat tervezése és implementálása. A heterogén adatforrások és az adattárház közötti adatáttöltő lépéseket hívjuk ETL folyamatnak. Részei: Extract, Transform és végül Load. A következő pontokban ezen lépéseket szeretném bemutatni. Az ETL folyamatainak bővebb szemléltetése látható az 5. ábrán. 5. ábra ETL folyamat (forrás: learndatamodeling.com) 19

20 3.1 EXTRACTION ADATOK KINYERÉSE Ez a pont foglalkozik az adatfolyam kiindulási pontjával, a forrásrendszerekkel. Különböző megoldások léteznek arra, hogy heterogén felépítésű adatforrásokból egységesítjük a felhasználandó információkat. A legtöbb esetben egy egyszerű adatfile-t kell valamilyen formában feldolgoznunk, hiszen az adattárház tervezésekor és kivitelezésekor a forrásrendszer már működik, megeshet, hogy egy másik cég, másik adatbázis adminisztrátor végzi a karbantartást. Számára a legegyszerűbb, ha ő maga ütemezi az adatok exportját, egy közös munkaterületre, ahonnan a DW is saját ütemezése szerint tudja importálni az adatfileokat. Többféle fileformátum alapján történhet az export. Beszélhetünk egyszerű szöveges állományról, excel tábláról, vagy strukturált XML állományról. A legtöbb esetben a leghatékonyabb az első megoldás, ebben az esetben igényel a legkevesebb overhead-et az adatok feldolgozása. Természetesen amennyiben a forrás és az adattárház közös rendszeren fut, akkor közvetlenül is elérhetjük az adatokat. A legtöbb adatbázis rendszernek van adatbetöltő modulja, SQL server esetén az Integration Service, míg Oracle rendszernél a SQL * Loader. Amennyiben a forrás és a DW is ugyanazt a software-t használja, a legegyszerűbb, ha a gyártó saját bináris flat file-jába exportáljuk, ebben az esetben nem kell törődnie az adatok strukturálásával, gyakorlatilag egyből egy üres memóriaterületre pakolhatja a friss importot. Fontos cél, hogy az extract folyamat során a forrásrendszereket a lehető legkevésbé és a lehető legrövidebb ideig terheljük. (Természetesen egy napi szintű áttöltés a legtöbb esetben éjszaka történik, ekkor lényegtelen a terhelés, de a például a munkaidő kezdetéig mindenképpen be kell fejeződnie.) A rendszeres adatáttöltés esetén rengeteg erőforrás spórolhatunk meg, ha valamilyen formában szűrjük az áttöltendő adatokat, feleslegesen ne mozgassuk a már létezőket, törekedjünk az inkrementális, tehát a változásokat rögzítő áttöltésre. Gondoljunk csak bele, ha mindig a legújabb adatokkal töltenénk fel az adattárházat, akkor elveszne az a nagyon is kellemes tulajdonság, hogy néhány attribútum esetén rögzíti a változást, ez a verziózás. A legtöbb adatbázis rendszer 20

21 támogatja a Change Data Capture funkciót, ekkor a legutóbbi áttöltés óta változott adatokat egy külön táblában gyűjti. Ebben a fázisban látjuk el az adatokat különböző audit információkkal, amelyeket az előző fejezetben már részleteztem. SQL server esetén az Extraction folyamat eredményeként az adatok egységes formában átkerülnek a staging területre. A 6. ábrán a nagy E és T betű közötti kék henger ez szemlélteti. 6. ábra ETL folyamat SQL server esetén (forrás: technet) 3.2 TRANSFORMATION ÁTLAKÍTÁS A transzformációs lépésnél a legfontosabb cél, hogy az adatprofilozás során előbukkant adatinkonzisztenciákat megszüntessük, tehát az adatink tiszták legyenek. Az előfeldolgozás során ellenőrizzük az adatok kódolását, bizonyos attribútumokat (pl.: dátum) egységes formára hozunk, illetve elvégezzük a szükséges algoritmikus átváltásokat (pl.: Celsius -> Fahrenheit). A mező szintű transzformációs lehetőségek közé tartozik, amikor összevonunk (kereszt+vezetéknév) vagy szétbontunk mezőket. Az adattisztításhoz rengeteg szoftver áll rendelkezésünkre, mindemellett a legtöbb esetben az adatprofilozás során felismert hibákat attribútumonként kell megvizsgálni és így beállítani rájuk valamilyen algoritmust. A következő funkciókkal a legtöbb rendszer könnyedén megbirkózik. A hiányzó attribútumok 21

22 esetén két dolgot tehetünk, vagy nem töltjük át az adatokat, vagy egy adott konstanssal helyettesítjük, ezáltal elkerülve a későbbi elemzésekből fakadó félreértéseket. Az ellentmondó adatokat szűrhetjük hibalistába, amit emberi segítséggel tisztíthatunk meg. A zajszűrés esetén különböző matematikai algoritmusokkal vizsgálhatjuk az adatok statisztikai hátterét, normalizálás esetén egy adott intervallumra képezhetjük le a adatokat, diszkretizálás során pedig véges számú értékhez rendelhetünk egy alapvetően folyamatos adatsort. 3.3 LOAD ÁTTÖLTÉS A Load fázis feladata, hogy az átalakítások elvégzése után a staging területről a megfelelő struktúrába pakolja az adatokat a DW-ben. Ehhez leginkább a fizikai séma tervezésénél leírtak szükségeltetnek. Ebben a fázisban először a dimenziókat töltjük át a megfelelő helyre, figyelve a verziózásból fakadó változtatásokra. Ekkor tesszük hozzá a surrogate key-t a táblához. Alapvetően kétféle verziókövetési módszert ismerünk. Az első esetében új kulcs felvétele mellett egy új rekord kerül az adott dimenzióba. Ekkor kiegészítjük két dátum típusú mezővel is a táblát, ezekkel jelezzük az érvényesség kezdetét és végét. A másik esetben (például egy vevő -jének a megváltozása esetén) gyakorlatilag nincs szükségünk a korábbi adatra, viszont minden fellelhető korábbi verzióban is ki kell cserélni az adott attribútumot. A ténytáblák feltöltése esetén szintén lecseréljük a kulcsokat, majd a megfelelő dimenzió aktuális eleméhez kötjük a bejegyzést. Ezután már könnyedén átkerülhetnek az eddigi struktúrába az adatok. 3.4 TOVÁBBI LÉPÉSEK A folyamatos és hibátlan működéshez további teendők szükségesek. Amennyiben szeretnénk az adattárházunkra OLAP kockát építeni, ezek után könnyedén megtehetjük, a ciklikus ETL folyamat végére a kocka processzálását is beépíthetjük, ekkor a reportokban is mindig a legfrissebb adatok fognak kerülni. 22

23 A megfelelő időzítés megválasztása legalább olyan fontos, mint az egyéni monitoringrendszer. A legtöbb adatfolyamba beépíthetők saját naplózó algoritmusok, ahol bizonyos hibák teljesülése esetén értesítve van az adminisztrátor, hiszen a másnapi elemzéseknél a döntéshozóknak tisztában kell lenniük azzal, hogy mikoriak a használat adatok. 23

24 4) A PÉLDA PROJEKT Az eddigiekben elméletben leírt tervezési és ETL folyamatot szeretném a következőkben a gyakorlatban is bemutatni, rávilágítva az SQL server szoftvercsomag lehetőségeire. A tervezés során az előző pontokban leírt folyamatot fogom implementálni 4.1 A FORRÁSADATBÁZIS ÉS A VEVŐK IGÉNYEINEK FELMÉRÉSE A példa projektet használó vállalat szoftverfejlesztéssel foglalkozik. A példa adatbázis az egyes projektekre és az azon belüli projekt-mérföldkövekre fordított munkaórát követi és auditálja. A feladat, hogy erre az adatbázisra kerüljön adattárház. Természetesen a klasszikus tervezési lépésekből az adatbázis sajátossága miatt néhány lépés elhagyható, ennek részletezése a tervezési megfontolások pontba kerül. Mivel egy OLTP adatbázisról van szó, ráadásul az adattárházunk ugyanabban a rendszerben fog működni, mint a forrásadatbázis, ezért a projekt valójában közelebb áll egy adatpiac megvalósításához, azonban egy bizonyos szint alatt a adattárház és adatpiac építés hasonló, ráadásul az általam is szem előtt tartott Kimball féle tervezési elvek [2] az adattárház bevezetés első lépéseként a független DM-ek kiépítését tűzik ki célul. A példa projekt fejlesztésével szeretném szemléltetni a 3. pontban leírt általános elveket, valamint igyekszem bemutatni a Visual Studio Business Intelligence Development Studio-ban, mint az Analysis Service és az Integration Service fejlesztőeszközében rejlő lehetőségeket. A sémák tervezésének elkezdése előtt tisztában kell lennünk a forrásadatbázis felépítésével, a későbbi adattárházban szereplő attribútumok OLTP sémában betöltött szerepeivel. A projekt célja természetesen, hogy a vevői igényeket majd egy megfelelő riportáló eszköz segítségével publikáljuk, így segítve a cég döntéshozóit. Ehhez szükséges lesz majd egy OLAP kockát építeni a megtervezett adattárház struktúrára. 24

25 Tehát a lépések: 1. Adattárház tervezése (Logikai, fizikai séma) 2. ETL folyamat tervezése 3. OLAP kocka tervezése 4. Riportáló eszköz használata, teljesítményteszt PK ProjectTaskCostType ProjectTaskCostTypeId ProjectTaskCostTypeName PK ProjectType ProjectTypeID ProjectTypeName PK ContractMilestoneType ContractMilestoneTypeId ContractMilestoneTypeName PK Project ProjectId FK2 ProjectProjectTypeId ProjectName FK1 ProjectCustomerId ProjectClosed ProjectClosedDate ProjectStartDate ProjectManager ProjectFreetext1Caption ProjectFreetext2Caption ProjectFreetext3Caption ProjectFreetext4Caption ProjectFreetext5Caption IsDeleted PK Customer CustomerId CustomerName IsDeleted PK FK1 Contract ContractId ContractCustomerId ContractName ContractDescription IsDeleted PK FK1 FK2 ProjectTask ProjectTaskId ProjectTaskProjectId ProjectTaskName IsDeleted ProjectTaskPlannedWorkHour ProjectTaskOverhead ProjectTaskCost ProjectTaskCostTypeId PK ContractMileStoneProjectTask ContractMileStoneProjectTaskId FK1 ContractMileStoneProjectTaskContractMileStoneId FK2 ContractMileStoneProjectTaskProjectTaskId IsDeleted ContractMilestoneProjectTaskIncomeValue PK FK1 FK2 ContractMilestone ContractMilestoneId ContractMilestoneContractId ContractMilestoneMilestoneName ContractMilestoneMilestoneDate ContractMilestoneMilestoneIncomeValue ContractMilestoneDescription IsDeleted ContractMilestonePlannedWorkHour ContractMilestoneTypeId TimeReportEntry PK TimeReportEntryId PK TimeReportEntryApprovalState TimeReportEntryApprovalStateIdApprovalStateId TimeReportEntryApprovalStateName FK1 TimeReportCalendarId FK3 TimeReportEntryExpertId FK2 TimeReportEntryContractMilestoneId TimeReportEntryTRWorkHours TimeReportEntryWorksheetWorkHours TimeReportEntryApprovedWorkHours FK4 TimeReportEntryTimeReportEntryApprovalStateId FK5 TimeReportEntryTimeReportEntryWorkHoursTypeId TimeReportEntryTRComment TimeReportEntryWorksheetComment TimeReportEntryApprovedComment TimeReportEntryFreetext1 TimeReportEntryFreetext2 TimeReportEntryFreetext3 TimeReportEntryFreetext4 TimeReportEntryFreetext5 PK PK Calendar CalendarId CalendarDate CalendarWorkDay CalendarWeek TimeReportEntryWorkHoursType TimeReportEntryWorkHoursTypeId TimeReportEntryWorkHoursTypeName PK ExpertAttribute ExpertAttributeId ExpertAttributeValidFrom ExpertAttributeValidTo FK1 ExpertAttributeExpertId ExpertAttributeWorkWeight ExpertAttributeWorkRate PK Expert ExpertId ExpertLoginName ExpertFullName Expert ExpertCategoryId PK Target TargetId TargetYear FK1 TargetExpertId TargetUtilization TargetCoverage 7. ábra Forrásadatbázis adatmodellje 25

26 A forrásadatbázis feladata, hogy egy adott projekten dolgozó szakemberek munkaóráit kövesse, valamint ez alapján képes legyen értékelni a projekt futását, valamint a szakember teljesítményét. A projektmenedzser bizonyos időközönként jóváhagyja a jelentett óraszámokat és összeállítja a megrendelő felé a számlázott óradíjat. Az ehhez szükséges egyéb vevő információkat is tartalmazza az adatbázis. Természetesen a példaprojektben a DB egy jól meghatározott szeletével foglalkozok. A forrásadatbázis adattárház szempontból releváns táblái a 7. ábra alapján: TimeReportEntry tábla (TR): egy munkaegység rögzítése történik ebben a táblában, három fontos mérték található itt: ReportedWorkHour (RWH) Az alkalmazott által jelentett óraszám ApprovedHour (AH) A projektvezető által jóváhagyott óraszám ApprovedWorksheetHour (AWH) Az ügyfél felé számlázott jóváhagyott óraszám Project tábla: Minden TR bejegyzést hozzá kell rendelni egy projetktaskhoz, illetve minden projekttask egy meghatározott projekthez tartozik. A projektnek különböző egyéb leíró jellegű attribútuma van, projektvezető neve, projekt kezdése és vége. Ebben a táblában is található egy lényeges mérték, melynek majd a ténytáblába kell kerülnie, ezt a projektvezető tölti ki bizonyos időközönként. Az overhead az a tervezett csúszás, amennyivel a tervezett plannedhour értékhez képest már most várhatóan túl fog csúszni a projekt. Calendar tábla: A logikai séma tervezésénél már szót ejtettem a külső calendar tábla értelméről. A relációs adatbázis már eleve ezen elvből indul ki, ezért minden TR bejegyzést a calendar táblához kapcsolódó idegen kulccsal köt össze. Találhatók még egyéb leíró információk: A bejegyzést végző személy elérhetőségei, valamint az ügyfelek, akikhez projektek és szerződések kapcsolódnak. 4.2 LOGIKAI SÉMA TERVEZÉSE A logikai séma tervezésének első lépéseként a megrendelői igények felmérése következik. Az adatbázist jelenleg is használják származtatott statisztikus 26

27 mértékek kiszámítására, azonban csupán a Sharepoint server (SPS) adta keskeny lehetőségeken belül. A SPS nem alkalmas súlyozott átlagolásra különböző absztrakciós szinteken, például szükségünk van cégszintű mutatószámokra a projektek összességéről, súlyozva fontosságuk, méretük alapján. Először a szükséges metrikákat kell meghatározni: Completed (%): Egy adott projektre vetítve a jóváhagyott óraszámot el kell osztani a jelentett óraszám és a csúszás összegével. Képlet: Approved Hour / (Reported Hour + ProjektTaskOverhead). Lebontható napi és projekttask szintre. Overdue: projekt futása közbeni arányosítás. Képlet: Planned Hour / (Planned Hour + overhead). Szintén napi és projekttask szinten értelmezhető. A két számított metrikához még hozzátartozik a TR-ben található 3 mérték, melyeket meg kell majd tudni jeleníteni egy adott napig szummázva is. Mivel csupán egy forrásadatbázis van, ezért a különböző OLTP forrásadatbázisból származó, de ugyanazt az entitást leíró adatok egységesítésével gyakorlatilag nem szükséges foglalkozni. Az eredeti DB-ben megadott mértékegységek átváltásra nem szorulnak, semmilyen konverziót nem kell végeznünk. Ez egyaránt a megrendelő kérése és a tervező megfontolása. A dimenziók és hierarchiák meghatározása: Az egyik dimenziócsoport a projekt hierarchia. Itt egy struktúrában szeretném megjeleníteni a projekttask-ot és a projekt nevét. A calendar tábla is egy hierarchiának minősül, amelyet az OLAP kockát építve fogunk jobban szétbontani. A logikai séma tervezésénél a szokásos gyakorlatot tartottam szem előtt. A vevő igényeit felmérve az OLTP adatbázis alapján megállapítottam a szükséges származtatott és a DB-ből azonnal kinyerhető metrikákat, majd a dimenziókat, amik alapján a mérőszámokat összegezni szeretnénk. A dimenziók esetén egyelőre nem foglalkoztunk azzal, hogy milyen struktúrában szeretnénk tárolni a táblákat, 27

28 csupán az azonos típusú attribútumokat csoportosítottuk és kialakítottunk természetes hierarchiákat az adatok között. 4.3 TERVEZÉSI MEGFONTOLÁSOK A projekt több szempontból is eltér egy hagyományos DW tervezésétől, ezeket a megfontolásokat, tervezői észrevételeket gyűjtöttem össze: Csupán egyetlen forrásrendszer található, azonban az ETL folyamat egy data mart esetén is tökéletesen végigkövethető. Az adatokat tisztának tekintjük, így nem foglakozunk a különböző adattisztítási eljárásokkal. Minimális változtatásokat kell elvégezni a mértékeken és dimenziókon, nincs szükség a részletezett összevonási, normalizálási és diszkretizálási folyamatokra. A relációs adatbázis eleve egy csillagsémához hasonló sémát alkalmaz Mivel egy forrásadatbázisunk van, ezért a busmatrix megtervezése felesleges. A mapping dokumentum a származtatott mértékeket tartalmazza, az előző pontban már részletezett Completed és overdue attribútumokat. A fent leírt okokból a projekt esetén a hangsúly a származtatott adatok kalkulálásán és az adatáttöltés folyamatán van. 4.4 FIZIKAI SÉMA MEGTERVEZÉSE A fizikai séma megtervezésénél a fact táblák és az összetartozó dimenziókból felépülő dimenziótáblák közötti kapcsolatokat, az adattárház fizikai sémáját határozzuk meg. A mértékek felsorolásánál tisztán látszik, hogy a kívánt mutatószámoknak elegendő egy ténytábla létrehozása. A Ms Sql server támogatja több ténytábla sémába illesztését, erre azonban jelenleg nincs szükség. A dimenziók meghatározásánál 2 összetartozó csoport alakult ki: a projekt és a calendar attribútumai. Mivel a naptáradatok eleve külön táblában szerepelnek ezért nem kell foglalkozni a dátumok szétbontásával. 28

29 A dimenziók esetén külön struktúrában fognak szerepelni a hierarchiában szereplő adatok és az összes többi attribútum. A későbbiekben látni fogjuk, hogy a kialakítandó struktúra és az azt feltöltő ETL taszk gyakorlatilag három táblába mozgatja majd az adatokat: fact tábla, projekt tábla és calendar tábla. A hierarchia felépítésére egy úgynevezett szerepjátszó dimenziót fogok használni, melyet az SQL server fejlesztőkörnyezete támogat. Ebben az esetben a fizikai sémában nem kell a hierarchiában szereplő attribútumokat külön válogatni, elegendő ezt majd a fejlesztőkörnyezetben megtenni. A projekttask és a projekt táblákat két külön dimenzióban jelenítem meg, pedig alapvetően egy hierarchiába fognak tartozni. Ezt elsősorban a szerepjátszó dimenziók szemléltetése céljából alakítottam, másrészt a későbbi fejlesztések során így könnyebben helyezhetünk erre az attribútumra verziókövetést. A vevő igények között első körben azonban nem szerepelt ez az elvárás. A 8. ábra a fenti lépéseket foglalja táblázatba. Rekord Táblanév Típus Hierarchia Year DimCalendarHierarchy Dimenzió Calendar Month DimCalendarHierarchy Dimenzió Calendar Day DimCalendarHierarchy Dimenzió Calendar ProjectName DimProjectHierarchy Dimenzió Project ProjectTaskName DimProjectHierarchy Dimenzió Project ProjectName DimProject Dimenzió - ProjectClosed DimProject Dimenzió - ProjectManager DimProject Dimenzió - ProjectTypeName DimProject Dimenzió - CustomerNAme DimProject Dimenzió - ProjectStartDate DimProject Dimenzió - ProjectClosedDate DimProject Dimenzió - PlannedHour Fact Mérték - ApprovedHour Fact Mérték - WorsheetHour Fact Mérték - Overhead Fact Mérték - Taskcost Fact Mérték - Overdue Fact Mérték - Completed Fact Mérték - Sum_approved Fact Mérték - 8. ábra a fizikai séma adatai 29

30 A kialakított csillagséma pedig a későbbi 12. ábrán található. 4.5 SQL SERVER SZOLGÁLTATÁSAINAK HASZNÁLATA Az ETL folyamat és a végcélként kitűzött OLAP kocka megtervezése előtt szeretném bemutatni a SQL Server szoftvercsomag elemeit, melynek segítségével megoldottam a következő lépéseket SQL SERVER MANAGEMENT STUDIO(SSMS) A SSMS gyakorlatilag az adatbázisok menedzselésére szolgál. Képesek vagyunk a sémákat és a táblákat listázni, SQL utasításokat futtatni, valamint különböző formátumokban a tábla struktúrákat exportálni. Mivel a jelenlegi projektben mi látjuk el az eredeti forrásadatbázis DBA-ját is, ezért hozzáférhetünk az eredeti struktúrához. Ezt kihasználva, az eredeti táblák sémáját SQL parancsok formájában exportáltam, majd a megtervezett táblákat kialakítottam. Így kerültem el, hogy véletlenül az áttöltendő adatok attribútumának más típust adjak meg. Ebben az eszközben hoztam létre a DW adatbázist, amely tartalmazza az áttöltendő táblák struktúráját, azonban a köztük létező függőségek használata a DW esetén felesleges, az adatok konzisztencia vizsgálatát az ETL folyamat fogja ellátni SQL SERVER INTEGRATION SERVICE (SSIS) Az SSIS szerepe az adattárház teljes ETL folyamatának lefedése. A 2008-as verzióban már gyakorlatilag teljes funkcionalitással vagyunk képesek az adatinkat több forrásból a szükséges átalakításokat elvégezve a DW-be tölteni, mindezt úgy, hogy az adatbázis rendszerbe ütemezhető taszként beépül. A forrás és a cél rendszer gyakorlatilag bármi lehet az Oracle-től kezdve az IBM-ig az összes nagyobb gyártót támogatja, sőt még excel táblából vagy flat file-ból is olvashatunk be, amelyeket a lokális filerendszerben vagy FTP kiszolgálón tárolhatunk. Az SSIS csomagot a BIDS-ben definiáljuk, ebben írjuk le az adatátöltő taszkot. Egy csomag két fő részből épül fel egy control és egy data flow összetevőből. A control részegység határozza meg a logikát. Például küld, ha végeztünk az áttöltéssel, illetve az adatbázisban található tárolt eljárások lefuttatásának is ide kell kerülnie. A data flow mozgatja és alakítja az adatokat. Az adatfolyamon belül három fontos részt különítünk el. A forrásadatokat, a céladatokat és a transzformációs taszkokat. 30

31 Ahogy egy hatékony, ETL folyamatot támogató programtól elvárható a transzformációs taszkok között támogatja a legtöbb a tervezési lépéseknél részletezett adatmanipuláló megoldást. Az ETL folyamattal a következő pontban foglalkozom részletesen SQL SERVER ANALYSIS SERVICE(SSAS) Miután kész az adattárházunk struktúrája és az adatátöltés is ütemezetten, pontosan megvalósul, a vevők igényeinek maximális kielégítése céljából szükségünk van egy eszközre, amely a riportoló alkalmazások számára implementál egy OLAP kockát. Ezen probléma megoldására létezik a SSAS, amelyben a megfelelő forrásadatok megadása után, szintén grafikus felületen (BIDS) tervezhető az OLAP kocka VISUAL STUDIO BUSINESS INTELLIGENCE DEVELOPMENT STUDIO(BIDS) Az SQL server programcsomag része egy a Visual Studio-ba beépülő plugin, melynek segítségével SSAS, SSIS projekteket hozhatunk létre. A BIDS támogatja, hogy a létrejött projekteket egyből az adatbázisba töltsük, vagy akár egy külön fileba.xml felépítéssel kimentsük MEGJELENÍTÉS LEHETŐSÉGEK Az OLAP kocka elkészítését követően az adatokat valamilyen riportoló alkalmazás segítségével megjeleníthetjük. Létezik az SQL serveren belül a Reported Service, ezzel a szolgáltatással azonban jelenleg nem foglalkozunk. A legegyszerűbb megjelenítési formát az Ms Excel adja, ahol pivot táblák adatforrásaként megadhatunk SSAS servert. Ekkor az Excel felületén megjelennek a metrikák, valamint a lehetséges dimenzió adatok, egyszerű drag-and-drop módszerrel kialakíthatjuk a táblázatunk, amit utána egy Sharepoint szerver felületre vagy egy statikus xls file-ba is kimenthetünk. A sharepoint server egy portálmotor, amelynek segítségével a teljes üzleti intelligencia megoldásra kínálhatunk felületet. 4.6 INTEGRATION SERVICE FOLYAM MEGTERVEZÉSE A korábban ismertetettek értelmében az SSIS az ETL folyamat teljes megvalósítására alkalmas. 31

32 Első lépésként a control flow-t kell megterveznünk. (9. ábra) A data flow task beillesztésével tudjuk majd az adatinkat a forrás és a cél között mozgatni. Az execute SQL task segítségével SQL utasítást futtathatunk, ennek szükségessége a későbbiekben részletezésre kerül. 9. ábra SSIS controll flow Ha Data Flow-ra kattintunk a rendszer már át is ugrik egy másik fülre, ahol összeilleszthetjük az adatfolyamunkat. Ebben a nézetben táblánként kell megvalósítanunk az áttöltést, hiszen más adatokra más konverzió lehet szükséges A DIMENZIÓTÁBLÁK ÁTTÖLTÉSE 10. ábra Data flow - Dimenziótáblák Minden Data flow esetén szükség van egy forrás és egy cél adatbázisra, valamint a közöttük lévő átalakító taszkokra. A forráshoz és a célhoz is először connection managereket kell felvennünk. Itt látszik a SSIS sokszínűsége, hiszen OLE db és ADO.NET db-n túl még flat file-t is tud kezelni forrásként. Amennyiben több 32

33 adatforrásból szeretnénk felölteni egy táblát, lehetőség van több kezdő, de akár több destination db-t is megadni. A fejlesztőkörnyezet felülete grafikus, drag-and-drop módszerrel tudjuk az egyes taskokat reprezentáló téglalapokat a munkafelületre húzni. A taskok között nyilak mutatják az adat áramlásának irányát. Minden taskból egy piros és egy zöld nyíl mutat kifelé. Amennyiben a task sikeresen lefutott a folyamat a zöld nyíl irányába megy tovább. Ahogy az a 10. ábra esetén is megfigyelhető (a Lookup taszk után kétfelé ágazik) néha természetesen elágazás esetén több irányba folyhat tovább az adat, ekkor általában valamilyen szempont alapján több halmazra bontjuk szét. Minden folyam esetén a source db taskban ki kell választanunk a megfelelő connection manager-t, majd a szükséges táblából kiválaszthatjuk a megfelelő attribútumokat. A mi esetünkben egy SQL kifejezés lefuttatásával kapjuk meg a pontos forrásadatokat és struktúrájukat. [9][10] 3 dimenziótáblát terveztünk megvalósítani, ezek kezelése 3 különböző módon történik. A Project tábla esetén a Lookup task-ot fogjuk alkalmazni. A tervek szerint az adatátöltő taszk hetente le fog futni, hogy az adatokat frissítse a DW-ben. A projekt dimenziótábla esetén választhatnánk azt az opciót, hogy minden esetben töröljük a DW-ben található adatokat és újból áttöltjük az egészet. Ez rengeteg erőforrás elpazarolásával jár, ezért kihasználjuk, hogy a project dimenzió elemeit megkülönböztethetjük egyértelműen az ID alapján. A lookup task ezt a feladatot látja el. A bejövő adatokat összehasonlítja egy mintával, melyet a DW adatbázisból kap meg. Ezután kettébontja, amik már szerepelnek azokat a 10. ábra első folyamatának második ága alapján egy SQL utasítás segítségével frissíti, míg a nem létezőket a bal oldali ágon keresztül inserteli az új táblába. Az összehasonlítás a DW és a forrásadatok esetén az ID alapján történik, ezt a kötést meg kell adni a task beállításainál. Továbbá az SQL server destination task esetén egy apróságot még át kell állítani. Az első tesztelésnél abba a hibába futottam, hogy a két task, az OLE db command és az sql destination nem tudott párhuzamosan lefutni. Később kiderült, hogy az sql utasítás idejére a bal oldali task zárolja a táblát, amit a setup oldalon található checkbox segítségével ki tudunk iktatni. 33

34 A probléma egy másik megoldása látható a projekttask dimenzió esetén. Az SSIS 2008-as verziójától kezdve megtalálható a Slowly changing dimension (SCD) a taskok között. Az attribútumokat három csoportba sorolja a SCD: vannak, amik sohasem változhatnak, amennyiben ezek között módosulást talál hibát jelez; a második csoport a változó attribútumok, amiknek változás esetén módosulnia kell; a harmadik pedig, amik esetén a változását követnünk kell verziókövetéssel. Jelen esetben a második opciót felhasználva hasonló eredményre jutunk, mint a look-up task-kal. Két csoportba vannak bontva az adataink, az egyik adag update utasítás hatására frissül, a másik adat pedig insert hatására új rekordként kerül a DW-be. A calendar dimenzió folyamatos frissítésére nincs szükség, ezért nem szerepel az SSIS package-ben sem. Elegendő bizonyos időközönként új ID-kat generálni az új dátumok számára. Ha foglalkoznánk az adatok verziókövetésével, akkor a derived column task segítségével az adatfolyamba akár egy új attribútumot is illeszthetünk. Itt kell megoldani a különböző átalakításokat is, például, ha valahol össze szeretnénk fűzni a vezeték és keresztnevet egy attribútummá TÉNYTÁBLA ÁTTÖLTÉSE A fact tábla esetén több érdekes tervezői döntést is szükséges volt meghozni. A vevők igényeinek a felmérése után realizálódott, hogy a TR adatokra csupán napi szintű lebontásig van szükség. Ezért teljesen felesleges az összes rekord áttöltése a DW-be, sokkal hatékonyabb, ha a mérőszámokat napi szinten szummázuk. Ez alapján a data source-be a következő query került: 34

35 SELECT dbo.projecttask.projecttaskprojectid, dbo.projecttask.projecttaskcosttypeid, SUM(dbo.TimeReportEntry.TimeReportEntryTRWorkHours) AS Workhour, SUM(dbo.ProjectTask.ProjectTaskPlannedWorkHour) AS PlannedHour, SUM(dbo.TimeReportEntry.TimeReportEntryApprovedWorkHours) AS ApprovedHour, SUM(dbo.TimeReportEntry.TimeReportEntryWorksheetWorkHours) AS WorksheetHour, SUM(dbo.ProjectTask.ProjectTaskOverhead) AS overhead, SUM(dbo.ProjectTask.ProjectTaskCost) AS taskcost, dbo.projecttask.projecttaskid, TimeReportCalendarId FROM dbo.projecttask INNER JOIN dbo.timereportentry ON dbo.projecttask.projecttaskid = dbo.timereportentry.timereportentryprojecttaskid GROUP BY dbo.projecttask.projecttaskprojectid, dbo.projecttask.projecttaskcosttypeid, dbo.projecttask.projecttaskid, TimeReportCalendarId Tisztán látszik, hogy csoportosítva szummázzuk ProjekttaskID szerint. Valamint az egyik mérték overhead egy távolabbi táblából van idehúzva, mint mérték, ezért kell a join. Fontos optimalizálási lehetőségeket találhatunk a fact tábla átöltésének ésszerűsítése. Az SQL server 2008-től kezdve található egy change data capture (CDC) nevű szolgáltatás a csomagban, amely képes rá, hogy egy bizonyos időpillanat, például az áttöltő task lefutása utáni adatváltozásokat tárolja, hogy a legközelebbi áttöltés esetén csak ezzel kelljen foglalkozni. Sajnos a jelenlegi forrásadatbázisunkban nincs ilyen szolgáltatás, ezért ID hiányában a legegyszerűbb egyszerűen minden áttöltés esetén eldobni az összes adatot, majd újratölteni őket. Az adatok eldobása a control flow-ban lefuttatott sql utasítás segítségével történik (9. ábra). Ebben a folyamatban lenne lehetőség a tényadatokat valamilyen attribútum alapján, például idő alapján particionálni, azonban jelenleg 7400 sort tartalmaz a ténytábla, amely nem indokolja a particionálást. 35

36 4.6.3 CSOMAGOK, DEBUG ÉS ÜTEMEZÉS Lehetőség van akár több különböző csomagba pakolni a ténytábla és a dimenziótábla áttöltését, amennyiben szeretnénk külön időpontokban lefuttatni őket. A tervezés alapján a taskok hetente, hétvégén futnának le, amikor a forrásadatbázis terhelése elhanyagolható. Ezért nem indokolt az ilyen jellegű szétválasztás. Ha elkészült a folyamat, akkor a BIDS-en belül lehetőség van lefuttatni, hibát keresni. Ekkor az egyes adatfolyamok éleire kiírja, hogy hány rekord áramlott rajtuk keresztül, valamint a task-okat is külön jelöli, hogy sikeresen lefutottak-e. Érdemes az adatok feltöltése után is többször lefuttatni, hátha valamilyen hiba a BIDS-ben merül fel. Egy Integration Services csomagot három különböző módon (helyen) tárolhatunk: Az SSIS package store-ban, fájlrendszerben vagy az msdb adatbázisban. Jelen esetben egy lokális dtsx kiterjesztésű xml állományba mentettük a folyamatot. Az ütemezés beállítása a Management Studio segítségével történik. Egy új job-ot létrehozva a legördülő menübe megjelenik a SSIS csomag kiválasztásának lehetősége, ezután már csak a filerendszerből ki kell böngészni a megfelelő csomagot és ütemezni. Újabb hibakeresési és a SSMS-en kívüli ütemezésre ad lehetőséget, hogy a dtexecui program futtatásával és a csomag megadásával egy command line-ból futtatható parancsot kaphatunk. 4.7 OLAP KOCKA TERVEZÉSE ÉS PROCESSZÁLÁSA Elérkeztünk az egyik leglényegesebb elemhez a kivitelezésben. Kimball szerint [2] üzletileg roppant fontos, hogy a vevő használhatónak ítélje az adattárház létezését, hiszen csak ekkor fognak költeni a beruházásra. Ennek leglátványosabb módja, ha az adatbázisra OLAP kockát építünk, majd valamilyen riportoló eszköz segítségével elérhetővé tesszük a felhasználók felé. Az SSAS lesz segítségünkre, melyet az SSIS-hez hasonlóan a BIDS-en keresztül tudunk elérni, a projekt fejlesztése itt történik. Amikor nyitunk egy új projektet, a 36

37 bal oldali solution ablakban szépen egymás után látszanak a szükséges lépések. (11. ábra) ADATFORRÁS BEÁLLÍTÁSA Legelőször egy adatforrást (data source) kell kiválasztani, majd egy data source view-ban megadni, hogy mely táblákat szeretném használni. A data source viewban ezután látszanak az általunk kiválasztott táblák felrajzolva. Mivel az SQL server felfogása alapján a DW elejétől kezdve multidimenzionális logikai adatsémát támogat, ezért itt már nem lesz sok dolgunk. Érdemes a táblák közötti logikai kapcsolatot megadni, egyszerűen húzzuk össze az összetartozó ID-kat. Az OLAP elnevezési konvenciókhoz tartozik, hogy a Dimenziótáblákat Dim kifejezéssel kell kezdeni, míg a ténytáblákat a Fact kifejezéssel. Ezután létre kell hozni a már többször említett szerepjátszó dimenziókat. Hiszen, egy normális dátum hierarchiában legalább egy nap/hónap/év felbontás található, míg a mi forrásadatink között nem minden szerepel. Ezért létrehozunk egy un. named query -t [6]Hiba! A hivatkozási forrás nem található.. Többféleképpen megadhatjuk az tartalmát, én a SQL leírást választottam. Ekkor megjelenik egy új dimenzióként, azonban az ikonon látszódik, hogy más típusú. A használt SQL query: SELECT CalendarDate, CalendarId, DATEPART([year], CalendarDate) AS Year, DATENAME(m, CalendarDate) AS Month, DATEPART([day], CalendarDate) AS Day, MONTH(CalendarDate) AS MonthNum FROM dbo.calendar A másik hierarchia a projektet és projekttask-ot fogja tartalmazni, erre is létrehozok egy külön dimenziót. A named query-k csak a kockában lesznek elérhetők, az adatbázisban gyakorlatilag nem tárolódnak, hasonló egy OLAP viewhoz. Ezután a measure-rel kel foglalkozni. A specifikációból kiderült, hogy nem minden mértéket ugyanolyan formában kell aggregálni például a különböző dátum szinteken. Az Approved Hour esetén a hónap végén a naponta beírt értékek 37

38 szummája a releváns érték. Ez a kockánál az alap beállítás. De mi történik, ha mint a planned hour esetén egy adott értéket frissít mindig a projektvezető, azonban ezt kvázi historikusan tároljuk. Ebben az esetben a hónap végén a legutoljára beírt érték lesz a releváns mérőszám. Éppen ezért a planned hour és az overhead mértékek esetén az aggregate function-t sum-ról LastNonEmpty -re kell állítani. Itt ragadnám meg az alkalmat, hogy felhívjam a figyelmet arra, hogy az itt kialakított struktúrát már látni fogják a user-ek. Éppen ezért olyan tényezőkre is oda kell majd figyelni, amik mellett eddig elsiklottunk. Van két dimenziótábla, melynek a használata csupán belső, tervezési megfontolás. Éppen ezért a Calendar és a Projekt task hierarchia nélküli táblák Visible értékét False-ra kell állítani, hogy ne zavarja a dimenziók felsorolásánál a felhasználókat A KOCKA PROCESSZÁLÁSA A solution-ben a következő lépés (11. ábra) a kocka elemeinek a kiválasztása. Egy egyszerű wizard-ot kapunk, ahol először a mértékeket tartalmazó táblát (táblákat) kell kiválasztani, majd a kapcsolódó dimenziókat felajánlja. 11. ábra SSAS Solution Ezután már ki tudott alakulni a kockánk multidimenzionális kinézete. (12. ábra) 38

39 12. ábra Csillagséma Ezután a kockát már tudjuk processzálni. Ez azt jelenti, hogy a projektben szereplő struktúrát az SQL serveren található SSAS kiszolgálóra tölti fel. Ezután bármilyen, az SSAS-t támogató alkalmazásból el tudjuk érni az adatokat. Majd sorban ki tudjuk alakítani a hierarchiáinkat. A solution nézetben a calendar hierarchy dimenzióra kattintva előbukkan a beállítási ablak. A legelső gondolatunk, hogy a hierarchy nézetben egymás alá húzzuk szépen sorban az év/hónap/nap hármast, így kialakítva a sorrendet. Ha ekkor a browse nézetre kattintunk, akkor láthatjuk a dimenzió attribútumainak a természetes hierarchiáját. (A browse szintén az SSAS kiszolgálóra kapcsolódik, tehát csak processzálás után fogjuk elérni az adatokat.) A rendszernek alapértelmezetten nincs információja arról, 39

40 hogyan épül fel egy dátum, éppen ezért az attribútumok descartes szorzatát veszi, vagyis minden év alatt megtalálható az összes hónap és az összes nap. Ezen a problémán úgy tudunk segíteni, ha minden egyes hierarchiában szereplő attribútumnak megadjuk azt, hogy melyik másik mező határozza meg, mi a kulcsa. A Day esetén a propertiesben a key column helyére az id-t kell írni, ő van legalul. A month kulccsa összetett lesz: a hónap és az év fogja egyértelműen meghatározni, hogy egy adott hónap melyik évhez fog csatlakozni. A year esetén kulcsnak is a year-t kell választanunk. Ezután az attribute relationship ablakban meg kell adni, hogy melyik attribútum mit határoz meg. (13. ábra) 13. ábra Calendar Hierarchy Ha megnézzük a browse felületen a hierarchia felépítését, már majdnem teljes a siker. Az apró hiba a hónapok sorrendjében rejlik. Jelenleg abc sorrendben sorakoznak. Emiatt volt szükséges felvenni a hónapokat számformátumban is, hiába kérték betűvel kiírva. A month attribútum order by oszlopában ki kell választani az attribute key lehetőséget, ezután a month num attibútumot. Processzálás után már látszik, hogy helyes sorrendben listázza a hónapokat. A dimenziókon belül is szükséges átgondolni, hogy melyek azok a mezők, amiket a vevőnek látnia kell, itt is megtalálható a visible property, például az ID-knál érdemes false-ra állítani, hiszen nem sok értelme van az óraszámokat a calendar ID alapján összegezni. Ezekre a problémákra egyébként felhívja a figyelmünket a fejlesztőkörnyezet is. A javaslatait kék aláhúzással jelzi, ezután a SQL books onlineon keresztül hatásos javaslatokat kaphatunk. [11] Hasonlóképpen kell eljárni a másik hierarchia esetén is, a projektben a projekttask-nak szintén összetett kulcsot kell kiválasztanunk, így rendeződik megfelelő sorrendbe. 40

41 4.7.3 SZÁRMAZTATOTT MÉRTÉKEK A specifikációban szerepelt két származtatott érték, amely nem található meg közvetlenül a táblában. Valamint volt a megrendelőnek egy kérése, miszerint egy adott dátumig szeretné aggregáltan is látni az approved hour értéket, nem csak az aznap felvittek szummáját. Felmerül a kérdés, hogy ezeket a származtatott adatokat hova érdemes elhelyezni. A legmegfelelőbb egy calculated members-be csomagolni. Ezek az adatok nem kerülnek közvetlenül letárolásra a csillagsémában, tehát nem bonyolítja feleslegesen a struktúrát, nem kell felvenni még egy ténytáblát, stb. A calculated members tagokat a kocka definíciójánál kell megadni MDX formátumban. Ez egy speciális lekérdezési szintaxis, direkt multidimenzionális lekérdezésekre. Először az egyszerűbb megoldás: Completed: [Measures].[Sum_Approved] / ( [Measures].[Planned Hour] + [Measures].[Overhead]) Ebben az esetben egyszerű a lekérdezés. Az adott hierarchia szerint kibontott completed értéket megkapjuk, ha ugyanabban a metszéspontban található egyszerű értékeket behelyettesítjük a fenti képletbe. Az sum_approved hour képlet némileg bonyolultabb: SUM( PeriodsToDate([Dim Calendar Hierarchy].[Hierarchy].CurrentMember.Parent.Level, [Dim Calendar Hierarchy].[Hierarchy].CurrentMember), [Measures].[Approved Hour]) A PeriodsToDate függvénnyel és a Parent.Level hívással tudjuk elérni, hogy a dátum hierarchia kibontása esetén az approved hour értékeket szummázza az adott dátum érték szülőjének az összes gyerekét (az adott értékkel egy szinten lévő összes értéket.) Tehát, ha a júniusi értékre vagyunk kíváncsiak, akkor a januártól júniusig tartó időszak szummájával fog visszatérni. Ezután a kiszámított mértékek is meg fognak jelenni a többi fact measure mellett. 41

42 Az MDX query-ket érdemes egy másik környezetben, például notepad++-ban megírni, ugyanis a BIDS ez esetben nem támogatja a syntax highlighting-ot, viszont az összes használható függvény megtalálható a listában. Az egyik leglátványosabb lehetőség a lekérdezési idő gyorsítására a calculated members származtatott adatoknál a non-empty behaviours mezők kitöltése. Amennyiben üresen hagyjuk ezt a mezőt az SSAS minden esetben kiszámítja a mezőt akkor is, ha valamelyik tényező nulla. Ha kitöltjük, első körben megvizsgálja az adott mező értékét, ha nulla, akkor nem vesződik a számítással. 4.8 REPORTOK MEGJELENÍTÉSE, KONKLÚZIÓ A report megjelenítését alapvetően két felületen próbáltam ki, az első esetben egy Excel táblába illesztettem közvetlenül az SSAS szolgáltatóról egy pivot táblát, második esetben pedig ugyanezt a táblát helyeztem el a cég Sharepoint felületén. Mindkét esetben teljes funkcionalitással üzemelt. (14. ábra) 14. ábra Pivot tábla 42