Értékesítési elemzés OLAP kockával Önálló laboratóriumi beszámoló

Készítette: Szabó Péter

Konzulens: Pálfi Attila

Dátum: 2011.05.05.

Tárgykód: VIETA386

Budapesti Műszaki- és Gazdaságtudományi Egyetem

Villamosmérnöki és Informatikai Kar

Elektronikai Technológia Tanszék

2

Tartalomjegyzék

Tartalomjegyzék ......................................................................................................................... 2

Bevezetés .................................................................................................................................... 3

1. A feladat bemutatása .......................................................................................................... 3

1.1. A feladat szoftver specifikus bemutatása ..................................................................... 4

2. A feladat által érintett ismeretanyag ................................................................................... 4

2.1. Árképzési gyakorlatok ................................................................................................. 5

2.1.1. Személyre szabott árképzés .................................................................................. 6

2.1.2. Nem lineáris árképzés ........................................................................................... 8

2.2. Adattárházak ................................................................................................................ 8

2.3. Az OLAP kocka ......................................................................................................... 10

2.4. Microsoft Dynamics NAV funkcionális áttekintése .................................................. 11

2.5. Árképzés Microsoft Dynamics NAV környezetben .................................................. 12

3. Az önálló laboratóriumi feladat megvalósítása ................................................................ 13

3.1. A fejlesztőkörnyezet kialakítása ................................................................................ 14

3.2. A Microsoft Dynamics NAV adatstruktúrájának megismerése................................. 14

3.3. Az adattárház struktúrájának kialakítása ................................................................... 15

3.4. Ismerkedés a Business Intelligence Development Studio-val ................................... 18

3.5. Az ETL folyamat elkészítése ..................................................................................... 18

3.5.1. A dimenziótáblák feltöltése ................................................................................ 19

3.5.2. A ténytábla feltöltése .......................................................................................... 21

3.6. Az OLAP kocka felépítése......................................................................................... 24

3.6.1. Dimenziók definiálása ........................................................................................ 24

3.6.2. Kocka építése ...................................................................................................... 25

3.7. Adatbázis kezelő cseréje ............................................................................................ 25

3.8. Ár kialakítása Excel 2010-ben ................................................................................... 26

3.9. Egyéni ár, akciós ár meghatározása ........................................................................... 27

4. Az elkészített implementáció üzleti jelentősége ............................................................... 30

5. Irodalomjegyzék ............................................................................................................... 32

6. Táblázatjegyzék ................................................................................................................ 32

7. Képletjegyzék ................................................................................................................... 32

8. Ábrajegyzék ...................................................................................................................... 32

3

Bevezetés

A feladatom egy értékesítési elemző rendszer kidolgozása volt. A kész rendszer használatát

nem tartom egy olyan kaliberű feladatnak, amit a vállalat IT dolgozójának kellene elvé-

geznie, sokkal inkább a marketinges(ek)nek. Ezért a feladat megoldása során végig az ve-

zérelt, hogy úgy alakítsam ki a környezetet, hogy az minél jobban elfedje a részleteket és

ne mutasson zavaróan sok adatot egy szakmán kívülinek.

Az egyes modulok vezérlése grafikus felületről néhány kattintással elvégezhető az adatok

áttöltésétől kezdve a kocka felépítésén át az elemzésig. Az elemzésből kinyert adatokat is

inkább Visual Basic (VB) Script-tel átalakítottam egy könnyen átlátható Excel munkafü-

zetbe, hogy ott az árakat meghatározó marketing szakembernek minél kevesebb felesleges

adat vonja el a figyelmét a feladatáról. Majd miután végzett munkájával, megint pár kattin-

tással le tud futtatni egy adatbázis folyamatot annak részletes ismerete nélkül, ezzel létre-

jönnek az új árlisták a vállalatirányítási rendszerben.

Továbbá célom volt még, hogy az elkészített komponensek kellően általánosak legyenek

ahhoz, hogy módosításuk egyszerű legyen, és a részfeladatok különüljenek el minél job-

ban, hogy azokat akár egymástól függetlenül is lehessen cserélni.

1. A feladat bemutatása Az önálló laboratóriumi feladatom egy fiktív vállalat, a Cronus Rt. értékesítési elemzése

OLAP (On-Line Analitical Process) használatával. A munkámban eladó által irányított

piacot fogok bemutatni, így az alkalmazott árképzési stratégia is ennek megfelelően kerül

kiválasztásra. Az eladó által irányított piacon az alábbi peremfeltételeket kell elfogadnunk:

az eladó tökételesen tisztában van az általa kínált áru értékével, minőségével, a többi piaci

szereplő helyzetével, a vevők közti információáramlás tökéletlen, azok csak a keresleti

árrugalmasságukon keresztül, vásárlási hajlandóságukkal tudják befolyásolni a keres-

let/kínálat alakulását. Az eladók a vevők közti tökéleten információáramlást kihasználva

kerülnek olyan pozícióba, hogy ők tudják kialakítani az árakat. (A modellezett piaci kö-

rülményekről részletesen a 2.1.-es fejezetben lesz szó.)

A feladatot Microsoft technológiák felhasználásával oldottam meg.

Az értékesítési elemzés során a következő problémákkal kerültem szembe:

1. Ki kellett alakítanom egy a vállalatirányítási rendszert támogató virtuális környeze-

tet, melyben a feladatom el tudtam végezni. Ehhez fel kellett kutatni a megfelelő

szoftvereket, valamint fel kellett készíteni azokat az egymás közti adatáramlásra.

2. A vállalatirányítási rendszer adatstruktúráját át kellett alakítanom egy, a számomra

megfelelő adattárház struktúrává, amelybe be kellett töltenem a szükséges adatokat.

Implementálnom kellett az ehhez szükséges áttöltő modulokat.

3. Fel kellett készíteni az adattárházat, hogy azon el tudjam végezni az elemzéseket,

azaz fel kellet építeni rá egy OLAP kockát.

4. Módosítani kellett a vállalat árazási rendszerét az elemzés következtében megho-

zott döntéseknek megfelelően.

4

A tervezett feladat blokkdiagramja:

NAV

AdattárházExcel kliens

Elemzés

Feltétel

Árlista

1. ábra – Az elvégzett részfeladatok

1.1. A feladat szoftver specifikus bemutatása

A feladatom megoldása során a Microsoft Dynamics NAV vállalatirányítási rendszert

használtam, egy demó vállalaton, a Cronus Rt.-n. A vállalatirányítási rendszer az adatok

tárolására MS SQL Server-t használ. Ezen az adatbázis szerveren hoztam létre egy csillag

sémás adattárházat, amiben az elemzéshez ténylegesen szükséges és hasznos adatokat tá-

roltam el.

A vállalatirányítási rendszer által tárolt adatok, adatstruktúrák logikai felépítése eltér az

általam megkívánttól, ezért azok megvalósítása érdekében el kellett készítenem egy áttöltő

modult, amely az áttöltésen felül át is alakítja a Dynamics NAV által használt adatstruktú-

rákat az adattárházamban használtnak megfelelő formára. Ezen áttöltő modult Visual

Studio-ban készítettem el.

Miután elkészült az adattárház és fel van töltve a szükséges adatokkal, felépítettem arra az

OLAP kockát, melyre, mint adatforrásra ezután rácsatlakozom Excelből és ott ki tudom

választani a kocka egyes dimenzióit, melyek az elemzésben különálló csoportokként jelen-

nek meg. A választás azért esett az Excelre, mint az elemzést megvalósító programra, mert

fejlett támogatás létezik bent a kockákra és egyszerűen lehet benne szemléletes diagramo-

kat létrehozni.

Ezen lehetőségek még életszerűbbé teszik a megvalósítást, hiszen a stratégiai döntéseket a

vezetők hozzák, akikre általában vagy nem jellemző az informatikai rendszerek mély isme-

rete vagy nem rendelkeznek túl részletes információkkal a tényleges marketing tevékeny-

ségről, csak a számok és arányok fontosak nekik.

Ahhoz azonban, hogy a vezetői döntéseket operatív megvalósítás is kövessen, azok ered-

ményét vissza kell írni a vállalatirányítási rendszer árazási modulja által használt táblákba

a megfelelő formátumban.

2. A feladat által érintett ismeretanyag A feladatom megoldásához szükséges ismeretanyag túlmutat a mérnök informatikus kép-

zés eddigi tantárgyainak tematikáján, ezért ebben a fejezetben elkészítettem a főbb érintett

5

területek rövid elméleti összefoglalóját. Így próbálom meg közös alapokra helyezni a dol-

gozatomban a későbbiekben előforduló fogalmakat, kifejezéseket.

2.1. Árképzési gyakorlatok [2] [4]

Az árképzés dinamikája szempontjából két csoportba szokásos felosztani az árazási straté-

giákat. Ezeket részletesen az 1. táblázat mutatja be.

1. táblázat - Árazási mechanizmusok és az árazást befolyásoló tényezők a statikus és a dinamikus árazású piacokon.

Az árazás dina-

mikája

Árazás alapme-

chanizmusa

Típusai Az árazást befo-

lyásoló tényezők

a kínálat oldalán

Az árazást befo-

lyásoló tényezők

a kereslet olda-

lán

Statikus Eladó által „dik-

tált” árazás,

hagyományos

listaárakkal

Diszkontárak Értékesítési csa-

torna

Szezonális keres-

let, divat

Eladó által „dik-

tált” árazás,

speciális diffe-

renciáláson

nyugvó formái

Szegmentálás,

előfizetés, áru-

kapcsolás

Eladott mennyi-

ség. A javak ösz-

szekapcsolása

Különböző cso-

portokba tartozó

vevők eltérő árér-

zékenysége

Dinamikus Vevői aktív ár-

alkotó szerepet

feltételező mo-

dellek

Aukció, tőzsde,

csoportos vásárlás

A termék jellege,

az eladók száma

Vevői szolidari-

tás, potenciális

vevők száma

Az eladó által

irányított, a ve-

