Informatika | Adatbázisok » Fábián Tamás - Adatbázis-migráció módszertanának bemutatása a Doksi.hu példáján keresztül

ÓBUDAI EGYETEM Keleti Károly Gazdasági Kar Vállalkozásmenedzsment Intézet Adatbázis-migráció módszertanának bemutatása a Doksi.hu példáján keresztül SZAKDOLGOZAT OE-KGK 2013. Hallgató neve: Hallgató törzskönyvi száma: Fábián Tamás Károly T002830/FI38878/G ÓBUDAI EGYETEM Keleti Károly Gazdasági Kar Vállalkozásmenedzsment Intézet SZAKDOLGOZAT FELADATLAP Hallgató neve: Fábián Tamás Károly Törzskönyvi száma: T002830/FI38878/G Tagozat: Nappali Neptun kódja: KAQ93O Szak: Gazdálkodási és Menedzsment Szakirány: Üzleti Informatika A dolgozat címe: A dolgozat címe angolul: Feladat: 1. Bevezetés, motiváció, témaválasztás indoklása 2. A migrációról általánosságban 3. Hatékony migrációs stratégia, alkalmazások 4. Doksihu migráció technikai kivitelezése, új logika implementálása 5. Adattisztítás, tesztelés Intézményi konzulens neve: Mohos Pál Külső konzulens neve, beosztása: Fábián Zoltán, vezető

tanácsadó Munkahelye: Clarity Consulting Kft. A kiadott téma elévülési határideje: Beadási határidő: 2013. január 9 A záróvizsga tárgyai: komplex gazdasági ismeretek, üzleti informatika A szakdolgozat nem titkos Kiadva: Budapest, 20 A dolgozatot beadásra alkalmasnak találom: PH . Intézetigazgató . Intézményi konzulens ÓBUDAI EGYETEM Keleti Károly Gazdasági Kar HALLGATÓI NYILATKOZAT Alulírott hallgató kijelentem, hogy a szakdolgozat saját munkám eredménye, a felhasznált szakirodalmat és eszközöket azonosíthatóan közöltem. Az elkészült szakdolgozatban található eredményeket az egyetem és a feladatot kiíró intézmény saját céljára térítés nélkül felhasználhatja, a titkosításra vonatkozó esetleges megkötések mellett. Budapest, 20. . hallgató aláírása Jelen szakdolgozatra a „Nevezd meg! - Ne add el! 2.5 Magyarország (CC BY-NC 25 HU)” szerzői jogi oltalom vonatkozik. ÓBUDAI EGYETEM Keleti Károly

Gazdasági Kar Vállalkozásmenedzsment Intézet Adatbázis-migráció módszertanának bemutatása a Doksi.hu példáján keresztül SZAKDOLGOZAT OE-KGK 2013. Hallgató neve: Hallgató törzskönyvi száma: Fábián Tamás Károly T002830/FI38878/G 1 0 Tartalom 1 Tartalmai összefoglaló . 3 1.1 2 3 Motiváció, témaválasztás indoklása . 4 A migrációról általánosságban . 6 2.1 A „nagy adat” világa. 7 2.2 Üzleti hajtóerő . 9 2.21 Operatív szempontból . 9 2.22 Stratégiai szempontból . 10 2.23 Banki rendszerek migrálásának sajátosságai menedzsment oldalról . 10 2.3 A migráció folyamata . 14 2.4 Az adatok típusai DB szempontból . 15 Hatékony migrációs stratégia . 19 3.1 Kockázatok . 19 3.2 Technológiai megfontolások . 20 3.3 A migráció megközelítése, a kivitelezés alternatívái . 21 3.31 4 5 A kivitelezés alternatívái . 22 3.4 Oracle TimesTen . 23 3.5 Alkalmazások, logikák . 24 3.51 Allround

Automations . 25 3.52 Oracle . 27 DB Biztonság . 31 4.1 Jogosultságok. 31 4.2 Adatbázis audit . 32 Doksi.hu migráció 33 5.1 A doksiról . 33 5.2 Doksi.hu adatbázisa 34 2 5.21 MantisBT Bug Tracking. 34 5.22 phpMyAdmin . 35 5.23 Doksi.hu adatbázis szerkezete 35 5.24 Fontos tudni, kimutatások . 37 5.3 Migráció technikai kivitelezése, új logika implementálása . 44 5.31 A migráció fázisai . 44 5.32 Alkategória hatékonyság céljainak meghatározása magas szinten . 49 5.33 Dok doksik tábla létrehozása. 49 5.34 Doksik kategória táblájának létrehozása . 51 5.35 Dok doksik feltöltése teszt adatokkal . 51 5.36 Alkategória hatékonyság . 54 5.37 Alkategória hatékonyság további fejlesztési lehetőségei . 56 5.38 Éles adatokkal való feltöltés módszerei, nehézségei . 57 5.39 External Tables . 58 5.310 Adatbázis migráció módszertani áttekintése . 62 5.4 Adattisztítás . 65 5.41 Adatminőségi

problémák keletkezéseinek okai, jellegzetességei banki rendszereknél . 65 5.42 Adatminőségi problémák jellege a doksi.hu-nál 69 5.43 Migrációs és adattisztítási projektek Magyarországon . 70 5.5 Banki rendszerek vs. doksihu adatbázisa 72 5.51 6 7 Jobok . 73 Tesztelés . 74 6.1 Típusok . 74 6.2 Teszt automatizálás. 75 Irodalomjegyzék . 77 3 1 Tartalmai összefoglaló Szakdolgozatomban az adatbázis migrációs projektekhez kapcsolódó feladatokról és sajátosságokról írtam üzleti oldalról, illetve egy internetes portál, a Doksi.hu adatbázismigrációs módszertanát mutattam be félig IT, félig üzleti oldalról Az alapkoncepció az volt, hogy egy MySQL szerverről egy Oracle szerverre költöztetem az adatok egy meghatározott körét, illetve bemutatom az ehhez kapcsolódó módszertani követelményeket. A dolgozat egy általam kidolgozott új funkció adatbázis oldali implementációs nehézségeit is bemutatja az ötlet

megszületésétől a kivitelezésig, amely már az Oracle 11gR2 adatbázisára épül. Az adatbázis költöztetéssel kapcsolatos általános problémákat banki rendszerek példáján keresztül ismertetem, mivel a bankok bonyolult IT architektúrával rendelkeznek, üzleti folyamataik pedig rendkívül komplexek. A kritikus infrastruktúrában való működés ráadásul számos migrációs sajátosságot hordoz. A fenti szempontokat alapul véve rendkívül sok párhuzamot tudtam vonni a banki rendszerek (pl.: adattárház) migrálásának folyamatai és a doksi.hu adatbázis költöztetéshez kapcsolódó folyamatai között This thesis is about database migration methodology set by the business side. It also demonstrates a migration case study related to a hungarian website called Doksi.hu by the IT side and also by a business approach. The concept was to migrate Doksi’s database from a MySQL server to an Oracle 11gR2 server, and introduction of migration demands and

requirements drawing parallel. The study introduce how a new function (and business logic) can be implemented in Oracle database from the beginning. Common difficulties are shown related to banking technologies. The reason is money institutes have difficult business processes provided by complex IT architectures. Critical infrastructure also refers to a huge amount of migration speciality. In addition, a lot of parallel is drawn among banking systems (like data warehouse) and Doksi.hu’s database migration methodology 4 1.1 Motiváció, témaválasztás indoklása Diplomamunkám témájának megválasztásakor az elsődleges szempont az volt, hogy olyan területről írjak, amely komplexitása révén kellő kihívást és izgalmat nyújt, valamint lehetőség nyílik a szakmai kreativitás kibontakozására. A mérlegképes könyvelői végzettség megszerzését követően úgy gondoltam, hogy olyan területen dolgoznék szívesen, ahol lehetőségem nyílik munkám során a

pénzügyi (esetleg számviteli) és informatikai vénám erősítésére. Az adatbázis migráció és fejlesztés tipikusan olyan téma, ahol széleskörű ismeretekre van szükség mind IT, mind üzleti területen. Fontos szempont még, hogy ehhez a témához kapcsolódó anyagok nem érhetőek el – csak korlátozott mértékben, korlátozott minőségben – magyarul, ezzel is ösztönöztem magam az informatikai és üzleti szaknyelv elsajátítására. Másrészt a munkaerőpiacon olyan tendencia látszik kialakulni, amiből középtávon is az informatikai beállítottságú szakemberek szaktudásának felértékelődésére lehet következtetni. Ha recesszió idején is tovább tud nőni a szakemberhiány stagnáló kibocsátás mellett, akkor konjunktúra idején a szakadék tovább nőhet. (sghu, 2012) Továbbá azon szerencsés emberek egyike lehettem, akiknek lehetőségük nyílt a KBC csoporthoz tartozó K&H Bank egy front-end fejlesztési projektének (Apollo

program) munkálataiban részt venni. A munkám során (doksi.hu – szerkesztő) sűrűn kerültek hozzám programozással kapcsolatos anyagok. Sosem tudtam hova tenni ezeket a programozási nyelveket és logikákat, teljesen ismeretlen világ volt ez számomra. A szakdolgozatom választásával kapcsolatosan jött az elhatározás, hogy törekedni fogok egy nyelv elsajátítására. Ez a nyelv az adatbázis fejlesztésre használt PL/SQL nyelv. Motivációm másik eleme, hogy testvérem egy IT megoldásokat szállító cég kötelékében egy pénzügyi szervezet bankközi hitelnyilvántartó szoftverrendszeréhez kapcsolódó adattárház migrációs munka projektvezetőjeként dolgozott. Ezen kívül a mai napig foglalkozik Oracle adatbázisok migrációjának automatizált ellenőrzésével, banki tervezésével és fejlesztésével illetve teszteléssel. (Clarityhu, 2012) szoftver-rendszerek 5 Kulcsszavak: adatbázis migráció, üzleti oldal, Oracle 11gR2, MYSQL,

migrációs módszertan, banki rendszerek migrálása, external table, manuális adattisztítás, automatizált adattisztítás, folyamat automatizálás, migráció tesztelése, Oracle TimesTen, migrációs projektek, Oracle PL/SQL Developer, memória alapú adatbázis, ITbusiness, orafaq, cross platform transportable tablespaces, Mantisbt bug tracking, Phpmyadmin, Direct Oracle Access, duplikátum, sql script, Oracle datapump, Oracle Recovery Manager, Erste bank, Vodefone, Sysman, Erste Symbols számlavezető rendszer, NOSQL, Oracle exadata, exalogic, Clarity Consulting, flash cash technológia, exalogic, adattárház, IT architektúra, Boston Consulting Group Keywords: Database migration methodology, Oracle 11gR2, MYSQL, migration of banking system, banking technology, external table, manual data cleansing, automated data cleaning, ITbusiness, orafaq, Mantisbt bug tracking system, phpmyadmin, database schema, Oracle developer, Direct Oracle Access, data duplicate, sql script, Oracle

datapump, Oracle Recovery Manager, procedural approache, Erste bank, Vodafone, Sysman, incremental migration, NOSQL, flash cash technology, migration factory, data warehouse, business logic, IT architecture, Boston Consulting Group 6 2 A migrációról általánosságban Az adatbázis (későbbiekben DB) migráció adatok átköltöztetését jelenti egy eszközről vagy rendszerből egy másik eszközre, vagy rendszerbe anélkül, hogy korlátoznánk, vagy negatív irányba módosítanánk az adatokra épülő üzleti folyamatokat (BP, Business Process). A sikeres implementáció, végső tesztelési fázisok, majd azt követő utómunkálatok elvégzése után az új eszköz, vagy rendszer már a migrált adatokból, esetleg ezekből transzformált adatokból tudja támogatni az üzleti folyamatokat. (Levine, 2009) Egy felmérés szerint az ICT vezetők 93 százaléka tartott az alkalmazásszintű migrációs projektek kimenetelétől. A Bloor Research szerint a migrációs

projektek több mint 80 százaléka nem készül el időben, vagy nem a tervezett költségvetés mellett. (Hollingsworth, 2008) Az USA-ban több millió dollárt, Magyarországon pedig több száz millió forintot költenek az üzletvitel fejlesztésére minden évben. Az ezekhez kapcsolódó számlavezető rendszerek, adatbázisok, adattárházak üzleti fejlesztésének nagy hányadát teszik ki a migrációs projektek, melyek 75 százaléka nem felel meg a hozzájuk fűzött elvárásoknak. Leggyakrabban azért, mert a migrációs munka folyamataiban (és az üzleti folyamatokban egyaránt) megbúvó hiányosságok nem várt hibákat, anomáliákat eredményeznek a cél rendszer működésében (és így az üzleti folyamatokban). (Oracle White Paper, 2011) A tökéletesen kivitelezett migrációhoz ismerni kell a forrásadatok minden jellemzőjét, illetve azokat a folyamatokat, amelyek következtében előálltak. Ha egy hibás adatot a szoftver, vagy alkalmazás korábbi hibás

verziója állított elő és az nem javult (például beépített automatizmusok, eljárások, megszorítások által), akkor a költöztetést megelőzően adattisztításra van szükség. (Fábián, 2012) Egy tipikus migrációs projekt futási ideje 6 hónap és 2 év között van. Az ideális ütemtervet a külső függőségek figyelembe vétele mellett kell kialakítani, legyen szó a szoftver licencek beszerzéséről (ami egy alkalmazás esetén akár 3 hét is lehet), fejlesztők keresésétől, külső tanácsadók, szállítók szerződtetéséről. (Oracle White Paper, 2011) Magyar állami közbeszerzések esetén egy-egy szoftver licenc beszerzése akár több hónap is lehet. (Fábián, 2012) 7 2.1 A „nagy adat” világa Korunk vállalatának legértékesebb vagyoneleme az információ. Ennek tudatában a mai cégek az utolsó információmorzsát is tárolni kívánják. A globális IT, távközlési és technológiai piac egy meghatározó

információszolgáltató vállalata, az IDC szerint az elmúlt három évben több adatot hozott létre az emberiség, mint az utóbbi negyvenezer évben. (idchungary.hu) (ITbusiness.hu, 2012) 2011-ben 1,8 zetabájt (1,8 milliárd terabájt) adat keletkezett a világon, 2012-ben ez várhatóan 2,7 zetabájt. Ennek a nagy adatmennyiségnek egy döntő hányada, mintegy kilencven százaléka strukturálatlan adat (képek, videók, zenék). Amerikában egy új fogalom honosodott meg, a „Big data”. Az adat növekedésének prognózisát a következő grafikonon láthatjuk. (ITbusinesshu, 2012) (ITbusiness.hu, 2012) Míg a relációs adatbázisokra egyre nagyobb adatmennyiség zúdul, addig ezek feldolgozására, üzletileg releváns adatok kinyerésére is egyre nagyobb erőforrást kell összpontosítani. Az adatok feldolgozását, információként való tálalását azonban valós időben, azonnal kell szolgáltatni. Az ilyen központi kimutatások egy forrása lehet az

adattárház, ahol magas szintű kompetenciával rendelkező alkalmazottak ki tudják nyerni a vállalat stratégiája szempontjából releváns adatokat. Ezeket az adattárház jellemzően a rendszerbe épített automatizmusok által támogatja és bocsátja a front-end rendszerek rendelkezésére. (ITbusiness.hu, 2012) 8 Általános tendencia, hogy operatív szinten is növekvő igény jelentkezik az azonnali adatfeldolgozásra. Képzeljük el, hogy egy banki callcenterbe beérkező telefonhíváskor az ügyintéző elkéri az ügyfél azonosításához szükséges adatokat. Az ügyintéző által kezelt front-end rendszer megkapja az adattárház elemzései által szolgáltatott információkat, kategorizálva nem, életkor, jövedelmi helyzet, vásárlási szokások, földrajzi elhelyezkedés és egyedi ügyféljellemzők alapján. Ezt az ügyintéző még kiegészíti a telefonbeszélgetés során kapott információkkal és a beszélgetést egy egyedi, az ügyfél számára

kedvező feltételeket nyújtó termékajánlattal zárja. (ITbusinesshu, 2012) Leginkább a biztosítók, szállítási, közlekedési cégek, bankok és közműipari vállalatok ülnek nagy adathalmokon. Ők rendelkeznek ugyanis közvetlen információval az ügyfeleikről – véli az Accenture technológiai igazgatója, Hatfaludy Károly. (Mártonffy Attila, 2012) Az Accenture szerint három szegmensbe lehet kategorizálni az adatokat. A piramis legalján a nyers adatok találhatók, amelyeknek az üzleti értékük csekély. A következő szinten már valamivel több hasznosítható információt nyújtó adatok találhatóak. A piramis csúcsán olyan tranzakció jellegű adatok találhatóak, melyek kiértékelésével lehet optimalizálni folyamatokat, direkt módon hozzájárulhat az értékesítés növeléséhez, marketing kampányok eredményességéhez. (Mártonffy Attila, 2012) A Facebook, Youtube és hasonló oldalak előretörésével párhuzamosan nőtt a

