Vállalati Információs Rendszerek Jövője

Megfigyelhető, hogy a régi, piacvezető ERP (Enterprise Resource Planning Systems – Vállalatirányítási Információs Rendszerek) gyártók az elektronikus kommunikáció terjedése miatt saját erőből vagy szövetségeseket keresve megpróbálnak elmozdulni az Internet, az Intranet és az üzleti intelligencia irányába.

Az új technológiai lehetőségek lehetővé teszik a vállalati folyamatok kiterjesztését a beszállítók és az ügyfelek irányába. Az üzleti informatika új területeinek, elemeinek utóbbi években történő megjelenése megerősíti, hogy az informatika alkalmazott tudomány. Csak más szakmákkal, tudományterületekkel (logisztika, marketing, számvitel, kontrolling stb.) együtt képes az üzleti életben előkerülő kérdésekre választ, megoldást adni. Az új alkalmazások bevezetése elsősorban nem az informatika-, hanem vállalati stratégia kérdése.

2. ERP rendszerek

Az integrált ERP rendszerek nem csak nagyvállalatok számára készülnek. (Ma már, az árbevétel szerinti első 200 magyar vállalatnak van integrált vállalatirányítási rendszere…) Az informatikai megoldásokat szállító cégek rájöttek, hogy a kis és közepes méretű vállalatok nagy piacot jelenthetnek ebben az öldöklő versenyben. A nagy rendszereknek megszülettek a kisebb változatai is (SAP, Infosys, Movex, Baan, Scala stb.), de vannak kifejezetten kisebb méretű cégeknek íródott szoftverrendszerek is (pl. Infor NT, Axapta, Exact). Ma Magyarországon több mint 40 ERP rendszert kínálnak különböző informatika cégek [4].

Egyre inkább elképzelhetetlen, hogy termelő-, szolgáltató vállalatok saját erőből fejlesszenek üzleti informatikai alkalmazásokat. Az ERP rendszerek esetén a fejlesztés időszükséglete meghaladja 20-50-100 mérnökévet. Egy-egy speciális területen elképzelhető kiegészítésként használt egyedi szoftver, de a megoldás-szállítók szinte minden feladatra, funkcióra nyújtanak reális választási lehetőséget. Az alkalmazó cégek szakembereinek “csak” kiválasztani, bevezetni és működtetni kell ezeket a rendszereket.

A “venni vagy gyártani?” kérdés tehát eldőlt. Ma a legtöbb integrált vállalatirányítási információs rendszer funkcionális területek szerint (Beszerzés, Raktározás, Termelés, Értékesítés, Pénzügy, Számvitel, Kontrolling, Karbantartás, Tárgyieszköz Gazdálkodás, Minőségbiztosítás, Emberi Erőforrás és Beruházás Menedzsment), modulokból épül fel, amelyek paraméterezhetők vagy CASE (Computer Aided System Engineering) rendszer segítségével illeszthetők a vállalati folyamatokhoz. Így egy termék a megfelelő modulok összeválogatásával akár egészen eltérő jellegű igényeket is képes kielégíteni. Megfigyelhető, hogy ezeket a kipróbált “kész” rendszereket iparágak szerint ajánlják. A rendszerekbe történő – paraméterezésen túli – beavatkozás általában költséges és garancia-vesztéssel is járhat. Az évről évre változó, újabb és újabb verziók nem biztos, hogy elviselik a korábban született kiegészítő megoldást. A szoftver-követés és garancia szempontjából a legoptimálisabb tehát a “standard” verzió választása, akár az üzleti folyamatok megváltoztatása árán is.

Az informatikusok új csoportjára lesz (van?) szükség, akik legalább olyan jól ismerik saját cégük működését, mint amennyire választott szakmájukhoz is értenek. Képesek felmérni a vállalatnál jelentkező igényeket és segítséget tudnak adni a felső vezetésnek a választásban. A vállalatirányítási információs rendszerek bevezetési projektjei azért sikertelenek néha, mert a vállalati folyamatok és az informatika között nincs összhang. A cél nem a bevezetés, hanem a vállalat hatékonyabb működése. (A felhasználót nem az érdekli, hogy a kliens és a szerver közötti adatátviteli sebesség ügyfelenként hány Kbit/s…)

Természetesen nem mindig várható el a felhasználóknál dolgozó informatikai szervezettől, szakemberektől, hogy egyedül vezessék be a rendszereket. A vállalatoknak nem konkrét szoftverrendszerekre van szükségük, hanem üzleti problémáik megoldására. Megjelentek a piacon az ún. rendszerintegrátorok és tanácsadó cégek, amelyek különböző, egymással kompatibilis megoldásokat illesztve segíteni tudnak az integrált vállalati információs rendszerek kialakításában.

Nem szabad az informatikai divatot gondolkodás nélkül követni. Elemezni kell, hogy az aktuális technológia bevezetése és alkalmazása tényleg haszonnal jár-e a vállalat számára. A gyors fejlődés miatt egy rövid, pár hónapos várakozás néha milliós költség megtakarítását, vagy jobb, “személyre szabottabb” megoldást eredményezhet.

3. Üzleti intelligencia

Az integrált vállalatirányítási információs rendszerek által szolgáltatott jelentések, listák (report-generátor…) képesek a vezetők számára információkat szolgáltatni, de bonyolult döntések előkészítésére és mélyebb elemzésekre már nem mindig alkalmasak. Az üzleti intelligencia rejtett bevételnövelő ill. költségcsökkentő lehetőségek feltárásával foglalkozó alkalmazások gyűjtőneve.

Az erősödő piaci verseny az alábbi feladatokat rója a cégekre:
üzleti tervek rendszeres aktualizálása
a változások várható hatásainak elemzése
a marketing és értékesítési akciók gyors és hatékony megtervezése
nyersanyag-felhasználás, raktárkészlet és létszám optimalizálása
beruházások hatásvizsgálata
szervezetfejlesztés.

A fentiek hatékony megoldásához ma már olyan eszközökre van szükség, amelyben a vállalat folyamatairól, tevékenységeiről szóló adatok a vezetők igényeinek megfelelő, könnyen kezelhető formában lesznek elérhetők.

A következőkben említett alkalmazások lényegesen nagyobb teljesítményű hardver elemeket igényelhetnek, mint egy hagyományos vállalati információs rendszer. A nagyobb hardver-szállítók (IBM, HP, Compaq) ajánlásokat készítenek arról, hogy különböző üzleti intelligenciák megvalósításához milyen számítástechnikai háttér szükséges.

3.1. Vezetői Információs Rendszer

A vezetői információs rendszerek (MIS - Manager Information System) interaktív jelentéseket, grafikonokat és összefoglalókat készítenek ismert alkalmazásokon keresztül. Maga a vezetői információs rendszer létrehozása az informatikai rendszer kiépítésének befejező lépése lehet. Csak akkor érdemes vele foglalkozni, ha az adatbázisokat létrehoztuk és a feldolgozói, ún. tranzakciós programokat beüzemeltük. Természetesen az informatikai fejlesztéseket taglaló tervekben ezt az igényt is szerepeltetni kell. Nem szerencsés, ha utólag illesztjük az igények közé a vezetői információs rendszert.

3.2. Adattárházak

A bonyolultabb döntéstámogató rendszerek (DSS - Decision Support System) meghatározott feltételrendszer alapján emelik ki az adatokat a vállalati adatbázisokból és azokat adattárházban tárolják. Az adattárházak (Data Warehouse) megfelelő struktúrában, elemzéshez előkészítve, történeti rálátással gyűjtik össze a vállalatok életében felmerülő külső és belső adatokat, amelyek bekerülésük után már nem változnak. Tulajdonképpen ezek is adatbázisok, de itt sokkal fejlettebbek a feltöltést, karbantartást és lekérdezést végző eszközök, módszerek. Az adattárházakban a különböző adatforrásokból nyert adatokat olyan struktúrában kell elhelyezni, hogy a bennük tárolt információk igény szerint, változatos formában legyenek lekérdezhetők. Lehetővé teszik a múlttal való összehasonlítást és különböző előrejelzési lehetőségeket is biztosítanak.

Egy adattárház kialakítása komoly beruházást igényel és kidolgozott módszertant kíván. Ennél egyszerűbb feladatot jelent az adatpiacok (Data Market) létrehozása. Ezek egy-egy tevékenységi területre (kontrolling, pénzügy, termelés, marketing) koncentráló, előre feldolgozott információgyűjtemények. A vállalat fejlődésével az adatpiacok összevonásával az adattárház is kialakítható. (Egy 1999-es IBM felmérés szerint 120 tagja van az IBM Terabyte Club-nak. Ezek a felhasználók IBM gépet használnak és adattárházuk, több mint 1 Terabyte adatot tartalmaz...)

Az adattárházak, adatpiacok megvásárláskor üresek, de beépített vagy csatolható eszközökkel az üzleti cél alapján feltölthetőek. Ilyenkor az első lépés mindig az ún. adattisztítás, amely a téves, elírt vagy vállalati szinten nem egységesen értelmezett adatok rendbetételét jelenti. A legjobb üzleti intelligencia-alkalmazás, - akárcsak az ERP rendszer - is megbukhat, ha nem “megtisztított”, megbízható adatokkal kerül feltöltésre.

A döntéstámogató, -előkészítő rendszereket a pénzügyi, a marketing, a termelési ill. a vállalat egészén dolgozó elemzők használják. Feladatuk a trendek meghatározása és a “mi lenne, ha?” kérdésekre válaszoló modellek felépítése, amelyek mérhető mennyiségekkel írják le a különböző árképzési és költségvetési alternatívákat.

Az adattárházakon működő lekérdező, döntéstámogató, elemző eszközök képességei eltérnek egy hagyományos operatív vállalatirányítási rendszerétől. Itt kell megemlíteni az OLAP technika (Online Analytical Processing) fogalmát. Ez többdimenziós alapú adatbázis alkalmazás. Az információkat a dimenziók (idő, értékesítési csatorna, földrajzi elhelyezkedés, beszállítói csoportok, alkalmazott technológiák stb.) mentén több irányból teszi hozzáférhetővé, elemezhetővé.

Az adattárházak egy másik felhasználása az ún. adatbányászat (Data Mining). Ez olyan számítástechnikai (adatbázis-kezelő) és statisztikai módszerekből valamint algoritmusokból álló eszközrendszer, amelynek segítségével az általunk fel nem ismert összefüggésekre is fényt deríthetünk. Elsősorban a marketing, ill. a kereskedelem területén alkalmazzák (pl. ügyfelek előre nem ismert csoportosítása), de ma már termelésben és logisztikában is hasznát veszik (kibocsátások hullámzása, selejt- és hiba-okok elemzése, szállítási késések vizsgálata stb.).

Az üzleti intelligencia alkalmazása fegyelmet kényszerít a vállalatokra, megköveteli a mutatók és az üzleti fogalmak cégen belüli azonos értelmezését. Nehezen integrálhatóak a szervezeti egységek vezetőinek egyéni “sziget-megoldásai”. Előnyös, ha az adatokat egy megbízható információkat nyújtó integrált vállalatirányítási információs rendszerből (ERP-ből) vesszük. Egy piackutató cég előrejelzése szerint a vezetői információs és döntéstámogatási rendszerek piacán 2002-re az operatív rendszerek és döntéstámogató rendszerek jelenlegi 70-30%-os aránya 30-70%-osra változik. A drasztikus változást azzal indokolják, hogy a hangsúly a döntéstámogatási munkát segítő információk gyors elérésére helyeződik.

A legjelentősebb számítógépes vállalati információs rendszereket forgalmazó cégek ezeken a területeken is kínálnak megoldásokat (SAP R/3-EIS, SCALA, Oracle-DataMart Suit, Megatrend, SAS stb.), de vannak olyan önálló, - nagy rendszerbe nem integrált - rendszer-független szoftvercsomagok, amelyek illeszthetőek a vállalatok speciális igényeihez (Cognos-Impromptu, Comshare Decision, MS-SQL Server 2000).

