Á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.
Megjegyzések
Megjegyzés küldése