strukturálatlan adatok hatékony tárolására vonatkozó törekvés. Az ilyen igények kielégítésére honosodott meg a NOSQL fogalma (not only SQL). Lényege abban rejlik, hogy ezek a portálok a strukturált adataikat relációs adatbázisban tárolják, míg a strukturálatlan adataikról csak egy elérési útvonal, vagy erre hivatkozó ID található. Ezek az adatok fizikailag tömbszerűen vannak elrendezve, PL/SQL memóriatáblák működési modelljéhez hasonlító indexeléssel. A NOSQL adatbázisok könnyedén skálázhatóak, nincsenek bonyolult relációs összefüggések a táblák között. A sok tárhelyet használó fájlok feldolgozási ideje lényegesen gyorsabb és biztonságosabb, mintha közvetlenül relációs adatbázisokban tárolnánk őket. (ITbusinesshu, 2012) 9 A teljes archivált adatmennyiségre vonatkozó prognózist a következő grafikon szemlélteti. (ITbusiness.hu, 2012) 2.2 Üzleti hajtóerő A migrációs projektek sosem öncélúak,

mindig valamilyen üzleti igény indukálja elvégzésüket az üzletvitel átszervezésének, IT rendszerek konszolidációjának következményeként. 2.21 Operatív szempontból A legtöbb vállalkozásnál az adatok mozgatása a hétköznapi munka része. Olyan rutinszerű tevékenység, aminek tényleges hozzáadott értéke nincs, azonban elvégzése kötelező. Miért ne lehetne akkor rendszerszinten ezeket a folyamatokat automatizálni, új adatkapcsolatokat kiépíteni? A munkavállalók munkaidejük nagyobb hányadát tölthetnék tényleges üzleti értéket képviselő munkával. Felügyelt csatornán, ellenőrzött módon utazhatnának az adatok, biztosítva ezzel: • az adatok kompatibilitását mást rendszerekkel; • az adatok integritását; • alacsony rendszerleállási időt; • jobb időkihasználtságot; • biztonsági szempontoknak való megfelelést. (Levine, 2009) 10 2.22 Stratégiai szempontból Nem mindegy, hogy egy cég milyen

mértékű erőforrásokat fordít az adminisztratív jellegű tevékenységek támogatására, illetve nagyvállalati szinten milyen alternatív költséget jelent az alkalmazottak kevésbé hatékony foglalkoztatása. Ezen felül a következő motivációs tényezők játszanak szerepet az IT rendszerek fejlesztéséhez kapcsolódó projektekben: • Operációs rendszerek, alkalmazások fejlődése, leváltása (pl.: új ERP rendszer bevezetése). • Új felhasználók, új piacok, új lehetőségek megjelenése vállalati akvizíció, vagy összeolvadás révén. • Szerver, vagy adatbázis technológia fejlődése, leváltása. • Szerver, vagy adatbázis konszolidáció. • Adatbázis struktúra, séma megváltozása (Üzleti igény megváltozásával az adatbázis architektúrája is megváltozhat!) 2.23 • Adattárház helyének megváltoztatása. • A szerverhez, vagy adatbázishoz kapcsolódó környezet karbantartása. • Adatbázis kiszolgálási

képességének fokozása. (Levine, 2009) Banki rendszerek migrálásának sajátosságai menedzsment oldalról Mivel a migrációs piac talán leglényegesebb szereplői a bankok, célszerűnek találtam egy külön fejezetet szentelni ennek a témának. A következőkben láthatjuk, hogy milyen szempontokat kell figyelembe venni core banki rendszerek modernizációja folyamán. Egy internetes banki rendszerekkel foglalkozó portál, a Bank System & Technology által készített felmérésből kiderült, hogy alapvetően milyen témakörök köré csoportosul azon problémák halmaza, amin áll vagy bukik egy banki rendszer bevezetésének sikeressége. A kutatásban megkérdezettek általában banki projektmenedzserek és tanácsadók voltak. Az ebben a témában kompetens szakemberek gyakran hasonlítják a core banki rendszereket érintő fejlesztéseket a nyílt szívműtéthez, utalva ezzel a projektek kockázatára és költségeire. (Penny Crosman, 2011) 11 A

következő 12 lépésben lehetne összefoglalni, hogy milyen szempontok és feladatok kerülhetnek előtérbe a munkálatok folyamán. Még a migráció előtt tisztítsd a rendszerben lévő adatokat! A német befektetési bank, a Deutsche Bank 72 országban van jelen, 1964 fiókja van. Az számlavezető-rendszerüket egy indiai konglomerátum, a TATA Consultancy Services egyik megoldására cserélik, ami a TCS BaNCS Core Banking nevet kapta. A bank vezére, Rudiger Schmidt elmondása alapján a 2010-ben induló projekt várhatóan 2016-ra fejeződhet be. A modernizáció egyik momentuma az adattisztítás, amit célszerű még a forrásrendszerben lefolytatni. A munkálatok előtt célszerű definiálni azt az adathalmazt, amit meg kívánnak tisztítani az oda nem illő elemektől. Ilyenkor jellemzően a számla és ügyfél szintű adatok vonatkozásában határozzák meg a master és nem master adatokat. (zoominfocom, 2012) (Penny Crosman, 2011) A Silicon Valley Bank (SVB)

esetében az adattisztításra szakosodott mérnököket használnak, akik folyamatosan ellenőrzik a kiszolgáló rendszerek által felhasznált adatok körét. Az SVB esetében a projekt öt évig tart, és folyamatosan váltják ki a banki rendszerek egyes moduljait. A kiváltott modulokhoz kapcsolódó adatbázist azonban nem állítják le, az új rendszerrel (Oracle DB) párhuzamosan működik. Ez az egyes release-ekhez kapcsolódó bukás kockázatát hivatott csökkenteni, hiszen ha az új fejlesztések nem integrálhatóak megfelelően az elszámolási folyamatba, akkor vissza lehet állni a régebbi adatbázisra. Ami teljes mértékben friss adatokat szolgáltat a szinkronizálás révén. (Penny Crosman, 2011) Készíts ütemtervet! Az ausztráliai Commonwealth Bank program menedzsere, Dave Curran elmondása alapján egyik lényeges szempont az ilyen programoknál a projektekhez kapcsolódó menetrend meghatározása. Ezek a fejlesztések ugyanis igazán nagyok; ha egy bank

nem tudja magát kötni az ütemtervhez, akkor elcsúszhat a büdzsé, kompromisszumot kell kötni a célok (scope) tekintetében. Az ilyen munkáknál a legnagyobb költségtényező az ember, vagyis ha, egy munka ötven százalékkal több ideig tart, a költségek is a másfélszeresére nőnek. A Commonwealth Bank esetében a projekt vélhetően 4 évig tart és 2012 végére fejeződhet be 580 millió dollár 12 ráfordítás mellett. Ez mai értéken (225 HUF/AUD) 130,5 milliárd forintot jelent Cél egy SAP rendszer integrálása a központi elszámoló rendszerbe. Program szinten való ragaszkodás az ütemtervhez serkentően tud hatni a banki emberek döntéshozatali képességére, de amennyiben ez nincs meg, könnyen el lehet csúszni a határidőkkel. Ennek egyik hátránya, hogy a banki emberek úgy érezhetik, hogy nem hoztak professzionális döntést. A legtöbbször azonban ez nem is cél (Penny Crosman, 2011) Magas szintű döntéshozatali képesség A Boston

Consulting Group (BCG) egykori tanácsadója, Bart Narter szerint teljesen új rendszer építése folyamán elengedhetetlen a bank különböző területeinek képviselőit is bevonó döntéshozatal. Egy teljesen új modell implementálása biztosan érinteni fogja a különböző területeket, legyen szó IT-ról, lakossági vagy vállalati banki szolgáltatásokról. Módszertani gyűjtemény A Deutsche Bank készített egy „migration factory”-t, egy olyan módszertani gyűjteményt, amiben általános migrációs eljárásokról, alkalmazások működéséről lehet olvasni, kiegészítve természetesen az adott projektre vonatkozó specifikus leírásokkal, döntéstámogató anyagokkal. Így az egyes alkalmazottak rá tudnak látni más – a munkájukhoz csak érintőlegesen kapcsolódó – csapatok munkájára, problémáira. (Penny Crosman, 2011) Ne próbálj mindent egyszerre megoldani! Szervezeten belül sokan gondolhatják úgy, hogy bizonyos üzleti

igényükre vonatkozó támogatást célszerű mihamarabb megszerezni. Ugyanis ha ezt nem kapják meg azonnal, akkor könnyen elsikkad a dolog, üres ígéretet kapnak kész funkciók helyett. Célszerű tehát egy adott rendszer kívánt funkcionalitását a lehető legkisebb fejlesztési igényekre felbontani. A cél, hogy folyamatában legyenek tervezhetőek, mérhetőek a fejlesztések. Hatékony megoldás, ha a célrendszerbe a már meglévő üzleti folyamatokat támogató adatbázisstruktúrát migráljuk. Ezt követően lehet az új alkalmazásokat fejleszteni, átalakítani az adatbázis-struktúrát, oly módon, hogy a DB és alkalmazás logika ne okozzon üzletviteli anomáliákat. (Penny Crosman, 2011) 13 Készíts kisebb alprojekteket! Kisebb munkákat jelenthet, amik értéket tudnak szállítani a megrendelőnek. Fontos, hogy az adott fejlesztéseket ne funkcionalitásában, inkább folyamatszemlélettel mutassák be az egyes területeknek. A Silicon Valley Bank

többnyire moduláris megközelítéssel migrál adatokat (incremental, bulk load). Ennek lényege, hogy az 5 éves projekt során logikailag élesen elkülönülő adatblokkokat költöztetnek. Egy ilyen blokk volt a külföldi valutában nyújtott hitelek nyilvántartására készített szoftver migrációja és üzletviteli konszolidációja. A projekt végeztével, látva a fejlesztések eredményességét és azt, hogy merőben új üzleti értéket tudtak teremteni, az SVB újragondolta a stratégiáját. Hatékony megoldást jelent, ha egy verzió átadását megelőzően még egy mini release-t, vagy technikai release-t is beterveznek, az utómunkálatok kivitelezése érdekében. Itt olyan területeket fejlesztenek, amikre vonatkozó igény még nem született meg, nem volt rendesen specifikálva, társterületek még nem döntöttek, stb. (Penny Crosman, 2011) Készülj fel arra, hogy a büdzsén és a határidőkön is lazítanod kell! „Még sosem láttam core banki

projektet időben befejezni Ezek igazán nagy, komplex projektek és mindig vannak meglepetések, amik ritkán kellemesek.” Mondja Bart Narter, a BCG egykori tanácsadója, a banki rendszerek guruja. (Penny Crosman, 2011) Fokozd az embereid kompetenciáját és tartsd meg őket! Még akkor is, ha platformot fog váltani a bank. Nagyon kiábrándító a munkavállalók számára, ha tudják, hogy a projekt lezárásával el lesznek küldve. Célszerű megértetni velük az új platform működését (ami talán nem is nehéz feladat, hiszen többnyire ők fejlesztik). Ezen kívül letisztult domain tudásuk van a banki működéssel kapcsolatban. Tudják, hogy milyen problémával kit lehet keresni, egységes nyelvezetet használnak. (Penny Crosman, 2011) Banki alkalmazottak bevonása Amint korábban említettem, kulcsmomentum lehet a döntési szakaszban a különböző területek képviselőinek bevonása. A tesztelési szakaszban inkább az operatív munkát végző munkaerő

bevonásával lehet növelni az ügyfél-elégedettséget. Érezhetik, hogy részük van az 14 új eszköz bevezetésében, növekedik ez által az alkalmazás felé irányuló elkötelezettségük. (Penny Crosman, 2011) Készülj fel a gyors válaszokra! A projektek által igényelt erőforrások mintegy felét is kitehetik a tesztelési feladatok és a hibák adminisztrálása. Ráadásul koránt sincs lehetőség mindent letesztelni, kizárt annyi tesztesetet definiálni, amennyi az életben is előfordulhat. Ebből az következik, hogy számos problémával találhatjuk magunkat szembe a rendszer élesítésekor. Ilyenkor már nincs lehetőség hosszas workshop-ok tartására, megfelelő döntés előkészítésre, azonnal kell cselekedni a kudarc elkerülése érdekében. (Penny Crosman, 2011) 2.3 A migráció folyamata Az adatok vizsgálatakor feltérképezzük, hogy az adatok milyen rendszerekben, milyen struktúrában találhatóak. Ezt követően alakíthatjuk a

migrációs scope-ot, meghatározhatjuk munka mérföldköveit, készíthetünk munkatervet. Ebben a szakaszban a migrációs vezetők, üzleti szakemberek, felhasználók és egyéb támogató személyzet is részt vehetnek. Adattisztításkor meghatározhatjuk a tisztítandó adatok körét, azok jellegét, prioritásokat állíthatunk fel az adattisztasági elfogadási kritériumokra vonatkozóan, illetve adattisztasági eljárásokat dolgozhatunk ki. Erről a témáról bővebben az Adattisztítás fejezet alatt olvashatunk. ETL folyamatok (extract, transform, load) keretén belül kialakíthatjuk a rendszerek közötti kapcsolatokat, mappelő rendszereket konfigurálhatunk, készíthetünk adattáblákat, scripteket. Jobokat definiálhatunk az adatok kinyerésének automatizálására. Tesztelhetjük a tesztkoncepció működését, hogy éles betöltés esetén a lehető legkevesebb leállással számolhassunk. Ezeket a feladatokat általában a migrációs csapat és

adatbázis adminisztrátorok (DBA) végzik el. (Soumendra Mohanty, 2004) 15 Adatok vizsgálata Adattisztítás ETL folyamatok tesztelése ETL folyamatok kivitelezése Migráció validációja Migrációt követő tevékenységek (Soumendra Mohanty, 2004) A következő ábrán egy klasszikus ETL folyamat látható: Szöveg fájlok Betöltés köztes táblákba Köztes tábla 3 Adatátalakítás Köztes tábla 1 Beemelés az adattárház táblákba (INSERT and UPDATE) Adat ellenőrzés Köztes tábla 2 Adattárház táblák (Palaczk Péter, 2001) A migráció validációjának szakaszában készíthetünk riportokat az átment és várakozó adatállományokról. Megoldásokat kereshetünk a hibás állományok javítására, betöltésére A munka e szakaszában jellemzően a migrációs csapat és üzleti szakemberek vesznek részt. A migrációt követő tevékenységek lehetnek például a célrendszer működőképességének ellenőrzése, tesztelése.

(Soumendra Mohanty, 2004) A gyakorlat azt mutatja, hogy a nagy migrációs projekteket apróbb átláthatóbb, végeredmény szempontjából mérhető egységekre osztják szét. 2.4 Az adatok típusai DB szempontból Oracle rendszerekben, de más eszközök esetében is általában az adat öt típusát különböztetjük meg. Ezek: • konfigurációs adatok (configuration data, set up data) • sub master data • master data • tranzakciós adatok (transaction data) • meta és tartalom adatok (content data) 16 Ezek a típusok a felsorolás sorrendjében függnek egymástól. 2.411 Konfigurációs adatok Ezek az adatok általában a rendszer által generált legalapvetőbb adatok. Szükséges, de nem elégséges feltételei rendszerünk helyes működésének. Generálódhatnak, módosulhatnak a rendszerbe épített automatizmusok által. Ezen adatokhoz kapcsolódó fontos szempont még a skálázhatóság kérdése. (Ramaswamy, 2009) Nem célszerű azonban a

bővíthetőség kérdését túldimenzionálni. A legtöbb esetben célravezető a „Soft Launch” elvét követni, azaz könnyebb kidobni egy kevésbé működő szoftvert, mint rögtön az elején arra tervezni egy alkalmazást, hogy tetszőleges mértékben skálázható lehessen. (Pásztor, 2011) 2.412 Sub master, Master data A sub-master adatok alapvető információkat hordoznak a vállalat működéséről, bizonyos mértékben kapcsolódnak a tranzakciós adatokhoz is. Ilyen adatok lehet például a fizetési mód, szállítási feltételek, szállítási mód, stb. (Ramaswamy, 2009) A master adatok hasonlóan a sub masterekhez alapvető információt hordoznak a vállalat operatív üzletviteléről. A masterek sokkal nagyobb értékkészletből dolgozhatnak, mint a sub masterek, hiszen az előzőben már termék, vagy ügyfél-specifikus adatok is megjelennek. Ilyen adatok lehetnek például az ügyfélhez, termékhez, szállítókhoz kapcsolódó leíró adatok. A

masterek logikailag mindig a tranzakciós adatok környezetéhez kapcsolódnak és folyamatos frissítést és karbantartást igényelnek. (enwikipediaorg, 2012) Túlnyomórészt külön alkalmazást használnak a masterek migrálására. A masterek adatbázisban való elhelyezkedése és az ezekhez az adatokhoz kapcsolódó mezők típusa kulcsfontosságú a migrálás szempontjából. Mivel a masterek alá vannak rendelve a folyamatos frissítésnek, ezért migrációjukat – függően a kivitelezés típusától (Big bang, incremental, stb.) – célszerű a rendszer élesbe állásához közeli időpontban kivitelezni (Ramaswamy, 2009) 17 2.413 Tranzakciós adatok Mindig valamilyen esemény leírására szolgálnak. Önmagukban sosem léteznek, mindig masterekhez, sub-masterekhez köthetőek. 3 tényező kapcsolódik hozzájuk: dátum, numerikus érték, referencia adat(ok). (enwikipediaorg, 2012) A tranzakciós adatok célrendszerben való élesítése mindig a migráció