Az átlagos telepítési ideje egy ilyen üzleti intelligencia eszköznek 3-6 hónap. De ez a bevezetés ideje és nem a befejezésé. Ezeket a projekteket abbahagyni lehet csak, befejezni nem… Nagyon sok projekt kudarccal végződik. Az okok - hasonlóan más sikertelen informatikai projektekhez - a következők lehetnek:

- szervezetlenség

- az alapadatokat szolgáltató számítógépes operatív vállalatirányítási rendszer alkalmatlansága

- motiváltság hiánya

- bevezetés iránt elkötelezett felsővezető hiánya

- a projektből kimaradó felhasználók

- nem megfelelően felmért informatikai igények

- rendezetlen adatbázisok

- nem egységes adat- és fogalomértelmezés

3.3. “Új”, divatos lehetőségek az üzleti
intelligenciában (Business Intelligence) [5]

3.3.1. BSC (Balanced Scorecard – stratégiai döntéstámogató rendszer)

A vállalatok könyv szerinti és piaci értéke között jelentős különbség lehet. Ennek egyik oka a vállalatoknál eluralkodó pénzügyi szemléletű teljesítménymérés.

Az üzleti tevékenységeket nemcsak pénzügyi oldalról, hanem az ügyfelek (vevők), belső működési folyamatok és az emberi erőforrás (tanulási és fejlődési képesség) oldaláról is mérhetővé kell tenni.

A pénzügyi célok teljesülését elégedett, visszatérő vevőkkel lehet kielégíteni. A vevőt a vállalati anyagi-, irányítási- és értékfolyamatok révén szolgálják ki. A folyamatok pedig a szervezetben dolgozó emberre épülnek. A rendszer ezeken a területeken előre meghatározott mutatók, mérőszámok alakulását vizsgálja. Egyszerűen mérhető, szakmailag még kezelhető számú (15-25) mutatót kell definiálni (pl. ügyfélkérésekre adott válaszok átfutási ideje, reklamációk száma, egy főre eső árbevétel-növekedés, oktatásra szánt idő).

A cél (hasonlóan a kontrollinghoz…) a több dimenzióban történő gondolkodás. A BSC az üzleti stratégia szervezeti lebontására is megoldást kínál, így minden szervezeti egység a vállalatival összhangban lévő, saját stratégiát alakíthat ki. Az alsó szintek megismerhetik saját munkájuk hatását a vállalat működésére. Az adatok a cég ügyviteli, műszaki elemző rendszereiből (ERP+MIS), de akár adattárházból is származhatnak.

A BSC tehát a vállalati stratégia kézbentartására alkalmas - az üzleti intelligencia informatikai eszközeire alapozott - informatikai támogatás (ScoreIT, Oracle BSC, SAS Strategic Vision stb.). Ha az adott cégnek nincs jól definiált, leírt stratégiája, akkor nem szabad BSC-ben gondolkodnia.

3.3.2. CRM (Customer Relationship Management – ügyfélkapcsolatok kezelése)

Az igazi kereskedő egyik legfontosabb célja az ügyfél vagy vevő lehető legteljesebb megismerése, és ezeknek az ismereteknek a kihasználása újabb és újabb eladások érdekében. A CRM nemcsak egy programcsomag. A piacon kapható szoftverek (Exact CRM, Marketing Manager, Pivotal eRelationship 2000, Onyx - Magic CRM stb.) csak eszközei a céget átható “új” értékesítési filozófiának. A középpontban a folyamatos, ismételt értékesítés áll.

A marketing a vállalkozások nagy részénél még mindig termékközpontú. Nem az ügyfelekre figyelnek, hanem a rövidtávú eladási adatokra. Ne “csak” eladni akarjunk, próbáljuk meg kideríteni, hogy mit szeretne a vásárló. A közeljövő sikeres cégei figyelembe veszik az ügyfelek egyedi igényeit, megpróbálnak személyre szabott árut és/vagy szolgáltatást nyújtani, valamint hosszú távú, stabil ügyfélkapcsolatot kiépíteni.

A CRM rendszerek a következő területeken nyújtanak segítséget:

kapcsolattartás (vevők, ügyfelek elérhetősége)

értékesítési és marketing akciók tervezése

értékesítési folyamat követése

ajánlat és rendelés nyilvántartás

értékesítési csatornák kezelése

telefonos vevőszolgálat (call-center)

szerviz és lízing szerződések kezelése

dokumentum kezelés

döntéstámogatás különböző elemzések, statisztikák segítségével

ügyfélkapcsolat gondozása

A CRM tehát szintén a vállalat üzleti stratégiáját támogató folyamatok és rendszerek együttese, amelyeket alkalmazva a vállalat képes hosszú távú, nyereséges kapcsolatot fenntartani a rendszer által kimutatott, számára fontos ügyfelekkel [2].

Várható, hogy sok vállalat fog az ügyfélkapcsolatot kezelő rendszerek irányába elmozdulni, de igazán jó eredményeket a nagy ügyfélkörrel (10000-100000) rendelkező cégeknél lehet várni, amelyek elfogadják az új felfogást, elviselve az esetleges szervezeti átalakulást is.

3.3.3. SCM (Supply Chain Management – ellátási, beszállítói lánc kezelése)

Az SCM–ben a vállalati belső ellátási lánchoz kívülről Internet hozzáférés segítségével illesztjük egyik oldalról a beszállítót, a másik oldalról a vásárlót. Ezek a rendszerek együttműködést feltételeznek a lánc tagjai között, racionalizálva a logisztikai rendszert. A résztvevők önállóságukat megőrizve egyesítik erőforrásaikat. Az SCM szoftverek (Ariba, QUAD, EXE Technologies, MatrixOne, Managustics Group, Commerce One, i2 Technologies stb.) az alábbi területeken adnak megoldást:

vevői igények felmérése

készletek beszerzése

gyártási folyamatok tervezése

rendelés követés

késztermék elosztás

piackutatás és terméktervezés

4. e-Business

Az IBM révén alig pár éve került be a köztudatba az e-business. A fogalmak még mindig nem tisztázottak, ill. nagyon általánosak.

Ebbe a körbe tartozik az üzleti célú elektronikus levelezés, a marketing célból készült és interaktív lehetőségeket is biztosító Web oldal üzemeltetése, valamint a teljes vállalati működést vagy annak egy részét elektronikus, ill. Internet alapokra helyező cég is.

Az elektronikus kereskedelem üzleti tevékenység - vezetékes és most már vezeték nélküli - Internet és Intranet hálózatot igénybevevő, Web alapú alkalmazásokat felhasználó kapcsolat, üzletvitel, információcsere amely lehet:

vállalaton belül, pl.: különböző telephelyek közötti Internet technológiát felhasználó kereskedelmi célú információcsere

vállalatok között (business to business– B2B), pl.: nagykereskedelmi megrendelések

vállalat és kormányzati, önkormányzati szféra között (business to administration – B2A), pl.: közbeszerzések

vállalat és végfelhasználó között (business to consumer – B2C), pl.: könyv-, pizza-rendelés

vagy akár két végfelhasználó között is (consumer to consumer – C2C), pl.: apróhirdetés

Az e-Business egyik legfontosabb eleme az elektronikus kereskedelem (e-Commerce), amelynek két oldala van; az egyik az elektronikus értékesítés (e-Sales), míg a másik az elektronikus beszerzés (e-Procurement). A kettő nem választható el egymástól. A kereskedelmi ügylet (adás-vétel) lebonyolódhat saját on-line bolton keresztül, virtuális piactéren (electronic marketplace) vagy ún. virtuális árverés, e-aukció (e-Auction) segítségével.

Az virtuális piactéren a vállalatok gyorsan, alacsony költséggel, a számukra megfelelő időpontban szerezhetnek be “bármilyen árut”, hiszen az Internet felhasználásával eltűnik a földrajzi és az időkorlát. Ezek a piacok minden vállalkozás számára nyitottak. Nagy valószínűséggel a kisebb vállalatoknak hoz majd hasznot, hiszen az egész világon jelen lehetnek termékeikkel és szolgáltatásaikkal. A “külföldi” lehetőségek után (www.fastparts.com, www.worldbid.com, www.trade2b.com stb.) Magyarországon is megjelent az első ilyen virtuális piactér (www.marketline.hu).

Az e-aukció az Interneten külön erre a célra a beszerző vállalat által időszakosan megnyitott platformon történik. A résztvevők az előzetes beszállítói minősítésen átesett, meghívott potenciális szállítók és természetesen a szervező cég. A beszállítók árban, szállítási határidőben, minőségben, garanciális szolgáltatásokban és fizetési feltételekben versenyeznek egymással. Az aukción résztvevők csak a saját ajánlatuk “helyezését” és a legjobb ajánlat adatait látják. Nem ismerik egymást. Ezzel kizárható az előzetes megegyezés. Egy-egy ilyen aukció az előkészületeket és az utómunkálatokat nem számítva (minősítés, meghívás, próba aukció, szerződéskötés, lehívás) 2-3 óráig tart.

Az elektronikus adatcsere (EDI - Electronic Data Interchange) már több mint 20 éve használt, Internettől független, szabványos megoldás. Adatvédelemmel ellátott számítógépes rendszerek közötti adatforgalom lebonyolítására szolgál. Független nyelvektől, alkalmazott hardvertől és szoftvertől. Több mint 200 szabványosított okmány küldhető a szolgáltató cég által összekötött “üzletfelek” között (megrendelések, számlák, árlisták, átutalások, számlakivonatok, visszaigazolások, adóbevallás, stb.). A világon a leginkább banki szférában, autógyártásban, adóbevallásnál használják. Eddig csak nagy mennyiségű kicserélendő adat esetén volt gazdaságos. Most megjelent az EDI egy újabb fajtája, a Web alapú direkt kapcsolat, a WebEDI, amely az előző hátrányt kiküszöböli.

5. Workflow rendszerek

A nagy szervezetek bonyolult felépítésűek. A dolgozók által elvégzett résztevékenységekből áll össze a szervezet tevékenysége. A munkatársak egymásnak adják át a feladatokat. A zökkenőmentes munkához nem elég az egyéni munkaköri feladatokat meghatározni. Szükséges az egymás után következő lépések megadása is.

A hagyományos ERP rendszerek nem látják el feladatokkal a felhasználókat. Vannak különböző lekérdezési lehetőségek az elvégzendő munkával kapcsolatban, de nincs határozott “feladat-delegálás” és felelősség-átadás. Kevés az olyan ellenőrzési lehetőség, hogy a kitűzött feladatot időben elvégezték-e.

A vállalati ügyvitel fejlődésének a következő lépcsőit figyelhetjük meg napjainkban:

hagyományos ügyvitel, a vállalati folyamatok adminisztrálása

optimalizálás, szükségletszámítás

rendszer által szabályozott folyamatok, feladatok szétosztása felelősönként, esetleg ellenőrzés

A workflow olyan szoftvereszköz, amellyel a vállalat dolgozóira, szervezeteire és feladataira kiterjedő, munkafolyamatokat kezelő és ellenőrző számítógépes hálózati alkalmazások alakíthatóak ki. Alkalmazásával az egyes részfeladatok közötti időszakok lerövidíthetőek, a holtidő eltűnik. A workflow használata olyan feladatok esetében különösen hatásos, ahol egy folyamat több döntési és ellenőrzési fázison megy keresztül. Ezek a rendszerek (Staffware, Oracle InterOffice, Domino, Aris, Flowmark stb.) a már meglévő alkalmazások “fölé” helyezve gyakorlatilag automatizálják a vállalat ügymenetét, és felhasználják az űrlap-generálási, iroda-automatizálási, elektronikus posta, adatbázis kezelő és szövegszerkesztő technikákat. A workflow hasonlatos a hagyományos értelemben vett folyamatszabályozáshoz. Itt is vannak események, csomópontok és ciklusok.

A feladatok szabályozott folyamat révén, dokumentált módon áramolnak az egyik munkahelyről a másikra Internet vagy Intranet segítségével. A folyamat a workflow rendszer által vezérelt és adminisztrált eljárás szerint megy végbe, rögzítve a feladatkiadás tényét és a felelőst. Így ellenőrizhető lesz; ki, mikor, hogyan teljesítette és továbbította a munkát. Ez eleinte elriaszthatja a felhasználókat, de az áttekinthetőbb és gyorsabb ügymenet révén a munka könnyebb lesz.

