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

Méret: px
Mutatás kezdődik a ... oldaltól:

Download "TÁMOP 4.1.1 Szolnoki Főiskola VIR rendszerterv. Szolnoki Főiskola. TÁMOP 4.1.1 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

TÁMOP 4.1.1 intézményi követelmények. Vezetői Információs Rendszer

TÁMOP 4.1.1 intézményi követelmények. Vezetői Információs Rendszer TÁMOP 4.1.1 intézményi követelmények Vezetői Információs Rendszer Tartalom 1. Bevezetés... 2 2. Szakmai követelmények... 2 A rendszer felhasználói és a biztosított felhasználások (információszolgáltatások)...

Részletesebben

Az ÓBUDAI EGYETEM ADATTÁR ALAPÚ VEZETŐI INFORMÁCIÓS RENDSZER (VIR) MŰKÖDÉSÉNEK SZABÁLYZATA

Az ÓBUDAI EGYETEM ADATTÁR ALAPÚ VEZETŐI INFORMÁCIÓS RENDSZER (VIR) MŰKÖDÉSÉNEK SZABÁLYZATA verzió Az Óbudai Egyetem Szervezeti és Működési Szabályzata melléklet Szervezeti és Működési Rend 50. függelék Az ÓBUDAI EGYETEM ADATTÁR ALAPÚ VEZETŐI INFORMÁCIÓS RENDSZER (VIR) MŰKÖDÉSÉNEK SZABÁLYZATA

Részletesebben

Intézményi interfész leírás

Intézményi interfész leírás Intézményi interfész leírás A felsőoktatási intézmények által az AVIR központi adattárba küldendő adatok interfészének bemutatása Tartalomjegyzék TARTALOMJEGYZÉK... 1 A FELSŐOKTATÁS ÁGAZATI ADATTÁR (AVIR)

Részletesebben

NEPTUN_GOLYA. (Felvételi konvertáló modul) Budapest, 2002

NEPTUN_GOLYA. (Felvételi konvertáló modul) Budapest, 2002 (Felvételi konvertáló modul) S Budapest, 2002 TARTALOM TARTALOM 2 1. BEVEZETÉS 3 2. HASZNÁLAT 4 2.1. Bejelentkezés adatáttöltéshez 5 2.1.1. Státusz információk 8 2.1.2. Módosítás véglegesítése 12 2.2.

Részletesebben

A FileZilla program beállítása az első belépés alkalmával

A FileZilla program beállítása az első belépés alkalmával 6. A záróvizsga-jegyzőkönyv készítése A záróvizsga-jegyzőkönyveketa Karok többsége a jegyzőkönyvkészítésre Dr. Tánczos László által kifejlesztett Access alkalmazás használatával készíti el. A záróvizsga-jegyzőkönyv

Részletesebben

PRECÍZ Információs füzetek

PRECÍZ Információs füzetek PRECÍZ Információs füzetek Információk, Módszerek, Ötletek és Megoldások a Precíz Integrált Ügyviteli Információs rendszerhez 3. EXCEL adatkapcsolat (mod. 2009.07.) Ügyviteli nyilvántartások és EXCEL formátumú

Részletesebben

A felsőoktatási szolgáltatások rendszer szintű fejlesztése: diplomás pályakövetés és vezetői információs rendszerek (TÁMOP 4.1.3)

A felsőoktatási szolgáltatások rendszer szintű fejlesztése: diplomás pályakövetés és vezetői információs rendszerek (TÁMOP 4.1.3) A felsőoktatási szolgáltatások rendszer szintű fejlesztése: diplomás pályakövetés és vezetői információs rendszerek (TÁMOP 4.1.3) 2011. december 7. Fejlesztés a minőségi oktatásért Minőség a felsőoktatásban

Részletesebben

Adattár. Adattár. Elemzések, modellezés. Adatszolgáltatás

Adattár. Adattár. Elemzések, modellezés. Adatszolgáltatás ADATTÁRALAPÚ VEZETŐI INFORMÁCIÓS RENDSZER (AVIR) Az táralapú Vezetői Információs Rendszer (AVIR) fő célja, hogy hatékonyabbá tegye az intézmény működését, megalapozottabbá tegye a vezetői döntéseket, illetve

Részletesebben

DW 9. előadás DW tervezése, DW-projekt

DW 9. előadás DW tervezése, DW-projekt DW 9. előadás DW tervezése, DW-projekt Követelmény felmérés DW séma tervezése Betöltési modul tervezése Fizikai DW tervezése OLAP felület tervezése Hardver kiépítése Implementáció Tesztelés, bevezetés

Részletesebben

Ágazati Vezetői Információs Rendszer koncepciója

Ágazati Vezetői Információs Rendszer koncepciója Ágazati Vezetői Információs Rendszer koncepciója Ágazati Vezetői Információs Rendszer koncepciója Bemutatja: Bruhács Tamás főosztályvezető-helyettes - OM, Fejlesztési és Tudományos Ügyek Főosztálya Hodász

Részletesebben

TÁMOP 4.1.1 VIR alprojekt VIR felhasználói kézikönyv

TÁMOP 4.1.1 VIR alprojekt VIR felhasználói kézikönyv 1. sz. melléklet TÁMOP 4.1.1 VIR alprojekt Készítette: Aloha Informatika Kft. Tartalomjegyzék 1. A Vezetői Információs Rendszer, mint a stratégiai gondolkodás eszköze...4 1.1 Elméleti háttér...4 1.2 VIR

Részletesebben

ETL keretrendszer tervezése és implementálása. Gollnhofer Gábor Meta4Consulting Europe Kft.

ETL keretrendszer tervezése és implementálása. Gollnhofer Gábor Meta4Consulting Europe Kft. ETL keretrendszer tervezése és implementálása Gollnhofer Gábor Meta4Consulting Europe Kft. Tartalom Bevezetés ETL keretrendszer: elvárások és hogyan készítsük A mi keretrendszerünk Bevezetési tanulságok

Részletesebben

Az alábbiakban a portál felépítéséről, illetve az egyes lekérdező funkciókról kaphat részletes információkat.

