DSS - Decision Support System

Ez az oldal a korábbi SCH wiki-ről lett áthozva. Az eredeti változata itt érhető el.

Ha úgy érzed, hogy bármilyen formázási vagy tartalmi probléma van vele, akkor kérlek javíts rajta egy rövid szerkesztéssel.

Ha nem tudod, hogyan indulj el, olvasd el a migrálási útmutatót

special thx to Dr. Kovács László && Marvell && unknown

Bevezető

• Az eddig megismert adatbázisok szerepe világ egy hű leképzése (jegynyilvántartás, könyvtár, raktárkezelés), adminisztrálása volt. Az aktuális állapotot tükrözte egy rendszerben. A lekérdezési műveletek mellett gyakori ==UPDATE== műveletek jellemezték.
• Az új szemlélet szerint a rendszer korábbi állapotaiból, összegyűjtött adataiból a jövőbeli trendekre szeretnénk következtetni. Célja a változásokat jellemezni. Többségében lekérdező műveletek használatával. Az így kialakuló alkalmazásokat szokás döntés támogató rendszereknek (DSS - Decision Support System) is nevezni.

DSS

• a lekérdezések optimalizálása szükséges.
• Szemben az eddig látott alkalmazásokkal, melyek az operatív tevékenységben résztvevő dolgozók számára készült adatokkal dolgoztak, a DSS rendszerek vállalat vezetői számára készültek. A vállalat működését befolyásoló stratégiai kérdések megoldására alkalmazzák.
• Kezdetben a rossz hatásfokú jelentéskezelő rendszerek - Management Information Systems - MIS / EIS jellemezték ezt a születő iparágat. Később adattárházakon alapuló döntéstámogatás váltotta le ezeket.

Ezen a helyen volt linkelve a dss1.PNG nevű kép a régi wiki ezen oldaláról. (Kérlek hozd át ezt a képet ide, különben idővel el fog tűnni a régi wikivel együtt)

A DSS rendszerek legfontosabb jellemzői:

• az egyszerű adatolvasás/írás helyett az adatok analitikus, statisztikus elemzése dominál. Adatelemző komponensekkel egészülnek ki a normál adatkezelő utasítások.
• célja az adatok mögött húzódó trendek felderítése, meghatározni az események változási irányát és jellegét
• nem tartalmaznak adatmódosítási elemeket
• a megfelelő minőségű, megbízható előrejelzésekhez nagy adatmennyiséget igényelnek.
• nagyobb szerepet kap az időbeliség (egy adatelem mely időpontbeli aktuális állapotnak felel meg).
• Felhasználóbarát, emberközeli kezelő felület
• lekérdezések terén rugalmasság: a problémákat sok oldalról, többféle megközelítésben meg lehet vizsgálni.

Az újfajta igények az adatkezeléstől gyorsabb nagy tömegű adatkezelést igényelnek. Analitikus műveleteket támogató, hosszabb és nagyobb adatmennyiségeket érintő tranzakciók kezelése.

OLTP vs OLAP

A hagyományos adatkezelést online tranzakció orientált rendszernek (On Line Transaction Processing - OLTP) nevezik, a másik módszert online analitikus elemzés orientált adatkezelésnek (On Line Analitical Processing - OLAP).

Az OLTP rendszerekben a működés során több konkurensen futó rövid életű tranzakció található meg. Az OLAP rendszereknél viszont lényegesen kevesebb a párhuzamosan futó lekérdezés, de azok jóval hosszabb időt igényelnek, hiszen mögöttük hatalmas adatmennyiség áll. Az adatok jellegében is különbséget találunk: az OLTP rendszereknél az aktuális állapotról tárolnak információt homogén modell szerint, hiszen javarészt egyetlen adatforrásra építenek. Az OLAP ezzel szemben nem a konzisztens állapotleírással foglalkozik, hanem minél több információt kíván kisajtolni a rendszerből, ennek érdekében szélesebb információ forrást von be az értékelésbe. Külön energiát szükséges fordítani a heterogén adatok összedolgozására.

| összehasonlítás || OSS - OLTP || DSS - OLAP 

|}

| funkció || adatfeldolgozás || döntéstámogatás 

|}

| szállítandó || üzleti műveletek, funkcionalitás || információ 