végső szakaszában történik. Ilyen adatok jellemzően a pénzügyi egyenlegek Fontos döntés előtt találhatjuk magunkat, amikor zárt tranzakciós adatok migrálásának kérdése merül fel. Ezek olyan egykori tranzakciós adatok, amelyekben már nem történik változás, azonban fontos információkat hordozhatnak, vagy megtartásukra, archiválásukra jogszabály kötelez. Ilyenek lehetnek például egykori banki ügyfelek számlamozgásához kapcsolódó adatok. (Ramaswamy, 2009) Az online tranzakciós adatokat kezelő rendszereket nevezzük OLTP (Online Transaction Processing) rendszereknek. Ezen rendszerek a CODD normálforma követelményeinek megfelelve (jobb esetben) relációs adatbázisra épülnek. Ilyen rendszerek támogatják például az ATM-ből való pénzfelvétel elszámolását. (etechplanetcom, 2010) Ha a mobilszolgáltatók tranzakciós rendszerét vesszük alapul, akkor feltöltő kártyás telefonok esetén előfordult szilveszterkor, hogy akár

1-2 óráig sem terhelték meg kártyánkat (a rendszer túlterhelése miatt). Ennek következtében lehetőség nyílt akár egy 500 ft-os egyenlegű kártya esetén több száz, akár 1000 db emelt díjú sms küldésére úgy, hogy utólag csak 500 Ft-al terhelték meg kártyánkat. Láthatjuk, hogy egy tranzakciós rendszer működésének gyorsasága kritikus. Általános tendencia, hogy a tranzakció alapú alkalmazásokat használó vállalkozások adataik nagy részét felhőbe való kiszervezéssel törekszenek költségeik csökkentésére. IT szempontból ezek a vállalkozások hibrid vállalkozások, hiszen információs rendszereik mind belső szervek, mind felhő alapú megoldások (Cloud computing) által támogatott. (informatica.com, 2011) 18 2.414 Metadata vs Content data A meta adatok olyan információkat hordoznak, amelyek meghatározzák az üzlethez közvetlenül kapcsolódó adataink típusát, helyét, elérési útvonalát. Egyszóval plusz információval

szolgálnak a fő adatról. Ezzel szemben a content data már az üzlethez ténylegesen kapcsolódó adatokat jelenti; ilyen lehet egy-egy ügyfél neve, telefonszám, kapcsolódó termékek, stb. (Oracle White Paper, 2011) 19 3 Hatékony migrációs stratégia A legtöbb vállalat az üzleti folyamatainak fejlesztésekor migrál adatot. A migrációs stratégia központjában olyan módszerek állnak, aminek segítségével az adat a forrás platformról a cél platformra helyeződik át úgy, hogy közben teljesítik a hozzájuk fűzött minőségi elvárásokat, nincsenek sérült rekordok, a transzferált adatokat sikeresen validálhatjuk a cél környezetben. (Levine, 2009) Számos mérőszám létezik egy hatékony migrációs projekt hatékonyságának meghatározására. Ezek a következők: • Migrált rekordok aránya • Migrált táblák aránya • Egy adott technológia által migrált rekordok száma • Egy adott alkalmazás által migrált

rekordok száma • Hibás adatok az összes adathoz viszonyítva • Kisiklások száma • Migráció hatása az adatbázis méretére • Migrációból adódó üresjáratok, állás idők • Kiegészítő hardware-ek, adatbázisok • Megoldott problémák száma • Tisztított adatok aránya • Manuálisan tisztított adatok aránya • Automatizáltan tisztított adatok aránya (Levine, 2009) 3.1 Kockázatok A tényleges adat transzferráció számos veszélyt hordozhat. Ilyen kockázat tényezőt jelent az, amikor nincs definiálva pontosan, hogy milyen követelményeknek kell megfelelni. Az üzleti specifikációban ki kell térni integritási, szabályozási, ellenőrzési kérdésekre is. 20 A migrációra vonatkozó elfogadási kritériumok nem egyértelműen definiáltak. Növeli a migrációs eljárások komplexitását az is, ha a logikailag összekapcsolódó adatok külön adatbázisokban találhatóak meg. Az IT megoldást szállító és

munkáját igénybevevő cég között szubjektív mérési kritériumokból adódó teljesítési problémák merülhetnek fel. Az ilyen esetek elkerülése végett lehet célszerű az SLA (service level agreement) szerződés kötése. A szolgáltatási szintre vonatkozó szerződés által lefedett területek nagysága és részletezettsége különbözik a közszférából és versenyszférából érkező megrendelések esetén. Az államigazgatáshoz kapcsolódó projektek esetében sokkal nagyobb hangsúly helyeződik az SLA részletezettségére és következetes betartására, ami sok esetben hatékonysági és rugalmassági problémákat idéz elő. (Fábián, 2012) További kockázati tényezőt jelent a menedzsment hozzáállásán túl (nem segítik a kivitelező partnerek munkáját), ha a projekt költségvetési keretei nem engedik meg a hatékony eljárások, technológiák alkalmazását. Ilyen technológiai megoldást jelenthet például

adatbázis-replikációs eljárások alkalmazása, amely igen költséges a többlet tárhely, illetve többlet sávszélesség igénybevétele miatt. Jelentős költséget indukálhat a fejlesztő eszközök korlátozott igénybevétele, valamint minőségbiztosítási (például HP Quality Center, QC), vagy audit rendszerek alkalmazása is (Oracle Audit Vault). A tesztelés támogatására szolgáló alkalmazások (QC, Oracle Test Manager) is megterhelhetik a projekt büdzséjét. (Levine, 2009) 3.2 Technológiai megfontolások A következő szempontokat érdemes figyelembe venni adataink költöztetésekor: • Az adatbázist kezelő rendszer kiadásának éve. Néhány migrációs alkalmazás nem biztos, hogy támogatja a működő rendszerünket. • Jelenlegi adatstruktúra, vagy séma átültethető-e a cél rendszerbe? Ha igen, az jelentős mértékben csökkenti a migráció komplexitását. (XTTS - little endian big endian probléma) • Szükségünk van az

átköltöztetett adatok törlésére a forrás rendszerben? Esetleg meghagyjuk a régi adatbázisunkat arra az esetre, ha a cél adatbázis összeomlik? A rendszerleállás kockázatát különféle adatbázis replikációs 21 módszerekkel (pl adatbázis tükrözés, vagy front-end, back-end architektúra) csökkenthetjük. Egy központi keretrendszer, vagy mappelő rendszer segítségével szállítjuk az • adatot a szerverek között? (Ha az adatbázisok fizikailag is elkülönült szervereken vannak.) A migrációt irányíthatjuk a forrás adatbázis oldali szerverről, vagy egy egyéb • szerverről. • Szükséges az adatintegritás ellenőrzése a validálás előtt? • Milyen alkalmazottak, tanácsadók állnak a rendelkezésünkre? (Levine, 2009) 3.3 A migráció megközelítése, a kivitelezés alternatívái A tényleges munkálatok megkezdése előtt fontos az üzleti folyamatokat kiszolgáló adatbázisunk, adatbázisaink, adattárházunk

architektúrájának megismerése. A tényleges kivitelezés módszertanának meghatározásakor talán a legfontosabb szempont az IT infrastruktúránk felépítésének jellege. Ide kapcsolódik adatbázisaink kommunikációja, illetve az, hogy milyen kapcsolatok vannak az egyes logikai egységek között. A biztonsági követelményeknek (pl. milyen titkosítási eljárást alkalmazunk) való megfelelés jelentős mértékben növelheti egy architektúra bonyolultságát. Emellett még üzleti folyamataink időbeli lefolyása, a folyamatos kiszolgálásra vonatkozó igény jelentős mértékben bonyolítja a migrációs munkálatok megszervezését. A projekt tervezésének szempontjából sokkal egyszerűbb olyan rendszereket migrálni, amiket akár egy egész éjszakára, vagy hétvégére le lehet állítani. Egy kisebb internetes portál esetében az éjszakai migráció és élesítés kevésbé jelenthet gondot, ugyanis éjszaka kevés felhasználó tartózkodik az oldalon.

Ilyenkor kevés alternatív költséget jelent az ’üzlet’ átmeneti felfüggesztése, míg egy bankkártya-tranzakciókat kiszolgáló adatbázis átmeneti felfüggesztése veszélyes következményekkel járhat. Természetesen a nagyobb nemzetközi hírportálok esetében kiegyensúlyozottabb terhelésről beszélhetünk. Az éjszakai terhelés ilyenkor kevésbé releváns a migráció szempontjából, hiszen az időeltolódás miatti látogatói aktivitás kevésbé differenciált. 22 3.31 A kivitelezés alternatívái Röviden összefoglalva a következőképpen állhatunk hozzá a munkához. Megközelítés Leírás Előnyök / Hátrányok Ne migrálj! Csak az új adatok lesznek betöltve az új Gyors környezetbe. bonyolult függőségek a régi Élhetünk az új adatok szinkronizálásának lehetőségével. kezdés, nincsenek rendszer felől. Alacsony üzleti érték, szűkös fejlesztési lehetőségek. Alkalom Az üzleti logika

szempontjából elkülönülő Alacsony üzletviteli kockázat, adtán (event- egység(ek) migrálása, bizonyos feltételeknek nagyobb based való megfelelés esetén (új termék egy piacon logikák migration) való lehetősége. bevezetése, kifutó termékek hozzáadott értékű fejlesztésének Gyors reagálási adminisztrálása stb.) képesség. Inkrementális A migrációt az üzlet szabályozza, az adatok Üzleti résztvevők által vezérelt, (incremental költöztetése kisebb, ámde növekvő méretű viszonylag alacsony kockázat. migration) lépésekben, logikailag egymásra épülő blokkok Többnyire agilis projektvezetés költöztetésével történik (pl. ügyféltörzs szintje, jellemző. termék szint, szolgáltatási szint, CRM, DSS.) Bulk load Először nagy adatblokkok migrálása (pl. Egyszerű projektmenedzsment. ügyféltörzs), később egyéb adatok, például tranzakció szintű adatok migrálása. Big bang Nagy

adatblokkok migrálása, ügyfelek, Egyszerű projektmenedzsment, termékek, üzleti folyamatokat támogató adatok egyértelmű (set-up-ok, feladatok, sub masterek, tranzakciók) egyidejű migrálása masterek, fejlesztési inkább fejlesztők által vezérelt. Új igényekre rugalmatlan válaszokat ad. 23 3.311 Incremental & Bulk load A két megközelítés sokban hasonlít egymáshoz, fő különbséget az egyszerre transzportált adatok mennyisége jelenti. Inkrementális megközelítés például az ügyféltörzshöz kapcsolódó adatok további logikai egységekre való bontását jelenti. Bulk load esetében például az ügyféltörzshöz kapcsolódó minden adatot migráljuk, majd ellenőrizzük a célkörnyezetben. 3.312 Big bang A big bang projektek általában egy menetben migrálják az adatokat a forrásrendszerből a célrendszerbe. Egyik nagy hátránya, hogy a rendszer leállítását követeli meg az adatok kinyerése, transzformálása és

betöltése (extract-transform-load, ETL) a cél rendszerbe. Vonzó lehet ebben a módszerben a gyors lefutási idő, de számos kockázatot hordoz, ugyanis kevés vállalkozás engedheti meg magának, hogy a core rendszer leállítása mellett kivitelezze az adatok költöztetését. A legtöbb big bang migrációt éjszakára, hétvégére, ünnepnapokra tervezik, amikor kisebb áldozat mellett lehet elvégezni a munkát. (Oracle White Paper, 2011) A mindent vagy semmit megközelítésnek a kockázatok mellett azonban számos előnye van. Elsődleges szempont talán, hogy jól tervezhetőek a munkafolyamatok, egyszerű a projektmenedzsment. Nincs szükség két rendszer egyidejű karbantartására Nem lépnek fel a rendszerek párhuzamos működéséből adódó szinkronizációs problémák, ugyanis nem kell frissen tartani a régi rendszer migrálás alatt lévő rekordjait. A kockázatok között talán az elsődleges szempont a projekt bukása esetére tervezett ’B terv’. Ez

a régi rendszerre való automatikus átállást jelenti. Azonban az új alkalmazás működése folyamán keletkezett adatváltozások szinkronizálása, vagy replikálása a régi rendszerbe problémás lehet. (datamigrationpro.com, 2009) 3.4 Oracle TimesTen Mint a bevezetőben is leírtam, az adatbázis-költöztetés olyan terület, ahol a legújabb, leghatékonyabb technológiák ismerete stratégiai előnyt biztosíthat a vállalat számára. Ha alapvetően egy tranzakciók által vezérelt adatbázist költöztetünk, azért, hogy költségeinket csökkentsük, a DB hatékonyságát növeljük, kiszolgálási időt csökkentsük, akkor jelenthet kiváló alternatívát az Oracle TimesTen. (Schopp Attila, 2009) 24 Vegyük például egy banki ügyfél példáját. ATM-en szeretne kivenni pénzt, annak ellenére, hogy nincs már pénz a bankszámláján és a hitelkeretét is kihasználta. A pénzkivételre vonatkozó igény jelentkezése és elutasítása között eltelt

időt csökkentheti ennek a rendszernek az alkalmazása. Ilyen esetekben ugyanis kulcsfontosságú a tranzakció átfutási ideje. (Schopp Attila, 2009) A hagyományos merevlemezek mechanikus szerkezetek, hatékonyságokat növelni egy szint felett már nagyon nehéz. A hagyományos merevlemezről futó adatbázis általában egy ún lapozási technológiát (paging) használ, aminek lényege, hogy a blokkszintű beolvasás miatt lényegesen nagyobb adatmennyiség kerül át a memóriába, mint amennyire valójában szükség van. Az itt átmenetileg tárolt adatokon fut le az utasítás és a végeredmény is a memóriában tárolt adatok által kerül meghatározásra. Legfőbb hátránya a magas processzorigény (Schopp Attila, 2009) A memóriaalapú adatbázisnak kiadott SQL parancsokat a DB memóriacímmé változtatja, így kevesebb művelettel végrehajtható az adott lekérdezés. (Schopp Attila, 2009) Az Oracle TimesTen is egy ilyen logika alapján működő relációs

adatbázis kezelő rendszer. Legfőbb érdekessége talán, hogy közös memóriahelyet használ az általa kiszolgált alkalmazásokkal. (Schopp Attila, 2009) A hagyományos és memória alapú relációs adatbázisok előnyeit hangsúlyozza ki az Oracle 11g R2 által támogatott Flash Cache technológia, ami már az exadatában is megtalálható. A logika azon az elgondoláson alapul, hogy a master és sub-master adatokhoz kapcsolódó folyamatok a hétköznapi adatbázisokhoz hasonlóan merevlemezről működnek, ugyanis az ezekhez kapcsolódó kiszolgálási sebesség kevésbé meghatározó. Az OLTP folyamatok viszont az „Exadata Smart Flash Cache” technológia segítségével kerül kiszolgálásra, azaz a tranzakció szintű folyamatok már memóriából futnak. (Ron Weiss, 2011) 3.5 Alkalmazások, logikák Ebben a fejezetben a migráció kivitelezésének szempontjából a két legnevesebb szoftverszállító céget és általuk fejlesztett alkalmazásokat tekintjük át.

Igaz, az Oracle esetében inkább egyfajta logikáról, illetve know-how-ról beszélhetünk, mintsem egy kész szoftverről. 25 3.51 Allround Automations Egy 1989-ben alapított német Szoftverfejlesztő cég, az Allround Automations ismerte fel a Delphi és C++ fejlesztő eszközök (pl.: Borland C++ Builder) között húzódó rést Ezt az űrt az 1997-ben piacra dobott PL/SQL Developer (PSD) integrált fejlesztő környezet (IDE – intgrated development environment) hivatott betölteni. (Coulam, 2001) 3.511 PL/SQL Developer Két fogalom miatt kedvező az adatbázis-fejlesztéssel és üzemeltetéssel foglalkozó szervezetek számára, ez a kedvező ár/minőség arány és a rugalmasság. Ugyan nem tud mindent, amire az adatbázis adminisztároroknak (DBA) szükségük lehet, de számos más, fejlesztők számára kedvező funkció bele van építve az árba, amiért a TOAD, SQLNavigator és RapidSQL esetében fizetni kell. Ezek a modulok például a profiling és a