Az alábbiakban a portál felépítéséről, illetve az egyes lekérdező funkciókról kaphat részletes információkat. Súgó Az alábbiakban a portál felépítéséről, illetve az egyes lekérdező funkciókról kaphat részletes információkat. A lekérdező rendszer a Hírközlési Szolgáltatások és Interfész bejelentések, valamint az

Részletesebben

Adóhátralék kezelés egyszerűen. Használati útmutató

Adóhátralék kezelés egyszerűen. Használati útmutató Használati útmutató Program indítása: A telepítés utáni első indításkor a program a szükséges alapbeállításokat elvégzi, és automatikusan újra indul. A főképernyőn a bejelentkezéshez mindig meg kell adni

Részletesebben

Projektmenedzsment tréning

Projektmenedzsment tréning Projektmenedzsment tréning Komplex szervezetfejlesztési projekt megvalósítása Kaposvár Megyei Jogú Város Polgármesteri Hivatalánál ÁROP-1.A.2/B-2008-0020 2010.10.20. Tematika Projektek Projektcsapat összeállítása

Részletesebben

Felsőoktatási intézményi adatmodell

Felsőoktatási intézményi adatmodell Felsőoktatási intézményi adatmodell Bevezető Mi a modell célja A TÁMOP 4.1.3 program az Educatio Nonprofit Kft.-nek feladatként írta elő egy intézményi adatmodell elkészítését. Az adatmodell céljait a

Részletesebben

Vezetői Információs Rendszer Felhasználói kézikönyv

Vezetői Információs Rendszer Felhasználói kézikönyv Vezetői Információs Rendszer Felhasználói kézikönyv Verzió 1.2 TÁMOP 4.1.1-08/2/KMR pályázat Adattár alapú Vezetői Információs Rendszer alprojekt 2011. szeptember 30. Tartalomjegyzék 1 A Vezetői Információs

Részletesebben

Sikerünk kulcsa: az információ De honnan lesz adatunk? Palaczk Péter

Sikerünk kulcsa: az információ De honnan lesz adatunk? Palaczk Péter Sikerünk kulcsa: az információ De honnan lesz adatunk? Palaczk Péter Bevezető az Oracle9i adattárházas újdonságaihoz Elemzési és vezetői információs igények 80:20 az adatgyűjtés javára! Adattárházak kínálta

Részletesebben

Döbrönte Zoltán. Data Vault alapú adattárház - Fél óra alatt. DMS Consulting Kft.

Döbrönte Zoltán. Data Vault alapú adattárház - Fél óra alatt. DMS Consulting Kft. Data Vault alapú adattárház - Fél óra alatt Döbrönte Zoltán DMS Consulting Kft. 1 Miről lesz szó Adattárház automatizálás Hol alkalmazható a leghatékonyabban Célok, funkcionalitás, előnyök Data Vault modellezés

Részletesebben

Diákhitel igénylés folyamata

Diákhitel igénylés folyamata 1 Diákhitel igénylés folyamata Beállítások A DHK-tól kapott éles vagy teszt tanúsítványokat telepíteni kell a megfelelő szerveren, szervereken (ld. Neptun üzemeltetési dokumentáció). A tesztelési folyamat

Részletesebben

Adatbázis, adatbázis-kezelő

Adatbázis, adatbázis-kezelő Adatbázisok I. rész Adatbázis, adatbázis-kezelő Adatbázis: Nagy adathalmaz Közvetlenül elérhető háttértárolón (pl. merevlemez) Jól szervezett Osztott Adatbázis-kezelő szoftver hozzáadás, lekérdezés, módosítás,

Részletesebben

Mérés gyakorisága. Aktív jogviszonnyal rendelkező hallgatók száma Fő Féléves ORH Neptun Automatikus

Mérés gyakorisága. Aktív jogviszonnyal rendelkező hallgatók száma Fő Féléves ORH Neptun Automatikus A.1 Hallgatói létszám növelése A.1.1 Aktív jogviszonnyal rendelkező hallgatók Aktív jogviszonnyal rendelkező hallgatók Fő Féléves ORH Neptun Automatikus Finanszírozási szempontú kimutatás, azaz kétszakos

Részletesebben

Minőségellenőrzési kérdőív kitöltő program Felhasználói kézikönyv

Minőségellenőrzési kérdőív kitöltő program Felhasználói kézikönyv Minőségellenőrzési kérdőív kitöltő program Felhasználói kézikönyv Magyar Könyvvizsgálói Kamara 2010. augusztus 18. Tartalom A program főablaka... 3 A fejléc, a felső menüsor valamint az eszköztár... 4

Részletesebben

Vezetői Információs Rendszer a Központi Statisztikai Hivatalban

Vezetői Információs Rendszer a Központi Statisztikai Hivatalban Vezetői Információs Rendszer a Központi Statisztikai Hivatalban Dr. Kárpáti József Főosztályvezető, KSH Tervezési főosztály Microsoft Szeminárium, 2007. március 21. E-mail: jozsef.karpati@ksh.hu Tel.:

Részletesebben

Diákigazolvány. Belépés> Adminisztráció> Iskolai oktatás képes menü> diákigazolvány> diákigazolvány igénylés

Diákigazolvány. Belépés> Adminisztráció> Iskolai oktatás képes menü> diákigazolvány> diákigazolvány igénylés Tartalom Új diákigazolvány igénylés folyamata... 2 1. IAR feltöltéshez szükséges jogosultságok beállítása... 2 2. Token kérés... 2 3. Új igénylés feladása... 2 Igénylések keresése, szinkronizálása... 4

Részletesebben

Importálás. más típusú (pl:.imp,.xml,.xkr,.xcz) állomány beimportálása a nyomtatványkitöltő programba

Importálás. más típusú (pl:.imp,.xml,.xkr,.xcz) állomány beimportálása a nyomtatványkitöltő programba Importálás Külső programok által generált imp és.xml állományokat be lehet tölteni a program import funkcióival. Az ABEV2006 az xml állományok importálását nem tudta. Ez újdonság a nyomtatványkitöltő programban.