A workflow [1] tehát részben módszertan, amelynek segítségével elkészíthető az ügyviteli folyamatok logikai modellje, részben pedig CASE eszköz, amellyel a logikai modell működő, fizikai rendszerré alakítható.

Várható, hogy a jövőben már nem kell mindenkinek mindennap bejárni a munkahelyére. Létrejöhet a “virtuális vállalat”, amelyet egy továbbfejlesztett ERP rendszer tart össze.

6. Folyamatok szimulációja

Ez a téma látszólag nem illeszkedik a cikkhez, de léteznek olyan termelési, logisztikai feladatok, problémák, amelyeket a legjobb ERP rendszerek sem képesek megoldani. Minden ipari termelő rendszerben anyagi folyamatok mennek végbe. Ez időben egymást dinamikusan követő diszkrét eseményeket (jármű- és gépgyártás) vagy folytonos-folyamatos modellel leírható folyamatot (vegyipar vagy élelmiszeripar) jelent. Ahhoz, hogy termelési rendszerünket irányítani tudjuk, pontos információk szükségesek a folyamatok belső törvényszerűségeiről.

Az esetleg hiányos ismeretek pótlására két lehetőség kínálkozik:

- Kísérletek végzése az ipari folyamatoknál nem mindig járható, mivel egy-egy “esemény” (pl. nagy értékű termelő berendezés rendszerbe állítása) költségei miatt megismételhetetlennek tekinthető

- A számítógépes folyamat-szimuláció a valóság lényeges tulajdonságainak leképezésével segítséget nyújthat a rejtett összefüggések megismerésében és a legelőnyösebb döntések meghozatalában. A számítógépes modell megalkotásával, vizsgálatával elemezhetjük a jelenben vagy jövőben lejátszódó valóságos folyamatokat. A szimuláció használata akkor indokolt, ha a kérdéses folyamat áttekinthetetlen vagy olyan adatokra van szükség, amelyekhez másként nem juthatunk hozzá

A szimulációval nyert adatok és összefüggések pontossága attól függ, hogy a modell mennyire jó. A kiértékelés során ne fogadjuk el kritika nélkül a kapott eredményeket. Ha lehetséges, elsőként mindig a valóságos állapotnak megfelelő modellt állítsuk össze. A szimuláció eredményeinek és tényleges input- és output adatok összevetésével kiderül, hogy mennyire megbízható a szimulációs modell. Egyezés esetén kezdjük el a tervezett változások hatásainak elemzését.

A szimulációs szoftvereket (Taylor II., Witness) a következő termelésirányítási problémák megoldásához lehet felhasználni:

gép-kihasználtság elemzése, értékelése

átfutási idők csökkentése

erőforrás szükséglet meghatározása

gyártósorok összehangolása

szűk keresztmetszetek meghatározása

raktározási, készletezési problémák megoldása

műhely-elrendezés elemzése

sorozatnagyság meghatározása

JIT koncepciók tesztelése

üzemzavarok hatásainak elemzése

új termelési programok, ütemezési tervek tesztelése

karbantartás ütemezése

A számítógépes modellek felépítése fizikai és logikai elemekből építőkockaszerűen történik. Fizikai elemek alatt a “megfogható” dolgokat értjük: anyagok, termékek, gépek, szállítópályák, tároló helyek, személyzet stb. A logikai elemek a modell működését vezérlik (pl. műszakrend, anyagok jellemzői, költségek, valószínűségi változók). A modell felépítése ma már nem igényel semmiféle programozói gyakorlatot, ill. matematikai (differenciál egyenletek és egyenletrendszerek felírása és megoldása) és rendszertechnikai ismeretet (diszkrét és folytonos-folyamatos rendszerek digitális szimulációja és sztochasztikus hatások “beépítése”). A felhasználókat korszerű 2D-s és 3D-s animáció, valamint beépített statisztikai elemző módszerek segítik. A modellekbe logikai elemként grafikonok, kijelzők vihetők be, amelyek az általunk kért adatokat mutatják dinamikus formában. A szimulációval gyorsan, gyakorlatilag költségmentesen lehet hosszú hónapok működésének megfelelő statisztikai adatsorokat elemezni.

7. Egyéb lehetőségek

A piacon találhatók nehezen besorolható, speciális üzleti megoldások, szoftverrendszerek is.

7.1. Szolgáltató cégek vállalatirányítási rendszerei

A projektorientált, elsősorban szakértői szolgáltatásokat nyújtó vállalatokra (K+F vállalatok, mérnöki irodák, tanácsadó cégek, szoftverfejlesztők, reklámügynökségek stb.) nem igazán illeszthető egy hagyományos ERP rendszer, hiszen a megoldandó problémák strukturálatlanok és állandóan változó környezetben jelentkeznek. Ilyen jellegű feladatokra fejlesztették ki az üzleti szolgáltatási irányítási rendszereket (PSA – Professional Services Automation). A cél a teljes szolgáltatási folyamat felügyelete az ügyfélkapcsolat és a szerződések kezelésétől (CRM?) a projektmenedzsmenten, erőforrás kezelésen és költség- ill. időelszámoláson át egészen az ún. support tevékenységekig. Nagyon sok esetben több, párhuzamos projekt fut egyszerre, ugyanazon erőforrásokat - az esetek nagy részében a szakértőket - terhelve. Az optimális működés kialakításában, a felvállalható feladatok megállapításában, és a felhalmozódott tudás kezelésében segítenek ezek a szoftverrendszerek (ArtemisView, Changepoint).

7.2. Termelésütemező rendszerek

Termelő cégeknél sok erőforrás és sok termék (diszkrét gyártás) esetén igen gyakori probléma a kapacitások hatékony kihasználása. Ezek a rendszerek képesek az erőforrások terhelését elemezni, azt grafikus formában (Gantt-diagram) megjeleníteni, nagy segítséget adva a reális átfutási idők megállapításához. Zavarok (gép meghibásodása, anyaghiány, nem várt rendelés stb.) esetén a gyártási terv gyorsan módosítható. Ezek a rendszerek (Preactor, Hanford Bay Associates – Total Enterprise Activity Management) elviselik a “manuális” beavatkozást is. Mind az előre történő- (kezdőnap megadása), mind a visszafelé történő (véghatáridő megadása) ütemezési feladatokat képesek megoldani.

7.3. Vállalati eszközmenedzsment (EAM – Enterprise Asset Management)

A vállalati géppark, az ingatlanvagyon, a járművek és közműhálózat optimális üzemeltetése megköveteli az informatikai támogatást. Ezek a szoftverek (akár függetlenek, mint a Maximo v. Mainpack, akár nagy ERP rendszerek része, mint a SAP R/3 PM modulja) segítik a megelőző karbantartást és a szabályozások betartásának ellenőrzését. Lehetőséget biztosítanak az állásidők, a költségek és az alkatrész készletek csökkentésére, valamint a karbantartási dokumentációk kezelésére. Mindezt, természetesen a ma már elvárható grafikus felhasználói felületen (GUI - Graphic User Interface) keresztül teszik.

8. Összefoglalás

Az üzleti intelligencia alkalmazások (adattárház, adatpiac, BSC, SCM, CRM, e-business, szimulációs rendszerek, speciális alkalmazások) egymással szoros kapcsolatban lévő megoldások. Az üzleti intelligencia terjedésével ezek egyre kevésbé tekinthetők önálló területeknek. Vannak átfedések is, sőt a gyártók, forgalmazók és alkalmazók fogalomértelmezése sem mindig azonos, ezért ezen a területen nagyon nehéz eligazodni. A cikkben szereplő “definíciók” nem minden szempontból tökéletesek, de talán hozzájárulnak az új fogalmak, betűszavak és irányzatok megértéséhez.

Az üzleti intelligencia rendszerek önmagukban nehezen állnak meg. Fontos, hogy legyen egy pontos, megbízható adatszolgáltató is, amely általában a bevezetésben említett ERP rendszer lehet. Igaz ez fordítva is. A nagyvállalatoknál az üzleti tranzakciók követéséből származó, nagy tömegben rendelkezésre álló adatokból a tervezéshez, döntéshez hasznos és szükséges információkat csak adattárház-alapú, üzleti célú rendszerekkel lehet kinyerni.

Jelenleg a vállalatirányítási információs rendszerek fejlesztésében az Internettel való kapcsolódás is hangsúlyossá vált.

Egy-egy ERP gyártó hosszú távú jövőjét befolyásolhatja, hogy hogyan közelíti meg az üzleti intelligencia alkalmazásokat, az Internet technológiát és az e-businesst, mennyire tud biztonságos megoldásokat kidolgozni. Ez akkor is igaz, ha esetleg jelenlegi piaci részesedése Magyarországon meghaladja a 60%-ot (SAP). Szélsőséges esetben egy felhasználó vállalat akár jól működő, keserves munka árán bevezetett, “zárt” ERP rendszerét is lecserélheti, ha nem kapja meg hozzá a külvilág eléréséhez és az összegyűlt adatok kezeléséhez szükséges megoldásokat [3].

Egy-egy önálló rendszer jövője pedig attól függ, hogy mennyire tudják nyitottá, operációs és adatbázis kezelő rendszerektől függetlenné tenni. Képesek lesznek-e a nagy cégek által (SAP, Oracle, Baan, One World-JD.Edwards) diktált platformokhoz illeszkedni, vagy sem?

Ez a rövid áttekintés természetesen nem tekinthető teljes körűnek. Számos terület kimaradt a cikkből. Így nem esett szó például az üzleti informatikához kötődő szakértői rendszerekről, az iratkezelésről és az ahhoz kapcsolódó archiválásról, valamint az e-business biztonsági kérdéseiről sem.

Irodalom

Adamcsik János: Irodaautomatizálás, INDOK Bt, Budapest, 1998

Fekete Gizella: Dönteni, nem döntögetni (Üzleti Intelligencia Rendszerek I-II. rész), Business Online, 1999. november-december

Fekete Gizella: Régi szelek – új távlatok (Vállalatirányítás 2000 után), Business Online, 2000. június-július (52-60. old.)

Hetyei József (szerk.): Vállalatirányítási információs rendszerek Magyarországon I-II., Computerbooks, Budapest, 1999-2000

Hetyei József (szerk.): Vezetői döntéstámogató és elektronikus üzleti megoldások Magyarországon, Computerbooks, Budapest, 2001.

Info_sys

Tartalom:
	1. Bevezetés
		1.1. Vállalati környezet
		1.2. Vállalati adathalmazok, döntéstámogatás
		1.3. Információszükségleti hierarchia
	2. Vállalatirányítási és döntéstámogató rendszerek evolúciója
	3. Az adattárház koncepció
		3.1. Az adattárház (data warehouse) fogalma
			3.1.1. Néhány adattárház definíció
			3.1.2. Inmon definíciója
		3.2. A "Data Warehousing" fogalma
		3.3. A "Business Intelligence" (BI) fogalma
	4. Az adattárház architekrúra
		4.1. Operational Data Store-tól az Extraprise Data Warehouse-ig
		4.2. Adattárház architektúrák
	5. OLTP és OLAP rendszerek
		5.1. OLTP rendszerek
		5.2. Új követelmények - OLAP rendszerek
		5.3. OLTP - OLAP renszerek összehasonlítása
	6. Adatmodellezés
		6.1. Adatsémák a tranzakciófeldolgozó rendszerektől az OLAP alkalmazásokig
		6.2. Tranzakciós rendszerek adatmodelljei - operációs séma
		6.3. Szemantikai réteg - felhasználói multidimenzionális adatfogalom
			6.3.1. Alapfogalmak
			6.3.2. Az adatkockák megjelenítése, kezelése a felhasználói felületen
			6.3.3. Analízisoperátorok
			6.3.4. A modell formalizált leírása
		6.4. Logikai réteg - adatbázis (belső) sémák
	7. MOLAP architektúrák
		7.1. Adatstruktúrák
		7.2. A többdimenziós tömb tárolás
		7.3. Ritka mátrix kezelés
		7.4. A multidimenzionális tárolás korlátai
		7.5. MOLAP termékek
	8. ROLAP architektúrák
		8.1. Relációs adattárház séma tervezésének 4 lépéses folyamata
		8.2. Csillagséma (star schema)
		8.3. Hópehely séma (snowflake schema)
		8.4. Konszolidált csillagséma
		8.7. ROLAP teljesítmény javítása
			8.7.1. Denormalizáció
			8.7.2. Aggregáció
			8.7.3. Particionálás
	9. HOLAP architektúrák
	10. Adattárház komponensek
		10.1. Az adatok kinyerése és betöltése az adattárházba
		10.2. Adatszolgáltatás az alkalmazások felé (OLAP Tools)
		10.3. Alkalmazások
		10.4.. Felügyelet, adminisztráció és metaadat-kezelés
	11. Az adattárház megoldás bevezetésének folyamata, az adattárház-project
	12. Kurrenskutatási területek
		12.1. Aggregáció
		12.2. Indexek
		12.3. Induktív adatbázisok
		12.4. Lekérdezés optimalizálás
		12.5. SQL bővítés
		12.6. Formális adatmodellek
		12.7. Elosztott adattárházak
		12.8. Metaadat kezelés
		12.9. Weblog-elemző Clickstream adattárházak
	13. Az adattárház piac és szereplői
	Irodalom

