PowerDesigner 6. Modellezés

 

Adattárházi modellezés (adatpiac építés)

 

Az adattárház bevezetés első lépéseként el kell döntenünk, hogy az adattárház központi adatmodelljét megvásároljuk-e (mert a piacon kaphatóak iparági sztenderd adatmodellek) vagy elkészítjük saját magunk.

Saját adattárház adatmodelljének megtervezéséhez, akkor először elkészítjük a logikai adatmodellt, majd ebből előállítjuk a fizikai adatmodellt is.

Specifikáció alapján egy számítógépes rendszer felépítése  a vízen járáshoz hasonlítható ... Sokkal könnyebb, ha be van fagyasztva

Logikai adatmodell elkészítése

A logikai adatmodell tervezéséhez fel kell mérnünk az üzleti igényeket.

Ez gyakorlatilag abból áll, hogy elkérjük az összes riportot, amit a jövőben az adattárházból akarnak előállítani, és lefolytatunk egy csomó interjút, ahol kifaggatjuk a leendő felhasználókat az igényeikről.

Ezek után megfogjuk az igényfelmérések megbeszélés jegyzőkönyveit, a riportokat, és elkezdünk logikai adatmodellt tervezni.

 

Általában a mutatószámokkal (Measures) és elkezdjük a kigyüjtést és egységes diefinició halmazba csoportosítjuk:

• Mi a mutató neve,
• Mi a definíciója,
• Mi a mértékegysége,
• Hogyan összegezzük fel az idő és más dimenziók mentén,
• Mi a képlete, ...

Majd ugyanezt megcsináljuk az attribútumokkal is a mutatószámok ismérvei alapján: pl.: Értékesítés napja, cikkcsoport neve, vevő címe, ...)

 

Az egységesítés során „konformizáljuk" a mutatókat (measures) és az attribútumokat is.

Pl.: A [bejelentés dátuma], a [keletkezés dátuma], a [rögzítés dátuma], [létrehozás dátuma] mind-mind ugyanazt a dátumot jelenti, csak ennyi féle néven nevezik a vállalatnál. Ekkor ezeket elnevezzük egységesen mondjuk [rögzítés dátuma]-nak és utána következetesen ezt használjuk mindenhol.

 

Az adattárház vagy egy üzleti intelligencia rendszer bevezetésének egyik legnagyobb hozzáadott értéke az lesz, hogy pontosan definiálva és egységesítve lesznek ezek mutatók, és mindenki azt fogja érteni rajtuk, amit valójában jelentenek.

 

Meg kell vizsgálni, hogy az egyes az attribútumokat kell-e, lehet-e dimenziókba rendezni.

Pl.: A dátum dimenzió attribútumai pl.: a hét, negyedév, hónap, év, ... lesznek. A vevő dimenziót a vevőcsoport, vevő neve, vevő címe, ... attribútumokból fogjuk felépíteni. Ezzel összeállnak az adattárház dimenziói is

 

Figyelni kell továbbá, hogy a logikai adatmodell tervezése során, hogy az adatmodell legyen:

1. Az üzleti felhasználók számára érthető, és könnyen használható
2. Az adatmodell fedje le a jelenlegi összes elemzési igényt, de legyen nyitott a jövőbeli igények kielégítésére is.

 

Tehát az összes üzleti igényt átforgattuk dimenziókká és mutatószámokká (measure), és ebből előállt egy olyan dokumentum amit logikai adatmodellnek hívunk.

Az elkészült egységesített logikai modellel elkészül egy BUS mátrix is, ami megmutatja, hogy az egyes mutatószámok milyen dimenziók mentén lesznek értelmezve.

 

 

 

Fizikai adatmodell elkészítése

 

A logikai adatmodell további finomítása (forrás rendszeri információk felhasználásával) kiegészítése az alábbi témákkal:

 - mező típus, hossz, pontosság, értékkészlet, kötelező töltöttség, adathiány kezelés szabályok

 - különböző tábla kulcs és adatforgató információk, megkötések és szabályok

 - hisztorizációs és státusz követő információk kezelése

 - kapcsolatok típusa, halmaz műveletek kezelése  (beágyazás, tartalmazás, ..)

 - adatbázis tábla indexelés, particionálás, tömörítés, analizálás lehetőségek felmérése 

 

Tehát a fizikai adatmodell elkészítésekor a célunk a logikai adatmodell finomítása, hogy az nagy adatmennyiségeket is hatékonyan kezeljen, gyorsan választ adjon az üzlet kérdéseire, tároljon minden változást historikusan, könnyű legyen karbantartani és üzemeltetni, stb.

 

PD különleges objektum kezelések:

A logikai adatmodellben létező, de fizikai adatmodellben máshogy megjelenő objektumok adatlapján jelölhetjük, hogy a LDM → PDM konverziónál ezt az elemet nem kell átvinni:

Például. egy-egy relációval rendelkező entitások vagy a logikai modellben néhány referencia-entitás.

Az entitást csak akkor lehet logikaiként megjelölni, ha belépünk a tulajdonság adatlapjára, és töröljük a „Generálás” jelölőnégyzet jelölését.