vőket elszigetelő

módszerek

Árak személyre

szabása, termék-

változatok, cso-

magban történő

értékesítés

A termék sze-

mélyre szabásá-

nak lehetőségei, a

termékek adott

volumene

A vevőkről be-

gyűjthető infor-

mációk, adatbá-

nyászat

A statikus árazási stratégiák jól illeszkednek az ipari klasszicizmus szelleméhez, vagyis,

hogy a kínálati oldal a domináns. Az árakat elsősorban az eladók szabják meg, úgynevezett

„one-to-many” módon, amikor a vállalat a vevőkre, mint fogyasztók tömegére tekint. Eb-

ben az esetben a vevők közti információáramlás tökéletlen, a vevők emiatt nem tudnak élni

a tömegükből adódó lehetőségeikkel a kedvezőbb ár kialakítására nézve, azt csak fizetési

hajlandóságukon és a keresleti árrugalmasságon keresztül, közvetetten képesek befolyásol-

ni.

A dinamikus árképzési stratégia kiteljesedését nagymértékben elősegítette a web kettes

világ térhódítása. Ekkor ugyanis a technikai fejlődés döbbenetesen fellendítette az infor-

máció áramlását. Többé már nem voltak elszigeteltek a vevők. Az információ minden hon-

nét ömlött rájuk, a kereső szolgáltatásokkal minden elérhetővé vált, amit csak meg akartak

tudni egy termékről. Ezáltal elillant az eladók előnye. A vevők ettől a pillanattól kezdve

pontosan meg tudták állapítani az áruk és a csatolt szolgáltatások értékét és egy adott ér-

tékhez pillanatok alatt meg tudták határozni a legkedvezőbb árat, vagy az adott áron elér-

hető legkedvezőbb szolgáltatásokat. A jól informált vevők az árak diktálóivá váltak. Vil-

6

lámgyorsan terjedni kezdtek a különböző aukciós oldalak, tőzsdei mintára szerveződő

adok-veszek típusú portálok és a csoportos vásárlásra buzdító site-ok.

Az internet adta lehetőségekre azonban nem csak a vevők figyeltek fel, az eladók is gyor-

san idomultak a változásokhoz, érthető módon céljuk a mielőbbi visszaszorítása volt az új

trendnek és az ár diktálási jogának visszavétele a vevőktől.

A vevők egyre magabiztosabban mozognak a web áruházakban, azokra ők leginkább ké-

nyelmi funkcióként tekintenek, valamint informálódnak rajtuk keresztül az egyes termékek

árairól, azonban keresgélésük során rengeteg információt hagynak a rendszerben maguk

után, amelyek rendkívül hasznosak az eladók számára a vásárlói szokások feltérképezésé-

hez. Ezen információk alapján az árdiktálás visszaszerzéséhez a cél a vevők megosztása,

egyéni árak, csoportokra szabott kedvezmények kialakítása.

E felhasználói adatok elemzése és az ügyfelek szegmentációja hatékony megoldás lehet

annak a klasszikus dilemmának a kezelésében, melyben az eladónak egyetlen egy árat kell

meghatároznia. Ha ezt az árat azonban túl magasra teszi, akkor ez sokakat elriaszt a vásár-

lástól, akik csak mérsékeltebb áron mutatnának hajlandóságot arra. Ha az ár túl alacsony,

akkor pedig a vállalat a haszon egy részét azoknál a fogyasztóknál hagyja, akik hajlandóak

lettek volna többet is áldozni a termékre, szolgáltatásra.

Dolgozatomban a vevők szegmentációra építő módszereket vizsgáltam.

2.1.1. Személyre szabott árképzés [4]

Az előző bekezdésekből világossá válhatott, hogy a fogyasztó által érzékelt értéknek kitün-

tetett szerepe van az árképzés során. Például ha rohanunk a vonatra, és közben szeretnénk

ételt vásárolni magunknak az útra, akkor a vasútállomáson a büfében vásárolható szendvics

felértékelődik bennünk, mert a szendvics értékébe az az idő is bele fog számítani, amit

azzal nyerünk, hogy nem kell a messzebb lévő sarki kisboltba kiszaladnunk. Ezért cserébe

hajlandóak vagyunk többet fizetni a büfében, csakhogy időt nyerjünk. Ebben és az ilyen

helyzetek minél jobb felismerésében rejlik a személyre szabott árképzés profitnövelő lehe-

tősége.

A személyre szabott árak logikus magyarázata a következőkben rejlik: egy adott ter-

mék/szolgáltatás keresleti görbéjét tekintsük adottnak, azon nem tudunk változtatni. Ekkor

az értékesítésből adódó profit az előállítási költség és a bevétel különbsége, a 2. ábrán lát-

ható téglalap területe. Látható, hogy a teljes elérhető bevétel a háromszög alatti terület len-

ne, de ettől messze elmarad a vállalat. A maximális bevételtől való elmaradás a két három-

szög területével magyarázható. Elszalasztott nyereség alatt azt a mennyiséget értjük,

amennyivel többet lettek volna hajlandóak áldozni a vásárlók, de a vállalat annál alacso-

nyabb árat szabtunk ki nekik, asztalon hagyottnak pedig azt a mennyiséget nevezzük, amit

azért bukik el, mert ezen ügyfelek nem vásárolják meg a szolgáltatást a jelenlegi áron, de

annál alacsonyabban megvették volna. Egyik eset sem szerencsés, ezért ezen háromszögek

területének minimalizálása és ezáltal a profit maximalizálása a cél.

7

2. ábra – A profitnégyzet a hozzá tartozó háromszögekkel

3. ábra – Több ár meghatározása

A 2. és 3. ábra alapján, a teljesség igénye nélkül belátható, ha több árat határozunk meg,

ezáltal egyre jobban szétosztjuk a vásárlókat, akkor a vállalat árbevétele és ezáltal a profit-

ja csökkenő ütemben, de növekszik ugyan. Maximális akkor lesz, ha a négyszögek terület-

összege megegyezik a háromszög területével, ezáltal az ügyfelek szeparációja teljessé vá-

lik, azaz minden vevőhöz egyedi árat határozunk meg.

Azon felhasználók megtalálása, akik hajlandóak többet fizetni, mindegy, hogy milyen mó-

don történik, úgyis nyerünk rajta és megéri a fáradságot, amennyiben az így elért nyere-

ségnövekedés fedezi a többletmunka költségét. (csökkenő hasznosság elve) A gyakorlatban

emellett fontos eltérés az elmélethez képest, hogy a vásárlók jól definiált többletszolgálta-

8

tásokat várnak el a többletfizetésért, ezért nem finomodhatnak a téglalapok minden határon

túl.

A személyre szabott ár kialakítása történhet:

földrajzi alapon (vasúti büfé példája)

vásárolt mennyiség alapján (lásd: 2.1.2 Nem lineáris árképzés)

kínált szolgáltatás színvonal alapján (1. és 2. osztályú vasúti menetjegyek)

vásárlás ideje alapján (előfoglalási kedvezmények)

A módszer sikerességére ékes példa Sir Collin Marshall, a British Airways elnökének nyi-

latkozata az ár „kismértékű” személyre szabásának eredményükre gyakorolt hatásáról:

„… az utazóközönség nagy rész meghatározott áron fog utazni… [de] néhányan közülük

valamivel többet fognak fizetni. Hangsúlyozom azonban, hogy amikor „kismértékű” kü-

lönbségekről beszélek, akkor arra is gondolok. Esetünkben 5%-os átlagos eltérésről be-

szélhetünk. […] Ez az 5% plusz 440 millió $-t hoz évente.”

2.1.2. Nem lineáris árképzés [4]

Sok vezető költségcsökkenéssel magyarázza a nem lineáris árszabás bevezetését. A ked-

vezmények hatására a megnövekedett rendelési tételnagyság miatt csökkennek az eladó

szállítási és raktározási költségei. Nem lineáris árképzés során mennyiségi kedvezményben

részesíti a vállalat a partnereit, azaz az egyes eladott termékeken érvényesített határnyere-

ség egyre csökken az értékesített mennyiség növekedésekor. Jövedelmező lehet a nem li-

neáris árképzési stratégia akkor, ha a kedvezmény megnöveli a vásárlási hajlandóságot, így

az eladások megnövekedett száma kompenzálja a határnyereség csökkenését. Tipikus eset

a nem lineáris árképzésre a bérletek árusítása. Például egy színházi előadás 1000 Ft-ba

kerül, de az 5 alkalmas bérletet már 4000 Ft-ért meg lehet vásárolni.

2.2. Adattárházak [5] [8]

Az adattárház az információtechnológia viszonylag frissen önálló életre kelt ága, mintegy

egy évtizedes múltra visszatekintő területe. Rohamléptekkel, egyszerre több irányba fejlő-

dő, kiforratlan és már bizonyított technológiák halmaza, kevés elismert szabvánnyal, sok

eltérő szolgáltatással és termékkel. Nehéz rá jó definíciót adni. Bill Inmon, a téma egyik

apostolának legtöbbet idézett definíciója így szól: "A data warehouse is a subject oriented,

integrated, nonvolatile, and time variant collection of data in support of management's

decisions.", vagyis tárgy orientált, integrált, tartós és idő független gyűjteménye az adatok-

nak, mely a vezetői döntéshozást támogatja. Jobban végiggondolva a definíciót, kellően

világos képet kaphatunk az adattárházak miben létéről:

Subject oriented (tárgy orientált): Az adattárházakat mindig valamilyen jól definiált

céllal hozzuk létre, azok meghatározott adatok köré épülnek, például az értékesítési

adatok köré.

Integrated (integrált): Az előz pontban említettet tárgyorientált, adatvezérelt terve-

zéshez szorosan kapcsolódik az integráltság fogalma abban az értelemben, hogy az

adattárházban tárolt adatokat egy az adott tárgyterületre jellemzően csoportosítva

célszerű tárolni.

Nonvolatile (nem illékony): Azaz alapelvárás az adattárházba betöltött adatokkal

