online kép - Fájl  tube fájl feltöltés file feltöltés - adja hozzá a fájlokat online fedezze fel a legújabb online dokumentumok Kapcsolat
   
 

Letöltheto dokumentumok, programok, törvények, tervezetek, javaslatok, egyéb hasznos információk, receptek - Fájl kiterjesztések - fajltube.com

 

Online dokumentumok - kep
   
kategória
 

Biológia állatok Fizikai Földrajz Kémia Matematika Növénytan Számítógépes
Filozófia
Gazdaság
Gyógyszer
Irodalom
Menedzsment
Receptek
Vegyes

 
 
 
 













































 
 

DIPLOMATERV - Viselkedés valtozas analízise tavközlési hívasadatokon

fizikai

Fájl küldése e-mail Esszé Projekt


egyéb tételek

 
FIZIKAI. KOLLOKVIUMI TÉTELEK
Az SI-mértékrendszer
FELÜLETI FESZÜLTSÉG
TESLA, A FELTALÁLÓ
P. CURIE FELFEDEZÉSE
A HELYZET MA
ÚJABB VIZSGÁLATOK
Feszültséggenerator. Áramgenerator
A FELTALÁLÁS FOLYAMATÁNAK NEHÉZSÉGEI
A MECHANIKA ALAPFOGALMAI
 
 

Diplomaterv

Viselkedés változás analízise
távközlési hívásadatokon


Tartalomjegyzék

1. Absztrakt ha kell angol is

2. Bevezetés

2.1. A téma elhelyezése a világban; adatbányászatról pár szó

2.2 Adatbányászati feladatok

2.3. BME és a T-com közös projektjének leírása: miről szól, milyen adataink vannak

2.4. A téma indoklása, a konkrét megoldandó feladat, a probléma megoldása mit tesz lehetővé a számunkra, Miért indokolt a probléma kezelése

2.5. A CRISP-DM modell rövid bemutatása, mely alapján a téma kidolgozása történik.

3. A téma kidolgozása

3.1. Business Understanding: a kitűzött feladat miért hasznos üzleti szempontból

  • sikeres végrehajtás kritériumainak meghatározása, milyen szempontok alapján értékeljük majd az eredményeket
  • rendelkezésre álló erőforrások (adatbázis, SZTAKI), feltételek: milyen programokat használtunk a megoldáshoz, (piped-mine, clementine) esetleg ezek rövid ismertetése
  • adatbányászati cél bemutatása

3.2 Data Understanding: adatok feltérképezése (piped-mine), begyűjtése (piped-mine), megértése

  • adatok leírása, kategori 141g69b zálása
  • fontos attribútumok kiszűrése: az előfizető hívási szokását jellemző attribútumok kiválasztása
  • adatminőség felmérése: mennyire jók, megbízhatóak az adataink

3.3. Data Preparation: a tényleges adathalmaz elkészítése

  • adatok kiválasztása: mely attribútumokra lesz szükségünk
  • adattisztítás: (ha szükséges volt a munka során) pl. hiányos adatok pótlása
  • adatbeszúrás (vektorokat állítunk elő, melyekből a bemenet lesz)
  • formátumok konvertálása (hívás idejének átalakítása)
  • a kész adathalmaz szétbontása tanító, tesztelő és verifikáló halmazokra

3.4. Modeling: konkrét adatbányászati műveletek: modellezési technika

3.4.1. technika kiválasztása: milyen modelleket próbáltunk, a sikeres (leghatékonyabb) modell ismertetése matematikai szempontból (elméleti háttér)

3.4.2. modell felépítése, futtatás

3.4.3. sikeresség vizsgálata, modell ellenőrzése

3.5. Evaluation

  • üzleti célnak megfelelően értékeljük a modellt
  • következő lépés meghatározása

3.6. Deployment

  • alkalmazási terv
  • az elkészült modellek értékelése

4. Összefoglalás, következtetések

  • A legjobb modell felépítésének összefoglalása, hatékonysága, következtetés

V. Irodalomjegyzék

  • a diplomaterv készítése során felhasznált irodalom felsorolása: könyvek, linkek pontos megjelöléssel

VI. Rövidítések jegyzéke

  • esetleges betűszavak felsorolása, ha szükséges angolról magyarra fordítása

VII. Ábrajegyzék

  • a diplomatervben előforduló ábrák, képek jegyzéke

VIII. Köszönetnyilvánítás

IX. Mellékletek



2.       Bevezetés

2.1.      Adatbányászat

Napjainkra a tároló kapacitások erőteljes növekedése valamint az árak nagymértékű csökkenése a hétköznapi életben is egyre több helyen elérhetővé tette adatbázisok és adattárházak használatát. Ezáltal manapság szinte minden közép- és nagyvállalat alkalmazza ezeket az informatikai eszközöket vásárlóik, ügyfeleik, illetve saját adataik tárolására. Ez a folyamat azt eredményezte, hogy egyre több információ halmozódott fel, melyeket eleinte csak ellenőrzésre illetve visszakeresésre használtak, így alakultak ki az úgynevezett „adattemetők” (data tombs) [1].

Azonban egyre több területen merült fel az igény arra, hogy a meglévő információkból valami új, hasznos információt nyerjünk ki, melyekre a régebbi adatbázis kezelő rendszerek még nem voltak felkészülve. Ez az igény keltette életre az adatbányászatot, az 1980-as éves végén, mely mostanra már közel húsz éves fejlődésen ment keresztül.

Az adatbázisból való tudásfeltárás[1] során adatbányászati algoritmusokat alkalmazunk. Az algoritmusok elvégzése után mintákat fedezünk fel az adatokban, végül számítógép segítségével a mintákból használható tudást kovácsolunk. Az adatbányászat definíciója tehát a következő: nagyméretű adatbázisokból új, nem triviális és egyben hasznos összefüggések feltárása.

Az adatbányászat egy új tudományterület, mely számos korábbi tudománnyal is szoros kapcsolatban áll, illetve ezeket ötvözi. Ilyenek például a teljesség igénye nélkül a matematika, statisztika, számítástudomány, mesterséges intelligencia és a marketing. A diplomatervem során az adatbányászat már meglévő eredményeit, módszereit használom föl, illetve feladatom megoldásához új módszert (modellt) alakítok ki, mellyel mindegy hozzájárulva az adatbányászat eddigi töretlen diadalmenetéhez.

2.2.      Adatbányászati feladatok

A sikeres alkalmazások eredményeképpen az adatbányászat egyre elfogadottabb tudománnyá vált, így ma már az adatok tárolásán kívül, szinte mindenütt fontos azok feldolgozása és elemzése is. Az adatbányászat a kereskedelem, a pénzügy, valamint a biológia és orvostudomány területén már bizonyította hatékonyságát. Mégis van néhány tipikus feladat, mely több különböző környezetben is felmerül és általános megoldási módszereik hasonlóak a különböző felhasználási területeken. Ilyenek például a következő feladatok:

·       Gyakori minták kinyerése [2]: olyan elemcsoportok megkeresése, melyek gyakran együtt fordulnak elő, azaz asszociációs szabályok megkeresése. Tipikus példája a vásárlói kosár elemzése, ahol a gyakran együtt vásárolt termékek kerülnek feltárásra.

·       Attribútumok közötti kapcsolat: itt az elemek attribútumai közti kapcsolatokat tárjuk fel, így alakítunk ki korrelációs, illetve függőségi szabályokat.

·       Osztályozás [2]: az elemeket valamilyen tulajdonságuk alapján előre definiált csoportokba soroljuk, vagyis osztályozzuk őket.

