TÁMOP Szolnoki Főiskola VIR rendszerterv. Szolnoki Főiskola. TÁMOP Vezetői Információs Rendszer. Rendszerterv. Verziószám: 1.

Átírás

1 Szolnoki Főiskola TÁMOP Vezetői Információs Rendszer Rendszerterv Verziószám: 1.1 Dátum: Oldal: 1 / 40

2 Dokumentumtörténet Verzió Dátum Készítő Státusz Megjegyzés Lochmayer György átadott verzió Lochmayer György intézményi észrevételek alapján módosított/kiegészített verzió Oldal: 2 / 40

3 Tartalomjegyzék 1 ELŐZMÉNYEK VIR KIMENETEK STRATÉGIAI MUTATÓSZÁMOK EGYÉB MUTATÓSZÁMOK Minőségmenedzsment és EFQM mutatószámok Esélyegyenlőségi és fenntartható fejlődési mutatószámok RIPORTOK AD-HOC ELEMZÉSEK PORTÁL Portál oldalak Jogosultságkezelés Riportok meta adatai FOGALMAK KEZELÉSE, MEGJELENÍTÉSE Fogalmak kezelése Fogalmak és VIR kimenetek kapcsolata ADATTÁR LOGIKAI ADATMODELL MŰKÖDÉSI LEÍRÁS ADATMODELL TERV FORMÁJA ADATTÁR ALAPADATOK INTERFÉSZ TERVEK KAPCSOLAT AZ ORSZÁGOS ADATTÁRRAL ETL FOLYAMATOK ETL FEJLESZTÉS MÓDSZERTANA FORRÁSRENDSZEREK AZ ETL FOLYAMATA Forrásadatok és a Stage Stage Alapadat szint Adatpiacok Kockák KÖZÖS DIMENZIÓK DIMENZIÓK IDŐBELISÉGE ÜZLETI SZABÁLYOK, SZÁRMAZTATOTT ELEMEK ADATELLENŐRZÉSEK Adatellenőrzés architektúra Kilépési pontok Kezdeti adatminőség felmérése ADATTÁR ADMINISZTRÁCIÓ ADATTÁR FRISSÍTÉSEK Kezdeti adatbetöltés Rendszeres adatfrissítés Az idő dimenzió frissítése ÜTEMEZÉSEK TÖRZSADAT-SZÓTÁRAK Oldal: 3 / 40

4 5.4 MENTÉSEK, HELYREÁLLÍTÁSOK Stage táblák Adattár táblák Adatpiac és adatkockák Riportok ARCHIVÁLÁS, ÖREGÍTÉS Log-adatok és adathibák öregítése Az adattár archiválása ADMINISZTRATÍV RIPORTOK BIZTONSÁGI, ADATVÉDELMI MEGFONTOLÁSOK JOGOSULTSÁG Objektum szintű jogosultságok Adatszintű jogosultságok Konkrét jogosultsági szintek, adatszintű jogosultságok VIR Kompetencia Központ NAPLÓZÁS RENDSZERKÖRNYEZET KAPCSOLÓDÁS MÁS RENDSZEREKHEZ BELSŐ FELÉPÍTÉS FIZIKAI RENDSZERKÖRNYEZET TERV Szolgáltatások elérhetősége FOGALOMJEGYZÉK MELLÉKLETEK Oldal: 4 / 40

5 1 Előzmények A TÁMOP pályázat keretében zajló főiskolai VIR fejlesztés során megtörtént a vezetői igények felmérése, majd ezek alapján elkészült az igényspecifikáció, amely tartalmazta a vezetői rendszerben megvalósítandó adatkörök, kimenetek definícióját. Az erre épülő rendszerterv a projekt következő mérföldköve, amely a fejlesztés elkezdése előtti utolsó fázis. Jelen dokumentáció célja az igényspecifikációban definiált követelmények, objektumok, szerepkörök továbbgondolása, leképezése a fejlesztők számára használható, megvalósítás központú rendszertervvé. A rendszerterv bemutatja a vezetői rendszer logikai adatmodelljét, architektúráját, a forrásrendszerekkel való interfészeit, a betöltő és hibakezelő folyamatokat, a rendszer kimeneti termékeit, valamint a rendszer adminisztrációjával kapcsolatos témaköröket is. 2 VIR kimenetek Az adattár tervezése során különböző BI eszközök kerültek meghatározásra, többek között riportok, stratégiai mutatószámok és ad-hoc elemzéseket megvalósító adatkockák. Az adattár megjelenítési felülete a portál, amelyet részletesen a 2.5 Portál fejezet mutat be. 2.1 Stratégiai mutatószámok A mutatószámok szerepe az intézményben a stratégiai vagy stratégia közeli információk egy értékbe sűrített megjelenése. Az egyes mutatószámokban megjelenő információk mélyebb szintű alábontását riportok vagy ad-hoc elemzések segítségével lehet megtenni, melyek a VIR-ben egyszerűen kapcsolhatók egy adott mutatószámhoz. A szállító egy stratégiai mutatószám listát állított össze, mely az intézményi igényfelmérésen túlmenően fedi le az intézményi folyamatokat. A lista 64 darab mutatót tartalmazott. Az intézmény ezt a listát is felhasználva a rendszerterv lezárásáig összeállított saját BSC mutatószám rendszerét, mely 5 BSC nézőpont mentén összesen 23 darab összetett stratégiai mutatószámot, illetve az ezek számítását lehetővé tévő 70 darab almutatószámot tartalmaz. A VIR rendszerben ezen összetett és almutatószámok elérhetősége lesz biztosított Az intézmény által a stratégiai mutatószámok esetében két dokumentum került átadásra, mely tartalmazza az intézményi BSC mutatószámok teljes körét. Az átadott anyagokat a rendszerterv melléklete tartalmazza. A mutatószámok a VIR portálon keresztül lesznek elérhetők a következők szerint: 1. Az egyes mutatószámok aggregált, teljes intézményre vonatkozó értékei témakörök szerinti csoportosítva különböző grafikus (merőóra, jelzőlámpa, stb.) elemeken kerülnek megjelenítésre, melyek tartalmazzák a mutatószám aktuális értéke mellett a meghatározott célértéket, a határértékeket és színkódolással a célérték teljesítést is. 2. A grafikus megjelenítési módra kattintva lesznek elérhetőek a mutatószámok saját oldalai, melyek tartalmazzák: a. a mutatószám pontos definícióját, mely a DefMart-ban kerül definiálásra b. a mutatószám időbeli alakulását idődiagramon és/vagy táblázatos formában c. a mutatószámhoz kapcsolódó riportokat és OLAP kockákat (ha van ilyen) Oldal: 5 / 40

6 2.2 Egyéb mutatószámok Minőségmenedzsment és EFQM mutatószámok Az intézmény által bevezetett Vörös Ösvény EFQM értékelési rendszer segítségével meghatározott időközönként történik meg az intézmény minőségügyi értékelése, melynek eredményei és mutatószámai egy elkészülő minőségügyi jelentés keretében statikus formában (dokumentumként) kerülnek publikálásra a VIR portálon. A minőségügyi jelentések és mutatószámok Vörös Ösvényben való elkészítését a VIR az alábbi két módon támogatja: 1. az EvaSys rendszerben előálló minőségmenedzsment és elégedettségi felmérési adatok elérhetővé tételével a VIR portálon; 2. az ad-hoc lekérdezésekkel Esélyegyenlőségi és fenntartható fejlődési mutatószámok Az intézményi pályázási folyamatok támogatása érdekében a VIR-ben megjelenítésre kerülnek azok az esélyegyenlőségi és fenntartható fejlődési mutatószámok, melyek az egyes pályázatok vonatkozó részeinek intézményi szintű egységes kezelését tudják biztosítani. Ezen mutatószámok az intézmény által definiált formában (dokumentumként ) kerülnek feltöltésre a VIR portálra, azok előállításához a VIR közvetlenül nem szolgáltat adatokat. 2.3 Riportok A tervezés során az igényfelmérésben felmerült riporttervek, adatigények az intézményi igényfelmérések összesítésével, az ágazati ajánlások és a VIR szállító szakmai tapasztalatai alapján konszolidálásra kerültek, így kevesebb riporttal több információs igényt is le lehet fedni. A folyamat során az intézményre specifikusan jellemző, a vezetők igényeit széleskörűen kielégítő VIR riportok kerültek meghatározásra. A kialakított riport gyűjtemény elsősorban úgy került felépítésre, hogy a szélesebb felhasználói kör által igényelt adatokat fix formában, rendszeresen, áttekintő módon tudja biztosítani. Emellett kisebb számban olyan riportok is definiálásra kerültek, melyek egy vezető számára nyújthatnak részletes adatokat egy-egy tématerületről. A több vezető által igényelt adatkörök és riportok egységesítésre és összevonásra kerültek. A tervezéskor kialakított riportgyűjtemény 48 darab riportot tartalmaz, melyek elsősorban a vezetők számára szolgálnak adatokkal egy-egy tématerületről. A riportlista mellett összeállításra kerültek úgynevezett vezetői csomag ajánlások is, melyek kifejezetten egy adott célközönség, vezetői szint (rektori kabinet, szenátus, stb.) felé, útján is küldendő riport csomagokat jelentenek. Ezen csomagok riporttartalmának és időzítéseinek ellenőrzése illetve esetleges kiegészítése az intézmény feladata volt ugyanúgy, mint a riporttervek validálása. A rendszerterv elkészítéséig az intézmény részéről két új riport igény érkezett, több riport szerkezetében és adattartalmában történtek a visszajelzések alapján módosítások. A rendszerterv lezárásáig összesen 50 darab fix riport került validálásra az intézmény által. Oldal: 6 / 40