szemben, hogy azok változatlanok legyenek. Amennyiben a forrásrendszer mégis

megváltoztatná azokat, abban az esetben megfelelő időbélyegekkel kell ellátni őket.

Time variant (időfüggetlen): Az adatokat általában jelen pillanatban töltjük be az

adattárházba, de az elemzéseket múltbeli forrásokra támaszkodva végezzük el, és

abból következtetünk jövőbeli eseményekre. Ezért az adatokat időponttól függetle-

9

nül kell időszakokhoz tárolnunk, hogy abból a szükséges riportok könnyen elérhe-

tők legyenek.

Az adattárház műveletek alatt általában a következőket értjük:

a) Adatkinyerés tranzakciós, vagy más rendszerből, pl.: a vállalatirányítási rendszer-

ből

b) A kinyert adatok átalakítása a beszámoló elkészítéséhez alkalmas formára.

c) A riportok, beszámolók elérhetővé tétele a döntéshozók számára.

Az adattárház felépítése e céloknak megfelelően eltér az Adatbázisok című tárgyból tanul-

taktól. [1] Ebben az esetben az elsődleges szempont az adatok hatékony kinyerése az elem-

zések elkészítéséhez, azaz megengedhető némi redundancia a teljesítmény növeléséhez. Az

adattárházakat általában csillag vagy hópihe sémában építik fel. Mindkét esetben az elem-

zés szempontjából fontos adatokat a ténytáblában helyezik el. Ide kerül be a vállalatirányí-

tási rendszer törzs adatállományának megfelelő transzformáltja. Eköré, az úgynevezett

dimenzió táblákba kerülnek be azon információk, melyek szerint a szűréseket, csoportosí-

tásokat elkészíthetik. Ezen táblákban, az ezek adatsémáiban, a köztük kapcsolatokban tér el

egymástól a csillag és a hópihe séma. Csillagsémánál az elemzési dimenziók idegen kulcs-

csal kapcsolódnak közvetlenül a ténytáblához a 4. ábrán látható módon.

4. ábra – Csillagséma ER diagramja

Ezzel szemben hópihe séma esetében az egyes dimenziótáblák a természetes logikát kö-

vetve egymással is kapcsolatban álnak, például az egyes üzletek városokban vannak, a vá-

rosok megyékhez tartoznak, és így tovább. A hópihe séma ER (Entitás Relációs) diagram-

jára példa az 5. ábrán látható.

10

5. ábra – Hópihe séma ER diagramja

A témám feldolgozása során csillag sémás adattárházat építettem fel.

A csillag séma összehasonlítása a hópihével:

Előnyei:

egyszerű, intuitív adatmodell

használata kevés join adatbázis műveletet igényel

használata kevés tábla olvasását igényli

könnyű megvalósíthatóság, a modell meta adatai (adatokat leíró adat) egyszerűek

Hátrányai:

aggregációk (összegek) képzése nehézkes

nagy dimenziótáblák esetén a hierarchiakezelés nagyon lassíthatja a lekérdezéseket

a dimenzióadatok tárolása redundáns

2.3. Az OLAP kocka

A vállalatirányítás rendszerek On Line Transaction Process (OLTP) elven működnek, azaz

fő rendező elvük a tranzakciók végrehajtása. A felhasználók, a programok apró, elemi mű-

veletek sorozatát hajtják végre a tranzakciókban, ezáltal egyes adatbázis objektumok álla-

potát kérdezik le, frissítik egymástól függetlenül, konkurens módon.

Az elemzésekhez azonban ez a megközelítés nem megfelelő. Ilyen célokra az On Line

Analysis Process (OLAP) megközelítés használatos. Az OLAP módszerek mindig maguk-

ba foglalják az adatok interaktív lekérdezését, valamint azok elemzését is. A felépített adat-

tárház adatstruktúrája már úgy van megtervezve, hogy az a lehető leghatékonyabban segít-

se ezt a szemléletet, emiatt az adattárház és az OLAP fogalmak a gyakorlatban teljesen

összefonódtak.

11

6. ábra – Értékesítési OLAP kocka 3 dimenziós reprezentációja

Az OLAP kocka egy adatszerkezet az adattárházban tárolt adatok elemzéséhez, csoportosí-

tásához. A kocka egyes dimenzióit az adattárház dimenzió táblái képzik, ezek szerint tud-

juk beazonosítani a ténytáblában tárolt adatok egyes összetett részhalmazait. A kocka fel-

építését a 6. ábra tartalmazza. Gyakran tárolják el az egyes termékek a részhalmazok egye-

sítésekor, aggregálásukkor az egyes halmazok összesített mutatószámait. Így jelentős telje-

sítménynövekedés érhető el. A gyakorlatban természetesen több dimenziót is alkalmazha-

tunk, azonban ez ritkán indokolt és könnyen vezethet nehezen áttekinthető végeredmény-

hez. A sok dimenzió szerinti analízis már inkább az adatbányászat területébe nyúlik át.

2.4. Microsoft Dynamics NAV funkcionális áttekintése

A Dynamics NAV (más nevén Navision) a Microsoft ERP rendszere, kifejezetten kis- és

középvállalatok számára. A vállalat napi teendőinek ellátásához teljes körű segítséget

nyújt, minden elvégzendő vállalati feladathoz rendelkezik megfelelő modullal.

Főbb moduljai a pénzügy, kereskedelem, CRM, termelésirányítás, raktárkezelés, projekt

menedzsment, humán erőforrás és üzleti elemzés.

A felhasználói felület felépítése és a megjelenő űrlapok nagyban hasonlítanak a félév során

a QAD EA-ban és SAP Business One-ban megismertekre.

A pénzügyi modulban állíthatók be a vállalat főkönyvi adatai, kezelhetők az eszközök és a

bankszámlák, de itt kérdezhetők le a vállalat cash-flow és likviditási adatai is.

A kereskedelem modulban találhatók meg a szállítói beszerzéseket és az értékesítést támo-

gató modulok. Ezek egymáshoz rendkívül hasonlóak, hiszen a két műveletnél ugyanazon

folyamatnak a két oldalán van a vállalat, ettől eltekintve a fogalmak hasonlóak: ajánlatok,

megrendelések, visszaigazolások, számlák.

A CRM rendszeren keresztül kerül kapcsolatba a termelés a vevőkkel, itt kerülnek megva-

lósításra azon funkciók, melyek az ügyféladatok kiértékelésében és az árképzésben támo-

gatják a felhasználót.

A termelésirányítási modulban nyílik lehetőségünk az agyagjegyzékek, a termékútvonalak,

a kapacitás, az ütemezés, és a gyártási megrendelések létrehozására, karbantartására.

A raktározás blokkjában a belső és külső árumozgatások összehangolása történik meg a

tárolási költségek minimalizálása és a vevői kiszolgálás színvonalának növelése érdekében.

A projektmenedzsment menüponton keresztül érhetők el az egyes projektek adatai, mint

például az előrehaladása, költségei.

12

A humán erőforrás modulban tarthatók karban az egyes dolgozók törzsadatai, mint a mun-

kaidő, a munkabér, az alkalmazottakhoz kapcsolódó ráfordítások vagy a személyi jellegű

költségek.

Az üzleti elemzés modul a vállalat főbb mutatóit fogja össze egy csoportba, azokat viszo-

nyítja a tervezési adatokhoz.

Könyvelés

Keresés

Ajánlat

Megrendelés

Szállító Vevő

Megkeresés

Ajánlat

Megrendelés

Készletvizsgálat

RaktárTermelésProjektSzerviz

Anyag raktár

Szállítás Szállítás

Szállítás

SzámlaSzámlázás Számlázás

Bank ÁtutalásÁtutalás

7. ábra – Üzleti folyamatok egymásra épülése a Microsoft Dynamics NAV-ban

2.5. Árképzés Microsoft Dynamics NAV környezetben

Az árképzéssel elsősorban az értékesítés kapcsán kell foglalkoznunk a Navisionben. Ennek

elhelyezkedése a program hierarchiájában a 7. ábrán látható. Mivel ez képzi a feladatom

központi problémáját, ezért a későbbiekben erre fektetek nagyobb hangsúlyt.

Az árképzésért nem egy modul felelős, az egy hosszú folyamat, mely több rendszert is

érint. Alapvetően az CRM hatásköréhez tartozik azon vevők felderítése, akik hajlandóak

magasabb árat fizetni a nekik kínált termékért, de mint a 8. ábra is mutatja, ezt nem képes

egymagában ellátni. Nem kaphatunk pontos képet a vevőinkről, anélkül, hogy ne ismer-

nénk a múltjukat, korábbi vásárlásaikat, szokásaikat. Ehhez a történeti adatokhoz kell visz-

szanyúlnunk, melyeket a vállalatirányítási rendszer adatbázisában találunk. A kialakítandó

árat mindig a jelenlegi helyzet alapján, a jövőbeni tervek érdekében, a múltbéli adatok fi-

gyelembevételével kell meghatározni. Ez a vállalati rendszer részeinek a szerves együtt

működését követeli meg. Az ERP és a CRM közösen kísérik végig a vevőt a megkereséstől

a termék egész életútján a 8. ábrán látható módon.

13

8. ábra - A CRM és az ERP kapcsolata az áralkotásban

Az árakat alapbeállításként a terméktörzsben lehet definiálni. Ettől eltérni ennek módosítá-

sa nélkül az Eladás és marketing/Készlet és árképzés/Eladási ár munkalapon lehet. Itt tu-

dunk definiálni különféle kedvezményeket, egyedi árakat.

Lehetőségünk van beállítani az új árazási stratégia kezdő és befejezési dátumát, annak ér-

vényességi körét, mind termékre, mint vásárlóra, vagy akár könyvelési vagy árcsoportra.

Új egyéni ár létrehozásakor az alábbi paraméterek megadására van szükség:

Kezdési/befejezési dátum: az ár érvényességi idejét szabja meg

