Az adatmodell tervezés folyamata - A logikai adatmodell

Az adattárház bevezetés első lépéseként el kell döntenünk, hogy az adattárház adatmodelljét megvásároljuk-e (mert a piacon kaphatóak iparági sztenderd adatmodellek) vagy elkészítjük saját magunk. Mindkettőnek megvan a maga előnye, de ebben a szegmensben ahol én ügyködöm, nem igazán szoktunk adatmodellt vásárolni. Elsősorban azért mert nincs rá igény másodsorban azért, mert drága. Így a cikk további részében a vásárolt adatmodellekkel nem foglalkozonk. Jöjjön tehát az adattárház adatmodelljének tervezési folyamata.

Amikor hozzákezdünk egy 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.

Logikai adatmodell elkészítése

A logikai adatmodell tervezése előtt 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 vagy fogyasztókat az igényeikről.

Ezek után megfogjuk az igényfelmérések jegyzőkönyveit és a riportokat, és elkezdünk logikai adatmodellt tervezni. Ez a gyakorlatban úgy néz ki, hogy felírjuk egy „papírra", hogy mutatószámok (Measures) és elkezdjük a riportokról erre a lapra átmásolni a mutatókat. Lejegyezzük, hogy:

  • 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, ...

És még egy csomó mindent.

Ezután ugyanezt megcsináljuk az attribútumokkal is: elkezdjük őket is átmásolni egy üres lapra. (az attribútum a mutatószámok ismérvei: pl.: Szállítás napja, cikkcsoport neve, vevő címe, ...)

Ha ezzel is megvagyunk akkor előáll két lista: Az egyiken az összes mutatószám, a másikon az összes attribútum szerepel. Egyelőre ömlesztve, de hamarosan elkezdjük őket egységesíteni.

Az egységesítés során „konformizáljuk" a mutatókat (measures) és az attribútumokat is. Mondok egy példát: 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.

Vagy egy másik klasszikus példa az [értékesítés], [Ft], [Huf], [Total], [Bevétel], [bruttó bevétel], [árbevétel], és még sorolhatnám mutatószámok. Ezek mind ugyanazt az „értékesítés árbevétele"mutatót jelentik csak nincs még egységesítve a nevük. (És sokszor a számítási módjuk sem. Egyébként egy 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.)

És ha ezzel is megvagyunk, akkor már csak az attribútumokat kell dimenziókba rendezni. 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

Az attribútumok, dimenziók és mutatók együttesen meghatározzák már a táblák szerkezetét is. (Dátum dimenzió tábla az [Év], [hónap], [nap], ... oszlopokból fog állni, a vevő dimenziótábla a vevőcsoport, [vevő neve], [vevő címe], ... oszlopokból, és így tovább)

Arra kell csak figyelnünk 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.

A tervezésnek ebben a fázisban még nem kell foglalkozni teljesítménnyel. Az majd a fizika adatmodell elkészítése során lesz lényeges. De erről majd a jövő héten fogok részletesen írni.

Most még csak ott tartunk, hogy 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.

Update 2009. május 4: Időközben elkészült az adattárház fizikai adatmodell készítési folyamatát bemutató cikk is

Kővári Attila - BI projekt

hozzászólás

van abban igazság, hogy az adattárházat az igények oldaláról kell felfogni és megépíteni, de ami itt le van írva, az inkább az adatpiac modellezésére alkalmas, kevéssé az összes adatpiacot kiszolgáló adattárház tervezéséhez. Jóllehet, ez már vallási kérdés, hogy ki és mit ért adattárházon... Én maradok az Inmon féle modellnél, de jelzem, hogy Kimball sem gondolkodik alapvetően másképpen, csak a kifejezési formája más. Úgy is mondhatnám, hogy "piackonformabb" - ha létezik ilyen kifejezés. A Kimball-féle hozzáállás jobban eladható a Megrendelők részére és ezt szerintem Kimball is tudja :) Kimball esetében elsőre zavaró, hogy Ő az adattárházat rögtön a jelentéskészítés forrásának is tartja. Csak éppen technikailag beilleszt 1-2 olyan elemet, melytől az egész hirtelen hasonlítani kezd az Inmon féle modellre. Ezen nem lehet csodálkozni. Egész addig, amíg az adatkinyerés a jelentéskészítés legmeghatározóbb - értsd leglassúbb - eleme, addig ez így is lesz. Ha sebesség problémák nem lesznek, elképzelhető, hogy a normalizált modellre már csak view-kat, query-ket kell majd illeszteni és kész az adatpiac. Jelenleg azonban nem tartunk itt. Attila cikkéből alapvető dolgokat hiányolok: - egységes, vállalati adatmodell, mely valamennyi adatpiac adatforrása - a forrásrendszerek felmérése, azok belső szerkezetének - és ami még sokkal fontosabb -, üzleti tartalmainak és üzleti logikájának felmérése. Nem kell megijedni. Nem arról van szó, hogy rögtön teljes és tökéletes adattárházat építsünk. Csak arról van szó, hogy rögtön kialakítsuk a legfontosabb entitásokat, amelyeket szükség szerint attributumokkal töltünk fel. A szükség szerint azt jelenti, hogy ahogy az adatpiacoknak, jelentéseknek szükségük van rá. Tapasztalatom szerint ezzel a módszerrel lehet növekedésre képes adattárházat építeni gyorsan(!), mely hosszútávon váza lesz a cég adattárházának és képes kiszolgálni az összes adatpiacot. E nélkül az átgondolás nélkül csupán riportáló adatbázisunk lesz (akárhogy is nevezzük), amit cca 3-5 évenként újraépíthetünk, és korábbi tartalmait eldobhatjuk.

Kedves Gábor! Önnek teljesen igaza van. A cikk a Kimball féle csillagsémás adatmodellek tervezéséről szól. Inmon szerint az adattárház adatmodellje normalizált és erre építünk csillagsémás adatpiacokat. Ha ebben a kontextusban vizsgáljuk a cikket akkor tényleg hiányzik belőle az „egységes, vállalati adatmodell, mely valamennyi adatpiac adatforrása”. Kimball azonban máshogy gondolja. Ő szerinte az adattárház az adatpiacok összessége, és az adattárház adatmodellje csillagsémás, tehát nem szükséges alá olyan adatmodell, amely az adatpiacok forrása lesz. (Azt már csak halkan jegyzem meg, hogy ő is használ egy úgynevezett staging területet, ahol összevárja, összefésüli, tisztítgatja a különböző rendszerek adatait, és nem közvetlenül a forrásrendszerekből építkezik, de ez nem nevezhető egységes adatmodellnek) Forrásrendszerek felmérése. Itt Kimball megint kicsit másképp gondolkodik, mint Inmon. Kimball azt mondja, hogy mérjük fel az üzleti igényeket, abból építsük meg az adatmodellt és utána keressük meg hozzá a forrásrendszerekben a szükséges adatokat. A logikai adatmodell a Kimball féle metodológiát követve tehát még a forrásrendszerek felmérése nélkül készül. A forrásrendszerek ismeretére majd csak később, a fizikai adatmodell megtervezése során lesz szükségünk. Köszönöm, hogy eszembe juttatta, hogy az adattárház adatmodellje nem csak csillagsémás lehet. Erről néha el szoktam feledkezni.

Új hozzászólás