debugging (Coulam, 2001) Számos előnye van, ezek például: • Code Assistant: gyors és intelligens, automatikus kód-kiegészítés • Bővíthető nézetek és tool set • Jó connection manager (tárolja a különféle adatbázisokhoz a kapcsolati adatokat, jelszavakat, hasonló a kedvencekhez) • Egységes lekérdezés varázsló a junior fejlesztőknek • Ez az iparági sztenderd • Kevés bug • Egyedi igényekre szabható • Egyes actionok széleskörű, több modulból való elérése • 20 perc alatt installálható, 30 napos teljes funkcionalitású próbaverzió Egyik legfontosabb előnye talán az, hogy az Oracle adatbázisok programozására teljes körűen használható. Tekintve, hogy a világ adatbázis-piacának 48,8%-át az Oracle uralja, ráadásul a növekedés mértéke jóval meghaladja az iparági átlagot, ez koránt sem elhanyagolható szempont. (Colleen Graham) 26 Emellett intuitív interfész, egységes, az oracle

adatbázisok programozási logikája mentén felépített help funkciók jellemzi. (Coulam, 2001) Hogy kik használják ma Magyarországon? A teljesség igénye nélkül: Aegon, Allianz, Audi, Axelero, BNP Paribas, Budapest Bank, Citibank, Erste Bank, FHB bank, HVB Bank, ING Group, K&H Bank, Nemzeti Fejlesztési Ügynökség (NFÜ), Oracle Corporation, OTP Bank, Raiffeisen bank, TATA Consultancy Services, Vodafone. (allroundautomationscom, 2012) Mennyibe kerül? Egy felhasználó esetén 180$, tíz felhasználó esetén 900$, 100 felhasználó esetén 3000$, szervezeten belüli korlátozatlan felhasználás esetén 6000$. (allroundautomations.com, 2012) Az Oracle is biztosít egy eszközt adatbázis-kezelésre, ami az Oracle SQL Developer nevet kapta. Egyik lényeges előnye, hogy ingyenes, azonban funkcionalitását, kezelhetőségét tekintve lényegesen elmarad a PL/SQL Developertől. (Fábián, 2012) 3.512 Direct Oracle Access Az Oracle alkalmazásokat fejlesztők

(amennyiben Delphit és C++-t használnak) munkáját jelentős mértékben egyszerűsítheti Direct Oracle Access komponenscsomag használata. (allroundautomations.com, 2012) Jelentősége az Oracle adatbázis interfészének közvetlen elérésében, 2 logikailag elkülönülő köztes szoftverréteg (middleware) kihagyásában rejlik. BDE alkalmazás BDE motor DB-ra mutató SQL link Oracle Call Interface, Oracle net Oracle adatbázis-réteg Direkt Oracle Access alkalmazás Oracle Call Interface, Oracle net Oracle adatbázis-réteg A fenti ábrákon egy elavult BDE (Borland Database Engine) motorral működő, és egy Direct Oracle Access segítségével fejlesztett szoftverarchitektúrát láthatunk. Az utóbbi felépítés 27 legfőbb előnye, hogy az alkalmazásrétegben működő szoftver kevésbé szembesül az alatta működő köztes rétegek működési logikájából fakadó függőségekkel, konfigurációs problémákkal. (allroundautomationscom, 2012) 3.52 Oracle

Larry Ellison és Bob Oats a 70-es években egy titkos projekten dolgoztak a CIA-nek. A cél egy hatékony adatbázis-kezelő rendszer fejlesztése volt. A projekt az Oracle nevet kapta Az Oracle, vagyis orákulum olyan személy, aki minden kérdésre tudja a választ. A projekt megszűnésével azonban nem álltak le a fejlesztéssel, létrehozták az Oracle Corporation-t. (Boglárka, 2009) A céget 1977-ben alapították Kaliforniában. A világ jelenleg legnagyobb üzleti szoftvermegoldásokat szállító cége Vezetője, Larry Ellison fő stratégiai célkitűzései között szerepel a platform-független alkalmazások fejlesztése, az egyszerűbb adatkezelés, rendszerek magasabb szintű együttműködése a szinkronizációs és migrációs képesség javítása érdekében. (erpfanblogspothu) Az Oracle stratégiájának fontos eleme volt a Szilícium völgyben található szoftvertermékeket gyártó cég, a Sun Microsystems felvásárlása. Mivel a Sun tulajdonában ált a Java

programozási nyelv védjegye, így az akvizícióval erre is szert tettek. A Java – harmonizálva Ellison stratégiájával – köztes szoftverként és platformként is egyaránt működik. Ebből még nem következne a platformfüggetlenség, de a java alkalmazásokat általában bájtkód formátumra alakítják, platformfüggetlenséget. ami aztán egy Természetesen virtuális natív gépen alkalmazás fut, támogatva is fejleszthető ezzel a javával. (hu.wikipediaorg, 2012) A Sun megvásárlásával know-how-t is vásároltak, ez döntő mértékben hozzájárult egy új megoldás, az Oracle Exadata megalkotásához. Ezzel párhuzamosan került a köztudatba az „Exalogic” kifejezés, amely egy félig-meddig előre konfigurált, ún. pre-engineered rendszerekre utal. Jelentősége, hogy az adatbázisréteg, köztes kiszolgáló rétegek és az alkalmazás réteg működése Oracle alkalmazások, jellemzően nagyvállalati környezetben való futtatására

van optimalizálva. (Phillips) 28 3.521 XTTS - Cross Platform Transportable Tablespace Az XXTS öt lépése (Oracle 11g Release 2 esetén): • Felkészülés a migrációra • A metaadatok exportálása a forrásrendszerből • Forrásrendszerben lévő ’content’ adatok másolása a célrendszerbe Recovery Manager segítségével • Metaadatok importálása a célkörnyezetbe • Adatok élesítése, rendszer validáció Viszonylag egyszerű, big-bang alapú megközelítést feltételez. Egyszerű logika mentén nyílik lehetőség az adatbázis költöztetésére. Az adatbázis tábláit egyszerre tudjuk migrálni a hozzájuk és a felhasználókhoz kapcsolódó indexek és bizonyos korlátozó feltételek (pl.: megszorítások) újbóli kódolása nélkül. (Oraclecom, 2012) Az Oracle Cross Platform migrációjának azonban nem csak előnyei vannak. Komoly hátrányt jelent, hogy Oracle-adatbázisok kizárólag Oracle-adatbázisra való költöztetését

támogatja. Másik korlátozó tényező a forrás és cél operációs rendszerek endian rendszereinek (little, big) egyezősége. (Oraclecom, 2012) Abban az esetben, ha nem egyezik meg a cél és forrásrendszer processzorain lévő bitek elhelyezkedési logikája (big endian, little endian), akkor konverzió szükséges. (en.wikipediaorg/wiki/Endianness, 2012) ALTER TABLESPACE tabla neve READ ONLY (ViSolve, 2012) Metaadatok exportálása Adatok konvertálása RMAN-el Content adatok célrendszerbe juttatása Metaadatok importálása ALTER TABLESPACE tabla neve READ ONLY 29 3.522 Oracle Data Pump Az Oracle Data Pump egy szerver oldali infrastruktúra (modul), ami a bulk típusú adat költöztetést támogatja, helyettesítve a régi export, import alapú adat migrációt. Egyszerű, biztonságos, ámde lassú megoldást jelent. Egyik fő hátránya, hogy újra kell építeni az indexelést a célrendszerben, ami jellemzően több időbe telik, mint maguk az adatok

költöztetése. (Oraclecom, 2012) Az Oracle Data Pump előnyei: • Egyszerűség • Nagy rugalmasság az a költöztetendő adatbázis objektumok kiválasztásakor: • Teljes adatbázis • Séma – ha nem vagyunk DBA-k, csak a saját sémánkat migrálhatjuk • Táblák – ha nem vagyunk DBA-k, csak a saját tábláinkat migrálhatjuk • Tablespace – a táblához kapcsolódó minden content és meta adat is migrálásra kerül • Transportable tablespace – csak meta adatok és a kapcsolódó DB objektumok kerülnek migrálásra (megszorítások, indexek, default értékek stb.) (psougorg, 2010) • Leállítható és újraindítható export és import job-ok • Futó imp/exp jobok folyamatos monitoringja, hibák logolása (oracle-dbaonline.com) 3.523 Recovery Manager A Recovery Manager egy olyan alkalmazás, vagy modul, amely Oracle szervereken tárolt adatok biztonsági mentéseiért felelős. Előnye, hogy a merevlemezen található üres

adatblokkokat figyelmen kívül hagyja, valamint az adatbázis-archiválási folyamatok lefolyása kevesebb időbe telik. (orafaqcom, 2011) 30 Az Oracle ezen felül a következő migrációs eljárásokat is támogatja: • Oracle Streams replikáció • Insert • Create table as select • Egyéni PL/SQL migrációs eljárások (Custom procedural approaches) (Oracle.com, 2012) 3.524 Oracle Migrációs eljárások összefoglalása A fenti 4 logika a következő táblázatban összegezhető: Migrációs technika Komplexitás (kockázat) Előképzettség Leállás ideje Szelektivitás + DB hely Előmunka Utómunka Transportable tablespaces Közepes Közepes Közepes Alacsony I Közepes Alacsony Data Pump (Export/Import) Alacsony Alacsony Hosszú Közepes I Alacsony Közepes Recovery Manager Közepes Közepes Rövid Alacsony N Alacsony Alacsony Procedural Approaches Magas Közepes Hosszú Magas N Magas Közepes (Oracle.com, 2012) A

komplexitás mértékével nő a kockázat is, hisz minél több lépésből áll egy eljárás, annál több a hibalehetőség, annál nagyobb a manualitás mértéke. A legtöbb adatbázis adminisztrátornak már van tapasztalata alapvető migrációs eljárásokban – ha nem is ismeri az összes technikát – az exp/imp mindenféleképpen ismerős számukra. (Oraclecom, 2012) A nagy rendszerek leállási idejére vonatkozó követelményeket az üzlet határozza meg. Fontos szempont, hogy maga a migráció üzleti folyamatokat támogat, a logikailag elkülönülő blokkok migrálása mindig valamilyen kapcsolatban áll más rendszerekkel, így közvetve az üzlettel is. Fontos feltérképezni a rendszerek egymásra épülését és az ebből fakadó függőségeket. 31 4 DB Biztonság Az informatikai rendszerek elleni támadások célpontja általában valamilyen adat megszerzése, mivel ezek általában adatbázisokban találhatóak, ezáltal kulcsfontosságú ezek

védelme. (Schopp Attila, 2011) Sokszor előfordul, hogy a cégek csak az éles rendszereikben található adatokat védik, az archivált adatokat nem. (Schopp Attila, 2011) A megfelelő védelem egyik alapelve, hogy különböző technológiák vegyítésével érhetjük el adataink hatékony védelmét. Legyen szó jogosultságok kiosztásáról, adatbázis auditról, DAM-ról, vagy encryption megoldásokról önmagukban egyik sem nyújt teljes körű védelmet. Egy Oracle felmérés szerint a vállalatok 28%-a titkosítja az adatait az adatbázisokban, 23%uk titkosítja az adatbázisok közötti kommunikációt, 15%-uk figyel oda az adatbázismentések és exportok biztonságára. (Sárecz Lajos, 2010) Egy 2011-es felmérés szerint a vállalatok 76%-a nem védi az érzékeny adatait az úgyn. privilegizált felhasználóival szemben (pl.: DB adminok), míg csupán 30%-uk monitorozza az érzékeny adataihoz való hozzáféréseket. (medianetworkoraclecom, 2012) 4.1 Jogosultságok

Az adatok feletti őrködés egyik legrégebbi módja a jogosultságok kiosztása. Előfordulhat olyan eset, hogy az adatbázis adminisztrátornak, vagy a jogosultságkezelő rendszert használó személynek nem áll módjában minden egyes személy esetében megvizsgálni, hogy milyen tevékenységeket engedélyezzen számára. Ilyenkor szerepkörök meghatározásával lehet létrehozni bizonyos jogosultsági szinteket és társítani a munkavállalókhoz. (Schopp Attila, 2011) Célszerű mind alkalmazás, mind adatbázisoldalon kialakítani a megfelelő jogosultsági szinteket. Ennek révén csökkenthető a közvetlenül adatbázis-oldali támadás kockázata (Schopp Attila, 2009) 32 Természetesen előfordulhat, hogy egy munkavállaló a neki jogosan járó jogosultságot magasabb szintre emeli, ezáltal hozzájuthat nem kívánt információkhoz. Ez elleni hatékony védekezést jelenthet, ha nem csak azt nézzük, hogy ki milyen lekérdezést, vagy módosítást csinált az

adatbázisban, hanem azt is, hogy mikor, honnan csinálta. (Schopp Attila, 2011) 4.2 Adatbázis audit 4.21 Database Activity Monitoring (DAM) A DAM eszközök olyan audit eszközök, amelyek minden tevékenységet rögzítenek az adatbázison belül. Igazából az auditon túl is mutat, hiszen nem csak az egyes DB elemek megváltozását, hanem a lekérdezéseket is naplózza. Valós időben elemzi a felhasználók viselkedés mintáit, hogy ha ezekben eltérést tapasztal, akkor ezt jelezni tudja. (Schopp Attila, 2010) Egy DAM eszköz képes: • rendszergazdai utasítás nélkül önállóan gyűjteni és elemezni az adatokat, • többféle forrásból (nem csak DB-n belül) gyűjteni információkat • különböző módokon elemezni az információkat és valós időben beavatkozni, • elkülöníteni egymástól a DB rendszergazda, auditor és a biztonsági szakemberek feladatköreit. 33 5 Doksi.hu migráció 5.1 A doksiról A doksi.hu-ról 2012-ben havonta

átlagosan 1 200 000 oldalszámú dokumentumot töltöttek le a felhasználók. Egy átlagos napon 30-an regisztrálnak, a regisztráltak fele kér heti rendszerességgel hírlevelet. A dokumentumok túlnyomó többsége magyar nyelvű, de számos anyag található angol, német, román, spanyol, francia és olasz nyelven is. A látogatók nagy hányada jellemzően a 19 és 23 év közötti korosztályból kerül ki. 5.11 Doksi.hu működési sajátosságok A doksi.hu profiljának nagy részét a portálra érkező látogatók számára biztosított tanulmányok, szakdolgozatok, jegyzetek, összefoglalók és különféle tanulást elősegítő segédletek jelentik. 2010-ben került átadásra egy új modul, a tanárkereső. Ide magántanárok jelentkezhetnek és hirdethetik magukat, kihasználva a kiváló Google-megjelenések lehetőségét (ha az adott tanár nevére, tárgyára keresünk). Az oldalon található a Magyar politikusok rovat, ahol napjaink politikusainak életrajza

található meg. Továbbá keresgélhetünk a Magyar uralkodók, Irodalmi arcok, Világirodalmi arcok, Irodalmi műfajok, Kötelezők stb. rovatokban is A főoldalon a teljesség igénye nélkül hírek, érdekességek, ajánlott doksik és egy kiemelt tanár látható. A portál adatbázis-kezelésre phpMyAdmin-t és MySQL Workbench-et használ. A munkák kiosztására, nyomon követésére, értékelésére, elemző munkák támogatására, hibák adminisztrálására, projektek nyomon követésére a MANTIS Bug Trackert használja. A portál Doksi-böngésző rovatán belül lehetőség nyílik a dokumentumok között, azok leírása alapján keresni. Ilyenkor, ha a keresett kulcsszó megtalálható a leírásban, akkor megjelenik a szűrt doksik között. 34 5.2 Doksihu adatbázisa 5.21 MantisBT Bug Tracking A portál a munkák szervezésére a MANTIS Bug Trackert használja. A MantisBT alapvetően a szoftverfejlesztők számára kínál egy alternatívát a ’kockás

füzet’ megoldások (pl.: excel, world) kiváltására a bugok nyomon követésének, fejlesztési teendők támogatásának területén. Ennek ellenére projektmenedzsment eszközként is használható, hatékony támogatást tud nyújtani kisebb projektek (kisebb migrációs projektek!) esetén. Lehetőség van új feladatokat felvenni témakörönként, azt emberekhez rendelni, prioritást, határidőt, költséget meghatározni, projekteket létrehozni felelősökkel (csak megfelelő jogosultsági szinttel), kimutatásokat csinálni a feladatok komplexitására, határidejére, hibák státuszára vonatkozóan stb Automatikusan készülnek kimutatások a projektek, státuszok és súlyosság (severity) mentén, a következőképpen: 35 5.22 phpMyAdmin A portál adatbázis-kezelésre főként phpMyAdmin-t használ. Ez egy PHP nyelven írt nyílt forrású eszköz, amely támogatja az alapvető adatbázis műveleteket, legyen szó táblákról, indexekről, felhasználói

jogosultságokról, procedúrákról. Lehetőség van a különféle DB elemek importálására, exportálására. Teljesen platform-független, így bármely operációs rendszerre telepíthető. (intermatrixhu, 2010) Képes MySQL adatbázisok menedzselésére, lehetőség van SQL parancsokat futtatni. Szuperfelhasználóként lehetőségünk van MySQL szerverek kezelésére. Sok Linux disztribúció is tartalmazza. (huwikipediaorg, 2012) 5.23 Doksi.hu adatbázis szerkezete Sajnos biztonsági okokból nincs lehetőség a teljes adatbázis tábla és mezőszintű bemutatására, azonban összefüggéseiben, egyes táblák logikai kapcsolatai áttekinthetők. A táblákra, mezőkre nem az eredeti nevükön hivatkozom. Az adatbázis felépítését adatvédelmi okokból néhol meg kellett változtatni. Mezőket lehagytam, illetve átcsoportosítottam nem létező táblákhoz. Az elektronikus tartalmak URL címét módosított formában szerepeltetem A dokumentum-találatok számát a