Ez biztosítja, hogy az összes ilyen entitást ne vegyük figyelembe az LDM → PDM átalakításakor.

Adattárházak általános architektúrája

 

STAGE (érkeztető 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 (konszolidációs 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
• technikai mezők: OBJ_TIPUS, FORRAS_AZON_1…5

 

DM (elemzések kiszolgáló területe)

• 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
• helygazdálkodás kérdése, visszamenőleges adattárolás

Fejlesztési folyamat és modell készítés összeföggése

Olyan DWH-s fejlesztési elem amely DW vagy DM objektumot annak tulajdonságán érint csak úgy élesedhet, ha a modell változtatások a megfelelő fizikai modellen is át vannak vezetve ill. a Modell felelős jóváhagyta.

Az adatváltozási jóváhagyás után, azonos érvényességi intervallumra jóváhagyott külön adat modell eltűnik az éles adatmodellből, mivel további tárolása fizikai szinten felesleges.

Az adatbázis a modellezett rendszer aktuális állapota mellett a múltbeli adatokat is tartalmazza visszakereshetően visszaállíthatóan.

 

A fizikai rendszertervnek legalább a következő tartalommal kell rendelkeznie:

• Szoftver környezet függőségek, a rendszer szoftver környezet függőségei;
• Tervezett modulok és eljárások: Név és magyarázat; az adott programozási környezet modulok, funkciók felsorolása, magyarázata.
• Szolgáltatási funkciók funkciók (elemzés, kimeneti kötött formátumú riportok, adat átadások),
• Adattöltéssel kapcsolódó alkalmazás funkciók
• Tábla terv és függőségek: Adatmodell, indexek, constraintek, egyedi kulcsok, idegen kulcsok.
• Adatáramlási terv: a rendszer által kezelt adatok forrásának és feldolgozási folyamatának részletes bemutatása,
• Folyamatok: Töltő folyamatok, bach folyamatok (nagy tömeges háttér feldolgozás, job-ok)
• Interfészek részletes fizikai specifikációja

 

Feladat és felelősség

A DWH rendszerszervező és Business analyst adatmodellező feladatot is ellát, feladata bővül az adattárház és az üzleti intelligencia rendszer adatmodelljének elkészítésével.

Ő az, aki az üzleti igényfelmérés eredménye alapján elkészíti a logikai majd a fizikai adatmodellt. Jellemzően részt vesz az üzleti igényfelmérésekben is.

 

Modellezés szempont rendszere

Az összes adatmodell elemre is értelmezhető az illeszkedés, a konformitás fogalma. Így a változók esetében is beszélhetünk összeférő változókról, amikor is az azonos változó elnevezés mögött azonos jelentés és azonos szerkezet húzódik meg az adattárház modell minden adatkockája esetén. 

 

Az adatelemzési igények feltárása után létrehozott adatmodelleket véleményezni kell, valamint használati esetekkel alátámasztott javaslatokat kell megadni.

 

 

 

Kapcsolatok minta: (HR séma részlet)

SqlDeveloperben így néz ki:

      Kék nyíl :  Minden dolgozó egy osztályon dolgozik

      Piros nyíl : Minen osztálynak van egy vezetője

      Zöld nyíl : Minden dolgozónak van egy vezetője (táblába visszaforduló nyíl)

PowerDesigner-ben pedig így néz ki:

Kapcsolatnál a a függés erőssége:

     Ha van kapcsolat a táblák között akkor folyamatos vonal (Mandatory), ha lehet akkor szaggatott vonal. (az ábrán láthatóság miatt kötelezőséget állítottam be)

     Az igazi modellben ez szaggatott vonal kellene ábrázolni, mert például van olyan dolgozó akinek nincs vezetője (vagy mert ő a legmagasabb szintű vezető, vagy mert még éppen kinevezés alatt áll a vezető [ezért nincs] )

Kapcsolat irányultság jelölése:

A kapcsolatokban szereplő egyedeket szerepük szerint nevezik még főegyednek vagy szülőnek, illetve alegyednek vagy gyereknek.
A logikai adatmodell szokásos ábrázolási módja szerint a „sok” oldalra nyílhegyet rajzolhatunk.
A nyíl hegye a főegyedtől az alegyed felé mutat.
A logikai adatmodell szokásos ábrázolási módja szerint a „sok” / N  oldal felé mutat a nyíl hegye. (Írányultság, kapcsolat jellege)

 

Pl.:

Típus szótár tábla felé nyílhegyek vannak           ←   TIPUS_DICT → 

History táblákból sok nyíl indul ki                       → VASARLAS_HIST ← 

Kapcsolat típusai

1 : 1  ==>  egy az egyhez kapcsolat

1 : n  ==>  egy a többhöz kapcsolat

n : n  ==>  több a többhöz kapcsolat  (külön kapcsoló táblára van még szükség a modellben)

 

 

Multidimenzios modell készítése

 

Fizikai modell táblák megjelölése melyikből lesz dimenzió tábla és melyikből ténytábla

Lépések

Bal felső sarokban ikonok jelennek meg a típusba sorolás szerint

Kocka generálás kiválasztása, végig OK-zás 

Generált multidimenziós modell

Minta modellek elérése : Link