|}

| felhasználás || strukturált, ismétlődő műveletek || ad-hoc a műveletek fajtája, jellege, intenzitása 

|}

| válaszidő || mp || órák, napok 

|}

| érintett rekordszám || kevés || igen sok 

|}

| lekérdezési profil || kevés tábla || sok tábla  

|}

| követelmény || stabil: egy jól ismert folyamathoz || ismeretlen: feltáró folyamathoz 

|}

| struktúra || sok tábla kevés oszlop, normalizált || kevés tábla sok leíró oszlop, redundáns 

|}

| szervezés || folyamat orientált (tranzakció alapú) || téma orientált 

|}

| adatok jellege || dinamikus || statikus 

|}

| frissítés || folyamatosan || bulk loading, periodikus 

|}

| felhasználók száma || nagyszámú, egyidejű || kevesebb, kisebb konkurencia 

|}

| hozzáférés jellege  || rekordokhoz, gyorsan || sok rekod, összegzésekhez 

|}

| gépfelhasználás  || stabil || nagyon dinamikus 

|}

| rendelkezésre állás  || kritikus 100% || nem kritikus 

|}

Denormalizált Adatstruktúra

Motivációk

Ezen a helyen volt linkelve a dss2.PNG nevű kép a régi wiki ezen oldaláról. (Kérlek hozd át ezt a képet ide, különben idővel el fog tűnni a régi wikivel együtt)

vállalati erőforrásgazdálkodási rendszer egyszerűsített ER diagrammja

A tapasztalatok szerint a lekérdezésoptimalizálók rossz hatékonysággal működnek a bonyolult adatstruktúrákon. AZ OLAP igényeket csak körülményesen nehezen lehet vele megvalósítani, a klasszikus elsődleges kulcs-idegen kulcs szerkezettel a több változót érintő aggregációs értékeket vizsgáló kapcsolatok feltárása igen hosszadalmas. Az ipari méretű rendszerekben az egyedtípusok (táblák) száma több ezer lehet. A végfelhasználó nem képes hatékonyan használni (különösen a vezetők, a managerek). A lekérdezés optimalizáló alkalmazások (cost-based) gyakran tévednek, általános struktúrák esetén katasztrofális hatékonysággal dolgoznak. A struktúra karbantartása (update) igencsak nehézkes, a tranzakció kezelésre van optimalizálva, nem pedig a szükséges lekérdezések támogatására.

Dimenziós modellezés

A jóval magasabb szintű funkcionális elemek leírására született meg a dimenziós modellezés (DM). Ennek támogatására grafikus, funkciójában az ER modellhez hasonló formátumú séma leíró nyelvek jöttek létre, köztük a csillag modell, mely az elkészített leírás alakjáról kapta a nevét.

Elemei a

• tények, melyek a csillag közepét alkotják: numerikus, additív, folyamatos értékkészletű attribútumokkal rendelkezik. Kevés attribútum, sok sor.
• dimenziók, melyek mentén a tényértékek változását kísérjük figyelemmel. Gyakran szöveges, leíró attribútumokkal rendelkeznek, sok attribútum és kevesebb rekord.

A ténytábla értékei egy többváltozós függvény függvényértékeinek feleltethetők meg. E mellett a dimenziók értékei a független változók értékeivel párosíthatók.

Praktikus jelöléssel lássuk az értékesítési folyamathoz tartozó DM-t:

Ezen a helyen volt linkelve a dss3.PNG nevű kép a régi wiki ezen oldaláról. (Kérlek hozd át ezt a képet ide, különben idővel el fog tűnni a régi wikivel együtt)

A tény kiolvasása a dimenziók együttállása mellett. Alkalmas-e ez a klasszikus struktúra által nyújtott szolgáltatások megvalósítására?

• általánosan nem
• egy konkrét kérdéskategóriára lehet hatékonyabb a dimenziós adatmodell
• de nem is baj a DSS-ben, ha nem támogat minden lekérdezést

Konform dimenziók

