Építsünk hierarchiákat?


A kilencvenes évek végén óriási csodának számított, hogy egy hierarchia mentén le lehetett fúrni a részletes adatokig. Akkortájt a hierarchiákkal el lehetett bűvölni az elemzőket és a vezetőket is, így annak idején sok hierarchiát építettünk.

Aztán jött a 21. század és észrevettem, hogy az elemzők egy részének már terhes a hierarchiák zárt világa. Ritkán használták a hierarchiákat és a lefúrás helyett szívesebben dolgoztak csak a hierarchiák szintjeivel. Hierarchiákat továbbra is építettünk, de már nem azért, hogy a felhasználókat elbűvöljük. Sokkal inkább azért, mert technikai-technológiai előnyei voltak illetve bonyolultabb kalkulációs illetve jogosultsági szabályokat könnyebb volt hierarchiák segítségével megfogalmazni.

Erre az időszakra tehát a kettősség volt a jellemző: A hagyományos többszintű hierarchiák mellett minden egyes hierarchia szintre építettünk egy külön attribútumot is. Így aki szerette a hierarchiákat, az továbbra is használhatta azokat, a technológiai előnyeit is ki tudtuk így használni, de az ügyesebb elemzők saját maguk is létre tudtak hozni elemzési (kvázi) hierarchiákat az attribútumok egymásba ágyazásával.

Nem sokkal később a felhasználók egyre határozottabban skandálták, hogy alternatív hierarchiákat szeretnének készíteni elemzéseikhez. És nem előre elkészített „alternatív " hierarchiákra gondolnak, hanem ad-hoc „alternatív" hierarchiára, ahol saját maguk határozhatják meg az aggregációs szinteket, szülő-gyerek kapcsolatokat. Természetesen akár a többmilliós vevő dimenzión is.

Kísérletezni persze kísérleteztünk az „ad-hoc alternatív" hierarchiákkal (Egy törzsadatkezelővel kombinált megoldásról írtam is) de átütő sikereket nem értünk el vele. Miért? Mert a felhasználók sokszor még ennél is rugalmasabb és gyorsabb megoldást várnak. Csakhogy erre a hagyományos diszk alapú adatbázis-kezelők nemigen alkalmasak. Még az OLAP sem. Ahhoz ugyanis, hogy a felhasználók által elvárt rugalmasságot biztosítsuk, minden adatnak a memóriában kell lennie.

Összefoglalva: Ha a felhasználók igényei kielégíthetőek előre elkészített, két betöltési ciklus között ritkán változó, szintjei számát tekintve fix hierarchiákkal, akkor építsünk hierarchiákat és használjuk az OLAP technológiát az adattárház fölött.

Ha viszont a felhasználók teljes szabadságra vágynak a hierarchiák és aggregációs csomópontok szerkesztésekor, akkor (is) építsünk hierarchiákat a relációs adattárhátban, de adjuk a felhasználók kezébe az alternatív hierarchiák létrehozásának és karbantartásának lehetőségét. Erre pedig a PowerPivot a legjobb eszköz.

ÖNKISZOLGÁLÓ BI WORKSHOP

Tudjon meg többet az itt elhangzottakról! Jöjjön el a 2017. szeptember 19.-i Önkiszolgáló BI workshopra. Részletek >>

  

POWER BI WORKSHOP

Tudjon meg többet az itt elhangzottakról! Jöjjön el a 2017. szeptember 5.-i Power BI workshopra. Részletek >>

  

Elválasztó

Már készül a következő cikk. Kérjen értesítést a megjelenéséről itt.

|

Szóljon hozzá!

Szabály: Legyen kedves, segítõkész és vállalja a nevét.
A mező tartalma nem nyilvános.
  • A web és email címek automatikusan linkekké alakulnak.
  • Engedélyezett HTML elemek: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • A sorokat és bekezdéseket automatikusan felismeri a rendszer.
ANTI SPAM
A robot regisztrációk elkerülésére.
Image CAPTCHA
Figyeljen a kis és nagybetűk használatára

POWER BI WORKSHOP

Tudjon meg többet az itt elhangzottakról! Jöjjön el a 2017. szeptember 5.-i Power BI workshopra. Részletek >>