*1. Bevezetés*
Data Warehouse, adattárház: az információtechnológia viszonylag frissen önálló életre kelt ága, kevesebb mint egy évtizedes múltra visszatekintő területe. Rohamléptekkel, egyszerre több irányzat mentén fejlődő, már bizonyított és kiforratlan technológiák halmaza, kevés elismert szabvánnyal, rengeteg kapcsolódó termékkel és szolgáltatással, sok kis, néhány nagyobb piaci szereplővel, valamint nem utolsósorban meggyőző piaci adatokkal. De mit is jelent valójában az adattárház kifejezés?
1.1. Vállalati környezet
A következőkben megvizsgáljuk az adattárház technológiák alkalmazásának mozgatórugóit, felhasználói körét, alkalmazásának környezetét. Induljunk ki ehhez először tetszőleges vállalatból valamely gazdasági tevékenységgel, versenyhelyzetben a többi hasonló vállalattal. A piaci kihívásokra, a dinamikusan változó gazdasági környezetre az adott vállalat lehetőségei szerint reagál, rövid- közép- és stratégiai céljainak megfelelően. Ezeket a reakciókat, lépéseket (akárcsak a célokat) a vállalat vezetése határozza meg. A vállalat vezetésének folyamata felfogható tehát (az egyik elterjedt vállalatvezetési modell szerint) döntéshozatalként, döntések sorozatainak meghozatalaként. A vállalat eredményessége a reakciók, vagyis a döntések minőségén, sebességén múlik. Érthető tehát, hogy a vállalatok (az egyébként mind kritikusabb) kihívásokra válaszképp mindinkább szeretnék ezeket a döntéseket és velük együtt a vállalat vezetőit, a döntéshozókat eszközökkel, módszerekkel támogatni, naprakész, jól használható információval ellátni. Egy adattárház megoldás megvalósításával ilyen, döntések információs hátterét biztosító adat- és tudásbázishoz juthatunk.
1.2. Vállalati adathalmazok, döntéstámogatás
A vállalat működéséhez elengedhetetlenül szükségesek bizonyos adathalmazok, nyilvántartások. Ilyenek pl. a könyvelések, a számlázások, személyi nyilvántartások, stb. Ezek az adatok valamilyen formában (elektronikusan vagy akár papíron) mindig rendelkezésre állnak, de amellett, hogy a működéshez szükségesek, önmagukban még nem feltétlenül segítik elő a megfelelő döntéshozatalt. A megfelelő információk előállítását, szolgáltatását célozza meg többek közt a controlling (v. kontrolling) mint közgazdasági irányvonal, részfeladatként a vállalatirányítás folyamatának racionalizálásában, megfelelő információs alapra helyezésében. Másrészről, ugyancsak ezekre a célokra, csak információs technológiák irányából közelítve ezért jelentek meg a különböző döntéstámogató rendszerek (Decision Support Systems, DSS), melyek az információ-ellátás informatikai hátterét hivatottak biztosítani. Gyakran rengeteg adat halmozódik fel a működési adatokból egy-egy vállalatnál. A vállalatoknak a kiélezett piaci versenyben törekedniük kell arra, hogy ez az adattömeg ne csak haszontalan ún. adattemetőként (data puddle) halmozódjon egyre nagyobb és nagyobb mennyiségekben, aminek fenntartása fölösleges költségeket jelent. Lehetőség szerint az adattömegekben rejlő információkat, összefüggéseket, trendeket, "tudást" ("knowledge") meg kell határozni, hiszen ezek konkrét piaci előnyökként realizálhatók (és így értéket képviselnek).
1.3. Információszükségleti hierarchia
1943-ban Maslow angol szociológus megalkotta az emberi szükségletek hiearchiájának elméletét. Ez egy igen egyszerű elmélet, amely szerint az emeri szükségleteket alapvetőtől az önmegvalósító tevékenységek igényéig sorba rendezhetjük. A sor jellemzője, hogy a következő szintű igények csak akkor jelentkeznek, ha a hierarchiában alatta lévőt már kielégítettük. Így először az alapvető fizikai szükségleteknek megfelelően eszünk, iszunk, ezután foglalkozhatunk a biztonságunkkal, ha ez is teljesül, sorra jönnek a szociális, majd az önkiteljesítést szolgáló öncélú igények. Ez a hierarchikus igény szép párhuzam egy tetszőleges vállalatnál jelentkező információs igényekhez, melyet az ábra szemléltet. (Információs igény alatt a vállalat irányításához szükséges adatokra, tudásra való igényt értem.) A piramis szintjeibe beírva az adott igényeknek megfelelő adatelőállítási módszer neve található.

1.ábra: Vállalati adatszükségleti hierarchia
A piramis alján foglalnak helyet a vállalat működéséhez feltétlenül szükséges adatok. (pl. számlák, szállítások adatai, megrendelések, gyártási adatok, stb.) A feljebb mind bonyolultabbá és összetettebbekké váló kérdésekre csak egyre összetettebb módszerekkel, technológiákkal lehetséges választ adni. Tulajdonképp a felső két-három szint stabil információszolgáltató háttereként születtek meg az adattárház technológiák.

2. Vállalatirányítási és döntéstámogató rendszerek evolúciója

60-as évek: Executive Information Systems (EIS)

maiframe környezet, operatív rendszereken alapuló statikus lekérdezések, minőségi információszolgáltatás döntéshozóknak

az OLTP környezeten belüli modulok, egységek

80-as évek: Management Information Systems (MIS)

leginkább statikus beszámológenerálás

hiearchiaszintek bevezetése a mutatószámokhoz (lefúrás, roll-up lehetséges)

kliens-szerver környezet, GUI, Windows, Apple

1992: W.H.Inmon bevezeti az adattárház fogalmát úttörő munkájával

redundáns adattárolás, a forrásrendszerektől elválasztva

analízis célú adattárolás

1993: OLAP célok, követelményrendszer bevezetése (E.F.Codd)

dinamikus, multidimenzionális analízis

3. Az adattárház koncepció

3.1. Az adattárház (data warehouse) fogalma

Próbálkozzunk meg az adattárház definíciójával. Bár mára a kifejezés értelmezésében viszonylag nagy az egyetértés, kisebb értelmezésbeli, nézőpontbeli különbségek még mindig jelen vannak. Nézzük először, hogy az adattárház elmélet két evangelistájának mondott űttörőnk Ralph Kimball és Bill Inmon hogyan is fogja meg a fogalmat: (Az idézett könyvek ([1][2]) egyébként egyelőre kiállták az idő próbáját, és még ma is a két alapműként tartják számon a témában - 1996 óta, ami persze nem nagy idő.)

3.1.1. Néhány adattárház definíció

Idézet Ralph Kimballtól: Data Warehouse: "The conglomeration of an organization's data warehouse staging and presentation areas, where operational data is specifically structured for query and analysis performance and ease-of-use." [2] Az adattárház fogalma itt tehát egy adott szervezet azon adatgyűjtő és szolgáltató részeit foglalja magában, ahol a működési adatokat újrastrukturálják riportkészítési, jó teljesítményű és egyszerűen kezelhető elemzésekhez. Kimball ezen definícióját főleg azért szokták kedvelni és idézni, mert sok mindent nem határoz meg, pl. az adattárház nem feltétlenül döntéstámogatási célú.
Ebből átmenetként foghatjuk fel a következő változatot (már nem Kimballtól), mely az adattárházat technológiák gyűjteményének definiálja: "A data warehouse is a collection of technologies aimed at enabling the knowledge worker (executive, manager, analyst) to make better and faster decisions." [6]

3.1.2. Inmon definíciója

Kimball az adattárházat máshol egyszerűbben a vállalati tranzakciós adatok egy speciális, elemzési és beszámoló-készítési célra átstrukturált változatának tartja, egy speciális adatbázisnak. Ez az adatbázisként való megközelítés már csak egy pontatlanabb változata Bill Inmon általánosan elfogadott és az irodalomban leginkább idézett definíciójának:
"A data warehouse is a subject oriented, integrated, nonvolatile, and time variant collection of data in support of management's decisions." [1]

Nézzük végig az említett (elemzési céloknak alárendelt) jellemzőket!

Subject oriented (tárgyorientált, tematikus, esetleg témaorientáltnak is szokás fordítani)
Hagyományosan az alkalmazásainkat annak funkcióit, feladatait szem előtt tartva tervezzük, azok köré építjük. Az adattárház tárgy-orientáltságát, tematikus felépítését ehhez képest olyan értelemben szokás használni, miszerint most adott tárgyterületek köré, a meglévő és kapcsolódó adatokat szem előtt tartva ("data driven") tervezünk. Példaként nézzünk egy vállalatot, aki kábeltévés szolgáltatást nyújt. Hagyományos rendszerei megvalósítanak sok feladatot, a számlázás folyamatát, a beszerzést, a karbantartást és így tovább. Minden ilyen alkalmazás támogatott valamilyen saját adathalmazzal. Az adattárház építésénél azonban szeretnénk a meglévő adatokat a vevő szerint csoportosítva, összegyűjtve kezelni, vagy más hasonló tárgyterület köré csoportosítva látni (mint például az adás-kimaradások). Az adattárházban minden adatunkat ezek köré a tárgyterületek köré csoportosítjuk, gyűjtjük. Megjegyzem gyakran ezek a forrásrendszerek funkcióinak központi szereplői, mint pl. számlázási rendszerből a számlák, a raktárkészlet-nyilvántartásból a termékek, stb.

Integrated (integrált)
Az előző pontban említett tárgyorientált, adatvezérelt tervezéshez szorosan kapcsolódik az integráltság fogalma a következő értelemben: az adattárház az említett tárgyterületekhez kapcsolódó adatokat az érintett adatforrásokból szabványosított formára alakítva egy helyre gyűjti és egységbe rendezve kezeli.

Nonvolatile (nem illékony, vagyis tartós)
Jelenti ez azt, hogy az adattárházban jelen lévő adatok alapvetően változatlanok. Ha a forrásrendszer adatai változnának, az adattárház a változást követi, de úgy, hogy a bentlévő adatot megfelelő időbélyeggel (érvényességi idővel) látja el, majd felveszi az új állapotot is, megfelelő időbélyeggel. A bekerült adatok tehát tartósan meg is maradnak.

Time variant (időfüggő)
A forrásrendszereink adatai nagyrészt egy adott időre vonatkoznak, a jelen pillanatra, tehát, az adott érvényes állapotokat tárolják. Ehhez képest a megcélzott elemzések leginkább történeti adatokon és adatok idősorain használatosak. Az adattárház ennek megfelelően az adatokat időfüggően, az adatokat időpontok és időintervallumok szerint tárolják és kezelik, a forrásrendszerek változását nyomon követve. Például, képzeljünk el egy raktárkészlet nyilvántartást. Ennek adatai ha megjelennek az adattárházban, ott nyomonkövethetők és elemezhetők a raktárkészlet változásai.