Részletesebben

Vállalati információs rendszerek I, MIN5B6IN, 5 kredit, K. 4. A meghirdetés ideje (mintatanterv szerint vagy keresztfélében):

Vállalati információs rendszerek I, MIN5B6IN, 5 kredit, K. 4. A meghirdetés ideje (mintatanterv szerint vagy keresztfélében): Követelményrendszer 1. Tantárgynév, kód, kredit, választhatóság: Vállalati információs rendszerek I, MIN5B6IN, 5 kredit, K 2. Felelős tanszék: Informatika Szakcsoport 3. Szak, szakirány, tagozat: Műszaki

Részletesebben

NEPTUN MOBIL ALKALMAZÁS FELHASZNÁLÓI SEGÉDLET

NEPTUN MOBIL ALKALMAZÁS FELHASZNÁLÓI SEGÉDLET NEPTUN MOBIL ALKALMAZÁS FELHASZNÁLÓI SEGÉDLET Felhasználói dokumentáció verzió 1.0 Budapest, 2015. Változáskezelés Verzió Dátum Változás Pont Cím Oldal Kiadás: 2015.07.05. Verzió: 1.6. Oldalszám: 2 / 12

Részletesebben

PwC EKAER Tool felhasználói leírás. 2015. május

PwC EKAER Tool felhasználói leírás. 2015. május www.pwc.com/hu/ekaer PwC EKAER Tool felhasználói leírás 2015. május Tartalom Bejelentések létrehozása 3 1. A forrás Excel állomány kitöltése 3 2. A forrás Excel állomány mentése 4 A szükséges mezők kitöltését

Részletesebben

Kifizetések kezelése. 1 Kifizetési dátumok megadása pénzügyi kódokhoz

Kifizetések kezelése. 1 Kifizetési dátumok megadása pénzügyi kódokhoz Kifizetések kezelése 1 Kifizetési dátumok megadása pénzügyi kódokhoz 1.1 Pénzügyi kódok menüponttól indulva Pénzügyek (kék menüpont, csak lenyitni + jelnél)(78600)/kifizetési jogcímek (jogcím kiválasztása)

Részletesebben

Diplomás pályakövetés intézményi online kutatás, 2012

Diplomás pályakövetés intézményi online kutatás, 2012 Diplomás pályakövetés intézményi online kutatás, 2012 Módszertani útmutató a Diplomás Pályakövető Rendszer 2012 es tavaszi online kérdőíveinek központi blokkjához Educatio Nonprofit Kft. Felsőoktatási

Részletesebben

WordPress segédlet. Bevezető. Letöltés. Telepítés

WordPress segédlet. Bevezető. Letöltés. Telepítés WordPress segédlet Bevezető A WordPress egy ingyenes tartalomkezelő rendszer (Content Management System - CMS), amely legnagyobb előnye az egyszerű telepítés és a letisztult kezelhetőség és a változatos

Részletesebben

Infor PM10 Üzleti intelligencia megoldás

Infor PM10 Üzleti intelligencia megoldás Infor PM10 Üzleti intelligencia megoldás Infor Üzleti intelligencia (Teljesítmény menedzsment) Web Scorecard & Műszerfal Excel Email riasztás Riportok Irányít Összehangol Ellenőriz Stratégia Stratégia

Részletesebben

GLPI V1.0. 2013 Felhasználói leírás. Informatikai Technológiai és Üzemeltetési Igazgatóság

GLPI V1.0. 2013 Felhasználói leírás. Informatikai Technológiai és Üzemeltetési Igazgatóság 2013 Felhasználói leírás V1.0 Informatikai Technológiai és Üzemeltetési Igazgatóság Tartalom ÁLTALÁNOS ISMERTETŐ... 2 HIBA BEJELENTÉS ÉS A MEGOLDÁS FOLYAMATA... 3 FELHASZNÁLÓI LÉPÉSEK... 6 Belépés... 6

Részletesebben

Haladó irodai számítógépes képzés tematika

Haladó irodai számítógépes képzés tematika Haladó irodai számítógépes képzés tematika Word haladó Haladó szövegszerkesztés Szöveg effektusok alkalmazása Az automatikus javítási beállítások használata Szöveg körbefuttatása, szövegtörés A szövegirány

Részletesebben

Pentaho 4: Mindennapi BI egyszerűen. Fekszi Csaba Ügyvezető 2011. október 6.

Pentaho 4: Mindennapi BI egyszerűen. Fekszi Csaba Ügyvezető 2011. október 6. Pentaho 4: Mindennapi BI egyszerűen Fekszi Csaba Ügyvezető 2011. október 6. 1 2 3 4 5 Bevezetés Pentaho-ról röviden - áttekintő Mindennapi BI egyszerűen a Pentaho 4 újdonságai Pentaho összefoglaló Alkalmazás

Részletesebben

Informatikai alapismeretek Földtudományi BSC számára

Informatikai alapismeretek Földtudományi BSC számára Informatikai alapismeretek Földtudományi BSC számára 2010-2011 Őszi félév Heizlerné Bakonyi Viktória HBV@ludens.elte.hu Titkosítás,hitelesítés Szimmetrikus DES 56 bites kulcs (kb. 1000 év) felcserél, helyettesít

Részletesebben

GoodBill számlázó és kintlévőség menedzselő rendszer

GoodBill számlázó és kintlévőség menedzselő rendszer GoodBill számlázó és kintlévőség menedzselő rendszer Könnyű kezelhetőség, átláthatóság jellemzi a GoodBill számlázó és kintlévőség menedzselő rendszert. Nem igényel különös képzettséget a számla elkészítéséhez.

Részletesebben

HASZNÁLATI ÚTMUTATÓ DOLGOZÓK IMPORTÁLÁSA KULCS BÉR PROGRAMBA AZ ONLINE MUNKAIDŐ NYILVÁNTARTÓ RENDSZERBŐL. Budapest, 2013. november 08.

