Az adatmodell tervezés folyamata - A fizikai adatmodell

Mielőtt elhúzok 2 hétre az MVP Global Summit-ra mindenképpen szeretném pótolni egyik restanciámat. A legutóbbi adattárház adatmodell tervezéssel foglalkozó cikkben megígértem, hogy a logikai adatmodell tervezésének bemutatása után írni fogok pár sort a fizikai adatmodellről és az eszközökről is, amelyekkel az adattárház adatmodellje elkészíthető.

Mindez jó fél éve történt, és megmondom őszintén teljesen elfeledkeztem a dologról. Nemrégen azonban kaptam két levelet is a cikkel kapcsolatban - amiért nagyon hálás vagyok - és amelyek eszembe juttatták, hogy ez a téma bizony még nincs befejezve. Következzen hát a folytatás:

Az adattárház fizikai adatmodelljének elkészítése

Legutoljára ott hagytuk abba, hogy kész az adattárház logikai adatmodellje. Emlékeztetőül: a Logikai adatmodell tartalmazza az összes mutatószámot, dimenziót és hierarchiát, amit az igényfelmérések során azonosítottunk. Ezek megnevezése, számítási módja már egységesítve van és elkészült a BUS mátrix is, ami megmutatja, hogy az egyes mutatószámok milyen dimenziók mentén vannak értelmezve.

A célunk majd az lesz, hogy ez az egyelőre még csak „papíron" létező logikai adatmodell fizikailag is testet öltsön egy adatbázisban, azaz készüljenek el azok a táblák, amelyek az adattárház dimenzióit illetve mutatószámait tartalmazzák majd. (Ezt fogjuk majd fizikai adatmodellnek nevezni)

Ahhoz, hogy továbbléphessünk az adattárház fizikai adatmodelljének megvalósítása felé, el kell készülnie még forrásrendszerek felmérésének, és el kell készülnie a forrásrendszereket az adattárházzal összepároztató úgynevezett mapping dokumentumnak vagy leírásnak is

Míg az előbbi sok más mellett arra ad választ, hogy a forrásrendszerek milyen táblákat, oszlopokat tartalmaznak és azok adattípusa, kitöltöttsége milyen, addig a második azt mutatja meg, hogy milyen átalakításokon fog átmenni a forrásadat az adattárházig. Mondok egy bugyuta példát: Tegyük fel, hogy be kell töltenünk az adattárházba az árbevételt, ami a forrásrendszerekben, mint darab és egységár külön táblákban tárolódik. Ebben az esetben a mapping leírás az adattárház árbevétel oszlopára azt fogja tartalmazni, hogy

[ÉrtékesítésTábla].[Mennyiség] * [EgységárTábla].[Ft] where [ÉrtékesítésTábla].[CikkSzám] = [EgységárTábla].[CikkSzám]

Ezek után megnézzük a forrásrendszerek felmérését, és abból kikeressük, hogy milyen az egységár és a mennyiség mező adattípusa. Ha mondjuk az egységár tizedes tört, a mennyiség egész akkor e kettő szorzataként előálló árbevétel mező adattípusa az adattárházban szintén tizedes tört lesz.

Tudjuk már tehát, hogy az adattárházban szereplő táblák oszlopainak adattípusa milyen lesz az, hány tizedes jegyet tárol majd, stb. Ezek alapján már akár el is készíthetnénk az adattárház fizikai tábláit, de előtte még célszerű megvizsgálni, hogy a forrásrendszer felmérések során nem találunk-e olyan információkat, amelyeket az üzleti igényfelmérés nem hozott felszínre, de érdemes átemelni az adattárházba. (Tipikusan ilyenek a törzsekben tárolt egyéb leíró információk) Ha találunk ilyeneket, akkor azokkal még kiegészítjük az adattárház adatmodelljét

De nem csak új elemek jöhetnek be az adatmodellbe, hanem a forrásrendszerek felmérése során kiderülhet, hogy egy-egy mező tartalma bizony nem megbízható, kitöltöttsége nem megfelelő, adatai használhatatlanok, stb. s így nem tudjuk szerepeltetni az adattárházban. Ezen információk felszínre kerülése szintén módosíthatja az adattárház fizikai adatmodelljét.