7 A mellékletben találhatók a fejlesztés során megvalósuló riportok és vezetői csomagok. Az Excel fájl több munkalapból épül fel. Az első munkalap tartalmazza a riportok összesítését, ezen minden sor egy riport adatait sorolja fel, melyek az alábbiak: Kód: a riport kódja, ilyen néven jelenik meg a későbbi munkalap füleken Riport megnevezése: a riport rövid neve Riport leírása: a riport részletesebb leírása, tartalma Tématerület: a riport milyen témakörhöz kapcsolódik Gyakoriság: a riport milyen gyakorisággal készül el Szerkezet: itt egy link található a riport szerkezetét mutató munkalap megjelenítéséhez A következő hat munkalap a vezetői csomag ajánlásokat írja le, melyek adott célcsoportoknak készültek, ezekből hat darab készült: Szenátusi csomag Intézeti csomag Tanszéki csomag Szakfelelősi csomag Oktatói csomag Rektori kabineti csomag Ezek a munkalapok a jelmagyarázaton és a többi célcsoportra való linkeken kívül soronként azoknak a riportoknak az összefoglaló adatait tartalmazzák, melyek az adott vezetői csomagban találhatók. A riportadatok a következők: Témakör: a riport melyik témakörhöz kapcsolódik Kód: a riport kódja, ahogy a fájlban máshol megjelenik Leírás: a riport tartalma Hónapok nevei: azoknál a hónapoknál szerepel zöld hátterű x, amely hónapokban az adott riport generálásra kerül, és az adott célcsoport azt meg is kapja formájában A többi munkalap az egyes riportok szerkezeti felépítését mutatja: milyen szűrő feltételekkel, csoportosításokkal, milyen sorokban és oszlopokban jelennek meg a riport adatai, illetve ha grafikon is szerepel a riportban, akkor ezek lehetséges elhelyezkedését is ábrázolja. A riportok az intézmény arculatának megfelelő stílusban és színekkel kerülnek kialakításra, a pontos design elemeket az intézménnyel a fejlesztés során egyeztetjük. 2.4 Ad-hoc elemzések Az ad-hoc elemzések az egyes vezetők számára a következőket biztosítják: vezetői igényeknek megfelelő, az áttekintő riportoknál mélyebb szintű rendszeres riportok és kimutatások kialakítása egyedi vagy nem rendszeres módon felmerülő igények azonnali, naprakész kielégítése egyedi elemzések végzése, kereszttáblás kimutatások A szállító által olyan ad-hoc elemzési adatkockák összesen 10 darab kerültek összeállításra a tervezés során, melyek egy-egy tématerület (pl.: felvételi, tantárgyi eredmények, HR állomány, stb.) Oldal: 7 / 40

8 főbb adatigényét összefoglalják, és a vezetők számára is biztosítják egy-egy terület átláthatóságát. A szállító által összeállított és az intézmény által validált, kiegészített adatkockák tervét a rendszerterv megfelelő melléklete tartalmazza. A rendszerterv részét képező adatmodell felépítése biztosítja, hogy a későbbiekben felmerülő vezetői igények alapján a VIR kompetencia központ a szállító által összeállított kockákat egyszerűen módosítsa, vagy teljesen új elemzési adatkockákat hozzon létre. Az Excel fájl több munkalapot tartalmaz. Az első munkalap az ad-hoc elemzések összesítését tartalmazza. Minden sor egy adott elemzés tulajdonságait sorolja fel, melyek az alábbiak: Sorszám: az ad-hoc elemzés sorszáma Azonosító: az ad-hoc elemzés azonosítója Témakör: az ad-hoc elemzés melyik témakörhöz kapcsolódik Ad-hoc igény: az ad-hoc elemzés rövid elnevezése Leírás: az ad-hoc elemzés leírása Megjelenítés: az ad-hoc elemzés paramétereit megjelenítő munkalapra mutató link A fájl többi munkalapja az ad-hoc elemzés azonosítójának megfelelő nevű, és az adott elemzés paramétereit, tulajdonságait, mérőszámait és dimenzióit mutatja be az alábbi mezők segítségével: Paraméterek, tulajdonságok o Megnevezés: az ad-hoc elemzés rövid elnevezése o Azonosító: az ad-hoc elemzés azonosítója o Részletes leírás: az ad-hoc elemzés bővebb leírása o Témakör: az ad-hoc elemzés melyik témakörhöz kapcsolódik o Granularitás: az ad-hoc elemzés legkisebb adategysége, amilyen mélységben az adatok bekerülnek a kockába o Célok: az ad-hoc elemzés üzleti céljának leírása o Kérdések: az ad-hoc elemzés segítségével milyen kérdésekre adhatunk választ Mérőszámok o Név: a mérőszám neve o Leírás: a mérőszám leírása o Mértékegység: a mérőszám mértékegysége o Üzleti szabály: a mérőszám kiszámításához kapcsolódó üzleti szabály o DW kód: a mérőszám adattárbeli azonosítója, kódja Dimenziók o Dimenzió név: a dimenzió neve o Attribútum csoport: a dimenzió attribútum-csoportjának elnevezése o Attribútum név: a dimenzió-attribútum neve o Attribútum leírás: az attribútum leírása o Értékkészlet: az attribútum lehetséges értékei o Üzleti szabály: a dimenzió-attribútum kiszámításához kapcsolódó üzleti szabály o DW kód: a dimenzió/attribútum adattárbeli azonosítója Javasolt hierarchiák o Hierarchia megnevezése: a javasolt hierarchia neve Oldal: 8 / 40

9 o 1. szint, 2. szint, stb.: a hierarchia szintjén mely dimenzió-attribútum helyezkedik el 2.5 Portál A vezetői információs rendszer megjelenési felülete a VIR portál, melynek alapvető építő eleme az oldal. Egy oldalon kerülnek elhelyezésre az összetartozó adatok. A portál az alábbi oldalakat tartalmazza: Oldal Kezdőoldal Szerepkörhöz tartozó oldalak Stratégia Saját oldal Fix riportok Ad-hoc elemzések Statikus beszámolók Benchmarking Kompetencia központ Tartalma Minden olyan információ és funkció, amely nem tartalmaz tényleges adatot Az egyes felhasználói csoportok (pl. szakfelelősök, szenátus, stb.) számára fontos információs tartalmat integráló oldal A stratégiai mutatószámokat tartalmazó oldal Az egyéni felhasználók által egyedileg igényelt vagy saját kezűleg beállított ad-hoc lekérdezéseket megjelenítő oldal A VIR-ből lekérdezhető riportok az egyes témakörökhöz csoportosítottan Az ad-hoc lekérdezések kiinduló oldala az egyes témakörökhöz Egyéb statikus (időben nem változó) beszámolók, elemzések, kimutatások a különböző témakörökben Az ágazati AVIR-ból származó adatkörökre épülő riportok és mutatószámok VIR Kompetencia Központ számára készített kimutatások 1. táblázat: Portál oldalak A VIR portálon a következő arculati elemeket lehet módosítani az intézményre szabott megjelenítés érdekében: fejléc háttérszíne felső navigációs sáv háttérszíne tartalom háttérszíne rovatcímek betűszíne oldal betűszíne linkek színe logó a logó tooltip szövege a böngésző címsorában megjelenő ikonkép (favicon) Ezeken kívül a fejlécbe lehet egy általános leírást beilleszteni Portál oldalak Minden oldal állandó eleme a segítség doboz, amely tartalmazza a rendszer használatához szükséges alapvető felhasználói információkat. Az oldalak bal oldali sávjában található doboz a következő elemeket tartalmazza: Kereső A kereső segítségével bármely oldalon indítható szabad szavas keresés. Tartalomleírás Minden oldalhoz egy egyénileg megfogalmazott, néhány mondatos leírás, amely az aktuális oldalon található tartalmakat ismerteti. Screencast videó Oldal: 9 / 40

10 Az adott oldal lehetőségeit és helyes használatát bemutató rövid, néhány perces videó. Technikai, tartalmi leírás Egy technikai és egy tartalmi leírást tartalmazó dokumentumra való hivatkozás. Support elérhetőségek Ügyfélszolgálat telefonszáma és címe. Közvetlen küldési lehetőség A felületről közvetlenül értesítés küldhető a technikai személyzetnek. VIR szabályzat A VIR szabályzat egy tömör kivonata, amely ismerteti a rendszer alapvető tulajdonságait. Riportok meta adatai A riportok esetében megadandó kötelező metaadatok köre Általános kezdőoldal A kezdőoldalon az egész rendszerre jellemző információk gyors elérésére van lehetőség. Az oldalon több portlet, azaz doboz található, amelyek a következő funkciókkal bírnak: 1. Szabad szavas kereső A kereső segítségével lehet kifejezésekre keresni a portál tartalmai között. 2. Témakör alapú kereső Meghatározott témakörök riportjai között lehet keresni. A keresés eredményhalmaza típusonkénti bontásban jelenik meg. 3. Riport frissítések utolsó időpontja 4. Gyakran ismételt kérdések (GYIK). Meghatározott elemek jelennek meg a kezdőoldalon, a további tételek a GYIK oldalon olvashatóak. 5. Jogosultság igénylés A látogatónak lehetősége van online felületen felhasználót igényelnie, hogy hozzáférhessen további, bejelentkezést igénylő tartalomhoz. 6. Hírek Szöveges tartalmak, amit a megfelelő jogosultsággal rendelkező felhasználó szerkeszthet. 7. Toplisták (mindig az első 5 elem jelenik meg) a. Leggyakrabban futtatott riportok listája b. Legaktívabb felhasználók 8. Fogalomtár megnyitása link 9. Riportlista jogosultságoktól függetlenül, meta-adatokkal megjelenítve Szerepkörhöz tartozó oldalak A szerepkörhöz tartozó oldalak segítségével lehetőség van minden szerepkör számára egyéni tartalmat készíteni. A szerepkör oldalai egyénileg készülnek, és bárki hozzáférhet, aki adott szerepkörrel rendelkező felhasználóval rendelkezik. Amennyiben egy felhasználóhoz több szerepkör is hozzá van rendelve, abban az esetben az összes szerepkörhöz tartozó oldal elérhető számára. A szerepkör oldalai egy két cella széles, két cella magas táblázatból épül fel. A bal felső cellában látható a szerepkör ún. dashboardja, ahol a szerepkörhöz tartozó egy-két lényeges stratégiai Oldal: 10 / 40