3.2. A "Data Warehousing" fogalma

Data Warehousing alatt értjük adott szervezet adatainak adattárház eszközzel való kezelésének folyamatát, az adatok keletkezésének helyétől indulva egészen az elemzési célú megjelenítésig.
"Data Warehousing is the process, whereby organizations extract value from their informational assets through the use of special stores called data warehouses." [3]
Ennek megfelelően az adattárház működése három fontos kulcsmozzanat köré szerveződik, ezek:

1. Adatkinyerés a tranzakciós (vagy más vállalat-működtetési) rendszerekből

2. A kinyert adatok átformálása riport (beszámoló) készítés számára

A riportok, beszámolók elérhetővé tétele a döntéshozók számára.
3.3. A "Business Intelligence" (BI) fogalma A Business Intelligence (BI), üzleti intelligencia fogalámát Howard Dresner (Gartner Group) definiálta 1989-ben, azóta általánosan elfogadott fogalommá vált. Olyan módszerek, fogalmak halmazát jelenti, melyek a döntéshozás folyamatát javítják adatok és ún. tényalapú rendszerek használatával. A "tényalapú rendszer" a következő alrendszereket foglalja magába:

Vezetői információs rendszerek (Executive Information Systems)

Döntéstámogató rendszerek (Decision Support Systems, DSS)

Vállalati információs rendszerek (Enterprise Information Systems)

Online Analitical Processing (OLAP)

Adatvizualizáció

Adat- és szöveg-bányászat

Geográfiai információs rendszerek (Geographic Information Systems, GIS)

Az üzleti intelligencia fogalmát gyakran említik együtt az adattárházak fogalmával, mivel az lefedheti ezen részrendszereket, valamint kiszolgálhat ilyen rendszereket. Leginkább azonban tekinthetjük az adattárház megoldásokat az üzleti intelligencia megoldások egy szeletének.

4. Az adattárház architekrúra
4.1. Operational Data Store-tól az Extraprise Data Warehouse-ig
Az adattárház megoldás mérete és célja szerint széles skálán mozog, ezekre szokás külön elnevezéseket használni. Data mart (adatpiac): A data mart egy lokális, a vállalat valamely felhasználói csoportja, szakterülete számára készült, konkrét feladatot ellátó, kisebb adattároló és analizáló egységet jelent, amely már önmagában is adattárház funkciókat láthat el. Operational Data Store (ODS): Az ODS a tranzakciós adatok egy olyan nagy részletezettségű gyűjtőheje, amit az adatok egyesítésére és tisztítására használhatunk, esetleg a teljes részletezettségű adatok elérésére. Az adattárház fogalmat akkor használjuk, ha vállalati szinten lát el adatgyűjtő, adatszolgáltató funkciókat, ehhez általában több adatforrást felhasználva. Extraprise Data Warehouse: Egy jövőbe mutató trend szerint az Extraprise DW olyan világméretű adatgyűjtő hely, ahol összefutnak Business to Business (B2B), Business to Customer (B2C) adatok. Virtuális adattárház: Ez a fogalom már nem az adattárház méretével függ össze. Virtuális adattárházról akkor beszélünk, ha az operációs (forrás) adatbázisokon túl nem épül adatbázis az adattárház adatai számára. Az adattárház ekkor az operációs adatok megfelelő nézetére biztosít felületet. Hátránya a gyenge válaszidő-teljesítménye és az forrás adatbázisok folyamatos terhelése.
4.2. Adattárház architektúrák
Ebben a pontban kicsit részletesebben foglalkozunk az adatok 3.2 pontban (Data Warehousing fogalma) leírt háromlépcsős útjának megvalósításával. Az adattárház felépítését, építőelemeit tekintve egy kliens-szerver rendszer. Jelenti ez azt, hogy a felhasználó egy kliensen keresztül kiszolgáló, kiszolgálók szolgáltatásait használja. A munkamegosztást tekintve a megvalósítások széles skálán mozognak, kezdve az egy gépen futó kliens-szerver párostól a sok gépre, különböző stratégiák szerint elosztott kliens-szerver rendszerekig. Ezeknek nézzük most meg alapvető változatait.

5. OLTP és OLAP rendszerek

5.1. OLTP rendszerek

OLTP: On Line Transaction Processing, azaz online tranzakciófeldolgozás. OLTP rendszerek alatt értjük általában az adatbázis rendszerek hagyományos alkalmazásait. Ide sorolhatók pl. a raktárnyilvántartások, szállítási nyilvántartások, könyvtár kölcsönzési adatbázisa, számlanyilvántartó rendszerek, filmkatalógusok és így tovább. Központi fogalmuk a tranzakció végrehajtás, a következő értelemben: az adatbázis objektumainak állapotát a felhasználók konkurens módon végrehajtott és egyenkénti, kis tranzakciók gyakori végrehajtásával módosítják és kérdezik le.

5.2. Új követelmények - OLAP rendszerek

OLAP: On Line Analitical Processing, az online analitikai feldolgozás. A kilencvenes évek elején erősödött fel az igény az elemző, analitikai alkalmazások iránt, és ezzel együtt egy egységes módszertan és követelményrendszer felállítására. 1992-ben megjelent E.F.Codd cikke, melyben bevezeti az OLAP fogalmát, és 12 pontban definiál egy általa felállított követelményrendszert. Ez a definíció az online analitikai rendszerekre az idők során általánosan elfogadottá vált.

Codd OLAP szabályai:

1. Multi-dimenzionális nézet

2. Transzparencia (itt most technikai részletek ismerete nélküli könnyű elérhetőség, tehát áttekinthetőség értelemben)

3. Elérhetőségek (jogosultságok) beállíthatósága

4. Állandó riportozási (lekérdezési) teljesítmény

5. Kliens-szerver architektúra

6. Általános dimenzió fogalom

7. Dinamikus ritka-mátrix kezelés (ez a multidimenzionális modell tárolására vonatkozik, megvalósításra megkötés)

8. Több konkurens felhasználó támogatása

9. Korlátozás nélküli dimenzióműveletek

10. Intuitív adatkezelés (a végfelhasználó számára)

11. Rugalmas riportozás (vagyis beszámoló-készítés, lekérdezés)

Korlátlan dimenziószám és aggregációs szint szám Sajnos az is nyilvánvaló azonban, hogy Codd definíciója iránymutató ugyan, de ugyanakkor elég pontatlan. Különböző OLAP alkalmazás szállítók gyakran értelmezik különbözőképp Codd pontjait. Annyi azonban biztos, hogy az OLAP mindig magában foglalja adatok interaktív lekérdezését, melyet az adatok analízise követ. Központi fogalma az adatok multidimenzionális nézete, amire még részletesen kitérünk.
Az OLAP és az adattárház fogalmak erősen összefonódtak. Ennek oka, hogy az adattárház döntéstámogatási, információszolgáltató feladatát általánosan elfogadott módon OLAP elemzések és adatbányász feladatok információellátó feladataként értelmezhetjük, konkretizálhatjuk.
5.3. OLTP - OLAP renszerek összehasonlítása Szokás összehasonlítani az OLTP és OLAP alkalmazások tulajdonságait. Ezt megtesszük mi is, ld. ábra. Jól látszanak a követelmények közti különbségek. Mostanra általánosan elfogadottá vált az a nézet, miszerint a két rendszer különbözik annyira céljaiban, felhasználóiban, módszereiben, hogy érdemes az online elemző alkalmazásokat és rendszereket teljesen külön, független rendszerként megvalósítani.

Az OLTP és az OLAP rendszerek összehasonlítása

A tranzakciós rendszerekre közvetlenül épített analitikai alkalmazásoknál problémát jelenthet az analízisek nem gyakori, de hatalmas adatigénye, amely veszélybe sodorhatja az OLTP feltétlen megkövetelt megbízhatóságát, gyorsaságát.
Ne felejtsük el azonban, hogy az OLAP alkalmazások a különbözőségük ellenére szorosan kapcsolódnak OLTP alkalmazásokhoz, hiszen az OLAP alkalmazások adataikat (speciálisan csak az elemzés céljával) valamilyen meglévő OLTP rendszertől, operatív adatbázisból

nyerik. A különbségek miatt viszont adattárház építésekor a meglévő OLTP rendszerünket nem éri meg OLAP elemzésekkel és alkalmazásokkal terhelni, erre célszerű külön adatbázist, adattárházat fenntartani.
Egy gyakran hangoztatott nézőpont szerint az OLTP rendszerekre adatok tárolásának célja (putting data in) jellemző, ezzel szemben az OLAP rendszerek fő célja az adatkinyerés (getting data out).

6. Adatmodellezés
6.1. Adatsémák a tranzakciófeldolgozó rendszerektől az OLAP alkalmazásokig
Az adatmodell kifejezést most a következő értelemben fogjuk használni: az adatmodell olyan fogalmak halmaza, melyek az adatbázis struktúrájának leírására használhatóak. A következőkben áttekintjük az adattárházzal kapcsolatos adatmodellezési módszereket. A következő ábrán nem szerepelnek az OLTP rendszerek mellett más adatforrások. Ennek oka nem az, hogy az adattárház koncepciójába esetleg csak online tranzakciófeldolgozó rendszerek férnének bele mint adatforrások, a koncepcióba bármilyen ad atforrás belefér. Tetszőleges adatforrás viszont tetszőleges adatmodellel épülhet (gondolhatunk itt Excel táblázatokra, textfile-okra, vagy akár szöveges beszámolókra is), így erre most nem térünk ki. Az alábbi ábra az adat útját követve nevezi meg az adatok megfelelő nézeteit.

Az adatbázis adatmodelljeit három kategóriába soroljuk:

A koncepcionális (vagy szemantikai) szintű adatmodellek a felhasználók adatleíró módszereit takarják, függetlenek a konkrét implementációtól

A logikai szintű adatmodellek már függnek az adatbázisszervertől, de még mindig egy absztrakt, bár alacsonyabb rendű felhasználói nézetet biztosítanak

A fizikai szint adatmodelljei már teljesen a konkrét adatbázis implementációtól függnek, azt írják le, hogyan is tároljuk fizikailag az adott adatokat

A publikált nagyszámú modell némelyike azonban gyakran több kategóriába is sorolható egyszerre, adott esetben nehéz lehet (főleg az ilyen egyébként is elmosódott) határvonalakat meghatározni. Emiatt szokás még más csoportosítást is használni, érdemes ezek közül talán a formális modellek csoportját kiragadni.
Az ábrán az OLTP és OLAP rendszerek implementációja során felhasznált adatmodellek láthatóak áttekintő jelleggel. Mi részletesen most az OLAP megoldások adatmodelljeivel foglalkozunk. A szaggatott vonalak jelzik az előzőekben felvázolt kategóriahatárokat.

