Ralph Kimball dimenzionális adatmodellezése a ténytáblák három típusát határozza meg. Ezek:
- Tranzakciós ténytáblák.
- Periodikus pillanatfelvétel táblák, és
- Akkumulációs pillanatfelvétel táblák.
Ebben a bejegyzésben végigmegyünk a ténytáblák minden egyes típusán, majd elgondolkodunk azon, hogy ezek nem változtak az elmúlt években, mióta Kimball utoljára frissítette az Adattárház eszköztárat. Ha már ismeri a ténytáblák e három kategóriáját, ugorjon előre a végén található elemzéshez; ha nem, tekintse ezt a cikket a Kimball-stílusú adatmodellezés egyik alapvető összetevőjének tömör bemutatásának.
Két gyors megjegyzés, mielőtt elkezdenénk: először is, ez a cikk feltételezi a csillagséma ismeretét. Olvassa el, ha szüksége van egy alapozóra – feltételezem, hogy minimálisan érti a tény- és dimenziótáblákat. Másodszor, megjegyzem, hogy Kimball ismeri a ténytáblák negyedik típusát – a timespan ténytáblát -, de ez csak különleges körülmények között használatos. Ezt itt most kihagyjuk a tárgyalásból.
Tranzakciós ténytáblák
A tranzakciós ténytáblákat könnyű megérteni: egy ügyfél vagy üzleti folyamat csinál valamit; ennek a dolognak az előfordulását szeretnénk rögzíteni, ezért rögzítünk egy tranzakciót az adattárházban, és máris készen vagyunk.
Ezt egy egyszerű példával lehet a legjobban szemléltetni. Képzeljük el, hogy Ön egy kisboltot üzemeltet, és van egy elektronikus értékesítési pont (POS) rendszere, amely minden egyes eladást rögzít.
Egy tipikus Kimball-stílusú csillagsémában a sémája középpontjában álló ténytábla a rendelési tranzakciók adataiból állna. Ezek elsősorban olyan numerikus mérőszámok, mint a rendelés végösszege, a tételek összege, az eladott áruk költsége, az alkalmazott árengedmények összege és így tovább.
Azt láthatjuk tehát, hogy a tranzakciós ténytábla pontosan azt jelenti, amit a címében mond: kap egy tranzakciót, rögzíti a tranzakciót a ténytáblájában, és ez lesz a jelentés alapjául. Sok szempontból a tranzakciós ténytábla az alapértelmezett ténytábla-típus, amelyről gondolkodni szoktunk.
Periodikus pillanatfelvétel táblák
A periodikus pillanatfelvétel ténytáblák logikus kiterjesztése a sima vanília ténytábláknak, amelyekkel fentebb foglalkoztunk. Az időszakos pillanatfelvétel ténytáblák egy sora valamilyen időszakos adatot rögzít – például a pénzügyi mutatók napi pillanatfelvételét, vagy esetleg a követelések heti összefoglalóját, vagy a készletszámok havi összesítését.
Más szóval, a “szemcse” vagy a “felbontás szintje” az időszak, nem pedig az egyes tranzakciók. Vegyük észre, hogy ha egy bizonyos időszakban nem történik tranzakció, akkor új sort kell beszúrni az időszakos pillanatfelvétel táblába, még akkor is, ha minden elmentett tény nulla!
Az időszakos pillanatfelvétel táblák általában hihetetlenül sok mezőt tartalmaznak. Ennek az az oka, hogy bármilyen ésszerűen érdekes mérőszámot be lehet tolni a periódustáblába. Elképzelhetünk egy olyan forgatókönyvet, ahol egy heti időszak összesített értékesítésével, árbevételével és az eladott áruk költségével kezdünk, de az idő előrehaladtával a vezetőség megkéri, hogy adjunk hozzá más tényeket, például készletszinteket, számlafizetési mérőszámokat és más érdekes mérőszámokat.
Miért hasznosak az időszakos pillanatfelvétel táblák? Nos, ezt meglehetősen egyszerű elképzelni. Ha áttekintést szeretne kapni a vállalkozása kulcsfontosságú teljesítménymutatóinak trendvonalairól, akkor segít, ha lekérdezést végez egy periodikus ténytáblával szemben.
A felhalmozási pillanatfelvétel táblák
A periodikus pillanatfelvétel táblákkal ellentétben a felhalmozási pillanatfelvétel táblákat egy kicsit nehezebb elmagyarázni. Ahhoz, hogy megértsük, hogy Kimball és társai miért találták ki ezt a megközelítést, segít egy kicsit megérteni, hogy milyen kérdéseket tettek fel az üzleti életben a 90-es években, amikor a Data Warehouse Toolkitet először írták.
A 80-as évek végén a japán gyártók mindenféle kellemetlen, de nem nyilvánvaló módon kezdték megelőzni amerikai társaikat. Ezek közül a legfontosabb a végrehajtási sebességre való összpontosítás volt.
A gyártás lépések sorozatának tekinthető. A gyár egyik végén nyersanyagot veszünk, a másik végén pedig autókat, telefonokat és kütyüket gyártunk belőle. A gyártási folyamat minden egyes lépése mérhető – mennyi időbe telik például, amíg az acéltömbökből acélpellet lesz? Mennyi ideig várakoznak a gyár raktárkészletében? És onnan mennyi idő, amíg a pelletekből autóalkatrészeket gyártanak? Mennyi időbe telik, mire azokat tényleges autókban használják fel?
A 70-es évek végén a japán vállalatok kezdték felismerni, hogy az értékteremtésnek ez a “lépések sorozata” szemlélet komoly versenyelőnyhöz vezethet, ha csökkentik az egyes lépések közötti késleltetési időt. Konkrétabban: ha csökkenteni tudták az egyes tételek előállításához szükséges lépések számát, és ha csökkenteni tudták az egyes lépéseken belül eltöltött időt, a japán gyártók megtanulták, hogy csökkenthetik az anyagpazarlást, a hibaarányt és a szállítási időt, ugyanakkor növelhetik a dolgozók termelékenységét, növelhetik a gyártási volument, bővíthetik a termékválasztékot és csökkenthetik az árakat – mindezt egyidejűleg.
A 90-es évekre a nyugati vállalatok is rájöttek erre. Számos vezetési tanácsadó – köztük elsősorban George Stalk Jr. a Boston Consulting Grouptól – a végrehajtási tempót mint a versenyelőny forrását kezdte el hirdetni. Ezek a tanácsadók arra utasították a vállalatokat, hogy jegyezzék fel a gyártási folyamat minden egyes lépésére fordított időt. Amikor egy megrendelés beérkezett, mennyi időt kellett várni a feldolgozásra? Miután feldolgozták, mennyi ideig tartott, amíg a megrendelést elküldték a gyárba? A gyárban mennyi ideig tartott, amíg a termék elkészült? És aztán mennyi ideig várakozott a raktárban? És végül, mennyi időbe telt, amíg a vevő megkapta a terméket, és értéket kapott belőle?
A 90-es évek vállalkozásai így arra kényszerültek, hogy a teljes üzleti szállítási folyamatukban mérjék a késleltetési időt. Erre azért kényszerültek, mert a japán versenytársak számos, korábban a nyugati vállalatok által uralt iparágba betörtek – egyes esetekben csődöket okozva és egész ellátási láncokat felborítva. Kimball ebben a környezetben dolgozott.
A felhalmozódó pillanatfelvételek ténytáblázata tehát az üzleti folyamaton belüli sebesség mérésének módszere. Vegyük például ezt az üzleti csővezetéket, amelyet Kimball a The Data Warehouse Toolkit második kiadásában mutatott be:
Ezzel a folyamattal kapcsolatban Kimball a következő halmozódó pillanatfelvétel-táblázatot javasolta:
A táblázat minden sora egy rendelést vagy egy rendelési tételt jelöl. E sorok mindegyike várhatóan többször frissül a megrendelések teljesítési folyamatában. Figyeljük meg különösen a séma tetején található dátummezők nagy számát. Amikor egy sort először hozunk létre ebben a táblázatban, e dátumok többsége nullaként indul, de az idő múlásával végül feltöltődnek. (Megjegyzés: Kimball itt dátumdimenziós táblát használ a beépített SQL dátum adattípus helyett, mert ez a The Kimball Way ™ – ez lehetővé teszi, hogy több információt rögzítsen a dátumokkal kapcsolatban, mint a naiv dátumtípusok.)
Szintén fontosak a lista alján található mezők. Ezek mindegyike egy késleltetési mutatót mér – vagyis két dátum közötti különbséget. Így például a Order to Manufacturing Release Lag az Order Date-től Release to Manufacturing Date-ig eltelt idő; a Inventory to Shipment Lag az Finished Inventory Placement Date-tól Actual Ship Date-ig eltelt idő, és így tovább. Az idő múlásával ezeket a dátumokat egy ERP-rendszer vagy esetleg egy adatbeviteli munkás tölti ki. Az egyes megrendelésekhez tartozó késleltetési idők így az egyes mezők kitöltésekor kerülnek kiszámításra.
Elképzelhető, hogy egy ilyen táblázat hasznos lehet egy időalapú versenykörnyezetben működő vállalat számára. Egyetlen táblázat segítségével a vezetőség láthatná, hogy a termelésében a késleltetési idők az idő múlásával növekednek vagy csökkennek. Az ilyen üzleti intelligencia segítségével meghatározhatják, hogy mely lépések a legproblémásabbak a termelési folyamatukban. A számukra legaggasztóbb részekkel kapcsolatban pedig lépéseket tehetnek.
Mellékjegyzet: ezeket az ötleteket a szoftverek világára adaptálták a “lean” terminológia alatt; a technológiai vállalatokon belüli termelés mérésével kapcsolatos további információkért tekintse meg az Accelerate című könyvről szóló bejegyzéseinket itt és itt.
Miért nem változtak?
Kimball és társai érdeme, hogy a háromféle ténytáblázat nem változott lényegesen azóta, hogy 1996-ban először megfogalmazták őket.
Miért van ez így? A válasz szerintem abban rejlik, hogy a csillagséma valami alapvető dolgot ragad meg az üzleti életben. Ha úgy modellezi az adatait, hogy megfeleljenek az üzleti folyamatainak, akkor nagyjából háromféleképpen fogja rögzíteni a tényadatokat: tranzakciókon keresztül, összevont időszakokkal, és – ha a vállalkozás eléggé ért az időalapú versenyhez – az értékszolgáltatási rendszer egyes lépései közötti késleltetési idők mérésével.
Kimball maga is valami hasonlót mond. Egy 2015-ös blogbejegyzésében azt írja:
Ahelyett, hogy a logikai versus fizikai modellekről szóló vallásos vitákba bonyolódnánk, egyszerűen fel kellene ismernünk, hogy a dimenziós modell valójában egy adattárházi alkalmazásprogramozási interfész (API). Ennek az API-nak az ereje abban rejlik, hogy konzisztens és egységes felületet lát minden megfigyelő, mind a felhasználók, mind a BI-alkalmazások. Látjuk, hogy nem számít, hol tárolják a biteket, vagy hogyan szállítják azokat, amikor egy API-kérést indítunk.
A csillagséma időtálló. Ennyi nyilvánvaló.
Ugyanebben a bejegyzésben Kimball ezután azzal érvel, hogy ezen a tényen még az olyan közelmúltbeli újítások sem változtattak, mint az oszlopos adattárház; a vállalatok többsége, akikkel beszél, a nap végén még mindig egy dimenziós modellstruktúránál köt ki.
A dolgok azonban megváltoztak. Az Adattárház eszköztárban végigvonulnak a “táblánkénti tények számának korlátozása” és “az adatmodellezési stratégia megtervezése a megbeszélésen jelenlévő összes domain érdekelt fél részvételével” furcsa említései. Ezek nem tükrözik azt, amit a gyakorlatban látunk a vállalatunknál és az ügyfeleink adatosztályainál.
A legnagyobb változás az a sebesség, amellyel a jelenlegi technológiák lehetővé teszik számunkra, hogy a “naiv ténytábláról” a “Kimball-stílusú dimenziós modellre” váltsunk – ami lehetővé teszi számunkra, hogy kihagyjuk az előzetes modellezés gyakorlatát, és helyette úgy döntsünk, hogy csak annyit modellezünk, amennyit szükséges. Ezt a gyakorlatot számos technológiai változás teszi lehetővé, amelyeket már korábban is tárgyaltunk ezen a blogon (leginkább az OLAP-kocka felemelkedése és bukása című bejegyzésünkben), de a ténytáblák használatára gyakorolt gyakorlati hatásai a következők:
- Tranzakciós ténytáblák – tökéletesen elégedettek vagyunk a kövér ténytáblákkal, soronként több tucat, ha nem több száz ténnyel! Ez nem azt jelenti, hogy ez az ideális helyzet, csupán azt, hogy ez egy nagyon elfogadható kompromisszum. Kimball idejével ellentétben ma az adattehetség megfizethetetlenül drága; a tárolás és a számítási idő olcsó. Így teljesen rendben vagyunk azzal, hogy bizonyos ténytáblákat úgy hagyunk, ahogy vannak – sőt, több olyan táblánk is van, amelyekben több mint 100 mező van, egyenesen a forrásrendszerünkből! Filozófiai álláspontunk a következő: ha összetett jelentési követelményeink vannak, akkor érdemes időt szánni az adatok megfelelő modellezésére. De ha a jelentések, amelyekre szükségünk van, egyszerűek, akkor kihasználjuk a rendelkezésünkre álló számítási teljesítményt, és úgy hagyjuk a ténytáblákat, ahogy vannak.
- Időszakos pillanatfelvétel ténytáblák – meglepő, hogy mennyire képesek vagyunk elkerülni ezt. Mivel a modern MPP oszlopos adattárházak olyan erősek, nem hozunk létre periodikus pillanatfelvétel ténytáblákat a kevésbé rendszeresen használt jelentésekhez. A lekérdezés végrehajtási ideje és a jelentések nyers tranzakciós adatokból történő létrehozásához szükséges többletköltségek tökéletesen elfogadhatóak, különösen, ha tudjuk, hogy a jelentésre csak hetente egyszer van szükség (vagy időszakos feltárásra bocsátjuk). Más adathalmazok esetében Kimball eredeti ajánlásainak megfelelően időszakos pillanatfelvétel-táblákat készítünk.
- Pillanatfelvétel-táblák felhalmozása – Ez szinte változatlan Kimball idejéhez képest. De – ahogy maga Kimball is mondja – a felhalmozó pillanatkép-táblák a gyakorlatban ritkán fordulnak elő. Ezért mi nem foglalkozunk ezzel olyan sokat, mint egy időorientáltabb vállalat tenné.
Itt fontos megjegyezni, hogy a modellezést fontosnak tartjuk. A különbség az, hogy az adatelemzési gyakorlatunk lehetővé teszi számunkra, hogy a jövőben bármikor felülvizsgáljuk a modellezési döntéseinket. Hogyan tesszük ezt? Nos, a nyers tranzakciós adatainkat betöltjük az adattárházunkba, mielőtt átalakítanánk. Ezt nevezzük “ELT”-nek, szemben az “ETL”-el. Mivel az összes transzformációt az adattárházon belül végezzük el, egy adatmodellezési réteg segítségével, szükség esetén képesek vagyunk felülvizsgálni döntéseinket és átalakítani adatainkat.
Ez lehetővé teszi számunkra, hogy először az üzleti érték előállítására összpontosítsunk. Ez alacsonyan tartja az adatmodellezéssel járó foglalatosságot.