HASZNÁLATI ÚTMUTATÓ DOLGOZÓK IMPORTÁLÁSA KULCS BÉR PROGRAMBA AZ ONLINE MUNKAIDŐ NYILVÁNTARTÓ RENDSZERBŐL. Budapest, 2013. november 08. HASZNÁLATI ÚTMUTATÓ DOLGOZÓK IMPORTÁLÁSA KULCS BÉR PROGRAMBA AZ ONLINE MUNKAIDŐ NYILVÁNTARTÓ RENDSZERBŐL Budapest, 2013. november 08. 1. CÉLKITŰZÉS A fő cél, hogy az OL Munkaidő Rendszerből kinyert jelenlét

Részletesebben

Szolgáltatói Adminisztrátori leírás

Szolgáltatói Adminisztrátori leírás Online Felügyeleti Központ Szolgáltatói Adminisztrátori leírás Egységes Megjelenítő Rendszer Online Felügyeleti Központ (Webes alkalmazói felület) Szolgáltatók részére 1. Használati útmutató és leírás

Részletesebben

Országos Rendezési Tervkataszter

Országos Rendezési Tervkataszter TeIR Országos Rendezési Tervkataszter Felhasználói útmutató Budapest, 2015. április Tartalomjegyzék 1. BEVEZETŐ... 3 2. LEKÉRDEZÉSEK... 3 2.1 TERV ELLÁTOTTSÁG LEKÉRDEZÉS... 4 2.1.1. Kördiagram... 5 2.1.2.

Részletesebben

ISA Internetes rendelési felület

ISA Internetes rendelési felület ISA Internetes rendelési felület Használati útmutató 2014.11.12 ISA elérhetősége) https://b2b.mol.hu/isa2/ 2 ISA főmenü Adatszolgáltatás - Információ a rendelésekről, visszaigazolásokról (táblázatos formátumban)

Részletesebben

A 2014/2015-ös ERASMUS+ KA103 (HE) záróbeszámolóval kapcsolatos technikai információk

A 2014/2015-ös ERASMUS+ KA103 (HE) záróbeszámolóval kapcsolatos technikai információk A 2014/2015-ös ERASMUS+ KA103 (HE) záróbeszámolóval kapcsolatos technikai információk Erasmus+ felsőoktatási mobilitási információs és konzultációs nap Budapest, 2015. szeptember 24. Tóth Tibor Előzmények,

Részletesebben

MÁV-START Tudáspróba Felhasználói kéziköny

MÁV-START Tudáspróba Felhasználói kéziköny MÁV-START Tudáspróba Felhasználói kéziköny Tartalomjegyzék Bejelentkezés a tudáspróbára... 3 Kijelentkezés... 3 Megkezdett tudáspróba folytatása... 4 Tudáspróba kiválasztása... 5 Tudáspróba kiválasztása...

Részletesebben

OSZMK portál részregisztráció és auditok általános felhasználói leírása

OSZMK portál részregisztráció és auditok általános felhasználói leírása Országos Szakfelügyeleti Módszertani Központ Informatikai Dokumentációs Rendszer Alkalmazás és alkalmazás-fejlesztés Dokumentáció OSZMK portál részregisztráció és auditok általános felhasználói leírása

Részletesebben

Tantárgyfelosztás. I. Ellenőrzés. Mielőtt hozzákezd a tantárgyfelosztás tervezéséhez, ellenőrizze le, illetve állítsa be a következőket:

Tantárgyfelosztás. I. Ellenőrzés. Mielőtt hozzákezd a tantárgyfelosztás tervezéséhez, ellenőrizze le, illetve állítsa be a következőket: Tantárgyfelosztás I. Ellenőrzés Mielőtt hozzákezd a tantárgyfelosztás tervezéséhez, ellenőrizze le, illetve állítsa be a következőket: Alkalmazott képes menü > alkalmazottak alapadatai - Alkalmazottak

Részletesebben

Ismerkedés az Office 2007 felhasználói felületével

Ismerkedés az Office 2007 felhasználói felületével Ismerkedés az Office 2007 felhasználói felületével A szalag kezelése Az új Fájl File menü A Gyorselérési eszköztár Az új nézetvezérlő elemek Összefoglalás Tudnivalók a Windows XP-t használó olvasók számára

Részletesebben

PartSoft Informatikai Kft. KÖNNY felhasználói kézikönyv 1 Általános információk... 2 1.1 Számítástechnikai alapok... 2 1.2 Felhasználói ismeretek...

PartSoft Informatikai Kft. KÖNNY felhasználói kézikönyv 1 Általános információk... 2 1.1 Számítástechnikai alapok... 2 1.2 Felhasználói ismeretek... 1 Általános információk... 2 1.1 Számítástechnikai alapok... 2 1.2 Felhasználói ismeretek... 2 2 Ügyfélcsoport... 2 3 Ügyfelek... 3 3.1 Váltás ügyfelek között... 4 4 Bevallások... 4 4.1 Létrehozás... 4

Részletesebben

Astra áttöltés Dimension-be

Astra áttöltés Dimension-be Astra áttöltés Dimension-be Az Astra-Dimension átállással kapcsolatosan a következő feladatokat kell végrehajtani. Kérem, olvassa át ezt a dokumentációt, hogy az áttöltés hiba nélkül történjen meg. Az

Részletesebben

Tartalomjegyzék 2. RENDSZER FELÉPÍTÉSE... 3

Tartalomjegyzék 2. RENDSZER FELÉPÍTÉSE... 3 Tartalomjegyzék 1. BEVEZETŐ... 2 2. RENDSZER FELÉPÍTÉSE... 3 2.1. FELÜLET... 3 2.2. FELHASZNÁLÓI FUNKCIÓK... 4 2.2.1. Modulok... 4 2.2.2. Előzmények... 4 2.2.3. Lekérdezés működése, beállítások... 5 2.2.4.

Részletesebben

Adatbázis rendszerek. dr. Siki Zoltán