Eladás típusa: itt adható meg, hogy az Eladási kód mezőben szereplő érték mely

paraméterre értendő

Cikkszám: az új ár az itt megadott termékre lesz csak érvényes

Mértékegység

Minimális mennyiség: azt a minimális rendelési mennyiséget jelenti, ami alatt nem

érvényes az egyedi ár

Új egységár: az az ár, amelyen az előbbi feltételek teljesülésekor az adott termék

megvásárolható

Sorengedmény %: az árengedmény az eredeti ár százalékában kifejezve

3. Az önálló laboratóriumi feladat megvalósítása A félév első felében az eddig leírtakban igyekeztem elmélyülni, hogy az elkészített megol-

dásom kellően átgondolt legyen. Úgy vélem, hogy ezen ismeretanyag elsajátítása után kel-

lően tudatosan tudtam nekiállni a probléma vizsgálatának. Ezt követően került megfogal-

mazásra, hogy mi is az a konkrét feladat, mit fogok a félév során elkészíteni.

Ebben a fejezetben a megoldás főbb lépéseit, tervezés fázisait mutatom be. Próbálom tisz-

tázni az egyes tervezői döntésekhez vezető okokat, előzményeket.

14

3.1. A fejlesztőkörnyezet kialakítása

A feladatom a hozzá szükséges fejlesztési környezet kialakításával kezdtem. A megoldás-

ban virtuális gépen futtatok Windows XP Professional SP3 operációs rendszert, és rajta

Microsoft SQL SERVER 2008 R2 Standard adatbázisszervert. Az adatbázis-kezelőt a kö-

vetkező szolgáltatásokkal telepítettem: SQL Server, Analysis Server valamint SQL Server

Business Intelligence Development Studio. A Business Intelligence Development Studio a

Visual Studio 2008 speciális konfigurációja, adatbázis folyamatok fejlesztésére. Az elem-

zéseket Excel 2010 programban készítem el a fejlettebb Analysis Service támogatás miatt.

Az alkalmazott vállalatirányítási rendszer Microsoft Dynamics NAV 5.0.

A Dynamics NAV telepítése után létrehoztam benne a Microsoft Demó vállalatát a Cronus

Rt.-t, azt az adatbázis kiszolgálom tároltam el. Ahhoz, hogy az ERP elérje az adatbázis

szervert a következő beállításokat kellett elvégeznem:

- az xp_ndo.dll elhelyezése az MSSQL telepítési könyvtárában, alapesetben a

C:\Program

Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Binn\xp_ndo.dll

útvonalon [3]

- az SQL szerveren be kellett állítani a xp_ndo_enumusergroups és

xp_ndo_enumusersids távoli eljáráshívásokat (Remote Procedure Call, RPC) [3]

3.2. A Microsoft Dynamics NAV adatstruktúrájának megismerése

Mint minden vállalatirányítási rendszer a Navision is rengeteg adatot tárol el, rendkívül

összetett, először kuszának tűnő struktúrában. Természetesen nem célom ezek részletes

bemutatása, csupán az árelemzés során felhasznál táblák bemutatása és a köztük lévő kap-

csolatok felderítése.

A program telepítésekor és a vállalat létrehozásakor az adatok tárolására két lehetőségünk

van: vagy a merevlemezen tároljuk azt fájlban, vagy adatbázis szerveren. Én ez utóbbit

választottam, ehhez a 3.1-es pontban ismertetett távoli eljáráshívásokat be kellett állítani.

A táblákhoz kétféle módon lehet hozzáférni: közvetlenül megkereshetjük az adatbázisban

azt, vagy Dynamics NAV-ban kiválasztunk egy menüpontot, például az Eladás és marke-

ting/Eladás/Vevők útvonalon feljövő űrlapon tudjuk kezelni a vevői törzsadatainkat. Ekkor

a fejlécben megváltozik a felirat:

9. ábra - A Navision fejléce

A szögletes zárójelek közötti részben olvasható, mely formon járunk, és az mely táblát

használja. Jelen esetben a Vevőkarton táblát használjuk. Az adatbázisban azonban angol

nevükön szerepelnek a táblák. A magyar-angol megfeleltetést a táblanevek között legegy-

szerűbben az Obejct Designer-rel tudjuk megtalálni. Ezt az Eszközök menüből érjük el

vagy a Shift+F12 billentyűkombinációval. A táblák magyar neve nem jelenik meg alapból,

azt külön be kell kapcsolni az oszlopok megjelenítésénél, a Caption-t bepipálva.

Ezek után már tudjuk azonosítani, hogy az adattárházhoz szükséges információk mely táb-

lákból nyerhetjük ki. Az árelemzéshez feladatomban a tényadatokat az Eladás, Eladási

számla és Eladási jóváírás táblákból nyerem főrészt. Ezen bizonylatok adataikat több táb-

lában tárolják el. Minden bizonylathoz tartozik egy fej tábla bejegyzés, ami a partnerek

általános törzsadatait, a kapcsolattartás, számlázás, fizetés, szállítás és a külkereskedelem

adatait tárolja a rendszer. Valamint minden bizonylattípushoz tartozik egy adat tábla is,

amiben a bizonylatok egyes sorai tárolódnak. Itt jelenik meg, a számlaazonosító, mint ide-

15

gen kulcs a számla fejére, a vevő azonosítója, cikkazonosító, mennyiség, egységár, ked-

vezmény, ÁFA, sorösszeg, stb.

10. ábra - A számla általános felépítése

Ahogy a 10. ábra is mutatja, a számlafej és a számlatörzs között egy-több kapcsolat van,

több számlatörzs rekordból és egy fejrekordból épül fel egy számla. Ezenkívül még renge-

teg egyéb kapcsolatban állnak ezen táblák az idegen kulcsaikon keresztül, például a vevő-,

cikk-, könyvelési csoport, fizetési feltételek táblával.

Miután megismertük az OLAP kocka alapjait, és megtaláltuk azon adatokat az ERP-ben,

amik majd a kocka ténytábláját alkothatják, meg kell határozni azon attribútumokat, me-

lyek alkalmasak rá, hogy dimenzióként használjuk őket.

A dimenzió megválasztásakor érdemes előre gondolkodni, hogy melyek lehetnek azok az

adatok, amelyek mentén lehet csoportosítani az adatainkat, és az eredményre is vezethet.

Érdemes lehet például elemezni az egyes cikkek eladásait, vásárlóink fogyasztását, ked-

vezményeiket, területi elhelyezkedésüket, azt, hogy vásárlásaikat mely időszakokra üteme-

zik. Ezek közül a legtöbb adatot pusztán a vállalatirányítási rendszerből ki tudjuk nyerni a

fent ismertetett módon. Én dimenzióként vettem fel, több, a vállalatirányítási rendszerben

használt paramétert, törzsadatot, mint például a könyvelési-, ár-, és kedvezménycsoportot,

a cikkeket, határidőket, vevőket és azok földrajzi elhelyezkedését. Ezen adatok mind az

adatbázis egyes tábláiban érhetők el, melyeket az Object Designer-rel találtam meg.

Az értékesítési elemzéshez lassan minden tábla rendelkezésre állt. Ahhoz azonban, hogy az

elemzés ne csak egy statikus folyamat legyen, hanem a felhasználó könnyedén hozhasson

létre engedményeket, egyedi árakat az eredmények függvényében, meg kellett keresni azt

ahol ezek tárolva vannak. A keresett funkciót megtaláljuk az Eladás és marke-

ting/Eladás/Vevő útvonalon, majd ott az Eladás gombra, majd a Sorengedményekre kat-

tintva. Ezután megkereshetjük a tároló táblát: Vevői sorengedmények.

3.3. Az adattárház struktúrájának kialakítása

Az elemzés megvalósításához az adatokat a vállalatirányítási rendszer adatbázisából át

töltöttem egy adattárházba. Az adattárházban nem a vállalat aktuális „működési” adatai

szerepelnek, hanem az archivált adatok lehető legbővebb gyűjteménye. Itt már nem szem-

pont a vállalat napi ügyeinek a nyomon követése. Mivel az adattárház szerepe, feladata sok

esetben eltér a normál adatbázisokétól, ezért létrehozásukkor is más szempontok szerint

kell eljárni. Az adatbázisba általában adatokat viszünk be, tároljuk azokat, ezért a legfonto-

sabb szempont a struktúra megalkotásakor a redundancia mentesség és a függőségek vesz-

teségmentes feloldása. Lekérdezéseket ritkábban futtatunk, és azok eredményhalmaza a

teljes struktúra viszonylag kis részét fedi le. Emiatt dominál a tárhely kedvezőbb kihaszná-

lása a join műveleteknél elszenvedett plusz műveleti idő felett.

Ezzel szemben az adattárházakban sokkal nagyobb hangsúlyt kap az adatok elérése a dön-

tések meghozatalakor egy jól strukturált, áttekinthető formában. Ezért az információt azzal

a céllal tároljuk, hogy onnét azt szakaszos beírás után többször kinyerjük. Ennek köszönhe-

tően az adat esetleg redundánsan több táblában is elhelyezkedik.

Az adattárház felépítéséhez csillag sémát választottam, főként a kisszámú tábla és a modell

egyszerűsége miatt.

16

A következő táblák szerepelnek benne:

- DimCustomer: A vevők adatait tartalmazó dimenziótábla

- DimDiscountGroup: A vevői árcsoportokat tartalmazó dimenzió

- DimItem: A cikkek tulajdonságai

- DimLocation: A vevők földrajzi elhelyezkedésének dimenziója

- DimPostingGroup: Az ERP-ben tárolt könyvelési csoportok

- DimPriceGroup: A tárolt vevői árcsoportok

- DimTime: Idő dimenzió a könyvelési és szállítási határidőhöz

- FactTable: Az adattárház ténytáblája

Az adattárház tábláit a következő SQL scripttel hoztam létre:

Dimenziótáblák létrehozása:

-- A ténytáblák létrehozása

