Alapelvek
Módszertan
· Csillagsémában, továbbá tény és dimenzió táblákban gondolkodunk elsődlegesen egy adatpiac építésekor. Mindemellett megengedett a szupertáblák készítése is, ha az igények úgy indokolják.
Felhasználóbarát
· Azon alapelv mentén modellezzük a sémát, hogy az üzleti felhasználók milyen kérdésekre szeretnének választ kapni és az ehhez megvalósítható legjobb modellt alakítjuk ki.
· A DM_ kezdetű adatpiacokat konkrétan maghatározott riportok kiszolgálására készítjük. Mindemellett lehetőséget biztosítunk az így kialakított adatpiacokhoz SQL-es hozzáférésre is.
· Külső kényszer hatására készíthetünk olyan adatpiacokat, ahol meghatározott adatkört elhelyezünk úgy, hogy nem ismerjük a pontos felhasználását. Ezeket elkülönítjük bármi mástól. Akár még valami névkonvenciót is alkalmazhatunk rá. De az a minimum, hogy ilyen adatpiacon nem lehet normál csillagsémás kiszolgálás.
Mindent a megfelelő helyen
· Több adatpiacra szükséges bonyolultan kikalkulálható adatokat érdemes egy szinttel lejjebb elhelyezni, így ezeket a műveleteket csak egy helyen kell elvégezni és karban tartani.
· Nem rögzítjük előre, hogy milyen tartalmú adatpiacokat építünk, mi kerülhet egy adatpiacra és mi nem. Irányadó szabályként követendő, hogy az kerülhet egy adatpiacra, ami valamilyen módon egymáshoz kapcsolódik. Ez a kapcsolat lehet tartalmi (pl. tranzakció alapú riportok egy helyen), lehet területi (pl. CRM terület által kért riportok kiszolgálása egy adatpiacra), vagy valamilyen más megfontolás alapján. De például az kevés kapcsolat, hogy használnának közös dimenzió táblát. Amikor egy projekt adatpiacot tervez, akkor a BI Architekt elé kell terjessze a terveket, hogy ő dönthessen ennek az irányelvnek a megtartásáról. (Hagyjuk valamennyire organikusan fejlődni, és inkább később refaktorálunk, mert most nem tudunk olyan tuti megoldást mondani, ami mindent visz. És nem félünk attól, hogy akár több kicsi adatpiacunk lesz.)
· Operatív riportokat is szolgálhatunk ki adattárházból. Operatív riportokat jellemzően valamilyen riport táblát készítve szolgálunk ki. Ez a riport tábla adatpiacon kerül elhelyezésre. Az is támogatható, ha egy adatpiac csillag sémája a forrása (csak ugyan az az adatpiac lehet, ahol a riport táblát elhelyezzük), vagy töltődhet közvetlenül a központi rétegből. Riport eszköz lehet ütemezett Cognos, vagy akár Karcsi is.
· Cognos riport épülhet bármelyik adatpiacra. (Az nem valószínű, hogy olyan riport lenne, amelyiket több adatpiacról tudunk kiszolgálni, de ne zárjuk ki ennek a lehetőségét sem.) Szintén nem kerülhetnek csillagsémák közös adatpiacra csak azért, mert mindegyikre épül Cognos riport.
Átláthatóság
· Adatpiacok közötti adatáramlás, azaz direkt töltés egyikből a másikba nem engedélyezett.
· Egy adatpiacon helyet kaphat több csillagsémás modell is, akár közös dimenzió táblák használata nélkül is.
· Egy adatpiacon levő tény tábla csak a saját adatpiacán levő dimenzió táblákat használhatja. (Ez azt jelenti, hogy nagyon hasonló dimenzió táblákat szükség szerint megduplázunk több adatpiacra.) Egy-egy dimenzió táblát természetesen használhat több tény tábla is, akár több kvázi-független csillagsémából is.
Hatékonyság
· A felhasználást leginkább támogató Indexek és kulcsok használata szükséges.
Eszköz
· Modellezés eszköze a PowerDesigner.
· Riporting eszköz kapcsán elsősorban a Cognosra kívánunk építeni, mind elemző riportok esetén, mind önkiszolgáló eszközként. Azt feltételezzük, hogy a Tableau is tudja majd használni a kialakított adathalmazt.
Névkonvenciók
Minden tábla és minden oszlop kommenttel kell rendelkezzen.
Séma
A fizikai sémák nevét - követve az EDW Landing és PA területein már alkalmazottakat - a következő szabály szerint kell meghatározni:
<DOMAIN RÖVIDÍTÉS><_><SÉMA TÍPUSA, AMI ADATPIAC ESETÉBEN MINDIG "DM"><_><ADATPIAC NEVE VAGY RÖVID NEVE>.
Az adatpiac nevét érdemes tagoltan meghatározni a jobb olvashatóság végett.
Példa: _HTR, EBRT_DM_CREDIT_CARD
Adatpiac táblák elnevezése
A tábla neve legyen beszédes, értse a használó terület mit is talál benne, a neve mindenféleképpen tartalmazza azt, hogy milyen tartalmú tábláról van szó.
A táblák elnevezésére az adatpiacokon a következő névkonvenciót írjuk elő:
<ADATPIAC AZONOSÍTÓ><TÁBLA TÍPUSA><_><TÁBLA ANGOL NYELVŰ NEVE>.
· <ADATPIAC AZONOSÍTÓJA>: minden adatpiac definiálásakor az is meghatározandó, hogy milyen három karakteres rövid egyedi névvel azonosítjuk.
· <_>: a következő karakter egy aláhúzás a tényleges táblanév előtt.
· <TÁBLA TÍPUSA>: a következő értékeket veheti fel egy karakteren:
ténytábla esetén F,
dimenzió tábla esetén D,
szupertábla esetén S,
paramétertábla esetén P,
egyéb ezekbe nem besorolható típusú tábla esetén O.
· <_>: a következő karakter egy aláhúzás a tényleges táblanév előtt.
· <TÁBLA ANGOL NYELVŰ NEVE>: a további 24 karakteren a tábla nevét kell definiálni angol nyelven szem előtt tartva azt az elvet, hogy legyen beszédes a neve és aláhúzásokkal tagolt a jobb olvashatóság végett.
· Hozzuk létre a tábla 6 betűs rövid elnevezését is, ezt pedig a tábla COMMENT-jébe tegyük bele, pl.: "Table short name:TRDCAL". Ez az index- (IDX_), foreign key (FK_)-, unqiue key (UK_)-, primary key (PK_) nevek megképzésekor fontos lesz.
Példák:
· HTR_F_LOAN_DISBURSEMENT: ami a Hitelezés Támogató Rendszer (HTR) adatpiacán jelent egy ténytáblát (F), mégpedig a hitelfolyósítások ténytáblát.
· RIS_D_DEAL_STATUS: ami a Risk (RIS) adatpiacon jelent egy dimenziótáblát (D), mégpedig az ügyletek állapota dimenziós táblát.
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.
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 Datamart 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.
Intervallum típusú mezők és konkrét napot tartalmazó dátum mezők nevei: START_OF_VALIDITY, END_OF_VALIDTY és EFFECTIVE_LOAD_DATE; töltési technikai mezők követve az EDW alsóbb 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_CUSID; IDX_ACCOUN_ACCTYPE
jelenleg 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.
Kivéve a flag mezőknél (*_FLG), ahol a CHAR(1 CHAR) típust.
Általánosságban egy adattárházi fejlesztés az alábbi főbb tevékenységekből tevődik össze:
- Igénykezelés- Fejlesztési döntés (Specifikáció V1)
- Fejlesztési függőségfelmérés
- Specifikáció V2 véglegesítése (Ami alapján történik az ajánlatkérés, megrendelés)
- Ajánlatkérés
- Megrendelés
- Tervezés, dokumentálás
- Rendszerterv Dokumentáció készítése
- Adatmodell tervezése
- Fejlesztés
- Rendszer módosítási elem kiadása
- Tesztelés
- Élesítés
- Dokumentáció frissítése az éles rendszer alapján
Ha kitörlünk egy adatbázistábla adott oszlopát, melyet egy másik töltőeljárás
használ, akkor a töltőeljárás működésképtelenné válik, mely megakasztja a napi
adattárház, adatpiac töltést. Ennek elhárítása a legtöbb esetben magas prioritású
és rendkívüli ráfordítást igényel.
Az előbbinél sokkal nagyobb probléma azonban, egy üzleti függőség figyelmen
kívül hagyása. Hiszen, ha például üzleti értelemben megváltozik egy mező
tartalma, amelyre függőség épül, akkor a töltőeljárás technikailag még lehet,
hogy képes lefutni.
Ebben az esetben azonban előfordulhat, hogy a megváltozott
mezőtartalom olyan helyekre kerül betöltésre, ahova üzleti értelemben nem való.
Ez azért veszélyes hiba, mert előfordulhat, hogy a hibát hosszabb ideig senki sem
fedezi fel, a napi töltés üzemszerűen folyik, de megtévesztő adatok kerülnek
betöltésre.
A függőségfelmérést például a PowerDesigner ’Lineage and Impact analysis’ funkciójával
lehetséges elvégezni. A felmérés során előfordulhat, hogy csak olyan információ áll
rendelkezésünkre, hogy egy tábla, vagy mező mely programon, adatbázis eljáráson
(mapping-en) belül töltődik, de maga a forrás tábla, vagy mező információja nem található
meg a dokumentációban.
Ilyen állapot jellemzően az olyan nagy bonyolultságú töltő
logikák esetében fordulhat elő, melyek értelmezése szoftveres úton nem megoldható.
Ebben az esetben a felmérést a Lineage elemzés, majd ezt követően a kód elemzés mellett,
akár egy újabb Lineage elemzéssel, több lépésben lehet elvégezni.
Minden ilyen fizikai adatmodellnek a lehető legteljesebb mértékben tartalmaznia kell az
adott területre vonatkozó objektumokat. A cél az, hogy minden elérhető adatot,
információt, tudást egy helyen például a PowerDesigner adatmodellben tároljunk, mert csak így garantálható, hogy ez legyen az elsődleges információforrás.
Ha sok olyan információ létezik, amely csak különböző dokumentációkban elérhető, és az adatmodellben nem szerepel, annak hosszú távon a modell hanyagolása lesz a következménye. Emiatt célszerű a tervezést végző szakértőktől megkövetelni, hogy minden elérhető információt az adatmodellbe rögzítsenek.
A Mapping-ek esetében külön ki kell térni jelen módszerben a fizikai adatmodellek közötti
Mapping készítésére. A módszerben ugyanis azt rögzítettük, hogy a különböző sémákat
különböző fizikai adatmodellekben hoztuk létre. Mappingek tervezésekor gyakori, hogy egy
tábla vagy oszlop mapping-je átnyúlik az aktuális fizikai modellből egy másik modellbe,
ugyanúgy, ahogy az adatbázis sémák töltő eljárásai is átnyúlnak másik sémába a töltés
közben.
A tervezés elkészültével következik az elkészült tervek átadása a fejlesztők számára. Egy
„ideális világban” egy terv olyan szinten kidolgozott, hogy azt különösebb kommunikáció
nélkül egy fejlesztőnek átadva, a fejlesztő képes legyen a szükséges fejlesztést elvégezni.
A kész terv és tudás átadásra szolgálnak a PowerDesigner Generáló és Export funkciói.
A táblák, nézetek, kulcsok, indexek, referenciák átadására a DDL generáló funkciókat
célszerű használni.
Az így átadott DDL-ek, tehát már tervezéskor előállnak, azokat a
fejlesztőnek nem kell létrehozni, begépelni. Ezen túl azt is biztosítjuk, hogy a tervekben
szereplő DDL megegyezik az adatbázisba élesítendő DDL-el.
Érdemes teljeskörűen kihasználni a Generáló funkciókat. Megjelölhetjük, hogy mely
objektum típusokat szeretnénk generáltatni. Például ha a foreing-key-eket performanciális
megfontolásból nem származtatjuk az adatbázisba, akkor azokat lehetőség van a
generálás közben kihagyni.
A példánál maradva fontos megjegyezni, hogy annak ellenére,
hogy nem hozzuk létre az idegen kulcsokat az adatbázisban, a modellben ezek legyenek
létrehozva. Ezen referenciák ugyanis megkönnyítik az adatmodell olvasását, az entitások
közötti kapcsolatok átlátását.
Megjegyzések
Megjegyzés küldése