Tábla szerkezet változáskor értelem szerűen ezek A kommentek is módosításra kerüljenek.
ST, Stage adat érkeztető terület elnevezése
Forrásrendszerenként külön sémába kerüljenek a táblák elhelyezésre.A táblák nevei három betűs forrásrendszer jelölő prefix-el egészüljenek ki. Javasolt a vizuális elkülönülés céljából a '_' alulvonás alkalmazása.
Pl. OPTEN-es tulajdonos adatok táblája : OPT_OWNER
Kövesse a forrás rendszeri adatok elnevezését, típusát adat hosszát és egészüljön ki a technológiai mezőkkel load_id, load_date
DM, adatpiac mezők elnevezése
A mezők neve legyen beszédes, értse a használó terület mit is talál benne, elsődlegesen angol mezőneveket kell meghatározni.
DM modellezés során a sémát, hogy az igénylő üzleti felhasználók csoportja szervezete alapján kell elnevezni ehhez hárombetűs azonosítót kell választani mely szerepel a séma nevében és a tábla nevét is első helyen prefixeli
Csillagsémában, továbbá tény és dimenzió táblákban gondolkodunk elsődlegesen egy adatpiac építésekor.
- Dimenzió tábla (egyes számú) név jelölője (másodlagos prefix) : D
- Tény tábla (fact) (egyes számú) név jelölője (másodlagos prefix) : F
Például:
Conrolling terület kártya típusok dimenzió táblája: CNT_D_CARD_TYPE
RISK terület tranzakció darabszám : RSK_F_TRANSACTION_NUMBER
A mesterséges kulcs azonosító mezők végén az "_ID" karaktersor jelenlen meg és a két tábla közötti kapcsolatot megteremtő mezők nevei egyezzenek meg a könnyű felhasználhatóság végett.
A DM szinten megjelenő forrás azonosítók egységesen „_ID” helyett „_SID” (Source ID) szuffix-szal legyenek ellátva, függetlenül annak típusától.
Dátum és dátum intervallum típusú mezők és konkrét napot tartalmazó dátum mezők nevei: START_OF_VALIDITY, END_OF_VALIDTY vagy START_DATE, END_DATE és LOAD_DATE;
Adattöltési technikai mezők követve az az adattárház alsóbb (forrás érkeztető) rétegeinek névkonvencióit: LOAD_ID, UPDATE_ID, és használjunk ACTIVE mezőt az érvényességi intervallum dátum mezők mellett, mert az üzleti felhasználás során ezt könnyebb használni.
Indexek neve
Az indexeknek séma szinten szükséges egyedinek lennie.Tartalmaznia kell a tábla rövid nevét és a mezőt/mezőket az alábbiak szerint.
IDX_[a tábla 6 betűs elnevezése]_[mező rövid neve]
pl.: IDX_CUSTOM_NAME; IDX_ACCOUN_ACCTYPE
Általában nem különböztetjük meg az indexek típusait az elnevezésben.
Primary key-ek neve
Az elsődleges kulcsoknak szükséges egyedieknek lenniük.
Tartalmaznia kell a tábla rövid nevét.
PK_[a tábla 6 betűs elnevezése]
pl.: PK_CUSTOM_CUSID
Unique key-ek neve
Az egyedi kulcsoknak szükséges egyedieknek lenniük.
Tartalmaznia kell a tábla rövid nevét.
UK_[a tábla 6 betűs elnevezése]
pl.: UK_CUSTOM_CUSID
Oszloptípusok
Karakteres típusoknál a VARCHAR2(%N CHAR) típust használjuk.
Szám típusoknál number típust használjuk
Kivéve a flag mezőknél (*_FLG), ahol a CHAR(1 CHAR) típust használjuk
Partíciók
A napi töltésű tábla partíció neve 'P' prefixxel kezdődjön és a partíció napra utaló név legyen.
pl : P_ÉÉÉÉHHNN
Amennyiben az ismétlődő mintázat és a metaadat vezérelhetőség fennáll, valamint a programlogika bonyolultsága megengedi, akkor van létjogosultsága a generált programoknak.
A programokat nem a metaadatok vezérlik, hanem a metaadatokból generálódik le a célprogram, ami elvégzi a meghatározott feladatokat.
Fontos megjegyezni, hogy a generált programokat változtatni csak a metaadatok változtatásával és a programok újragenerálásával lehet.
A következő esetekben tipikusan alkalmazták:
■ Stage töltés
■ Nem bonyolult DW töltés
■ Nem bonyolult DM töltés
A speciális adattárház működésére kitalált programkód generáló alkalmazás segítségével az elkészített kódot előre definiáltak.
A tényleges adatmozgatások során csak a forrás- és célobjektumok tulajdonságát és töltési szabályát kell meghatározni, amelyekből a generátor előállítja a kész programot.
A generátorok két fő típusa:
■ Metaadattal generált program (stage programok jellemzően ilyenek) – mapping megadása metaadatként (input, output, transzformáció)
■ Verzionált adatokra snapshot tábla generáló programok – kulcs alapján legenerálja adott időszakra, az adott tábla snapshot-ját
A generált programok fejlécébe van írva mely paramétertáblákból és milyen programgenerátorral készült. A továbbiakban a módosításuk is ezek segítségével történik.
• A fizikai séma vagy egy adatbázis séma vagy egy operációs rendszer könyvtárat jelent
• A logikai séma egy logikai csoportosítása a rendszereknek (tipikusan 1:1 kapcsolat a fizikai sémával, de kapcsolódhat akár több logikai séma egy fizikai sémához is)
• Az ODI modell 1:1 kapcsolatban van a logikai sémával
A logikai séma nem a fizikai séma egy az egyben, így a neve is inkább egy komponens neve, nem pedig a fizikai séma neve.
A fizikai séma változhat (és contextben átirányítható). A logikai séma és modell nem változik idők során.
A modell illetve a logikai séma módosítása elronthatja a már létező MAP-ek működését, ezért tiltott!
Partíciók
A napi töltésű tábla partíció neve 'P' prefixxel kezdődjön és a partíció napra utaló név legyen.
pl : P_ÉÉÉÉHHNN
Programgenerátorok
Egyedi PL-SQL blokkok fejlesztésénél előszeretettel alkalmaztak programgenerátorokat.Amennyiben az ismétlődő mintázat és a metaadat vezérelhetőség fennáll, valamint a programlogika bonyolultsága megengedi, akkor van létjogosultsága a generált programoknak.
A programokat nem a metaadatok vezérlik, hanem a metaadatokból generálódik le a célprogram, ami elvégzi a meghatározott feladatokat.
Fontos megjegyezni, hogy a generált programokat változtatni csak a metaadatok változtatásával és a programok újragenerálásával lehet.
A következő esetekben tipikusan alkalmazták:
■ Stage töltés
■ Nem bonyolult DW töltés
■ Nem bonyolult DM töltés
A tényleges adatmozgatások során csak a forrás- és célobjektumok tulajdonságát és töltési szabályát kell meghatározni, amelyekből a generátor előállítja a kész programot.
A generátorok két fő típusa:
■ Metaadattal generált program (stage programok jellemzően ilyenek) – mapping megadása metaadatként (input, output, transzformáció)
■ Verzionált adatokra snapshot tábla generáló programok – kulcs alapján legenerálja adott időszakra, az adott tábla snapshot-ját
A generált programok fejlécébe van írva mely paramétertáblákból és milyen programgenerátorral készült. A továbbiakban a módosításuk is ezek segítségével történik.
ODI (Oracle Data Integrátor)
• A fizikai séma vagy egy adatbázis séma vagy egy operációs rendszer könyvtárat jelent
• A logikai séma egy logikai csoportosítása a rendszereknek (tipikusan 1:1 kapcsolat a fizikai sémával, de kapcsolódhat akár több logikai séma egy fizikai sémához is)
• Az ODI modell 1:1 kapcsolatban van a logikai sémával
A logikai séma nem a fizikai séma egy az egyben, így a neve is inkább egy komponens neve, nem pedig a fizikai séma neve.
A fizikai séma változhat (és contextben átirányítható). A logikai séma és modell nem változik idők során.
A modell illetve a logikai séma módosítása elronthatja a már létező MAP-ek működését, ezért tiltott!
Konstans típusok:
C_<forrásrendszer rövidnév>_: a forrásrendszerben használt üzleti rövidítések
C_REF: referencia hiba, üres, nincs
C_SCH: Classification Scheme konstansok
C_CLS: Classification konstansok
C_SKY: source key üres
C_SOB: Source Object konstansok
C_FLG: Flag konstansok
Knowledge Module használat:
• Landing area töltő map esetén a fizikai map ábrán vagy egy filter vagy egy temporary tábla található, amire kattintva beállítható a Loading Knowledge Module (LKM Any to Oracle with DBLINK (Custom))
• Az Integration Knowledge Module-okat a céltáblákra kattintva lehet beállítani.
Az IKM tipusok:
o IKM Oracle Insert (Custom): egy céltábla insert
o IKM Oracle Merge (Custom): egy céltábla merge
o IKM Oracle Update (Custom): egy céltábla update
o IKM Oracle Delete (Custom): egy céltábla delete
o IKM Oracle Multi Table Insert (Custom): több céltábla insert. INSERT ALL utasítást generál. Az első és utolsó tábla beállítása szükséges a KM paraméterek között
o IKM Oracle SCD2 (Custom): Slowly Changing Dimension, hisztorizáló KM.
Az adattárház stage / LD terület általános filozófiának megfelelően járunk el:
A LD területre a forrás adatok változatlan tartalommal és csak technikai mezőkkel (töltés dátum, töltés ID) kiegészítve,
mindenféle szűrés, transzformáció és aggregáció nélkül kerüljenek át.
Mindennemű adat transzformáció, tisztítás, szűrés, adat gazdagítás, aggregáció csak a felsőbb területen történhet.
Inkrementális adatkinyeréskor csak egy korábbi, előző töltés időpont óta (pl. az utolsó adatkinyerés óta) megváltozott adatokat válogatjuk le az adattárház részére.
A megváltozott adatok, melyek még nem kerültek áttöltésre leszűrhető ha a forrástábla egy oszlopa tartalmazza az utolsó módosítás időpontját, vagy az egyes változások egy szekvencia azonosítóval (annak növekedésével) foghatóak meg.
Megjegyzések
Megjegyzés küldése