6.2. Tranzakciós rendszerek adatmodelljei - operációs séma
Az OLTP rendszerek nagy múltra tekintenek vissza, ennek megfelelően jól bevált modellrendszerekkel és jól kidolgozott eméleti háttérrel dicsekedhetnek (ez sajnos az adattárházakra még nem mondható el tiszta szívvel). A legelterjedtebb módszer a tárolandó objektumok leírására az Egyed/Kapcsolat diagramm (Entity/Relationship Diagram) ami aztán könnyen transzponálható az adatbázis relációs adatmodelljébe.
6.3. Szemantikai réteg - felhasználói multidimenzionális adatfogalom
Ebben a pontban az adattárház felhasználóinak fogalmi, elméleti (conceptual) adatmodelljét tekintjük át. Egy adattárház felhasználói általában nem elsősorban informatikusok, informatikai, matematikai felkészültségük sem feltétlenül mély. A felhasználóknak éppen ezért biztosítani kell egy könnyen kezelhető, rugalmas felületet, mellyel anélkül, hogy technikai részletekben kellene elmerülniük, tetszőlegesen lekérdezhetik, elemezhetik adataikat. Ehhez biztosít egy általánosan elfogadott adatabsztrakciós módszert a multidimenzionális modell. (OLAP eszközök esetén a multidimenzionális modell követelmény.) Meg kell jegyeznünk, hogy a multidimenzionális modell fogalomkészlete erősen intuitív, általában nem definiálják absztrakt módszerekkel.
6.3.1. Alapfogalmak
Tényadatnak (v. mutatószámnak, keyfigure, Kennzahl) nevezzük azokat mérhető, numerikus adatokat, melyeket elemezni és ehhez tárolni szeretnénk. (A koncepcionális modellben inkább mutatószám, későbbi adatbázis realizációknál inkább tény, tényadat néven szerepel.) Lehetnek hagyományos, vagy a közgazdaságtanból átvett mérőszámok. Ilyenek pl. az árbevétel, súly, eladott darabszám, nyereség, raktárkészlet, stb. A tényadatok általában additívak (pl. árbevétel), de lehetnek részben additívak vagy nem additívak is (pl. haszonkulcs). Dimenziónak (v. egyszerűen jellemzőnek) nevezzük azokat a jellemzőket, tulajdonságokat, melyek szerint a mérőszámokat csoportosítani, jellemezni tudjuk. A dimenziók egymástól független jellemzői egy-egy tényadatnak. Dimenziók lehetnek pl. idő, hely, termék, alapanyag, szállító neve, raktár, költségnem, költséghely, stb. A dimenziók elemei a modellünkben hierarchiákba rendezhetők. Ilyen hierarchikus szerkezet lehet pl. idő dimenzió esetén egy év - hónap - nap felbontás, vagy egy egyetemi szoba esetén egy épületegyüttes - épület - emelet - szoba felbontás. A következőkben az adatainkat úgy kezeljük, mintha egy n-dimenziós kocka pontjai lennének, ahol a dimenziók az itteni dimenzió fogalomnak megfelelnek (így az ő számuk az n). Az így felvázolt szerkezetet nevezzük adatkockának. A kocka név itt általános, az n-dimenziós adathalmazt is kockának hívjuk, nem csak a háromdimenziós esetet. Az adatkockákat független közgazdasági tárgyterületenként (ld.3.1.2, adattárház definíciója) készítjük. A kocka felbontása (granularity) alatt azt a legkisebb adategységet értjük, mely egységekben az adatot még elérhetővé szeretnénk tenni, tehát mikor az adat jellemezéséhez minden dimenziót felhasználunk. Adatkockánként több tényadat is szerepelhet, ekkor azonban mindegyikük granularitása meg kell egyezzen. A következő példa egy nagyon leegyszerűsített háromdimenziós változatát ábrázolja egy nemzetközi kereskedő cég eladási adataiból alkotott adatkockának. A mutatószámok (tényadatok) a kocka celláiban helyezkednek el, egyértelműen azonosíthatók egy idő-termék-hely hármassal. Jelenti ez azt is, hogy a kocka legkisebb felbontásként a következő adatot tartalmazza: egy adott napon egy adott fióküzletben mennyi fogyott egy adott termékből, és ebből mennyi árbevétel keletkezett. Az ábrán szintén szerepelnek dimenziókhoz hiearchiák is.

6.3.2. Az adatkockák megjelenítése, kezelése a felhasználói felületen

Nyilvánvaló, hogy az adatkockánkat, hacsak nem 2 (esetleg 3) dimenziós, nem tudjuk megfelelően megjeleníteni a végfelhasználó számára. Az elemző, a felhasználó az adatkockának mindig csak egy megfelelő két dimenziós nézetét látja, láthatja, egy táblázat formájában. Jelenti ez azt, hogy a többi dimenzió szerint az adatok vagy fel lesznek összegezve, vagy egy konkrét értékre le lesznek szűrve a megjelenítéshez.

6.3.3. Analízisoperátorok

Az adatkockákon végzett elemzésekhez kockák közti műveleteket használhatunk. Most megnézzük a leginkább elterjedt műveleteket. Ezek a műveletek az adatkockához egy új adatkockát rendelnek, céljuk általában az, hogy az új adatkocka az adatok egy olyan nézetét biztosítsa, ami az elemzési szempontunknak megfelel, esetleg táblázatként meg is jeleníthető.

Aggregáció (roll up)
Egy adott dimenziót kihagyunk a felbontásból, azaz a dimenzió elemein végighaladva az adatokat felösszegezzük. Előfordulhat az is, hogy a dimenzió felbontását nem teljesen hagyjuk ki, hanem áttérünk egy kisebb elemszámú hierarchia alkalmazására az adott dimenzióra. (Pl. városok helyett országok szerint nézzük adatainkat)

Lefúrás (drill down, roll down)
Ennek ellentéte, mikor egyre részletezettebben nézzük az adatokat. Pl. felbontjuk az összesített eladási adatokat termékekre, vagy a havi összesített adatokat lebontjuk napi adatokra.

Pivoting
Az adatkocka elforgatását értjük alatta. A kocka felbontása marad, csak a dimenziókat cseréljük fel, ezáltal más nézetét kapva az adatoknak.

Szelekció (selection, filtering)
Ebben az esetben egy adott dimenzió egy adott elemét kiválasztjuk, és a hozzá tartozó adatokat nézzük, a többi adatot pedig figyelmen kívül hagyjuk. Ilyen pl., ha kíváncsiak vagyunk egy konkrét fióküzlet bevételeinek alakulására

Szeletelés (slicing and dicing)
Slicing alatt a szelekcióhoz hasonlóan azt értjük, mikor adott dimenziót fix értékkel lekötünk, és így nézzük a kocka nézetét, szeletét. Dicing alatt a kocka egy részkockájának kivágását értjük.

Fontos, hogy ezen műveletek elvégzésére a felhasználók másodperces nagyságrendű válaszidőket várnak. Általában 5 másodperc körülienek határozzák meg a még elfogadható OLAP műveleti időket!

6.3.4. A modell formalizált leírása A hagyományos adatbázis leírási módszereink (Entity/Relationship, UML) a multidimenzionális rendszer esetében nem használhatók megfelelően, vagy nem nyújtanak hasznos segédeszközt. Kénytelenek vagyunk lemondani az általánosan használhatóságról, hogy használható multidimenzionális leíró rendszert kapjunk. Itt most két ilyen formális leíró módszert nézünk meg. ME/R modell: Multidimensional Entity/ Relationship Modell
A klasszikus egyed/kapcsolat modell egy kibővítése. A kapcsolat egy speciális "tényadat-kapcsolat", ezen keresztül kapcsolódnak a dimenzió-szintek, melyek között a nyíl jelzi a specializációs kapcsolatot. A nyilak nem alkothatnak kört, és a kisebb részletezettség felé mutatnak.

ADAPT: Application Design for Analitical Processing Technologies

6.4. Logikai réteg - adatbázis (belső) sémák

Célunk az előzőekben részletezett elvi multidimenzionális adatmodell megvalósítása adatbázis belső sémák szintjén. Itt már különbséget kell tennünk a sémák közt megvalósítás módja szerint, vagyis, hogy milyen adatbázisban szeretnénk tárolni az adatokat. A csoportok ezek szerint:
MOLAP: Multidimensional OLAP, azaz olyan OLAP megoldások, melyek saját speciális adatbáziskezelővel közvetlenül valamely multidimenzionális célstruktúrában tárolják az adatokat. Nagy hagyományokkal rendelkező megközelítés, szinte a relációs adatbáziskezelővel egyidőben megjelent a multidimenzionális elemzési célú tárolás: a 70-es évek elején két MIT hallgató fejlesztett ki egy modellt és működő rendszert, amely jóval később az Oracle Express termékcsalád alapját is képezte. Az adattárház séma ebben a csoportban tehát ezt a speciális multidimenzionális sémát jelenti.
ROLAP: Relational OLAP, azaz olyan OLAP megoldások, ahol az adatok tárolását hagyományos relációs adatbáziskezelővel végezzük. Itt a multidimenzionális megjelenést speciális relációs adatbázis sémákkal biztosítjuk. Elterjedtségére főképp rugalmasságára és a relációs adatbáziskezelők viszonylagos olcsóságára és megbízhatóságára, valamint a relációs tárolási technika elterjedtségére vezethető vissza. Az említett relációs adattárház sémák leginkább a csillagséma, hópehely séma, melyekre még visszatérünk.
HOLAP: Hybrid OLAP, azaz olyan hibrid megoldások, ahol az adatbáziskezelő biztosítja a hagyományos relációs tárolás lehetősége mellett multidimenzionális tárolási metódusokat is biztosítanak. Itt az előző kettőre jellemző adatbázis sémák mindegyike előfordulhat. Egyre inkább tendencia, hogy a relációs adatbázisok támogatják a multidimenzionális adattárolást speciális indexekkel, SQL bővítményekkel stb.

7. MOLAP architektúrák
Multidimenzionális OLAP alkalmazások esetében adatainkat speciális multidimenzionális struktúrában tároljuk.
7.1. Adatstruktúrák
MOLAP esetén külön kezeljük a dimenziók adatait és a tényadatokat. Dimenziók: véges, rendezett lista a dimenziók elemeiről. Fontos, hogy a dimenzióelemek listája jól rendezett legyen. Adatkocka: Egy n dimenziós kocka esetén az adatok egy n-dimenziós térben helyezkednek el, annak egy zárt részhalmazában a dimenzióértékek végessége miatt. Mivel a dimenziók diszkrét értékűek is, a dimenzióértékek a térben cellákat jelölnek ki. Ezek a cellák tartalmazzák a mutatószámokat. A dimenzióértékek által lehatárolt térrészt, azaz a kockát speciális indexstruktúrával látjuk el, aképp, hogy a a kocka minden egyes cellája be legyen indexelve. (Az index általában adott attribútumú sorok gyors elérését szolgáló struktúra.) A kockát eltároljuk a háttértárunkon, felépítjük az indexet, ami általában elfér a memóriában is, és ezt használva az adatok elérése jelentősen gyorsabb, mint egy sima relációs adatbázisban. Előny továbbá, hogy a struktúra jól illeszkedik a koncepcionális modellhez, fordítás nélkül alkalmazhatóak rá az OLAP műveletek. Dimenzió hierarchiák: A dimenziók hierarchikus felépítését úgy kezeljük, hogy a hierarchia csomópontjait elhelyezzük a dimenzióelemek között és összesített adatokat rendelünk hozzá

Aggregált adatok: Aggregált, felösszegzett adatok kezelése MOLAP architektúra esetén akkor sem jár elfogadhatatlan válaszidővel, ha külön nem foglalkozunk összegek tárolásával, mégpedig a gyors adatelérés miatt. Ezen túlmenően előre is definiálhatunk a kockákban aggregációs szinteket, hasonlóképp mint a hierarchiák esetében, ekkor az összegek beépülnek a kockába. Fontos megjegyezni a rendszerek azon hiányosságát, hogy nem lehet aggregált adatokat tárolni dimenziók nem teljes értékkészletével. Például nem megoldható, hogy aggregált adatokat tároljunk csak Gödöllő és Eger adataival. Igaz ugyanakkor az is, hogy a felhasználói lekérdezések ritkán ilyen jellegűek.
A dimenzió hierarchiák és az aggregált adatok esetén nyújtott megoldások tulajdonképp az adatok rendundás tárolásához vezetnek. A teljesítmény növelésére használt redundáns tárolás nem csak a MOLAP megoldásokra, hanem általánosan jellemző az adattárházakra, a tárhely-takarékosságról áthelyeződött a hangsúly a kiértékelés gyorsaságára.

Attribútumok: Ebben az esetben attribútum alatt a dimenzió jellemzőit értjük. Például, tekintve a "Vevő" dimenziót, ennek attribútumai lehetnek a vevő címe, számlaszáma, kategóriája, szöveges leírása, és így tovább.