CREATE TABLE onlab.dbo.DimTime(

[DateKey] int IDENTITY (1, 1) PRIMARY KEY,

[Date] datetime UNIQUE NOT NULL,

[DayNumberOfWeek] int NOT NULL,

[DayNumberOfMonth] int NOT NULL,

[DayNumberOfYear] int NOT NULL,

[WeekNumberOfYear] int NOT NULL,

[MonthNumberOfYear] int NOT NULL,

[QuarterOfYear] int NOT NULL,

[SemesterOfYear] int NOT NULL,

[Year] int NOT NULL,

-- Az idő táblába való beszúrás előtt leellenőrzöm a dátum constraint-

eket.

CONSTRAINT C_DimTable_DNOW CHECK (DayNumberOfWeek BETWEEN '1' AND '7'),

CONSTRAINT C_DimTable_DNOM CHECK (DayNumberOfMonth BETWEEN '1' AND '31'),

CONSTRAINT C_DimTable_DNOY CHECK (DayNumberOfYear BETWEEN '1' AND '366'),

CONSTRAINT C_DimTable_WNOY CHECK (WeekNumberOfYear BETWEEN '1' AND '53'),

CONSTRAINT C_DimTable_MNOY CHECK (MonthNumberOfYear BETWEEN '1' AND

'12'),

CONSTRAINT C_DimTable_QOY CHECK (QuarterOfYear BETWEEN '1' AND '4'),

CONSTRAINT C_DimTable_SOY CHECK (SemesterOfYear BETWEEN '1' AND '2')

);

-- A földrajzi elhelyezkedés táblájának létrehozása

CREATE TABLE onlab.dbo.DimLocation(

[CountryCode] nvarchar(2),

[City] nvarchar(30),

[CustomerID] nvarchar(20) PRIMARY KEY,

[Country] nvarchar(255)

);

-- A könyvelési csoport táblájának létrehozása

CREATE TABLE onlab.dbo.DimPostingGroup(

[PostingCode] int IDENTITY (1, 1) PRIMARY KEY,

[PostingGroup] nvarchar(30) UNIQUE NOT NULL

);

-- A vevői árcsoport táblájának létrehozása

CREATE TABLE onlab.dbo.DimPriceGroup(

[Code] nvarchar(10) PRIMARY KEY NOT NULL,

[Description] nvarchar(30) NOT NULL

);

17

-- A kedvezmény csoport táblájának létrehozása

CREATE TABLE onlab.dbo.DimDiscountGroup(

[Code] nvarchar(10) PRIMARY KEY,

[Description] nvarchar(30) NOT NULL

);

-- Az eszköz tábla létrehozása

CREATE TABLE onlab.dbo.DimItem(

[No] nvarchar(20) NOT NULL PRIMARY KEY,

[Description] nvarchar(30)

);

-- A vevő tábla létrehozása

CREATE TABLE onlab.dbo.DimCustomer(

[IDNumber] varchar(20) PRIMARY KEY NOT NULL,

[Name] varchar(50) UNIQUE NOT NULL

);

A ténytáblában el kell tárolni a dimenziótáblák kulcsait is idegen kulcsként, a függőségek

megőrzéséhez. Emiatt, valamint a tárolt adatok sokfélesége miatt a tábla attribútumainak

száma bőven meghaladja a dimenziótáblákét.

A ténytáblát létrehozó script:

-- A ténytábla létrehozása

CREATE TABLE onlab.dbo.FactTable (

"No_" nvarchar(20),

"Sell-to Customer No_" nvarchar(20),

"Bill-to Name" nvarchar(50),

"Bill-to Address" nvarchar(50),

"Bill-to City" nvarchar(30),

"Posting Date" datetime,

"Shipment Date" datetime,

"Payment Discount %" numeric(38,20),

"Customer Posting Group" nvarchar(10),

"Currency Code" nvarchar(10),

"Currency Factor" numeric(38,20),

"Customer Price Code" nvarchar(10),

"Customer Discount Code" nvarchar(10),

"ItemNo" nvarchar(20),

"Description" nvarchar(50),

"Unit of Measure" nvarchar(10),

"Quantity" numeric(38,20),

"Unit Price" numeric(38,20),

"Unit Cost (LCY)" numeric(38,20),

"VAT %" numeric(38,20),

"Line Discount %" numeric(38,20),

"Line Discount Amount" numeric(38,20),

"Amount" numeric(38,20),

"Amount Including VAT" numeric(38,20),

"Country Code" nvarchar(2),

"Shipment Date Code" int,

"Posting Date Code" int,

"Customer Posting Code" int

);

18

3.4. Ismerkedés a Business Intelligence Development Studio-val [6]

Az MS SQL Server beépítetten tartalmazza a Visual Studio egy speciálisan konfigurált

változatát, a Business Intelligence Development Studio-t, amellyel egy LabView szerű,

grafikus programozói felületen tudunk áttöltő modulokat készíteni.

A program használatának megtanulásához könnyen érthető demók találhatók a

social.msdn.microsoft.com web helyen. A rendszer működésének megismeréséhez, vala-

mint demók készítéséhez elérhető egy AdventureWorks nevű alkalmazás is, mely telepíté-

se során több mintaadatbázist hoz létre a kiszolgálón. Ennek telepítése nagy segítséget je-

lentett a rendszerrel való ismerkedés folyamán.

A félév során megismerkedtem a Business Intelligence Development Studio grafikus prog-

ramozói felületével, és a programozással benne. [7] Az önálló laborom megoldásához a

programban elkészített folyamatok a 12-14. és a 18. ábrákon láthatók.

Az így elkészített folyamatok aciklikus gráfok, melyek csomópontjaiban helyezkednek el

az adatokat átalakító műveletek, élei pedig csővezetékeket hoznak létre az adat áramlásá-

hoz.

3.5. Az ETL folyamat elkészítése

Az adattárház struktúrájának létrehozása önmagában még nem túl nagy feladat, hiszen az

még üres, nincs bent adat. A feltöltése a vállalatirányítási rendszer adatbázisából történik

meg. A Navision adatbázisát tanulmányozva hamar rájöhetünk arra, hogy annak felépítése

nem egyezik meg az előzőekben létrehozott adattárház-struktúrával, az adatokat át kell

alakítani betöltés előtt.

Az ilyen adatbázis folyamatokat Extract, Transform, Load-nak (kinyer, átalakít, betölt

(ETL)) nevezik.

A minél könnyebb továbbfejleszthetőség miatt a következő névkonvenciót vezettem be a

dimenziótáblákra: az általam létrehozott dimenziótábla neve a „Dim” előtaggal kezdődik,

majd utána következik a forrástábla NAV által használt angol neve.

A folyamatot próbáltam a lehetőségeimhez mérten minél inkább automatizálni, hogy üte-

mezetten is futtatható legyen kis változtatással. Az emberi beavatkozás szükségességét

természetesen nem lehet elkerülni, hiszen az árképzés stratégiai döntés.

Az ETL folyamatom state-chart diagramja a 11. ábrán látható. A process elején hozom

létre az adattárház sémáját a fent bemutatott SQL script segítségével. Ezután megkezdődik

a dimenzió táblák adatainak áttöltése az ERP adatbázisából az adattárház megfelelő táblái-

ba. Ezek általában egyszerű SQL lekérdezésekből állnak, majd az eredmény beíródik a

megfelelő adattáblába. Végül az elkészült dimenzió táblák alapján, már fel lehet tölteni a

ténytáblát is. A ténytáblába az adatokat némi átalakítás után az egyes értékesítési bizonyla-

tok soraiból veszem.

19

11. ábra - Az elkészített ETL folyamat state-chart-ja

Ahhoz, hogy az egyes adatfolyamatokat definiálni tudjam, először létre kellett hoznom a

vezérlési folyamatot Visual Studio-ban a state-chart alapján, majd az egyes állapotokat

bővítettem ki adatfolyamokkal.

3.5.1. A dimenziótáblák feltöltése

Az egyes dimenziótáblák feltöltése nagyon hasonlóan néz ki a feladatomban. Ezért részle-

tesen csak a vevői árcsoport szerinti feltöltést ismertetem részletesen, illetve az ehhez kép-

esti eltérésekre térek ki a többi esetben.

A dimenzió táblák feltöltése többnyire egyszerű. A projekthez definiálni kellett egy kap-

csolatot, mely rendelkezik az adatbázishoz való hozzáférést biztosító proterty stringgel.

Ezután létre hoztam az adatfolyamot: két objektum, csővezetékkel összekötve. Kell egy,

ami kiolvas az ERP adatbázisából és egy, ami a kiolvasott adatokat beírja az adattárház

megfelelő táblájába. Az árcsoport táblához tartozó adatfolyamot a 12. ábra mutatja.

20

12. ábra - Egyszerű adatfolyam

Az adatfolyam ténylegesen csak egy forrásból és egy célból áll. A forrásban választható ki,

hogy mely adatkapcsolatból olvasson ki adatokat. Itt beállítottam az ERP adatbázisára mu-

tató korábbi kapcsolat objektumot, ez után kiválaszthatóvá válik, hogy mely táblából aka-

runk olvasni. Emellett elérhető egy saját SQL parancs kiadását lehetővé tevő opció is. Én

azt választottam. A döntésem indoka a következő volt: általában a táblák nagyon sok attri-

bútumot tartalmaznak, ezeknek csak a töredékére van szükségem, ezért csak azokat kér-

deztem le, amik ténylegesen bekerülnek az adattárházba. Így biztosan kisebb lesz az adat-

forgalom az adatbázis szerver és az adattárház között, valamint a folyamat rövidebb pro-

cesszoridőt igényel a kevesebb feldolgozandó adat miatt.

A cél beállítása hasonló a forráséhoz. Itt is ki kell választani a célobjektum leíróját, ezért

definiáltam egy további kapcsolatot, de ez esetben az adattárházhoz. Majd itt is beállítható

a cél adatbázis, illetve annak egy már létező táblája, vagy új tábla hozható létre. Mivel az