lekérdezések során módosítottam, azonban egymáshoz viszonyított arányuk változatlan maradt. 36 Az alábbi képen egy FreeMind – MindMap alkalmazás segítségével elkészített ábrát láthatunk a doksi.hu DB szerkezetéből 37 5.24 Fontos tudni, kimutatások Migrálás előtt egyik lényeges szempont, hogy minden, a portálhoz kapcsolódó információ a rendelkezésünkre álljon. Lehet, hogy nem lesz rá szükségünk, de értelmes kimutatások készítése vezetheti a gondolatmenetünket, érdekes összefüggések, ezáltal új fejlesztendő területek kerülhetnek előtérbe, amiről eddig szó sem esett (mint ahogy történt az alábbi kimutatások folyamán is). Azonban nem feltétlen áll rendelkezésünkre minden adat a szükséges formában annak érdekében, hogy megfelelő minőségű prezentációkat el tudjunk készíteni. A kimutatásoknak mindig valamilyen üzleti értéket kell képviselni, olyan témát kell feldolgozni, ami az adott területen

jellemző sajátosság. Sokszor elfecséreltnek tűnik az elemzésre fordított idő, de egy-egy összefüggés definiálása döntő lehet a további fejlesztések, az üzletvitel és stratégiai célkitűzések szempontjából. A portál esetében a kimutatások fő témakörei: • Letöltések mennyisége kategóriánként, alkategóriánként. • Kategóriánkénti oldalszám, átlagos oldalszám. • Dokumentumok átlagos mérete (általában oldalszám, kiterjesztés, tömörítés függvénye). • Szerver terhelése. • Fejlesztési lehetőségek szerver oldali támogatása. • Egy új mini-projekt, a dokumentum előnézet fejlesztése tipikusan ilyen. A doksi.hu esetében a letöltések (találatok) mennyisége, a szerveren lévő oldalszám, adatmennyiség, a letöltések egymáshoz viszonyuló aránya kulcskérdés a migráció szempontjából, hiszen a szokásos üzletvitel hatékonysága is ezeken a mérőszámokon alapul. 5.241 Főkategóriánkénti

dokumentum-letöltések megoszlása meghatározásának nehézségei Cél annak meghatározása, hogy a látogatók dokumentum letöltéseinek mennyisége, hogyan oszlik meg az egyes alkategóriák között. Problémaként jelentkezett az, hogy csak az alkategóriának volt ID-ja, a főkategóriának nem. Az ID-k kiosztásának algoritmusából sajnos 38 nincs lehetőség következtetni a hozzá tartozó főkategóriára, ami szükséges lenne a Select utasítás kiadásakor. Jelenlegi ID: Jelenlegi id kiosztás logikája (folyamatosan növekvő). Lehetséges ID: jövőbeli (?) id kiosztás logikája (hátrány: több helyet foglal a karakterszámok növekedése miatt). Így egyértelműen beazonosítható egy-egy főkategória az első számjegy(ek) egyezősége miatt. Kategória azonosító kiosztásának logikája: Főkategória Alkategória Főkategória jelenlegi ID Lehetséges ID Gazdasági ismeretek Adózási ismeretek gazdasagi ism ado ismk 1 001

Államháztartás gazdasagi ism allamhaztartas 2 002 Auditálás gazdasagi ism auditalas 3 003 Bankok, Pénzügyi szervezetek gazdasagi ism bank pu szerv 4 004 Anyagismeret gepesz anyagism 5 011 Biztonságtechnika gepesz biztonsagtech 6 012 Hadtörténelem hadasz hadtori 7 021 Középiskola hadasz kozep 8 022 Adatbázisok info db 9 031 Alapismeretek, ECDL info alapism 10 032 Ergonómia info ergonomia 11 033 Gépészet Hadászat Informatika A kimutatást nem lehetne megcsinálni (vagy csak általam nem ismert módon), de ha megnézzük a dok doksik tábla egyik oszlopa a dokumentum fizikai elérési útvonalára hivatkozik a következőképpen: anyag/gazdasagi ismeret/gazdasagi ism/ anyag/gazdasagi ismeret/allamhaztartas/ 39 anyag/gazdasagi ismeret/auditalas/ anyag/gazdasagi ismeret/bank pu szerv/ A következő utasítás kiadás után lehetőség van excelbe exportálni az adatokat (a lekérdezéseket célszerű phpMyAdmin-ban

könyvjelzőbe menteni): SELECT dok doksik.katid, dok fokat.eleresi ut, dok fokat.nev, SUM(dok doksik.talalat) FROM dok doksik, dok fokat Where dok fokat.katid = dok doksikkatid GROUP BY dok doksik.katid A lekérdezés eredményének excelbe való exportálását követően a 3 segédsorban egy ’KÖZÉP’ és egy ’SZÖVEG.KERES’ függvénnyel lefejtük az irreleváns adatokat a főkategória elérési útvonaláról. 40 A következő eredményt kapjuk: Alk at I D Főkat. Alkategória 200 angol Humánerőfor rásmenedzsment 24534 520 angol 413 biosz Kum. S letöltések 1 S2 S3 6 angol/erettsegi/ anyag/angol/erettsegi/ Ideggyógyász at 2652 6 angol/tesztek/ anyag/angol/tesztek/ Konferenciák 6 biologia/altalanos isk/ anyag/biologia/altalanos is k/ 339 Pivot tábla segítségével a következő eredményt kapjuk a Gazdasági ismeretek főkategória letöltéseinek megoszlására vonatkozóan: Gazdasági ismeretek főkategóriában lévő

letöltések megoszlása alkategóriánként Letöltések száma 120000 100000 80000 60000 40000 20000 0 Összesen Alkategória megnevezése 41 Láthatjuk, hogy az Auditálás, Középiskola, Nonprofitszféra alkategóriák viszonylag csekély darabszámú találatot eredményezett. Ennek különböző okai lehetnek: • Az egyes alkategóriákban eleve kevés dokumentum van. • Ezek a témakörök nem érdeklik az embereket. • Google optimalizálási problémák merültek fel. A leírás rossz, kevés, vagy irreleváns kulcsszavakkal van tele, nem tudja beindexeli a google, stb. Ilyen problémák enyhítésére indult el az Előnézet projekt. 42 5.242 Összes letöltés megoszlása főkategóriánként 43 5.243 Oldalszám meghatározása főkategóriánként, konklúzió A Főkategóriánkénti dokumentum-letöltések megoszlása meghatározása folyamán meghatározott Select-et kiegészítve ’SUM( dok doksik.oldalszam )’-al a következő

kimutatást készíthetjük el. Főkategóriánkénti oldalszámösszegek 12000 10000 8000 6000 4000 2000 0 Összesen Főkategóriák Adózási Államháztartás Auditálás Bankok, Biztosítás Döntéselmélet Európai Unió Gazdaságföldrajz Gazdaságpolitika Gazdaságtörtén Globalizáció Humánerőforrá Kontrolling Környezetgazda Középiskola Közgazdaságtan Logisztika Magyarország Marketing Médiagazdaság Menedzsment Minőségbiztosít Nonprofit szféra Operációkutatás Pénzügy Projektmenedz Számvitel Tanulmányok, Társadalombizt Tőzsde USA Üzleti terv Vállalatgazdasá Vállalkozási Vezetés- Világgazdaságtan Oldalszámösszegek A fenti kimutatásokból láthatjuk, hogy például marketing témakörében a doksik oldalszámösszege aránylag nagy, amihez magas találati arány is tartozik. Auditálás témakörében ugyan kevés tartalom van (kevés oldalszám), emellett kevés találatot is eredményez. Ennek ellenére lehetséges, hogy a relatív

hatékonysága magasabb, mint a marketing témakörnek. Ennek két oka lehet: • Auditálás témakörében magasabbak az egy kattintásra jutó reklámbevételek. A reklámok a vendégről kialakított profil alapján jelennek meg, amelyek részben Google keresési statisztikák, másrészt doksi keresési statisztikák összefésülése (súlyozása) révén kerül kialakításra. • Lehet, hogy az auditálás kategóriában kevés dokumentum van fent, kevés oldalszámmal, de az egy oldalra jutó átlagos kattintások száma meghaladja a marketing doksik egy oldalra jutó találatok számát. 44 5.244 Magas üzleti értékkel rendelkező fejlesztési lehetőségek Ha megnézzük az Üzleti terv alkategóriát, akkor láthatjuk, hogy messze kiemelkedő találati aránnyal rendelkezik, holott a hozzá tartozó doksik oldalszámösszege a legalacsonyabbak között van. Leegyszerűsítve ez azt jelenti, hogy kevés pénzbe kerül a szerver rá eső költsége, üzleti hozama

azonban kiemelkedő. Ugyan valós bizonyíték nem volt erre vonatkozóan, de a rendszer által logolt kulcsszavakból már régebben is kitűnt. Ez a kimutatás csak megerősíti és bizonyítja, hogy a kulcsszavakra való optimalizálás egy kiváló fejlesztési terület, amit migráció folyamán érdemes kiaknázni. Az ehhez kapcsolódó üzleti logika az alkategória hatékonyság c. fejezet alatt található 5.3 Migráció technikai kivitelezése, új logika implementálása 5.31 A migráció fázisai A költöztetést logikailag elkülönülő blokkonként érdemes kivitelezni. Ez jelen értelmezésben olyan táblákat jelent, melyek kapcsolatban állnak egymással. Migráció alatt szükséges definiálni, hogy milyen megközelítéssel állunk neki a munkának, ami jelen esetben bulk load típusú migrációt feltételez. Illetve érdemes azt is meghatározni, hogy mit értünk kapcsolat alatt. Ha például „A” táblában szerepelnek „B” táblából beágyazott

mezők (nested table), „B” táblában van egy idegen kulcs, melynek forrása a „C” tábla, ugyanakkor C tábla egy mezőjének megváltozása változást idéz elő „D” táblázatban (pl.: egy trigger által) akkor A, B, C és D tábla kapcsolódó. A rendszernaplókat tartalmazó táblák – függetlenül attól, hogy egyéni, vagy rendszer által generált adatokat tartalmaznak – külön migráljuk. A rendszernaplókat azért érdemes külön blokként kezelni, mert lehetnek olyan táblák, amelyek az összes egyéni tábláról adatot gyűjtenek. Az egzakt definíció megfogalmazása ellenére azonban előfordulhatnak olyan esetek, hogy bizonyos táblákról nehéz eldönteni, hogy milyen funkciót töltenek be, illetve, hogy melyik blokkhoz köthetők. Előfordulhat, hogy egy tábla több más blokkal is kapcsolatban áll, ám ilyenből jelen esetben kevés van. 45 Blokkok lehetnek például: • Főkategóriák • Doksik • Indexek • Score • Log

• Hírek • Magántanárok • Felhasználók • Illegális tevékenység • Fórum • Partnerek A következőkben a magántanárok (dok tanar ), főkategóriák (dok fokat), doksik (dok doksik) blokkok migrációjának folyamatát fogom bemutatni. Utóbbi kettőt azért, mert az új logika tesztelésének és implementálásának követelménye az ezeken a táblákon végrehajtott transzformáció. 46 A blokkok alatt található táblák és a hozzájuk kapcsolódó megváltoztatandó mezők a következőképpen néznek ki: Blokk neve Főkategória Doksik Magántanárok Tábla tartalma Főkategória Doksik Táblák nevei dok fokat dok doksik Mezők nevei (MYSQL 5.1) Üzleti igény (Oracle 11gR2) Mezők típusa Mező típusa Extra Extra katid katid int(5) NUMBER(3,0) auto increment sequence dokid dokid int(11) NUMBER auto increment sequence text text VARCHAR(4000) VARCHAR(1000) Naptár dok tanar napt NEM SPECIFIKÁLT! Város

értékkészlet dok tanar varos varosID VarID int(10) NUMBER auto increment sequence Ahol a tanár oktat dok tanar varos1 Változatlan struktúra! Priv. adatok dok tanar tanar vezetek nev teljes nev VARCHAR2(50) kereszt nev VARCHAR2(100) VARCHAR2(50) Láthatjuk, hogy bizonyos mezők automatikus feltöltéséért a MySQL-nél az auto increment, míg az Oracle esetében a sequence felelős. Különbség még, hogy a default értékek meghatározásakor set-ekről (SET(’default1’,’default2’,)), míg Oracle esetében megszorításokról (constraint) beszélünk. Előfordulhat olyan eset, mikor az áttöltött szöveg 47 mezők (VARCHAR) hosszát csökkenteni akarjuk, esetünkben 4000 karakterről 1000 karakterre. Erre azért lehet szükség, mert a felhasználó felület legfeljebb 910 karaktert képes elcsúszás nélkül megjeleníteni. Számos olyan esettel is találkozhatunk (talán ez a legjellemzőbb), mikor a táblákat, blokkokat változatlan

sémában, változatlan adatkörrel migrálunk. Olyan esettel is találkozhatunk, mikor bizonyos blokkok migrálásának követelményeit az üzlet még nem specifikálta. Találkozhatunk bizonyos mezők megszüntetésére, egybevonására, formátumának megváltoztatására vonatkozó igényekkel is. Bár a doksi.hu esetében a migráció viszonylagos egyszerűsége miatt aligha számíthatunk adatbázis replikációs eljárásokkal kapcsolatos igényekre, kritikus rendszerben célszerű ilyen lehetőségekkel élni. Egy esetleges összeomlással járó károk nagy része kivédhető, ha az érzékeny adatainkat egy másik adatbázissal szinkronizáljuk. 48 A következő ábra a teljes migráció magas szintű folyamatát szemlélteti az igények keletkezésétől az élesítésig: Egyeztetés a tulajdonossal a fejlesztések üzleti értékéről és pü.-i forrásokról Főszerkesztő Szerkesztők Látogatók Üzleti igények összegyűjtése specifikálása HLD (magas

szintű specifikáció) Partnerek Részletező specifikáció I. Részletező specifikáció II. Szállítók Meta adatok migrációja Séma, DB architektúra kialakítása Részletező specifikáció III. Hibásan migrált adatkör tesztelése Nem, hiba miatt Adatblokkok migrálása Adott blokk teljes körűen migrálásra került? Nem, lassúság miatt igen Ellenőrző mechanizmusok, triggerek, default értékek, scriptek, constraint stb. beállítása, paraméterezése Validálás Hibajavítás (technikai releaseben) Új funkció alkalmazás oldali fejlesztése Új funkciók működőképességének tesztelése, követelmények meghatározása DB oldalról Unit teszt, Funkcionális teszt, Regressziós teszt User Acceptance teszt (UAT), Regressziós teszt nem Elfogadási kritériumoknak megfelel? igen Élesítés (Go-live) 49 5.32 Alkategória hatékonyság céljainak meghatározása magas szinten Célunk az egyes alkategóriák hatékonyságának

meghatározása a cél rendszerben úgy, hogy a forrásrendszerből a szükséges táblákat, hozzájuk tartozó kapcsolatokat (amennyiben szükséges) kiépítjük, megszorításokat, default értékeket beállítjuk. Új funkciókat mindig a cél rendszerben érdemes kidolgozni, hiszen a régi rendszer DB struktúrája nagy valószínűséggel különbözni fog az új rendszerétől. Az új logikát, adatbázisoldalról fogom bemutatni. Véleményem szerint ennek nagyobb hozzáadott értéke van, mint az alkalmazásoldali kivitelezésnek. Az alkalmazásoldalt jelen esetben a doksi.hu-n – megfelelő jogosultsággal való bejelentkezés (szerkesztők, főszerkesztők) esetében - megjelenő új almenüpontok és a hozzájuk kapcsolódó HTMLriportok jelentik. Másrészről az adatbázis oldali bemutatás követelménye maga a migráció 5.33 Dok doksik tábla létrehozása Hozzuk létre a feltöltött dokumentumok tábláját. A „/*/” karakterek között és „--” karakterek

után kommentként megjegyezésként beszúrtam a mezőkre vonatkozó kritériumokat. CREATE TABLE dok doksik (dokid NUMBER, /* Az egyéni azonosító folyamatos növekvő, így most 99 999 dokumentumot támogat. Migrálás miatt Number a mező típusa, egyébként a doksik darabszámával párhuzamosan folyamatos növekvő */ katid NUMBER(3, 0), /* 3 karakter felvitele lehetséges, ami nem kevés, mert 999 alkategóriáig úgysem jutunk el, mert átláthatatlan lenne a kereső.*/ nev VARCHAR2(200), -- a dokumentum megnevezése 200 karakter hosszú lehet url VARCHAR2(95), -- a fizikai elérésre való hivatkozás maximum 95 karakter lehet leiras VARCHAR2(900), /* Ennyi karakterből álló kulcsszavakat a google még hatékonyan be tud indexelni. Ha ennél több, akkor már nem tud megjelenni a leírás a pop-up-ban és nem látná a google.*/ 50 datum DATE, talalat NUMBER(6), /* 999 999db találatig tudja a letöltéseket megjeleníteni. */ meret