·       Klaszterezés [2]: itt az elemeket egy-egy előre nem definiált csoportokba soroljuk be. Az adott klaszterező algoritmus feladata az egyes csoportok kialakítása. Az a fontos, hogy a csoporton belüli elemek egymáshoz valamilyen szempontból közeliek legyenek, a különböző csoportokban lévők pedig távoliak.

·       Sorozatelemzés: a hasonló sorozatokat vagy részsorozatokat keressük meg, illetve azokat, amelyek gyakran fordulnak elő. Megpróbáljuk meghatározni, hogy egy adott sorozat nagy valószínűséggel mivel fog folytatódni.

·       Eltéréselemzés: az előző feladatoknál általában nem vettük figyelembe az általános trendtől erősen eltérő néhány elemet. Itt viszont pont azokat kell megkeresnünk. Tipikus példája a hibadetektálás, vagy a csalások felderítése.

·       Viselkedés előrejelzés: feladat itt az, hogy a múltbéli események alapján megjósoljuk, hogy milyen fordulatok várhatók a vizsgálati alany viselkedésében. Ez használatos, ha például meg akarjuk tudni, melyik ügyfél hajlik arra, hogy szolgáltatót váltson (churn-analízis), vagy, hogy melyik ügyfél nagy valószínűséggel hogyan fog reagálni egy-egy új termék bevezetésére (affinitás elemzés). Diplomatervemben főként ez utóbbi kérdéskört vizsgálom meg.

2.3.      A tanszéki projekt

Az előző félévek során bekapcsolódtunk a tanszék egyik adatbányászati projektjébe. A projekt a T-Com távközlési cég megbízásából indult, a MTA-SZTAKI[2], a TMIT tanszék és az AITIA Rt. részvételével. A cég vezetékes telefonhívások szolgáltatásával is foglalkozik, így nagy mennyiségű hívásadatok állnak rendelkezésükre. Az adatok tárolása itt létfontosságú, hiszen az előfizetők nyomon követéséhez és a számlázásához elengedhetetlen nagyméretű adattárházak használata. A tárolt adatok nagy segítséget nyújtanak akkor is, ha egy vállalat racionalizálni szeretné a működését, illetve mindezeken kívül az adatokból másfajta összefüggésekre is rá lehet jönni az adatbányászati tudomány segítségével. A tanszék hallgatóinak feladata pedig az, hogy az adatokon különböző adatbányászati projekteket hajtsunk végre. Természetesen a felhasználói viselkedések helyes modellezése a többi telekommunikációs területen, például mobil távközlés, vagy internet szolgáltatók esetén is alkalmazható, sajnos azonban ilyen adatbázis nem áll rendelkezésünkre. A tanszéken elemezzük a hívások különböző attribútumait, úgymint a hívások időpontját, időtartamát, irányultságát valamint a költségét, mely a tarifacsomagokhoz szorosan kapcsolódik. Természetesen a hasznos információ megszerzéséhez az előfizetők megfelelő modellezésére van szükség, mely tulajdonképpen ezen adatbányászati projektek célja.

2.4.      A téma indoklása és a telekommunikációs piac

Manapság a telekommunikációs piac telítődött, így a cégek számára a legfontosabb, hogy a már meglévő ügyfeleiket, megtartsák. Ezért, ha sikerül előre jelezni, hogy ki fog szolgáltatót váltani (ez a terület a churn-analízis), célzott reklámokkal, ajánlatokkal (Direct Marketing) van esély megtartani az ügyfelet. A cégek hajlandóak az ügyfelek részére egy kedvezőbb tarifacsomagot ajánlani, ezáltal kevesebb profithoz jutni, csak azért, hogy nehogy más szolgáltatót válasszanak. Ráadásul a helyzetet még az is bonyolítja, hogy a tarifacsomag váltása után a legtöbb ügyfélnek megváltoznak a telefonálási szokásai. Sokan jóval többet kezdenek telefonálni, mások pedig jobban odafigyelnek arra, hogy mikor telefonáljanak. Természetesen vannak olyanok is, akik érzéketlenek a tarifacsomag váltásukra vagy nincsenek pontosan tudatában annak, hogy a nap melyik szakában milyen irányban mekkora költséggel telefonál. A diplomatervemben ezt a feladatkört próbálom megoldani, vagyis olyan modelleket kívánok létrehozni, melyek hűen türközik egy átlagos előfizető viselkedését egy új tarifacsomag bevezetése esetén.

Az üzleti feladat részletesebb kifejtésére és az adatbányászati cél meghatározására 3.1.1. fejezetben kerül sor.

2.5.      Adatbányászati modell (CRISP-DM)

Az adatbányászati algoritmusok megszületését követően problémaként merült fel, hogy a konkrét adatbányászati projektek terén nincs olyan jól kidolgozott általános módszertan, mely mentes lenne a különböző szaksági specifikumoktól. Mivel az adatbányászati feladatokat széleskörűen alkalmazzák, ezért a tapasztaltabb szállítók kidolgoztak egy olyan módszertant, mely rendszerezi a nélkülözhetetlen lépéseket és lehetővé teszi, hogy egy adott területen megszerzett tudást egy másikban is felhasználják. Így jött létre a CRISP-DM (CRoss Industry Standard Process for Data Mining − Iparág független Szabványos Adatbányászati Módszertan) [3] [4].

A módszertan hat fő lépését az ábrán láthatjuk (1. ábra), vizsgáljuk meg ezeket a lépéseket sorjában!

1. ábra ACRISP-DM módszertan

                               1.    Üzleti célok meghatározása (Business Understanding): ez a projekt első fázisa, itt fogalmazzuk meg a projekt célkitűzését, illetve a vele szemben támasztott elvárásokat üzleti szemszögből igyekszik meghatározni. Itt határozzuk meg az alkalmazási környezetet is.

                               2.    Az adatok megismerése (Data Understanding): Ebben a fázisban először begyűjtjük az elemzéshez szükséges adatokat, megértjük őket, majd megvizsgáljuk mely attribútumok fontosak számunkra az elemzés szempontjából és ezek milyen típusúak. Elemezzük az adatainkat adatminőség szempontjából is, hogy mennyire hiányosak vagy inkonzisztensek a rendelkezésre álló adatok. Ez utóbbi lépés nagyon fontos minden projekt során, mert ha nem tiszta adaton dolgozunk a konkrét adatbányászati algoritmusokkal, akkor vagy hibás eredményeket kapunk, vagy eredménytelen lesz a projekt.

                               3.    Adatelőkészítés (Data Preparation): ebben a fázisban a különböző forrásokból begyűjtött adatokat egységes formátumra hozzuk. Elvégezzük az adattisztítást, mely során az adat minőségének feltárása során megismert hiányosságokat pótoljuk: a hiányzó illetve hibás adatokat feltöltjük. Valamint elvégezzük az adatbeszúrás műveletét is, mely során akár új attribútumokat, vagy rekordokat fűzhetünk a már létező adatstruktúrákhoz. A fázis végére elkészül az a struktúra, mely az elemzés bementéül szolgál.

                               4.    Modellek megalkotása (Modeling): Ebben a fázisban érkezünk el az adatbányászati műveletek végrehajtásához. Először a modellezési technikát választjuk ki, általában valamely erre a célra kifejlesztett szoftver (például Clementine) segítségével. A technika kiválasztása után, a modellt az aktuális adatokhoz hangoljuk, vagyis felparaméterezzük a modellünket. A modellezés elvégzése után meg kell vizsgálnunk a modell sikerességét. Nem kielégítő eredmények esetén új modellel, vagy új paraméterekkel kell újrakezdeni a modellezési lépést. Ezeket a lépéseket egy adatbányászati projekt keretében többször is végrehajtják. Egy ilyen projektre ugyanis sokkal inkább jellemző az, hogy elsőre nem sikerül a helyes modellt megtalálni.

                               5.    Eredmények értékelése (Evaluation): Ebben a szakaszban már a megfogalmazott üzleti céloknak megfelelően értékeljük ki a modell, illetve a modellezési lépések sikerességét, hogy teljesítettük-e az első fázisban megalkotott üzleti célokat. Amennyiben az eredményt megfelelőnek ítéljük, akkor modellünket éles bevetésben is használhatjuk és továbblépünk a megvalósítás fázisába. Ha a modellünk nem megfelelő, akkor vissza kell kanyarodnunk egy korábbi lépéshez, vagy egy új projekt keretén belül más irányvonalat kell keresnünk.

                               6.    Az eredmények üzleti szintű alkalmazása (Deployment): Ezen utolsó fázis célja, hogy a projekt során megszerzett ismereteket a megrendelő számára is érthető formába kell hoznunk. Ehhez egy alkalmazási és egy üzleti tervet kell készíteni. Ez utóbbi azért szükséges, hogy az adatbányász csoport kivonulása után is folytatódhasson a munka. Bizonyos esetekben célszerű gondosan kidolgozott fenntartási stratégiákat is kidolgozni. A projekt végén gyakran szükség lehet egy olyan összefoglaló dokumentumra, mely a projekt során nyert tapasztalatokat összegzi. Végül saját magunk számára is hasznos egy olyan dokumentum létrehozása, melyben a projekt pozitív és negatív tapasztalatait gyűjtjük össze és levonhassuk a megfelelő konzekvenciákat.