adattárházban az adatokat időszakonként töltjük be, ilyen és ehhez hasonló folyamatokkal

ezért az inicializálásnál hoztam létre a táblát, hogy most, az áttöltés során már csak bele

kelljen írni abba. Ezáltal többször használható, bővíthető lesz a projekt. A már létező tábla

attribútumaihoz ezután hozzá kell rendelni az adatfolyam attribútumait, ezt angolul

mapping-nak nevezik. Ez egy egy-egy kapcsolat, amely meghatározza, hogy az adatfolyam

mely adatai pontosan melyik tulajdonságnak feleljenek majd meg a kimeneten. Ha nem

található a bemeneten adat, akkor a kimenetre automatikusan NULL érték kerül.

A többi dimenzió tábla feltöltése ehhez hasonlóan zajlik, természetesen mások a be- és

kimeneti táblák azoknál.

Lényegesebb eltérés van azonban az időt és a földrajzi elhelyezkedést definiáló dimenzió-

táblákban az eddigiekhez képest.

Az idő dimenziónál az adatokat egy Excel táblába generáltam le, az AdventureWorks de-

mótáblájának mintájára, melyet a 13. ábra mutat.

2. táblázat - Az idő dimenzió paramétereit tartalmazó Excel tábla részlete

Tehát az idő dimenziót tartalmazó adattáblát nem adatbázisból, hanem Excel táblából kell

feltölteni. Ehhez speciális kapcsolatot kell létrehozni az adatbázis kapcsolathoz hasonlóan,

amelyben a kapcsolat leíró objektum egy munkafüzetre tartalmaz mutatót. Ezután külön

definiálni kell hozzá új adatforrást a megfelelő állapothoz, amely Excel munkafüzetből

21

képes adatokat beolvasni. A kimenet kezelése megegyezik az árcsoport dimenziónál leír-

takkal, hiszen a cél itt is egy tábla lesz az adattárházban.

A dimenziótáblák feltöltése közül a legösszetettebb a földrajzi elhelyezkedést tároló tábláé.

Ennek menetét a 14. ábrán követhetjük végig.

13. ábra - A földrajzi elhelyezkedés tábla feltöltése

Itt két adatforrásból nyertem ki az összes szükséges információt. Egyrészt a vállalatirányí-

tási rendszer vevői törzsadatait tartalmazó táblából a vevő országának rövidítését, városát

és azonosítóját, másrészt készítettem egy Excel munkafüzetet, melyben eltároltam az or-

szágok rövidítését és tejes nevüket. Miután beolvastam az adatot mindkét forrásból, azokat

össze kell illeszteni, hiszen közösen fognak egy rekordot alkotni. Erre való a Merge Join

művelet a Visual Studio-ban, ami négy bemenő paramétert vár: a két illesztendő, illesztési

kulcs szerint rendezett adathalmazt, és az illesztési attribútumok nevét az adathalmazok-

ban. A rendezett bemenetek megteremtéséhez rendező objektumokat illesztettem be az

adatfolyam gráfba, az illesztési attribútumokat pedig az illesztő objektum tulajdonságainál

határoztam meg. Az így előálló n+m-1 attribútumú adathalmazt, - ahol m és n a bemenetek

attribútumainak száma - a már ismertetett módon hozzácsatoltam egy cél objektumhoz,

amely beszúrja azt az adattárház megfelelő táblájába.

3.5.2. A ténytábla feltöltése

A dimenziók megtervezése és létrehozása után minden feltétel adottá vált, az adattárház

ténytáblájának elkészítéséhez. Az ERP adatainak áttöltése a ténytáblába bonyolult feladat,

amely sok, apróbb részfeladatból áll össze. Ezen kisebb részfeladatokat mutatom be ebben

a fejezetben, a betöltő teljes adatfolyam-diagramja a 15. ábrán látható.

Az adatok kinyerése a vállalatirányítási rendszer adatbázisából itt is hasonló kapcsolat leíró

objektumokon keresztül történik, mint a dimenziótáblák elkészítésénél. Igyekeztem itt is

22

csupán a szükséges attribútumokat lekérdezni ezeken keresztül, hogy az adatmozgatást és a

vele járó hálózatterhelést minimalizálni tudjam. A dimenzióktól eltérő módon azonban

minden egyes vevői bizonylat adatállománya kettő adattáblában van szétosztva. Ezért az

egyes táblákból különböző adatokat érünk el a bizonylatokról, melyeket egyértelműen

azonosít és az adataikat összekapcsolja a bizonylat azonosítója a földrajzi elhelyezkedésnél

már bemutatott join merge művelet segítségével. Ehhez itt is rendezni kell a bemeneti

adatfolyamokat.

A bizonylatok soraiban szereplő adatok nagyon hasonlóak, azonban a jelentésük eltérő

lehet, ezért nem szabad meggondolatlanul áttölteni azokat az adattárházba, hiszen bizony-

lattípustól függően más és más jelentése lehet számunkra az adott mezőknek, még ha ne-

vük azonos is. Például az eladási jóváírások esetében az eladott áruk mennyisége és a be-

vételünk nem növekszik, noha ezen mennyiségek pozitívan jelennek meg a bizonylatokon

(ellentétben a QAD EA-val, ahol a stornózáskor negatív mennyiséggel is felkerül a tétel).

Ahhoz, hogy ez ne okozzon téves forgalmat a statisztikai adatokban, és ne torzítsa el az

elemzés eredményét, ezen számlák végösszege és darabszáma negatívan kell, hogy beke-

rüljön az adattárházba. Ehhez a Derived Culomn nevű komponenst használtam, ami a be-

menetére kötött adatfolyam attribútumain képes aritmetikai műveleteket elvégezni.

Miután minden bizonylatsor és a hozzá tartozó bizonylatfej egyesítésre került, a három

adatállomány szerkezete teljesen egységes és semmi sem indokolja a külön kezelésüket a

továbbiakban, ezért a három adathalmaz unióját képzem a további műveletek előtt az Uni-

on All metódus segítségével.

Ebben a pillanatban az adatfolyamban előállt minden adattal, amit a ténytáblából az elem-

zés során ki szeretnék majd nyerni. Egy fontos szakasz azonban még hátra van, mielőtt az

adattárházba be lehetne írni: el kell helyezni a dimenziótáblák kulcsait, ugyanis jelenlegi

állapotában az adatállomány soraihoz nem, vagy csak nagyon erőforrás igényes művele-

tekkel lehetne hozzárendelni a dimenziókat. Ennek elkerülése végett a dimenziótáblák kul-

csait idegen kulcsként el kell helyezni a formálódó adatállományba.

A kulcsok beszúrásához az úgynevezett Lookup komponenseket használom fel. Mint a

neve is mutatja, egy lookup táblát megvalósító feltételes szerkezet, ami ha … akkor …

típusú ellenőrzésekre használható. Általánosságban véve nagy hátránya, hogy nagyon me-

rev a szerkezet, nem képes tanulásra, csak a táblából képes visszaadni értéket. Ez itt nem

jelent problémát, hiszen az ERP rendszerből úgy sem lehet kinyerni természetes működés

mellett olyan adatot, ami nem szerepel bent. Másik hátránya a tábla méretéből adódó kere-

sés komplexitása, ezt azonban speciális adatbázis környezetben lehet például ritkaindexe-

léssel javítani. Minden dimenziótábla kulcsa egy lookup tábla segítségével kerül bele egy

új attribútumként az átalakítandó adathalmazba

Miután minden kulcsot megkapott a kiolvasott, átalakított adat, az elérte azt a végső for-

máját, ami már kompatibilis az adattárház ténytáblájával. Ekkor nincs más művelet hátra,

mint beírni azt a megfelelő táblába. Ez a dimenziótábláknál ismertetettel teljesen azonos

elven történik.

23

14. ábra - A ténytábla feltöltése az ERP adatbázisából

24

3.6. Az OLAP kocka felépítése

Miután az adattárház struktúráját kialakítottam és megtöltöttem azt az elemzéshez szüksé-

ges adatokkal a következő lépés az volt, hogy az adatokat olyan módon kell összefogni,

hogy abból elemzéseket lehessen készíteni. Mivel elemzőeszköznek Excelt választottam,

ezért adott volt a lehetőség, hogy a kockát Analysis Service projektként hozom létre Visual

Studio-ban, mert az mind Excel-ben, mind pedig az SQL Serveren támogatva van.

Analysis projektben is először adatkapcsolatot kell létrehozni a forrásként használni kívánt

adatbázissal. Ez hasonló módon történik az ETL-nél megismerthez, vagyis itt is létrejön

egy konnektor objektum a projekt és az adatbázis között.

Ezen kapcsoló objektumon keresztül ezután létrehozhatunk egy nézet objektumot a pro-

jekthez, melyben az adatbázis táblái között további kapcsolatokat, új kulcsokat hozhatunk

létre, új attribútumokat származtathatunk már meglévőkből.

Mindez azonban csak virtuális változás, csak ebben a projektben jön létre, a tényleges

adatbázis nem módosul.

Létrehoztuk a virtuális adatmodellünket, neki láthatunk a kocka felépítésének.

3.6.1. Dimenziók definiálása

A kocka építése előtt azonban definiálni kellett még azokat a dimenziókat, melyek szerint

az adatok elemezhetők, csoportosíthatók lesznek majd. A dimenziókat varázslóval hoztam

létre. Ehhez meg kellett adni, hogy melyik tábla alapján akarom elkészíteni, a tábla mely

mérőszámait akarom felhasználni, illetve azt is, hogy melyik tábla adatain értelmezett az a

dimenzió. Ez utóbbit minden dimenzió esetében az adattárház ténytáblájára állítottam. A

varázsló végigkattintgatása után létrejövő formon tudtam beállítani azt egyes dimenziók-

ban megjelenő objektumokat, azok hierarchiáját. A hierarchia létrehozásával keletkező

hibaüzenetek megszüntetésére be kellett állítani a kapcsolatokat a hierarchiában résztvevő

attribútumok között.