VARCHAR2(11), /* Az oracle kbyte-ban adja meg a fájl méretét. Egy doksi maximálisan 99 999 999 999 kbyte lehet*/ oldalszam NUMBER(6), -- Egy dokumentum oldalszáma 3 karakter, azaz maximum 999 lehet. Ez jelenleg azért 6 karakter, mert későbbi teszt adatok feltöltése folyamán jobban tesztelhető a funkció működése. created DATE, doksi lang VARCHAR2(3) ); Alapértelmezett (default) nyelv magyar. A dokumentumok a megadott értékkészletből vehetnek fel értéket: Alter table dok doksik Modify DOKSI LANG NOT NULL default HU A feltöltött dokumentumok 90%-ban magyar nyelvűek, de találhatóak angol, német, spanyol, latin, olasz, francia, szlovák és román nyelven íródott anyagok is: Alter table dok doksik add constraint doksi cons lang Check (DOKSI LANG IN ( HU, EN, DE, ESP, LA, IT, FR, SK, RO 51 ) 5.34 ); Doksik kategória táblájának létrehozása A dok doksik tábla mintájára létrehozunk egy táblát, ez fogja tartalmazni a kategória

azonosítóját (KATID), a kategória nevét (NEV), a kategória angol nevét (NEV EN), a létrehozás dátumát(DATUM), elérési útvonalát(ELERESI UT). KATID NEV NEV EN DATUM ELERESI UT DOK ID ROWID 1 kat 1 cat 1 2012.1202 url/kat 1 AAADhtAAEAAAAFgAAA 21 kat 21 cat 21 2011.1213 url/kat 21 AAADhtAAEAAAAFgAAB 31 kat 31 cat 31 2012.1217 url/kat 31 AAADhtAAEAAAAFgAAC 41 kat 41 cat 41 2012.1220 url/kat 41 AAADhtAAEAAAAFgAAD 51 kat 51 cat 51 2012.1209 url/kat 51 AAADhtAAEAAAAFgAAE 61 kat 61 cat 61 2012.1229 url/kat 61 AAADhtAAEAAAAFgAAF A táblán igyekeztem úgy kitölteni, hogy az egyes mezők adatai beszédesek legyenek, azaz lehetőleg a név, angol név, elérési út is tartalmazza a kategória azonosítóját. A fenti tábla nem éles adatokkal van feltöltve, célja a dokumentum hatékonyság mögött húzódó logika működésének bizonyítása a cél rendszerben. 5.35 Dok doksik feltöltése teszt adatokkal A következő

táblázatban a tervezett teszt adatokat láthatjuk, amelyek az új logika működőképességét hivatott tesztelni. További 3 segéd oszlop is látható, melyek az egyedi hatékonyságot, súlyozott hatékonyságot, illetve a számunkra igazán érdekes statikus hatékonyság indexet hivatott reprezentálni. Az egyedi hatékonyság a találat (TALALAT) és méret (MERET) hányadosaként kapott arányszám. Azt mutatja meg, hogy 1 oldalszámra hány találat, azaz hány letöltés jut Értéke annál kedvezőbb, minél nagyobb. Minél kisebb egy dokumentum oldalszáma a fajlagos szerverterhelése is annál alacsonyabb. 52 A méret azonban nem az oldalszám függvényében változik, hanem a tartalom típusától (képek, ábrák, szöveg), azonban ez a különbség nagy elemszámú dokumentum esetében kiegyenlítődik. A legkedvezőbb dokumentum számunkra az, amihez a lehető legalacsonyabb szerverterhelés mellett a lehető legnagyobb találat társul. A statikus hatékonyság

index (utolsó oszlop) az egyes alkategóriák alatt található találatösszegek és a hozzájuk tartozó oldalszám-összegek hányadosaként kaphatjuk meg. A súlyozott hatékonysági index az egyes alkategóriák alatt található találat-összegek és a hozzájuk tartozó oldalszám-összegek hányadosaként kapjuk, melyet az egyes alkategórián belül súlyoztunk az oldalszám-összeggel. Ez a hányados azonban pont a lényeget takarja el szemünk elől, hiszen a nagyobb oldalszámú dokumentumokhoz relatív nagyobb találati arányt társít. 6 7 8 9 1 0 1 1 1 2 1 3 1 4 1 5 1 6 1 7 1 8 1 9 2 0 2 1 E 2 E 3 E 4 E 6 X 1 X 2 X 3 X 4 X 5 X 6 tes tesz tesz t1 t te tes tesz tesz t1 t te tes tesz tesz t1 t te tes tesz tesz t1 t 10 10 2010 HU 100,00 100,00 100,00 100 0 100 000 300 1000 2009 HU 0,01 0,00 0,00 10000 0 300 2006 ENG 0,00 1970 HU 13,33 12,20 10,02 200 200 1990 ENG 10,00 100 100 1999 HU 0,10 200 70 70 2001 HU 2,86 2,32

1,40 10 60 60 2010 LA 0,17 30 40 40 2009 IT 0,75 40 30 30 2006 RO 1,33 150 0 170 0 900 0 460 0 470 0 10 22 22 1970 RO 68,18 488,64 10 10 1990 RO 170,00 1356,6 1 5 5 1999 RO 1800,00 3 3 2010 HU 1533,33 4 4 2010 HU 1175,00 40 40 2009 ESP 0,25 0,69 0,11 10 90 90 2006 ESP 0,11 20 240 240 1970 ESP 0,08 11 220 220 1990 HU 0,05 18 210 210 1999 ESP 0,09 22 10 10 2001 HU 2,20 TALALAT DOKSI LAN G 5 te Hatékonyság index, statikus CREATED 4 2010.02 04 2012.03 03 2010.04 05 2011.03 04 2009.08 08 2001.03 03 2000.04 06 2012.12 24 2009.12 04 2007.11 23 2008.12 04 2007.11 06 2008.12 27 2001.09 12 2000.12 12 2003.03 04 2005.08 09 2007.08 20 2010.07 27 2003.03 04 2011.03 04 Haté konyság index (súlyozott) OLDALSZA M 3 t Egyedi hatékonyság MERET 2 1 2 1 3 1 3 1 3 1 4 1 4 1 4 1 4 1 5 1 5 1 5 1 5 1 5 1 6 1 6 1 6 1 6 1 6 1 6 1 url /a url /b url /b url /c url /c url /c url /d url /d url /d url /d url /e

url /e url /e url /e url /e url /x url /x url /x url /x url /x url /x DATUM 2 A 1 B 1 B 2 C 1 C 2 C 3 D 1 D 2 D 3 D 4 E 1 LEIRAS 1 URL 1 NEV DOKID KATID 53 100 0 10 150 400 0 200 0 10 A táblázat alapján feltöltjük a tesztadatokkal a dok doksik táblát. INSERT into dok doksik VALUES (1, 1, A 1, url/a, (2010/02/04,YYYY/MM/DD), t, to date 1000, 10, 10, to date 54 (2010,YYYY), HU); INSERT into dok doksik VALUES (2, 21, B 1, url/b, (2012.0303,YYYY/MM/DD), (2009,YYYY), HU); te, to date 10, 1000, 1000, to date INSERT into dok doksik VALUES (3, 21, B 2, url/b, (2010.0405,YYYY/MM/DD), (2006,YYYY), EN); tes, to date tesz, to date 150, 100000, 100000, to date INSERT into dok doksik VALUES (4, 31, C 1, url/c, (2011.0304,YYYY/MM/DD), (1970,YYYY), HU); 4000, 300, 300, to date -- ennek mintájára töltjük be a 21 teszt rekordot A táblázat tesztadatokkal való feltöltése folyamán problémaként jelentkezett a dátumok

betöltése a táblába. A to date(’20100405’,’YYYYMMDD’) utasítással azonban a bemeneti adatok dátum formátuma pontosan meghatározható. A 21 rekord adatokkal való feltöltése manuálisan sem vesz sok időt igénybe. Éles adatokkal való feltöltése esetén közel 17000 rekordról beszélünk, ilyenkor a manuális feltöltés kizárható. 5.36 Alkategória hatékonyság Az alkategória hatékonyságának meghatározásához már minden szükséges teszt adat megtalálható az Oracle adatbázisban. A következő Select-tel tudjuk meghatározni az egyes alkategóriák hatékonyságát: 55 SELECT a.arany as "Hatékonyság index", f.nev as "A kategória neve", a.katid as "A kategória azonosítója" FROM (SELECT SUM( dok doksik.talalat ) / SUM( dok doksik.oldalszam ) AS arany, dok doksik.katid FROM dok doksik GROUP BY dok doksik.katid) a, dok fokat f WHERE a.katid = fkatid A kapott végeredményt összehasonlítjuk a teszt adat

táblázatának „Hatékonyság index (statikus)” oszlopával, akkor ugyanazt az eredményt kaptuk. A végeredményt a következő táblázat tartalmazza: Hatékonyság index A kategória neve A kategória azonosítója 100 kat 1 1 0,002 kat 21 21 10,017 kat 31 31 1,4 kat 41 41 488,636 kat 51 51 0,112 kat 61 61 56 A fenti grafikonon látható, hogy kat E nevet kapó kategória messze a legnagyobb oldalszámarányos találattal rendelkezik, míg a kat B a legkisebb találati aránnyal rendelkezik. 5.37 Alkategória hatékonyság további fejlesztési lehetőségei A select nem veszi figyelembe azt, hogy a régebb óta elérhető dokumentumok magasabb találati aránnyal rendelkezhetnek, mint az újonnan felkerülők. Ennek kiegyenlítésére célszerű lehet az eltelt napok számával súlyozni a fent lévő dokumentumokhoz rendelt hányadost. Ez által a kapcsolódó kategóriához tartozó hatékonyság index is már súlyozott formában fog szerepelni.

Vannak kiemelt kulcsszavak, amire érkező látogatók értékesebbek. Ilyenkor ehhez is társítható egy arányszám. A tőzsde, gazdasági jog, építészet, erotika, biztosítás témájú dokumentumok például nagyobb aránnyal fognak rendelkezni, míg az antropológiai dokumentumok kevesebbel. A letöltött dokumentumokat a látogatók neme, kora és lakhelye szerint is szegmentálni lehet, hiszen egy Budapesten élő, aktívan kereső férfi nagy valószínűséggel értékesebb (marketing szempontból), mint egy vidéken élő, középiskolában tanuló lány. 57 Függetlenül attól, hogy milyen módon veszünk figyelembe bizonyos marketing szempontokat, célszerű mindig kimutatásokból meggyőződni az új funkciók vélhető sikerességéről. Sok esetben új logikák implementálása annyira csekély üzleti értékkel rendelkeznek, hogy kivitelezésük aránytalanul magas költséget jelent a várható haszonhoz képest. Azaz célszerű mindig az üzleti érték

arányában mérlegelni a fejlesztéseket 5.38 Éles adatokkal való feltöltés módszerei, nehézségei Célunk a lehető leggyorsabban és legegyszerűbben feltölteni dok doksik és dok fokat táblákat. PhpMyadminon keresztül az egyes lekérdezéseket a következő formátumok egyikébe kell exportálnunk: • CSV (legelterjedtebb formátum exportáláskor) • MS Excel CSV adat (Angol nyelvű excelbe exportáláskor) • Microsoft Word 2000 • MediaWiki Table (Wikipedia által használt formátum a táblák megjelenítésére) • Open Document munkafüzet (OpenOffice tudja kezelni) • Open Document szöveges dokumentum (OpenOffice tudja kezelni) • PDF (lekérdezések prezentálására kiváló, nem módosítható) • PHP array • Texy! szöveg • Excel 97-2003 XLS Workbook • Excel 2007 XLSX Workbook • SQL (SQL formátumban exportált fájl esetén lehetőségünk van a fájl PL/SQL Developerben scriptként való megnyitására)

(wiki.phpmyadminnet, 2012) Kézenfekvő megoldásnak tűnt Oracle kompatibilis módban SQL-be exportálni az adatállományt, majd azt szkriptként megnyitni a következőképpen: 58 Ezzel az a probléma, hogy INSERT utasítás kiadásának szempontjából helytelen szintaxisba exportálja ki a PhpMyadmin a szükséges táblát. Ezen probléma kiküszöbölése helyett jobbnak láttam inkább excelbe exportálni a kívánt táblákat, majd kialakítani a helyes nyelvezetet a következő féleképpen: INSERT INTO dok fokat (katid, nev, nev en, datum) VALUES ( 1 9 , Angol nyelv , English language , to date( 200 5.04 .20 , YYYY.MMD D)); INSERT INTO dok fokat (katid, nev, nev en, datum) VALUES ( 1 9 , Közép iskola , High school , to date( 200 5.04 .20 , YYYY.MMD D)); INSERT INTO dok fokat (katid, nev, nev en, datum) VALUES ( 1 9 , Infor matik a , Informatio n Technolog y , to date( 200 5.04 .20 , YYYY.MMD D)); INSERT INTO dok fokat (katid, nev, nev

en, datum) VALUES ( 1 9 , Nyelv izsgák , Language exams, tests , to date( 200 5.04 .20 , YYYY.MMD D)); INSERT INTO dok fokat (katid, nev, nev en, datum) VALUES ( 1 9 , Bioló gia , Biology , to date( 200 5.04 .20 , YYYY.MMD D)); 5.39 External Tables Az external table (külső tábla) lehetőséget biztosít, hogy az adatbázison kívüli fájl adatait az adatbázisban tárolt adatokhoz hasonló módon felhasználjuk a lekérdezéseink folyamán. Az Oracle 9i verziója csak read-only műveleteket támogat, míg 10g-t követő verzióknál már ki 59 lehet írni adatokat külső táblákba. Ezeken a külső táblákon DML utasítások azonban nem futtathatók (UPDATE, INSERT, DELETE). (Natalka Roshak, 2006) Az, hogy mely fájlok támogatottak külső táblaként való felhasználáskor az mindig az access driver függvénye. Az alapértelmezett driver az ORACLE LOADER, amely mappelő funkciót tölt be. A másik driver az ORACLE DATAPUMP nevet kapta,

segítségével a lekérdezett adatokat külső fájlokba menthetjük el, majd ezeket akár vissza is tölthetjük az adatbázisba. A következő példában látható, hogy milyen logika alapján használhatunk külső táblákat migráláskor. A következő ext teszt1dat text fájl tartalmazza a következő adatokat (a teszt adatok táblázat sémája alapján): A 1, url/a, t, 2010.0204 B 1, url/b, te, 2012.0303 B 2, url/b, tes, 2010.0405 C 1, url/c, tesz, 2011.0304 A követkető ext teszt2.dat text fájl tartalmazza az alábbi adatokat: C 2, url/c, teszt1, C 3, url/c, t, 2009.0808 2001.0303 D 1, url/d, te, 2000.0406 D 2, url/d, tes, 2012.1224 60 A következő SQL utasítással készítünk egy external table-t, ami az admin ext teszt1adat nevet kapja a sysadmin sémában, majd betöltjük az adatokat a dok doksik ext táblába. CONNECT / AS SYSDBA; -- Címtárat készítünk és hozzárendeljük a sysadmin-t CREATE OR REPLACE DIRECTORY admin dat dir AS

/flatfiles/data; CREATE OR REPLACE DIRECTORY admin log dir AS /flatfiles/log; CREATE OR REPLACE DIRECTORY admin bad dir AS /flatfiles/bad; GRANT READ ON DIRECTORY admin dat dir TO sysadmin; GRANT WRITE ON DIRECTORY admin log dir TO sysadmin; GRANT WRITE ON DIRECTORY admin bad dir TO sysadmin; -- A sysadmin azonosítóval belépünk CONNECT sysadmin -- External table készítése CREATE TABLE dok doksik ext (nev url leiras datum VARCHAR2(200), VARCHAR2(95), VARCHAR2(900), DATE ) ORGANIZATION EXTERNAL ( TYPE ORACLE LOADER DEFAULT DIRECTORY admin dat dir ACCESS PARAMETERS ( records delimited by newline badfile admin bad dir:ext teszt%a %p.bad logfile admin log dir:ext teszt%a %p.log fields terminated by , 61 missing field values are null ( nev, url, leiras, datum ) ) LOCATION (ext teszt1.dat, ext teszt2dat) ) PARALLEL REJECT LIMIT UNLIMITED; /* A párhuzamos betöltést is beállíthatjuk, ez abban az esetben hasznos, ha rendkívül sok adatot töltünk be */ ALTER