11 mutatószám jelenik meg. Az oldal egyéb tartalma a szerepkörhöz erősen köthető riportok megjelenítéséből és listájából áll Saját oldal A saját oldal a saját, illetve publikus, de átvett riportok megjelenítésére szolgál. Amennyiben a felhasználó saját riportokat készít, ezen az oldalon érheti el őket. A felhasználónak lehetősége van a mások által feltöltött riportok, illetve a statikus elemzések közül összeválogatni azokat az elemeket, amelyek szintén megjelennek a saját oldalak menüpont alatt. További lehetősége, hogy ad-hoc elemzési (OLAP) nézeteket helyezzen el a saját oldalán Stratégia oldal A stratégia oldal tartalmazza az egyes témakörökben definiált mutatószámok grafikus (mérőóra, jelzőlámpa, stb.) formájú megjelenítési formáját, melyekre kattintva érhetők el az egyes mutatószámok saját oldalai. A stratégia oldalhoz alapértelmezésben minden látogató hozzáfér, viszont a mutatószámhoz tartozó lefúrások és elemzések melyek a mutatószám saját oldalán helyezkednek el elérése jogosultsághoz kötött Fix riportok A fix riportok oldalon az adattáron alapuló, előre elkészített riportok jelennek meg témakör szerinti bontásban. Az oldal annyi dobozt tartalmaz, ahány témakör van definiálva a rendszerben. A dobozban a riportok linkként érhetőek el Ad-hoc elemzések Az ad-hoc elemzések oldal felépítése hasonló, mint a fix riportok oldal, de itt az OLAP kockák jelennek meg, ezeket tudja megnyitni a felhasználó, és tetszése szerinti kimutatást tud kialakítani. A kiforgatott riport elmenthető a saját oldalra Statikus beszámolók A statikus beszámolók oldal statikus, azaz egy időpontban aktuális dokumentumok publikálására használható (pl.: éves értékelő jelentés stb.). Itt tipikusan nem automatizált beszámolók jelennek meg, hanem az adatok alapján elkészült szöveges beszámolók, elemzések, stb. A megjelenést tekintve szintén kategóriánkénti bontásban, szöveges linkként jelennek meg a dokumentumok. Lehetőség van egyéni jogosultság beállítására az egyes elemekre Ágazati benchmarking adatok Az ágazati AVIR-ból származó adatkörökből felépülő, az intézmény országos helyzetét bemutató, és a többi intézménnyel való összehasonlítását lehetővé tevő mutatószámok és riportok gyűjtőoldala Kompetencia központ oldala Az oldal logikailag megegyezik az adminisztrátoroknak szánt személyes oldallal. Az oldalon a következő információk érhetőek el: Felhasználó- és riportszám ETL napló Felhasználási statisztikák Oldal: 11 / 40

12 2.5.2 Jogosultságkezelés A portálon az egyes oldalakhoz történő hozzáférést a felhasználó szerepköre határozza meg. A statikus tartalmak hozzáférése dokumentumonként beállítható. A riportok esetében az összes riport megjelenik minden felhasználó számára, és az adott riportban történik a jogosultságkezelés. Így ha egy felhasználónak nincs joga egy adott adatkört megtekinteni, akkor a riport futtatásakor annak adattartalma üres lesz, és egy üzenet tájékoztatja a felhasználót arról, hogy jogosultsági problémák miatt nem tekintheti meg a kért adatokat. E megoldás előnye az, hogy a felhasználó látja, milyen kimutatások vannak a rendszerben, és kérheti a hozzáférés engedélyezését. A módszer azonban csak akkor alkalmazható, ha a riportoknak csak kis részénél korlátozza az intézmény a hozzáférést. A felhasználói elégedettség csökkenéséhez vezetne, ha a riportok 20%-ánál nagyobb arányban kapna a felhasználó ilyen választ Riportok meta adatai Minden riport feltöltése után a következő meta adatok megadására van lehetőség: a. Név * b. Leírás c. Riport típus (Online, OLAP, Statikus) * d. Témakör, altéma * e. Megjelenítés típusa (táblázat, grafikus) * f. Milyen üzleti folyamatot támogat (oldalakon nem jelenik meg, csak a keresőben) * g. Célcsoport (szerepkörök) h. ben ütemezetten elküldött riport-e, ha igen, milyen célcsoport(ok)nak i. A riportban használt, fogalomtárban definiált fogalmak jegyzéke j. Időszak k. Felelős (személy) l. Igénylő (személy) m. Fejlesztő (személy) n. Frissítési gyakoriság o. Érvényesség (aktív-e, mettől meddig) p. Státusz (publikált vagy vázlat, ilyenkor csak a fejlesztő és kompetencia központ látja) q. Statikus beszámoló esetén: dokumentum csoport r. Verzió s. Jogosultságok A *-al megjelölt elemeket kötelező megadni az egyes riportok publikálása előtt. 2.6 Fogalmak kezelése, megjelenítése Fogalmak kezelése A VIR kimenetek egyértelműsége érdekében a használt fogalmakat pontosan definiálni kell. Ezek a definíciók az intézmény vezetőivel és szakértőivel együttesen kerülnek kidolgozásra, publikálásukat a DefMart fogalomtár rendszer biztosítja. A rendszertervezési fázisában egy kezdő fogalomkészlet került összeállításra az Educatio Kft. által összeállított központi AVIR Fogalomtárban található fogalmakból. Az intézményben a rendszerterv lezárásának időpontjában is zajlik a BSC, az EFQM és minőségmenedzsment illetve egyéb mutató- és Oldal: 12 / 40

13 mérőszámok definiálása. A folyamatok lezárása után ezen fogalmak is betöltésre kerülnek a DefMart rendszerbe. A rendszerterv lezárásig a DefMart fogalomtár szoftver telepítésre került, a rendszeradminisztrátori oktatás lezajlott, a kezdeti fogalomkészlet az intézmény felé átadásra került. A fogalomtárban tárolt fogalmak köre a fejlesztés és az éles üzem során is bővülni fog, többek között a VIR-ben előálló kimenetek pontos értelmezésével és leírásával Fogalmak és VIR kimenetek kapcsolata A VIR rendszer és DefMart fogalomtár összekapcsolásának köszönhetően a VIR portálon megjelenő mutatószámok és riportok esetében biztosított lesz az azokban szereplő fogalmak közvetlen, beágyazott link útján történő elérése. A mutatószámok esetében az elérhető fogalom definíció magának a mutatónak a leírását, számítási módját, céljait, stb. tartalmazza, míg a riportok esetében az azokban szereplő mérőszámok, dimenziók és dimenzió attribútumok leírását jelenti. Oldal: 13 / 40

14 3 Adattár logikai adatmodell 3.1 Működési leírás Az adattárház architektúrája, felépítése több szintű, így biztosítja többek között a forrásrendszerek adatainak megfelelő struktúrában történő átalakítását, ellenőrzését, idősoros tárolását. A forrásrendszerek adatai a legalsó szinten helyezkednek el - erre épül a stage0 szint - melyek még teljesen a forrásrendszerek felépítését mutatják. A következő szintre lépve az adatok már az adattár struktúrájának megfelelő módon jelennek meg, az adatok ténytáblákba, dimenziókba rendeződnek, és erre a szintre épülve alakíthatók ki az adatkockák, adatpiacok, riportok, stb. 3.2 Adatmodell terv formája A logikai adatmodell tervezésénél az adatokat témakörökre osztottuk, és témakörönként egy fájlban összesítettük a modell adattábláit, azok egyes mezőit, tulajdonságait, kapcsolatait és összefüggéseit. A fájlok RTF formátumúak, elnevezésük úgy épül fel, hogy a dw_ prefix után következik a témakör neve. Az adatmodellt bemutató RTF dokumentumok felépítése két fő részre osztható: az adattáblákat grafikusan ábrázoló diagramokra és a táblák mezőit leíró táblázatokra. A diagramokon az adott tématerület illetve interfész adattáblái és az adattáblák kapcsolatai láthatók. Egy tématerülethez több diagram is tartozhat, egy diagramon egy-két ténytábla és a hozzájuk kapcsolódó dimenziótáblák helyezkednek el. A diagramokon látható az adattáblák elnevezése, a táblák mezőinek neve és típusa, az elsődleges és az idegen kulcsok, illetve a kapcsolatok multiplicitása. A diagramok ábrázolása után az adattáblák részletes adatai szerepelnek a fájlban. Minden adattáblához tartozik egy táblázat, amelynek fejléce megadja a tábla nevét és egy rövid leírást a tábláról. A táblázat a következő oszlopokat tartalmazza: PK: az adott mező elsődleges kulcs része-e Név: a mező neve Típus: a mező típusa (pl. int, nvarchar, stb.) Hossz: a mező hossza (karakteres mezők esetén) Leírás: részletező információk a mezőről A logikai adatmodellt és az interfészeket leíró fájlok is ugyanolyan formátumban és szerkezetben kerültek bele a rendszertervbe, a leíró fájlok a rendszerterv mellékletét képezik. 3.3 Adattár alapadatok Az adattár alapadatai a következő témakörök köré csoportosíthatók a rendszerben: 1. Oktatás Az oktatás témakör az oktatáshoz kapcsolódó folyamatokat, entitásokat foglalja magában, mint például a hallgató, a hallgató képzése, felvételi, kurzusfelvétel, oktatásszervezés, szakmai gyakorlat, vizsgáztatás, oktatói felelősségek, felnőttképzési tanfolyamok, hallgatói mobilitás, TDK tevékenység. 2. Gazdálkodás Oldal: 14 / 40

15 A gazdálkodás témaköre az adatmodellben eszközökre, számlákra, pénzügyre és személyes pénzügyekre bomlik, ezeken belül jelennek meg a gazdálkodási terület adattáblái, adatmezői dimenziói, stb. 3. Humán erőforrás A HR témakörben az oktatók több tulajdonsággal rendelkeznek, mint az oktatási tevékenységet nem végző dolgozók, így a modellben külön rész tartalmazza az oktató vonatkozási információkat. A következő altémákat tartalmazza a modell: dolgozói munka, nyelvvizsga, továbbképzés, távollét, végzettségek, valamint oktatói egyesület, publikáció, rendezvényrészvétel és oktatói munka. 4. Törzsadatok A törzsadatok témakörben az idő és a szervezeti egység dimenziótáblái jelennek meg, valamint a szótártáblák. 5. Ingatlan Az ingatlan témakör az ingatlanok és helyiségek jellemzőit tartalmazza. 6. Kollégium A kollégiumi témakör tartalmazza az intézményi hallgatók kollégiumi jogviszonyainak adatait. 7. EFQM kérdőívek Az egyes EFQM területen végzett kérdőívek aggregált eredményei. A vezetői rendszerben szereplő témakörök részletes adatait, adattábláit, diagramjait és összefüggéseit az alábbi táblázatban szereplő fájlok tartalmazzák a mellékletben. Témakör oktatás gazdálkodás humán erőforrás törzsadatok ingatlan kollégium EFQM kérdőívek 2. táblázat: Alapadatokat tartalmazó fájlok Fájl neve dw_oktatas.rtf dw_gazdalkodas.rtf dw_hr.rtf dw_torzs.rtf dw_ingatlan.rtf dw_kollegium.rtf dw_kerdoiv.rtf 3.4 Interfész tervek A forrásrendszerek előre definiált interfészeken keresztül kapcsolódnak a vezetői információs rendszerhez. Ezek típusa forrásrendszertől függően eltérő lehet, előfordulhat többek között web service-es elérés, ODATA elérés, egyéb fájlokhoz való kapcsolódás vagy közvetlen adatbázis kapcsolat. Az alábbi táblázat tartalmazza az egyes forrásrendszerek típusát és az interfész fájlok nevét. Oldal: 15 / 40