Mivel diplomatervem gyakorlatilag egy teljes adatbányászati projekt végrehajtását tartalmazza, ezért munkám során ezt a jól kidolgozott módszertant követem a továbbiakban.

Az 1. ábrán jól láthatjuk, hogy az egyes lépések között visszalépések is történhetnek, ez a CRISP-DM metodika egyik legfontosabb jellemzője, mely azért van, mert nem megfelelő eredmények esetén gyakran vissza kell lépni az előző fázisba és addig változtatni az adathalmazon, új ötleteket kipróbálni, ameddig kielégítő eredményeket nem kapunk. Diplomaterv feladatom megoldása során magam is többször alkalmaztam ezt a visszalépési eljárást, de ebbe a dokumentumba már csak a végleges, legjobb eredményt hozó módszert fejtem ki részletesen, az előfordult esetleges visszalépéseket és eredménytelen „vakvágányokat” csak megemlítem a dolgozatomban.


3.       Viselkedés előrejelzés

3.1.      Üzleti célok meghatározása (Business Understanding)

A fejezet címe egy adatbányászati projekt első lépése. Ebben a fázisban a projekt célkitűzéseit, illetve a vele szemben támasztott elvárásokat üzleti szemszögből igyekszünk meghatározni. Az „üzleti” kifejezés itt nem feltétlenül a hagyományos pénzpiaci értelmezését fedi, hanem az általános alkalmazási környezetet adja meg, ezért ebben a fejezetben térek ki a munkám során rendelkezésre álló technikai és alkalmazási eszközökre is.



3.1.1.     Az adatbányászati cél meghatározása

A diplomatervemben olyan modelleket kívánok létrehozni, melyek hűen türközik egy átlagos előfizető hívási szokásait egy új tarifacsomag bevezetése esetén.

Nehezíti a modell megalkotását, hogy az előfizetők egyes csoportjai biztosan másképpen reagálnak egy-egy új tarifacsomag bevezetésére. A nagyobb cégeknél dolgozók munkahelyi hívási szokásait valószínűleg nem befolyásolja, hogy a cég milyen szolgáltatót választott, és épp az adott időpontban mekkora költséggel telefonál a dolgozó. Másrészt pedig a nagyobb cégek általában olyan kedvezményekre is jogosultak, melyek egyéni előfizetők számára nem elérhetők. Ezért a további vizsgálatokban csak az egyéni előfizetőket veszem nagyító alá. Tovább nehezíti a modellalkotást az, hogy egyéni előfizetőkön belül is több csoport létezik, hiszen biztosan más hívási szokásai vannak egy üzletembernek, akinek munkájához elengedhetetlen a telefon használata, illetve egy nyugdíjas idős hölgynek. Ezek az előfizetői csoportok azonban nem választhatók szét a rendelkezésre álló hívási információk alapján.

Határozzuk meg, hogy mit értünk egy előfizető hívási szokásai alatt, vagyis hogy mit kell mégis modelleznünk! A hívási adataink (mely részletesen a 3.2.1. fejezetben kerül majd részletes bemutatásra) lényegében azt tartalmazzák, hogy az egyes felhasználók, mikor, milyen irányban és milyen hosszan telefonáltak. Ezekből az adatokból többféle származtatott adatot készíthetünk, melyek modellezése a célom. Ilyen származtatott adatok a következők:

·       felhasználónként a legkorábbi és legkésőbbi hívás időpontja a vizsgált időszakban

·       hány hívást bonyolított a felhasználó egy adott hónapban

·       a felhasználó átlagos híváshossza

·       egy hónapban összesen hány percet telefonált

Természetesen ezeket az értékeket különböző bontásokban külön-külön is kiszámíthatjuk. Ilyen bontások lehetnek a következők:

·       Hívás időpontja szerinti bontásban

Ø     hétköznap csúcsidőben

Ø     hétköznap csúcsidőn kívül

Ø     hétvégén

·       Hívás iránya szerinti bontásban

Ø     helyi

Ø     távolsági

Illetve ezek kombinációjaként például kiszámíthatjuk a hétköznap csúcsidőn kívüli, helyi hívások átlagos hosszát. Ezekből az adatokból és a különböző felbontásokból nagyszámú adatot tudunk származtatni az egyes felhasználókhoz, melyek jól leírják viselkedésüket.

Feladatom ezen értékek előrejelzése, abban az esetben, ha egy felhasználó tarifacsomagot váltott. Természetesen az egyes felhasználókról feltételezhetjük, hogy a hozzájuk tartozó hívási adatok (hívások száma, átlagos híváshossz, hívások időtartamának összege) a váltás után nem változik és így a váltás előtti hónap adataival becsülhetjük. Hasonlóan jó becslés lehet, ha a felhasználók tarifaváltás előtti összes hívási adata alapján számítjuk az értékeket és ezt vetítjük le egy hónapra majd feltételezzük, hogy a váltás után szintén ilyen paraméterekkel fog telefonálni.

Az adatbányászat eszközeivel viszont kihasználhatjuk, hogy már vannak olyan előfizetők az adatbázisban, akiknek tudjuk, hogy hogyan változtak meg a szokásaik váltásuk után. Ezen felhasználók segítségével egy modellt építve egy olyan felhasználóról is kiszámíthatjuk a hívási szokásainak peremétereit, akik még nem is váltottak át másik tarifacsomagra, vagy éppen most váltottak át. Ez üzleti szempontból nagyon fontos, melyről a következő fejezetben esik szó.

Diplomatervem célja, tehát hogy olyan modellt alkossak, mely pontosabb becslést tud adni annál, mintha az adott felhasználó szokásának változását csak egyszerűen az előző havi (váltás előtti), vagy váltás előtti életciklusának átlagával becsülnénk. Amennyiben ez sikerül, akkor tekinthetjük úgy, hogy az adatbányászati projekt elérte célját.

Az adatok elemzése során továbbá megtudhatjuk, hogy mennyire érzékenyek az emberek saját tarifacsomagjukra és így a saját pénztárcájukra, valóban megváltoznak-e a hívási szokásaik, ha új tarifacsomagba lépnek át. Megéri-e a szolgáltatónak olcsóbb tarifákat bevezetni és ezzel több előfizetőt megtartani, illetve hogy többet telefonálunk-e a szükségesnél, ha bizonyos időpontokban olcsóbban, vagy akár teljesen ingyen telefonálhatunk.