SESSION ENABLE PARALLEL DML; -- Betöltjük az adatokat a dok doksik ext táblázatba INSERT INTO dok doksik ext (nev, url, leiras, datum) SELECT * FROM admin ext teszt1adat; (Oracle Database Administrators Guide 11g R2, 2011) 62 5.310 Adatbázis migráció módszertani áttekintése 63 A fenti folyamatábrához szükséges tisztázni néhány alapfogalmat. A karakter kódolási hibák konzisztencia vizsgálata azt a tevékenységet foglalja magában, mikor leellenőrizzük, hogy az egyes karakterek konzisztens módon térnek el a kívánt karakterektől. (pl: Műanyagok felhasználása: ű = ű, á = á) Ez jellemzően ékezetes betűknél keletkező eltéréseknél járható út, kizárólag kis elemszámú táblákban és akkor is korlátozott módon. Az esetek túlnyomó többségében célszerű inkább a helyes karakterkódolási módot kiválasztani. Adatállomány hibáinak konzisztencia vizsgálata az adattisztítás fejezet alatt kerül kibontásra. Fontos

tisztázni, hogy a migrációs folyamatban minél több rendszert használunk annál inkább nő a hiba lehetőségek kockázata, ezért ezt célszerű minimalizálni. Lehetőleg az adatokat minél kevesebbszer költöztessük a cél rendszerből való kinyerés és forrás rendszerbe költöztetés között. 64 5.3101 A betöltés folyamata 65 5.4 Adattisztítás Egyre több szervezet tulajdonít nagy jelentőséget a megfelelő tisztaságú adatoknak. Sokszor ugyanis redundánsan vannak tárolva az adatok, az esetleges változások pedig nem érintik konzisztens módon a duplikált adatokat, így nehéz utána járni, hogy melyik adat valós. Ennek következtében az üzleti területek sincsenek megfelelő módon napra kész, releváns adatokkal ellátva. Emellett az informatikai üzemeltetés számára is plusz tevékenységet jelent ezek kezelése, további terheket ró a vállalatra az irreleváns adatok tárolása következtében keletkező tárhely igény. (Mártonffy

Attila, 2010) Az adattisztaság iránti érzékenységet a piaci verseny is táplálja, hisz egyre kevésbé tolerálj a a hibás információkon alapuló új szolgáltatást és terméket. (Clarityhu, 2007) Az adatminőségbeli problémák jellemzően integrált adatgyűjteményekben, például adattárházakban, központosított adatbázis rendszerekben, web alapú információs rendszerekben keletkeznek. (Mártonffy Attila, 2010) Adatminőségű problémák keletkezésének okaként szokták emlegetni a rendszerek migrációját is. Ilyenkor a legfőbb problémát azt jelenti, hogy az részleteiben nem hangolják össze a migrációs folyamatokat, nem rendelkeznek sztenderdizált eljárásokkal. (Mártonffy Attila, 2010) 5.41 Adatminőségi problémák keletkezéseinek okai, jellegzetességei banki rendszereknél Általánosságban elmondható, hogy egy rendszer minél több adatot tárol, annál nagyobb a hibalehetőség. Ez azonban korántsem ilyen egyszerű, hisz az

adatokat például bankok esetében különböző alkalmazásokon keresztül, különböző szaktudású emberek veszik fel, míg más esetekben az adattisztaságra vonatkozó elvárások szinte 100%-ban betarthatóak. Ilyenek jellemzően a kevés manualitás adatrögzítést igénylő rendszerek. Előfordulhat olyan eset, hogy egy Magyarországon tevékenykedő bankra költségoptimalizálási céllal ráerőltetnek egy, az anyabank által fejlesztett rendszert, ami eredetileg az ’anya’ működéséből fakadó specifikus igényeket hivatott kiszolgálni. Ilyen eszközök lehetnek például számlevezető rendszerek, hitelnyilvántartó rendszerek, audit alkalmazások, minőségbiztosítási eszközök, könyvelő szoftverek. Az ilyen rendszerek 66 átvétele sosem mentes a kompromisszumoktól, a kliens és adatbázis-oldali adatfelviteli és adattárolási mechanizmusokat is hozzá kell igazítani a magyar igényekhez. Ez a hozzáigazítás sokszor bonyolult

pénzügyi és üzletviteli folyamat-szabályozási kérdéseket vet fel, amiknek megfelelni nem lehet teljes egészében (vagy csak irreális költségvonzat mellett). Ilyenkor gyakran a legtöbb területre kiterjedő problémákat járják körbe, például, ami lefedi az üzleti problémák 90%-át. A maradék 10% pedig bonyolult adatintegritási és adattisztasági problémákat eredményez, amiket részben az adattisztítás folyamán kell körbejárni. (Fábián, 2012) Az, hogy mely rendszerek átvétele ajánlott az mindig menedzsmentkérdés, hiszen ilyenkor licenc díjfizetési szempontokat és jogszabályi megfelelőséget is vizsgálni kell. Sok esetben a rendszerek logikus és könnyű paraméterezhetősége is kulcsfontosságú. Ha belegondolunk egy esetleges áfa emelés a legtöbb pénzügyi rendszerre kihat. Integrált rendszerek esetében célszerű úgy kialakítani az elszámolási logikát, hogy ne kelljen minden folyamatot újra feltérképezni. Ez ugyanis sok

idő, sok pénz és sok stressz (Fábián, 2012) Bankok esetében hibás adatnak minősülnek az elírt telefonszámok, elírt utcanevek, hiányos egyéb adatok, elírt bankszámlaszámok, hiányos kapcsolattartó adatai, hibás termékjellemzők stb. Ezek ellen sok esetben lehet védekezni, például a helytelenül beírt utcanevek helyett az ügyintézőt az első karakterek beírását követően egy felugró ablak segítheti a megfelelő utca kiválasztásában. Ahhoz, hogy ez a funkció működjön, célszerű a minisztériumi vagy postai címtörzs adatbázisát megszerezni és így támogatni az ügyfélnyitás folyamatát. A telefonszámok esetében az első 2 számjegy alapértelmezett értékként 20, 30, 60 illetve 70 lehet, illetve célszerű a karakterek hosszának ellenőrzésére is ellenőrző funkciót beállítani. Cél, hogy a lehető legtöbb ellenőrző mechanizmus be legyen építve a rendszerünkbe, ezzel is csökkenthetjük az utólag jelentkező

adattisztítási és tárolási költségeket. (Fábián, 2012) Az adattisztaság megőrzése érdekében a különböző azonosító számokat úgy alakítják ki, hogy az utolsó számjegy ellenőrző funkciót töltsön be. Adóazonosító jel, személyi szám esetében mindig, főkönyvi számlaszámok esetében (nagyvállalatoknál) sok esetben működik ez az ellenőrzés. (Ok: adóazonosító jel, személyi szám kiosztása törvényileg szabályozott, főkönyvi számlaszámok kiosztására azonban csak ajánlás létezik.) 67 Banki rendszerek esetében a különböző adatbázisokban szereplő adatokat célszerű integrálni egy közös törzsadatbázisba, elkerülve ezzel a duplikátumokat. Ezzel az adatokat lényegesen rövidebb idő alatt lehet módosítani, mint abban az esetben, amikor az adatok számos különböző rendszerben találhatóak. 5.411 Manuális adattisztítás A manuális adattisztítást olyan esetekben célszerű elvégezni, amikor az adathibák

javításának módja nem kivitelezhető programozott eljárásokkal, vagyis az adathibák jellege nem konzisztens. Ilyen esetekben általában egyedileg kell utánajárni a problémának, fel kell venni a kapcsolatot az ügyféllel, partnerrel. Előnye, hogy az így javításra kerülő információk nagy valószínűséggel megbízhatóak, az információgyűjtés ideje alatt marketing szempontok is érvényesíthetőek (pl.: felhívják az ügyfél figyelmét új termékekre) Hátránya, hogy az ügyfélhez / partnerhez kapcsolódó valamennyi hibás, vagy hiányos adatról tudnunk kell, hiszen a többszöri felkeresés visszás lehet. A manuális adattisztítás megkerülhetetlen a kritikus infrastruktúrák esetében. (Fábián, 2012) 5.412 Automatizált adattisztítás Automatizált adattisztításról akkor beszélhetünk, amikor az adatok hibáinak jellege jól körülírható, programozott eljárásokkal (scriptekkel) javítható. Ilyen adathiba lehet például egy magyar

ügyfél címadataiban a „Budapest” elgépelése, amennyiben 1 karakterben tér el a helyes értéktől. Bonyolultabb megoldást igényelhet, amikor az irányítószám, település neve, település típusának értékei közül egy rosszul van felvéve. Ebben az esetben ugyanis bármely két érték helyes megléte esetén nagy eséllyel tudunk helyesen következtetni a harmadik értékre. Ellenőrzést mindig a legfrissebb minisztériumi felhasználásával érdemes futtatni. (Fábián, 2012) vagy postai címtörzs adatbázis 68 Az alábbi folyamat egy adattisztításra használható script lehetséges működését mutatja be: Hibás adat logolása Hibás adat nem Adott közterület neve egy betűben tér el az adott irányítószámhoz rendelhető értékkészlet elemeitől? nem igen Javítás az adott közterület nevére nem Az adott irányítószám tartozhat a településhez? Adott közterület neve és jellege tartozhat az adott irányítószámhoz?

igen igen Helyes adat nem Település neve egy betűben tér el az adott irányítószámhoz rendelhető települések neveitől? igen Javítás az adott településre nem Irányítószám értéke egy számban tér el az adott településhez tartozó irányítószámoktól? igen Javítás az adott irányítószámra Beszélhetünk olyan esetről is, amikor bizonyos ügyfél, vagy termék adatok duplikáltan, illetve multiplikáltan szerepelnek különböző rendszerekben, ráadásul az adatokban eltérések tapasztalhatók. Ilyen esetekben automatizmusokkal ki lehet szűrni, hogy mely adatok elavultak. Egy PL/SQL eljárás (procedure) például megnézheti, hogy a duplikált adatok között melyiket hozták létre utoljára (pl.: úgy hogy a SYSDATE-ből kivonja a létrehozás dátumát) és a helyes értékkel frissíti az régi mezőket. 69 Automatizáltan tisztított adatok esetében fontos szempont, hogy csak a jól paraméterezhető hibákat javítsuk és (az adatok

jellegétől függően) a helytelennek vélt adatokat is őrizzük meg egy ideig. 5.42 Adatminőségi problémák jellege a doksi.hu-nál A dokumentumok leírása alapvetően a dokumentumokban való keresést segíti elő. A doksi.hu esetében hibás adatnak minősülhet egy dokumentum leírásában található szöveg abban az esetben, ha az lényegesen meghaladja az 1000 karaktert, vagy 19 sort. Ilyenkor a felhasználói felület szétcsúszhat, továbbá a látogatókat sem érdekli a leírásban szereplő többletinformáció. Adatminőségi problémának minősülnek továbbá a leírásban szereplő különleges karakterek. Alkalmazás oldalról a következő eljárások biztosítják az adatminőség fenntartását (a teljesség igénye nélkül): Új dokumentumok felvitele: • Dokumentum megnevezése nem lehet több x karakternél • Kötőjelek használatával a szerzők külön adatbázis mezőkbe mentődnek el • Fájlfeltöltés csak .rar kiterjesztéssel

megengedett • Készült év: csak szám lehet, 4 karakter hosszú (dokumentum megnevezéséből származtatódik) • Oldalszám: értéke minimum 1, maximum 999 lehet (dokumentum megnevezéséből származtatódik) • Nyelv: alapértelmezett magyar • Adatbázis oldalon futó duplikátum ellenőrzés Magántanár adatlap: • E-mail cím felviteli mező: egy „@” jel a felviteli karakterkészlet minimum követelménye. Ha nincs „@” jel, akkor hibaüzenetet kap a felhasználó • (E-mail cím megjelenítési mező: „@” jel maszkolva van, hogy internetes robotok ne tudják spam-eléshez felhasználni) • Gyakorlat: szám formátum 70 • Otthonában oktat, házhoz megy, csoportot vállal, távoktatást vállal, számlaképes mezők csak igen / nem értéket vehetnek fel • Oktatási helyszínek: megadott értékkészlet alapján választható értékek (magyarországi kerületek) • Oktatott tárgyak: megadott értékkészlet alapján

választható értékek • Oktatott tárgyak szintje: megadott értékkészlet alapján választható értékek (alapszint, középszint, magasszint) • 5.43 Egy felhasználó csak egy tanári adatlapot hozhat létre Migrációs és adattisztítási projektek Magyarországon Miután 2004-ben az Erste Bank Rt. megvásárolta a Postabankot, az Erste Symbols számlavezető rendszerébe kellett költöztetni a Postabank ügyféladatait. Első lépésben a lakossági szegmensbe tartozó ügyféladatok kerültek migrálásra. A projekt során a régi adatokon véghezvitt transzformációt kellett megtervezni és kivitelezni, migrációs eljárárásokat kellett kidolgozni és programozni (procedural approaches) Oracle-adatbázisban. (Gergely Ferenc, 2005) 2004-ben az Erste a Postabank valamennyi számlavezető rendszerének, azaz • a lakossági forint számlavezető, • a lakossági és vállalti deviza számlavezető, • a lakossági hitelszámla vezető, • a vállalati

forint számlavezetést és vállalati hitelszámla vezetést végző számlavezető rendszerek migrációját egy lépésben tervezte. A feladat komplexitásából fakadóan azonban ezt két fázisra bontották fel. (Papp Ferenc Gábor, 2005) „2006-ban a Clarity Consulting adattisztítási módszertant dolgozott ki az Országos Egészségbiztosítási Pénztár számára nyilvántartó rendszere (Társadalmi Azonosító Jel / Bejelentett Személyek Jogviszony adatai) megbízhatóságának növeléséhez.” A rendszer 12 millió TAJ-számot, illetve 50 millió jogviszonyhoz kapcsolódó adatot tartalmazott. A feladat a két adatcsoport adattisztasági szempontból való elemzése és 71 értékelése volt. Ezt követően automatikus scriptekkel lett javítva az adatállomány minősége (Lengyel Sándor, Istvanovszki Mihály, 2007) 2003-ban került bevezetésre a BNP Paribas Hungária Bank Zrt.-nél egy integrált számlavezető rendszer. Itt a tanácsadó cég részéről a

munka nagy részét a banki interfészek (OMR, SWIFT, VIBER, GIRO, EB, CATI) és helyi rendszerek összeillesztése jelentette. Ezen felül még tesztstratégia készítése, tesztkörnyezet felépítése, funkcionális tesztelés tette ki a munka nagy részét. (Lengyel Sándor, Villarroel Hektor, 2003) 2004-ben az Invitel célja az ügyfél-adminisztrációs, számlázási és folyószámlavezető rendszereinek integrálása, migrációját elősegítő egységes ügyféltörzs kialakítása adattisztítási feladatok ellátása volt. A projekt céljai között szerepelt az ügyfélkapcsolati és számlázó rendszerekben található adatok minőségének felmérése, kijelölt ügyfél- és ügyfelekhez kapcsolódó adatismétlődések, redundanciák vizsgálata. (Csordás Ákos, 2004) A Vodafone Magyarország Zrt. a Sysman Informatikai Zrt-t bízta meg a „Design and implementation of the new architecture of Phoenix production and PET systems” nevet kapó projekt

kivitelezésével. A projekt középpontjában az üzletileg kritikus UNIX alapú számlázási rendszer architektúrájának váltása ált. A projekt mérföldkövei a következők voltak: • Aktuális helyzet felmérése • Operációs rendszer verzióváltása a tesztrendszerben • Operációs rendszer verzióváltása az éles környezetben • Éles rendszerhez kapcsolódó architektúra tervek kidolgozása • Éles üzemben működő Phoenix rendszer migrációja az új hardverekre • Teszt rendszerhez kapcsolódó architektúrák terveinek kidolgozása • Új teszt környezet kialakítása az új hardvereken 72 A migrációhoz kapcsolódóan a Sysman a következőket teljesítette: • Migrációs terv kidolgozása • Rollback terv (visszaállási terv) kidolgozása • Migrációhoz kapcsolódó döntés előkészítés, migrációs módjának meghatározása • Éles környezet kialakítása • Interfészeken a kapcsolódó paraméterek

feltérképezése • Migrációs tevékenységek kivitelezése, támogatása 5.5 Banki rendszerek vs doksihu adatbázisa A doksi.hu adatbázis-migrációhoz kapcsolódó logikájának kidolgozásakor számos olyan szempontot nem vettem figyelembe, amely alkalmazása banki rendszerek migrálásakor elengedhetetlen. A doksi adatbázisa sokkal inkább terhelhető rosszul megírt lekérdezésekkel, mint egy banki architektúra. Ennek-, illetve a kritikus infrastruktúrára vonatkozó követelmények következményeként más módszertan helyén való. Kritikus infrastruktúrákban, jellemzően banki rendszerek esetében komoly kihívást jelent a hibás adatok programozott feltérképezése, módosítása és törlése. Amikor ugyanis egy termékjellemzőt, vagy ügyfél adatot akarunk törölni (függetlenül attól, hogy manuálisan tesszük, vagy egy PL/SQL scriptel), akkor maga a törlés több, adatbázis motor által végrehajtott ellenőrző folyamaton is végig fog menni. Ez az