Virtuális adatkocka: olyan kocka, amely levezetett, számolt adatokat tartalmaz, melyek konkrétan nem szerepelnek fizikailag tárolt kockákban. Ilyen lehet például egy a nyereségből épített kocka, vagy egy tény-terv összehasonlító százalékos eltérést mutató kocka.

7.2. A többdimenziós tömb tárolás

A kocka indexeléséhez szokás olyan indexstruktúrát használni, ahol a kocka celláit valamilyen adott algoritmussal sorbarendezzük, majd az indexek sora ennek a sorbarendezésnek felel meg. Ennek legegyszerűbb módja, ha a kocka adott (x1, x2, .. xn) koordinátájú pontjához a kordinátákból alkotott x1 + (x2-1)*|{1.dimenzió elemszáma}|+...+(xn-1)*|{(n-1)..dimenzió elemszáma}| sorszámú indexet rendeljük.
Az indexeket és magát a fizikai tárolóhelyet a háttértárakon előre elkészítjük, így az adatok anélkül írhatóak, hogy az indexstruktúrát módosítani kellene. Ugyanakkor mivel a rendezés egyértelműen azonosítja az adott cellát, nem kell az adatokkal együtt a kulcsokat is eltárolni.

7.3. Ritka mátrix kezelés

Amennyiben az adatmátrixunk ritka, tehát az adatok a kockán belül szétszórtan helyezkednek el, a kocka a hasznos adat mennyiségéhez képest nagy területet foglalhat el. Ennek oka, hogy az előre felépített indexstruktúra miatt a háttértáron előre helyet kell foglalni a kocka egészének. Sok dimenzió és nagy kiterjedésű dimenziók esetén ez akár oda is vezethet, hogy az adatbázis használhatatlanul naggyá válik. (A konkrét adatok egy becsléséhez ld. 6.ábra.) A ritka mátrix probléma kezelésére egyes multidimenzionális adatbáziskezelők tartalmaznak ún. ritka mátrix algoritmust, amely a kocka szerkezetéből megpróbálja a nem használt részeket kiszűrni, és a nekik fenntartott helyet felszabadítani, így elkerülve a mátrix kezelhetetlen naggyá válását.

7.4. A multidimenzionális tárolás korlátai

A már említett ritka mátrix probléma mellett meg kell említenünk még, hogy a strukturális változtatások ebben a modellben rendkívül költségesek. Emellett ezek a rendszerek általában nehezen skálázhatók, nincs általánosan elfogadott szabványuk, minden gyártó saját utakon jár.

7.5. MOLAP termékek

A MOLAP termékek széles skálán mozognak az asztali, néhány 10 Mb mennyiségű adat kezelésére alkalmas alkalmazásoktól kezdve a vállalati "high end" szoftverekig. Az első csoportba tartoznak pl. a Cognos PowerPlay-e, az Andyne PaBLO-ja és a Business Objects Mercury-ja. Az utóbbi kategóriában a Kenan Acumulata ES-e, az Oracle Express családja, a Planning Sciences Gentium-a és a Holistic System Holos-a olyan termékek, melyek nem csupán a multidimenzionális adattárolást, hanem rengeteg más kapcsolódó feladatot is megoldanak. Tisztán multidimenzionális adatbázis motorok az Arbor Essbase-e, a D&B/Pilot Ship Servere és a TM/1 a Sinper-től

8. ROLAP architektúrák

ROLAP architektúra esetén tehát a koncepcionális modellünket a hagyományos relációs adatbázis környezetben szeretnénk megvalósítani. (Feltételezem, hogy alapvető relációs-adatbázis ismeretekkel rendelkezünk.)
Jelölésként a következőket szokás használni: egy-egy téglalap egy relációs táblát jelent, melynek neve a téglalap elsötétített tetején szerepel. A téglalap sorai megfelelnek a tábla oszlopainak (attribútumok). A téglalapok közti vonalak a táblák közti kulcs-kapcsolatokat jelentenek, tehát az egyik tábla valamely sorainak a másik tábla megfelelő attribútuma idegen kulcsa. (Jelenti ez azt, hogy egyrészt a hivatkozott táblában egy adott mező kulcsként van értelmezve, másrészt teljesíti a hivatkozási épség megszorítását is, tehát a hivatkozó tábla minden kulcsához tartozik érték a hivatkozott táblában. A jelölés hiányossága, hogy egyrészt a kapcsolat nem irányított, másrészt nem egyértelmű a kulcsok kijelölése, de erre nem is lesz igazán szükség.)

8.1. Relációs adattárház séma tervezésének 4 lépéses folyamata

Nézzük meg a Kimball által [2.] javasolt négylépcsős relációs adattárház-tervezési metódust!

1. modellezendő üzleti folyamat kiválasztása
pl.: raktárkészlet nyilvántartások

2. felbontás (granularity) meghatározása
pl.: raktárkészlet termékenként, naponként, raktárhelyiségként, szállítóként, stb.

3. dimenziók meghatározása, kidolgozása
pl.: termék: név, súly, szín, beszerzési ár, stb.

4. tényadatok meghatározása
pl.: raktári mennyiség, súly, érték, minőségi mutatók, stb.

A lépésekkel előre haladva előfordulhat, hogy előző lépésre visszatérve már meghatározott jellemzőket újra kell gondolnunk, kiegészítenünk, módosítanunk kell.
8.2. Csillagséma (star schema) Modellünkben a tényadatok, mutatószámok játsszák a központi szerepet. A koncepciónknak megfelelően készítünk egy táblát, amely tartalmazza az összes tényadatunkat, és azok jellemzőit. A ténytábla normalizálásaként a mutatószámok jellemzőit dimenziók szerint egy-egy dimenziótáblában gyűjtjük össze, melynek minden elemét egy kulcs azonosít. Célszerű generált kulcsot használni, melyek nem rendelkeznek önálló információtartalommal, viszont az adatbáziskezelő támogatja a kezelés

A dimenziótáblák attribútumai közé általában érdemes minél több jellemzőt felvenni. Igaz ugyanis, hogy az adataink elemezhetősége nagyban függ a dimenziótáblák elemeinek megfelelő csoportosíthatóságától, rendezhetőségétől. Ehhez szükséges, hogy az elemzést végző felhasználók minél több, lehetőleg szöveges jellemző alapján tudjanak tájékozódni a dimenzión belül. Példaként tekintsük az "dátum" dimenziót! Ennek talán nem is szentelnénk saját dimenziótáblát, hiszen az adatbáziskezelőnk valószínűleg ismer valamely dátum típust, azt gondolhatjuk ez elég is. Gondoljuk végig azonban azt az esetet, mikor az dátumnak egy külön dimenziótáblát szentelünk, és abba az elemezni kívánt időtartam minden napját felveszünk. Mellé kerülhetnek jellemzőként ünnepnapokat, leltározási időszakokat, évszakot, kormányváltás időszakát, vagy bármely más fontosnak vagy kevésbé fontosnak gondolt attribútum. Ekkor ezek szerint az attribútumok szerint az adataink elemezhetőek. A dimenziótábla mérete pl. 50 éves időintervallumra nézve is csak 18250 sor, ami valószínűleg a ténytáblánk méretéhez képest még mindig elhanyagolható (még ha a táblák denormalizáltak is), cserében viszont nagy elemzési rugalmasságot kapunk.
Általánosan is igaz, hogy a dimenziótáblák mérete a ténytábla méretéhez képest nagyságrend(ekk)el kisebb, ez adja tulajdonképp a csillagséma denormalizált (redundáns) dimenziótábláinak létjogosultságát

csillagséma 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 metaadatai (adatokat leíró adat) egyszerűek

A csillagséma 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

8.3. Hópehely séma (snowflake scheme) A hópehely séma nagyban hasonlít a csillag sémára, csak itt normalizáljuk a dimenziótáblákat (megszüntetjük vagy csökkentjük a redundanciát).

8.4. Konszolidált csillagséma
Konszolidált csillagsémának hívjuk azt a speciális csillagsémát, mikor a központi ténytáblában aggregált adatokat is tárolunk.
8.7. ROLAP teljesítmény javítása
A relációs multidimenzionális eszközök teljesítményében (válaszidőkben) általában elmaradnak a MOLAP eszközöktől. A teljesítmény javítására három standard módszert alkalmaznak Nem térünk ki most a relációs adatbáziskezelők teljesítményének javítására, amely tetemes elméleti és gyakorlati háttérrel büszkélkedhet. A következő módszerek már csak ezeket kiegészítő, speciálisan csak adattárházakra alkalmazható módszerek.
8.7.1. Denormalizáció
Denormalizáció alatt értjük azt az eljárást, mikor a ténytáblában redundánsan eltárolunk járulékos jellemzőket, olyanokat, melyek a dimenziótáblákban egyébként szerepelnek. Például, a kiskereskedős példánál az elemzéseknél gyakran használják a termék dimenziót, de abból csak a gyártó jellemzőt. Ekkor, ha a válaszidők nem megfelelőek, a ténytáblába mint oszlop bevesszük a "gyártó" jellemzőt, így megspórolva egy join műveletet a kiértékelésnél, elbukva viszont tárterületet a redundancia miatt. Az adattárház rendszerekre általánosan jellemző az elemzési hatékonyság miatti redundáns adattárolás.
8.7.2. Aggregáció
Aggregáció alatt értjük azt, mikor az adatok valamely szempont szerinti felösszegzett változatát is eltároljuk az adatbázisunkban. Ez jelentheti egy vagy több dimenzió elhagyását. A következő ábra szemlélteti egy négydimenziós adatkocka agregációs lehetőségeit. Nyilván az aggregációs szintek bevezetésével, használatával a válaszidők jelentősen javulhatnak egyes lekérdezéseknél, igaz viszont az is, hogy az összegeket minden új adatelem beszúrásánál frissíteni kell.

Ezek közül a lehetőségek közül érdemes kiválasztani a leginkább használt nézeteket.
Szokás az adatkocka n dimenziót tartalmazó változatát n-cuboid-nak nevezni. A kocka materializációja alatt pedig azt értjük, hogy a lehetséges cuboid-ok közül melyeket tárolunk el fizikailag is.
Az aggregáció egy általánosabban értelmezése szerint gyakran tárolják az adatok olyan nézeteit is, ahol valamely dimenziókat elhagynak, valamely más dimenziókat viszont leszűkítenek egy adott értékintervallumra vagy értékre. (Ezt a fajta aggregációs tárolást egyébként a MOLAP adatbázisok általában nem támogatják, ezt szokták emlegetni mint hátrány. Újabban viszont támogatják relációs adatbázisok szintjén, például az Oracle 9i adatbáziskezelő a Materialized View objektum bevezetésével.)

8.7.3. Particionálás

A ténytábla túl nagyra hízása a teljesítmény rovására megy. Ezt elkerülendő szokás a táblát több ténytáblára vágni, melyek esetleg akár párhuzamosan is feldolgozhatók lehetnek.

9. HOLAP architektúrák

Egyre jellemzőbb trend, hogy a már meglévő relációs adatbázisok funkcionalitását kibővítik multidimenzionális tárolási lehetőségekkel. Ez lehetőséget ad olyan hibrid architektúrák felépítésére, melyeket alapvetően relációs módszerekkel építünk annak jól skálázható és robosztus tulajdonságai miatt, de kiegészítésként a gyakran használt nézetekre, adatokra építünk multidimenzionális kockákat is, a jóval gyorsabb lekérdezési sebesség miatt.
Az Oracle bár még néhány évig támogatja az Express termékcsaládját, hosszú távon ő is a relációs adatbáziskezelőjébe való beolvasztással tervez. Ugyancsak megjelent a Microsoft SQL Server-ében a multidimenzionális tárolást használó Analysis Services, és a DB2 relációs adatkezelőjébe a 8.1-es változattól ugyancsak beolvasztottak egy MOLAP szervert.
Az architektúra térnyerését jelzi például az eddig kizárólag relációs technikára és relációs adatbáziskezelőkre építkező SAP Business Information Warehouse adattárház terméke, ahol is a 3.0-ás változattól (2002), amennyiben az alatta lévő adatbáziskezelő MSSQL Server Analysis Services, már szintén képes a multidimenzionális tárolási technika alkalmazására.