Kialakított hierarchia Attribútumok közti relációk Kész dimenzió

3. táblázat - A kocka dimenzióinak létrehozásának lépései

25

3.6.2. Kocka építése

A dimenziók elkészítése után futtatható a kockát elkészítő varázsló. Ebben lehetőségünk

van beállítani, hogy mely táblákat kezelje ténytáblaként a rendszer, azokon milyen méré-

seket végezzen el, valamint mely dimenziókat rendelje hozzá.

A varázsló lefuttatása után ismét egy formot kapunk, melynek első fülén a táblák közti

kapcsolatok láthatók. A többi fülön van lehetőségünk beállítani új számított értékeket a

kockára, a feliratokhoz, értékek nevéhez új fordításokat definiálni, illetve böngészni a koc-

kában.

Miután megépítettem a kockát, valamint beállítottam az aggregációk mentén az egyes mé-

rések típusát, már csak telepíteni kellett a kockát egy adatbázis kiszolgálóra. Mivel mind a

vállalatirányítási rendszer adatbázisa, mind az adattárház és ezekből kifolyólag a kocka is

csupán tesztelési, fejlesztési céllal lett létrehozva, különösebb terhelésnek nincsenek kité-

ve, ezért úgy döntöttem, hogy mindet egy MS SQL Server példány fog kiszolgálni.

15. ábra - Az OLAP kocka „csillag” sémája

3.7. Adatbázis kezelő cseréje

Az OLAP kocka adatbázisba való telepítése közben a következő hibaüzenetet kaptam:

Errors related to feature availability and configuration:

The 'Perspectives' feature is not included in the 'Standard Edition' SKU.

26

A hiba okának keresése közben hamar egyértelművé vált, hogy az csak XP SP3-nál jelent-

kezik. Tovább keresgélve, megtaláltam az SQL Server különböző kiadásait összehasonlító

listában, hogy a Standard nem támogatja az Analysis Serices-t. Ezért MSDNAA-ról töltöt-

tem le SQL Server Developer-t, és felkészültem az adatok migrálására.

Próbálkoztam a régi adatbázisok többféle módon történő kiexportálására, de egyik sem

hozta az általam elvárt eredményt, ezért azokról a fájlokról készítettem biztonsági másola-

tot, amelyekben az adatbázis el van tárolva.

A régi verzió eltávolítása előtt megpróbáltam megoldani a problémát a telepítőbe épített

kiadásfrissítési lehetőségekkel, azok azonban nem használtak, ezért az adatbázis kiszolgáló

teljes törlése mellett döntöttem.

Miután újra telepítettem és újra konfiguráltam a kiszolgálót, most már a Developer válto-

zatát, sikerült a kocka telepítése az adatbázisba.

A kötelező újraindítás követően azonban ismételten hiba fogadott a kocka ismételt felépí-

tésekor:

Unable to connect to the Analysis server.

SQL Server Configuration Manager-rel megnézve a szolgáltatásokat, észrevettem, hogy

nem indult el automatikusan az Analysis Service, ezért megpróbáltam kézzel elindítani,

amire a következő hibaüzenetet kaptam válaszul:

The request failed or the service did not respond in a timely fashion.

Consult the event log or other application error logs for details.

Rövid keresgélés után rájöttem, hogy ez a hiba szintén XP-n jelenik csak meg. A megoldás

megtalálásához viszont már sokkal több idő kellett, mire egy fórumon ráleltem: Ki kell

törölni minden bejegyzést a rendszernapló alkalmazások csoportjából.

Mióta kitöröltem a naplóbejegyzéseket ismét hibátlanul tudom használni a szolgáltatást.

3.8. Ár kialakítása Excel 2010-ben

Miután sikerült visszaírni a kockát az adatbázis kiszolgálóra, annak tartalma könnyedén

elérhető Excelből, csak adatforrást kell definiálni hozzá.

Az adatforrást az Adatok/Egyéb forrásból/Az Analysis Services szolgáltatásból útvonalon

lehet létrehozni az adatbázis szerverre való bejelentkezés után a kocka kiválasztásával.

Ezután a baloldalon megjelenő Kimutatás mezőlista menüből drag&drop lehet összerakni a

különböző jelentéseket, diagramokat.

A jelentésekből a felhasználó tetszőleges szisztéma szerint kialakíthatja az elképzeléseihez

leginkább igazodó árakat, akciókat.

Az általam megvalósított egyéni árképzés szintén Excelben történik, kettő dimenzió men-

tén. Az árképzés során a vevőket és a termékeket használtam fel az árlisták megvalósításá-

hoz, mint két független dimenziót. Az elemzés mérőszámaként ebben a konkrét implemen-

tációban a bizonylatokból kinyert összegeket használtam fel, de a feladat további részét

úgy alakítottam ki, hogy e két dimenzió mentén tetszőleges mérőszám segítségével lehes-

sen árlistát készíteni. Az elemzésben a dimenziókat nem egymásba ágyazva helyeztem el,

hanem X és Y irányban, így az Excel által generált nézet egy mátrixként jelenik meg,

melynek oszlopainak száma megegyezik a vevők számával és oszlopazonosítói a vevők

cégneve. Hasonlóan a sorok száma megegyezik az ERP-ben definiált termékek számával,

melyeket szintén a termék megnevezésével azonosítottam. A mátrix (i,j)-dik eleme az az

összeg, amennyit az i-edik partnere fizetett a j-edik termékért összesen a vállalatnak. Ezen

mátrixnak természetesen csak abban az esetben lesz feltöltve minden sora és oszlopa, ha az

adattárházban szereplő minden vevő vásárolt már legalább egy darabot minden termékből.

A minta vállalat adatbázisából emiatt egy erősen hiányos mátrix képezhető, azonban ennyi

is elég a feladat végiggondolásához és megvalósításához.

27

16. ábra - Automatikusan generált diagram: Értékesített cikkmennyiség negyedéves bontásban

3.9. Egyéni ár, akciós ár meghatározása

A kockából képzett ritka mátrixból sok tanulság leszűrhető az egyes termékekről vagy a

vásárlóink szokásairól, arra azonban teljesen alkalmatlan, hogy belőle adat egyszerűen

visszatölthető legyen a Navision-be. Az egyes vevőkre vonatkozó árak, kedvezmények

felvétele ugyan lehetséges lenne a mátrixba is, azonban az arra vonatkozó egyéb paraméte-

rek beállítása itt nem, vagy csak nehezen áttekinthető módon lenne kivitelezhető.

Ennek kezelésére egy Visual Basic scriptet írtam, amely átalakítja a mátrixot olyan táblá-

zatos formára, amiben az egyéni árak kialakításához szükséges minden paraméter egysze-

rűen megadható és azok könnyen áttekinthetők. Az így kialakított táblázatban szereplő

oszlopok a vevők, az értékesített termékek, a kijelölt mérési eredmények, az adott vevőre

vonatkozó sorkedvezmény százalékban kifejezve, a kedvezményes ár használatának időtar-

tama és az a minimális rendelési mennyiség, amely felett a kedvezményes árra jogosul a

vevő.

A ritkamátrixot táblázattá átalakító kódrészlet a scriptből:

’A vevők összeszámolása a munkafüzet 2. sorában

Do Until ExcelReader.Cells(2, intCustomerNumber) = ""

intCustomerNumber = intCustomerNumber + 1

Loop

’A cikkek összeszámolása az első oszlopban

Do Until ExcelReader.Cells(intItemNumber, 1) = ""

intItemNumber = intItemNumber + 1

Loop

’...

’Egymásba ágyazott ciklusokkal végig pásztázom a ritka mátrixot és

28

’ha értékes elemet találok benne, akkor azt átmásolom a táblázatba

For i=1 To intCustomerNumber

For j=1 To intItemNumber

If ExcelReader.cells(j+2, i+1).Value <> "" And

ExcelReader.cells(j+2, i+1).Value <> "0" Then

WrittenSheet.Cells(intRow, 1).Value =

ExcelReader.Cells(2, i+1)

WrittenSheet.Cells(intRow, 2).Value =

ExcelReader.Cells(j+2, 1)

WrittenSheet.Cells(intRow, 3).Value =

ExcelReader.cells(j+2, i+1)

intRow = intRow + 1

End if

Next

Next

A táblázat előre kitöltött részeit létrehozó kódrészlet:

’Kitöltendő oszlpok nevének kitöltése, megjelölésként

WrittenSheet.Cells(1, 1).Value = "Vevők"

WrittenSheet.Cells(1, 2).Value = "Termékek"

WrittenSheet.Cells(1, 3).Value = ExcelReader.Cells(1, 1)

WrittenSheet.Cells(1, 4).Value = "Kezdési dátum"

WrittenSheet.Cells(1, 5).Value = "Befejezési dátum"

WrittenSheet.Cells(1, 6).Value = "Minimális rendelési mennyiség"

WrittenSheet.Cells(1, 7).Value = "Sorengedmény %"

4. táblázat - A VB Script által generált táblázat részlete

Ezen oszlopok közül az időszakot, a minimális rendelési mennyiséget és a sorengedmény

százalékos értékét a felhasználónak kell meghatároznia. Az így elkészített táblázatos forma

már nem tartalmazza azokat az elemeit a mátrixnak, ahol az nem tartalmazott értéket.

Emellett a táblázat visszatöltése az adatbázisba sokkal egyszerűbben algoritmizálható is.

A táblázat feltöltését, ezzel a vásárlói engedmények megállapítását Excelben végeztem el,

ezzel egyúttal teszteltem a kialakuló megoldásom, hogy az ténylegesen képes-e nyújtani az

elvárt működést. Az átláthatóság kedvéért minden sorban a kezdési és befejezési dátum,

valamint a minimális rendelési mennyiség mezőket azonosra állítottam. Természetesen ez

nem kötelező a későbbiek során.

A feladat megoldás során a következő adatokkal töltöttem fel az Excel táblát: Kezdési dá-

tum: 2008.01.15. Befejezési dátum: 2008.02.10. Minimális rendelési mennyiség: 100 db.

