Az idősor kalkulációk dimenzió

Adott egy adatkocka, melyből kinyerhető, hogy mennyit értékesítettünk agy adott hónapban, negyedévben, évben.

De mennyit értékesítettünk az előző hónapig bezárólag összesen?

Az ehhez hasonló kérdések megválaszolásához olyan számított mezőt kell létrehoznunk, amely az előző hónapig kumulálja (halmozza) az értékesítési mennyiségeket.

1. ábra: Aktuális havi és YTD adatok

Definíciók: Kumulált, halmozott, Year to Date, YTD, ...

YTD: az év első napjától az aktuális napig terjedő időperiódus. (a Year to Date rövidítése). Az adott időszak teljesítményeinek összessége. A július 20.-i YTD érték megmutatja például, hogy a január 1.-től július 20.-ig összesen hány terméket értékesítettünk.

A mutatót leggyakrabban teljesítmények összehasonlítására használjuk. Olyan kérdéseket válaszolhatunk meg segítségével, mint a:

• hogyan állunk előző év azonos időszakához képest? Vagy:
• Hány százalékát teljesítettük eddig az éves tervnek?

A mutatónak természetesen létezik nem év elejétől halmozó (kumuláló) változata is:

• MTD: A hónap első napjától az aktuális napig terjedő időperiódus. (A Month to Date rövidítése.)
• QTD: A negyedév első napjától az aktuális napig terjedő időperiódus. (A Month to Date rövidítése.)

A YTD, MTD, QTD mutatók a kumulált mutatók egy speciális fajtája, melyek idősoron vannak értelmezve, és kezdőpontjuk rögzített időpont. (A kumulálás értelmezett bármilyen mennyiségi soron, tehát nem csak idősoron). Mégis, ha kumulált értékekről beszélünk, általában az év elejétől halmozott adatokat értjük rajta.

Kumulált (halmozott) számított mezőt könnyen létre tudunk hozni a YTD, PeriodsToDate, Lag MDX függvények segítségével. A kérdés csak az – és a cikk a továbbiakban erre fog fókuszálni – hogy hova, melyik dimenzióba tegyük a YTD (kumulált) számított mezőt.

YTD számított mező a Measures dimenzióba

Ha csak egy Measure-ünk van, például forint, akkor kielégítő megoldást kapunk, ha a YTD számított mezőt a Measures dimenzióba tesszük. (Lásd 1. ábra) Ha több measure-ünk van, mint például darab és forint, akkor measure-önként létre kell hoznunk egy-egy YTD számított mezőt: [YTD Darab], és [YTD Forint].

Tehát két vagy több measure esetén célszerű más módszert választanunk. Például tegyük be a YTD számított mezőt az idő dimenzióba, és akkor mind a Forint, mind a darab értékek vizsgálhatók egy YTD számított mező segítségével, hiszen előállítható vele a kumulált – darab, és a kumulált – forint dimenzióelem pár

YTD számított mező az időszak hierarchiába

Létrehozhatunk egy YTD számított mezőt az Idő hierarchiában is, ha felhasználóinkat csak és kizárólag a YTD aktuális értéke érdekli (nem érdekli őket például a 2 hónappal ezelőtti kumulált adat)

Ebben az esetben több measure-re is értelmezve lesz a YTD érték (pl.: kumulált forint és kumulált darab), de elvesztjük annak lehetőségét, hogy felhasználóink kumulált (YTD) adatokat vizsgálhassanak az aktuálistól eltérő hónapokra.

Ennél jobb megoldást kapunk, ha a YTD számított mezőt kitesszük egy külön dimenzióba

YTD számított mező az „Idősor kalkulációk” dimenzióba

Az UDM – Unified Dimension model – jelentős változásokat hozott ezen a téren (is). UDM előtt, a 2000-es Analysis Services-es a gyakorlat az volt, hogy a Year To Date és egyéb idősor kalkulációkat (Year over Year, …) külön dimenzióba tettük. Így a YTD értéket megvizsgálhattuk több measure-re, és több időpontra is.

Az idősor kalkulációk dimenzió

Az idősor kalkulációk dimenzió előnye az volt, hogy csak egyszer kellett létrehozni, s utána minden új kockát már csak dimenzionálhattunk vele.

De az időszak kalkulációk dimenzió két hátránnyal is járt: Egyrészt létre kellett hozni egy fiktív dimenziót és egy fiktív oszlopot a tény táblában, amelyen keresztül a fiktív dimenzió kapcsolódni tudott, másrészt nehezen jöttek rá maguktól a felhasználók, hogy hogyan állítsanak elő egy májusig kumuláló adatsort.

YTD számított mező az „Idősor kalkulációk” attribútumba

Az UDM megteremtette annak technológiai lehetőségét, hogy az idősor kalkulációkat (YTD, Year on Year, …) az idő dimenzió egy külön attribútumába tegyük, amivel több legyet ütünk egy csapásra:

Egyfelől nem kell fiktív dimenziót, fiktív ténytábla oszlopot létrehoznunk, másfelől elérjük mindazon felhasználói előnyöket, amelyeket a külön dimenzióban tárolás hoz magával, kiegészítve azzal, hogy a felhasználók az Idő dimenzióban találják az idősor (Year to Date) kalkulációkat.

[Update: 2008. július 9.] Találtam egy nagyon jó tanulmányt, ami pontosan leírja, hogy hogyan kell megcsinálni. Ő "shell" time dimenziónak nevezi, de ezt leszámítva egyről beszélünk.

Összefoglalva:

Véleményem szerint célszerű minden esetben az idősor kalkulációk attribútumot használni. Ez a legérthetőbb felhasználóink számára, s technológiai szempontból is ennek megvalósítása a leghatékonyabb. Ha egyszer megszokták a felhasználók hogy a YTD-et hol kell keresni, illetve hogy kell használni, onnantól kezdve gyerekjáték lesz számukra egy YTD-et tartalmazó riport előállítása.