16 Forrásrendszer Típus Fájl neve Neptun ODATA elérés int_neptun.zip nexonbér MS SQL adatbázis int_nexonber.rtf TÜSZ MS SQL adatbázis int_tusz.rtf GÓLYA MS SQL adatbázis pontos tartalma jelenleg még nem ismert FELIR Excel táblázatok int_ingatlan.rtf TDK Excel táblázatok int_tdk.rtf EvaSyS (EFQM terület) Excel táblázatok int_evasys.rtf AVIR (adatszolgáltatáshoz Excel táblázatok int_avirba.rtf szükséges egyéb adatok) AVIR (központból intézmény felé szolgáltatott adatok) web service pontos tartalma jelenleg még nem ismert 3. táblázat: Interfészek típusai forrásrendszerek szerint A forrásrendszerek interfészeit kivétel a Neptun rendszerét az adatmodellhez hasonló módon és formátumban tartalmazza a rendszerterv, a különbség csupán annyi, hogy ebben az esetben nem témakörönként, hanem forrásrendszerenként egy RTF fájl készült. Az interfészeket leíró fájlok neve az int_ prefixből és az adott forrásrendszer nevéből tevődik össze. A Neptun interfész tervet az SDA Kft. adta át a szállító részére, és ezek ebben a formátumba kerül be a rendszertervbe. Az AVIR rendszerbe kötelezően szolgáltatásra kerülő adatok áttöltésének segítéséhez az adattárba Excel fájlokat töltünk be, ezeken az Excel fájlokon keresztül kell az adatot szolgáltatnia az intézménynek az országos adattár felé. Ezeknek a fájloknak a pontos felépítését a következő fejezetpont tartalmazza. Az AVIR rendszerből az intézményi vezetői rendszer web service-en keresztül kap adatokat. 3.5 Kapcsolat az országos adattárral Az AVIR kötelező adatszolgáltatás részeként az intézmény adatokat köteles szolgáltatni az országos felsőoktatási adattár felé, illetve a központi adattárból az intézmény adatokat kérdezhet le. Ennek az adatszolgáltatásnak külön interfészt kell kialakítani a vezetői rendszer oldaláról is. A kötelezően szolgáltatandó adatokat a melléklet tartalmazza az alábbi részletes adatokkal, tulajdonságokkal: Interfész tábla: a tábla neve Típus: a tábla mező típusa; dimenzió, mérőszám, vagy id (azonosító) Mező: a tábla egy mezője Leírás: a tábla adott mezőjének jelentése, leírása Kapcsolódó fogalomtári definíciók: milyen fogalom kapcsolódik az adott mezőhöz, mi segíti a megértését Mező típusa: a tábla adott mezőjének adattípusa, pl. int, date, stb. Szótár típus/idegen kulcs: a mező milyen szótárban jelenik meg, illetve hol jelenik meg idegen kulcsként Verzió: a tábla mezőjének verziószáma Mező sorrend: a mező sorszám az interfész táblában A lekérdezhető adatok körét az Educatio Kft. a rendszerterv lezárásának időpontjáig nem publikálta, ezért azt a fejlesztés ideje alatt szükséges pontosítani. Oldal: 16 / 40

17 4 ETL folyamatok 4.1 ETL fejlesztés módszertana Az egész adattár fejlesztési módszertanunkra jellemző a modularitás. Az egyes témaköröket egységenként kezeljük, és a fejlesztés ilyen egységek egymás utáni kidolgozásából áll. Egy témakör lefejlesztése a következő lépéseket fedi le: a kapcsolódó forrásrendszerekhez való csatlakozás definiálása az interfészek kialakítása a stage-be áttöltő jobok kidolgozása az adatminőség javítása az adatok aggregálása, denormalizálása, konszolidációja az adattárt feltöltő jobok lefejlesztése az adatpiac szint és az adatkockák előállítása a mutatószámok és riportok definiálása és kidolgozása A módszertan nagy előnye a gyorsaság és az inkrementális fejlesztés: az egyes témakörök kidolgozása önmagukban sokkal gyorsabban lezajlik, mint a horizontális fejlesztési módszertanok esetén. Utóbbiak ugyanis először az interfészek teljes kidolgozásával kezdik, ezt követően jön a stage teljes feltöltésének lefejlesztése, és így tovább. Ebből adódóan sokkal később adható át egy késznek tekinthető egység, így az esetleges hibákról a felhasználók később értesülnek, és csak ezt követően tudnak visszajelezni, a hibák javítása is tolódik. Az inkrementális fejlesztés esetén viszont már az első témakör átadását követően be lehet csatornázni a fejlesztésbe az felhasználói visszajelzéseket, a felmerülő hibákat a következő egységek fejlesztésekor már rögtön kezelni lehet. A módszertanból adódóan nem készül el előre a teljes mapping, mivel a témakörök lefejlesztésének szerves része az áttöltés kidolgozása is. Ezeket a terveket tehát az adattár fejlesztése során inkrementálisan fogjuk kidolgozni és átadni. 4.2 Forrásrendszerek Az ETL folyamatok során az alábbi forrásrendszerek adatai kerülnek betöltésre az adattárba: Neptun tanulmányi, HR és helyiség adatok GÓLYA felvételi adatok TÜSZ gazdálkodási, eszköz-nyilvántartási és ingatlan adatok nexonbér HR és béradatok FELIR ingatlan adatok Vörös Ösvény minőségmenedzsment és EFQM mutatószámok EvaSys által exportált DPR pályakövetési illetve minőségmenedzsment és elégedettségi felmérési adatok Excel táblák betöltésével: o intézményi TDK tevékenység adatai A forrásrendszerek és a vezetői igények felmérése során a könyvtári terület vonatkozásában kiderült, hogy az ALEPH rendszer nem tud teljes körűen adatokat szolgáltatni az adott a témakörben (pl. az olvasótermi aktivitásra vonatkozó adatokat nem tartalmazza), illetve kimeneti igényként kizárólag az Oldal: 17 / 40

18 évente készülő beszámoló ( Beszámoló a Szolnoki Főiskola Könyvtár és Távoktatási Központjának évi tevékenységéről ) VIR-en történő megjelenítésének támogatása merült fel. A fent említett beszámolót annak jellege, és az adatok egy részének hiánya miatt nem tudja a VIR előállítani, ezért javasolt, hogy a könyvtári terület adatigényei a VIR portálon az éves beszámoló dokumentumként való publikálásával kerüljenek kielégítésre. 4.3 AZ ETL folyamata Az ETL folyamat az adatok forrásrendszerből történő kinyerését (Extract), az adatok átalakítását (Transform), és az adatok adattárba való betöltését (Load) foglalja magában. Az adattár több szintből épül fel. A legalsó szinten a forrásrendszerek szintje helyezkedik el. Itt találjuk az adattár alapjául szolgáló adathalmazokat, melyek különböző rendszerekből származnak Forrásadatok és a Stage0 Minden egyes forrásrendszer minden adatát átmásoljuk egy közös területre, ez alkotja az adattár következő szintjét, melyet a tervezés során stage0-nak nevezünk. Ez a szint a forrásrendszerek adattábláinak pontos tükörképe, illetve a nem adatbázis alapú forrásrendszerek adatai ezen a szinten már adattáblákba rendeződnek. Ugyanazok az adattáblák, ezen belül pedig ugyanazok az adatmezők szerepelnek ezen a szinten, mint a kiindulási rendszerekben, az adatok struktúrája nem változik. Ebben a fázisban a cél az adatok minél gyorsabb átmásolása a közös rendszerbe. Az egyes forrásrendszerek adatai egymástól függetlenül kerülnek áttöltésre. Minden forrástáblából két másolat létezik a stage0 szinten. Az egyik az aktuálisan áttöltött adatokat tartalmazza, míg a másik az előző adatáttöltés során betöltött adatokat. Az egyes adattáblák áttöltési időpontját is eltárolja a rendszer. Oldal: 18 / 40

19 1. ábra: ETL folyamat az adatmodell tervezése során Stage A következő szint feladata az adatstruktúra oly módon történő módosítása, hogy megfeleljen az adattárház építés követelményeinek. Ez magában foglalhatja az adatok más elven történő csoportosítását, köztes adattáblák, munkatáblák létrehozását, adattípusok módosítását, illetve az adattisztítási folyamatokat is. Ezen a szinten nem feltétlenül különböztethető meg, hogy melyik adat melyik forrásrendszerből érkezett. Az így kialakított konszolidált stage szint már megegyezik az adattárház struktúrájával, ez képezi az adattár alapadat halmazát Alapadat szint Az adatstruktúra alapvetően a csillagsémát követi: egy tényadatokat tartalmazó központi ténytábla körül helyezkedek el a szűrési, csoportosítási szempontokat tartalmazó dimenziótáblák. A ténytábla a dimenzióknak megfelelő részletezettséggel, redundánsan tartalmazza az adatokat. A redundáns adattárolás gyorsítja az adatok lekérdezését Adatpiacok Az alapadatok feletti szinten adatpiacokat lehet létrehozni. Az adatpiac logikailag összetartozó táblákat tartalmaz, pl. azonos témakörhöz tartozó adatok halmazát. Egy adatpiac lehet egyszerűen az alapadatok egy szűkített halmaza, de tartalmazhat összesítéseket, aggregálásokat, illetve származtatott adatokat is. Az adatpiacok fizikailag egy adatbázisban tárolódnak, csak logikai szinten választjuk szét őket. Oldal: 19 / 40

