DWH (Data Ware House) vagy EDW (Enterprice Data Warehouse) értelmezésba az adatárház ill. vállalti adattárházzal foglakozunk.
Bill Inmon:
Csillagsémás (Kimball) vagy normalizált (Inmon) adattárházat építsünk?
Az adatpiac az adattárház része amely tipikusan egy üzleti folyamat, vagy egy szervezeti egység támogatására készül.
(Köznapi értelemben egy olyan adattárház amely egy szervezeti egység igényeinek kielégítésére készül)
Szerkezetét tekintve csillagsémás
Mi az OLAP: A megosztott többdimenziós(Fast Analysis of Shared Multidimensional Information (FASMI, Nigel Pendse)
- Mi az adatbányászat: Az adatbányászat a nagymennyiségű adatokban rejlő információk fél-automatikus feltárása mesterséges intelligencia algoritmusok alkalmazásával (például neurális hálók, szabálygenerálók, asszociációs modellek)
Az „üzleti intelligencia célja végső soron az, hogy akik a döntéseket hozzák (legyenek azok bármilyen döntések), minél relevánsabb, minél magasabb feldolgozottsági szinten álló, minél aktuálisabb, minél könnyebben emészthető és felhasználható információkat kapjanak.
A jobb információ jobb döntést eredményez, a jobb döntés nagyobb hasznot hoz.”
DWH építés feladatok:
- Kezdeti Scope kijelölése.
- Mérhető célok meghatározása
- Kockázat elemzés (Készen áll a bevezetésre)
- Beruházás gazdaságossági vizsgálatok elkészítése
- Koncepcióterv és megvalósíthatósági tanulmány
- Projekt megtervezése: Ki mit fog csinálni (staffing), ki kinek mikor számol be, …
Mi a projekt terjedelme? (Scope)
- Mi az a Scope? Kerítés az igényeink körül. Terület, amin belül az ajánlatadók focizhatnak. Nekünk kell kijelölni
Adatprofilozási , adatminőségi észrevételek, interfész specifikációk (hogyan, mikor fogjuk elérni a forrásrendszereket, hogyan válogatjuk le őket, …), adatfolyam diagram (mi honnan jön, hova megy (stage, pre stage, business meta), adatmennyiség becslések.
Az újonnan keletkező DWH / DM táblákat adatkörhöz kell rendelni. Adatkörnek egy üzleti szempontból összetartozó táblahalmazt nevezünk
Integráció az adattárházban létrejövő tárgyterületekhez kapcsolódó adatokat az érintett adatforrásokból szabványosított, egységes formára alakítva egy helyre gyűjti és egységbe rendezve kezeli.
DWH fő kiszolgáló lépései:
• Adatkinyerés a tranzakciós (vagy más vállalat-működtetési) forrásrendszerekből
• 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.
DWH modell építés szintjei:
• 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.
Hiereachia:
Téma -> modul -> csomag -> objektum ( saját process flow package, táblák, mapping-ek, stb )
Mapping-eket csak blokk-szinten lehet létrehozni. Modul-szinten csak blokkokat hivatkozhatunk.
A modul több további blokkjának alapul szolgáló tábla PREP-töltése, - érintett táblák (load, stage, dwhd, prep...),
A nézetek használata nem javasolt, az üzleti logikát a mapping-ekbe kell rakni.
A fentiek alapján látható, mennyire hasznos a névkonvenció: bizonyos tapasztalattal minden objektumról lehet tudni hogy hova tartozik, mi a szerepe.
A kollekciókba nem kell betenni az adatpiaci táblákat, csak a historizálás előtét-tábláit, mivel az adatpiaci táblával az üzleti blokk nem foglalkozik (csak a generált historizáló).
Sok adat transzformáció leírható SQL kifejezésekkel, a CTAS utasítás használatával a transzformált adatokat hatékonyan egy új táblába írhatjuk.
Meglevő táblák esetén a INSERT /*+APPEND*/ ... AS SELECT utasítás alkalmazható.
Adattárház környezetben a CTAS utasítás tipikusan párhuzamosan, NOLOGGING módban fut.
• DW_DEV Fejlesztői környezet
• DW_TEST Teszt környezet
• DW_PROD Éles környezet
Az OWB és az ODI is egy grafikus ETL-eszköz, vagyis elsődleges rendeltetése az, hogy az adattárházas műveleteket (Extraction, Transformation, Load) vizuálisan megjeleníthető módon, könnyen definiálni lehessen.
Az OWB / ODI adatbázisa egy úgynevezett tervadattár (repository),
ODS (operational data store) :
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.
ETL (Extract, transform, load || kinyerés, átalakítás, betöltés):
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)
Ezek az objektumok a repository-ban csak tervként, metaadatként léteznek. Innen telepíthetőek a fizikai adatbázisba (deploy-művelet).
Fontos ezért, hogy kialakításuk jól átgondoltan, esetleg megfelelő formalizmusok használatával történjen.
A metaadat egy átfogó jelző olyan fogalomrendszerre é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.
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.
• Explore: az adatok természetének vizsgálata, a bennük rejlő összefüggések, trendek, ellentmondások, hiányosságok meghatározása.
• Modify: a modellezés számára szükséges változók készítése, kiválasztása, átalakítása.
• Model: olyan modellek készítése, amelyek a mintaadatokban rejlő összefüggések alapján a lehető legjobb előrejelzéseket tudják adni.
• Assess: a különböző modellek kiértékelése, összehasonlítása.
• Adatok megismerése
• Adatelőkészítés
• Modellezés
• Kiértékelés
• Bevezetés
2. Céladatbázis létrehozása: kiválasztani a használandó adatbázist vagy annak egy részét, amiből a tudást ki akarjuk nyerni.
3. Adattisztítás és előfeldolgozás: itt olyan alapvető operációkat értünk, mint a téves bejegyzések eltávolítása, hiányos mezők pótlása, zajok szűrése stb.
4. Adatintegráció: a feldolgozás számára fontos, esetleg elosztott adatbázisok egyesítése.
5. Adattér csökkentés: az adatbázisból a cél szempontjából fontos attribútumok kiemelése.
6. Adatbányászati algoritmus típusának kiválasztása: eldönteni, hogy a megoldandó feladat klaszterezés, szabály-, illetve mintakeresés, esetleg osztályozás-e.
7. A megfelelő adatbányászati algoritmus meghatározása: előnyeinek, hátrányainak, paramétereinek vizsgálata, futási idő- és memóriaigény elemzése.
8. Az algoritmus alkalmazása.
9. A kinyert információ értelmezése, esetleg visszatérés az előző lépésekhez a további finomítások céljából.
10. A megszerzett tudás megerősítése: összevetése az elvárásokkal, előzetes ismeretekkel. Eredmények dokumentálása és átadása a felhasználónak.
Az OWB/ODI-ben az adatok mozgatását mapping-ekkel, vagyis leképezésekkel lehet leírni. Egy mapping egy adatfolyamot ír le.
A mapping-ben az adatok mozgását nyilakkal definiálhatjuk, az átalakító lépéseket ún. operátorokkal. Két tábla kulcsmezőkkel való összekapcsolásának pl. egy join-operátor felel meg.
A feldolgozások vezérlése, process flow-k
Egy csomópont egy adott adatmozgató lépésnek (pl. mapping-nek) felel meg, amit már a process flow elkészítése előtt definiálni kell. Ezután lehet bekötni (bind) a process flow-ba.
A process flow-k irányított gráfok. Azt írják le, hogy az egyes adatfeldolgozási lépések milyen módon, ill. milyen feltételek mentén követhetik egymást.
- ROI : (Return on Investment), a befektetés megtérülésének mutatója.
A ROI a jövedelmezőségi mutatók egyik típusa, amely megmutatja a befektetések hatékonyságát.
A mutató nagy népszerűségnek örvend, mert egyszerű kiszámítani, és egyértelműen megmutatja, hogy érdemes-e befektetni az adott lehetőségbe.
A ROI számítása
ROI = (befektetés bevétele - befektetés költségei) / befektetés költségei
Amennyiben a ROI értéke negatív, vagy létezik egy másik befektetési lehetőség, amely ROI-ja magasabb, akkor adott beruházásba nem ajánlott befektetni.
(http://ecopedia.hu)
A blokk process flow-inak a független kezelhetőség okán nem szabad a blokkon kívülre hivatkozniuk (a standard historizálásra sem, ami szintén az üzleti blokkon kívülről hívódik).
A kétdimenziós táblákban (ezeket hívjuk relációknak).
A relációk sorokból és oszlopokból állnak, ahol az oszlopokat attribútumoknak nevezzük.
A relációk közös attribútumok segítségével összekapcsolhatók.
A reláció nevét és a reláció-attribútumok halmazát együtt relációsémának nevezzük.
A relációs modellben a terv egy vagy több relációsémát tartalmaz.
Ezen relációsémák halmazát nevezzük relációs adatbázis-sémának.
Táblajellemzők
Partícionált táblák – Jellemzően Stage, ODS, DM rétegekben
o LIST
o RANGE
o HASH (jellemzően nem használt)
· Snapshot táblák – jellemzően DW rétegben
o Állandó sorok kulcs szerint
o Kieső sorok kulcs szerint
· DELETE és DELETE WHERE táblák
· Source_system, source_tch
· INSERT /*+ APPEND */
· TRUNCATE,DELETE
· UPDATE kerülendő
· Asszociatív memóriatömbök használata.
· Result cache
· BULK COLLECT
· FORALL UPDATE (Példa)
· A programok legyenek újrafuttathatóak
o előkészít maga előtt
o takarít maga után
· Készítsünk csomagot a közösen használt azonos funkciókra
o egyszer kell jól és hibátlanul megírni
o start_map – töltés előtt mindig futó programrész
o end_map – töltés után mindig futó programrész
o Authid Current_User – egy sémában van csak, de úgy fut, mintha ott lenne
Logolás
· pragma autonom_transaction
· log sequence
· OS USER
o V_USER := SYS_CONTEXT('USERENV', 'OS_USER');
· session_id
o V_SESSION_ID := SYS_CONTEXT('USERENV', 'SESSIONID');
Közösen használt
· Minden program esetében (~95 %) azonos teendőnk van a töltés kezdetekor és elvégzését követően
· Töltés előtt
o logbejegyzés a folyamat indulásáról
o ALTER SESSION SET REMOTE_DEPENDENCIES_MODE = SIGNATURE
o dbms_session.set_nls('NLS_SORT', 'BINARY');
o dbms_session.set_nls('NLS_COMP', 'BINARY');
o Output táblák ürítése, ill. előkészítése az adatbetöltésre
· Töltés után
o ANALYZE
o archiválás
o logbejegyzés a folyamat végeztéről
· Hiba esetén – exception
o logolás, SQLERRM, stb.
Analyze Partícionált tábla esetében
dbms_stats.gather_table_stats(ownname => l_owner
,tabname => t_table(x)
,partname => l_partname
,granularity => 'PARTITION'
,estimate_percent => l_analize_percent
,degree => 6
,cascade => True
,no_invalidate => True);
Teljes tábla esetében
dbms_stats.gather_table_stats(ownname => l_owner
,tabname => l_table_name
,estimate_percent => l_analize_percent -- 30
,degree => 6
,cascade => True
,no_invalidate => True);
Töltések hasonlósága
· Az adattárház folyamatok ~50 %-a azonos algoritmus mentén működik
· GNRC_... programok készítése (Synonyms használata) – Példa
· Programgenerátorok használata
o Pl.: Változáskövetéses táblák töltése esetében
EXECUTE IMMEDIATE / EXECUTE_CLOB_SCRIPT
Oracle Katalógus táblák és saját vezérlő-paramétertáblák
OLOCAL és GLOBAL index
OTöltés után a GLOBAL INDEX invaliddá válik
OREBUILD INDEX használata javasolt
ÉALTER INDEX <INDEX> REBUILD PARTITION <PART>;
ÉÖsszes használhatatlan indexre (GLOBAL):
For i In (Select index_name
From user_indexes
Where table_name = p_table_name
And status = 'UNUSABLE')
Loop
Execute Immediate 'alter index ' || i.index_name || ' rebuild';
End Loop;
Bill Inmon:
Az adattárház egy témaorientált, integrált, historikus és nem változó adatgyűjtemény a menedzsment döntéseinek támogatására.
Az adattárház csak egy része a vállalat teljes üzleti intelligencia rendszerének.
A vállalatnak egy adattárháza van és az adatpiacok ebből táplálkoznak.
Az adattárház adatmodellje normalizált.
A tranzakciókat adatkörökre osztja (pl.: vevő adatok)
Ralph Kimball:
A vállalatnak egy adattárháza van és az adatpiacok ebből táplálkoznak.
Az adattárház adatmodellje normalizált.
A tranzakciókat adatkörökre osztja (pl.: vevő adatok)
Ralph Kimball:
Az adattárház a szervezet adatainak elemzésére, gyors lekérdezhetőségére és könnyű használatra strukturált halmaza
Az adattárház az adatpiacok összessége. Az adattárház adatmodellje csillagsémás.
A tranzakciókat „tény”-re és dimenziókra osztja
Csillagsémás (Kimball) vagy normalizált (Inmon) adattárházat építsünk?
Az adatpiac az adattárház része amely tipikusan egy üzleti folyamat, vagy egy szervezeti egység támogatására készül.
(Köznapi értelemben egy olyan adattárház amely egy szervezeti egység igényeinek kielégítésére készül)
Szerkezetét tekintve csillagsémás
Mi az OLAP: A megosztott többdimenziós(Fast Analysis of Shared Multidimensional Information (FASMI, Nigel Pendse)
- Mi az adatbányászat: Az adatbányászat a nagymennyiségű adatokban rejlő információk fél-automatikus feltárása mesterséges intelligencia algoritmusok alkalmazásával (például neurális hálók, szabálygenerálók, asszociációs modellek)
Az „üzleti intelligencia célja végső soron az, hogy akik a döntéseket hozzák (legyenek azok bármilyen döntések), minél relevánsabb, minél magasabb feldolgozottsági szinten álló, minél aktuálisabb, minél könnyebben emészthető és felhasználható információkat kapjanak.
A jobb információ jobb döntést eredményez, a jobb döntés nagyobb hasznot hoz.”
DWH építés feladatok:
- Kezdeti Scope kijelölése.
- Mérhető célok meghatározása
- Kockázat elemzés (Készen áll a bevezetésre)
- Beruházás gazdaságossági vizsgálatok elkészítése
- Koncepcióterv és megvalósíthatósági tanulmány
- Projekt megtervezése: Ki mit fog csinálni (staffing), ki kinek mikor számol be, …
Mi a projekt terjedelme? (Scope)
- Mi az a Scope? Kerítés az igényeink körül. Terület, amin belül az ajánlatadók focizhatnak. Nekünk kell kijelölni
Adatprofilozási , adatminőségi észrevételek, interfész specifikációk (hogyan, mikor fogjuk elérni a forrásrendszereket, hogyan válogatjuk le őket, …), adatfolyam diagram (mi honnan jön, hova megy (stage, pre stage, business meta), adatmennyiség becslések.
Az újonnan keletkező DWH / DM táblákat adatkörhöz kell rendelni. Adatkörnek egy üzleti szempontból összetartozó táblahalmazt nevezünk
Integráció az adattárházban létrejövő tárgyterületekhez kapcsolódó adatokat az érintett adatforrásokból szabványosított, egységes formára alakítva egy helyre gyűjti és egységbe rendezve kezeli.
DWH fő kiszolgáló lépései:
• Adatkinyerés a tranzakciós (vagy más vállalat-működtetési) forrásrendszerekből
• 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.
DWH modell építés szintjei:
• 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.
Hiereachia:
Téma -> modul -> csomag -> objektum ( saját process flow package, táblák, mapping-ek, stb )
Mapping-eket csak blokk-szinten lehet létrehozni. Modul-szinten csak blokkokat hivatkozhatunk.
A modul több további blokkjának alapul szolgáló tábla PREP-töltése, - érintett táblák (load, stage, dwhd, prep...),
A nézetek használata nem javasolt, az üzleti logikát a mapping-ekbe kell rakni.
A fentiek alapján látható, mennyire hasznos a névkonvenció: bizonyos tapasztalattal minden objektumról lehet tudni hogy hova tartozik, mi a szerepe.
A kollekciókba nem kell betenni az adatpiaci táblákat, csak a historizálás előtét-tábláit, mivel az adatpiaci táblával az üzleti blokk nem foglalkozik (csak a generált historizáló).
Oracle (ETL) transzformálás SQL használatával:
A CREATE TABLE ... AS SELECT utasítás (CTAS) hatékony eszköz nagy mennyiségű adat transzformálására.Sok adat transzformáció leírható SQL kifejezésekkel, a CTAS utasítás használatával a transzformált adatokat hatékonyan egy új táblába írhatjuk.
Meglevő táblák esetén a INSERT /*+APPEND*/ ... AS SELECT utasítás alkalmazható.
Adattárház környezetben a CTAS utasítás tipikusan párhuzamosan, NOLOGGING módban fut.
• DW_DEV Fejlesztői környezet
• DW_TEST Teszt környezet
• DW_PROD Éles környezet
Az OWB és az ODI is egy grafikus ETL-eszköz, vagyis elsődleges rendeltetése az, hogy az adattárházas műveleteket (Extraction, Transformation, Load) vizuálisan megjeleníthető módon, könnyen definiálni lehessen.
Az OWB / ODI adatbázisa egy úgynevezett tervadattár (repository),
ODS (operational data store) :
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.
ETL (Extract, transform, load || kinyerés, átalakítás, betöltés):
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)
Ezek az objektumok a repository-ban csak tervként, metaadatként léteznek. Innen telepíthetőek a fizikai adatbázisba (deploy-művelet).
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.
A metaadat egy átfogó jelző olyan fogalomrendszerre é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.
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.
Módszertanok
SAS rendszerben a SEMMA módszertan lépései:
• Sample: mintavételezés, azaz egy vagy több kisebb tábla létrehozása megfigyelési, tanulási célra.• Explore: az adatok természetének vizsgálata, a bennük rejlő összefüggések, trendek, ellentmondások, hiányosságok meghatározása.
• Modify: a modellezés számára szükséges változók készítése, kiválasztása, átalakítása.
• Model: olyan modellek készítése, amelyek a mintaadatokban rejlő összefüggések alapján a lehető legjobb előrejelzéseket tudják adni.
• Assess: a különböző modellek kiértékelése, összehasonlítása.
A CRISP-DM (CRoss Industry Standard Process for Data Mining) módszertan lépései:
• Üzleti probléma megértése• Adatok megismerése
• Adatelőkészítés
• Modellezés
• Kiértékelés
• Bevezetés
10 fázisú, az előzőeknél általánosabb módszertan [Bodon]
1. Az alkalmazási terület feltárása és megértése, fontosabb előzetes ismeretek begyűjtése, és a felhasználási célok meghatározása.2. Céladatbázis létrehozása: kiválasztani a használandó adatbázist vagy annak egy részét, amiből a tudást ki akarjuk nyerni.
3. Adattisztítás és előfeldolgozás: itt olyan alapvető operációkat értünk, mint a téves bejegyzések eltávolítása, hiányos mezők pótlása, zajok szűrése stb.
4. Adatintegráció: a feldolgozás számára fontos, esetleg elosztott adatbázisok egyesítése.
5. Adattér csökkentés: az adatbázisból a cél szempontjából fontos attribútumok kiemelése.
6. Adatbányászati algoritmus típusának kiválasztása: eldönteni, hogy a megoldandó feladat klaszterezés, szabály-, illetve mintakeresés, esetleg osztályozás-e.
7. A megfelelő adatbányászati algoritmus meghatározása: előnyeinek, hátrányainak, paramétereinek vizsgálata, futási idő- és memóriaigény elemzése.
8. Az algoritmus alkalmazása.
9. A kinyert információ értelmezése, esetleg visszatérés az előző lépésekhez a további finomítások céljából.
10. A megszerzett tudás megerősítése: összevetése az elvárásokkal, előzetes ismeretekkel. Eredmények dokumentálása és átadása a felhasználónak.
Az OWB/ODI-ben az adatok mozgatását mapping-ekkel, vagyis leképezésekkel lehet leírni. Egy mapping egy adatfolyamot ír le.
A mapping-ben az adatok mozgását nyilakkal definiálhatjuk, az átalakító lépéseket ún. operátorokkal. Két tábla kulcsmezőkkel való összekapcsolásának pl. egy join-operátor felel meg.
A feldolgozások vezérlése, process flow-k
Egy csomópont egy adott adatmozgató lépésnek (pl. mapping-nek) felel meg, amit már a process flow elkészítése előtt definiálni kell. Ezután lehet bekötni (bind) a process flow-ba.
A process flow-k irányított gráfok. Azt írják le, hogy az egyes adatfeldolgozási lépések milyen módon, ill. milyen feltételek mentén követhetik egymást.
- ROI : (Return on Investment), a befektetés megtérülésének mutatója.
A ROI a jövedelmezőségi mutatók egyik típusa, amely megmutatja a befektetések hatékonyságát.
A mutató nagy népszerűségnek örvend, mert egyszerű kiszámítani, és egyértelműen megmutatja, hogy érdemes-e befektetni az adott lehetőségbe.
A ROI számítása
ROI = (befektetés bevétele - befektetés költségei) / befektetés költségei
Amennyiben a ROI értéke negatív, vagy létezik egy másik befektetési lehetőség, amely ROI-ja magasabb, akkor adott beruházásba nem ajánlott befektetni.
(http://ecopedia.hu)
A blokk process flow-inak a független kezelhetőség okán nem szabad a blokkon kívülre hivatkozniuk (a standard historizálásra sem, ami szintén az üzleti blokkon kívülről hívódik).
A kétdimenziós táblákban (ezeket hívjuk relációknak).
A relációk sorokból és oszlopokból állnak, ahol az oszlopokat attribútumoknak nevezzük.
A relációk közös attribútumok segítségével összekapcsolhatók.
A reláció nevét és a reláció-attribútumok halmazát együtt relációsémának nevezzük.
A relációs modellben a terv egy vagy több relációsémát tartalmaz.
Ezen relációsémák halmazát nevezzük relációs adatbázis-sémának.
Táblajellemzők
Partícionált táblák – Jellemzően Stage, ODS, DM rétegekben
o LIST
o RANGE
o HASH (jellemzően nem használt)
· Snapshot táblák – jellemzően DW rétegben
o Állandó sorok kulcs szerint
o Kieső sorok kulcs szerint
· DELETE és DELETE WHERE táblák
· Source_system, source_tch
Adatfolyamról általában
· Nagy tömegű és számoságú táblák és eljárások indokolják az folyamatütemező használatát (Pl. PWM)Performancia praktikák
· XCHANGE, DROP, CREATE PARTITION· INSERT /*+ APPEND */
· TRUNCATE,DELETE
· UPDATE kerülendő
· Asszociatív memóriatömbök használata.
· Result cache
· BULK COLLECT
· FORALL UPDATE (Példa)
Programozás praktikák
· Logolás· A programok legyenek újrafuttathatóak
o előkészít maga előtt
o takarít maga után
· Készítsünk csomagot a közösen használt azonos funkciókra
o egyszer kell jól és hibátlanul megírni
o start_map – töltés előtt mindig futó programrész
o end_map – töltés után mindig futó programrész
o Authid Current_User – egy sémában van csak, de úgy fut, mintha ott lenne
Logolás
· pragma autonom_transaction
· log sequence
· OS USER
o V_USER := SYS_CONTEXT('USERENV', 'OS_USER');
· session_id
o V_SESSION_ID := SYS_CONTEXT('USERENV', 'SESSIONID');
Közösen használt
· Minden program esetében (~95 %) azonos teendőnk van a töltés kezdetekor és elvégzését követően
· Töltés előtt
o logbejegyzés a folyamat indulásáról
o ALTER SESSION SET REMOTE_DEPENDENCIES_MODE = SIGNATURE
o dbms_session.set_nls('NLS_SORT', 'BINARY');
o dbms_session.set_nls('NLS_COMP', 'BINARY');
o Output táblák ürítése, ill. előkészítése az adatbetöltésre
· Töltés után
o ANALYZE
o archiválás
o logbejegyzés a folyamat végeztéről
· Hiba esetén – exception
o logolás, SQLERRM, stb.
Analyze Partícionált tábla esetében
dbms_stats.gather_table_stats(ownname => l_owner
,tabname => t_table(x)
,partname => l_partname
,granularity => 'PARTITION'
,estimate_percent => l_analize_percent
,degree => 6
,cascade => True
,no_invalidate => True);
Teljes tábla esetében
dbms_stats.gather_table_stats(ownname => l_owner
,tabname => l_table_name
,estimate_percent => l_analize_percent -- 30
,degree => 6
,cascade => True
,no_invalidate => True);
Töltések hasonlósága
· Az adattárház folyamatok ~50 %-a azonos algoritmus mentén működik
· GNRC_... programok készítése (Synonyms használata) – Példa
· Programgenerátorok használata
o Pl.: Változáskövetéses táblák töltése esetében
Az optimális teljesítmény eléréséhez fogadjuk meg a következő javaslatokat:
- a ténytáblák minden idegen kulcs mezőjére építsünk egy-egy bitmap indexet;
- a STAR_TRANSFORMATION_ENABLED inicializálási paraméter értékét állítsuk TRUE-ra!
A fenti feltételeket teljesítő adattárházakban a legtöbb csillaglekérdezés ún. csillagtranszformációt alkalmaz végrehajtáskor, ami nagyon hatékony.
A csillagtranszformáció egy olyan optimalizációs technika, melyben a csillaglekérdezés SQL-jét az Oracle-adatbázis implicit átalakítja a hatékony végrehajtás érdekében.
Az optimalizáló automatikusan alkalmazza a csillag-transzformációt, amikor alkalmas, a felhasználónak nem is kell feltétlen tudni róla.
Az Oracle-csillagtranszformáció választásakor a lekérdezést két lépésben hajtja végre.
Az első lépésben a ténytábla a szűréseknek megfelelő sorait határozza meg. Bitmap indexeket használva ezt hatékonyan meg tudja tenni.
A második lépésben a ténytábla kiválasztott sorait a dimenziótáblákhoz kapcsolja. A csillag-transzformáció feltétele, hogy a ténytábla valamennyi joinban szereplő oszlopára legyen csak ezt az egy mezőt tartalmazó bitmap index.
Az optimalizáló automatikusan alkalmazza a csillag-transzformációt, amikor alkalmas, a felhasználónak nem is kell feltétlen tudni róla.
Az Oracle-csillagtranszformáció választásakor a lekérdezést két lépésben hajtja végre.
Az első lépésben a ténytábla a szűréseknek megfelelő sorait határozza meg. Bitmap indexeket használva ezt hatékonyan meg tudja tenni.
A második lépésben a ténytábla kiválasztott sorait a dimenziótáblákhoz kapcsolja. A csillag-transzformáció feltétele, hogy a ténytábla valamennyi joinban szereplő oszlopára legyen csak ezt az egy mezőt tartalmazó bitmap index.
Az Oracle optimalizáló a következőképp dönti el, hogy alkalmazza-e a csillag-transzformációt, ha annak feltételei különben adottak: elkészít egy optimális tervet az eredeti, majd egy másikat a transzformált SQL-re. Az alacsonyabb becsült költségű tervet alkalmazza végül.
Ha a lekérdezés a ténytábla sorainak nagy részét érinti, előfordul, hogy a csillag-transzformáció és a bitmap indexek használata helyett a tábla teljes végigolvasása a hatékonyabb.
Ha a lekérdezés a ténytábla sorainak nagy részét érinti, előfordul, hogy a csillag-transzformáció és a bitmap indexek használata helyett a tábla teljes végigolvasása a hatékonyabb.
EXECUTE IMMEDIATE / EXECUTE_CLOB_SCRIPT
Oracle Katalógus táblák és saját vezérlő-paramétertáblák
OLOCAL és GLOBAL index
OTöltés után a GLOBAL INDEX invaliddá válik
OREBUILD INDEX használata javasolt
ÉALTER INDEX <INDEX> REBUILD PARTITION <PART>;
ÉÖsszes használhatatlan indexre (GLOBAL):
For i In (Select index_name
From user_indexes
Where table_name = p_table_name
And status = 'UNUSABLE')
Loop
Execute Immediate 'alter index ' || i.index_name || ' rebuild';
End Loop;
A particionálás nemcsak új adatok hozzáadásakor hasznos, hanem adatok kimozgatásánál és archiválásánál is. Sok adattárház esetén gördülő ablak van az adatokra. Ezzel a módszerrel egy régi partíciót a többitől függetlenül és gyorsan elvehetünk a táblából.
Egy partíció kimozgatása a táblából nem feltétlenül jelenti az adatok fizikai törlését az adatbázisból. Két lehetőség van a régi adatok kimozgatására egy particionált táblából.
- Az egyik módszer az adatok fizikai törlése a partíció eldobásával, így a lefoglalt terület is felszabadul.
- A másik módszer szerint a régi partíciót kicserélhetjük egy ugyanolyan struktúrájú üres táblával.
Megjegyzések
Megjegyzés küldése