Adatbázis rendszerek. dr. Siki Zoltán Adatbázis rendszerek I. dr. Siki Zoltán Adatbázis fogalma adatok valamely célszerűen rendezett, szisztéma szerinti tárolása Az informatika elterjedése előtt is számos adatbázis létezett pl. Vállalati személyzeti

Részletesebben

Általános használati tudnivalók és szabályok

Általános használati tudnivalók és szabályok MÜTF Polihisztor Általános használati tudnivalók és szabályok A MÜTF Polihisztor azzal a céllal jött létre, hogy elsősorban a MÜTF hallgatóinak tanulmányait és közösségépítését segítse jegyzetfeltöltési

Részletesebben

QBE Édes Otthon lakásbiztosítás tarifáló webservice. Fejlesztői dokumentáció 1.0.2

QBE Édes Otthon lakásbiztosítás tarifáló webservice. Fejlesztői dokumentáció 1.0.2 QBE Édes Otthon lakásbiztosítás tarifáló webservice Fejlesztői dokumentáció 1.0.2 Az ebben a dokumentumban található információ a FoxArt Kft. tulajdona, és bizalmas anyagként került átadásra. Az anyag

Részletesebben

VÍZIKÖZMŰ-ONLINE ÉS VÍZHASZNÁLAT-ONLINE ADATFELDOLGOZÓ RENDSZEREK

VÍZIKÖZMŰ-ONLINE ÉS VÍZHASZNÁLAT-ONLINE ADATFELDOLGOZÓ RENDSZEREK VÍZIKÖZMŰ-ONLINE ÉS VÍZHASZNÁLAT-ONLINE ADATFELDOLGOZÓ RENDSZEREK A RENDSZEREK ALAPSZOLGÁLTATÁSAINAK RÖVID ISMERTETÉSE ORSZÁGOS VÍZÜGYI FŐIGAZGATÓSÁG 2015. ELŐZMÉNYEK 2011-ben elkészült és üzembe állt

Részletesebben

Felhasználói segédlet a Scopus adatbázis használatához

Felhasználói segédlet a Scopus adatbázis használatához Felhasználói segédlet a Scopus adatbázis használatához Az adatbázis elérése, regisztrálás, belépés Az adatbázis címe: http://www.scopus.com Az adatbázis csak regisztrált, jogosultsággal rendelkező intézmények,

Részletesebben

DAT adatcserefájl AutoCAD MAP DWG mapobject konvertáló program dokumentáció

DAT adatcserefájl AutoCAD MAP DWG mapobject konvertáló program dokumentáció H - 1161 Budapest Rákóczi út 76. Tel./Fax.: +36-1-4010159 http://www.pageos.hu toni@pageos.hu DAT adatcserefájl AutoCAD MAP DWG mapobject konvertáló program dokumentáció A program használható a TOPOBASE

Részletesebben

BarAck.Net. Internetes csomagkezel. Felhasználói kézikönyv V 1.0. (2011. július 20.)

BarAck.Net. Internetes csomagkezel. Felhasználói kézikönyv V 1.0. (2011. július 20.) BarAck.Net Internetes csomagkezel Felhasználói kézikönyv V 1.0 (2011. július 20.) Tartalomjegyzék 1 Áttekintés...2 1.1 Célkitzés...2 1.2 A program felépítése...2 2 Futtatási környezet, telepítési információk...3

Részletesebben

Bár a szoftverleltárt elsősorban magamnak készítettem, de ha már itt van, miért is ne használhatná más is.

Bár a szoftverleltárt elsősorban magamnak készítettem, de ha már itt van, miért is ne használhatná más is. SZOFTVERLELTÁR FREE Amennyiben önnek vállalkozása van, akkor pontosan tudnia kell, hogy milyen programok és alkalmazások vannak telepítve cége, vállalkozása számítógépeire, és ezekhez milyen engedélyeik,

Részletesebben

Karbantartás. Az ESZR Karbantartás menüjébentudjuk elvégezni az alábbiakat:

Karbantartás. Az ESZR Karbantartás menüjébentudjuk elvégezni az alábbiakat: Karbantartás Az ESZR Karbantartás menüjébentudjuk elvégezni az alábbiakat: Jelszó módosítása: A felhasználói jelszavunkat módosíthatjuk ebben a menüpontban, a régi jelszavunk megadása után. Általánosan

Részletesebben

Tájékoztató a határon túli támogatások központi nyilvántartó rendszeréről