ellenőrző funkció annál hosszabb, minél több tábláról, minél több kapcsolatról (idegen kulcsról), megszorításról (constraint), esetleg triggerről beszélünk. Azaz általánosságban elmondható, hogy minél bonyolultabb egy adatbázis architektúra annál több időbe telik az adatok konzisztens manipulálása. Fontos tudni, hogy egy-egy kiadott SQL milyen tranzakciókat generál az adatbázismotor által, hiszen egy rekord törlése az idegen kulcsokon keresztül számos táblát érinthet. A táblákon elhelyezett megszorítások további korlátozó feltételt jelentenek, amit az adatbázis motornak le kell ellenőriznie. (Fábián, 2012) A doksi adatainak transzformálását PL/SQL memóriatáblákkal, vagy más néven gyűjtőtáblák használatával is lehet támogatni. Ezek olyan memóriában tárolt táblák, melyek adatai listaszerűen, tömbszerűen vannak elrendezve, ahol a gyors keresést BINARY INTEGER 73 elsődleges kulcs biztosítja az

indexeléshez. Mivel a táblák mérete korlátozatlan, ezért valójában egy fájlkezelési mechanizmus tartozik hozzájuk a háttérben. A sok adatot tartalmazó táblák nem megfelelő használata jelentősen megnövelheti a transzformáció végrehajtási idejét, ami egy banki rendszer migrálásakor kritikus lehet, a doksi esetében azonban kevésbé lényeges. (Kende Mária, 2002) 5.51 Jobok Banki adatbázisokban számos ellenőrzési funkció is működik, amit jobokba szerveznek. Ezek futása általában szerverigényes feladat, működésüket meg kell szervezni. Számos ilyen job fut a doksinál. Az illegális tevékenységet folytató felhasználók tevékenységeihez kapcsolódó adatokat folyamatosan logolja a DB, majd ezek egy idő elteltével archiválásra, majd megőrzésre kerülnek. Az ehhez hasonló jobok futását azonban kevésbé kell szervezni, elég ha éjszaka lefutnak. Másik ilyen job a dokumentumok előnézettét generáló script, ami meghatározott

időkben (alacsony látogatottság mellett) fut és kinyeri a dokumentumok első 10 oldalát, hogy aztán felkínálja a google-nek indexelésre – természetesen a különleges karakterektől és irreleváns adatoktól megtisztítva. Ennek a futása szerverigényes feladat, a már fent lévő anyagok esetében néhány nap alatt generálja le az előnézetet. A heti rendszerességgel felkerülő dokumentumok esetében pedig a feltöltést követő éjszaka kerülnek feldolgozásra. 74 6 Tesztelés A legtöbb vállalat a tesztelésre nem szán megfelelő minőségű és mennyiségű erőforrást. Sokszor elbagatellizálják a tesztelés fontosságát, holott komplex rendszerek esetében a tesztelés nagyságrendileg a fejlesztés felét is kiteheti, migrációs projektekben még többet is. (Fábián, 2012) 6.1 Típusok Unit teszt: A tesztelés ezen szakaszában a fejlesztő egyes programegységek működését ellenőrzi kódrészek kiemelésével. Erre azért van szükség,

mert sokszor folyamatosan változó scope mellett kell tevékenykedni a programozóknak, ráadásul az egyes funkciókon akár többen is dolgozhatnak. Sokszor az üzleti területek a funkciók működésére vonatkozó követelményeket nem határozta meg, vagy hibásan specifikálták. (Döbrentei István, 2011) Migrációs szempontból az unit tesztekkel ellenőrizni lehet, hogy a program a megfelelő adatokat a megfelelő helyen dolgozza e fel, továbbá ellenőrizhető, hogy a megfelelő adattranszformációs eljárások futottak e le. (Kartikey Brahmkshatriya, 2007) Funkcionális teszt: fekete doboz módszer, melynek lényege a részletező üzleti követelményben leírtaknak való megfelelés. A tesztelő nem ismeri az alkalmazás programozási logikáját. Funkcionális tesztesetek írásakor érdemes arra törekedni, hogy a lehető legtöbb hibát felleljük, illetve törekedjünk a lehető legszélesebb körben lefedni az alkalmazás működését. A tesztesetek írásakor

figyelembe vehetjük a jellemző működést, így magasabb prioritást szentelhetünk a jellemző folyamatokra. Regressziós tesztelés során célszerű előre definiált teszteseteket futtatni az egyes Releaseekben, ellenőrizni tudjuk ezáltal, hogy az új funkciók működése nem akadályozza-e a régebben fejlesztett funkciók működését. Ez jellemzően a komplex jogosultságkezelési mechanizmusokkal támogatott rendszereknél hasznos. Regressziós teszteléskor célszerű lehet release-enként a teszteseteket frissíteni. Ahogy haladunk a szoftverfejlesztési folyamatban, az egyes teszteseteket folyamatosan frissítjük az új funkciókra vonatkozó elvárásokkal. (enwikipediaorg, 2012) 75 User acceptance teszt során a végfelhasználó szemüvegén keresztül ellenőrizzük a rendszer működését, a ’kis’ funkciók helytelen működése akkor releváns, ha az a teljes folyamat helytelen működését eredményezi (azaz sokkal inkább folyamatszemléletű).

Ilyenkor célszerű a végfelhasználókat is bevonni a tesztelésbe. A következő ábrán láthatjuk a tesztelés folyamatát: Teszt csapat megismeri a specifikációban leírt követelményeket Üzleti követelmény specifikációk Traceability matrix (nyomonkövetési diagram) Magas szintű követelmény specifikáció (HLD, High level design document) Tesztelési tervet (test plan) készít Követelmény ellenőrzése (requirement testing) Teszt esetek, sql lekérdezés írása Tesztelés módszertanának meghatározása, előkészületek Unit teszt (Unit testing) Funkcionális teszt (Functional testing) Teszt kivitelezése Regressziós teszt (Regression testing) Teljesítmény teszt (performance testing) User acceptance testing (UAT) (Kartikey Brahmkshatriya, 2007) 6.2 Teszt automatizálás Célszerű olyan esetekben automatizálni, amikor nagy esetszámú tesztesetet tudunk ellenőrizni és erre bizonyos időközönként szükség is van. Teszt automatizálás

történhet a nested table segítségével, ilyenkor egy külső fájlban létrehozunk egy táblázatot, ami a teszteset paramétereit tartalmazza. Ilyenkor célszerű úgy megírni a scriptet, hogy az új funkciók fejlesztéséhez kapcsolódó új paramétereket 76 dinamikusan tudja a későbbiekben kezelni. Így kerülhető el, hogy a release-enként tesztelést végző scriptet újra kelljen írni. Tesztautomatizáláshoz különböző alkalmazások is léteznek. Teszt automatizálás input adatainak meghatározásakor akadályba is ütközhetünk. Ha a tesztelés folyamán sok ellenőrzési mechanizmus is fut a mezőkre vonatkozóan, akkor könnyen lehet, hogy egy-egy teszteset nem tud lefutni a bemeneti adatokban (paraméterekben) fellelhető ellentmondás miatt. Banki rendszerek migrációjának ellenőrzésekor pl, ha az ügyfelekhez kapcsolódó adatokat ellenőrizzük, akkor a legegyszerűbb (ám kevésbé hatékony módszer), ha megnézzük, hogy az összes rekord

átment e. Ha például a személyi számokat összeadjuk, és a végeredmény megegyezik a forrásrendszerbeli végeredménnyel, akkor biztosak lehetünk, hogy sikerült erre az adatkörre a migráció. Lényegesen bonyolultabb megoldást jelenthet, ha maga a migráció futása alatt akarunk valós időben automatizáltan tesztelni. Ilyen funkciót tölt be az ORACLE LOADER csomag, hiszen segítségével logolásra kerülnek a hibásan, vagy nem betöltött adatállományok. Ezen információk felhasználásával a migráció ideje alatt is riportolhatunk. Lényegében lehetőség nyílik a migrációs folyamatok valós idejű monitorozásra és ezeket felhasználhatjuk különböző PL/SQL eljárások írása folyamán is. 77 7 Irodalomjegyzék (dátum nélk.) Forrás: erpfanblogspothu: http://erpfanblogspothu/2009/10/az-oracletortenetehtml (2007). Forrás: Clarityhu: http://wwwclarityhu/site/hu/services/descriptionphp?id=71 (2009). Forrás: datamigrationprocom:

http://wwwdatamigrationprocom/data-migrationarticles/2009/3/26/the-data-migration-go-live-strategy-what-is-it-and-why-doeshtml (2011). Forrás: informaticacom: http://wwwinformaticacom/us/vision/harnessing-bigdata/oltp-and-analytics/ (2011). Forrás: Oracle Database Administrators Guide 11g R2: http://docs.oraclecom/cd/E11882 01/server112/e10595/tables013htm (2012). Forrás: zoominfocom: http://www.zoominfocom/#!search/profile/company?companyId=11141461&targetid=profil e (2012). Forrás: wikiphpmyadminnet: http://wikiphpmyadminnet/pma/export#PHP Array allroundautomations.com (2012) Forrás: http://wwwallroundautomationscom/ Boglárka, R. (2009) wwwtechnethu Forrás: Híres cégnevek meglepő története: http://www.technethu/hir/20090918/undorito lenyek es mar furcsasagok/ Clarity.hu (2012) Forrás: http://wwwclarityhu/site/hu/about us/consultantphp?id=60 Colleen Graham. (dátum nélk) Forrás: Market Share, All Software Markets, Worldwide 2011:

http://www.oraclecom/us/products/database/number-one-database-069037html Coulam, B. (2001) http://wwworafaqcom Forrás: PL/SQL Developer by Allround Automations: http://www.orafaqcom/tools/allround/developerhtm Csordás Ákos. (2004) Forrás: Clarityhu: http://wwwclarityhu/site/hu/projectphp?id=46 78 Döbrentei István. (2011 10 23) A Unit tesztek jelentősége a fejlesztés során Forrás: http://dobrenteiistvan.hu/lang/hu/2011/10/23/a-unit-tesztek-jelentosege-a-fejlesztessoranhtml en.wikipediaorg (2012) Forrás: http://enwikipediaorg/wiki/Master data: http://en.wikipediaorg/wiki/Master data en.wikipediaorg (2012) Forrás: http://enwikipediaorg/wiki/Transaction data en.wikipediaorg (2012 12 17) Forrás: Regression testing: http://en.wikipediaorg/wiki/Regression testing en.wikipediaorg/wiki/Endianness (2012) Forrás: http://enwikipediaorg/wiki/Endianness etechplanet.com (2010) Forrás: http://wwwetechplanetcom/questions/what-do-you-meanby-oltpaspx Fábián, Z. (2012) Budapest (F

Tamás, Kérdező) Gergely Ferenc. (2005) Forrás: Clarityhu: http://wwwclarityhu/site/hu/projectphp?id=31 Hollingsworth, P. (2008) Auerbach Publications Forrás: Why Flexibility Is Key to a Successful Data Migration: http://www.ittodayinfo/Articles/DataMigrationhtm hu.wikipediaorg (2012) Forrás: Java (programozási nyelv): http://hu.wikipediaorg/wiki/Java %28programoz%C3%A1si nyelv%29 hu.wikipediaorg (2012) Forrás: http://huwikipediaorg/wiki/PhpMyAdmin idchungary.hu (dátum nélk) Forrás: http://wwwidchungaryhu/indexphp?nd=About+IDC intermatrix.hu (2010) Forrás: http://intermatrixhu/phpmyadmin ITbusiness.hu (2012) Forrás: http://www.itbusinesshu/Fooldal/hirek/ict n/Adatbol is megarthat a sokhtml Kartikey Brahmkshatriya. (2007) Doksihu Forrás: Data warehouse testing: http://doksi.hu/getphp?lid=17605 79 Kende Mária. (2002) PL/SQL táblák In K D Kende Mária, Adatbázis-kezelés az Oraclerendszerben (old: 420) Budapest: Panem Kft Lengyel Sándor, Istvanovszki Mihály. (2007)

Forrás: Clarityhu: http://www.clarityhu/site/hu/projectphp?id=94 Lengyel Sándor, Villarroel Hektor. (2003) Forrás: Clarityhu: http://www.clarityhu/site/hu/projectphp?id=22 Levine, R. (2009 Augusztus 29) Data migration strategies Forrás: http://wikibon.org/wiki/v/Data migration strategies Mártonffy Attila. (2010 11 07) ITbusinesshu Forrás: Adattisztaság fél egészség: http://www.itbusinesshu/Fooldal/hetilap/business/Adattisztasag fel egeszseghtml Mártonffy Attila. (2012 03 12) ITbusinesshu Forrás: http://www.itbusinesshu/Fooldal/hetilap/business/Adattomegen ulok mit csinaljakhtml medianetwork.oraclecom (2012 10 25) Forrás: The Golden Parachute: http://medianetwork.oraclecom/video/player/129259561001 Natalka Roshak. (2006 03 05) Forrás: orafaqcom: http://wwworafaqcom/node/848 Oracle White Paper. (2011 Október) Forrás: wwworaclecom: http://www.oraclecom/technetwork/middleware/oedq/successful-data-migration-wp1555708pdf Oracle.com (2012) Forrás: Migration Stategies:

http://wwworaclecom/technetwork/serverstorage/engineered-systems/database-appliance/documentation/oda-migration-strategies1676870pdf oracle-dba-online.com (dátum nélk) Forrás: Data pump utility: http://wwworacle-dbaonlinecom/data pump utilityhtm orafaq.com (2011 08 20) Forrás: Recovery Manager: http://www.orafaqcom/wiki/Recovery Manager 80 Orafaq.com (2012) Forrás: Start using datapump export: http://www.orafaqcom/wiki/Datapump#Start using datapump export Palaczk Péter. (2001 10 04) downloadoraclecom Forrás: Sikerünk kulcsa: az információ De honnan lesz adatunk?: http://www.googlehu/url?sa=t&rct=j&q=etl%20folyamat%20magyatl&source=web&cd=3& ved=0CD0QFjAC&url=http%3A%2F%2Fdownload.oraclecom%2Fglobal%2Fhu%2Fszemi nariumok%2FOracle szem 20011004 Palaczk Peter.pdf&ei=Qv3jUOKbPO774QTH1YDo CA&usg=AFQjCNGIBfGKNIS69-JB3tPs Papp Ferenc Gábor, H. F (2005) Forrás: Clarityhu: http://www.clarityhu/site/hu/projectphp?id=84 Pásztor. (2011 01 11)

Bevezetés a nagy terhelésű rendszerek fejlesztésébe János Pásztor, Budapest, Docler Holding Academy. Penny Crosman. (2011 03 01) Banktechcom Forrás: http://wwwbanktechcom/coresystems/12-best-practices-for-a-core-banking-upg/229402439 Phillips, D. (dátum nélk) What is Oracle Exalogic?! OpenWorld 2011 Forrás: youtube.com: http://www.youtubecom/watch?v=cPo9bC J4OQ&feature=BFa&list=PLB59ADDF6E024A 89D psoug.org (2010) Forrás: Oracle DataPump utility: http://psoug.org/reference/datapumphtml Ramaswamy. (2009 07 27) http://hosteddocsittoolboxcom Forrás: http://hosteddocs.ittoolboxcom/Data%20Migration092707pdf Ron Weiss. (2011) Oraclecom Forrás: Exadata Smart Flash Cache Features and the Oracle Exadata Database Machine: http://www.oraclecom/technetwork/server-storage/engineeredsystems/exadata/exadata-smart-flash-cache-366203pdf Sárecz Lajos. (2010) Oraclecom Forrás: Teljeskörű adatbázis védelem:

http://www.oraclecom/hu/corporate/events/db-security-wbreachvideo-hun-330575-hupdf 81 Schopp Attila. (2009 11 04) ITbusinesshu Forrás: http://www.itbusinesshu/Fooldal/hetilap/tech/Adatbazist a memoriabolhtml Schopp Attila. (2009 04 07) ITbusinesshu Forrás: Az adat védve jó: http://www.itbusinesshu/Fooldal/hetilap/tech/Az adat vedve johtml Schopp Attila. (2010 09 10) ITbusinesshu Forrás: Adatbázisok titkai: http://www.itbusinesshu/Fooldal/hetilap/tech/Adatbazisok titkaihtml Schopp Attila. (2011 03 25) ITbusinesshu Forrás: Veszélyek és védelmek: http://www.itbusinesshu/Fooldal/hetilap/tech/Veszelyek es vedelmekhtml sg.hu (2012 Június 25) Hiányszakma a mérnök és az informatikus Forrás: http://www.sghu/cikkek/90499/hianyszakma a mernok es az informatikus Soumendra Mohanty. (2004 05 01) Forrás: Information Management: http://www.information-managementcom/specialreports/20040518/1003611-1html ViSolve, M. (2012) wwwvisolvecom Forrás: Cross Platform Transportable

Tablespaces Migration in Oracle 11g: http://www.visolvecom/uploads/resources/Cross%20Platform%20Transportable%20Tablesp aces%20Migration%20in%20Oracle%2011g ViSolve%20Inc.pdf Jelen szakdolgozatra a „Nevezd meg! - Ne add el! 2.5 Magyarország (CC BY-NC 25 HU)” szerzői jogi oltalom vonatkozik