A ténytáblák a vállalati működés kritikus folyamatait fedik le, melyek ezáltal jól elemezhetőkké válnak. A vállalat vezetése szempontjából átfogó kép kell az összes folyamatról. A dimenziós modellben a ténytáblák csak dimenziókat, a dimenziók csak tényeket kapcsolnak össze. Ha azonban multidimenziós adatmodell képzünk az azonos dimenziók együtt (nemcsak logikailag, hanem a megvalósítás szempontjából is) közösen kezelehetjük. Az adathalmazok összevonásával jönnek létre az ún. *konform dimenziók*: a különböző tényekhez tartozó azonos jelentésű dimenziók azonosakra vannak kialakítva (közösek). Ezen keresztül azonban a tényadatok között is kapcsolatot lehet teremteni.

Ezen a helyen volt linkelve a dss4.PNG nevű kép a régi wiki ezen oldaláról. (Kérlek hozd át ezt a képet ide, különben idővel el fog tűnni a régi wikivel együtt)

adattárház busz

CSONK

Célja a dimenzióstruktúrák összekapcsolása a konform dimenziók rendszerén keresztül, mégpedig úgy, hogy nincs fizikai kapcsolat kialakítva! Az a konstrukció, ami a konform dimenziók rendszerén keresztül összekapcsolja a különböző dimenziós struktúrákat.

Ezen a helyen volt linkelve a dss5.PNG nevű kép a régi wiki ezen oldaláról. (Kérlek hozd át ezt a képet ide, különben idővel el fog tűnni a régi wikivel együtt)

rendezett formában (busz) ábrázolás

Implementációs lehetőségek:

• relációs: tény-tábla
  • táblák
  • kulcs
  • a ténytáblában a tényadatokon kívül annyi idegen kulcs lesz, ahány dimenziója van
• multidimenziós tömbök + 5. ábra
  • dimenziók a tengelyeken
  • cella hordozza a tényadatok értékét
  • egy tényadat

Példák: ROLAP (relációs alapokon) , MOLAP (multidimenziós alapokon), HOLAP (hibrid).

OLAP

Aggregátum

Előre kiszámított, majd eltárolt lekérdezés, amely a tényadatokat összegzi a dimenziókban rejlő hierarchiáknak megfelelően. Az aggregált lekérdezések rengeteg adatot érintenének, a sok diszkművelet nagyon lassú működéshez vezetne. A lekérdezések előtt az előreszámítással és ezek tárolásával felgyorsíthatjuk ezt a folyamatot. Kérdés hogy milyen felbontással van szükségünk rájuk (értékesítés termékcsoportokra, hetente, megyénként). Ennek beállítása a betöltéskor szükséges. Új lekérdezésekkor ezekhez fordulunk, pl. az összes értékesítés egy héten, az aggregátumok közötti összegzés.

Def: bizonyos lekérdezések tárolt eredményei, melyek segítségével a lekérdezési teljesítményt futásidőben, virtuálisan meg tudjuk növelni. Az aggregátumot jellegzetesen az egyes dimenziókban található hierarchiák mentén szokták definiálni: egy dimenzióban több hierarchia is lehet. E mellett alkalmazható még az is, hogy az aggregátumokat több dimenzió mentén is elkészítjük. Azonban egy tényhez akár 10 dimenzió is tartozhat, dimenziónként átlagosan 4 hierarchiaszint: igencsak számításigényes... További megfontolások szükségesek a kiszámítandó aggregátumok meghatározására.

• drill down : ha egyre részletezettebb felbontást akarunk, a hierarchiában lefele megyünk. Például tudjuk az igazgatósági értékesítési számot, és az érdekel, hogy ezt hogy hozza össze az igazgatóság 3 osztálya.
• rolling up : aggregáltabb felbontást akarunk, a hierarchiában felfele megyünk. Például az igazgatóság adatai után a vállalati szintre vagyok kíváncsiak.
• drill through : a konform dimenziókon keresztül egy dimenzióstruktúrában megfogalmazott adathoz hozzá akarunk kapcsolni egy másik dimenzióstruktúrában lévő tényt. Például az értékesítést követően mikor realizálódott a termék után a pénz: egyik tény az értékesítés , a másik a megtérülés .
• slice and dice : "forgasd és szeleteld" a dimenziók kiválasztása, elhelyezése (mit, minek a függvényében). Majd bizonyos dimenziók fixálása - szeletelés. Például az adott időpillanatban vagy adott termék kapcsán vizsgálódunk.