Tájékoztató a határon túli támogatások központi nyilvántartó rendszeréről HATÁRON TÚLI MAGYAROK HIVATALA 1518 BUDAPEST 112, PF. 43 I. BÉRC U. 13-15. ( 372-9502 372-9561 - htmh@htmh.gov.hu Tájékoztató a határon túli támogatások központi nyilvántartó rendszeréről A szomszédos

Részletesebben

Dokumentum létrehozása/módosítása a portálon:

Dokumentum létrehozása/módosítása a portálon: Dokumentum létrehozása/módosítása a portálon: 1. Belépés a szerkesztőfelületre A következő webcímre belépve - http://www.zalaegerszeg.hu/licoms/login - megjelenik a szerkesztőfelület beléptető ablaka,

Részletesebben

Fejlesztések és változások a Precíz Integrált Ügyviteli Információs rendszerben. 2005. január

Fejlesztések és változások a Precíz Integrált Ügyviteli Információs rendszerben. 2005. január 2005. január Fejlesztések és változások a Precíz Integrált Ügyviteli Információs rendszerben. Ügyviteli nyilvántartások és EXCEL formátumú adatszolgáltatás A korszerű ügyviteli rendszereknek, a jogszabályi

Részletesebben

Közoktatási Statisztika Tájékoztató 2012/2013. Használati útmutató

Közoktatási Statisztika Tájékoztató 2012/2013. Használati útmutató Közoktatási Statisztika Tájékoztató 2012/2013 Tartalomjegyzék 1. Technikai információk... 2 2. Publikus felület... 2 2.1 Bejelentkezés... 2 2.2 Összesítés... 3 2.2.1 Statisztikai tábla megtekintése...

Részletesebben

Automatikus feladatok modul

Automatikus feladatok modul Automatikus feladatok modul 1. Bevezetés... 2 2. Kijelölt feladat módosítása... 2 2.1. Adott feladathoz tartozó felhasználó(k) kiválasztása... 3 o Feladatkör esetén... 3 o Munkatárs esetén... 4 3. Feladat

Részletesebben

Van-e ingyen-ebéd? Avagy mire elég a nyílt forráskodú Pentaho? Fekszi Csaba Ügyvezető 2012. október 4.

Van-e ingyen-ebéd? Avagy mire elég a nyílt forráskodú Pentaho? Fekszi Csaba Ügyvezető 2012. október 4. Van-e ingyen-ebéd? Avagy mire elég a nyílt forráskodú Pentaho? Fekszi Csaba Ügyvezető 2012. október 4. Omnit Solutions 2007 óta a piacon BI & adattárház tanácsadás 20 fős csapat Oracle, IBM és Pentaho

Részletesebben

OOP. Alapelvek Elek Tibor

OOP. Alapelvek Elek Tibor OOP Alapelvek Elek Tibor OOP szemlélet Az OOP szemlélete szerint: a valóságot objektumok halmazaként tekintjük. Ezen objektumok egymással kapcsolatban vannak és együttműködnek. Program készítés: Absztrakciós

Részletesebben

Fizikai terv. A fizikai tervezés részei: Adatterv Adatvédelmi terv A rendszer működésének terve Funkciók terve (programspecifikációk) I/O tervek

Fizikai terv. A fizikai tervezés részei: Adatterv Adatvédelmi terv A rendszer működésének terve Funkciók terve (programspecifikációk) I/O tervek Fizikai terv A fizikai tervezés részei: Adatterv Adatvédelmi terv A rendszer működésének terve Funkciók terve (programspecifikációk) I/O tervek Készítsük el a Hallgatói adatok kezelésének Dialógus tervét!

Részletesebben

Technikai információk fejlesztőknek

Technikai információk fejlesztőknek Technikai információk fejlesztőknek Különbségek a Java-s nyomtatványkitöltő program és az Abev2006 között 1. A mezőkód kijelzés bekapcsolása a Szerviz/Beállítások ablakban érhető el. 2. Az xml állományok

Részletesebben

5. fejezet JELMAGYARÁZAT. Kapcsolódó tartalom a kézikönyv további fejezetében. Kapcsolódó honlaptartalom a www.avir.hu oldalon

5. fejezet JELMAGYARÁZAT. Kapcsolódó tartalom a kézikönyv további fejezetében. Kapcsolódó honlaptartalom a www.avir.hu oldalon aca ca ca c aca ca ca c aca ca ca c 134 ADATTÁR ALAPÚ VEZETŐI INFORMÁCIÓS RENDSZER 5. fejezet JELMAGYARÁZAT a b c A fogalom definíciója megtalálható a Fogalomgyűjteményben Kapcsolódó tartalom a kézikönyv

Részletesebben

Amit mindig is tudni akartál a Real Application Testing-ről. Földi Tamás Starschema Kft.

Amit mindig is tudni akartál a Real Application Testing-ről. Földi Tamás Starschema Kft. Amit mindig is tudni akartál a Real Application Testing-ről Földi Tamás Starschema Kft. Környezet Adattárház Oracle 9i, HPUX 13ezer tábla ~1400 betöltő folyamat ~8000 töltési lépés (mapping) Riportok BusinessObjects

Részletesebben

BOC Information Technologies Consulting GmbH. Minőségmenedzsment

BOC Information Technologies Consulting GmbH. Minőségmenedzsment Minőségmenedzsment Bäckerstraße 5/3, A- 1010 Wien Tel: +43-513 27 36-0 Fax: +43-513 27 36-5 http://www.boc-hu.com E-Mail: boc@boc-hu.com AZ ADONIS ÉS A MINŐSÉGMENEDZSMENT / ISO 9000:2000 A sikeres és dinamikus

Részletesebben

Szülői modul. Belépés a TANINFORM rendszerbe. Főoldal

Szülői modul. Belépés a TANINFORM rendszerbe. Főoldal Szülői modul Belépés a TANINFORM rendszerbe Belépni vagy a bogim.hu oldalon elhelyezett linkre való kattintással vagy a https://start.taninform.hu/application/start?intezmenyindex=032552 cím böngészőbe

Részletesebben

AZ INTEGRÁLT NYOMONKÖVETŐ RENDSZER BEMUTATÁSA (TÁMOP 3.4.2-B) Kern Zoltán Közoktatási szakértő Kern.zoltan@educatio.hu

AZ INTEGRÁLT NYOMONKÖVETŐ RENDSZER BEMUTATÁSA (TÁMOP 3.4.2-B) Kern Zoltán Közoktatási szakértő Kern.zoltan@educatio.hu AZ INTEGRÁLT NYOMONKÖVETŐ RENDSZER BEMUTATÁSA (TÁMOP 3.4.2-B) Kern Zoltán Közoktatási szakértő Kern.zoltan@educatio.hu Integrált (Elektronikus) Nyomonkövető Rendszer Miért használjuk? Hogyan használjuk?

Részletesebben

icrm ügyfélkapcsolatkezelő

icrm ügyfélkapcsolatkezelő Az megoldás egy általános értelemben vett partnerkapcsolati megoldás kiegészítve a partnerekkel folytatott különböző szintű kommunikációk nyilvántartására szolgáló funkciókkal. 1 megoldás Segíti a napi

Részletesebben

Oktatás saját intézményben

Oktatás saját intézményben Oktatás saját intézményben A Humán-erőforrás Nyilvántartó Rendszerben rögzítendő adatok egyik nagy csoportját az egy-egy tanév megadott félévére vonatkozó oktatási tevékenységhez kapcsolódó adatok képezik,

Részletesebben

FIR WEBMODUL ALKALMAZÁS DIÁKIGAZOLVÁNY IGÉNYLÉS

FIR WEBMODUL ALKALMAZÁS DIÁKIGAZOLVÁNY IGÉNYLÉS Educatio Társadalmi Szolgáltató Nonprofit kft. FIR WEBMODUL ALKALMAZÁS DIÁKIGAZOLVÁNY IGÉNYLÉS Felhasználói kézikönyv Dokumentum állapota: Tervezet Verzió: 0.1.0 Tartalomjegyzék 1. Bevezetés... 3 2. Bejelentkezés...

Részletesebben

Szociális ellátások nyilvántartási rendszere CSTINFO Lekérdezői modul

Szociális ellátások nyilvántartási rendszere CSTINFO Lekérdezői modul Szociális ellátások nyilvántartási rendszere CSTINFO Lekérdezői modul Békéscsaba, 2013.május 1 A települési önkormányzatok jegyzői, a közös önkormányzati hivatalok jegyzői, a kormányhivatalok járási hivatalai,

Részletesebben

Aromo Szöveges Értékelés

Aromo Szöveges Értékelés Aromo Szöveges Értékelés AROMO Iskolaadminisztrációs Szoftver v2.50 - Felhasználói kézikönyv- Szöveges értékelés 1 Tartalomjegyzék Aromo Szöveges Értékelés 1 Bevezetés 3 A Szöveges Értékelés modul koncepciója

Részletesebben

Területi elemzések. Budapest, 2015. április

Területi elemzések. Budapest, 2015. április TeIR Területi elemzések Felhasználói útmutató Budapest, 2015. április Tartalomjegyzék 1. BEVEZETŐ... 3 2. AZ ELEMZÉSBEN SZEREPLŐ MUTATÓ KIVÁLASZTÁSA... 4 3. AZ ELEMZÉSI FELTÉTELEK DEFINIÁLÁSA... 5 3.1.

Részletesebben

NYÍREGYHÁZI FŐISKOLA NYÍREGYHÁZA ADATTÁR ALAPÚ VEZETŐI INFORMÁCIÓS RENDSZER (VIR) MŰKÖDÉSÉNEK SZABÁLYZATA

NYÍREGYHÁZI FŐISKOLA NYÍREGYHÁZA ADATTÁR ALAPÚ VEZETŐI INFORMÁCIÓS RENDSZER (VIR) MŰKÖDÉSÉNEK SZABÁLYZATA NYÍREGYHÁZI FŐISKOLA NYÍREGYHÁZA ADATTÁR ALAPÚ VEZETŐI INFORMÁCIÓS RENDSZER (VIR) MŰKÖDÉSÉNEK SZABÁLYZATA Elfogadva: 2012. április 24., hatályba lép: 2012. április 26-án Módosítva: 2015. március 31., hatályba

Részletesebben

Személyügyi nyilvántartás szoftver

Személyügyi nyilvántartás szoftver Személyügyi nyilvántartás szoftver A nexonhr személyügyi nyilvántartás szoftver a személyügyi, továbbképzési és munkaköri adatok kezelését teszi lehetővé. A szoftver támogatja a HR adminisztrációs feladatokat,

Részletesebben

Közfoglalkoztatás támogatás megállapítását segítő segédtábla használati útmutatója

Közfoglalkoztatás támogatás megállapítását segítő segédtábla használati útmutatója Közfoglalkoztatás támogatás megállapítását segítő segédtábla használati útmutatója 1.) Általános tudnivalók: A segédtábla két méretben készül, 10, és 50 sort lehet kitölteni. A tábla megnevezéséből amit