3.1.2.     Miért szükséges mindez?

Elsősorban a szolgáltatók számára nagyon fontos az előző fejezet kérdéseinek megválaszolása. Napjaink üzleti világában elengedhetetlen, hogy egy-egy tarifacsomag bevezetése után kiszámítható legyen, hogy ez a szolgáltató számára milyen többlet költségekkel fog járni a jövőben, vagy mekkora többlet nyereség várható egy új számlázási rendszer megvalósítása esetén. Egy ilyen felhasználói modell segítségével elemezhető, hogy vajon egy rivális szolgáltató miért vezetett be egy adott új tarifacsomagot, esetleg nekünk is megérné-e hasonlót létrehozni.

Üzleti szempontból tehát nagyon fontos, hogy modellezzük egy előfizető viselkedését, hiszen ezzel megtudhatjuk, hogy egy felhasználó melyik tarifacsomagról melyikre áttérve milyen paraméterekkel fog telefonálni. Ebből aztán költséget számíthatunk a telefonszolgáltató számára, meghatározhatjuk a tarifacsomagok percdíjait, melyekből aztán kiszámíthatjuk a bevételt és kiadásokat, illetve ezáltal a távközlési szolgáltató nyereségét.

Azonban a telekommunikációs szolgáltatók számára nem pusztán az anyagi értékek előrejelzésére (prediktálására) használhatják ezt a modellt. Távközlési és informatikai szempontból is szükség van arra, hogy előre lássuk egy-egy vonal terheltségét, kihasználását, hiszen a tervezések és fejlesztések során ezek az információk nélkülözhetetlenek. Ugyanakkor ennek a problémakörnek a megoldására a távközlési szolgáltatók jelentősen túlméretezik saját kommunikációs hálózatukat, mert anyagi és üzleti okok miatt így gazdaságos számukra a jövőre nézve, és ezzel kerülik el a hálózat esetleges túlterheltségét.

Egy-egy új tarifacsomag bevezetése esetén létrejöhetnek kritikus időpontok, amikor a hálózat terheltsége nagyon megnő vagy lecsökken. Ezek kiszámításához szintén elengedhetetlen egy ilyen ügyfélmodell megalkotása.

3.1.3.     Alkalmazási és technikai környezet

A tanszéki projekt a T-Com távközlési cég megbízásából indult, a MTA-SZTAKI, a TMIT tanszék és az AITIA Rt. részvételével. A hívási információk tárolását és alapvető feldolgozását a SZTAKI tette lehetővé számunkra. A tanszék adatvédelmi okok miatt kisebb módosításokkal kapta meg az adatokat a SZTAKI-tól, azonban ezek a módosítások az elemzés szempontjából irrelevánsak, így lehetővé vált számunkra az adatbányászat ezeken hívási információkon.

A Távközlési és Médiainformatikai Tanszék a módosított adatokat tárolta és a SZTAKI a tanszéki szerveren is elérhetővé tette az adatok kitömörítéséhez és alapvető feldolgozásához szükséges piped-mine nevű programot, melyet a SZTAKI fejlesztett ki.

3.1.3.1.    A piped-mine keretrendszer [5]

Ez egy komponens alapú rendszer, mely erősebb kapcsolatot jelent a komponensek között, mint az objektum orientáltság. Lényege, hogy adott egy komponens keretrendszer, melyet egyszer létrehoztak és ebbe a programozás során lehet behelyezni az egyes komponenseket. Ezen rendszer felépítését szemlélteti a 2. ábra.

2. ábra A piped-mine keretrendszer

Mikor a komponenseket a rendszerbe helyezzük, a komponensek tudnak kommunikálni egymással, és a keretrendszerrel. Nekünk csak azt kell ismerni, hogy a „core” és közöttünk milyen interfész található. A rendszerben jelenleg hozzávetőlegesen 40-50 komponens található. Amennyiben valamelyiket használni szeretnénk, akkor ezeket bármilyen sorrendben egymás mögé rakhatjuk, szintaktikailag működni fognak, csak rossz esetben értelmetlen kimenetet kapunk. Illesztésekkel tehát nem szükséges foglalkozni. Ilyen módon a számunkra szükséges komponensek felhasználásával egy „csővezetéket” (innen ered a rendszer neve is) építhetünk melynek a kimenetén megjelenik a számunkra szükséges adathalmaz.

A feladatunk tehát egy olyan konfigurációs fájl elkészítése, mely tartalmazza, hogy milyen komponensekből tettük össze a rendszert és azok hogyan kapcsolódjanak egymáshoz (melyik melyikkel álljon kapcsolatba). Tehát a konfigurációs fájl megírásánál a következő információkat kell megadnunk:

·       melyik komponensből: pl. kitömörítő, szűrő (filter), aggregáló, hisztogram készítő, fájlba író komponensek

·       hányat: szükség esetén természetesen több ugyanolyan komponens is egymás mögé fűzhető pl. több szűrő komponens egymás után

·       kivel kommunikáljon: melyik másik komponenstől kapja az információt és melyiknek adja tovább a „csővezetékben”

A komponensek és a keretrendszer egy egységben vannak, melynek a mérete (csak az algoritmusokat tartalmazza) kb. 24 MB. A SZTAKI ezt a rendszert tette elérhetővé számunkra a tanszéki szerveren, mivel az adatok tömörített formában vannak tárolva és a piped-mine segítségével megoldható, hogy csak azok az adatok kerüljenek kitömörítésre, melyekre a további elemzések során szükségünk lesz.

A keretrendszerről egy általam készített részletesebb útmutató található az irodalomjegyzékben [5].

3.1.3.2.    Clementine adatbányász szoftver [6]

Ez a Java alapú adatbányászati szoftver-rendszer lehetővé teszi az üzleti tapasztalatokon alapuló előrejelző modellek gyors kifejlesztését, és azok üzleti és a döntési folyamatokba való beillesztését. Mivel az SPSS a nyílt, egymással összekapcsolható eszközök híve, így a Clementine az iparág független CRISP-DM módszertant követi, mely a diplomatervem során rendkívül előnyös. A Clementine nyitott architektúrája lehetővé teszi a meglévő IT befektetések megőrzését és felhasználását a rugalmas elemzési modell kialakításban és annak üzemelési folyamatokba történő beépítésében.

Az alapvető szükséges adatok kiválasztása és kitömörítése után (melyet az előző fejezetben ismertetett piped-mine rendszerrel végeztem el a tanszéki szerveren) az adatokat átmentettem a saját itthoni számítógépemre. Ezt követően az adatok további átalakítását, a modellek megalkotását és értékelését itthon végeztem el a Clementine 11.1.-es verziójával.

3.1.3.3.    Számítógépem, azaz az elemzés eszközének erőforrásai

·       Intel(R) Core(TM)2 Duo E6750 2,66 GHz

·       3071 MB RAM

·       Háttértárolók: Samsung SP1614C 160 GB valamint 2 db Seagate Barracuda 7200.10 320 GB (Raid1)

·       Windows Vista x64 operációs rendszer

·       Sun Java(TM) 6 Update 5

·       Clementine 11.1.

3.1.3.4.    A tanszéki szerver paraméterei

·       Dual Opteron processzor

·       4 GB memória

·       Debian Linux operációs rendszer

·       Piped-mine keretrendszer


3.2.      Az adatok megismerése (Data Understanding)