20 4.3.5 Kockák Az alapadatok feletti másik szintet képezik az adatkockák. A kocka alapját csak logikailag összetartozó és összeegyeztethető adatok képezhetik Egy adatkocka egy-egy adatpiacból, vagy az alapadatok szintjéből építhető. Egy adatkocka akár egy adatpiac része is lehet. Ezen a szinten figyelembe kell venni, hogy az adatok mennyi és milyen szintű aggregálása szükséges, hiszen a túl sok aggregálás ugyan növeli a lekérdezés sebességét, de közben jelentősen megnövelheti a tároláshoz szükséges tárhely mértékét. Ezen a szinten már csak olyan tényadatokat, dimenzióadatokat érdemes tárolni, melyek valóban szükségesek az adott intézmény felhasználói számára. 4.4 Közös dimenziók A közös dimenzióknak az alábbi négy típusát különböztetjük meg az adattárházban. 1. A dimenzió értékkészlete külső forrásból származik, amihez az adattár alkalmazkodik, ilyen például az AVIR törzs. 2. A dimenzió egy adott forrásrendszerből származik, amely a dimenzió értékkészletének ún. gazdája, és minden más rendszer ehhez alkalmazkodik, pl. témaszám struktúra a TÜSZ-ben. 3. A dimenzió az adattárházban kerül kialakításra, mert a dimenziókat nem lehetséges konszolidálni. A dimenzió karbantartása is az adattárban történik. Pl. közös szervezeti egység létrehozása, de emellett a TÜSZ-ös önálló egység és munkahely hierarchia is megmarad, hogy a gazdasági adatokat is megfelelően lehessen ábrázolni. 4. A negyedik dimenziókategóriába pl. az idő dimenzió kerül, mely a fejlesztés során kerül generálásra, majd az évente sorra kerülő adminisztrátori munka keretében újragenerálásra. A mellékletben található táblázat megmutatja, hogy melyik dimenziót melyik típusba soroltuk a tervezés során, illetve az 1-es, 2-es kategória esetén melyik forrásrendszerből kapja az értékkészletét. 4.5 Dimenziók időbelisége A dimenziók értékkészlete az idő múlásával folyamatosan változhat. Az adattárba érkező tényadatokat (alapértelmezés szerint) az aktuálisan érvényes dimenzió értékekhez szeretnénk kapcsolni, de meg szeretnénk hagyni a mindenkori értékek visszakereshetőségét is. Fontos tehát definiálni, hogy miként kezeli az adattár az ilyen jellegű változásokat. A dimenziók attribútumairól külön-külön eldönthető, hogy milyen változáskezelést alkalmazzunk. A dimenzió betöltését úgy kell megvalósítani, hogy minden attribútum az előre definiált módon viselkedjen a változás tekintetében. Az első típusú dimenzió-attribútum az SCD0. Ezek a mezők egyszer kerülnek be az adattárba, és végérvényesen megmarad az értékük. Ezek tehát nem változó attribútumok. Ilyen tipikus dimenzióattribútum egy indikátor eredeti terv értéke: egyszer bekerül a rendszerbe, és az adott pillanatban meghatározott tervértéket adja meg. Minden más módosítás egy új időponthoz köthető, és módosított tervként kezelendő, tehát az eredeti tervadatra nincs hatással. A második típus az SCD1. Ide tartoznak azok a mezők, amelyek változása esetén az eredeti értéket felülírhatjuk az új értékkel, így a régi állapot elveszik. A harmadik típust SCD2-nek hívjuk. Ezeknél az attribútumoknál fontos eltárolni, hogy melyik időszakra érvényesek, tehát szükséges egy érvényesség kezdete és vége, illetve egy aktuálisan érvényes mezőt felvennünk az adott rekordhoz. Változás esetén az eredeti rekordot érvénytelennek nyilvánítjuk az aktuális dátummal, és bekerül egy új rekord, amely az aktuális dátumtól kezdődően a Oldal: 20 / 40

21 következő változásig érvényes marad. A tényadatokat mindig az aktuálisan érvényes dimenziórekordokhoz kapcsoljuk hozzá. Az egyes dimenzió-attribútumokat tehát egyesével be kell kategorizálni a fenti típusok valamelyikébe. Ez üzleti döntés, mivel a legtöbb esetben több típus is értelmes eredményt ad. A dimenzió-mezők ilyen tipizálását az intézmény szakértőivel együttműködve fogjuk kidolgozni. 4.6 Üzleti szabályok, származtatott elemek Ahogy az egyes riportokon szereplő mutatók, mérőszámok és dimenziók definíciója elengedhetetlen a rendszer működéséhez, ugyanúgy ezeknek az értékeknek a számítási módját is pontosan le kell írni. A kimutatásokon szereplő mutatók illetve mérőszámok egy része származtatott elem: semelyik forrásrendszerben nem szerepel abban a formában, ahogy annak a riporton meg kell jelennie. Ide tartoznak többek között az aggregált és a konszolidált mérőszámok. Ezek esetén pontosan meg kell határoznunk, hogy milyen üzleti szabály alapján történik az aggregálás vagy a konszolidáció. De már olyan egyszerűnek tűnő mérőszámok esetén is mint például a hallgatói létszám felmerülhet, hogy az egyes szervezeti egységek, részlegek mást értenek alatta, másképp számolják. Ezeket a számítási módokat dokumentálni és szükség szerint egységesíteni kell üzleti döntés alapján. Ilyen szabályokra nemcsak a riportoló felületen van szükség: már az adattár szinten is lesznek olyan származtatott elemek, amelyek számítási módja üzleti döntéstől függ. A fejlesztési fázisban a következő üzleti szabályok további pontosítása szükséges: 1. Mi számít hallgatói lemorzsolódásnak (passzív félév, szak váltás, munkarend váltás, képzés elhagyása, kilépés a képzésről, stb.)? 2. A karok közötti átoktatások esetében milyen szabályok alapján kerülnek kiszámításra az átoktatási díjak? 3. Az oktatói terhelések mérése esetében: a. milyen módon van szabályozva az órakedvezmények köre (pl.: TDK felelős, stb.)? b. az egyes kurzusok esetében milyen szorzószámok mentén történik a terhelés megállapítása (pl.: angol nyelven oktatott tárgy 1,5 idősávnak számít)? c. hogyan határolható le a kereset kiegészítés keretében végzett oktatási tevékenység köre (pl.: távoktatás, levelezős képzés)? d. a kötelező óraterhelés keretének terhére elszámolható-e, és ha igen, hogyan a kereset kiegészítéses órák tartása? e. a vizsgaidőszaki terhelések számítására van-e intézményi szabályozás? 4. Értelmezhető-e, és ha igen, hogyan az egy képzésre jutó bevétel és kiadás? 5. A hallgatói féléves eredményeinek értékelés során milyen átlagok kiszámítása szükséges? Mi ezek pontos számítási módja? (tanulmányi átlag, súlyozott átlag, kollégiumi átlag, stb.) 6. A hallgató végzési eredményeinek értékelés során milyen átlagok kiszámítása szükséges? Mi ezek pontos számítási módja? (záróvizsga átlag, diploma átlag, stb.) 7. A kurzus és vizsga eredmények esetében a nem ötfokú skálán mérték esetében milyen átlagszámítási szabály vannak érvényben? 8. A felvételi esetében sorszáma milyen mélységben fontos, ehhez kapcsolódva a túljelentkezés milyen módon számolandó? 9. A diplomához szükséges nyelvvizsga követelmények hogyan alakulnak képzési szintenként és szakonként? Oldal: 21 / 40

22 10. Hogyan határozható meg a hallgatói juttatásra jogosultak létszáma az egyes juttatási jogcímek esetében? 4.7 Adatellenőrzések Az adatellenőrzés során minden adatminőségi kérdés a stage szinteken kerül kezelésre. Ebből adódóan a forrásból érkező hiányos, hibás vagy inkonzisztens adatok javítása a transzformációk során történik, az adattárba már csak tisztított adatok kerülnek betöltésre. További alapelv, azokat az adatokat, melyekről tudható, hogy rosszak, azokat lehetőség szerint nem töltjük be. Ha egy mezőről, rekordról, tábláról eldőlt, hogy helytelen adatot tartalmaz, az nem kerül betöltésre az adattárba, ezek az Adathibák adatbázisban lesznek eltárolva. Csak javított adat kerülhet be az adattárba; természetesen bizonyos esetek automatikusan javíthatók, más hibák azonban utólagos, manuális javítást igényelnek Adatellenőrzés architektúra 2. ábra: Adatellenőrzés architektúra A fenti ábra az adatellenőrzési folyamat architektúráját mutatja be. Az ETL folyamat három fázisa jól elkülöníthető. A stage0 adatbázisban a forrásrendszerek tükörképei jelennek meg. Az ETL folyamat Extract fázisában történik meg a karakterkódolások konszolidálása és az összes típuskonverziós művelet. Ettől a szinttől kezdve ebben a tekintetben az adatok egységesek és konzisztensek: a stage és az adattár karakterkódolását és az egyes mezők típusait úgy határozzuk a rendszerspecifikációban, hogy ezek ne okozzanak áttöltési hibát. Oldal: 22 / 40

23 A munka táblákban történik minden mező- és rekord szintű adatellenőrzés: reguláris kifejezések, hiányzó értékek, idegen kulcs sértések kezelése, stb. A konszolidált stage adattáblái tehát ilyen szempontból tisztának tekinthetők a továbbiakban. A konszolidált stage az adattár tükörképének tekinthető: ezeknek a tábláknak a struktúrája megegyezik az adattárház táblák szerkezetével. Ezen a szinten az adatok inkonzisztenciáját kezeljük. Elképzelhető például, hogy egy vagy több dimenzió betöltése sikertelenül futott le. Ilyenkor a hozzájuk kapcsolódó ténytábla nem minden esetben kerül betöltésre. A cél az, hogy ne jelenjenek meg az adattárban inkonzisztens sorok, de ha az adatok egy kisebb halmaza inkonzisztens, és az egész tábla hiánya több lekérdezésben okozna fennakadást, akkor a ténytábla ettől még betöltésre fog kerülni. Ezek a kivételes esetek a fejlesztés során lesznek definiálva Kilépési pontok Az adathibákat több szempont szerint csoportosíthatjuk. Az egyik szempont szerint megkülönböztetünk tényleges adathibát és metaadat hibát. Tényleges adathiba egy extrém érték, a metaadat hiba pedig az az információ, hogy egy adathalmaz több, mint 30%-a extrém értéket tartalmaz. Az ETL folyamatot úgy alakítjuk ki rendszerspecifikáció szinten, hogy a lehető legtöbb ismert hibát észlelje, adathiba miatt ne szakadjon meg a folyamat futása. Nem kerül javításra minden hiba, bizonyos hibák tárolásra sem kerülnek. A hiba figyelmen kívül hagyása is megfelelő lehet annak érdekében, hogy ne álljon le az ETL folyamat. A folyamatban kilépési pontokat csak a Load fázisban definiálunk. Itt dönthet úgy a job, hogy nem tölti be a táblát az adattárba, és hibával leáll. A tényleges adathibák (pl. hiányzó érték, stb.) nem okoznak ETL leállást: az ilyen hibákat vagy javításra, vagy figyelmen kívül hagyásra kerülnek ugyanakkor a számosságuk nyilván lesz tartva. Egy ETL job akkor állhat le, ha metaadat hibát észlel, azaz a tényleges adathibák számossága meghaladja a kritikus értéket. Ilyenkor az adott tábla betöltése nem történik meg, amely a hozzá kapcsolódó táblák betöltését is megakadályozhatja. A kilépési pontok definiálásával az is elérhető, hogy a felhasználók felé az adathibák teljes köréről visszajelzést adható: nem áll le az első hibánál a futás, hanem az összes hiba eltárolásra kerül. A definiált hibák stage szinten kerülnek kezelésre: detektálásra, javításra vagy figyelmen kívül hagyásra kerülnek, azaz adattár és adatpiac szinten az adatok minőségén már nem történik javítás. Az adattár és adatpiac közti áttöltés nem állhat le olyan hiba miatt, ami kezelendőként lett meghatározva Kezdeti adatminőség felmérése A rendszerterv elkészítése előtti fázisban az intézményi adatgazdák bevonásával előzetes felmérések kezdődtek az ismert adatminőségi problémák tekintetében. Ezek célja olyan intézkedések megfogalmazása, amelyek az adatminőségi hibákat az interfészek elérhetősége előtt is képesek javítani. Az interfészek rendelkezésre állásakor felmérjük az adatok minőségét egy kezdeti adatprofilozó folyamat segítségével. Ez a következő elemeket foglalja magában: alapstatisztikák készítése: Oldal: 23 / 40