A sorengedmény meghatározása során törekedtem azoknak a bonyolult szabályoknak a

követésére, amelyek alapján a valós életben a kedvezmény megállapításra kerül, csupán

egy egyszerű képlet alapján számolom azt (1. képlet). Természetesen a felhasználó tetsző-

leges bonyolultságú, az Excelben megvalósítható képletet találhat ki az engedmény megha-

tározására.

1. képlet – A sorengedmény % kiszámítása

29

Ahhoz, hogy az így meghatározott árlistát is felhasználja a Navision a bizonylat felvételé-

nél a fizetendő ár meghatározására, annak tartalmát vissza kell tölteni az adatbázisba. Eh-

hez meg kellett határoznom az adatok exportálásakor ismertetett módon, hogy melyik

adatbázistáblában tárolja az ERP ezeket az adatokat.

A dolgozat témáját képző feladat megoldásához nem maradt más hátra, minthogy vissza

kell töltenem az adatokat a Sales Discount Line táblába. Ehhez egy az adatok adattárházba

való betöltése során használt ETL folyamatokhoz hasonlót készítettem el ismét, melynek

adat forrásként a már egy marketing szakember által módosított Excel táblát adtam meg,

valamint a betöltéshez szükséges egyéb kapcsolótáblákat. Az ETL modul adatfolyam diag-

ramját a 17. ábra szemlélteti.

17. ábra - Az egyéni árlistát visszatöltő ETL process adatfolyam diagramja

30

Ahhoz, hogy a fentiekben elkészített munkafüzetet vissza tudjam tölteni a vállalatirányítási

rendszer adatbázisának megfelelő táblájába, hozzá kell csatolni a constraint-ek kielégítésé-

hez szükséges külső kulcsokat. A cikkek azonosítóját a kocka cikk dimenzió táblájából

csatoltam hozzá, a vevő azonosítót pedig a vevő dimenzióból. Van még néhány kulcs, amit

fel kellett vennem, de ezek e feladatban statikusak, ezért nem csatoltam őket hozzá az adat-

folyamhoz, hanem csak beállítottam azok értékét statikusan. Egy újabb join számításigé-

nyes művelet, és már így is van jó pár a process-ben, valamint értékük nem változhat, mert

az a fizikai valóságot sértené meg. Például mindig csak a vevő jellegű partnereinknek tu-

dunk kedvezményeket adni, a szállítóktól legfeljebb csak kaphatunk kedvezményt, de ve-

lük úgysem foglalkoztam a feladatom során. Végül hozzácsatoltam az ERP cikkekre vo-

natkozó törzsadatokat tároló táblájából még hozzácsatoltam a mennyiség mértékegységét.

Miután minden kényszert kialakít az adatfolyam, nincs más feladat hátra, be kell írni azt a

megfelelő táblába.

Az adatbázis műveletek optimalizálása érdekében kiszűrtem a ritka mátrix azon sorait,

amiben nincs érték már a táblázattá alakítás során, most pedig betöltés előtt szűröm ki azon

rekordokat az adatfolyamból, amelyekben a kedvezmény mértéke 0%. Ezek tárolása értel-

metlen és felesleges az adatbázisban, illetve ha mégis megtörténik, akkor teljesítményrom-

lást okozhat a Navision futásában is, hiszen minden új bizonylat felvételénél az ár megha-

tározásakor több látszólagosan „kedvezményes” árból kellene kiválasztani a minimálist,

amire ezen adatok semmilyen hatással sincsenek.

Az elemzés eredményének az ERP adatbázisába történő visszatöltésével bezárult a 1. ábrán

felvázolt kör. Ez azt jelenti, hogy a vállalatirányítási rendszer árlistái már tartalmazzák a

felhasználó által meghatározott egyéni kedvezményeket, árakat, vagyis mindig, ha ezután

új bizonylatot vesz fel valaki a rendszerben, akkor annak létrehozásakor a rendszer már

figyelembe veszi a most beállított új kedvezményeket is.

5. táblázat - A kedvezmény automatikus érvényesítése bizonylat készítésekor

4. Az elkészített implementáció üzleti jelentősége Az általam elvégzett feladat jelentős részét meg lehetett volna oldani a Microsoft Dyna-

mics NAV-on belül is. Árlisták definiálására, kedvezmények megadására természetesen ott

is van lehetőség. Arra a döntésre, hogy a feladatot az adatok külső adattárházba exportálá-

sával oldjam meg az vezetett, hogy az így elkészített megoldás sokkal dinamikusabb,

mintha az ERP-n belül oldottam volna meg a feladatot.

Vegyünk például egy multinacionális vállalatot, amelynek több országban is jelen van le-

ányvállalata. Ebben az esetben közös ERP-t nem, vagy csak nehezen használhatnának,

hiszen, pl. országonként más és más számviteli törvényeknek kellene megfelelniük. Ezért

saját ERP-ben tárolják a tranzakciós adataikat.

A vállalati adatok elosztott kezelése egyszerűbben konfigurálhatóvá és üzemeltethetővé

teszi a vállalatirányítási rendszereket, ugyanakkor az adatok centrális tárolásának hiánya

nehézkessé teszi mind az elemzést, mind az anyavállalat közös árképzési politikájának

meghatározását. Erre a problémára nyújtottam egy megoldást a dolgozatom során, ahol

meghagytam a lehetőséget arra, hogy a vállalat egyes divíziói saját vállalatirányítási rend-

31

szereket üzemeltethessenek úgy, hogy a cégvezetés stratégiailag fontos döntéseihez szük-

séges adatokat újragondolt struktúrában, egy központi adattárházban is eltároltam. Fontos

észrevenni, hogy a feladat nem követeli meg azt sem, hogy az egyes leányvállalatok azo-

nos vállalatirányítási rendszereket használjanak, így különösen kedvező megoldásként

szolgál több cég egyesítésére is.

Önálló laboratóriumi munkám során biztosítottam a lehetőséget az ERP-k egymástól minél

függetlenebb implementációjára a centrális, dinamikus árpolitika lehetőségének biztosítása

mellett.

32

5. Irodalomjegyzék

[1] Gajdos, S. (1999). Adatbázisok. Budapest: Műegyetemi Kiadó.

[2] Hámori, B., & Szabó, K. (2006). Információgazdaság. Budapest: Akadémiai Kiadó.

[3] Lohndorf-Larsen, L. (2008. november 5). Basic SQL - Creating Extended Stored

Procedure / xp_ndo.dll. Letöltés dátuma: 2011. március 10, forrás: Nav developer's

blog: http://blogs.msdn.com/b/nav_developer/archive/2008/11/05/basic-sql-

creating-extended-stored-procedure-xp-ndo-dll.aspx

[4] Robert J. Dolan, & Hermann Simon. (2000). Árképzés okosan. Budapest: Geomédia

Szakkönyvek.

[5] Sildó, C. (2004. augusztus). Adattárház összefoglaló. Letöltés dátuma: 2011. április

25., forrás: Adattárház összefoglaló:

http://scs.web.elte.hu/Work/DW/adattarhazak.htm

[6] social.msdn.microsoft.com. (dátum nélk.). Letöltés dátuma: 2011. május 5., forrás:

MSDN fórum: social.msdn.microsoft.com

[7] SSIS Tutorial: Creating a Simple ETL Package. (dátum nélk.). Letöltés dátuma: 2011.

május 5., forrás: Microsoft Developer Network: http://msdn.microsoft.com/en-

us/library/ms169917(v=sql.90).aspx

[8] Whitehorn, M., & Burns, K. (2008. július). Best Practices for Data Warehousing with

SQL Server 2008. Letöltés dátuma: 2011. május 5., forrás: Microsoft Developer

Network: http://msdn.microsoft.com/en-us/library/cc719165(v=sql.100).aspx

6. Táblázatjegyzék

1. táblázat - Árazási mechanizmusok és az árazást befolyásoló tényezők a statikus és a

dinamikus árazású piacokon. ...................................................................................................... 5

2. táblázat - Az idő dimenzió paramétereit tartalmazó Excel tábla részlete ............................. 20

3. táblázat - A kocka dimenzióinak létrehozásának lépései ..................................................... 24

4. táblázat - A VB Script által generált táblázat részlete .......................................................... 28

5. táblázat - A kedvezmény automatikus érvényesítése bizonylat készítésekor....................... 30

7. Képletjegyzék

1. képlet – A sorengedmény % kiszámítása ............................................................................. 28

8. Ábrajegyzék

1. ábra – Az elvégzett részfeladatok ........................................................................................... 4

2. ábra – A profitnégyzet a hozzá tartozó háromszögekkel ........................................................ 7

3. ábra – Több ár meghatározása ................................................................................................ 7

4. ábra – Csillagséma ER diagramja ........................................................................................... 9

5. ábra – Hópihe séma ER diagramja ....................................................................................... 10

6. ábra – Értékesítési OLAP kocka 3 dimenziós reprezentációja ............................................. 11

7. ábra – Üzleti folyamatok egymásra épülése a Microsoft Dynamics NAV-ban ................... 12

8. ábra - A CRM és az ERP kapcsolata az áralkotásban .......................................................... 13

33

9. ábra - A Navision fejléce ...................................................................................................... 14

10. ábra - A számla általános felépítése ................................................................................... 15

11. ábra - Az elkészített ETL folyamat state-chart-ja ............................................................... 19

12. ábra - Egyszerű adatfolyam ................................................................................................ 20

13. ábra - A földrajzi elhelyezkedés tábla feltöltése ................................................................. 21

14. ábra - A ténytábla feltöltése az ERP adatbázisából ............................................................ 23

15. ábra - Az OLAP kocka „csillag” sémája ............................................................................ 25

16. ábra - Automatikusan generált diagram: Értékesített cikkmennyiség negyedéves

bontásban .................................................................................................................................. 27

18. ábra - Az egyéni árlistát visszatöltő ETL process adatfolyam diagramja .......................... 29