Információ menedzsment hallgatói szemmel verzió*
|
|
- Rudolf Péter
- 7 évvel ezelőtt
- Látták:
Átírás
1 Információ menedzsment hallgatói szemmel 0.8. verzió* DSS - Decision Support System... 2 Bevezető... 2 DSS... 2 OLTP vs OLAP... 3 Denormalizált Adatstruktúra... 4 OLAP... 7 Módszerek az adattárház adatainak hasznosítására... 8 Metaadat kezelés... 9 Történet as évek es évek as évek es évek után Adattárházak Definició Architektúrák Fejlődése üzemeltetési arhitektúra Relációs lekérdezések optimalizálása Heurisztikus, szabály alapú optimalizálás Költség alapú optimalizálás Lekérdezés optimalizálás csillagsémákon Adattárház módszertanok Üzleti életciklus Lakmusz teszt Pénzügyi megfontolások A projekt résztvevői Követelmények összegyűjtése Dimenziós modellezés Összegzések tervezése *hiányzó részek: Reklámkampány analízis Állomásoztató terület tervezése Közel valósidejű dw
2 DSS - Decision Support System Bevezető DSS 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. 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 az születő iparágat. Később adattárházakon alapuló döntéstámogatás váltotta őket. 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éynek válozá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őbleiség (egy adatelem mely időponbeli 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 leeht vizsgálni.
3 Az újfajta igények az adatkezeléstől gyorsabbb nagytömegű adatkezelést igényelnek. Analaitikus műveleteket támogató, hosszabb és nagyobb adatmennyiségeket érintő tranzakciók kezelése. OLTP vs OLAP A hagyományos adatkezlé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ű transzakció található meg. Az OLAP rendsezreknél viszont lényegesen kevesebb a párhuzamosan futó lekérdzés, de azok jóval hosszbb időt igényelnek, hiszen mögöttük hatalmas adatmennyiésg á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, funkcionlitás információ felhasználás struktúrált, ismétlődő műveletek válaszidő mp órák, napok érintett rekordszám kevés ad-hoc a műveletek fajtája, jellege, intenzitása igen sok lekérdezési profil kevés tábla sok tábla követelmény struktúra szervezés stabil: egy jól ismert folyamathoz ismeretlen: feltáró folyamathoz sok tábla kevés oszlop, normalizált folyamat orientált (tranzakció alapú) kevés tábla sok leíró oszlop, redundáns témaorientált adatok jellege dinamikus statikus frissítés folyamatosan bulk loading, periodikus felhasználók száma nagyszámú, egyidejű hozzáférés jellege rekordokhoz, gyorsan kevesebb, kisebb konkurencia sok rekodoz, összegzésekhez gépfelhasználás stabil nagyon dinamikus rendelkezésre állás kritikus 100% nem kritikus
4 Denormalizált Adatstruktúra Motivációk vállalati erősforrásgazdálkodási rendszer egyszerűsített ER diagrammja A tapasztalatok szerint a lekérdezésoptimalizálók rossz hatékonysággal műkönek 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 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 katasztrófá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 egy 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.
5 Elemei a tények, melyek a csillag közepét alkotják: numerikus, additív, folyamatos értékkészletű attributumokkal rendelkezik. Kevés attributum, sok sor. a dimenziók mentén a tényértékek változását kísérjük figyelemmel. Gyakran szöveges, leíró attribútumokkal rendelkezik, 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: 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
6 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 logikailagi, 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. 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. rendezett formában (busz) ábrázolás
7 Implementációs lehetőségek: relációs: tény-tábla o táblák o kulcs o 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 o dimenziók a tengelyeken o cella hordozza a tényadatok értékt o egy tényadat Pédlá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, amley a tényadatokat összegi 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égeses. Új lekérdezésekkor ezekhez fordulunk, pl. az össes é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észtelezettebb felbontást akarunk, a hiearchiá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 hiearchiá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.
8 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 ben vagy más módon (fileszerver, telefon) eljutatott jelentés. Dinamikussá tehető néhány változó lekérezé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 adattiszí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 Adattárház 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ős meghatározása és a következetető (összefüggések feltárása) adatbányászatot.
9 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 szemanitiká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)
10 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.
11 Történet 1960-as évek mainframe-ek leporellóra nyomtatták százszámra az oldalakat lassú a további adatfeldolgozás katasztrofális 1970-es évek terminál alapú rendszerek (inputok kijelzőn) 1980-as évek PC alapú rendszerek intelligens terminálok grafikus módon megjelenített adatok rendszerek: EIS (Executes Information System) (ez nem biztos, hogy így van)?! abszolút inkonziszens adatok (ellentmondásosak) kevés historikus adat (a gyenge tárak miatt) bonyolult adatbázissémák. nehéz lekérdezhetőség 1990-es évek megjelennek azok a rendszerek, amelyeket adattárházaknak nevezünk erőfeszítés az adatok egységesítésére, konzisztencia megőrzésére szemantikailag, fizikailag integrálják egyetlen igazság kiolvashatósága bármilyen lekérdezéssel. kliens server modell első megvalósítása trend analízis - > klasszikus predektív analízis internet technológia bevonultatása. döntés támogatási eszközök kiszélesítése, informatikai alapokra helyezése vékony kliensek (vállalati intranet) információ hozzáférés 2000 után internet technológiák benyomulása széleskörű hozzáférés biztosítása Közel valós idejű (real time) döntéstámogatás adat feltöltés egy időben az adatok lekérdezésével. (nem éjszaka van feltöltés).
12 Adattárházak Definició Adattárház olyan információs rendszer, melyet jellegzetes szervezeti és stratégiai döntés támogatásra használnak. Négy fő tulajdonsága van: subject-oriented : egy helyen jelennek meg az üzleti logikai fogalmak, nem rendszerekben elosztva. Korábban function-oriented-ek voltak integrated : konzisztens kód és adatformátumok time-variant : Az adatok idősorosan vannak tárolva, bármi áron kiszolgálva a múltbéli adatok elemezhetőségét. non-volatile : nincs lehetőség adatmódosításra, csak beolvasási és lekérdezési műveletek adottak. Minden betöltött adatot megőrzünk, még a vélhetően hibás adatok javítására sincs mód. Az UPDATE műveletek kizárását a nagy költségek indokolják. Az adott rekordot érvénytelenné tehető, és helyére betölthetünk egy újat/frissebbet (jelölve az adatok hatályosságát). Architektúrák koncepcionális elvi adat (konzisztencia) milyen módszerekkel front-end (végvelhasználó hogyan használja), back-end (letöltöget) eszközarchitektúra fizikailag milyen eszközök üzemeltetési milyen funkciókat biztonsági biztonság megteremtése Az koncepcionális architektúra tervezés elemei: forrásrendszerek nincs plusz terhelhetőség, max járatban így szedi ki belőle az adatot kinyerés-integrálás úgy kell az adatot kinyerni, hogy a legkisebb terheléssel és módosítással tegyük állomásoztató terület ( Staging Area - SA) A back-end nagy része. Itt zajlik az átadott adatok összekapcsolása, transzformációja, módosítása; legtöbb hozzáadott értelmet ez állítja elő. elemi adattár szakterületi adattár lekérdezésorientált adatstruktúrák tervezése és megvalósítása metaadattár üzemi adattár (operational data store - ODS) o integrált és témaorientált adatok, o nem historikus: csak a jelen helyzet olvasható ki o o aggregált adatok helyett elemieket tárol Célja: megkönnyítse az adatok integrálását, lehetővé tegye a jelen idejű adatok lekérdezését, adatmódosítás végrehajtása több rendszer érintésével (több helyen egyszerre változik az adat) MOM (Message Oriented Middleware) direkt mód megjelenítés támogatás
13 Fejlődése Összehasonlítási alapok: megvalósítás költsége megvalósíthatóság rugalmasság funkcionalitás adatkonzisztencia illeszkedés a vállalati hierarchiához. Állomások: Nem tervezett döntéstámogatás: Egyszerű (a felmerült igények mentén alakítjuk a felületet) viszont hosszú távon igen drága,hiszan a fizikailag elkülönült front-end-ek káoszt okozhatnak. Rugalmatlan (a forrásrendszerben bekövetkezett változást problémás több helyen lekezelni), inkonzisztens. Szakterületi adattár szemantikai integrálása : egységes vállalati adatomdell lekérdezhetősége és a logikai kapcsolatok felépítése. Jóval több erőfeszítést igényel, illetve új szerepkör: adatgondnok. Csökkenti a forrásrendszerek terhelését. A bemeneti adatok konzisztenciája nem biztosított, ugyanis nincs fizikai adatintegrálás. virtuálisan integrált szakterületi adattárak: funkcionalitás többletet ad a Middleware használata. függő szakterületi adattár: (hub and spoke architektúra) Mind a szemantikai mind a fizikai integritás garantált. Részletes adattárház áll rendelkezésre a beérkező adatok feldolgozása után. Az adatok összekapcsolása megvalósítja, hogyk a különbözőképpen megadott leérdezések azonos eredményt szolgáltatnak. Jól skálázható, kategórikus tiltások. o részletes adattárház - nagykereskedő o stakterületi adattár - kiskereskedő
14 üzemeltetési arhitektúra adatminőség problematikája o soha ne higyjünk annak, ha a megrendelő azt mondja, hogy jó minőségű az adatforrás o mit tegyünk a rossz adatokkal? * a rekord mögött valami valós cselekmény van * ha nem töltöm be, akkor biztos, hogy csalok * mitől rossz? * valami adat hibás, hiányos, értelmetlen * nem ahhoz a klienshez lehet kapcsolni ütemezés o betöltés, transzformáció... o elegáns megoldás éjszaka betöltés nappali lekérdezés o mi van, ha naponta többször kell adatot átvenni? hogy segít ebben a koncepcionális architektúra? közös diszk-alrendszer külön node végzi a betöltést külön node végzi a kérések kiszolgálását ha alacsonyszinten (tranzakciókezelést és constraintellenőrzést kihagyjuk), akkor sokkal gyorsabb lehet a betöltés bulk loading o kérdés az automatizáltság foka első lépésben a full automatizmus irreális cél legyen benne a potenciál, pl workflowmanagement az üzemeltetés során alakulnak ki a feltételek, amikre a későbbiek során érdemes automatizmust építeni o hogyan menedzseljük az összeg táblákat? o hogyan monitorozzuk a használatot? ki, mit, mikor kérdezett le a dw-ből? mennyire terhelt a rendszert? o o o hardware, operációs rendszer üzemeltetése fejlesztői - teszt - üzemi környezet szeparálva (teszt és üzemi adatokhoz nem szabad, hogy hozzáférjen a fejlesztő: ugyanis a teszt adatoknak valóságosnak kell lenni) fizikailag vagy logikailag szeparálva
15 Relációs lekérdezések optimalizálása Heurisztikus, szabály alapú optimalizálás Módszer : Reláció algebrai alakból felrajzolt fa optimalizálása. Lekérdezési fa elkészítése során célunk a lehető leggyorsabb alak kiválasztaása: induljunk ki a kanonikus alakból (Descartes, szűrés, projekció). lesüllyesztjük a szelekciókat átrendezzük a leveleket (először a kisebbeket descartes szorozzuk) join operandusok projekció lesüllyesztése Műveletek Fel merül a kérdés, hogy két fa mikor ekvivalens? lásd slideok Használjuk ki a halmazműveletek(únió, metszet) kommutativitását és a join Descartes-szorzat és a halmazműveletek asszociatívitását. Összefoglalva a szabályokat: kopnjunktív szelekciós feltételeket szelekciós feltételek sorozatává bontjuk. szelekciós műveleteket felcseréljük a többi művelettel átrendezzük a leveleket a Descartes szozatokat és a fölüttök lévő szelekciós kapcsolási feltételt egy join műveletté vonjuk össze. projekciós műveletekket leseréljük a többi művelettel.
16 Költség alapú optimalizálás A relációkról a renelkezésre álló információk alapján kiszámolunk több végrehajtási tervre egy költséget, és az optimálisat kiválasztjuk. Katalógusadatok Ehhez katalógusadatokat tárolunk az egyes relációkról: n_r az r rel-ben található rekordok száma (number) b_r az r rel-et tartalmazó blokkok száma (block) s_r egy rekord mérete (size) f_r mennyi rekord fér egfy blokkba (blocking factor) pl.: ha a rel rekordjai fizikailag együtt vannak tárolva, akkor b_r = [n_r/f_r] (felső egész) V(A, r) hány különböző értéke fordul elő az r rel-ben az A attr-nak SC(A, r) selection cardinality, azon rekordok átlagos száma, amelyek egy kiválasztási feltételt kielégítenek. Pl.: ha A kulcs: SC(A, r)=1 illetve általánosan: SC(A, r) = n_k / V(A, r) f_i fa struktúrájú index esetén (pl B*), pointer kimenetek átlagos száma (elágazis tényező) HT_i az index szintjeinek a száma, Pl.: HT_i = [log f_i (V(A,r))] (alsó egész), illetve hash esetén HT_i = 1 LB_i a levélszintű indexblokkok száma (lowest level index block). Hátrányok a relációk elemszámánal nyilvántartása nem triviális lekérdezni hosszú idő (~100milliós rekordszámnál pl) folyamatos frissités is nagy overhead ezért pl az ORACLE-nél külön, explicit módon kell frissíteni a katalógust (ANALYZE) itt még azt is meg lehet adni, hogy hány %-a alapján analizálja a db-t Költségszámítás Felmerül a kérdés: hogyan határozzuk meg egy reláció költségét: igényelt és felhasznált erőforrások alapján? válaszidő alapján? (az összes rekord vagy az első válasz rekord válaszideje alapján?) kommunikációra fordított idő alapján? (elosztott rendszereknél fontos) A definicó szerint legyen egy reláció költsége a háttértár blokkolvasások és írásak száma a válasz kiíratásának ktg-e nélkül (uis a diszkolvasás ms nagyságrendű, a blokk feldolgozása pedig ennek pl 100-a). Ez az érv kezdi érvényét veszteni, amikor ~100GB-os memóriák is vannak, és lehet az egész db-t memóriában tárolni.
17 Operációk műveletek költsége SELECT attribútum = alapján A1 - lineáris keresés ktg: E_A1=b_r A2 - bináris keresés o feltételi, hogy a blokkok folyamatosan az A attribútum szerint rendezettek legyenek a diszkeken, illetve, hogy a szelekció feltétele az A attribútumon legyen. o ktg E_A2 = [log2(b_r)] + [SC(A,r)/f_r] -1, ahol az első tag: binárisan megkerünk 1 blokkot, a második tag: több rekord is egyezhet, ezek ennyi rekordban vannak, illetve a harmadik tag: az első blokk megtalálását kétszer számolnánk egyébként. A3 - elsődleges indexszel, kulcsot vizsgálva o ktg: E_A3 = HT_i + 1, ahol az első tag: indexfa végigjárása illetve a második tag: adatblokk beolvasása. A4 - elsődleges indexszel, de ez nem kulcs o ktg E_A4 = HT_i + [SC(A, r)/f_r], ahol első tag: indexfa végigjárása második tag: adatblokkok beolvasása A5 - másodlagos index használatával o ktg: E_A5 = HT_i + SC(A, r), ahol az első tag: indexfa végigjárása illetve a második tag: adatblokkok beolvasása (ui a blokkok nem sorban vannak egymás utáni blokkoban) E_A5 = HT_i + 1 (ha A kulcs). SELECT összehasonlítás alapú szelekció: A<v ha v-t nem ismerjük: n_r/2-t kapunk vissza ha v-t ismerjük, egyenletes eloszlás esetén n_ált = n_r((v-min(a,r))/(max(a,r)-min(a,r))) A6 - elsődleges index használatával o ha a v-t nem ismerjük E_A6 = HT_i + b_r/2 o ha v-t ismerjük E_A6 = HT_i + [c/f_r], ahol c a találati halmaz várható nagysága A7 - másodlagos index E_A7 = HT_i + LB_i/2 + n_r/2, ahol az első tag: végigmegyünk az indexfán, a második tag: az indexfa leveleit olvassuk illetve a harmadik tag: az adatblokkok olvasás. Ez igencsak nem gazdaságos, ugyanis, ha bután, kimerítően keresek, akkor b_r-nyit kell csak olvasni SELECT komplex szelekció Mind a konkunkció és diszjunkció esetén nem bonyolultabb, mint egy szimpla szelekció becslése.
18 JOIN nested loop join o worst case ktg: n_r*b_s + b_r (ha legalább az egyik belefér a memóriába, akkor a ktg b_r+b_s) block nested loop join o 4 ciklus egymásban (2: 1-1 blokkok mindig felolvasok mind2 relációból + 2: blokkon belül illesztek o worst-case ktg: b_r*b_s+b_r (sok memory: b_r+b_s) indexed nested-loop join o az egyik rel-hez van indexünk o az első alg-ot nézzük, a belső ciklusban az indexelt reláció legyen o ktg: b_r+n_r*c, ahol a c a szelekció ktg-e s-en sorted merge-join o a rel-kat a join feltételben meghatározott attr-ok mentén rendezzük, majd fésüljük hash-join o az egyik rel-t hash-táblán keresztül érjök el, miközben a másik rel-t egy adott rekordjához illeszkedő rekordok keressük egyéb o pl bitmap indexszel, bitmap join Egyéb operációk CSONK Egy kifejezés kiértékelésnek módjai Materializáció: def Egyszerűen implementálható viszont sok háttértár műveletet igényel. Pipelineing: Szimultán kiértékelés, a részegységek az előttük álló elemből kapott eredményekből a sorban következő számára állítanak elő részeredményeket. Nincs szükség a teljes reláció előre kiszámolására. Ezáltal az ideiglenes tárolási igényeket minimalizálja, kicsi memóriaigény. viszont leszűkíti az alkalmazható algoritmusok körét. A kiértékelési terv kiválasztása A terv során válaszolnunk kell a következő kérdésekre: milyen műveleteket kívánunk elvégezni milyen sorrendben milyen algoritmus használatával milyen workflow szerint. Ha minden ekvivalens kifejezést (költség alapú optimalizáció) megvizsgálnanák és minden formát kiértékelnénk (azzal a céllal, hogy a végén az optimálisat válasszuk ki), túl nagy terlhelést jelentene a rendszer számára. Ezért Heurisztikus költség alapú optimalizálást érdemes használni. Mindezt automatikusan vagy manuálisan? Az automata szélesebb ismerettel rendelkezik a
19 letárolt adatelemekről, gyorsabb a numerikus kiértékeliési mechanizmusa, szisztematikusan értékel, algoritmusa több szakember együttes tudását hordozza, dinamikusan minden műávelet előtt az aktuális feltételeket figyelembe véve értékel. Ezzel szemben az ember szélesebb általánso ismerettel rendelkezik, a probléma szemantikai tartalmát megérti, nagyobb szabadsággal rendelkezik a felhasználható módszerek, eszközök tekintetében illetve jobban fel van készítve a váratlan helyzetek kezelésére. Lekérdezés optimalizálás csillagsémákon Az Oracle 7-es verziójától érhető el, különbözik a korábbi filozófiától, nagyságrendekkel hatékonyabb: lényegében egy illesztés a ténytábla és a dimenziós táblák között. A dimenziós táblák join-jának kiküszöbölése, lehetőség az automatikus felismerésre. Két ismert séma (hópihe,csillag közül a csillagsémákon vizsgáltuk részletesen a lekérdezésoptimalizálást. Hópihe séma A hópihe sémáról megemlítettük, hogy gyenge browsing teljesítménnyel rendelkezik ha növeljük a relációk számát. Itt a dimenziós táblák nem önmagukban állnak, hanem több tábla írja le a különböző hierarchia-szinteket. A gyakorlati tapasztalat azt mutatja, hogy az adattárház hozzáférések 80-90%-a dimenziók megfelelő kezelésével, a hatalmas lekérdezés előkészítésével foglalkozik.
20 Csillag séma A csillag séma kialakításának feltétlei (Oracle): egyattribútumos bitmap index definiálása a tény valamennyi idegen kulcsára inicializáló paraméter beállítása (STAR_TRANSFORMATION_ENABLED should be set to TRUE) költségalapú optimalizálás használata Bitmap (bittérkép) lehetőleg alacsony kardinalitású attribútumot válassznk (azaz kevés különböző érték forduljon elő) Pl.: Az alkalmazott nemének (férfi-nő) tárolására: definiálunk egy kétoszlopos indexet, az értékeknek megfelelően (annyi oszlop, ahány érték). A táblázat sorai a sorszámnak megfelelően be van indexelve külső kulccsal a relációhoz. mivel alacsonykitöltésű a táblázat, ezért tömöríteni szokták: a töredékére összenyomható bizonyos szelekciók kiértékelését nagyon meg tudja könnyíteni (a bitmap indexek jóval kisebbek, könnyebb vele bánni) bővebben lásd wikipédia.
21 Csillag transzformáció Az Oracle query optimalizáló modulja végzi el az SQL utasítás átírását, ahol ez hasznos lehet. A művelet két lépésből áll, elsőnek a szükséges sorokat választja ki a tény táblából, ez a bitmap indexelés használata miatt igen hatékény. A második lépésben az így kapott eredményhalmazt JOIN -oljuk a dimenziós táblákkal. Lássunk egy csillag queryt: SELECT ch.channel_class, c.cust_city, t.calendar_quarter_desc, SUM(s.amount_sold) sales_amount FROM sales s, times t, customers c, channels ch WHERE s.time_id = t.time_id AND s.cust_id = c.cust_id AND s.channel_id = ch.channel_id AND c.cust_state_province = 'CA' AND ch.channel_desc in ('Internet','Catalog') AND t.calendar_quarter_desc IN ('1999-Q1','1999-Q2') GROUP BY ch.channel_class, c.cust_city, t.calendar_quarter_desc; Az első transzformációs lépés után a három bitmap (time_id, cust_id, channel_id) index felismerése után AND operátorral kötjük össze: SELECT... FROM sales WHERE time_id IN (SELECT time_id FROM times WHERE calendar_quarter_desc IN('1999-Q1','1999-Q2')) AND cust_id IN (SELECT cust_id FROM customers WHERE cust_state_province='ca') AND channel_id IN (SELECT channel_id FROM channels WHERE channel_desc IN('Internet','Catalog')); Az így kapott eredményhalmazon végül a dimenziók mentén JOIN művelet következik. Ennek hatékonyságát növeli, hogy a bitmapnak köszönhetően effektíve egyetlen JOIN művelet elegendő a dimenziónkénti JOIN -ok helyett. Megállapíthatjuk, hogy a csillagtranszformáció elég jól működik, ha a WHERE predikátum kellően szelektív a tényrekordra, viszont ha sok tényrekord értintett az eredmény előállításában, akkor "full table scan" jobb lehet...
22 Adattárház módszertanok Üzleti életciklus Az egyes módszerek közös pontja, hogy iteratívan képzeli el a DW kialakítását, fázisokat definiálnak. Hadden-Kelly: Preparing - Planning - Building - Operating HP Open Warehouse Oracle Warehouse Methodology Ralph Kimball SAS Lakmusz teszt Nagy adattárház gyakorlattal rendelkező szakértők állították össze, választ ad arra a kérdésre, hogy adott helyzetben, adott cégnek van-e szüksége DW használatára. Lolopop.Readiness.Test.pdf Do You Have A Strong Business Management Sponsor? Is There A Compelling Business Motivation? Is There A Strong Information Systems (IT)/Business Partnership? What Is Your Current Analytic Culture? What Is The Feasibility For Undertaking A Data Warehouse Project? A kérdéscsoprtok súlya: , 1-5-ös skála szerint kell osztályozni. A DW bevezetése célszerű, ha négynél nagyobb, három és négy között: nem rossze eredmény, de érdemes odafigyelni a 3-nál kisebbes tételekre. Kettő és három közti érték esetén határeset, érdemes a céget fejleszteni olyan irányba, hogy jobb választ lehessen adni ezekre a kérdésekre. Kérdéses, hogy ez megéri-e. Kettőnél kisebb átlag elérése esetén egyáltalán nem ajánlott DW bevezetése a vizsgált környzetbe. A teszt iránymutatásnak jó, a DW bevezethetőségét nem feltétlenül ez alapján érdemes eldönteni. Pénzügyi megfontolások A ROI (Return of Investment) határoz meg mindent. Költségek közt számolni kell a SW/HW vásárlásokkal, belső fejlesztésekkel, külső erőforrásokat veszünk igénybe, támogatással (support) és a növekedéssel (üzleti folyamatok optimalizálása, átalakítása). Ezek mennyiség és eloszlása igen jó becsülhető. Haszonként ezért cserébe bevételnövekedést (gyorsabb piacrajutás, forgalomnövekedés a jobb termék pozicionálás eredményeképp) és költségcsökkenést érhetünk el.
23 A projekt résztvevői Heterogén csapat kialakítása a feladat: PROJEKT MANAGER főmérnök - architect (a technika összeálljon egy egésszé) üzleti analitikus (a folyamatokat átlássa) biztonság tervező (kritikus, üzleti titkok kezelése) adatgondnok (naprakész infó az adatok jelentéséről, elérhetőségéről... -> humánkiegészítésű metaadattár) adatmodellező betöltés tervező front-end tervező (végfelhasználók kiszolgálása) adatminőségbiztosító ("rubish in - rubish out") stb. Követelmények összegyűjtése alapelvek Indirekt kérdezzünk rá a dolgokra, segíteni kell aa stratégiai kezdeményezések felismerését. Meg kell határozni sikerességi mutatókat. Azokat a legfontosabb üzleti folyamatokat kell kiválasztani, melyeknek javítása jelentős kihatással jár (például a legtöbb pénzt mozgató folyamatok). interjúk lebonyolítása Az interjúkészítőnek beszélgető partnernek kell lenni: legyen tapaszalt és a tárgyterülettel kellően tisztában. Ugyanakkor az üzlethez kell érteni, nem a technológiához. Ismerje hogy milyen módszerrel állhat neki, milyen kérdéseket érdemes feltennie, milyen sorrendben. Az ötletelésnek nincs helye (drága a partner ideje...). Kiket kérdezzünk meg? A legfelsőbb vezetőket (stratégiai kérdésekben), üzleti kulcsszereplőket (a folyamatokról), a középvezetőket (ők a földön járnak...), az IT részleget (a környezet előkészítettsége rajtuk áll), illetve végül, akiket muszáj megkérdezni politikai okokból (megéri, különben kerékkötője lesz a projektnek). szokásos kérdések egy interjún az adott vezető szervezetének mi a helye a cégben, a vezetőnek mi a felelőssége? az adott vezető szervezetének mi az üzleti célja? hogyan és milyen gyakran szokták mérni az eredményességet személyre, szervezetre vonatkozóan? milyen problémáik vannak? a tapasztalataik szerint mi akadályozza legfőképpen a céljaik elérésében? milyen rutinszerű analíziseket használnak ténylegesen? szoktak-e kérni adhoc elemzéseket? milyen akadályai vannak, hogy a megfelelő információkhoz hozzájussanak? milyen régi infókhoz szoktak hozzányúlni, minek van értelme, mennyire karakterisztikus a jövőre? milyen üzleti lehetőségekhez fogna, ha megfelelő infók állnának a rendelkezésre?
24 Sikerkritériumok meghatározása Az adattárház folyamatosan fejlesztendő rendszer ("egy adattárház addig él, amíg változtatnak rajta"), ugyanis a környezet is folyamatosan változik. A folyamatos változás miatt a kezdeti elképzelés változhat. Bizonyos analízistípusokat le tud-e szállítani, célszerű ellenőrizni, hogy adott idő alatt lefut-e az analízis? Mennyi megfelelően transzformált adat áll a rendelkezésre? Ténylegesen hányan használják a rendszert? konszolidálás, priorizálás, konszenzus kialakítása Az igényeket érdemes csoportosítani és prioritásokat felállítani. Mit, mi mentén akarunk elemezni. A prioritás meghatározásának szempontjai. érintett pénzvolumen milyen adatok, milyen rendszerekből szükségesek (a rendszerek legyenek jól dokumentáltak illetve a dokumentáció legyen konzisztens a valósággal). mennyire komplex, mekkora adatmennyiség Dimenziós modellezés előnyök lekérdezés könnyen optimalizálható a modell bővítése egyszerű, nem kell átstruktúrálni az adatbázist, ha új adatot veszünk fel laikusok által is könnyen lekérdezhető a lekérdezést nem kell megváltoztatni, ha az adattárház bővül négylépéses dimenziós modellezés 1. üzleti folyamat azonosítása o szolgáltatás használata o hitelek igénylése, felvétele o bevéltelek alakulása o kinnlévőségek o rendelések o személyzeti ügyek o számlázás o javítások és reklamációk 2. tényadat granularitásának megválasztása - milyen részletes adatok tárolását támogatjuk o túl részletes (sok adat, nagy diszk-, CPU-igény) o nem elég részletes (elemzéseket akadályozhat meg) o le kell írni a tényrekord pontos jelentését 3. dimenziók azonosítása - mi alapján akarunk rendezni, lekérdezni, csoportosítani a tényadatokat? o sok és részletes dimenzió => változatosabb analízisek, sok erőforrásigény o az igényeket szembesíteni kell az üzleti lehetőségekkel 4. tények azonosítása - általában numerikusak és folyotonos értékkészletűek pl.: eladott áru darabszáma, eladási ár forintban, átlagos kisker ár
25 dimenziós tervezési elvek Ismerjük meg és értsük pontosan a kezelt adatokat. ténytáblák A ténytáblában legyenek rövid rekordok (lehető legkisebb granularitás), kódokkal teli, rendelkezzen azonosítókkal. additív tényadatok: általában összegezhető adatokat kell választani nem additív tényadatok: egyáltalán nem összegezhetőek, egyetlen dimenzió mentén sem szemi-additív tényadatok: minden dimenzió szerint összegezhető, kivéve az időt. (általánosabban: egyes dimenziók szerint összegezhető, mások szerint nem). Ténynélküli ténytáblák valójában klasszikus több-több kapcsolatok, pl. óralátogatási szokás ( időpont, tárgy, terem, diák, tanár ) vagy egy termék-kampány lefedettségi táblái ( eladás, termék, bolt, idő, kampányjellemzők ) Nem ad választ arra, hogy mit nem adtak el abból, amiről a kampány szólt. Legyen egy másik ténytábla rekordja, mely a kampányban való résztvételt jelenti. Az esemény-tények egyetlen időponthoz köthetőek, az állapot tény viszont két időponthoz (kezdet+vég). Itt azonban új tényrekord beszúrása egy másik lezárásával jár, ez egyrészt alacsonyabb hatékonyságú másrészt valószínűsíthető az információveszteség. Ugyanakkor egymásba átalakíthatók. dimenziós táblák A dimenziós táblákban foglalnak helyet a leíró attribútumok (a rekordok hossza kevéss kritikus, akár igen nagyszámú is lehet). Konform dimenziókat használjunk. A felesleges dimenziók teljesítményveszteséget eredményznek. A dimenziós adatok nem feltétlenül nyerhetők ki valamely forrásrendszerből. Általában az idő, termék, hely, ügyfél a leggyakoribb dimenzió. Minden dimenzió rendelkezzen egy surrogate kulccsal, mely anonym, kiegészítő, jelentés nélküli, mesterséges. A surrogate kulcs használatával elég jó méretcsökkentést tudunk elérni a ténytáblákban. A forrásrendszeri kulcs változásaitól függetlenek lesz a rendszerünk, sőt az entitások időbeli változásait is le tudjuk így írni. Hátránya ugyanakkor, hogy a tény és dimenziós rekordok újrakulcsolával jelentős betöltési overheadet kapunk.
26 Role-playing dimenziók többféle jelentést is hordozhatnak a tényadathoz kapcsolódóan, például egyetlen fizikai idődimenzió több kulccsal kapcsolódhat a tényrekordhoz Degenerált dimenziók olyan leíró (rövid dimenziós jellegű) adatok, melyeket a ténytáblában helyezünk el különösebben kapcsolódó dimenzió nélkül. Például egy dokumentunk egyedi sorszáma, számlaszám. Velük a forrásrendszerben könnyen lehet azonosítani valamit, így egyedi megfontolásból kerülnek be. Junk dimenziók nem mindig szervezhetők dimenziókba egy vagy néhány jelentés nélküli dimenziót alkotó elemeket nevezzük így, melyeket a ténytáblában nem célszerű elhelyezni: flagek, szöveges leírók. idővel változó dimenziók SCD (slowly changeing dimensions) kezelésére három módszert használhatunk: o felülírás : egyszerűen megvalósítható, de adatvesztéssel jár. o o old mező létrehozása : szintén gyorsan implementálható, de korlátozott history. új dimenziós rekord beillesztése : teljes history építhető fel vele, nehézkesebb keresési műveletek. Összegzések tervezése Összegzésnek nevezzük azokat az előre kiszámított speciális lekérdezéseket, mleyekben a ténytábla tényadatait összegezzük bizonyos feltételek mentén. Azaz a dimenziókban lévő hierarchiákat összenyomjuk és a tényadatokat ennek megfelelően összegezzük. Ezáltal elérhetjük a meglévő teljesítményi korlátok betartását. Garantálnunk kell akár 1000-es nagyságrendű egyidejűleg futó összegzést is. Ehhez azonban minda fizikai adatszervezést, mind az összegzéseket terveznünk kell, illetve a lekérdezést a végletegik optimalizálnunk. Az összegzéseket új ténytáblákban ildomos tárolni, ehhez azonban új dimenziós táblák is kellenek (+ a hozzájuk tartozó surrogate kulcsok). Az új ténytáblák és dimenziós táblák (granularitás csökkentésével) szerkezetének kialakításakor a már meglévőkből is képezhetjük. Pédldául termékek helyett márkákra aggregálunk. Ezáltal egy új márka kulcs jön létre. Az összegzések méretezésekor célszerű legalább 10:1 arányú rekorszámcsökkenést eszközölni. Ennek mérőszámai a dimenzió kompresziója és az együttes előfordulási gyakoriság (density). Az előző példánál maradva ha egy márkához átlagosan 50 termék tartozik, akkor a márkán definiált összegzés 50x komresszióval bír termék, bolt, nap előfordulási gyakoriság: egy adott boltban, azon a meghatározott napon a termékek 10%át adták el átlagosan márka, bolt, nap előfordulási gyakoriság: egy adott boltban, azon a meghatározott napon a márkák 50%át adták el átlagosan Az összegzések közti navigációt egy külön rétegnek kell kiszolgálnia, mely meghatározza, hogy melyik a legalkalmasabb összegzés a felhasználói lekérdzeés kiszolgálására, ezáltal növelve a rendszer teljesítőképességét és kényelmes használhatóságát. Igyekezni kell kerülni a túl sok összegzés definiálását, hiszen nem mindegyik összegzés fogja jelentősen csökkenteni a lekérdezett sorok számát. Ennek kiszámítása futás-idejű feladat.
RELÁCIÓS LEKÉRDEZÉSEK OPTIMALIZÁLÁSA. Marton József november BME TMIT
RELÁCIÓS LEKÉRDEZÉSEK OPTIMALIZÁLÁSA Marton József 2015. november BME TMIT ÁTTEKINTÉS lekérdezés (query) értelmező és fordító reláció algebrai kifejezés optimalizáló lekérdezés kimenet kiértékelő motor
RészletesebbenAdatbázisok analitikus környezetben. Adatbázisok elmélete 4. előadás Gajdos Sándor
Adatbázisok analitikus környezetben Adatbázisok elmélete 4. előadás Gajdos Sándor Tartalom Döntéstámogatás általában OSS vs. DSS Multidimenziós modellezés Hozzáférési módok, BI eszközök Lekérdezés optimalizálás
RészletesebbenRELÁCIÓS LEKÉRDEZÉSEK OPTIMALIZÁLÁSA. Dr. Gajdos Sándor november BME TMIT
RELÁCIÓS LEKÉRDEZÉSEK OPTIMALIZÁLÁSA Dr. Gajdos Sándor 2014. november BME TMIT TARTALOM Heurisztikus, szabály alapú optimalizálás Költség alapú optimalizálás Katalógus költségbecslés Operációk, műveletek
RészletesebbenAdattárházak. Gajdos Sándor, TMIT ősz
Adattárházak Gajdos Sándor, TMIT 2015. ősz Döntéstámogató rendszerek (DSS: decision support systems) Kommunikáció-orientált Adat-orientált Dokumentáció-orientált Tudás-orientált Modell-orientált Kommunikáció-orientált
RészletesebbenMarton József BME-TMIT. Adatbázisok VITMAB november 11.
Marton József BME-TMIT Gajdos Sándor diasorának felhasználásával Adatbázisok VITMAB00 2016. november 11. A lekérdezés-feldolgozás folyamata I. Cél: az adatok adatbázisból való kinyerése Mivel: egyértelmű,
RészletesebbenAdattárház alapú vezetői információs rendszerek
Adattárház alapú vezetői információs rendszerek Gajdos Sándor gajdos@tmit.bme.hu Adatbázisok haladóknak 2012. 2012. szeptember 11. Bevezető Fő kérdések: Mitől lesz egy adattárház projekt sikeres? Mik a
RészletesebbenI. RÉSZ. Tartalom. Köszönetnyilvánítás...13 Bevezetés...15
Tartalom 5 Tartalom Köszönetnyilvánítás...13 Bevezetés...15 I. RÉSZ AZ ALAPOK... 17 1. fejezet Egy kis történelem...19 A korai MIS rendszerektől az alapgondolatig...19 Operatív és analitikus rendszerek
RészletesebbenAdatbázisrendszerek április 17.
Adatbázisrendszerek Áttekintés az adattárházakról és az OLAP-ról 2018. április 17. Az adattárházak célja 2 A számítási kapacitások állandó növekedése és az analitikai eszközök és módszerek egyre összetettebbé
RészletesebbenAdatmodellezés. 1. Fogalmi modell
Adatmodellezés MODELL: a bonyolult (és időben változó) valóság leegyszerűsített mása, egy adott vizsgálat céljából. A modellben többnyire a vizsgálat szempontjából releváns jellemzőket (tulajdonságokat)
RészletesebbenDW 9. előadás DW tervezése, DW-projekt
DW 9. előadás DW tervezése, DW-projekt Követelmény felmérés DW séma tervezése Betöltési modul tervezése Fizikai DW tervezése OLAP felület tervezése Hardver kiépítése Implementáció Tesztelés, bevezetés
RészletesebbenTörténet John Little (1970) (Management Science cikk)
Információ menedzsment Szendrői Etelka Rendszer- és Szoftvertechnológia Tanszék szendroi@witch.pmmf.hu Vezetői információs rendszerek Döntéstámogató rendszerek (Decision Support Systems) Döntések információn
RészletesebbenEllenőrző kérdések. 36. Ha t szintű indexet használunk, mennyi a keresési költség blokkműveletek számában mérve? (1 pont) log 2 (B(I (t) )) + t
Ellenőrző kérdések 2. Kis dolgozat kérdései 36. Ha t szintű indexet használunk, mennyi a keresési költség blokkműveletek számában mérve? (1 pont) log 2 (B(I (t) )) + t 37. Ha t szintű indexet használunk,
RészletesebbenBGF. 4. Mi tartozik az adatmodellek szerkezeti elemei
1. Mi az elsődleges következménye a gyenge logikai redundanciának? inkonzisztencia veszélye felesleges tárfoglalás feltételes függés 2. Az olyan tulajdonság az egyeden belül, amelynek bármely előfordulása
RészletesebbenSikerünk kulcsa: az információ De honnan lesz adatunk? Palaczk Péter
Sikerünk kulcsa: az információ De honnan lesz adatunk? Palaczk Péter Bevezető az Oracle9i adattárházas újdonságaihoz Elemzési és vezetői információs igények 80:20 az adatgyűjtés javára! Adattárházak kínálta
RészletesebbenVállalati információs rendszerek I, MIN5B6IN, 5 kredit, K. 4. A meghirdetés ideje (mintatanterv szerint vagy keresztfélében):
Követelményrendszer 1. Tantárgynév, kód, kredit, választhatóság: Vállalati információs rendszerek I, MIN5B6IN, 5 kredit, K 2. Felelős tanszék: Informatika Szakcsoport 3. Szak, szakirány, tagozat: Műszaki
RészletesebbenVIR alapfogalmai. Előadásvázlat. dr. Kovács László
VIR alapfogalmai Előadásvázlat dr. Kovács László Információ szerepe Információ-éhes világban élünk Mi is az információ? - újszerű ismeret - jelentés Hogyan mérhető az információ? - statisztikai - szintaktikai
RészletesebbenAdatbázis rendszerek. dr. Siki Zoltán
Adatbázis rendszerek I. dr. Siki Zoltán Adatbázis fogalma adatok valamely célszerűen rendezett, szisztéma szerinti tárolása Az informatika elterjedése előtt is számos adatbázis létezett pl. Vállalati személyzeti
RészletesebbenVezetői információs rendszerek
Vezetői információs rendszerek Kiadott anyag: Vállalat és információk Elekes Edit, 2015. E-mail: elekes.edit@eng.unideb.hu Anyagok: eng.unideb.hu/userdir/vezetoi_inf_rd 1 A vállalat, mint információs rendszer
RészletesebbenVÁLLALATI INFORMÁCIÓS RENDSZEREK. Debrenti Attila Sándor
VÁLLALATI INFORMÁCIÓS RENDSZEREK Debrenti Attila Sándor Információs rendszer 2 Információs rendszer: az adatok megszerzésére, tárolására és a tárolt adatok különböző szempontok szerinti feldolgozására,
RészletesebbenTartalom. Konfiguráció menedzsment bevezetési tapasztalatok. Bevezetés. Tipikus konfigurációs adatbázis kialakítási projekt. Adatbázis szerkezet
Konfiguráció menedzsment bevezetési tapasztalatok Vinczellér Gábor AAM Technologies Kft. Tartalom 2 Bevezetés Tipikus konfigurációs adatbázis kialakítási projekt Adatbázis szerkezet Adatbázis feltöltés
RészletesebbenInfor PM10 Üzleti intelligencia megoldás
Infor PM10 Üzleti intelligencia megoldás Infor Üzleti intelligencia (Teljesítmény menedzsment) Web Scorecard & Műszerfal Excel Email riasztás Riportok Irányít Összehangol Ellenőriz Stratégia Stratégia
RészletesebbenAdattárház tiszta alapokon Oracle Day, Budapest, november 8.
Adattárház tiszta alapokon Oracle Day, Budapest, 2011. november 8. WIT-SYS Consulting Zrt. Lévai Gábor gabor.levai@wit-sys.hu Tematika Az adattárházról általánosan Az adattárház definíciója Fő jellemzők
RészletesebbenNév- és tárgymutató A, Á
313 Név- és tárgymutató A, Á Accumulating snapshot. Lásd Tényegyedek és táblák, gyűjtött pillanatfelvétel Adatbázis tervezése módszertani folyamat, 36 több fázison keresztül, 37 Adatgazda, 39 Adatkinyerés.
RészletesebbenVan-e ingyen-ebéd? Avagy mire elég a nyílt forráskodú Pentaho? Fekszi Csaba Ügyvezető 2012. október 4.
Van-e ingyen-ebéd? Avagy mire elég a nyílt forráskodú Pentaho? Fekszi Csaba Ügyvezető 2012. október 4. Omnit Solutions 2007 óta a piacon BI & adattárház tanácsadás 20 fős csapat Oracle, IBM és Pentaho
RészletesebbenTudásalapú információ integráció
Tudásalapú információ integráció (A Szemantikus Web megközelítés és a másik irány) Tanszéki értekezlet, 2008. május 14. 1 Miért van szükségünk ilyesmire? WWW: (Alkalmazások) Keresés a weben (pl. összehasonlítás
RészletesebbenAdatbázisműveletek és lekérdezésoptimalizálás
és lekérdezésoptimalizálás Nagyméretű adathalmazok kezelése Kazi Sándor 2010. február 24. Kazi Sándor (kazi@cs.bme.hu) és lekérdezésoptimalizálás 1 / 39 1 Bevezetés 2 3 4 5 6 7 Kazi Sándor (kazi@cs.bme.hu)
RészletesebbenBEVEZETÉS AZ ADATTÁRHÁZ AUTOMATIZÁLÁSBA
BEVEZETÉS AZ ADATTÁRHÁZ AUTOMATIZÁLÁSBA Gollnhofer Gábor JET-SOL Kft. Nyilvántartási szám: 503/1256-1177 JET-SOL KFT. Alapadatok 2003-ban alakultunk Több mint 120 magasan képzett munkatárs Ügyfélkör Nagyvállalati
RészletesebbenAdatmodellezés, alapfogalmak. Vassányi István
Adatmodellezés, alapfogalmak Vassányi István Alapok A helyes modell az információs rendszer későbbi használhatóságánakazalapja, olyanmint a jómunkaruha: véd, de nem akadályozza a munkát Objektum-orientált
RészletesebbenTartalom. Jó hogy jön Jucika, maga biztosan emlékszik még, hányadik oldalon van a Leszállás ködben.
Tartalom Jó hogy jön Jucika, maga biztosan emlékszik még, hányadik oldalon van a Leszállás ködben. Előszó 1. Az adatbányászatról általában 19 1.1. Miért adatbányászat? 21 1.2. Technológia a rejtett információk
RészletesebbenAdatbáziskezelés. Indexek, normalizálás NZS 1
Adatbáziskezelés Indexek, normalizálás NZS 1 Fáljszervezés módjai Soros elérés: a rekordok a fájlban tetszőleges sorrendben, például a felvitel sorrendjében helyezkednek el. A rekord azonosítója vagyis
RészletesebbenAz adatok a vállalat kulcsfontosságú erőforrásai. Az információs rendszer adatai kezelésének két alapvető változata:
ADATSZERVEZÉS Az adatok a vállalat kulcsfontosságú erőforrásai. Az információs rendszer adatai kezelésének két alapvető változata: fájlrendszerek (a konvencionális módszer) és adatbázis rendszerek (a haladóbb
RészletesebbenADATBÁZIS-KEZELÉS - BEVEZETŐ - Tarcsi Ádám, ade@inf.elte.hu
ADATBÁZIS-KEZELÉS - BEVEZETŐ - Tarcsi Ádám, ade@inf.elte.hu Számonkérés 2 Papíros (90 perces) zh az utolsó gyakorlaton. Segédanyag nem használható Tematika 1. félév 3 Óra Dátum Gyakorlat 1. 2010.09.28.
RészletesebbenMicrosoft SQL Server telepítése
Microsoft SQL Server telepítése Az SQL Server a Microsoft adatbázis kiszolgáló megoldása Windows operációs rendszerekre. Az SQL Server 1.0 verziója 1989-ben jelent meg, amelyet tizenegy további verzió
RészletesebbenAlkalmazásokban. Dezsényi Csaba Ovitas Magyarország kft.
Tudásmodellezés Kereskedelmi Alkalmazásokban Dezsényi Csaba Ovitas Magyarország kft. Tudásmenedzsment Adat -> Információ -> Tudás Intézményi tudásvagyon hatékony kezelése az üzleti célok megvalósításának
RészletesebbenÖnkiszolgáló BI Az üzleti proaktivítás eszköze. Budapest,
Önkiszolgáló BI Az üzleti proaktivítás eszköze Budapest, 2016.10.27 Tartalom 1. Kihívások Való Világ 2. Hogyan segít az Önkiszolgáló BI? confidential 10/26/2016 2 Riportokkal szembeni igények alakulása
RészletesebbenCsima Judit szeptember 6.
Adatbáziskezelés, bevezető Csima Judit BME, VIK, Számítástudományi és Információelméleti Tanszék 2017. szeptember 6. Csima Judit Adatbáziskezelés, bevezető 1 / 20 Órák, emberek heti két óra: szerda 14.15-16.00
RészletesebbenInformatikai alapismeretek Földtudományi BSC számára
Informatikai alapismeretek Földtudományi BSC számára 2010-2011 Őszi félév Heizlerné Bakonyi Viktória HBV@ludens.elte.hu Titkosítás,hitelesítés Szimmetrikus DES 56 bites kulcs (kb. 1000 év) felcserél, helyettesít
RészletesebbenADATTÁRHÁZ MENEDZSMENT ÉS METAADAT KEZELÉS
ADATTÁRHÁZ MENEDZSMENT ÉS METAADAT KEZELÉS Gollnhofer Gábor JET-SOL Kft. Nyilvántartási szám: 503/1256-1177 TARTALOM Bemutatkozás Adattárház menedzsment szemszögből Mi kell a sikeres adattárházhoz? Kérdések
RészletesebbenAz információ hatalom. adatok. információ
DW 3. előadás Az információ hatalom adatok információ Információs rendszerek Hagyományos adatforrások (legacy system) Virt. vállalati Virtual coop. Információs Informational Döntési (Decisional) Műveleti
RészletesebbenAdatbázis, adatbázis-kezelő
Adatbázisok I. rész Adatbázis, adatbázis-kezelő Adatbázis: Nagy adathalmaz Közvetlenül elérhető háttértárolón (pl. merevlemez) Jól szervezett Osztott Adatbázis-kezelő szoftver hozzáadás, lekérdezés, módosítás,
RészletesebbenADATBÁZISOK ADATBÁZIS-KEZELŐ RENDSZEREK. Debrenti Attila
ADATBÁZISOK ADATBÁZIS-KEZELŐ RENDSZEREK Debrenti Attila Az adatbázis fogalma 2 Számos egzakt, tudományos definíció. Hétköznapi definíció: az adatbázis valamilyen jól definiált rendszer szerint tárolt adatokból
RészletesebbenNyilvántartási Rendszer
Nyilvántartási Rendszer Veszprém Megyei Levéltár 2011.04.14. Készítette: Juszt Miklós Honnan indultunk? Rövid történeti áttekintés 2003 2007 2008-2011 Access alapú raktári topográfia Adatbázis optimalizálás,
RészletesebbenAdatbázisok elmélete
Adatbázisok elmélete Adatbáziskezelés, bevezető Katona Gyula Y. Számítástudományi és Információelméleti Tanszék Budapesti Műszaki és Gazdaságtudományi Egyetem Katona Gyula Y. (BME SZIT) Adatbázisok elmélete
RészletesebbenData Vault 2.0 és az Oracle DW/BD referencia architektúra. Gollnhofer Gábor Meta Consulting Kft.
Data Vault 2.0 és az Oracle DW/BD referencia architektúra Gollnhofer Gábor Meta Consulting Kft. Az Oracle referencia architektúrák Rövid bevezető Az IT Strategies from Oracle (ITSO) része Átgondolt, bevált,
RészletesebbenGazdasági informatika alapjai
PSZK Mesterképzési és Távoktatási Központ / H-1149 Budapest, Buzogány utca 10-12. / 1426 Budapest Pf.:35 II. évfolyam Név: Neptun kód: Kurzus: Tanár neve: HÁZI DOLGOZAT 2. Gazdasági informatika alapjai
RészletesebbenProgramozás. Adatbázis-kezelés (alapok) Fodor Attila
Programozás Adatbázis-kezelés (alapok) Fodor Attila Pannon Egyetem Műszaki Informatikai Kar Villamosmérnöki és Információs Rendszerek Tanszék foa@almos.vein.hu 2010. április 22. Bevezetés Adatbáziskezelés
RészletesebbenINFORMATIKA ÁGAZATI ALKALMAZÁSAI. Az Agrármérnöki MSc szak tananyagfejlesztése TÁMOP-4.1.2-08/1/A-2009-0010
INFORMATIKA ÁGAZATI ALKALMAZÁSAI Az Agrármérnöki MSc szak tananyagfejlesztése TÁMOP-4.1.2-08/1/A-2009-0010 2. Adatbáziskezelés eszközei Adatbáziskezelés feladata Adatmodell típusai Relációs adatmodell
RészletesebbenValós idejű megoldások: Realtime ODS és Database In-Memory tapasztalatok
Valós idejű megoldások: Realtime ODS és Database In-Memory tapasztalatok Pusztai Péter IT fejlesztési senior menedzser Magyar Telekom Sef Dániel Szenior IT tanácsadó T-Systems Magyarország 2016. április
RészletesebbenRendszermodernizációs lehetőségek a HANA-val Poszeidon. Groma István PhD SDA DMS Zrt.
Rendszermodernizációs lehetőségek a HANA-val Poszeidon Groma István PhD SDA DMS Zrt. Poszeidon EKEIDR Tanúsított ügyviteli rendszer (3/2018. (II. 21.) BM rendelet). Munkafolyamat támogatás. Papírmentes
RészletesebbenCAD Rendszerek I. Sajátosság alapú tervezés - Szinkron modellezés
CAD Rendszerek I. Sajátosság alapú tervezés - Szinkron modellezés Farkas Zsolt Budapesti Műszaki és Gazdaságtudományi Egyetem, Gép- és Terméktervezés Tanszék 1/ 14 Tartalom -Sajátosság alapú tervezés:
RészletesebbenRelációs algebra 1.rész alapok
Relációs algebra 1.rész alapok Tankönyv: Ullman-Widom: Adatbázisrendszerek Alapvetés Második, átdolgozott kiadás, Panem, 2009 Lekérdezések a relációs modellben 2.4. Egy algebrai lekérdező nyelv, relációs
RészletesebbenA gyakorlat során MySQL adatbázis szerver és a böngészőben futó phpmyadmin használata javasolt. A gyakorlat során a következőket fogjuk gyakorolni:
1 Adatbázis kezelés 3. gyakorlat A gyakorlat során MySQL adatbázis szerver és a böngészőben futó phpmyadmin használata javasolt. A gyakorlat során a következőket fogjuk gyakorolni: Tábla kapcsolatok létrehozása,
RészletesebbenOracle SQL Developer Data Modeler és a DW adatmodellezés. Gollnhofer Gábor Meta Consulting Kft.
Oracle SQL Developer Data Modeler és a DW adatmodellezés Gollnhofer Gábor Meta Consulting Kft. Oracle Information Management & Big Data Reference Architecture 2 Mi a NoSQL modellezés célja? Forrás: Insights
RészletesebbenMMK-Informatikai projekt ellenőr képzés 4
Miről lesz szó Big Data definíció Mi a Hadoop Hadoop működése, elemei Köré épülő technológiák Disztribúciók, Big Data a felhőben Miért, hol és hogyan használják Big Data definíció Miért Big a Data? 2017.
RészletesebbenAdatbázis-kezelő rendszerek. dr. Siki Zoltán
Adatbázis-kezelő rendszerek I. dr. Siki Zoltán Adatbázis fogalma adatok valamely célszerűen rendezett, szisztéma szerinti tárolása Az informatika elterjedése előtt is számos adatbázis létezett pl. Vállalati
RészletesebbenAdattárház kialakítása a Szövetkezet Integrációban, UML eszközökkel. Németh Rajmund Vezető BI Szakértő március 28.
Adattárház kialakítása a Szövetkezet Integrációban, UML eszközökkel Németh Rajmund Vezető BI Szakértő 2017. március 28. Szövetkezeti Integráció Központi Bank Takarékbank Zrt. Kereskedelmi Bank FHB Nyrt.
RészletesebbenStruktúra nélküli adatszerkezetek
Struktúra nélküli adatszerkezetek Homogén adatszerkezetek (minden adatelem azonos típusú) osztályozása Struktúra nélküli (Nincs kapcsolat az adatelemek között.) Halmaz Multihalmaz Asszociatív 20:24 1 A
RészletesebbenParametrikus tervezés
2012.03.31. Statikus modell Dinamikus modell Parametrikus tervezés Módosítások a tervezés folyamán Konstrukciós variánsok (termékcsaládok) Parametrikus Modell Parametrikus tervezés Paraméterek (változók
RészletesebbenADATBÁZIS-KEZELÉS. Relációalgebra, 5NF
ADATBÁZIS-KEZELÉS Relációalgebra, 5NF ABSZTRAKT LEKÉRDEZŐ NYELVEK relációalgebra relációkalkulus rekord alapú tartomány alapú Relációalgebra a matematikai halmazelméleten alapuló lekérdező nyelv a lekérdezés
RészletesebbenDöbrönte Zoltán. Data Vault alapú adattárház - Fél óra alatt. DMS Consulting Kft.
Data Vault alapú adattárház - Fél óra alatt Döbrönte Zoltán DMS Consulting Kft. 1 Miről lesz szó Adattárház automatizálás Hol alkalmazható a leghatékonyabban Célok, funkcionalitás, előnyök Data Vault modellezés
RészletesebbenAz adatbázisrendszerek világa
Az adatbázisrendszerek világa Tankönyv: Ullman-Widom: Adatbázisrendszerek Alapvetés Második, átdolgozott kiadás, Panem, 2009 1.1. Az adatbázisrendszerek fejlődése 1.2. Az adatbázis-kezelő rendszerek áttekintése
RészletesebbenA szürke háttérrel jelölt fejezet/alfejezet szövege a CD-mellékleten található. A CD-melléklet használata. 1. Elméleti áttekintés 1
A szürke háttérrel jelölt fejezet/alfejezet szövege a CD-mellékleten található meg. A CD-melléklet használata Bevezetés xi xiii 1. Elméleti áttekintés 1 1.1. Adatmodellezés 3 1.2. Táblák, oszlopok és sorok
RészletesebbenTudásalapú információ-kereső rendszerek elemzése és kifejlesztése
Tudásalapú információ-kereső rendszerek elemzése és kifejlesztése 1 Tudásalapú információ-kereső rendszerek elemzése és kifejlesztése Természetes nyelv feldolgozás 2 Tudásalapú információ-kereső rendszerek
RészletesebbenAdatbázisok* tulajdonságai
Gazdasági folyamatok térbeli elemzése 4. előadás 2010. 10. 05. Adatbázisok* tulajdonságai Rendezett, logikailag összefüggő és meghatározott szempont szerint tárolt adatok és/vagy információk halmaza Az
RészletesebbenVizuális adatelemzés - Gyakorlat. Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék
Vizuális adatelemzés - Gyakorlat Budapesti Műszaki és Gazdaságtudományi Egyetem Méréstechnika és Információs Rendszerek Tanszék Adatelemzés szerepe a rendszermodellezésben Lényeges paraméterek meghatározása
RészletesebbenTeljeskörű BI megoldás a gyakorlatban IBM eszközök használatával, Magyarországon
Teljeskörű BI megoldás a gyakorlatban IBM eszközök használatával, Magyarországon esettanulmány csokor, mely megpróbálja összefoglalni az elmúlt 10 év tapasztalatait,tanulságait és bemutat egy élő, hazai
RészletesebbenMveletek a relációs modellben. A felhasználónak szinte állandó jelleggel szüksége van az adatbázisban eltárolt adatok egy részére.
Mveletek a relációs modellben A felhasználónak szinte állandó jelleggel szüksége van az adatbázisban eltárolt adatok egy részére. Megfogalmaz egy kérést, amelyben leírja, milyen adatokra van szüksége,
RészletesebbenA Gazdasági - Műszaki Főigazgatóság feladatai az intézményirányítás fejlesztésében
A Gazdasági - Műszaki Főigazgatóság feladatai az intézményirányítás fejlesztésében 1. Menedzsment controlling rendszer bevezetése 2. Menedzsment controlling folyamatok kockázatelemzése 3. Az AVIR-hez kapcsolódó
RészletesebbenAccess gyakorlati feladatok lépésről lépésre
Access gyakorlati feladatok lépésről lépésre 1. feladat: Hajómenetrend A balatoni hajómenetrend rendelkezésünkre áll a menetrend.txt állományban. Készítsen új adatbázist HAJO néven! A mellékelt adatállományt
RészletesebbenAdatbányászat és Perszonalizáció architektúra
Adatbányászat és Perszonalizáció architektúra Oracle9i Teljes e-üzleti intelligencia infrastruktúra Oracle9i Database Integrált üzleti intelligencia szerver Data Warehouse ETL OLAP Data Mining M e t a
RészletesebbenRelációs algebra lekérdezések optimalizációja. Adatbázisok használata
Relációs algebra lekérdezések optimalizációja Adatbázisok használata Mi a cél? Moore-törvénye: (Gordon Moore) szerint az integrált áramkörök sok jellemzőjének fejlődése exponenciális, ezek az értékek 18
RészletesebbenPentaho 4: Mindennapi BI egyszerűen. Fekszi Csaba Ügyvezető 2011. október 6.
Pentaho 4: Mindennapi BI egyszerűen Fekszi Csaba Ügyvezető 2011. október 6. 1 2 3 4 5 Bevezetés Pentaho-ról röviden - áttekintő Mindennapi BI egyszerűen a Pentaho 4 újdonságai Pentaho összefoglaló Alkalmazás
RészletesebbenKÖVETKEZŐ GENERÁCIÓS NAGYVÁLLALATI TARTALOMKEZELŐ MEGOLDÁSOK Stratis Kft. / Autonomy üzleti reggeli / 2014.10.16. Mezei Ferenc üzletág-igazgató
KÖVETKEZŐ GENERÁCIÓS NAGYVÁLLALATI TARTALOMKEZELŐ MEGOLDÁSOK Stratis Kft. / Autonomy üzleti reggeli / 2014.10.16. Mezei Ferenc üzletág-igazgató Hasonló, mégis más Ez se rossz amíg ezt ki nem próbáltad!
RészletesebbenAdatbázis-lekérdezés. Az SQL nyelv. Makány György
Adatbázis-lekérdezés Az SQL nyelv Makány György SQL (Structured Query Language=struktúrált lekérdező nyelv): relációs adatbázisok adatainak visszakeresésére, frissítésére, kezelésére szolgáló nyelv. Születési
RészletesebbenAdatszerkezetek Adatszerkezet fogalma. Az értékhalmaz struktúrája
Adatszerkezetek Összetett adattípus Meghatározói: A felvehető értékek halmaza Az értékhalmaz struktúrája Az ábrázolás módja Műveletei Adatszerkezet fogalma Direkt szorzat Minden eleme a T i halmazokból
RészletesebbenADATBÁZISOK, ADATTÁRHÁZAK
ADATBÁZISOK, ADATTÁRHÁZAK 1 Adattárolás Háttértárak Fájlok Fájlkezelő rendszer 2 Adattárolás Az adatok, információk bináris formában kerülnek tárolásra. Értelmezés kérdése, hogy egy bitsorozatnak milyen
RészletesebbenAdatbázis rendszerek 2. előadás. Relációs algebra
Adatbázis rendszerek. előadás Relációs algebra Molnár Bence Szerkesztette: Koppányi Zoltán Bevezetés Relációs algebra általában A relációs algebra néhány tulajdonsága: Matematikailag jól definiált Halmazelméletből
RészletesebbenFájlszervezés. Adatbázisok tervezése, megvalósítása és menedzselése
Fájlszervezés Adatbázisok tervezése, megvalósítása és menedzselése Célok: gyors lekérdezés, gyors adatmódosítás, minél kisebb tárolási terület. Kezdetek Nincs általánosan legjobb optimalizáció. Az egyik
RészletesebbenTSIMMIS egy lekérdezés centrikus megközelítés. TSIMMIS célok, technikák, megoldások TSIMMIS korlátai További lehetségek
TSIMMIS egy lekérdezés centrikus megközelítés TSIMMIS célok, technikák, megoldások TSIMMIS korlátai További lehetségek 1 Információk heterogén információs forrásokban érhetk el WWW Társalgás Jegyzet papírok
RészletesebbenAdatbázis rendszerek 6.. 6. 1.1. Definíciók:
Adatbázis Rendszerek Budapesti Műszaki és Gazdaságtudományi Egyetem Fotogrammetria és Térinformatika 6.1. Egyed relációs modell lényegi jellemzői 6.2. Egyed relációs ábrázolás 6.3. Az egyedtípus 6.4. A
RészletesebbenDW/BI rendszerek kialakítása bevezetői szemszögből. Gollnhofer Gábor - Meta Consulting Kft.
DW/BI rendszerek kialakítása bevezetői szemszögből Gollnhofer Gábor - Meta Consulting Kft. Bemutatkozás Meta Consulting Kft. BI, DW és CRM rendszerek tervezése és kialakítása rendszerintegráció, egyedi
RészletesebbenAnalitikus adatfeldolgozás. Adattárház Adatkocka Adatbányászat
Analitikus adatfeldolgozás Adattárház Adatkocka Adatbányászat 1 Áttekintés A hagyományos adatbázisokat sok, apró, egyszerű lekérdezésre hangolták A jelenlegi alkalmazások kevesebb, de idő igényesebb, bonyolultabb
RészletesebbenEnterprise extended Output Management. exom - Greendoc Systems Kft. 1
Enterprise extended Output Management exom - Greendoc Systems Kft. 1 exom - Greendoc Systems Kft. 2 Sokféle bementi adatformátum kezelése Adatok fogadása különböző csatornákon Előfeldolgozás: típus meghatározás,
RészletesebbenNem klaszterezett index. Klaszterezett index. Beágyazott oszlopok. Index kitöltési faktor. Indexek tulajdonságai
1 2 Nem klaszterezett indexek Egy táblán csak egy klaszterezett index lehet Ha más oszlop szerint is keresni akarunk, nem klaszterezett indexeket használunk A tábla mellett megjelenő adatstruktúra Egy
RészletesebbenAdatbáziskezelő-szerver. Relációs adatbázis-kezelők SQL. Házi feladat. Relációs adatszerkezet
1 2 Adatbáziskezelő-szerver Általában dedikált szerver Optimalizált háttértár konfiguráció Csak OS + adatbázis-kezelő szoftver Teljes memória az adatbázisoké Fő funkciók: Adatok rendezett tárolása a háttértárolón
RészletesebbenAdatbázismodellek. 1. ábra Hierarchikus modell
Eddig az adatbázisokkal általános szempontból foglalkoztunk: mire valók, milyen elemekből épülnek fel. Ennek során tisztáztuk, hogy létezik az adatbázis fogalmi modellje (adatbázisterv), amely az egyedek,
RészletesebbenData Vault adatmodellezés.
Data Vault adatmodellezés Nemeth.Zoltan@iqpp.hu Új adattárház adatmodellezési módszer Dan Linstedt nevéhez fűződik Ismérvei Részletes, tételes adatok Történetiség kezelése Data Vault Üzleti területek köré
RészletesebbenÜgyfél- és címadatok feldolgozása Talenddel
Ügyfél- és címadatok feldolgozása Talenddel 2012.október 4. Dr. Miskolczi Mátyás, Kiss György A Stratisról röviden Jellemzők - Alapítva: 1998 - Tisztán magyar tulajdon - 50 tanácsadó - 140 ügyfél - 500+
RészletesebbenETL keretrendszer tervezése és implementálása. Gollnhofer Gábor Meta4Consulting Europe Kft.
ETL keretrendszer tervezése és implementálása Gollnhofer Gábor Meta4Consulting Europe Kft. Tartalom Bevezetés ETL keretrendszer: elvárások és hogyan készítsük A mi keretrendszerünk Bevezetési tanulságok
RészletesebbenAdattárházak. Méréstechnika és Információs Rendszerek Tanszék
Adattárházak Méréstechnika és Információs Rendszerek Tanszék https://www.mit.bme.hu/oktatas/targyak/vimiac04 1 Adatfeldolgozási folyamat Döntés Modell Adatbányászat Adatok kinyerése, transzformálása Adattárház
RészletesebbenMagas szintű adatmodellek Egyed/kapcsolat modell I.
Magas szintű adatmodellek Egyed/kapcsolat modell I. Ullman-Widom: Adatbázisrendszerek. Alapvetés. 4.fejezet Magas szintű adatmodellek (4.1-4.3.fej.) (köv.héten folyt.köv. 4.4-4.6.fej.) Az adatbázis modellezés
RészletesebbenMiskolci Egyetem Általános Informatikai Tanszék
Software tesztelés Miskolci Egyetem Általános Informatikai Tanszék Software tesztelés SWTESZT / 1 A tesztelés feladata Két alapvető cél rendszerben található hibák felderítése annak ellenőrzése, hogy a
RészletesebbenA tesztelés feladata. Verifikáció
Software tesztelés Miskolci Egyetem Általános Informatikai Tanszék Software tesztelés SWTESZT / 1 A tesztelés feladata Két alapvető cél rendszerben található hibák felderítése annak ellenőrzése, hogy a
RészletesebbenVvAaLlÓóSs IiıDdEeJjȷŰű OoDdSs goldengate alapokon a magyar telekomban
VvAaLlÓóSs IiıDdEeJjȷŰű OoDdSs goldengate alapokon a magyar telekomban Pusztai Péter IT fejlesztési senior menedzser Magyar Telekom Medveczki György szenior IT architekt T-Systems Magyarország 2014. március
RészletesebbenAdatbáziskezelı-szerver SQL. Relációs adatbázis-kezelık. Relációs adatszerkezet. Házi feladat 2012.03.05.
1 2 Adatbáziskezelı-szerver Általában dedikált szerver Optimalizált háttértár konfiguráció Csak OS + adatbázis-kezelő szoftver Teljes memória az adatbázisoké Fő funkciók: Adatok rendezett tárolása a háttértárolón
RészletesebbenSzámítógépes döntéstámogatás. Döntések fuzzy környezetben Közelítő következtetések
BLSZM-09 p. 1/17 Számítógépes döntéstámogatás Döntések fuzzy környezetben Közelítő következtetések Werner Ágnes Villamosmérnöki és Információs Rendszerek Tanszék e-mail: werner.agnes@virt.uni-pannon.hu
RészletesebbenALAPOK. 0 és 255 közé eső számértékek tárolására. Számértékek, például távolságok, pontszámok, darabszámok.
ADATBÁZIS-KEZELÉS ALAPOK Főbb Adattípusok: Igen/Nem Bájt Ez az adattípus logikai adatok tárolására alkalmas. A logikai adatok mindössze két értéket vehetnek fel. (Igen/Nem, Igaz/Hamis, Férfi/Nő, Fej/Írás
RészletesebbenIV/1. sz. melléklet: Vállalati CRM, értékesítési terület funkcionális specifikáció
IV/1. sz. melléklet: Vállalati CRM, értékesítési terület funkcionális specifikáció 1. A követelménylista céljáról Jelen követelménylista (mint a GOP 2.2.1 / KMOP 1.2.5 pályázati útmutató melléklete) meghatározza
RészletesebbenAdatbázis rendszerek 7. Matematikai rendszer amely foglal magában:
Adatbázis Rendszerek Budapesti Műszaki és Gazdaságtudományi Egyetem Fotogrammetria és Térinformatika Tanszék 2011 Dr. Alhusain Othman oalhusain@gmail.com 7.1. Bevezetés 7.2. Klasszikus- és relációs- algebra
RészletesebbenAz indexelés újdonságai Oracle Database 12c R1 és 12c R2
Az indexelés újdonságai Oracle Database 12c R1 és 12c R2 Szabó Rozalinda Oracle adattárház szakértő, oktató szabo.rozalinda@gmail.com Index tömörítés fejlődése 8.1.3-as verziótól: Basic (Prefixes) index
Részletesebben