24 o minimum, maximum, átlag értékek definiálása o extrém értékek szűrése NULL értékek számosságának meghatározása egyéb adatminőség felmérő folyamatok Ezek a vizsgálatok egyszeri, ad-hoc jellegűek, céljuk az adatminőség feltérképezése. Pontos módszert a fejlesztés során definiálunk. 5 Adattár adminisztráció 5.1 Adattár frissítések Kezdeti adatbetöltés Az adattár kezdeti feltöltésekor minden adatkör áttöltése megtörténik. Az alábbi táblázat tartalmazza az egyes adatkörökhöz definiált időhorizontot, amely azt adja meg, hogy milyen régi adatokat kell betölteni. A nincs időkorlát azt jelenti, hogy a forrásrendszer teljes tartalmát átemeljük a kezdeti adatbetöltéskor az időszaktól függetlenül. Az időhorizont meghatározásánál az a legfontosabb szempont, hogy melyik az az időszak a múltban, amelyre még minden tekintetben megfelelő mennyiségű és minőségű adat érhető el a forrásrendszerekből. Másik szempont, hogy szükséges-e régi adatok eltárolása az adattárban: elévült, nem használt adatok csak a tárhelyet növelik, felesleges a betöltésük. Az adattárban az így definiált időhorizontnál korábbi adatok tehát nem lesznek elérhetők. Az alábbi táblázatban megadott időhorizontok a vezetői igényekből kerültek levezetésre. Az egyes forrásrendszer interfészek rendelkezés állása után fel kell mérni az adatkörök minőségét és töltöttségét, és meg kell becsülni a kapcsolódó adattisztítási folyamatok erőforrás ráfordítását. A kapott eredményeket az intézményi VIR projekt csapatnak és a szállítónak közösen szükséges áttekinteni, és ezek alapján az esetleges időhorizont módosításokat megtenni. Forrásrendszer Adatkör Időhorizont Neptun hallgatói törzsadatok nincs időkorlát Neptun képzési szerkezet nincs időkorlát Neptun kurzusok, vizsgák 2006/07 őszi félév Neptun HR nincs időkorlát GÓLYA Felvételi 2006/2007 tanév nyári és pótfelvételi eljárása nexonbér bér január 1. nexonbér HR nincs időkorlát TÜSZ Ingatlan január 1. TÜSZ Pénzügy január 1. TÜSZ Számlák január 1. TÜSZ Kötelezettségvállalás január 1. TÜSZ Eszközök január 1. FELIR Ingatlan nincs időkorlát Vörös Ösvény Minőségmenedzsment, EFQM mutatók nincs időkorlát Oldal: 24 / 40

25 Forrásrendszer Adatkör Időhorizont EvaSys DPR kérdőívek nincs időkorlát EvaSys Minőségmenedzsment és nincs időkorlát elégedettségi felmérések TDK (Excel) TDK, OTDK, stb. intézményi adatfeltöltéstől függ AVIR később definiálandó később definiálandó 4. táblázat: Kezdeti adatbetöltés időhorizontja adatkörönként Rendszeres adatfrissítés Ugyanezekre az adatkörökre meg kell határozni a frissítési gyakoriságot is. Ez azt írja le, hogy milyen rendszerességgel kéri le az új adatokat az adattár a forrásrendszerekből. Ennek optimalizálására több szempontból is szükség van. Az egyik szempont, hogy a rendszeresen változó adatok minél kisebb késleltetéssel kerüljenek be az adattárba, minél frissebb adatokon lehessen riportot készíteni. Ugyanakkor a még nem véglegesített vagy ritkán változó adatokat nem célszerű gyakran lekérdezni, mert azzal egyrészt inkonzisztencia léphet fel (ideiglenes adatok esetén), másrészt feleslegesen használjuk az erőforrásokat, ezzel lassítva az áttöltés teljes folyamatát. Az áttöltést minden esetben éjszaka és hétvégén kell végezni, ezzel optimalizálva a rendszererőforrások terhelését. A teljes áttöltésnek 5 órába bele kell férnie, a pontos időablakról a rendszerüzemeltetéssel egyeztetünk a fejlesztés során. A frissítésnek három típusa van: beszélhetünk teljes, időszaki vagy inkrementális frissítésről. A teljes áttöltés azt jelenti, hogy időszaktól függetlenül a forrásrendszerben lévő összes adat betöltődik az adattárba. Időszaki áttöltéskor mindig csak az aktuális időszakra vonatkozó adatok kerülnek áttöltésre, de attól függetlenül, hogy változtak-e. Ebben az esetben fontos kitétel, hogy a lezárult időszakon történt visszamenőleges változások nem kerülnek be az adattárba. Az inkrementális frissítés esetén csak a megváltozott vagy új adatok töltődnek át. Ennek a tipizálásnak az adattárban két ponton is szerepe van. Egyrészt az interfészek esetén definiált frissítési tipizálás arra vonatkozik, hogy az adott forrásrendszerből minden alkalommal a teljes tartalmat átemeljük, vagy csak az adatok egy részét kapjuk meg. A másik pont a stage és az adattár közötti áttöltés: az adattárat alapértelmezés szerint inkrementálisan töltjük, tehát csak a változások kerülnek be. Csak a kezdeti betöltésnél, illetve egy esetleges komolyabb rendszerleállás esetén van szükség teljes áttöltésre (ilyenkor az aktuális adatok elvesznek). Az alábbi táblázat mutatja az adatkörök frissítési gyakoriságát és a forrásrendszerek frissítési típusát. Forrásrendszer Adatkör Frissítési gyakoriság Frissítés típusa Neptun hallgatói törzsadatok heti teljes Neptun képzési szerkezet heti teljes Neptun kurzusok, vizsgák időszakosan napi időszaki Neptun HR heti teljes GÓLYA Felvételi havi teljes nexonbér bér heti teljes nexonbér HR havi időszaki TÜSZ Ingatlan havi időszaki TÜSZ Pénzügy napi időszaki Oldal: 25 / 40

26 Forrásrendszer Adatkör Frissítési gyakoriság Frissítés típusa TÜSZ Számlák napi időszaki TÜSZ Kötelezettségvállalás havi időszaki TÜSZ Eszközök időszakosan napi időszaki FELIR Ingatlan havi teljes Vörös Ösvény Minőségmenedzsment, lezárt értékelések után időszaki EFQM mutatók EvaSys DPR kérdőívek lezárt felmérések után időszaki EvaSys Minőségmenedzsment és lezárt felmérések után időszaki elégedettségi felmérések TDK (Excel) TDK, OTDK, stb. lezárt konferenciák időszaki után AVIR később definiálandó 5. táblázat: Adatfrissítés gyakorisága adatkörönként Az adattár betöltése több lépésben történik. Először töltődnek a közös dimenziók, ezután az adatkörök saját dimenziói, és végül a ténytáblák új sorai Az idő dimenzió frissítése Az idő dimenzió egy speciális adatkörnek számít. Ezt a táblát a rendszerüzemeltetés felügyeli. Kezdetben visszamenőleg a legkorábbi időhorizontnak megfelelő dátumig, időben előretekintve pedig a következő egy évet töltjük fel egy előre definiált szkript segítségével. Ezt követően minden év végén fel kell tölteni a következő éves dátumadatokat ugyanannak a szkriptnek a használatával. Erre azért van szükség, mert az idő dimenzió a dátumokon kívül olyan metaadatokat is tartalmaz az egyes napokról, mint pl. a szorgalmi időszak kezdete vagy vége. Ezek az adatok évről évre változnak, és csak az év végén érhető el a következő évre vonatkozó hiteles információ. 5.2 Ütemezések Az adattár feldolgozó programjainak indításáért egy mindennap lefutó SQL Agent job a felelős. Ez a job megtalálható majd mind az éles, mind a teszt rendszerben. A betöltő az SQL szerver időzítőjét használja. Az időzítő egyetlen SSIS csomagot futtat, amely tartalmazza az összes betöltő futtatásához szükséges logikát. A csomag lefutásakor csak azok a betöltések hajtódnak végre, amelyeket az adott napon le kell futtatni. A betöltő csomagok futtatása után a rendszer frissíti az információkat a adatkockákban is. A csomag egy külön erre a célra létrehozott felhasználó nevében fut, amely hozzáfér az összes forrásrendszerhez, valamint adminisztrátori jogosultságokkal rendelkezik a célrendszerben. A csomagok éjszaka futnak le, mert futás közben a forrásrendszereket akár jelentősen is terhelheti, így azok válaszideje megnövekedhet. A teszt rendszer ütemezése eltér az élestől, itt az időzített futás tesztelésének idejére kapcsoljuk be az SQL Agent ütemezőjét. 5.3 Törzsadat-szótárak A több forrásrendszerben is tárolásra kerülő forrásadatok esetében szükséges a VIR rendszerben olyan konszolidált törzsadat-szótárakat létrehozni, melyek biztosítják 1. az egyes rendszerek között az entitások egyértelmű megfeleltetését; 2. az egyes rendszerekben külön tárolt, de egy entitáshoz tartozó adatok összerendelését. A kialakítandó törzsadat-szótárak köre a következők szerint lett megállapítva. Oldal: 26 / 40