Részletesebben

META. a földügyi folyamatok tükrében. Zalaba Piroska főtanácsos Földművelésügyi és Vidékfejlesztési Minisztérium Földügyi és Térinformatikai Főosztály

META. a földügyi folyamatok tükrében. Zalaba Piroska főtanácsos Földművelésügyi és Vidékfejlesztési Minisztérium Földügyi és Térinformatikai Főosztály META a földügyi folyamatok tükrében Zalaba Piroska főtanácsos Földművelésügyi és Vidékfejlesztési Minisztérium Földügyi és Térinformatikai Főosztály A földüggyel szembeni alapvető elvárások Államhatalmi

Részletesebben

Ügyfél- és címadatok feldolgozása Talenddel

Ügyfél- és címadatok feldolgozása Talenddel Ügyfél- és címadatok feldolgozása Talenddel 2012.október 4. Dr. Miskolczi Mátyás, Kiss György A Stratisról röviden Jellemzők - Alapítva: 1998 - Tisztán magyar tulajdon - 50 tanácsadó - 140 ügyfél - 500+

Részletesebben

smepro.eu tananyagbázis és kurzusrendszer portálok felépítése

smepro.eu tananyagbázis és kurzusrendszer portálok felépítése smepro.eu tananyagbázis és kurzusrendszer portálok felépítése Az SMELearning módszertan egyik legfontosabb ajánlása, egybehangzóan az előzetes szükségletelemzés következtetéseivel a következő: a kis-és

Részletesebben

Tartalom Tartalom...1 Bevezetés...2 Általános áttekintés...3 Az IFSZ Házipénztár modul alapkoncepciója... 3 Jogosultságkezelés... 4 Bizonylatszámozás... 4...5 Törzsadatok és beállítások... 5 Pénztári jogosultságok

Részletesebben

Nemzeti Társadalmi Felzárkóztatási Stratégia indikátor rendszer

Nemzeti Társadalmi Felzárkóztatási Stratégia indikátor rendszer Szociális ÁIR (Szociális Ágazati Információs Rendszer) Nemzeti Társadalmi Felzárkóztatási Stratégia indikátor rendszer Felhasználói útmutató Budapest, 2012. december 1 Tartalomjegyzék 1. Előzmények, célok...

Részletesebben

Vonalkód olvasó rendszer. Specifikáció Vonalkód olvasó rendszer SoftMaster Kft. [1]

Vonalkód olvasó rendszer. Specifikáció Vonalkód olvasó rendszer SoftMaster Kft. [1] Specifikáció Vonalkód olvasó rendszer SoftMaster Kft. [1] T a r t a l o m j e g y z é k 1 Bevezetés... 3 1.1 A rendszer rövid leírása... 3 1.2 A dokumentum célja... 3 1.3 A rendszer komponensei... 3 1.4