Az adatbányászati projekt következő lépése az adatok megértése. Ekkor feltérképezzük, hogy milyen adatok állnak rendelkezésünkre, majd az elemzési célt figyelembe véve ezekből kiválogatjuk az elemzéshez szükséges adatokat. A kiválogatott adatokat részletesebben is megvizsgáljuk, hogy milyen típusúak, milyen értékkészletűek, grafikonokat készítünk az eloszlásukról. Elemezzük, hogy van-e hiányzó, vagy téves adat, illetve, hogy mennyire konzisztens az adatbázisunk. Ezek a lépések egy adatbányászati folyamat sarkalatos pontjai, hiszen itt dől el, hogy mely adatokon fogunk dolgozni. Hibás, vagy téves adatok elronthatják a modell építését és végül hibás eredményekhez jutunk és a projekt sikerességét is veszélyeztetjük.

3.2.1.     Rendelkezésre álló adatok

A SZTAKI által rendelkezésünkre bocsátott adathalmaz 54 attribútumot tartalmaz. A feladatunk ezek közül a számunkra lényegesek meghatározása. Az összes mező rövid leírása megtalálható a [M1] mellékletben, azonban az attribútumok beszédes neve miatt részletes tárgyalásukra itt nem térek ki. Általánosan elmondható, hogy a „D_SZAM” kifejezést tartalmazó információ a hívó félre vonatkozik, míg a „B_SZAM” a hívott félre vonatkozó attribútum.

Mivel diplomatervem feladata az ügyfelek telefonálási szokásainak vizsgálata, ezért olyan mezőket kell kiválasztanunk az 54 közül, melyek egy előfizető szokásait jellemzi. Egy hívás legfőbb tulajdonságai ilyen szempontból, hogy milyen irányban telefonálunk, milyen időpontban és természetesen, hogy mennyi ideig. Ezek alapján a következő mezőket választottam ki az elemzéshez, melyeket az alábbiakban részletesen is bemutatok:

·       D_SZAM: Ezen mező kiválasztása azért szükséges, hogy a hívó felet azonosítani tudjuk. Ez tulajdonképpen a hívó fél telefonszáma is lehetne, azonban adatvédelmi okok miatt ezek nem a tényleges hívó fél telefonszámai, hanem valamilyen módon azokból előállított azonosító. Ez egy string[3] típusú változó az adatbázisban.

·       D_SZAM_KORZET: Ez a mező a hívó fél körzetszámát tartalmazza. Azért van rá szükségünk, hogy meg tudjuk állapítani, hogy vajon az adott hívás az helyi, vagy távolsági hívás. Ezen kívül pedig szükség esetén akár demográfiai információk is visszafejthetők ebből a mezőből. Ez a mező egész számokat tartalmaz, tehát integer[4] típusú.

·       D_SZAM_BIU: Ez tartalmazza azt az információt, hogy egy adott ügyfél milyen ügyfélcsoporthoz tartozik. Az adatbázisban több mint 182 ügyfélcsoport létezik, melyek az [M2] mellékletben hivatkozott helyen megtalálhatók. Azonban amennyiben ez a mező „1” értékű az minden esetben a lakossági, egyéni ügyfeleket tartalmazza. A diplomatervem 3.1.1. fejezetében részletezett okok miatt csak az egyéni előfizetőket vizsgálom, cégek hívásinformációját nem. Így a későbbiekben csak azokat a rekordokat[5] tartottam meg, ahol ez a mező „1” értékű. A mezőben található adat integer típusú.

·       D_SZAM_UGYFEL_VONALDARAB_SZAMA: Az elemzések későbbi fázisaiban fény derült arra, hogy egy felhasználó (azaz egy D_SZAM) 60-70-szer váltott tarifacsomagot. Ez természetesen hibás feltételezés, melynek oka, hogy egy D_SZAM-hoz több vonal is tartozik melyek más-más tarifacsomag szerint számlázódnak. Így eddig a lépésig vissza kellett lépni a CRISP-DM (2.5. fejezet) metodika alapján és ezt a mezőt is felvenni a szükséges, vizsgálandó mezők közé. Tehát ez a mező azt az információt tartalmazza, hogy a hívó fél számához hány tényleges vonal tartozik. A legtöbb rekord esetében ez tipikusan „1” értékű, de mint látjuk természetesen előfordulhat, hogy egy számhoz több vonal is tartozik.

·       B_SZAM_KORZET: Ez a mező a D_SZAM_KORZET-hez hasonlóan, a hívott fél körzetszámát tartalmazza. Ez a mező szintén integer típusú. Szükséges ezen mező felvétele is, hiszen a D_SZAM_KORZET és a B_SZAM_KORZET mezőkkel együttesen tudjuk megállapítani az adott hívás típusát (helyi, helyközi, távolsági).

·       TARTASIDO: Ez a mező tartalmazza az adott hívás hosszát. Értéke egy egész szám, vagyis interger, mely a hívás hosszának másodpercekben kifejezett értéke.

·       HIVAS_IDEJE: Ez az attribútum tárolja azt az információt, hogy az adott hívás mikor történt. Értéke egy nagy egész szám, mely az 1970. január 1.-e óta eltelt másodpercek száma az adott hívás időpontjáig. A SZTAKI így tárolta a hívási időpontokat ezért számunkra is ilyen meglepő formátumban áll rendelkezésünkre.

·       TARIFACSOMAG_KOD: Ez egy string típusú mező, mely a hívó fél tarifacsomagjának kódja. 48 féle lehetséges értéke van, melyek az [M3] mellékletben találhatók meg.

3.2.2.     Piped-mine és az adatok átvitele

A hívási adatok a SZTAKI-tól a tanszéki szerverre kerültek, ahol a piped-mine keretrendszer szintén elérhető. A keretrendszerről részletesebb információ diplomatervem 3.1.3.1. fejezetében található, valamint egy általam írt dokumentum is elérhető az irodalomjegyzék [5] pontjánál.

Elkészítettem azt a konfigurációs fájlt, mely elvégezte a szükséges attribútumok kiválasztását. Mivel hatalmas méretű adathalmazról van szó (tömörítetten 28,5 GB) ezért az előző fejezetben említett D_SZAM_BIU mező alapján már itt szétválasztottam az egyéni ügyfeleket a vállalati ügyfelektől. Ehhez a művelethez a piped-mine-ban egy filtert definiáltam, mely kiválogatta azokat a rekordokat, melyekben D_SZAM_BIU „1” értékű. Ezzel hozzávetőlegesen a hívási adatok felét kiszűrtem az elemzés korai fázisában.

Ahogy az előző fejezetben említettem a későbbi elemzések szükségessé tették a D_SZAM_UGYFEL_VONALDARAB_SZAMA mező használatát is ezért erre is egy külön filtert írtam, mely csak azokat az ügyfeleket válogatta ki, melyeknek egy vonal tartozik a hívószámukhoz.

Elhagyva ezeket a számomra felesleges rekordokat egy sokkal kisebb méretű adathalmazt kellett csak a hálózaton átmásolnom az itthoni számítógépemre, melyen az elemzés további részét végeztem.

A piped-mine konfigurációs fájl, mely az adatok kitömörítését és a szükséges attribútumok kiválasztását végzi az [M4] mellékletben található.

A kitömörítés után célszerű az adatokat ismét összetömöríteni és így átmásolni a hálózaton, hiszen sok azonos karakter fordul elő bennük, ezért nagy méretcsökkenés érhető el az eljárással. A hálózaton ilyen tömörített formában másoltam át a számomra szükséges adathalmazt. Az így átmásolt majd kitömörített adathalmaz mérete: 34 GB mely 687 481 666 rekordot és az előző fejezetben megjelölt 8 attribútumot tartalmaz.

3.2.3.     Az átmásolt adatok értelmezése

