OBIEE Hiërarchieën (Oracle BI Enterprise Edition)

In januari 2011 is er een artikel geplaatst als introductie op OBI 11g. We hebben toen stil gestaan bij de opzet en het stappenplan om een repository in te richten.

Een van de meest opvallende nieuwe zaken bij het inrichten van repositories is het gebruik van hiërarchieën. De mogelijkheden voor de hiërarchieën ten opzichte van versie 10g zijn enorm verbeterd. In dit artikel gaan we daarom verder in op de verschillende soorten hiërarchieën en de toepassingen daarvan.

Hiërarchieën

In een BI omgeving worden hiërarchieën gemaakt bij de dimensies in het model. Het gebruik van hiërarchieën is vooral bedoeld voor eindgebruikers van de BI oplossing: Zij krijgen een of meer zoekpaden om in te zoomen op details.

Binnen OBIEE bestaat een dimensie uit een logische tabel en een object dimension. Bij de dimension worden de levels en hiërarchieën vastgelegd. De definities die u vastlegt zegt daarmee iets over de structuur van de achterliggende data.

De eerste optie (Time) geeft aan dat er sprake is van een tijdsdimensie. Door een dimensie als tijdsdimensie te specificeren, maakt u het mogelijk om met deze dimensie berekeningen uit te voeren op meetwaarden die betrekking hebben op “Time Series” (tijdsreeksanalyses).

De andere twee opties hebben betrekking op de opbouw van de data voor level based hierarchies. Eerst een toelichting, zodat direct duidelijk wordt waarvoor de optie ‘Ragged’ en ‘Skipped Levels’ dienen.

Voorbeelddimensie winkel – verkoper

Laten we als voorbeeld een dimensie winkel – verkoper nemen, waarbij sprake is van een level based hierarchy.

Vanuit het top level ALL kunt u via de REGION naar de STORE en CONCESSION (concessiehouder). Aan deze structuur is niets bijzonders.

Waar u dan blijkbaar impliciet een aanname voor doet, is dat de data in deze dimensie op alle niveaus altijd beschikbaar is. En dat is niet altijd de dagelijkse praktijk.

Ragged Hierarchies

Het kan namelijk best voorkomen dat er in bepaalde gevallen geen CONCESSIONs zijn voor een STORE. In dat geval ontstaat er een boomstructuur, waarbij de takken niet altijd even diep vertakt zijn.

In bovenstaande figuur ziet u een voorbeeld. Dit noemen we een “ragged hierarchy”.

Wanneer u de data opvraagt uit een relationeel dimensioneel model, dan zijn er vaak technische trucs toegepast om toch alle levels met data te vullen. Anders zou een ad-hoc querytool niet in staat zijn om goed te drillen op de beschikbare gegevens. Met de opties voor deze soort hiërarchieën zult u zien dat OBIEE toch in staat is om alle data op juiste wijze te presenteren, zoals in de multi-dimensionele wereld (MOLAP) gebruikelijk is.

Skip Level Hierarchies

In het voorbeeld rechts van deze tekst ziet u trouwens ook direct een voorbeeld van een “skip level hiearchy”.

Bij Skip Level Hierarchies is er sprake van het overslaan van een bepaald niveau, omdat deze knoop niet bestaat.

Bij skip level hierarchies is het toch noodzakelijk om ook de data te tonen indien een bepaalde knoop niet is ingevuld. Verder is het ook noodzakelijk om de gebruiker een juiste drill-down functionaliteit aan te bieden, zonder allerlei dummy gegevens voor ontbrekende knopen te moeten invullen.

Parent-Child Hiërachieën

Naast de eerder genoemde level-based hierarchies zijn er ook Parent-Child hiearchies te onderscheiden. Om dit type hiërarchie te maken dient u bij de keuze an het type dimensie al direct te kiezen voor een parent-child hierarhy.

Dit soort dimensies is ideaal voor boomstructuren, waarbij de diepte van het aantal vertakkingen (knopen) niet bekend is, zoals bij een organisatieboom. De wijze waarop deze de data van deze bomen wordt getoond is niet met behulp van benoemde levels (kolommen in een rapport), maar met behulp van 1 benoemd level met een variabel aantal onderliggende waarden. Zie het voorbeeld hiernaast.

Ook deze vorm van een dimensie kent zijn oorsprong uit de multi-dimensionele wereld.

Vervolgartikelen

In een van de volgende artikelen zullen we wat meer tijd besteden aan enkele van de stappen uit het inrichten van een OBI EE omgeving, zoals het toepassen van security.

Dit artikel is geschreven door Maarten Pauw, BI consultant en docent van onder andere de cursussen OBI Repository Design en Data Warehouse concepten.