10. Adattárház komponensek

Az adattárház-rendszer működtetéséhez, az információfeldolgozás automatizálásához és adminisztrációjához sok eszközre, komponensre van szükségünk. Ezek az eszközök a data warehousing folyamatának egy-egy kisebb-nagyobb részfolyamatára nyújtanak megoldást, kézenfekvő tehát őket a megoldott részfeladatok alapján csoportokba sorolni. Az ábrán szerepelnek az adattárház alapvető komponensei.

10.1. Az adatok kinyerése és betöltése az adattárházba - Data Staging Area

ETL Tools: Extraction, Transformation and Load, vagyis olyan eszközök, melyek az adatok kinyerését, transzformációját és adattárházba töltését támogatják. Ez a csoport jelenti az összekötő kapcsot a tranzakciós rendszerek és az adattárház között.
Az adatbetöltés folyamata a következő részfeladatokra bontható le:

Adatkinyerés az operatív rendszerekből (extraction)

Adattranszformáció (különböző adatformátumok, mértékegységek, nyelvek stb.)

Adatminőség ellenőrzése, adattisztítás (cleaning)

Adatbetöltés az adattárház struktúráiba (loading)

Az adattárház adatai az operatív adatokból származnak, az operatív adatok változásainak propagálódniuk kell az adattárház részletezett és aggregált adatain át a felhasználó által látható beszámolókig. Nem feltétlenül igaz viszont, hogy az operatív adatok változásait ezek azonnal követik. Fontos az adatfeltöltés periodicitásának és időpontjának gondos megválasztása. A túl gyakori adatfrissítés az operatív rendszerek fölöslegesen nagy terheléséhez vezethet, a túl ritka frissítésnek pedig az elemzett adatok naprakészsége láthatja kárát. Szétválaszthatjuk az adatainkat eszerint pl. óránkénti, naponkénti, hetenkénti és havonkénti adatfrissítést igénylő adatokra, és ezeknek megfelelően időzíthetjük az adattöltést az operatív rendszerek számára leginkább megfelelő időpontokra. Gyakran ezek az időpontok, időintervallumok éjszakai órák, hétvégék, ekkor legkisebb ugyanis az OLTP rendszerek terhelése. Fontos odafigyelni arra, hogy adott adattárház tárgyterületek adattöltése nagy adatmozgásokat igényelhet, az OLTP rendszerek hagyományos felhasználásával szemben több ezer, millió rekord egyidejű lekérdezésével jár, melyek semmiképp nem veszélyeztethetik a vállalat mindennapi működését.
Adattöltések megoldásai közt két alapvető csoportot különböztethetünk meg, attól függően, hogy hová csoportosítjuk az adatgyűjtést végző, szabályozó mechanizmusokat.

"Push" adattöltés: Az operatív rendszerünket felkészítjük arra, hogy az adattárház számára adatokat gyűjtsön, adatokat továbbítson. Ebben az esetben lentről-felfelé az operatív rendszer kezdeményezi az adatok továbbítását az adattárházba.

"Pull" adattöltés: Az adattárház a megfelelően beállított időintervallumban az operatív rendszerekhez intézett lekérdezésekkel frissíti az adatait.

Két újabb kategóriát jelenthet az adattöltések megkülönböztetése a változások követésének szemszögéből. Eszerint, ha az operatív rendszerben új vagy megváltozott adatokra vonatkozóan csak a változás valamilyen leírását továbbítjuk, delta-töltésről (a változásra utalva), ha az operatív rendszer adatait egy az egyben továbbítjuk, teljes-töltésről beszélhetünk.
Egy viszonylag részletes lista ETL szállítókról és termékekről: http://www.dwinfocenter.org/clean.html
10.2. Adatszolgáltatás az alkalmazások felé (OLAP Tools) - Data Presentation Area Ide az adattárház adatain OLAP lekérdezéseket lehetővé tévő eszközök tartoznak. Az adattárház valamelyik már tárgyalt módszerrel tárolja az analitikai adatokat, az adatkockákat, ezek az eszközök pedig ezekhez az adatokhoz biztosítanak az OLAP elvárásoknak megfelelő lekérdező felületet. Ezek az adatszolgáltató megoldások túllépnek a hagyományos adatbázis lekérdezéseket kiszolgáló SQL szerverek funkcionalitásán, speciális OLAP lekérdezésekre, lekérdezés sorozatokat is támogatva.
Fontos kérdés, hogy az OLAP szerver milyen kapcsolódási felületet biztosít a kliens-alkalmazások felé. Eddig egységesen elfogadott szabvány OLAP-lekérdező interface-re még nem igazán született, a különböző szállítók különböző utakat járnak. Megoldást jelenthet talán az Open-OLAP szabvány, ami egyre szélesebb körben elfogadott és támogatott.
10.3. Alkalmazások Ez a csoport az adattárház adataira épülő elemző, riportozó alkalmazásokat foglalja magába. Nagyon széles skálán mozoghatnak ezek az eszközök, kezdve a legegyszerűbb lekérdező-beszámolókészítő alkalmazásoktól a hagyományos statisztikai elemző-szoftvereken át az adatbányász eszközökig. Gyakran találkozhatunk valamely már ismert elemző eszköz vagy táblázatkezelő (SAP esetében pl. Excel) OLAP funkciókkal kibővített változatával. Ennek előnye a gyors tanulhatóság és a megszokott környezet, ezáltal a végfelhasználókkal való könnyebb elfogadtathatóság.
10.4.. Felügyelet, adminisztráció és metaadat-kezelés Metaadat: Ebben az esetben a "meta-" előtagot olyan értelemben használjuk, mint egy átfogó jelző olyan fogalom-és leíró módszerekre, amelyek egy eredeti fogalomrendszerrel foglalkoznak, abból származnak. Innen adódik a metaadat kifejezésre az "adatokat leíró adatok" meghatározás. A metaadat fogalma már a '60-as évektől kezdve jelen van az informatikában, a nem szekvenciális file-manager rendszerek adatleíró mezőitől kezdve (metaadatként felfogva az adatrekordok indexeléséhez felhasznált rekord-leíró mezőket) mind sokrétűbb módszerekként. A '70-es évektől relációs adatbáziskezelő rendszereknél is megjelent és kifejlődött többféle adatdefiníciós módszer, adatleíró megoldás, a tábladefiníciós megoldásoktól kezdve absztraktabb módszerekig, mint pl. az Entity/Relationship modell.

sok szállító --> sok tervezést és adminisztrációt segítő termék --> sok metaadat-kezelő megoldás

11. Az adattárház megoldás bevezetésének folyamata, az adattárház-project



12. Kurrens kutatási területek
A következőkben a teljesség igénye nélkül kiragadok néhány, számora érdekesnek, valamint időszerűnek tűnő kutatási területet az adattárházak területéről.
12.1. Aggregáció
A relációs adattárházak gyenge pontja a lekérdezések viszonylag nagy válaszideje főképp az elvégzendő tábla-összekapcsolások (join) miatt. Erre megoldást jelenthet megfelelően kialakított aggregátumok (technológiai elnevezésével élve materializált nézetek) tárolása az adatbázisban. Kérdéses viszont, hogy milyen algoritmussal érdemes kiválasztani az lehetséges aggregátumokból a megfelelőket, milyen hierarchikus szerkezetet érdemes belőlük kialakítani, és milyen módszerrel lehet az aggregátumokat saját magukat karbantartó tulajdonsággal felruházni.
12.2. Indexek
A relációs tárolás hatékonyságát, a lekérdezések válaszidejét nagyban javíthatja megfelelő indexstruktúrák alkalmazása. Kutatás tárgyát képezi az adattárházak struktúráival hatékony módon működő indexelési módszerek kialakítása. Két már bevált és hasznos ilyen jellegű index-típus az úgynevezett bitmap index, valamint a join index. Az indexelés témaköre nagyban összefügg az előző pontban tárgyalt aggregátum-kezelés témakörrel: mindkét témakör olyan, adatbázisban járulékosan tárolt, redundáns adatok kezelésével, kialakításával foglalkozik, melynek célja a lekérdezések válaszideinek csökkentése.
12.3. Induktív adatbázisok
Induktív adatbázis alatt értjük azokat az adatbázisokat, melyek nem csak adatokat, hanem az adatokat leíró következtetési sémákat is tartalmaznak. Az induktív adatbázisok koncepciója még nem teljesen kiforrott, annyit azonban leszögezhetünk, hogy induktív következtetési szabályokat, modelleket járulékosan tartalmazó adatbázisokról van szó. Képzeljünk el például egy olyan adatbázist, amely amellet, hogy tartalmazza például egy vállalat teljes vevőnyilvántartását, és lehetővé teszi a (deduktív következtetésekként felfogható) hagyományos adatbázis lekérdezések végrehajtását, olyan modelleket is tartalmaz, melyek az adathalmazból általánosított következtetéseket tartalmaznak, például jellemző megrendelési szokásokat, a vevők klaszterezését stb. Az induktív adatbázisok témaköre szoros kapcsolatban áll az adatbányászattal, ahol is hasonló rejtett összefüggések kinyerése a cél.
12.4. Lekérdezés optimalizálás
A relációs adattárházak csillag struktúrájának lekérdezését célzó query-k gyakran nem az optimális, leggyorsabban kiértékelhető formában érkeznek. Kérdés, hogy hogyan lehet a query-ket az optimális formára alakítani, és a lehető leggyorsabban kiszolgálni?
12.5. SQL bővítés
Az SQL lekérdező nyelv nem nyújt megfelelő támogatást OLAP, illetve adatbányász lekérdezések végrehajtásához. Kérdés, hogy milyen bővítés lenne célravezető ezek magasszintű támogatásához?
12.6. Formális adatmodellek
Az adattárházak adatmodelljei még korántsem mutatnak egységes, kiforrott képet. A tervezés, az implementáció és a használat során megfelelően használható, elfogadott modell még nincs jelen.
12.7. Elosztott adattárházak
Adattárházat építeni PC-k klasztereiből, vagy általában sok független adatpiacból még nem kidolgozott, de ígéretes terület. A megfelelő módszerek, modellek még hiányoznak.
12.8. Metaadat kezelés
Az adattárház metaadat-szótára kulcsfontosságú a használhatósága és a hatékonysága szempontjából. Fontos ezért, hogy kialakításuk jól átgondoltan, esetleg megfelelő formalizmusok használatával történjen. Fontos még az általános használhatóság, a könnyen illeszthetőség feltétele is más rendszerekhez, valamint lehetőség szerint a minél teljesebb elfogadottság, a nagy piaci szereplők meggyőzése a metaadatkezelő szabvány használatáról, így az egységesítés.
12.9. Weblog-elemző Clickstream adattárházak
A különböző portálok, vállalati webszerverek egyre nagyobb felhasználása megteremtette az igényt az általuk készített naplófile-ok megfelelő analízisére. Erre megfelelő megoldást nyújthat egy adattárház, azonban a rendkívül nagy adatmennnyiségek miatt a megvalósított struktúrák, megoldások gyakran kudarchoz vezetnek. Ezek kutatása is ígéretes terület.

Irodalom

[1] W.H.Inmon: Building the Data Warehouse - Second Edition

[2] Ralph Kimball, Margy Ross: The Data Warehouse Toolkit - Second Edition

[3] Naeem Hashmi: Businness Information Warehouse for SAP

[4] Andreas Totok: Modellierung von OLAP- und Data-Warehouse-Systemen

[5] Gary Dodge, Tim Gorman: Essential Oracle8i Data Warehousing

[6] Matthias Jarke, Maurizio Lenzerini, Yannis Vassiliou, Panod Vassiliadis: Fundamentals of Data Warehouses

[7] Sakhr Youness: Professional Data Warehousing with SQL Server 7.0 and OLAP Services

[8] Wolfgang Martin: Data Warehousing: Data Mining - OLAP

[9] Schutte, Rotthowe, Holten: Data Warehouse Management-handbuch

[10] Ramon Baraquin, Herb Edelstein: Planning and Designing the Data Warehouse

ADAPT: Application Design for Analitical Processing Technologies