A SZTAKI 2005. október 3.-tól 2006. április 30.-ig tartó időintervallum hívásait bocsátotta rendelkezésünkre tömörített formában.

A kitömörítés és a szükséges adatok kiválasztása után Clementine segítségével végeztem el az átmásolt adatok elemzését. Az adatbázisban csak a vezetékes hívásokat találtam, mivel az adatokat megvizsgálva a B_SZAM_KORZET oszlopban nem találtam mobil irányba menő hívásokat, azaz 20-as, 30-as, 70-es körzetszámot.

A körzetszámokat tovább vizsgálva kiderült, hogy a leghosszabb hívási időtartamok általában az 51-es körzet felé irányulnak. Ami nem is véletlen, hiszen az 51-es körzet a modemes internetszolgáltató körzetszáma. Mivel az adatok 2005. és 2006. évből származnak, ezért ebben az időpontban még jelentősebb volt a modemes internet kapcsolattal webezők száma mint manapság, ezért ez jelentős összeget jelent. Mivel diplomatervem célja a hívási szokások elemzése, ezért a továbbiakban az ilyen irányú hívásokat kivettem a további vizsgálatokból.

Az adatok megismerése sokszor grafikonokkal a legegyszerűbb és legszemléletesebb, így a kiinduló adatokból is készítettem ábrákat. Az adatokat Clementine segítségével összegeztem, majd az adatokat Microsoft Excelbe vittem át és ott készítettem el az ábrákat, melyek közül az alábbiak voltak érdekesebbek. A 3. ábraán a vizsgált időszakban ábrázoltam az összes hívás összegét, minden előfizetőre nézve. A grafikon függőleges tengelyén az adott nap lebonyolított összes hívás időtartamának összegének percben kifejezett értéke látható. Kimagasló számot mutat a Karácsony és Szilveszter, ami érthető is, hiszen ekkor a legtöbben felhívjuk szeretteinket. A többi csúcsérték jellemzően vasárnapi időpontokat mutat, azonban ezek a csúcsértékek nem túlzottan magasak, így ezekből további szokási következmények nem vonhatók le.

3. ábra A tartási idők összege a vizsgált időintervallumban

A következő ábrán (4. ábra) az adott napra eső összes hívás időtartamából egy átlagot számoltam. Ez látható a grafikon függőleges tengelyén másodpercekben kifejezve. Az ábrán jellegzetes „tüskék” láthatóak, melyek jellemzően vasárnapra esnek. Ez azzal magyarázható, hogy az előfizetők még vasárnap, a következő hét előtt aránylag hosszabb időtartamban beszélnek szeretteikkel. Mivel az adatbányászat korai fázisában már kiszűrtük csak az egyéni előfizetői hívásokat (3.1.1. fejezetben kifejtett okok miatt) ezért a grafikon a cégek hívásait nem tartalmazza, így valószínűleg nem a munka okok miatt indított hívások okozzák a kiugró vasárnapi értékeket.

4. ábra A tartási idők átlaga a vizsgált időintervallumban

A következő ábrán (5. ábra) a vizsgált időintervallumban az egyes napokon megszámoltam, hogy hány darab hívás történt. A „tüskék” ezen a grafikonon is jelentkeztek, azonban itt pont a fordított negatív irányban. Azaz a vasárnapi hívások darabszáma mindig kevesebb, mint az egyéb napokon indított hívások.

5. ábra A hívások darabszáma az adott időintervallumban

A 4. ábraés 5. ábra segítségével azonban egy fontos következtetést vonhatunk le a hívási szokásokról. Az ábrákon ugyanazt a két vasárnapi (2006.01.29. valamint 2006.02.05.) és hétfői (2006.01.30. valamint 2006.02.06.) napot jelöltem meg, mivel általában ez a két nap jelenti a maximumokat és minimumokat. Vasárnap jellemzően kb. 15%-al kevesebb hívást indítunk, mint hétfőn, viszont kb. 40%-al hosszabb (mely nagyjából 100 másodpercnek felel meg) időtartamban beszélgetünk a hívott féllel. Ezzel szemben hétfőn több hívást indítunk, kisebb átlagos híváshosszal. Ez a megállapítás egy fontos hívási szokást jelent.

Azonban a hívásokat nem csak az egyes napokra összegezhetjük, hanem megvizsgálhatjuk azt is, hogy egy nap adott percében hány hívást indítottak. Mindegyik hívásról megállapítottam, hogy a nap mely percében történt, tekintet nélkül arra, hogy a hívás napja hétköznapra vagy hétvégére esett, majd ezeket összegeztem a 6. ábra. Az ábrán két jellegzetes „púpot”fedezhetünk fel. Az első maximumát reggel 8:00 közelében éri el. Ezt követően a délelőtt folyamán kicsit csökken a hívások száma, majd 14:30 körül ismét emelkedni kezd. A második „púp” délután 17:30 körül éri el a maximumát, majd innen fokozatosan csökken az indított hívások mennyisége. Az ábrán nagyon szembetűnő még, hogy a második „púpon” belül tüskéket fedezhetünk fel, melyek szabályosan fél órás időintervallumokkal követik egymást. Valószínűsítjük, hogy ennek oka szoros összefüggésben van a televíziózási szokásokkal, valamint az éppen akkor sugárzott adással. A műsorok többsége általában egész órakor, vagy félkor kezdődnek, így reklámok alatt megnő a hívások mennyisége, majd a műsor alatt nagymértékben rövid idő alatt lezuhan. Végül egy érdekes momentum, hogy a nap végéhez közeledve 23:00-kor még egy utolsó ugrás van a hívások számában, melynek okát nem ismerjük biztosan.

6. ábra A nap perceiben indított hívások darabszáma


3.3.      Adatelőkészítés (Data Preparation)

3.3.1.     Adattisztítás Clementine segítségével

Az adatok további módosítását már az itthoni számítógépen végeztem el a Clementine adatbányászati szoftver segítségével, mivel ezeket a feladatokat csak sokkal nehezebben, vagy egyáltalán nem is lehetett megoldani a piped-mine keretrendszerben.

Az adatok ellenőrzésekor fény derült arra, hogy egy-két heti hívás információban a szokásos [M3] mellékletbeli tarifacsomag kódok helyet egész számok szerepelnek, melyeknek nem tudtuk a jelentését. Szerencsére ezen adatok kijavítása még időben megtörtént, de szükségessé tette az összes eredmény újrafuttatását.

A 3.2.3. fejezetben említettem, hogy jelentős hívási időtartamot jelent az 51-es körzetbe irányuló hívás, vagyis a modemes internet. Ezeket a rekordokat Clementine segítségével eldobtam, mert a későbbi modellezés jobb eredményeket produkált ezen rekordok elhagyásával.

A következő fontos lépés a hívás idejének átalakítása volt, melyet a HIVAS_IDEJE mező tartalmazott. Ez a mező a 3.2.1. fejezetben részletezett módon az 1970. január 1.-e óta eltelt másodperceket tartalmazza. Szerencsére a Clementine szoftverben előre definiált függvények vannak ezen szám átalakítására, így ezeket a másodperceket jelentő számokat könnyűszerrel átalakítottam. Megemlíteném, hogy mivel a tarifacsomagok általában egész órakor váltanak, ezért kezdetben elégségesnek láttam a hívás időpontját úgy átalakítani, hogy dátumot, napot (a hét melyik napja) és órát kapjak. Azonban később kiderült, hogy ez nem elegendő és szükséges lenne percre pontosan tudni a hívások időpontját. Ezért ismét vissza kellett lépni a CRISP-DM módszertan alapján és a perc attribútummal kibővíteni az elemzési adathalmazt.