Tegyük fel, hogy nem merültek fel ilyen problémák és a kezdeti adatmodellt nem kell módosítanunk. Az adattárház adatmodellje kész, már csak egy-két technikai kiegészítést kell tennünk, hogy előálljon a végleges fizikai adatmodell. Ezek a következők:

  • Ki kell egészíteni az adatmodell dimenzió tábláit egy mesterséges kulcs oszloppal (az adattárházban ezt fogjuk használni a dimenzió elemek azonosítására)
  • Ki kell egészíteni az adatmodellt az audit információk tárolására, vagy hivatkozására alkalmas oszloppal: Melyik forrásrendszerből jött az adott rekord, melyik betöltéssel került be az adattárházba, ...)
  • Elő kell állítani azokat a tábla, oszlop, stb tulajdonságokat (Extended property), amelyeket arra fogunk használni, hogy az adatmodell leíró információit tároljuk (Mapping kifejezések, példa értékek, leírások, szinonimák, ...)
  • A dimenzió táblákat ki kell egészíteni a historizáláshoz (rekordok verziózásához) használt információkkal (mettől meddig volt érvényes az adott dimenzióelem az adattárházban, most érvényes-e)
  • El kell készíteni azokat a nézet (view) definíciókat, amelyeken keresztül el fogják érni az üzleti felhasználók az adattárházat. (Nem erről szól ez a cikk, de le van benne írva, hogy miért kell definiálni nézeteket az adattárház fölé)
  • Meg kell határozni az adattárház kezdeti index stratégiáját
  • Dönteni kell, hogy melyik ténytáblát fogjuk partícionálni az adattárházban, és arról is, hogy mi alapján fogunk partíciókat képezni (Dátum, vagy esetleg valamilyen más jellemző keresése)
  • Dönteni kell az adatok tömörített vagy tömörítetlen tárolásáról

És kész. Ezzel előállt az adattárház fizikai adatmodellje is, ami jelen pillanatban még nem más, mint SQL utasítások sorozata. Ezeket az utasításokat lefuttatva megkapjuk majd az adattárházunk összes tábláját. Indexelve, partícionálva, vagy úgy ahogy az adatmodellben meghatároztuk.

Összefoglalás

A logikai adatmodell kialakítása során elsősorban az üzlet jelenlegi és jövőbenit igényei vesszük figyelembe. Célunk egy üzletileg jó adatmodell elkészítése, amely pont azt modellezi, ahogy az üzleti terület látja a vállalatát, ahogy az üzleti terület szeretné elemezni a vállalat mutatószámait.

Ezzel szemben 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.

A végére már csak egy kérdés maradt hátra: Mivel tervezzük az adatmodellt?

Adatmodell tervezést támogató szoftverek

  1. VISIO: Microsoftos környezetben egyből beugrik az embernek, hogy a Visio-val lehet szép adatmodell ábrát készíteni. Ám a Visio, - legalábbis az verziója ami az Office-szal együtt érkezik és ami mindenkinek megvan - , nem tudja az adatmodell változásait megvalósító scripteket előállítani. Azaz azt tudja, hogy az adatbázis alapján megrajzolja az adatmodellt (reverse engineering) de azt már nem, hogy a változásokat visszaírja az adatbázisba (forward engineering). Ahhoz, hogy a Visio oda vissza szinkronizálja az adatmodellt és az adatbázist meg kell vennünk a Visual Studio Enterpise Architect-et...
  2. ERWin: Kb. három éve teszteltem utoljára, de akkor még nem tudta az SQL Server 2005-ös adatbázisok illetve táblák és oszlopok tulajdonságait olvasni. Ha ERWin-t akar használni, akkor ennek mindenképpen nézzen utána, mert ezekre a tulajdonságokra nagy szüksége lesz az adatmodellezés során.
  3. PowerDesigner, E/R Studio, ...: Szintén elterjedt eszközök, de megmondom őszintén 10 éve nem használtam egyiket sem, úgyhogy nincs róla releváns tapasztalatom.
  4. Adatmodellező Excel táblázat: Kimball-ék csináltak egy kifejezetten adattárház adatmodell készítést támogató Excel fájlt, amivel könnyen tudunk adattárház adatmodellt tervezni. Igaz, hogy nem tudja szinkronizálni magát az adatbázisból, de nekem annyira kézre esik, hogy ezt használom mindig. Csak javasolni tudom Önnek is. (a fájl ingyenesen letölthető az MsftDWToolkit.com oldalról). Persze van az a projekt méret, ahol ezt már nem lehet használni, de a kezdeti adatmodell felépítésére a tökéletesen megfelel (Aztán majd visszafejtjük az adatmodellt a kiválasztott eszközzel az adatbázis alapján...)

Kapcsolódó anyagok:

Más. Hagy hívjam fel a figyelmét egy BI eseményre. Március 3-án a sugárban kerül megrendezésre az Informatika Tisztán Üzleti Intelligencia rendezvénye, amely az SQL 2008 üzleti intelligencia szolgáltatásait járja körül. A rendezvény ingyenes, de a regisztrációhoz kötött. Én sajnos nem tudok menni, mert ezidőtájt még javában Seattle-ben fogom hallgatni a következő SQL Server verzió újdonságait, de ha itthon lennék, biztos elmennék.

Kővári Attila - BI projekt

Új hozzászólás