27 Törzsadat-szótár szervezeti egységek oktatók (foglalkoztatottak) oktatók (óraadók) helyiségek gazdasági adatok összerendelés Érintett forrásrendszer Neptun, TÜSZ, nexonbér Neptun, nexonbér Neptun, nexonbér Neptun, TÜSZ, FELIR Neptun, TÜSZ, nexonbér A rendszerterv készítését megelőző időszakban az intézményi projekt csapat bevonásával megkezdődött ezen törzsadat-szótárak kialakításának folyamata. Az eddigi eredményeket a rendszerterv kapcsolódó melléklete tartalmazza. 5.4 Mentések, helyreállítások A VIR egyes szintjeinek biztonsági mentésére és helyreállítása eltérő stratégiákat alkalmazunk Stage táblák A stage adatbázis három elkülönülő részre bontható: a stage0-ra, a köztes munkatáblákra és a konszolidált stage táblákra. Ezen szintek adatai csak ideiglenesen tárolódnak el, így minden betöltéskor felülíródnak. Ennek megfelelően az ezekről készült biztonsági mentések csak a stage előző állapotát tudják visszaadni. A stage0 táblák a forrásrendszer tükreként viselkednek, egy az egyben az áttöltött adathalmazt tartalmazzák minden jellegű adatfeldolgozás nélkül. Ezekről a táblákról kettős másolatot készítünk. Egyrészt a stage0 backup táblába minden áttöltés előtt bekerül a tábla teljes tartalma (felülírva a backup tábla aktuális tartalmát), így az áttöltés során felmerülő hiba esetén automatikusan vissza tud állni a rendszer az előző állapotra. Ez a backup adatbázis dinamikus, tehát csak az előző állapotot tudjuk visszanyerni. Másrészt az adatok kinyerését követően rögtön készítünk egy másolatot a tábláról MSSQL RAW formátumban, dátummal ellátva a fájlrendszeren. Ez a formátum az SQL Server sajátja, ebből gyorsan és könnyedén visszaállítható bármely elmentett állapot. A köztes munkatáblák feladata az adatok konszolidációja, aggregálása és tisztítása. Ebből adódóan az itt tárolt adatok gyakran még nem teljesek, és minőségük is a feldolgozottság szintjétől függ. Ezek a stage0 táblákból előállíthatók, így biztonsági mentésük nem szükséges. Ugyanez érvényes a konszolidált stage táblákra is. Adatvesztés akkor léphet fel, ha a stage0 tábla betöltése a következő esedékes betöltésig nem valósul meg. Ekkor ugyanis az adatok egy része már a következő állapotra vonatkozik, és az aktuális állapot még nem került be a rendszerbe. Ezt az ETL jobok belső logikája kezeli Adattár táblák Az egyes betöltő jobok futásának utolsó lépése az adott adattár táblák biztonsági mentése egy külső, az adattár adatbázistól eltérő helyre. Az adatár visszamenőleg is idősorosan tartalmazza a betöltött adatokat, ezért a biztonsági mentést követően a korábbi backup törlődik. Szükség esetén ezt az intézmény rendszerüzemeltetése kimentheti szalagra vagy egyéb külső tárhelyre. Az előző állapotból és a stage0 táblák biztonsági másolataiból bármikor visszaállítható az adattár aktuális, a hiba bekövetkezése előtti állapota. A két állapot között a visszaállítás idejétől eltekintve nem kell adatvesztéssel számolni. Oldal: 27 / 40

28 5.4.3 Adatpiac és adatkockák Az adatpiacok táblái fizikailag az adattár részét képezik, így ezek biztonsági mentése a teljes adattáréhoz hasonlatos. A kockák struktúráját és adattartalmát az SSAS adatbázis tartalmazza, ezek mentését szintén az ETL jobok végzik. A kocka sikeres frissítése után készül róla teljes mentés. Az idősoros tárolás erre is érvényes, így itt is csak az utolsó állapot mentése történik, csak az állítható vissza az ilyen típusú másolatból Riportok A riportok két csoportra oszthatók attól függően, hogy milyen adatokból készülnek. Egyik részük (jellemzően a kevésbé bonyolult, kevesebb adatbázis-műveletet igénylők) minden egyes megnyitáskor a mások áltat is használt alapadatokból (DW szint vagy kockából) generálja le a riportot. A másik csoportban olyan riportok vannak, melyek bonyolultabbak, s ez által legenerálásuk sok időt venne igényben. Utóbbiak saját adatelőkészítést igényelnek, s ezek az áttöltőkhöz hasonlóan be van ütemezve az éjszakai futtatásokba. Az első csoport csak a riportok definícióit jelenti: az adattartalom mindig a riport generálásakor készül az alapadatokból. Ezeknek a szerkezetéről (a riport definícióról) készül biztonsági mentés, az adattartalomról nem. Utóbbi csoport alapadatai az áttöltésekhez hasonlóan készülnek el, így biztonsági mentésük módszere is megegyezik azokéval: a kész (riportok alapját képező) táblák csak abban az esetben íródnak felül, ha az új időszakra vonatkozó tábla tökéletesen elkészült. 5.5 Archiválás, öregítés Az archiválás elsődleges célja a feleslegessé vált, elévült vagy ritkán használt adatok eltávolítása a rendszerből a tárhely megfelelő menedzselése és a hatékony működés fenntartása céljából. Ez az eltávolítás jelenthet teljes törlést vagy külső tárhelyre, szalagra mentést is Log-adatok és adathibák öregítése A log-adatokra és az adathibák adatbázisra tipikusan azért van szükség, hogy a rendszerüzemeltetés a rendszer működését követni tudja, és az esetleges adathibákat részletesen is meg tudja vizsgálni. Ezek az adatok viszont nagyon gyorsan elévülnek és feleslegessé válnak: a rendszerüzemeltetésnek folyamatosan monitoroznia kell a rendszert, így néhány héttel korábbi log-adatok már nem tartalmaznak érdemi információt számukra. A log-adatokról és az adathibákról is készülnek aggregált táblák, amelyek a futtatások eredményeit összesítve tartalmazzák. Ezeket a táblákat referenciaként megőrizzük, de az egy hónapnál régebbi részletes log-adatokat és adathibákat minden betöltést követően automatikusan törli a rendszer Az adattár archiválása Az adattár rövid és középtávon sem nő olyan nagyságúra, hogy az adatkockák előállítása ne férjen bele az áttöltésre szánt időablakba. Ugyanakkor csak középtávon néhány év múlva, a rendszer használata során derül ki az, hogy melyik táblákat használják a legtöbben riportokhoz, és milyen időintervallumra kíváncsiak általában a felhasználók. Ezen mérési eredményeket követően van értelme az adattár archiválási módszertanának kidolgozására a hatékonyabb működés érdekében. Oldal: 28 / 40

29 5.6 Adminisztratív riportok A feldolgozásokat végző egyes jobok felelősei értesítést kapnak, ha hiba történ a futás során, és a rendszer egy kilépési ponton megáll. Az üzenetben megjelenik maga a hibaüzenet, a hiba időpontja, valamint az, hogy melyik job futása során lépett fel a hiba. Az automatikus eken túl a rendszer üzemeltetői és fejlesztői számára riportok is készülnek a VIR-ben. Ezeknek a riportoknak a célja az, hogy megkönnyítsék a napi üzemeltetési munkát, illetve a különböző kimutatások alapján a rendszert még hatékonyabbá lehessen tenni. A következő táblázat mutatja be a fejlesztésre kerülő adminisztratív riportokat. Riport neve Adathibák összegzés Adathibák részletes Futási statisztikák összegzés Riportfuttatási statisztikák összegzés Riportfuttatási statisztikák részletes 6. táblázat: Adminisztratív riportok Paraméterek időszak, hibakód időszak, hibakód időszak időszak időszak, riport Az adminisztratív riportok a VIR portál Kompetencia központ oldalán is elérhetők lesznek. Ezeken kívül az adathiba és a log adatbázisokból ad-hoc módon több információ is kinyerhető. 5.7 Biztonsági, adatvédelmi megfontolások A rendszer biztonsága érdekében az alábbi adatvédelmi szempontok betartása szükséges. Biztonsági mentések A VIR fejlesztés szkópja az alábbi mentési feladatok elvégzésére terjed ki: betöltő és adatfeldolgozó jobok biztonsági mentése HDD-re az adattár teljes adattartalmának mentése HDD-re riportdefiníciók mentése HDD-re Nem a fejlesztés hatókörébe tartozik: mentések kiírása szalagra vagy más tárolóra VIR Portál oldalainak, szerkezetének biztonsági mentése Elszeparált hálózati környezet (VLAN) A rendszer üzemeltetéséhez szükség van bizonyos szolgáltatások és a hozzá tartozó portok megnyitására. Ahhoz, hogy ezek ne jelentsenek biztonsági kockázatot, egy VLAN létrehozása javasolt. A VLAN-on belül a szerverek egymást elérik olyan portokon is, melyek a külvilág számára nem elérhetőek. Megfelelő határvédelem A szerverek saját tűzfala egy plusz védelmet tud adni a VLAN határait védő tűzfalon túl. Ezen a tűzfalon csak az alkalmazás által használt legszükségesebb portokat szabad megnyitni (ezen portok listája a teljesen pontos szerkezet fejlesztése során derül ki). Oldal: 29 / 40

30 A távoli asztal kapcsolat esetén csak az RDP 6-os verziója fölötti protokoll használata célszerű, régebbi protokollokat a szerveren tiltani kell. Más programok az adattár szervereken Az adattár szerver sok szenzitív adatot is tartalmaz. Más rendszerek telepítése ugyanarra a szerverre biztonsági kockázatot jelentene, ezért mindenképpen szükséges, hogy ezek dedikáltan az adattár kiszolgálását végezzék. A feldolgozások időigényesek lehetnek, ezért az időzítéseket is megzavarhatja, ha más alkalmazás leterheli a szervert működés közben. Azonosíthatóság A rendszerben minden fejlesztőnek és tesztelőnek a saját belépési kódjával kell dolgoznia. Kerülendő a Rendszergazda felhasználóval való belépés. Szintén kerülendő a több személy által használt belépési kódok alkalmazása (pl. fejlesztő). Ilyen kódokat csak tesztelési célra szabad használni, amikor egy adott szerepkörben levő felhasználó jogosultságait kívánjuk tesztelni. Váron kívüli adatvédelem Az adatok biztonsága érdekében fontos az alábbi szabályok betartása: A fejlesztői adatbázisba (ha az nem a teszt szerveren van) nem szabad szenzitív, éles adatokat átmásolni. A fejlesztéshez teszt adatok előállítása szükséges. A szenzitív adatok nem hagyhatják el a VLAN határvonalát. Az adatgazdáknak célzott visszajelzések, melyekben nagy mennyiségű adat van (pl. tételes adathiba jelentés Excelben), nem küldhetők en. Ezeket egy közösen használt fájlszerveren keresztül lehet eljuttatni a címzetteknek. Az automatikusan elküldött riportok nem tartalmazhatnak szenzitív adatokat. Amennyiben ilyen igény merül fel, akkor az csak a riport linkjét tartalmazza, a riportot a VIR Portálon keresztül tekintheti meg a felhasználó. 5.8 Jogosultság A vezetői információs rendszerben két jogosultságkezelési mechanizmust különböztethetünk meg: az objektum szintű és az adatszintű jogosultságkezelést Objektum szintű jogosultságok Az objektum szintű jogosultságok kiosztása csoportokon keresztül történik. Az egyes szerepköröknek megfelelő Active Directory csoportokat kell létrehozni, majd a felhasználókat ezekbe a csoportokba kell besorolni. Az adattárban az alábbi objektumok jogosultságkezelése valósítható meg a fenti módszerrel: Adattár táblák Adatkockák a kockákat minden felhasználó eléri, azonban adatait csak azok láthatják, akik az adott adathoz is rendelkeznek hozzáféréssel Riportok Oldal: 30 / 40