Ezeket az adattisztítási és átalakítási lépéseket elvégezve előállt az az adathalmaz, melyben már csak egyéni előfizetők adatai vannak (akiknek egy vonaluk van), és nem tartalmaznak internetes hívásokat sem. Így már neki láthattam azon ügyfelek hívásainak kiválasztásához, akik váltottak tarifacsomagot. Ez az eredeti adathalmaz 2 026 352 egyéni ügyfélhez tartozó hívásokat tartalmazza.

3.3.2.     Váltások kiszűrése, váltások száma

Mivel diplomatervem feladata, hogy a tarifacsomagot váltott előfizetők szokását elemezzem, ezért a következő feladatom az volt, hogy a tarifacsomagot váltott ügyfelek hívásait szétválasszam azoktól a hívás rekordoktól, melyek olyan ügyfelekhez tartoztak, akik nem váltottak tarifát.

Ehhez előfizetők azonosítója (D_SZAM) szerint, majd idő szerint sorba rendeztem a hívásokat, mivel a szerverről az adatok havi bontásban lettek átmásolva. Majd megállapítottam, hogy mely rekordpároknál fordul elő az, hogy két időben egymást követő hívás esetén azonos D_SZAM-hoz különböző TARIFACSOMAG_KOD tartozik, azaz mely ügyfeleknél történt váltás. Ezen ügyfelekből egy új adathalmazt készítettem, mely tartalmazta az ügyfelek azonosítóján kívül a tarifacsomag váltását (melyik tarifáról melyikre) illetve a váltás időpontját.

Persze fél éves időintervallumban megesik, hogy egy ügyfél akár 2-szer 3-szor is vált tarifacsomagot. Kétszer váltott tarifacsomagot, 50 186 ügyfél és háromszor 8 086 ügyfél. Azonban ez a szám túl nagy és csak nehezítik a későbbi modellezést, ezért kiválogattam azokat az ügyfeleket, akik csak egyszer tértek át másik számlázási rendszerbe. A futtatás végére 321 191 ilyen ügyfelet találtam, melyet a kiindulási ügyfélszámmal összevetve kiszámítható, hogy fél év alatt az ügyfelek 15,85%-a váltott egyszer számlázási csomagot.

Eloszlás a váltásokról az időintervallumban

Melyik tarifáról melyikre váltottak sokan

Melyik tarifacsomag párt választottam és miért, tarifacsomag információ a netről

3.3.3.     Váltott előfizetők hívásainak kiválasztása

Join, havonként és miért.

Az előbbi két adathalmazt az ügyfél azonosítója alapján összeillesztettem (join), így egy olyan hívási adathalmazt kaptam, amiben csak a tarifacsomagot váltott ügyfelek hívásrekordjai vannak. Ez az adathalmaz ????61 639 742???? rekordot tartalmaz és mérete ????3,6 GB????. Ez mekkora méretű, hány rekordja van.

A két tábla összeillesztése, azokhoz a userekhez tartozó rekordok kiválasztása akik váltottak. Problémák, így hány rekord, mekkora méretű.

Hány rekordból hány lett így, ezek mekkora méretűek

További bontás: azon hívásrekordok kiválasztása, akik egy bizonyos tarifáról egy másikba mentek át

3.3.4.     Elemzési vektorok elkészítése

Váltás előtti hívás-e, melyik hívási típusba esik. A vektor hogyan épül fel, melyik mezőből épül fel, hogy bontottuk fel a hetet.

4.       Ide jön a téma kidolgozása a CRISP-DM szerint.

5.       Szótár és rövidítések jegyzéke

Prediktálás – előrejelzés

CRISP-DM – CRoss Industry Standard Process for Data Mining, Iparágfüggetlen Szabványos Adatbányászati Módszertan

Business Understanding – Üzleti célok meghatározása

Data UnderstandingAz adatok megismerése

Data PreparationAdatelőkészítés

ModelingModellek alkotása

Evaluation – Eredmények kiértékelése

DeploymentAz eredmények üzleti szintű alkalmazása

Filterszűrő

Piped-mine – A SZTAKI által fejlesztett komponens alapú keretrendszer

6.       Irodalomjegyzék

[1]  Jiawei Han − Micheline Kamber: Data mining concepts and techniques (Second Edition)
2006, Morgan Kaufmann Publisher

[2]  Dr. Bodon Ferenc: Adatbányászati algoritmusok, 2008
http://www.cs.bme.hu/~bodon/magyar/adatbanyaszat/tanulmany/

[3]  A CRISP-DM szabvány hivatalos honlapja
http://www.crisp-dm.org/

[4]  A CRISP-DM módszertan
http://www.dss.hu/modszertanok/crisp_dm

[5]  Korábbi félévben általam írt dokumentum a piped-mineról:
http://www.hszk.bme.hu/~fg497/dm/doc/piped-mine.doc

[6]  Az SPSS cég Clementine nevű adatbányász szoftvere:
http://www.spss.hu/clementine/

[7] 


[M1]      melléklet

pipestartOrig.headerfields=D_SZAM

pipestartOrig.headerfields=D_SZAM_KORZET

pipestartOrig.headerfields=D_SZAM_UGYFELCSOPORT

pipestartOrig.headerfields=D_SZAM_BIU

pipestartOrig.headerfields=D_SZAM_INSTALLATION_LINE_NR

pipestartOrig.headerfields=D_SZAM_VONAL_KEZDO_DATUM

pipestartOrig.headerfields=D_SZAM_LESZERELES_DATUM

pipestartOrig.headerfields=D_SZAM_TELEPULESNEV

pipestartOrig.headerfields=D_SZAM_OSS_TERMEK_KOD

pipestartOrig.headerfields=D_SZAM_ADSL_FLAG

pipestartOrig.headerfields=D_SZAM_MEGSZUNTETES_TIPUS

pipestartOrig.headerfields=D_SZAM_UZEMSZUNET

pipestartOrig.headerfields=D_SZAM_HITELKEPESSEG

pipestartOrig.headerfields=D_SZAM_FIZETOKEPESSEG

pipestartOrig.headerfields=D_SZAM_UGYFEL_VONALDARAB_SZAMA

pipestartOrig.headerfields=D_SZAM_VONALALLAPOT



pipestartOrig.headerfields=D_SZAM_NATURE_OF_LINE

pipestartOrig.headerfields=D_SZAM_SERVICE_CATEGORY

pipestartOrig.headerfields=D_SZAM_VONALTIPUS

pipestartOrig.headerfields=D_SZAM_FIZIKAI_MEGVALOSITAS_KOD

pipestartOrig.headerfields=D_SZAM_AHIER2_KOD

pipestartOrig.headerfields=D_SZAM_VALOS_VONAL

pipestartOrig.headerfields=D_SZAM_KSH_KOD

pipestartOrig.bodyfields=B_SZAM

pipestartOrig.bodyfields=B_SZAM_KORZET

pipestartOrig.bodyfields=TARTASIDO

pipestartOrig.bodyfields=IMPULZUSSZAM

pipestartOrig.bodyfields=UJRADIJAZOTT_OSSZEG

pipestartOrig.bodyfields=KORREKCIOS_OSSZEG

pipestartOrig.bodyfields=OCP_KEDV_OSSZEG

pipestartOrig.bodyfields=HIVAS_IDEJE

pipestartOrig.bodyfields=TARIFACSOMAG_KOD

pipestartOrig.bodyfields=OSS_TERMEK_KOD

pipestartOrig.bodyfields=B_SZAM_UGYFELCSOPORT

pipestartOrig.bodyfields=B_SZAM_BIU

pipestartOrig.bodyfields=B_SZAM_INSTALLATION_LINE_NR

pipestartOrig.bodyfields=B_SZAM_VONAL_KEZDO_DATUM