Módszerek az adattárház adatainak hasznosítására

• Riport ("canned" report): Rendszeresen elkészített azonos témájú, néhány (50) számérték frissítésével e-mailben vagy más módon (fájlszerver, telefon) eljuttatott jelentés. Dinamikussá tehető néhány változó lekérdezés esetén kap értéket (pl. idő dimenzió: év-hó-nap)
• OLAP analízisek : ROLAP (relációs alapokon) , MOLAP (multidimenziós alapokon), HOLAP (hibrid).
• ad-hoc lekérdezések : nem jellemző, a sok elemi adat kezelhetetlensége könnyen padlóra küldheti a rendszert.

Adatbányászat

Aggregátumnavigáció, metaadat kezelés.

Adatbányászat

Adattárház

adattisztítás (data cleaning) értékhibák feltárása, csak megbízható információ beengedése, statikus szabályok mellett gyanúsnak tartott értékek esetén figyelmeztetés. Heterogén környezetből gyűjti az adatokat, akár az adatok formátumcseréje árán is. integrálás : adatforrások kiválasztása, elérése, beolvasása mintavételezés: frissítési folyamat az az aktuális állapot betöltése az eddig meglévőkhöz. transzformálás adatbányászati elemzés dokumentálás

adatkinyerés tisztítás integrálás transzformáció betöltés aggregálás lekérdezés

Megkülönböztetjük a leíró (alapjellemzők meghatározása) és a következtető (összefüggések feltárása) adatbányászatot.

Módszerei:

• csoportos leírás (jellemzők megadása)
• asszociációs szabálykeresés
• szabálygenerálás
• előrejelzés
• szegmentáció
• idősorelemzés

Eszközök:

• statisztika
• fuzzy
• neurális hálózatok
• döntési fák
• ad-hoc módszerek

Metaadat kezelés

• Definíció*: Egy másik adatot leíró, meghatározó adat, amely összefoglalja az adat használatára vonatkozó összes tényt.

Az adattárház használhatóságát alapvetően meghatározza mind az üzemeltetés mind a lekérdezés szempontjából. Hiszen a sokféle heterogén forrásrendszer adatainak, hasonló, a frissítésekkor változó adatoknak igen gazdag adatstruktúráját kell tudnunk kezelni.

• A jól struktúrált adatok szerkezete az adatok teljes terjedelméhez képest elhanyagolható.
• A Közepesen (semi-) strukúrált adatok belső szerkezetét fel lehet ismerni, de a nagysága összemérhető a teljes kezelt adattal. pl.: XML.
• A nem strukútrált adatok nem jellemezhetők, akármilyen szemantikával is próbálkozunk.

Csoportosítás

Funkció szerint:

• technikai (mezők típusa, hossza, sorrendje, csoportjai, kényszerei)
• szemantikai, más néven üzleti információs metaadatok (az adat mértékegysége)
• adminisztrációs az adattárházban zajló folyamatok járulékos adatai (indulási időpont, forrás, végrehajtott transzformációk, végrehajtott lekérdezések, lekérdezések eredménye, lekérdezések jogosultsága)
• navigációs az elérhető adatok struktúrákba szervezése, majd a végfelhasználó számára ajánlások (elkészült aktivizálható riportok felsorolása, alapstruktúrák, aggregátumok)

Befolyásoltság szerint:

• aktív : A folyamatok befolyásolási (triggelerési) lehetősége, tipikusan a jól felépített adattárházak tartoznak ebbe a csoportba
• passzív : Az események leírására szolgálnak, értelem szerűen nem befolyásolják a folyamatokat.

Illetékességi hely szerint:

• back-room
• front-room

Kapcsolódó folyamatok

Gyakorlatilag megegyezik a korábbi adatok kezelése során felsoroltakkal.

• adatkinyerés
• adminisztráció (aktualizálás, konszolidálás, mentés...)
• végfelhasználói hozzáférés

Lehetőség szerint a centralizált metaadattár és a lekérdező felület javasolt.

Szabványosítási folyamat

• MDC: MDIS
• EIA: CDIF
• MS: XML
• ORACLE: 1999-ig saját , majd 2001-től XML, végül a Object Managment Group által készített Common Warehouse Metamodell (CWM) használja.

-- adamo - 2007.11.06.