2020. február 27., csütörtök

Adatbázis modellek jellemzői

Á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 bizottsági döntés (Specifikáció V1)
- Fejlesztési függőség felmérés
- Specifikáció V2 véglegesítése (Ami alapján történik a szállítói 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
- Utógondozás
- Dokumentáció frissítése az éles rendszer alapján



A dokumentálási módszertan részeként új folyamatlépésenként elkülönülnek:

- Függőségelemzés a meglévő dokumentációk alapján a specifikációs fázisban
- Fejlesztési dokumentáció készítése a tervezés és fejlesztés fázisaiban
- Élesítés utáni dokumentáció frissítése a tényleges éles rendszer alapján



Érdemes  használni adatbázis modellező eszközben CDM (Koncepcionális adatmodell), és LDM (Logikai adatmodell) funkcióiban rejlő lehetőségeket, mellyel ez a korai tervezési szakasz is megkönnyíthető.



A felmérést technikai és üzleti értelemben is szükséges elvégezni: 

 - A felmérés során technikailag elsődlegesen a táblák, oszlopok, nézetek, töltőeljárások (mapping-ek) érintettségeire kell kitérni.
- Üzletileg pedig az érintett objektumok üzleti tartalmára kell tekintettel lenni. A fejlesztések során az ezekre gyakorolt hatásokat szükséges szem előtt tartani.



A technikai és üzleti megfontolások egyaránt fontosak:

- 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 DWH 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.


 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 a 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.



Az adatmodellben az alábbi objektumokat hozzuk létre: 

- Felhasználók (A felhasználók a séma user-ek, melyek megegyeznek a fizikai adatmodell nevével)
- Táblák
- Oszlopok
- Nézetek
- Domain-ek
- Kulcsok
- Referenciák
- Mapping-ek
     - Tábla szintű mapping-ek
     - Oszlop szintű mapping-ek



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



Az adatmodelleken átnyúló mappingek definiálása nem jelent különösebb bonyodalmat. A mapping létrehozásakor a megfelelő DataSource-ból (mint adatmodellből) kell a source oldalát kiválasztani a mappingnek a szerkesztendő target objektum forrás definiálásakor.


A kötelező comment-ezés az alábbiakat tartalmazza: 

- Felhasználó név (automatikus)
- Dátum (automatikus)
- Fejlesztési azonosító
- A fejlesztés célja pár szóval, tömören megfogalmazva


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 modellező eszköz 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 teljes kö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.


Nem új, hanem módosított objektumok esetén a modellező eszköz képes olyan DDL generálására is, mely a meglévő adatbázis szerkezetéből kiindulva alakítja a modellbeli állapotra az adott objektumot.

Ez nem jelenti azt, hogy ezeket a generált szkripteket mindenképpen le is kell futtatni az éles adatbázisban, csupán annyit jelent, hogy az alkalmazás képes a delta képzésre és ilyen DDL előállítására is.

A fejlesztőnek tehát ezen DDL-ek írásával sem kell külön időt töltenie, érdemes a modellező eszköz funkcióit kihasználni.

A DDL generáló funkciókon túl pedig mappingek átadására is az Exportáló funkciók szolgálnak.

A modellező eszköz specifikus extension-ök közül a lista szerű riportok arra készültek, hogy képesek legyenek a modellben található mapping-eket Excel formában kiexportálni.

Egy jól definiált mapping Excel alapján, a fejlesztő képes a töltőeljárások létrehozására.

Meg kell jegyezni azonban, hogy célszerű bevezetni a meglévők mellé új fejlesztési konvenciókat, amelyek a dokumentálási folyamatot leegyszerűsítik, teljesebbé teszik, és ezáltal a dokumentáció készítés automatizált használhatóságát kibővítik.

 Itt elsősorban olyan fejlesztési szabványokat szükséges kiemelni, melyek betartása mellett olyan forráskódok születnek, amik egy kód feldolgozó algoritmus számára is értelmezhetőek.

Például egy futásidőben épülő, szöveges változóba több forráskód soron keresztül összekonkatenált Insert utasítás egy ilyen alkalmazás számára nem értelmezhető, míg egy hagyományos módon megírt Insert utasítás könnyen parseolható és feldolgozható.

 Az alkalmazás által fel nem dolgozható SQL szkriptek modellező eszközben történő dokumentálására értelemszerűen csak kézi feldolgozás mellett van lehetőség.


Ez azt jelenti, hogy arányaiban minél több automatizáltan értelmezhető forráskód születik, az adatbázis mapping-jeinek annál nagyobb részét lehet a modellbe automatizáltan visszafrissíteni.


Mappingek esetében ki kell térni arra, hogy a mapping source és target oldali lábának is objektum szinten léteznie kell az adatmodellben ahhoz, hogy a mappinget definiálni lehessen a modellező eszköz adatmodellben.

A speciális mapping-ek esetében is - például amikor konstans értékből, vagy szekvencia alapján töltődik egy adott mező - szeretnénk tárolni az elérhető információkat.

Ennek kezelésére létrehoztunk egy speciális például VIRTUAL nevű adatmodell-t, melybe az ilyen speciális objektumokat hoztuk létre a minél teljesebb mapping töltés érdekében.










2020. február 24., hétfő

DWH konvenciok



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.