31 Portál objektumok Dokumentumok ETL jobok ezeket csak az adminisztrátorok érhetik el Adatszintű jogosultságok Lehetőség nyílik az egyes adatok különböző dimenziók mentén történő szűrésére, azaz az adatkockák vagy riportok sor szintű jogosultságának beállítására. Ez több módon is megvalósulhat: 1. Szervezeti hierarchia alapján: A felhasználók csak a hozzájuk rendelt szervezeti egység adatait láthatják, a többi szervezeti egységre vonatkozóan csak aggregáltan vagy egyáltalán nem érik el az adatokat. 2. Témaszám alapján: Egy felhasználó a hozzárendelt témaszámok adatait láthatja. 3. Bármely dimenzió alapján: A többi dimenzió alapján is lehetőség van a jogosultságok kezelésére, beállítására. Előre egyeztetett dimenziók esetében meghatározható, hogy az adott dimenzió adott eleméhez mely felhasználók férhetnek hozzá. Ezzel lehetőség nyílik a szenzitív béradatok jogosultságának felhasználó szintű kezelésére is, és meghatározható, hogy egy adott felhasználó mely munkavállalók béradatait láthatja. A jogosultságok egy Excel fájlban tarthatók karban, melyben az alábbi adatokat kell megadni: a felhasználó vagy csoport neve a jogosultság hatóköre (kocka vagy riport) neve a dimenzió attribútum, amire az adott korlátozás vonatkozik hozzáférési szabály A jogosultságokat adminisztráló Excel fájl mintája mellékletben megtalálható Konkrét jogosultsági szintek, adatszintű jogosultságok Az intézményi szerepköröket, struktúrát és vezetői igényeket figyelembe véve a VIR-ben az alábbi jogosultsági struktúra megvalósítása javasolt. Megnevezés S. Adott szinthez tartozó szereplők Rektori szint 1. rektor 2. főtitkár rektorhelyettesek gazdasági főigazgató Gazdasági Tanács további tagjai Szenátus további tagjai 3 Rektori Hivatal és alá tartozó szervezeti egységek vezetői (területenként) GMI és alá tartozó szervezeti egységek vezetői (területenként) Stratégiai- és Minőségmenedzsment Központ vezetői Tanulmányi és Oktatásszervezési Központ vezetői 4 Kollégium és Diákszálló vezetője Könyvtár és Távoktatási Központ vezetője Hallgatói Szolgáltatások Központ vezetője Felnőttképzési és Szakképzési Központ vezetője Sport- és Szabadidő Központ vezetője Oldal: 31 / 40

32 Megnevezés S. Adott szinthez tartozó szereplők Intézeti és 1 intézeti vezetők tanszéki szint 2 tanszéki vezetők DW szint 1 VIR kompetencia központ külső VIR tanácsadók Adatszintű jogosultságkezelést a következők mentén javasolt megvalósítani: 1. a bérezési adatok érzékeny adatnak minősülnek, így szükséges ezek külön kezelése; 2. egyelőre nem definiált módon, később meghatározandó TÜSZ témaszámok alapján VIR Kompetencia Központ A VIR Kompetencia Központ feladata a jogosultságok adminisztrálása, beállítása a rendszerben. A riportok belső működése biztosítja, hogy ha egy felhasználó az adatokhoz nem fér hozzá, akkor hiába éri el a riportot, az nem jelenít meg számára adatokat. A jogosultságok beállításához az üzemeltetői kézikönyv ad segítséget. A VIR kompetencia központ tagjainak teszt és éles rendszerbeli jogosultságainak meghatározása a következők szerint javasolt: a VIR kompetencia központ tagok alapértelmezésben minden adatot láthatnak mind a tesztrendszerben, mind az éles környezetben, hiszen a riportok és kockák elkészítéséhez és teszteléséhez szükséges, ezáltal a VIR kompetencia központ tagoknak az éles rendszerben a jogosultsága nem az intézményi pozíciójuktól függ. A VIR kompetencia központ működésének szabályozását az intézmény SzMSz keretében fogja megtenni. 5.9 Naplózás A rendszer működését több szinten naplózzuk. A napló adatok lehetővé teszik, hogy az előforduló hibákat vissza lehessen keresni, azok okát fel lehessen deríteni, illetve hogy a felhasználók szokásait, aktivitását monitorozni lehessen. Adathibák naplózása Az adatminőség ellenőrzése során minden észlelt probléma bekerül a rendszer naplóba (részletesen az 4.7 ADATELLENŐRZÉSEK fejezetben). Feldolgozások naplózása A feldolgozó programok minden lépését az SSIS beépített mechanizmusa naplózza. A napló az adattárba a sysssislog nevű táblába történik. A rendszer által előállított log állományokat nem tekintjük véglegesnek. A feldolgozás végén készítünk olvashatóbb állományt a rendszer naplózásának eredményéből, melyet az üzemeltetés könnyen tud értelmezni. Adatkockák használati naplója Az aggregációk optimalizálásához a rendszer lekérdezési naplót készít. Ennek célja nem az, hogy minden lekérdezést naplózzunk, hanem az, hogy a kockák tipikus lekérdezéseire statisztikai úton becsülést lehessen adni. Ezt az OlapQueryLog táblában tároljuk. Oldal: 32 / 40

33 Riportok használati naplója A riportok naplózásához egy beépített adatbázis táblát használunk. A tábla tartalmazza minden riport futtatását, és tárolja, hogy ki futtatta illetve milyen formátumban kérte a kimenetet. A napló alapján a felhasználói szokások elemezhetők. Portál naplózás A VIR portálon végzett műveletek naplózását a SharePoint beépített naplózása végzi. Ez lehetővé teszi, hogy a SharePoint felületéről lekérdezhetők a webhely használati és látogatottsági adatai. Oldal: 33 / 40

34 6 Rendszerkörnyezet 6.1 Kapcsolódás más rendszerekhez A VIR kapcsolódását a helyi adatforrásokhoz és más rendszerekhez az alábbi ábra szemlélteti. 3. ábra: VIR kapcsolódása más rendszerekhez A VIR két példánya közül a végfelhasználók csak az éles rendszert érik el. A teszt rendszert csak a VIR Kompetencia Központ tagja, a tesztelők és a fejlesztők érik el. Mindkét VIR példány hozzáfér a forrásadatokhoz, így tesztelhetők az adatbetöltések. A rendszer javításai, kiegészítései a fejlesztői környezetből egy ftp helyen keresztül kerülnek a teszt, illetve az éles környezetbe (ennek folyamatát később mutatjuk be). Az országos adattár (AVIR) két szerepkörben is megjelenik a rendszerben: mint a kötelező adatszolgáltatás cél rendszere mint a rendszer egyik forrás rendszere (központi lekérdezhető adatok) Oldal: 34 / 40

35 6.2 Belső felépítés A VIR működéséhez az alábbiakban felsorolt rendszer-szolgáltatásokra van szükség. A rendszer működéséhez szükséges szolgáltatások 1. SQL szerver a) adatbázis tárolása, kezelése b) OLAP szerver (SSAS) c) riport kiszolgáló (SSRS) d) integrációs szolgáltatások (SSIS) e) ütemező (SQL agent) 2. SharePoint a) a riportok megjelenítéséhez szükséges portál kiszolgálója 3. Storage a) az adatbázisok tárolásához szükséges tárterület (adattár, archív adatok, naplók) b) adat integrációs jobok és riportok definícióinak tárolása c) riportok egyik publikációs lehetősége a fájl szerverre való mentés Fejlesztéshez, üzemeltetéshez szükséges szolgáltatások 1. VPN: Virtuális magánhálózat, mely lehetővé teszi, hogy a rendszer üzemeltetői, fejlesztői távolról is elérhessenek olyan szolgáltatásokat, melyeknek a publikus elérése biztonsági kockázatot jelentene. A VPN olyan hozzáférést kell biztosítson, hogy a belépő felhasználó elérje a szerverek VLAN-ját. 2. FTP kliens: Ahhoz szükséges, hogy a fejlesztői környezetből a frissítéseket, kiegészítéseket el lehessen juttatni a teszt és éles környezetekbe. 3. mstsc: Távoli asztal kapcsolat, mely lehetővé teszi, hogy az üzemeltető és fejlesztő csapat hozzáférjen a szerverekhez. 6.3 Fizikai rendszerkörnyezet terv Az alábbi ábra mutatja, hogy a fent vázolt szolgáltatások milyen hardver szerkezettel és infrastruktúrával valósíthatók meg. Oldal: 35 / 40

36 4. ábra: Hardver infrastruktúra A szerverekkel szemben támasztott követelmények az alábbiak: SZOLF SharePoint szerver Ez a szerver szolgálja ki a Főiskola SharePoint rendszerét. A VIR az első évben biztosan nem jelent akkora terhelést, hogy az hardverbővítést tegyen szükségessé. A szerveren a rendszer számára előreláthatólag 20GB tárterület szükséges. Komponens Éles rendszer Teszt rendszer Portál URL Content A rendszer által használt content A rendszer által használt content adatbázis adatbázisába kerül a VIR is. adatbázisába kerül a VIR_teszt is. Új site collection 0 db 0 db Site 1 db 1 db Felhasználói hitelesítés Windows hitelesítéssel, AD alapján Windows hitelesítéssel, AD alapján Adattár szerver 7. táblázat: SharePoint szerver paraméterei Az adattár teljes hátterét kiszolgáló szerver. Tartalmazza az éjszakai feldolgozó programok futtatását végző komponenseket, az OLAP és SQL kiszolgálót és a riportok futtatását végző komponenseket is. Javasolt hardver: dual processzor 3Ghz 4 GB RAM 100 GB HDD Storage Oldal: 36 / 40