Részletesebben

Orvosi készülékekben használható modern fejlesztési technológiák lehetőségeinek vizsgálata

Orvosi készülékekben használható modern fejlesztési technológiák lehetőségeinek vizsgálata Kutatási beszámoló a Pro Progressio Alapítvány számára Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Mérnök informatika szak Orvosi készülékekben használható modern

Részletesebben

NightHawk AccessControl

NightHawk AccessControl NightHawk AccessControl Poker Edition Version: 2.0 2012. január 1 Tartalomjegyzék Rendszer elemei... 3 Felhasználói felület... 3 Nap nyitása, zárása... 4 Új játékos felvitele... 4 Ki és beléptetés... 5

Részletesebben

Kézikönyv Sarzs (LOT) kezelés - alapok

Kézikönyv Sarzs (LOT) kezelés - alapok Kézikönyv Sarzs (LOT) kezelés - alapok 1 4 Tartalomjegyzék 2 ÁRUCIKK - ÜRES... 10 3 ÁRUCIKK - MEGJELENÍTÉS [10035 BE_S_ANYAG SARZSOS ALAPANYAG]... 12 4 ÁRUCIKK - VÁLTOZTATÁS [10035 BE_S_ANYAG SARZSOS ALAPANYAG]13

Részletesebben

Képernyőképes segédlet a Prompt e-learning portál használatához

Képernyőképes segédlet a Prompt e-learning portál használatához Képernyőképes segédlet a Prompt e-learning portál használatához Regisztráció 1. lépés Az edu.prompt.hu címen elérhető e-learning portál használatához minden résztvevőnek szükséges elkészítenie a saját

Részletesebben

Programozás. Adatbázis-kezelés (alapok) Fodor Attila

Programozás. Adatbázis-kezelés (alapok) Fodor Attila Programozás Adatbázis-kezelés (alapok) Fodor Attila Pannon Egyetem Műszaki Informatikai Kar Villamosmérnöki és Információs Rendszerek Tanszék foa@almos.vein.hu 2010. április 22. Bevezetés Adatbáziskezelés

Részletesebben

LÉTESÍTMÉNYGAZDÁLKODÁS. Változáskezelés. Változás Pont Cím Oldal 2.0 2014.03.19 A teljes dokumentáció átírásra került 2.1 2014.07.14 8.

LÉTESÍTMÉNYGAZDÁLKODÁS. Változáskezelés. Változás Pont Cím Oldal 2.0 2014.03.19 A teljes dokumentáció átírásra került 2.1 2014.07.14 8. ESZKÖZIGÉNY Felhasználói dokumentáció verzió 2.2. Budapest, 2015. Változáskezelés Verzió Dátum Változás Pont Cím Oldal 2.0 2014.03.19 A teljes dokumentáció átírásra került 2.1 2014.07.14 8.3 Új, oszlopszerkesztésbe

Részletesebben

SZOLGÁLTATÓI NYILVÁNTARTÁSI RENDSZER FELHASZNÁLÓI KÉZIKÖNYV

SZOLGÁLTATÓI NYILVÁNTARTÁSI RENDSZER FELHASZNÁLÓI KÉZIKÖNYV SZOLGÁLTATÓI NYILVÁNTARTÁSI RENDSZER FELHASZNÁLÓI KÉZIKÖNYV Felhasználói kézikönyv IX. kötet BEJEGYZÉSEK LEKÉRDEZÉSE Magyar Államkincstár Betekintési jogosultsággal rendelkező felhasználók számára 2014.12.10.

Részletesebben

A jelen fejlesztéssel párhuzamosan bővült az Adatbázis kapcsolat ablak információtartalma.

A jelen fejlesztéssel párhuzamosan bővült az Adatbázis kapcsolat ablak információtartalma. TÁJÉKOZTATÓ A CCN V2015.6 VERZIÓHOZ Változások a V2015.5 verzió kiadása után Általános információk, alapadatok 1. SQL adatbázis adatainak kijelzése SQL server Express edition esetén, ha az adatbázis által

Részletesebben

IV/1. sz. melléklet: Vállalati CRM, értékesítési terület funkcionális specifikáció

IV/1. sz. melléklet: Vállalati CRM, értékesítési terület funkcionális specifikáció IV/1. sz. melléklet: Vállalati CRM, értékesítési terület funkcionális specifikáció 1. A követelménylista céljáról Jelen követelménylista (mint a GOP 2.2.1 / KMOP 1.2.5 pályázati útmutató melléklete) meghatározza

Részletesebben

FOLYAMATAUDIT JELENTÉS ELEKTRONIKUS VÁLTOZATA

FOLYAMATAUDIT JELENTÉS ELEKTRONIKUS VÁLTOZATA FOLYAMATAUDIT JELENTÉS ELEKTRONIKUS VÁLTOZATA 1.0 VERZIÓ A program alkalmazási környezete A program felépítése, tulajdonságai A program további tulajdonságai A program ára A program szállítása, telepítése

Részletesebben

KIRA. Közlekedési Információs Rendszer és Adatbázis. Dr. Havas Gergely Forrainé Hernádi Veronika

KIRA. Közlekedési Információs Rendszer és Adatbázis. Dr. Havas Gergely Forrainé Hernádi Veronika KIRA Közlekedési Információs Rendszer és Adatbázis Dr. Havas Gergely Forrainé Hernádi Veronika 2 Intézményrendszer 3 GIS adatkapcsolatok Hogyan működik ez a rendszer? Általában kétoldali megállapodások

Részletesebben

Vihar 2.0 rendszer Felhasználói kézikönyv

Vihar 2.0 rendszer Felhasználói kézikönyv Vihar 2.0 rendszer Felhasználói kézikönyv Versenyzői funkciók O l d a l 0 21 Tartalomjegyzék Tartalom Tartalomjegyzék... 0 Bevezető... 1 Felhasználói funkciók... 2 Regisztráció... 2 Támogatott böngészők...

Részletesebben