Szülő/gyerek hierarchiák historizálása

Adott a következő feladat: építsünk hierarchiát az üzletkötő dimenzióra. Az üzletkötők viselkedéséről a következőket tudjuk:

1. Az üzletkötőknek vannak olyan mutatói, amelyet nem összegezhetünk fel a hierarchia mentén (pl. jövedelem. A vezető jövedelme nem egyenlő a saját plusz beosztottjai jövedelmével.
2. Nem tudjuk hány szintje van az üzletkötő hierarchiának, csak azt, hogy legalább 9. (Változó szintszámú hierarchia)
3. Az üzletkötők folyamatosan változtatják hierarchiabeli helyzetüket. Beérik majd megelőzik főnökeiket, visszaléptetik őket eggyel lejjebbi szintre és közben természetesen viszik magukkal a leszármazottaikat (saját rész struktúrájukat) is. Nekünk pedig folyamatosan nyomon kell tudnunk követnünk az üzletkötők vándorlását úgy, hogy bármilyen időpontra fel tudjuk rajzolni a hierarchiát

Az 1) és 2) pont miatt szülő/gyerek, (vagy az angol terminológiának megfelelően parent/child (PC)) dimenzióban kell gondolkodnunk, és a 3) pont miatt SCD TYPE 2 módszerrel kell majd nyomon követnünk az üzletkötők vándorlását.

Csakhogy e kettőt egyszerre megvalósítani nem nagyon lehet. A szülő/gyerek hierarchia ugyanis egy tisztán SCD TYPE 1-es historizációt lehetővé tevő dimenzió típus. (Az SCD type-ok ról a wikipédia itt ír)

Mit lehet ilyenkor tenni?

1. Odamegyünk az üzleti területhez és elmagyarázzuk nekik, hogy lehetetlent kérnek.
2. Kitalálunk valamit a lehetetlen megvalósítására.

Mivel ez utóbbi több eredménnyel kecsegtet, induljunk el rögtön ezen az úton.

Historizált szülő/gyerek dimenzió

Alapgondolat: Historizáljuk úgy a szülő/gyerek dimenziót, mint egy normál dimenziót: Ha valakinek megváltozik a szülője, akkor szúrjunk be neki egy új sort a dimenziótáblába. Vegyük például a következő esetet: Adott egy szervezeti hierarchia ahol Ausztrália a nyugati régióhoz tartozik: (A példát innen kölcsönöztem)

Kis idő elteltével a menedzsment úgy dönt, hogy Ausztrália mától fogva nem a nyugati régióba tartozik, hanem átkerül az Ázsia régióba. Ekkor új sort szúrunk be Ausztráliának:

Innentől kezdve pedig Ausztrália forgalma az ázsiai régióba kerül, de eddigi forgalma marad a Western régióban:

Remek. Pont ezt szeretnénk. Csakhogy a fenti módszer csak akkor működik, ha a levél szinten történik a változás. Ha már régió szinten kéne változtatni, akkor az új régiónak és összes leszármazottjának új mesterséges kulcsot kell adnunk, és újra be kell szúrnunk őket a dimenzió táblába.

Számoljunk. Tegyük fel, hogy egy vezető üzletkötő alá tartozik 200 üzletkötő. Most tegyük fel, hogy ez a vezető üzletkötő feljebb lép egyet a hierarchiában. Ebben az esetben 201 új sor kerülne a dimenziótáblába, hiszen neki is, és részstruktúrájának is új mesterséges kulcsot kéne adni. Belátható, hogy ez egy relatíve gyorsan változó üzletkötő hierarchiában olyan dimenzió elemszám növekedéshez vezet, ami hosszú távon kezelhetetlen lenne. Mást kell kitalálni

Diszkréten historizált (SCD Type 3) szülő/gyerek hierarchia

Ne kövessük nyomon az üzletkötők napi vándorlásait. Koncentráljunk arra, hogy hol voltak a hónapzárás pillanatában. No ez már egy olyan könnyítés, ami miatt megnyílnak más lehetőségek is:
Készítsünk minden hónap végén egy pillanatfelvételt az üzletkötő hierarchiáról.

Ebben az esetben az üzletkötő dimenziótábla a következő oszlopokat tartalmazná:

• Üzletkötő (gyerek)
• Üzletkötő (szülő)
• Üzletkötő (szülő most)
• Üzletkötő (szülő az előző hónap végén)
• Üzletkötő (szülő 2 hónappal ezelőtt)
• stb...

Ez a megoldás már jó lehet. De gondoljuk tovább a dolgot. Felléphet-e valamilyen technikai korlátozó tényező, ami miatt megdőlne a megoldás? (Akit nem érdekel az Analysis Services-es megvalósítás kérdése, az ugorjon rögtön a felsorolás utáni bekezdésre).

Nézzük meg milyen korlátai vannak szülő/gyerek dimenziónak Analysis Services-es megvalósítás esetén:

• Egy dimenzióban csak egy szülő/gyerek hierarchia lehet. Hát ez baj, de nem kizáró ok. szülő/gyerek hierarchiánként létrehozunk majd egy dimenziót
• A szülő/gyerek hierarchiát a kulcsoszlopból kell képeznünk (Nem csinálhatjuk meg pl. azt, hogy a mesterséges kulccsal kötjük a dimenziót a ténytáblához, és a természetes kulcsból építünk hierarchiát) Hát ez is probléma, de referencia dimenziókkal kikerülhetjük (Természetes kulcsokra építjük a szülő/gyerek hierarchiát és ezen természetes kulcson keresztül kapcsoljuk a mesterséges kulcsot tartalmazó dimenzióhoz. Úgy, mint a dátum dimenziót a belépés dátumán keresztül az üzletkötő dimenzióhoz)
• A szülő/gyerek hierarchiának nagyon rossz a felösszegzési és lekérdezési teljesítménye. Ok. Ez van.
• A szülő/gyerek hierarchiabeli elemére nehéz olyan MDX scriptet írni, amelyik a SCOPE, vagy Currentmember funkciókra alapoz. Ez később, a kalkulációknál jelenthet majd gondot, de a dimenzió tervezése szempontjából indifferens

A fentiekből következik, hogy a diszkréten historizált szülő/gyerek hierarchia, ha nyakatekerten is, de megvalósítható. Egyetlen negatívuma a megoldásnak, hogy a felhasználóknak el kell magyarázni, hogy ha július forgalmát akarják elemezni a júliusi struktúra szerint, akkor a dátum és struktúra dimenziókat is mozgatniuk kell. Persze ez így elmondva érthető, de a tapasztalat az, hogy a felhasználók zömének hosszú időbe telik míg megértik: a hierarchiák igazából csak aggregációs útvonalak. Ha ezt megértik, akkor már világos lesz számukra az is, hogy július forgalmát ki lehet mutatni a júliusi üzletkötő struktúra szerint is és a most éppen aktuális üzletkötő struktúra szerint is. Hol így hol úgy, függően a döntési problémától.

Összefoglalva: Gyakran változó szülő/gyerek dimenziók változásait folyamatosan nem tudjuk nyomon követni, mert egy csomópontbeli elem változásának hatására az elem alatt elhelyezkedő összes leszármazottnak új sort kéne beszúrnunk. Ez pedig olyan elemszám növekedéshez vezetne, amely hosszú távon nem lenne kezelhető. Alternatív megoldásként tehát marad a fent bemutatott SCD Type 3-hoz hasonlító, diszkréten historizáló módszer, vagy a szülő/gyerek hierarchia kiváltása (kiegyensúlyozatlan) hierarchiákkal.