Alapfogalmak
A Business Intelligence – üzleti intelligencia (BI) célja az üzleti döntéshozást
megkönnyítendő adathalmazok feldolgozása, ezekből kimutatások, statisztikák
létrehozása, gyakorlatilag a szervezet összes szintjén az üzleti döntéshozás valós
időben való megkönnyítése.
megkönnyítendő adathalmazok feldolgozása, ezekből kimutatások, statisztikák
létrehozása, gyakorlatilag a szervezet összes szintjén az üzleti döntéshozás valós
időben való megkönnyítése.
Adattárház deffiniciói
– I.
“A data warehouse is a subject oriented, integrated, nonvolatile, and time variant collection of data
in support of management’s decisions.”
—
“Az adattárház olyan témaspecifikus, integrált, időfüggő, fizikailag is tárolt adatgyűjtemény,
amely a menedzsment döntéshozó folyamataihoz szükséges lehet.”
(W. H. Inmon)
=>
Modellje szerint azonnal adattárházat tervezünk, mely azonnal szolgáltatásokat fog
nyújtani az vállalat egésze számára.
—
Adattárház: A vállalt üzleti folyamatiban integrált, a teljes infrastruktúrát
lefedő rendszer. Általában nem felejtő, historikusan tárolt adatokból
dolgozik.
“A data warehouse is a subject oriented, integrated, nonvolatile, and time variant collection of data
in support of management’s decisions.”
—
“Az adattárház olyan témaspecifikus, integrált, időfüggő, fizikailag is tárolt adatgyűjtemény,
amely a menedzsment döntéshozó folyamataihoz szükséges lehet.”
(W. H. Inmon)
=>
Modellje szerint azonnal adattárházat tervezünk, mely azonnal szolgáltatásokat fog
nyújtani az vállalat egésze számára.
—
Adattárház: A vállalt üzleti folyamatiban integrált, a teljes infrastruktúrát
lefedő rendszer. Általában nem felejtő, historikusan tárolt adatokból
dolgozik.
-II.
Data Warehouse: “The conglomeration of an organization’s
data warehouse staging and presentation areas, where operational data is
specifically structured for query and analysis performance and ease-of-use.”
=>
Az adattárház fogalma itt egy adott szervezet azon adatgyűjtő és
szolgáltató részeit foglalja magában, ahol a működési adatokat újrastrukturálják
riportkészítési, jó teljesítményű és egyszerűen kezelhető elemzésekhez.
— (Ralph Kimbal)
Data Warehouse: “The conglomeration of an organization’s
data warehouse staging and presentation areas, where operational data is
specifically structured for query and analysis performance and ease-of-use.”
=>
Az adattárház fogalma itt egy adott szervezet azon adatgyűjtő és
szolgáltató részeit foglalja magában, ahol a működési adatokat újrastrukturálják
riportkészítési, jó teljesítményű és egyszerűen kezelhető elemzésekhez.
— (Ralph Kimbal)
Kimball féle tervezési elvek az adattárház bevezetés első lépéseként a független DM-ek kiépítését tűzik ki célul.
Ezen megközelítés szerint a DWH egyből nem eladható mert a nagy volumenú
a beruházás megtérülése túlságosan kitolódik, ezért inkább modulárisabban kell kezelni a
bevezetést. Eszerint először elszigetelt Adatpiacok (Data Mart – DM) jönnek
létre, melyekből később, miután működésük bonyolulttá és áttekinthetetlenné
válik, kialakul a homogén adattárház (Data Warehouse – DW) struktúra.
a beruházás megtérülése túlságosan kitolódik, ezért inkább modulárisabban kell kezelni a
bevezetést. Eszerint először elszigetelt Adatpiacok (Data Mart – DM) jönnek
létre, melyekből később, miután működésük bonyolulttá és áttekinthetetlenné
válik, kialakul a homogén adattárház (Data Warehouse – DW) struktúra.
Adatpiac: Speciális üzleti igényekre, specializált elemzésekre létrehozott,
tematikus, a vállalat egy bizonyos csoportja által használt rendszer, mely
önmagában is elláthat adattárház feladatokat, azonban a kapacitás és az
információszükséglet lényegesen kisebb.
tematikus, a vállalat egy bizonyos csoportja által használt rendszer, mely
önmagában is elláthat adattárház feladatokat, azonban a kapacitás és az
információszükséglet lényegesen kisebb.
Egyéb DWH építéssel kapcsolatos fogalmak:
STAGE /landig (érkeztető réteg/terület)
• forrásrendszerrel megegyező tárolási struktúra
• forrásadatok többnyire napi táblapartíciókban
• adatfogadás vagy beszerzés
• forrásadatok változtatásmentes archiválása
• Teljes újratöltés lehetősége
DW (adatház referencia tár réteg/terület)
• egységes üzleti adatmodell
• helyettesítő kulcs képzése
• forrás természetes kulcsainak tárolása
• történeti adattárolás
• elsődleges, egyedi és idegen kulcsok beállítása
• forrásrendszeri fix értékkészletek egységes tárolása •
forrásoldali fizikai törlés kezelése
• szótár-, törzs-, kapcsoló- és esemény típusú táblák (Business Glossary)
• technikai mezők: OBJ_TYPE, SOURCE_1…5, LOAD_ID
DM (adatpiac, publikációs réteg/terület)
• helyettesítő kulcs megtartása
• különböző aggregáltsági szint több rétegen keresztül
• újrafuttathatóság a folyamatos bővítések miatt
• aggregátumok üzleti paraméterezés alapján
• főleg helygazdálkodás kérdése, visszamenőleges adattárolás
Operational Data Store (ODS): Az ODS a tranzakciós adatok egy olyan nagy részletezettségű gyűjtőheje, amit az adatok egyesítésére és tisztítására használhatunk, esetleg a teljes részletezettségű adatok elérésére.
Virtuális adattárház: Ez a fogalom már nem az adattárház méretével függ össze. Virtuális adattárházról akkor beszélünk, ha az operációs (forrás) adatbázisokon túl nem épül adatbázis az adattárház adatai számára. Az adattárház ekkor az operációs adatok megfelelő nézetére biztosít felületet. Hátránya a gyenge válaszidő-teljesítménye és az forrás adatbázisok folyamatos terhelése.
Az adatbázis adatmodelljeit három kategóriába soroljuk:
– A koncepcionális (vagy szemantikai) szintű adatmodellek a felhasználók adatleíró módszereit takarják, függetlenek a konkrét implementációtól.
– A logikai szintű adatmodellek már függnek az adatbázisszervertől, de még mindig egy absztrakt, bár alacsonyabb rendű felhasználói nézetet biztosítanak.
– A fizikai szint adatmodelljei már teljesen a konkrét adatbázis implementációtól függnek, azt írják le, hogyan is tároljuk fizikailag az adott adatokat.
– A 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.
Leegyszerűsítve az adattárház adat töltéshez két alapvető adatkezelési művelet kell csak:
– a kezdeti adatbetöltés
– a lekérdezésekhez szükséges adatelérés betöltései
— OLAP fő műveletek
Felgörgetés – Roll up (drill-up): összesítjük (pl. összegezzük) az adatokat a hierarchián feljebb lépve vagy a dimenziót elhagyva
Lefúrás – Drill down (roll down): kirészletezünk adatokat (a felgörgetés fordítottja) alacsonyabb szintű összesítést veszünk, részletezzük az adatokat, vagy bevezetünk egy új dimenziót
Szeletelés és kockázás – Slice and dice: vetítés és kiválasztás
Forgatás (pivotálás) – Pivot (rotate): elforgatjuk a kockát, vagy a vizualizációját, a 3D-t alkotó 2D-s síkszeletek sorozatát átrendezzük
– a kezdeti adatbetöltés
– a lekérdezésekhez szükséges adatelérés betöltései
— OLAP fő műveletek
Felgörgetés – Roll up (drill-up): összesítjük (pl. összegezzük) az adatokat a hierarchián feljebb lépve vagy a dimenziót elhagyva
Lefúrás – Drill down (roll down): kirészletezünk adatokat (a felgörgetés fordítottja) alacsonyabb szintű összesítést veszünk, részletezzük az adatokat, vagy bevezetünk egy új dimenziót
Szeletelés és kockázás – Slice and dice: vetítés és kiválasztás
Forgatás (pivotálás) – Pivot (rotate): elforgatjuk a kockát, vagy a vizualizációját, a 3D-t alkotó 2D-s síkszeletek sorozatát átrendezzük
– Egyéb OLAP műveletek
Keresztülfúrás – drill across: egynél több ténytáblában fúrunk le
Átfúrás -drill through: a lefúrást SQL utasításokkal a kockában a legrészletezettebb adatokig, azaz az alap relációs táblákig folytatjuk
Keresztülfúrás – drill across: egynél több ténytáblában fúrunk le
Átfúrás -drill through: a lefúrást SQL utasításokkal a kockában a legrészletezettebb adatokig, azaz az alap relációs táblákig folytatjuk
— DWH megvalósítási tipusok
Vállalati adattárház (Enterprise warehouse) : a teljes szervezet összes fontos információját tartalmazza, amely bármilyen témájú elemzéshez valaha is kellhet
Adatpiac (Data Mart) : egy adott témához (például marketing) szükséges adatok gyűjteménye külön is megépíthetjük, de lehet része a vállalati adattárháznak is
Virtuális adattárház (Virtual warehouse) : A működési adatbázisra építünk nézeteket Egyes összesítő nézeteket materializálunk
Vállalati adattárház (Enterprise warehouse) : a teljes szervezet összes fontos információját tartalmazza, amely bármilyen témájú elemzéshez valaha is kellhet
Adatpiac (Data Mart) : egy adott témához (például marketing) szükséges adatok gyűjteménye külön is megépíthetjük, de lehet része a vállalati adattárháznak is
Virtuális adattárház (Virtual warehouse) : A működési adatbázisra építünk nézeteket Egyes összesítő nézeteket materializálunk
— DWH -ban a leíró adatok kezelése (Metadata Repository)
A metaadatok az adattárház objektumainak definícióit tárolják.
Adattárház struktúráinak leírása : sémák, nézetek, dimenziók, hierarchiák, számolt adatok definíciói, adatpiacok elérési helye és tartalma
A metaadatok az adattárház objektumainak definícióit tárolják.
Adattárház struktúráinak leírása : sémák, nézetek, dimenziók, hierarchiák, számolt adatok definíciói, adatpiacok elérési helye és tartalma
Működési metaadatok adatvonal :(a migrált adatok története és a transzformációk sorozata), adatállapot (aktív, archivált, törölt), monitorozási információk (használati statisztikák, hibajelentések, ellenőrzések)
Az összesítésekhez, aggregációkhoz szükséges algoritmusok
Azok a leképezések (mappings), amelyek a működési adatbázisból áttöltik az adatokat az adattárházba
Rendszer szintű adatleírások a jobb teljesítményhez indexek definíciói, frissítési periódusok
Üzleti adatok : üzleti fogalmak, definíciók, díjkalkulációk
A DWH-ban alkalmazott teljesítmény javítási módszerek:
– Denormalizáció
Denormalizáció alatt értjük azt az eljárást, mikor a ténytáblában redundánsan eltárolunk járulékos jellemzőket, olyanokat, melyek a dimenziótáblákban egyébként szerepelnek. Például, a kiskereskedős példánál az elemzéseknél gyakran használják a termék dimenziót, de abból csak a gyártó jellemzőt. Ekkor, ha a válaszidők nem megfelelőek, a ténytáblába mint oszlop bevesszük a “gyártó” jellemzőt, így megspórolva egy join műveletet a kiértékelésnél, elbukva viszont tárterületet a redundancia miatt.
Az adattárház rendszerekre általánosan jellemző az elemzési hatékonyság miatti redundáns adattárolás.
Denormalizáció alatt értjük azt az eljárást, mikor a ténytáblában redundánsan eltárolunk járulékos jellemzőket, olyanokat, melyek a dimenziótáblákban egyébként szerepelnek. Például, a kiskereskedős példánál az elemzéseknél gyakran használják a termék dimenziót, de abból csak a gyártó jellemzőt. Ekkor, ha a válaszidők nem megfelelőek, a ténytáblába mint oszlop bevesszük a “gyártó” jellemzőt, így megspórolva egy join műveletet a kiértékelésnél, elbukva viszont tárterületet a redundancia miatt.
Az adattárház rendszerekre általánosan jellemző az elemzési hatékonyság miatti redundáns adattárolás.
– Aggregáció
Aggregáció alatt értjük azt, mikor az adatok valamely szempont szerinti felösszegzett változatát is eltároljuk az adatbázisunkban. Ez jelentheti egy vagy több dimenzió elhagyását. A következő ábra szemlélteti egy négydimenziós adatkocka agregációs lehetőségeit. Nyilván az aggregációs szintek bevezetésével, használatával a válaszidők jelentősen javulhatnak egyes lekérdezéseknél, igaz viszont az is, hogy az összegeket minden új adatelem beszúrásánál frissíteni kell.
Aggregáció alatt értjük azt, mikor az adatok valamely szempont szerinti felösszegzett változatát is eltároljuk az adatbázisunkban. Ez jelentheti egy vagy több dimenzió elhagyását. A következő ábra szemlélteti egy négydimenziós adatkocka agregációs lehetőségeit. Nyilván az aggregációs szintek bevezetésével, használatával a válaszidők jelentősen javulhatnak egyes lekérdezéseknél, igaz viszont az is, hogy az összegeket minden új adatelem beszúrásánál frissíteni kell.
– Particionálás
A ténytábla túl nagyra hízása a teljesítmény rovására megy. Ezt elkerülendő szokás a táblát több ténytáblára vágni, melyek esetleg akár párhuzamosan is feldolgozhatók lehetnek.
A ténytábla túl nagyra hízása a teljesítmény rovására megy. Ezt elkerülendő szokás a táblát több ténytáblára vágni, melyek esetleg akár párhuzamosan is feldolgozhatók lehetnek.
– Parallel futtatás (Parallel execution)
A parallel futtatás egyszerűen kifejezve azon az ötleten alapszik, hogy szétszedjük a folyamatot több részre, és ahelyett hogy egyetlen rendszerfolyamat kezelne minden munkát egy lekérdezés kapcsán, több szál is ugyanazon a lekérdezés egy egy részét dolgozza fel. Példa lehet az ilyen futtatásra ha négy folyamat dolgoz fel különböző negyedéveket, egyetlen folyamat helyett.
A parallel futtatás egyszerűen kifejezve azon az ötleten alapszik, hogy szétszedjük a folyamatot több részre, és ahelyett hogy egyetlen rendszerfolyamat kezelne minden munkát egy lekérdezés kapcsán, több szál is ugyanazon a lekérdezés egy egy részét dolgozza fel. Példa lehet az ilyen futtatásra ha négy folyamat dolgoz fel különböző negyedéveket, egyetlen folyamat helyett.
A DWH adattöltési megoldások:
– “Push” adattöltés: Az operatív rendszerünket felkészítjük arra, hogy az adattárház számára adatokat gyűjtsön, adatokat továbbítson. Ebben az esetben lentről-felfelé az operatív rendszer kezdeményezi az adatok továbbítását az adattárházba.
– “Pull” adattöltés: Az adattárház a megfelelően beállított időintervallumban az operatív rendszerekhez intézett lekérdezésekkel frissíti az adatait.
– “Push” adattöltés: Az operatív rendszerünket felkészítjük arra, hogy az adattárház számára adatokat gyűjtsön, adatokat továbbítson. Ebben az esetben lentről-felfelé az operatív rendszer kezdeményezi az adatok továbbítását az adattárházba.
– “Pull” adattöltés: Az adattárház a megfelelően beállított időintervallumban az operatív rendszerekhez intézett lekérdezésekkel frissíti az adatait.
Change Data Capture(CDC) :
A legtöbb adatbázis rendszer támogatja azt a funkciót, ekkor a legutóbbi áttöltés óta változott adatokat egy külön táblában gyűjti. Itt egy bizonyos időpillanat, például az áttöltő task lefutása utáni adatváltozásokat tárolja, hogy a legközelebbi áttöltés esetén csak ezzel kelljen foglalkozni.
A legtöbb adatbázis rendszer támogatja azt a funkciót, ekkor a legutóbbi áttöltés óta változott adatokat egy külön táblában gyűjti. Itt egy bizonyos időpillanat, például az áttöltő task lefutása utáni adatváltozásokat tárolja, hogy a legközelebbi áttöltés esetén csak ezzel kelljen foglalkozni.
Slowly changing dimension (SCD) :
– első csoportban vannak, amik sohasem változhatnak, amennyiben ezek között módosulást talál hibát jelez;
– a második csoport a változó attribútumok, amiknek változás esetén módosulnia kell;
– a harmadik pedig, amik esetén a változását követnünk kell verziókövetéssel.
– első csoportban vannak, amik sohasem változhatnak, amennyiben ezek között módosulást talál hibát jelez;
– a második csoport a változó attribútumok, amiknek változás esetén módosulnia kell;
– a harmadik pedig, amik esetén a változását követnünk kell verziókövetéssel.
Alapvetően két csoportba vannak bontva az adataink, az egyik adag update utasítás hatására frissül, a másik adat pedig insert hatására új rekordként kerül a DW-be.
Az SCD technikának két tiszta formája létezik:
– az SCD type-1 módszer lényege, hogy nem követi a dimenzióelemek változását, nem őrzi meg például a vevők korábbi jellemzőit (mint például a telephely), hanem azokat helyben felülírja;
– az SCD type-2 módszer lényege, hogy a dimenzióelem megváltozása esetén létrehozza annak egy újabb verzióját, nem írja felül a vevő korábbi telephelyét, hanem létrehoz egy új vevőt az új telephellyel, úgy, hogy közben megmarad a régi is.
– az SCD type-1 módszer lényege, hogy nem követi a dimenzióelemek változását, nem őrzi meg például a vevők korábbi jellemzőit (mint például a telephely), hanem azokat helyben felülírja;
– az SCD type-2 módszer lényege, hogy a dimenzióelem megváltozása esetén létrehozza annak egy újabb verzióját, nem írja felül a vevő korábbi telephelyét, hanem létrehoz egy új vevőt az új telephellyel, úgy, hogy közben megmarad a régi is.
Egyes típusok részletesebb kifejtéséből számomra a következő elemek tetszettek:
Type 0 – The passive method
Type 1 – Overwriting the old value
Type 2 – Creating a new additional record
Type 3 – Adding a new column
Type 4 – Using historical table
Type 6 – Combine approaches of types 1,2,3 (1+2+3=6)
Type 0 – The passive method
Type 1 – Overwriting the old value
Type 2 – Creating a new additional record
Type 3 – Adding a new column
Type 4 – Using historical table
Type 6 – Combine approaches of types 1,2,3 (1+2+3=6)
Type 6 – Combine approaches of types 1,2,3 (1+2+3=6). In this type we have in dimension table such additional columns as:
current_type – for keeping current value of the attribute. All history records for given item of attribute have the same current value.
historical_type – for keeping historical value of the attribute. All history records for given item of attribute could have different values.
start_date – for keeping start date of ‘effective date’ of attribute’s history.
end_date – for keeping end date of ‘effective date’ of attribute’s history.
current_flag – for keeping information about the most recent record.
current_type – for keeping current value of the attribute. All history records for given item of attribute have the same current value.
historical_type – for keeping historical value of the attribute. All history records for given item of attribute could have different values.
start_date – for keeping start date of ‘effective date’ of attribute’s history.
end_date – for keeping end date of ‘effective date’ of attribute’s history.
current_flag – for keeping information about the most recent record.
DWH adattöltéssel kapcsolatos további fogalmak:
A mesterséges kulcs (DW_ID) feladata:
– elsődleges feladata, hogy segítségével meg tudjuk oldani az adattárházba érkező rekordok verziózását.
– elszakadhatunk a forrásrendszerek kódolásától, így azok esetleges változását könnyen kezelni tudjuk.
– egyszerre több forrásrendszerből jövő „vevőkódot” is fel tudunk dolgozni;
– felvehetünk a dimenzióba olyan dimenzióelemeket, amelyek nem léteznek a forrásrendszerekben;
– az egész számként tárolt mesterséges kulcs hatékonyabb, mint a szöveges természetes kulcs:
kevesebb helyet foglal, könnyebben megbirkózik vele a relációs adatbázis-kezelő is, így hatékonyabb lesz a lekérdezés és a feldolgozás is.
– elsődleges feladata, hogy segítségével meg tudjuk oldani az adattárházba érkező rekordok verziózását.
– elszakadhatunk a forrásrendszerek kódolásától, így azok esetleges változását könnyen kezelni tudjuk.
– egyszerre több forrásrendszerből jövő „vevőkódot” is fel tudunk dolgozni;
– felvehetünk a dimenzióba olyan dimenzióelemeket, amelyek nem léteznek a forrásrendszerekben;
– az egész számként tárolt mesterséges kulcs hatékonyabb, mint a szöveges természetes kulcs:
kevesebb helyet foglal, könnyebben megbirkózik vele a relációs adatbázis-kezelő is, így hatékonyabb lesz a lekérdezés és a feldolgozás is.
Lookup az a művelet amikor egy rekordot betöltünk az adattárház ténytáblájába, akkor az abban szereplő természetes kulcsokat ki kell cserélnünk a dimenziótáblákban található mesterséges kulcsokra.
Tehát azt a folyamatot, amikor a ténytáblák betöltése során az azokban szereplő természetes kulcsokat kicseréljük azok megfelelő mesterséges kulcspárjaikra, lookup-nak nevezzük.
Tehát azt a folyamatot, amikor a ténytáblák betöltése során az azokban szereplő természetes kulcsokat kicseréljük azok megfelelő mesterséges kulcspárjaikra, lookup-nak nevezzük.
Az adatbányászati folyamatnak két elfogadott szabványa is létezik, a CRISP-DM és a SEMM.
A adatbányászati folyamat felosztása (CRISP-DM):
– Üzleti probléma megértése
– Adatok megismerése
– Adat előkészítés
– Modellezés
– Kiértékelés
– Bevezetés
– Üzleti probléma megértése
– Adatok megismerése
– Adat előkészítés
– Modellezés
– Kiértékelés
– Bevezetés
Egyes DWH forrás terültek:
Interfész/ adat betöltési terület feladata a különböző forrás rendszerek adatainak azonos platformra hozása (egységes adatbázisba töltése).
A staging terület (ideiglenes tároló) feladata az adatok átmenetileg tárolása, konverziók elvégzése és adatok öregítése.
Az adatok kinyerése és betöltése az adattárházba funkció első szeparált területe a Data Staging Area.
Mivel a staging adatok nincsenek betöltve az adattárba ezért normál felhasználók számára egyáltalán nem elérhetőek el.
A staging területen az adatok legalább 6 hónapig öregíthetőek és itt az adatoknak különböző verzióit kell kezelni,
hiszen a később hibásnak ítélt adatokat akár többször is be kell tölteni.
Az adatok kinyerése és betöltése az adattárházba funkció első szeparált területe a Data Staging Area.
Mivel a staging adatok nincsenek betöltve az adattárba ezért normál felhasználók számára egyáltalán nem elérhetőek el.
A staging területen az adatok legalább 6 hónapig öregíthetőek és itt az adatoknak különböző verzióit kell kezelni,
hiszen a később hibásnak ítélt adatokat akár többször is be kell tölteni.
Néhány DWH-hóz kapcsolódó egyéb fogalom
adatöregítés :
Az adatok egyfajta archiválása, melynek lényege, hogy bizonyos időszaknál régebbi adatokat megfelelően aggregálunk (aggregált adat), a tárhelyigény csökkentése érdekében a legkevesebb információvesztéssel.
(Például napi adatok esetén olyan felösszegzést, összevonást alkalmazunk, hogy havi adatok álljanak elő.)
Az adatok egyfajta archiválása, melynek lényege, hogy bizonyos időszaknál régebbi adatokat megfelelően aggregálunk (aggregált adat), a tárhelyigény csökkentése érdekében a legkevesebb információvesztéssel.
(Például napi adatok esetén olyan felösszegzést, összevonást alkalmazunk, hogy havi adatok álljanak elő.)
adattisztítás :
A valóságtól eltérő, hibás adatok, zajok, valamint az inkonzisztens adatok kiszűrése és javítása a rendszerben.
A valóságtól eltérő, hibás adatok, zajok, valamint az inkonzisztens adatok kiszűrése és javítása a rendszerben.
adattranszformáció :
Az adatok átalakítása más formára hozza az adott adatsort egy művelet, függvény, vagyis valamely alkalmas transzformáció alkalmazásával. Az adatok aggregálása egy tipikus és gyakori transzformáció.
Az adatok átalakítása más formára hozza az adott adatsort egy művelet, függvény, vagyis valamely alkalmas transzformáció alkalmazásával. Az adatok aggregálása egy tipikus és gyakori transzformáció.
aggregált adat
Valamely dimenzió(k) mentén bármely alkalmas aggregációs művelet (SUM, MIN, MAX, AVG stb.) segítségével felösszegzett adat.
Valamely dimenzió(k) mentén bármely alkalmas aggregációs művelet (SUM, MIN, MAX, AVG stb.) segítségével felösszegzett adat.
alapadat
A forrásrendszerekből kinyert adathalmaz, mely csak a minimálisan szükséges módosításokon, transzformációkon esett át, ezért a felösszegzett, adatpiacokhoz, riportokhoz vagy elemzésekhez előállított adattáblák alapjául szolgál.
A forrásrendszerekből kinyert adathalmaz, mely csak a minimálisan szükséges módosításokon, transzformációkon esett át, ezért a felösszegzett, adatpiacokhoz, riportokhoz vagy elemzésekhez előállított adattáblák alapjául szolgál.
átmeneti adattároló (staging)
Az ETL adatbetöltési folyamatait segítő, köztes adattároló terület az adattárházon belül. Lényege, hogy minimalizálja a forrásrendszerek adatbázisainak terhelését, és az alapadatok kinyerése után az adattárházon belül végezzük el a szükséges transzformációkat.
Az ETL adatbetöltési folyamatait segítő, köztes adattároló terület az adattárházon belül. Lényege, hogy minimalizálja a forrásrendszerek adatbázisainak terhelését, és az alapadatok kinyerése után az adattárházon belül végezzük el a szükséges transzformációkat.
dimenzió
Egy adott ismérv értékeinek összessége, melynek mentén a mérőszámok értékei értelmezhetőek. Például dimenzió az idő, értékei az évek, mely évek mentén a hallgatói létszámok értelmezhetőek.
Egy adott ismérv értékeinek összessége, melynek mentén a mérőszámok értékei értelmezhetőek. Például dimenzió az idő, értékei az évek, mely évek mentén a hallgatói létszámok értelmezhetőek.
dimenzionális adatmodell
Az adattár tervezésének egy speciális adatmodellje, ahol a ténytáblákban rögzítjük a mérőszámokat, dimenziótáblákban a mérőszámok különböző csoportosításait (dimenzióit), és rögzítjük a ténytáblák és dimenziótáblák összefüggéseit.
Az adattár tervezésének egy speciális adatmodellje, ahol a ténytáblákban rögzítjük a mérőszámokat, dimenziótáblákban a mérőszámok különböző csoportosításait (dimenzióit), és rögzítjük a ténytáblák és dimenziótáblák összefüggéseit.
dimenziótábla
Tartalmazza egy adott dimenzió összes értékét általában az egyes értékek azonosítójával összerendelve, illetve a dimenzió egyes szintjeinek (hierarchiájának) alkalmas rögzítésével.
Tartalmazza egy adott dimenzió összes értékét általában az egyes értékek azonosítójával összerendelve, illetve a dimenzió egyes szintjeinek (hierarchiájának) alkalmas rögzítésével.
ETL (Extract, transform, load) folyamat
Az adatok kinyerése, átalakítása és betöltése, mely megfelelően aggregálja és kezeli az adatokat a forrásrendszertől az adattárház megfelelő adatpiacáig.
Az adatok kinyerése, átalakítása és betöltése, mely megfelelően aggregálja és kezeli az adatokat a forrásrendszertől az adattárház megfelelő adatpiacáig.
forrásrendszer
Azon rendszerek, amelyek az operatív, üzletmenettel, intézményi tevékenységgel kapcsolatos vagy egyéb olyan feladatokat támogatnak, melyek az adattárház számára forrásadatokat generálnak.
Azon rendszerek, amelyek az operatív, üzletmenettel, intézményi tevékenységgel kapcsolatos vagy egyéb olyan feladatokat támogatnak, melyek az adattárház számára forrásadatokat generálnak.
granularitás szint
Az adattárházban tárolt adatok részletezettségi szintjének jellemzője, mely a tárolt adatok összegzési szintjében, az egyes rekordokban az adatról fellelhető legelemibb egységben nyilvánul meg.
Az adattárházban tárolt adatok részletezettségi szintjének jellemzője, mely a tárolt adatok összegzési szintjében, az egyes rekordokban az adatról fellelhető legelemibb egységben nyilvánul meg.
integrált információrendszer
Az információrendszer különböző szintjeit egymással kommunikáló, egységes egészbe szervezett együttes.
Az információrendszer különböző szintjeit egymással kommunikáló, egységes egészbe szervezett együttes.
metaadat
Adat az adatról, vagyis az egyes adatbázisok leírása, az adatállományok tulajdonságain keresztül. Egy adattábla mezőjének a hossza, típusa, formátuma tipikus példa a metaadatokra. Felhasználói metaadat lehet egy leírás, mutató vagy fogalomdefiníció.
OLAP (Online Analytical Processing)
Online analitikus (elemző) feldolgozás. Olyan elemzésre, lekérdezésre optimalizált adattárolási módszer, amely az összes összevonható dimenzió mentén minden lehetséges kombinációban és szinten előre felösszegzi a mérőszámokat, így csökkentve a lekérdezéskori számítási időigényt, illetve a több dimenzió mentén történő, hatékony elemzést.
Online analitikus (elemző) feldolgozás. Olyan elemzésre, lekérdezésre optimalizált adattárolási módszer, amely az összes összevonható dimenzió mentén minden lehetséges kombinációban és szinten előre felösszegzi a mérőszámokat, így csökkentve a lekérdezéskori számítási időigényt, illetve a több dimenzió mentén történő, hatékony elemzést.
PDCA-módszer
A PDCA bármilyen műveletre, tevékenységre, folyamatra, rendszerre, működtetésre, koncepcióra, elgondolásra vonatkoztatható, zárt hatásláncú, folytonosan ismétlődő körfolyamat-elv, a minőségfejlesztés alapciklusa. A folyamat fázisai: tervezés (Plan), megvalósítás (Do), ellenőrzés (Check), beavatkozás (Act)
A PDCA bármilyen műveletre, tevékenységre, folyamatra, rendszerre, működtetésre, koncepcióra, elgondolásra vonatkoztatható, zárt hatásláncú, folytonosan ismétlődő körfolyamat-elv, a minőségfejlesztés alapciklusa. A folyamat fázisai: tervezés (Plan), megvalósítás (Do), ellenőrzés (Check), beavatkozás (Act)
ténytábla
A dimenzionális adatmodellnek azon táblái, amelyek a mérőszámokat tartalmazzák. Egy témakörben használt mérőszámok tipikusan egy ténytáblában kerülnek tárolásra. Bennük kerül továbbá rögzítésre, hogy mely dimenziók mentén értelmezhetőek a mérőszámok, azaz mely dimenziótáblák kapcsolhatóak hozzá. Egy OLAP-kocka általában egy ténytábla és a hozzákapcsolódó dimenziótáblák feldolgozásával áll elő.
A dimenzionális adatmodellnek azon táblái, amelyek a mérőszámokat tartalmazzák. Egy témakörben használt mérőszámok tipikusan egy ténytáblában kerülnek tárolásra. Bennük kerül továbbá rögzítésre, hogy mely dimenziók mentén értelmezhetőek a mérőszámok, azaz mely dimenziótáblák kapcsolhatóak hozzá. Egy OLAP-kocka általában egy ténytábla és a hozzákapcsolódó dimenziótáblák feldolgozásával áll elő.
validáció (adatfeldolgozás)
Az a folyamat, amely lehetővé teszi, hogy megbízható, hiteles adatok kerüljenek betöltésre az adattárba.
Az a folyamat, amely lehetővé teszi, hogy megbízható, hiteles adatok kerüljenek betöltésre az adattárba.
A biztonsági szempontok három rétege:
• Alkalmazás biztonság: az adatkezelő alkalmazások jogosultságkezelésére, biztonságára vonatkozó szempontok.• Objektum biztonság: A nyilvántartások, adatbázisok adott valós objektumok halmazáról tárolnak adatokat. Ebbe a csoportba a teljes objektumok (pl. állampolgárok, személygépjárművek, stb.) adataira vonatkozó megkötések, biztonsági elvárások tartoznak.
• Adatbiztonság: a tárolt elemi szintű adatok hozzáférhetőségére, módosíthatóságára vonatkozó szempontok.
A fogalmak és tevékenységek megvalósítására néhány gyártó megoldása:
Microsoft
– VISUAL STUDIO BUSINESS INTELLIGENCE DEVELOPMENT STUDIO (BIDS)
Az SQL server programcsomag része egy a Visual Studio-ba beépülő plugin, melynek segítségével SSAS, SSIS projekteket hozhatunk létre. A BIDS támogatja, hogy a létrejött projekteket egyből az adatbázisba töltsük, vagy akár egy külön file ba .xml felépítéssel kimentsük.
Az SQL server programcsomag része egy a Visual Studio-ba beépülő plugin, melynek segítségével SSAS, SSIS projekteket hozhatunk létre. A BIDS támogatja, hogy a létrejött projekteket egyből az adatbázisba töltsük, vagy akár egy külön file ba .xml felépítéssel kimentsük.
– SQL SERVER INTEGRATION SERVICE (SSIS)
Az SSIS szerepe az adattárház teljes ETL folyamatának támogatása.Itt lehet a forrás adatainkon több forrásból a szükséges átalakításokat elvégezni és a DW-be tölteni (akár ütemezhető taszként).
Az SSIS szerepe az adattárház teljes ETL folyamatának támogatása.Itt lehet a forrás adatainkon több forrásból a szükséges átalakításokat elvégezni és a DW-be tölteni (akár ütemezhető taszként).
Az SSIS csomagot a BIDS-ben definiáljuk, itt írjuk le az adatátöltő taszkot. Egy csomag két fő részből épül fel egy control és egy data flow összetevőből.
A control részegység határozza meg a logikát és a data flow mozgatja és alakítja az adatokat.
Az adatfolyamon belül három fontos részt jelenik meg:
- a forrásadatok,
- a céladatok
- a transzformációs taszkok.
Az SSIS használata:
Első lépésként a control flow-t kell megterveznünk. Ebben elhelyzett data flow task beillesztésével tudjuk majd az adatinkat a forrás és a cél között mozgatni. A derived column task segítségével verzió követés végső átalakításokat, összefűzések elvégezhetőek
Első lépésként a control flow-t kell megterveznünk. Ebben elhelyzett data flow task beillesztésével tudjuk majd az adatinkat a forrás és a cél között mozgatni. A derived column task segítségével verzió követés végső átalakításokat, összefűzések elvégezhetőek
SQL SERVER ANALYSIS SERVICE (SSAS)
Ez az eszköz implementál egy OLAP kockát. Itt a megfelelő forrásadatok megadása után, grafikus felületén a BIDS-nek tervezhető az OLAP kocka.
Ez az eszköz implementál egy OLAP kockát. Itt a megfelelő forrásadatok megadása után, grafikus felületén a BIDS-nek tervezhető az OLAP kocka.
SQL SERVER MANAGEMENT STUDIO (SSMS)
A SSMS az SQL szerver adatbázisok menedzselésére szolgál. Itt lehet sémákat és a táblákat listázni, SQL utasításokat futtatni, …
A SSMS az SQL szerver adatbázisok menedzselésére szolgál. Itt lehet sémákat és a táblákat listázni, SQL utasításokat futtatni, …
Az ütemezés beállítása a Management Studio segítségével történik. Egy új job-ot létrehozva a legördülő menübe megjelennek a SSIS csomagok listája.
Oracle
Oracle Warehouse Builder (OWB) / Oracle Data Integrátor (ODI)
Az OWB olyan integrált környezet, amelyben az adattárház megvalósítás teljes életciklusa menedzselhető és kivitelezhető a tervezéstől, a fejlesztésen, tesztelésen át az üzemeltetésig, az esetleges adattárház változások megoldását is beleértve, mindezt csoportmunka támogatással.
Komponensei a három-paneles Design Center navigátor itt a munka ténylegesen modulokban történik, amely általában forrás (source) és cél (target) definíciókat tartalmaz, ez lehet:
- map
- transzformáció
- dimenzió
- adatkocka (cube)
- tábla
Lehetőségünk van Feladatok (Jobs) ablakban megtekinteni a telepítési (deploy) műveleteket, a végrehajtott és az időzített tevékenységeket. Az adott feladatra duplán kattintva megtekintjük a futás részletes eredményét, és az esetleges hibaüzeneteket.
Oracle Business Intelligence Enterprise Edition (OBIEE)
– Administration Tool (Enterprise Business Model Administration)
Feladata a három adat forrás réteg kezelése:
• Fizikai réteg (Physical) -> Alapegységei a katalógus, séma itt jelennek meg a táblák, ..
• Üzleti és mapping réteg (Business Model and Mapping)
• Megjelenítési réteg (Presentation)
• Fizikai réteg (Physical) -> Alapegységei a katalógus, séma itt jelennek meg a táblák, ..
• Üzleti és mapping réteg (Business Model and Mapping)
• Megjelenítési réteg (Presentation)
– Answers (Oracle Business Intelligence Answers)
Az Answers-ben a szervezetek elemzési riportállási kérdéseinkre lehet válaszokat készíteni.
Itt tetszőleges lekérdezéseket lehet összeállítani, futtatni és elmenteni, egy bármilyen számítógépről elérhető webes felületen.
Itt tetszőleges lekérdezéseket lehet összeállítani, futtatni és elmenteni, egy bármilyen számítógépről elérhető webes felületen.
WEB-es riportok adattartalmi és formázási tervezése és publikálására szolgál.
– Dashboard (Oracle Business Intelligence Dashboards)
A BI Interactive Dashboards egy olyan felületet melyen tetszőleges számú és
típusú lekérdezés eredményt és jelentést (legfontosabb adatokait) jelenit meg WEB-es webes felületen,
melynél a lekérdezések paramétereit is könnyen tudjuk módosítani, hangolni.
Az itt készített “műszerfal” számtalan kulcs (KPI) információt mutat egyszerre cél felhasználók számára.
típusú lekérdezés eredményt és jelentést (legfontosabb adatokait) jelenit meg WEB-es webes felületen,
melynél a lekérdezések paramétereit is könnyen tudjuk módosítani, hangolni.
Az itt készített “műszerfal” számtalan kulcs (KPI) információt mutat egyszerre cél felhasználók számára.
Régi és újabb OBI technológiák összehasonlítása funkcionalitás alapján
Technológiák | Discoverer | OBIEE Plus
Adminisztráció |Discoverer Administrator |BI EE Administration Tool
Ad-hoc elemzések |Discoverer |Plus BIEE Answers
Riportozás | Oracle Reports Builder | Oracle BI Publisher
Publikálás |Discoverer Portlet Provider | BIEE Interactive Dashboards
Ütemezés, elosztás | Discoverer Scheduler Oracle | BI Delivers
Office integráció | Excel OLAP Add-In | Oracle BI Office Plug-In
ETL folyamat elvárások, jellemzők:
• Fejlesztő eszköz független formalizált tervezés
• Egységes meta adatok képzése • Egységes adatmodellre és kulcsolási mechanizmusra épülő mappelés
• Futtatható kód generálás az adatbázisban ill. interface-en keresztül
• A generálási folyamat hátterét egy adatbázis objektumokból álló alkalmazás adja, ami a paraméterezésnek megfelelő mappingeket állít elő.
• History képzése :
•egyedi kulcs alapú history képzés standard mezők felhasználásával
•history kezelt mezők meghatározása automatikusan - dictionary alapján
•céltáblával azonos szerkezetű munkatáblák használata
• Fizikai mapping a logikai mapping alapján könnyen elkészíthető
• DW töltése egyszerűbb
• DM töltése aggregáltsági szinttől függően több lépésben valósítható meg
• Mapping logikák egymásba ágyazhatók
• Bonyolultabb forráslekérdezések nézetbe rendezhetők
• Generált kód kézi továbbfejlesztése kizárja a központi meta adattár további használatát
• Újraindítható kódok
Adatbázis objektumokból álló generálási folyamat háttér, háromszintű paraméterezés:
-Alapadatok definiálása
1.Map neve, csoportja
2.Céltábla és tulajdonosa, alias
3.Töltés típusa:
DELTA/FULL
History képzés típusa
4.SQL paraméterezés/hintek
-Forrástáblák és kapcsolatok definiálása
1.Forrás táblák, tulajdonosok, aliasok
2.Forrásként használt táblák kapcsolási feltételei:
JOIN
Halmazműveletek
DISTINCT
Analitikus függvények használata
3.Filterek megadása
4.SQL paraméterezés (hintek)
5.Automatikus forrás struktúra forgatások – tipikusan DM töltéskor aktuális és history adatok együttes használata (ACT_HIST_FL = ’I’)
-Mezőszintű mappelés
1.Forrás-cél mezőpárok
2.History képzés egyedi kulcs alapján
3.Helyettesítő kulcs képzése szekvenciából egységes rövidnevek alapján
4.Lookup kapcsolatok egyszerű paraméterezése forrás objektumok és idegen kulcsok alapján
Agilitás az adattárház építésben:
Back-end: töltési megközelítés: „vigyünk mindent”, modellezzük ami kell Front-end
Klasszikus agilis módszerek: SCRUM, „prototípus”
- Megfelelő BI eszközök (Klasszikus Bi eszközök vs „önkiszolgáló BI” )
- „Sand-box” az éles környezetben
A DWH fejlesztési életciklus a következő részekre tagolható:
1. Projekttervezés
2. Az információigények összegyűjtése, adatmodellezés
3. Az adatbázis fizikai tervezése és kidolgozása
4. Adatforrások meghatározása és integrációja
5. Az adattárház feltöltése
6. Az adatbetöltési folyamat automatizálása
7. Kiindulási riportkészlet létrehozása
8. Adatok minőségellenőrzése és tesztelése
9. Oktatás
10. Rollout / tartós használatba vétel
11 Utógondozás
Megjegyzések
Megjegyzés küldése