pipestartOrig.bodyfields=B_SZAM_LESZERELES_DATUM

pipestartOrig.bodyfields=B_SZAM_TELEPULESNEV

pipestartOrig.bodyfields=B_SZAM_OSS_TERMEK_KOD

pipestartOrig.bodyfields=B_SZAM_ADSL_FLAG

pipestartOrig.bodyfields=B_SZAM_MEGSZUNTETES_TIPUS

pipestartOrig.bodyfields=B_SZAM_UZEMSZUNET

pipestartOrig.bodyfields=B_SZAM_HITELKEPESSEG

pipestartOrig.bodyfields=B_SZAM_FIZETOKEPESSEG

pipestartOrig.bodyfields=B_SZAM_UGYFEL_VONALDARAB_SZAMA

pipestartOrig.bodyfields=B_SZAM_VONALALLAPOT

pipestartOrig.bodyfields=B_SZAM_NATURE_OF_LINE

pipestartOrig.bodyfields=B_SZAM_SERVICE_CATEGORY

pipestartOrig.bodyfields=B_SZAM_VONALTIPUS

pipestartOrig.bodyfields=B_SZAM_FIZIKAI_MEGVALOSITAS_KOD

pipestartOrig.bodyfields=B_SZAM_AHIER2_KOD

pipestartOrig.bodyfields=B_SZAM_VALOS_VONAL

pipestartOrig.bodyfields=B_SZAM_KSH_KOD


[M2]      melléklet

Excel táblázat, mely az ügyfeleket tartalmazza:

  http://www.hszk.bme.hu/~fg497/dm/doc/ugyfelcsoport_biu.xls

[M3]      melléklet

     Row #             TARIFACSOMAG_KOD TARIFACSOMAG_NEV

     1                      U                                   Ismeretlen

     2                      U                                   Bázis csomag

     3                      BBB                              Barangoló

     4                      CBC                              CBC LTO-S tcs.

     5                      FAV                              Favorit usp.

     6                      HTC                              Bázis csomag

     7                      KKK                             Kontroll

     8                      OPE                              Optimist üzl.

     9                      RUE                              Ritmus üzl.egy.

     10                    SOK                              Új sokatm.tcs.

     11                    SOK                              Sokatmondó tcs.

     12                    TBO                              Turbo ISDN.tcs.

     13                    TST                               Teszt díjcsomag

     14                    V8V                              V8 vállalkozói

     15                    BELU                            Belföldi csomag

     16                    BIZU                             Minimál díjcsom

     17                    BPLU                            Csevegő díjcsom

     18                    FPLU                            Favorit Plusz

     19                    HETU                           Hétvégi csomag

     20                    KORM                          Kormányzati tcs

     21                    MINU                           Mindenkinek cs.

     22                    R100                             Ritmus100

     23                    R200                             Ritmus200

     24                    R300                             Ritmus300

     25                    RITU                             Ritmus csomag

     26                    RUZL                            Ritmus üzleti

     27                    SPEC                            Speciális tcs.

     28                    UFEL                            Üzleti felező

     29                    UTBO                           Üzleti turbó

     30                    VOCA                           VoCATV díjcs.

     31                    BAZIS                           Bázis díjcsom.

     32                    TPCBC                         Teleperc CBC

     33                    TPERC                          Teleperc dcs.

     34                    TPPAR                          Teleperc Part.

     35                    WIMAX                        WIMAX USP.

     36                    FELEZO                       Felező tcs.

     37                    LTCSEV                       Csevegő LTO tcs

     38                    RCSUCS                       Ritmus csúcs

     39                    RHELYI                        Ritmus helyi

     40                    RMOBIL                       Ritmus mobil

     41                    RSTAND                      Ritmus standard

     42                    FEPLUSZ                     FelezőPlusz tcs

     43                    LTOCSEV                    Csevegő LTO tcs

     44                    LTOR100                      R100 CBC tcs.

     45                    R1PLUSZ                     Ritmus100+

     46                    R2PLUSZ                     Ritmus200+

     47                    R3PLUSZ                     Ritmus300+

     48                    RBELFOLD                  Ritmus belföldi


[M4]      melléklet

### Ez a komponens vegzi a fajlba irast
### letrehozzuk majd beallitjuk a parametereit

create.coord=textwriter

coord.filename=fg200510.txt

coord.writeheader=1

coord.separator=|

#coord.link=pipestartOrig

#coord.link=dbg

coord.link=filterelementLakossag

### Ez egy szuro, mely csak a lakossagi elofeizetoket valogatja ki
### azaz azokat a sorokat, ahol D_SZAM_BIU=1

create.filterelementLakossag=filterelement

filterelementLakossag.link=filterelementVonaldarab

filterelementLakossag.create.int32filter1=int32filter

filterelementLakossag.int32filter1.field_name=D_SZAM_BIU

filterelementLakossag.int32filter1.op=!=

filterelementLakossag.int32filter1.value=1

filterelementLakossag.filterobject=int32filter1

### Az 1 vonaldarabszamu ugyfelek kivalogatasa
### azaz ahol D_SZAM_UGYFEL_VONALDARAB_SZAMA=1

create.filterelementVonaldarab=filterelement

#filterelementVonaldarab.link=dbg

filterelementVonaldarab.link=pipestartOrig

filterelementVonaldarab.create.int32filter2=int32filter

filterelementVonaldarab.int32filter2.field_name=D_SZAM_UGYFEL_VONALDARAB_SZAMA

filterelementVonaldarab.int32filter2.op=!=

filterelementVonaldarab.int32filter2.value=1

filterelementVonaldarab.filterobject=int32filter2

### Ez egy hasznos debug eszkoz,
### ez csak maxnumbernyi embert porget vegig a rendszeren

create.dbg=sampling_debug

dbg.link=pipestartOrig

dbg.maxnumber=50000

### Ez a kitomorito elem, itt adom meg hogy melyik filebol dolgozzon
### es hogy milyen mezoket csomagoljon ki.
### A kitomorito elem neve legyen: pipestartOrig

create.pipestartOrig=decoder

#### Ekkor a temp file-okat eltunteti maga utan

#pipestartOrig.file_operation=-1

#### Ekkor meghagyja a temp file-okat

#pipestartOrig.file_operation=0

#### Ekkor kepes meglevo tempfileokbol dolgozni

#pipestartOrig.file_operation=1

### Bementi fajlok megadasa

pipestartOrig.sourcefilename=/export/1/compressed_data/20051003-20051009.dat

pipestartOrig.sourcefilename=/export/1/compressed_data/20051010-20051016.dat

pipestartOrig.sourcefilename=/export/1/compressed_data/20051017-20051023.dat

pipestartOrig.sourcefilename=/export/1/compressed_data/20051024-20051030.dat

### A kivant attributumok beallitasa

pipestartOrig.headerfields=D_SZAM

pipestartOrig.headerfields=D_SZAM_KORZET

pipestartOrig.headerfields=D_SZAM_BIU

pipestartOrig.bodyfields=B_SZAM_KORZET

pipestartOrig.bodyfields=TARTASIDO

pipestartOrig.bodyfields=HIVAS_IDEJE

pipestartOrig.bodyfields=TARIFACSOMAG_KOD



[1] Tudásfeltárás adatbázisokból − KDD: Knowledge Discovery in Databases

[2] Magyar Tudományos Akadémia Számítástechnikai és Automatizálási Kutató Intézet

[3] string: a programozásban és adatbázisokban használt adattípus, mely karakterek füzére

[4] integer: röviden „int” olyan adattípus, mely csak egész számokat tartalmazhat

[5] rekord: az angol record szóból, itt az adatbázis egy adott sorát jelenti

Találat: 1740