BI – Speciale Dimensies

Alles te weten komen over BI & Analytics?

Cadran-analytics.nl is hier dé plek voor. Ontdek de mogelijkheden van Business Intelligence & Analytics tools om waardevolle inzichten te krijgen in uw data.

Bekijk andere BI & Analytics artikelen

Oracle BI – Overpeinzingen (4) – Cadran publiceert een reeks artikelen over het gedachtegoed rondom Oracle Business Intelligence in combinatie met Oracle JD Edwards. In deze artikelen komen diverse overwegingen en overpeinzingen aan bod, die behulpzaam kunnen zijn in het maken van de juiste beslissingen bij de implementatie en toepassing van beide systemen. In de voorgaande artikelen is ingegaan op het sterschema, feiten, dimensies en het samenspel tussen deze twee. In dit artikel wordt gekeken naar het doorbreken van het dwingende verband.

Dat er in eerste instantie een dwingend verband is, is een logisch gevolg van één van de design principles van dimensioneel modelleren. De relatie tussen feiten en dimensies wordt opgezet in het sterschema en daar is doorgaans sprake van een zogenoemde inner join. Of wel: een relatie tussen twee entiteiten moet bestaan om data te laten zien. Deze benadering heeft een aantal belangrijke voordelen:

• Consistentie en relevantie tussen de data
• Integratie van de data
• Beperkte ontwikkeltijd vanwege de eenvoud

Voor gewone analyses in Oracle BI is dit toereikend. Indien we de omzet per productgroep per jaar willen weten, zijn we niet geïnteresseerd in productgroepen zonder omzet in een bepaald jaar. En dan is het nog belangrijk om onderscheid te maken tussen geen omzet en nul omzet. Het laatste houdt in dat een productgroep een omzet van €0,- heeft (bijvoorbeeld omdat dit de groep is met de gratis producten).

Toch zal er in bepaalde gevallen behoefte zijn van deze stelregel af te wijken en informatie in een analyse te combineren, die puur theoretisch niet te relateren valt. Oracle BI heeft hier een aantal mechanismen voor die (ook weer) rechtstreeks aan de theorieën van Ralph Kimball zijn ontleend.

In het algemeen kan het fenomeen drastisch in omvang afnemen wanneer dimensies niet eindeloos worden uitgenormaliseerd. Wanneer een Sales Order regel onder klant Jansen valt en klant Jansen valt onder regio Noord, dan is hier snel sprake van het gevaar van Slowly Changing Dimensions. Valt een Sales Order zelf onder regio Noord, dan is het veel eenvoudiger omzet zuiver aan een regio toe te wijzen.

In Oracle JD Edwards is dit deels ondervangen doordat allerlei categoriecodes uit de stamdata naar de transactiedata worden doorgetikt. Denk hier bij aan allerlei Customer Master Attributen, die worden gerepliceerd naar de Order Header en allerlei Item Branch Category Codes, die worden gerepliceerd naar de orderregels. Wat aanvankelijk redundantie in Oracle JD Edwards lijkt, kan voor Oracle BI goed uitkomen.

Nonconforming Dimensions

Een dimensie als Product zal het liefst eenmalig en eenduidig zijn opgezet en kan dienst doen om meerdere onderwerpsgebieden te bedienen. Wat in Oracle JD Edwards het artikel is, komt immers voor in Inkoop, Verkoop, Productie en Voorraad. Dit vereist wel de bijbehorende eenduidige definitie van de dimensie Product. Is dit wel voor alle onderwerpsgebieden hetzelfde? Immers zal een grondstof wel in Inkoop, Productie en Voorraad worden gebruikt, maar niet in Verkoop. De schaal begint te glijden. We willen zoveel mogelijk een dimensie hergebruiken om tegen verschillende feiten te gebruiken, maar hierdoor kan het zijn dat een dimensie niet altijd de juiste gewenste relatie met feiten heeft.

Wanneer een dimensie niet altijd gelijkwaardig te relateren valt aan te combineren feiten, dan is er sprake van Nonconforming Dimensions. In Oracle BI zijn er technieken voor om dit te realiseren. Met deze technieken introduceren we wel de noodzaak tot zo mogelijk nog nauwkeurigere definities. Er wordt immers een interpretatie toegevoegd. Aan de hand van een voorbeeld proberen we dit duidelijk te maken.

Voorbeeld 1: Alle omzet

Indien we een omzetoverzicht willen met alle omzet en waar van toepassing de productgroep, maken we het mogelijk de omzet van bijvoorbeeld diensten mee te nemen. Er vanuit gaande dat deze diensten niet als Non Stock Item in de Item Master zijn opgezet, zullen deze wegvallen indien de dimensie Product erbij betrokken wordt. Indien dit niet gewenst is, dan krijgen we te maken met een tweedeling in feiten, te weten Productomzet en Dienstenomzet. Dit vindt mogelijk zijn herkomst ook op basis van verschillende definities. Willen we deze twee feiten combineren in een analyse, dan kan dat door de Dienstenomzet te relateren aan de dimensie Product, maar op het hoogste niveau van de hiërarchie. Zo wordt feitelijk deze dimensie omzeilt. Liever wordt hier een vangnet aangekoppeld, zoals een Non Stock Item of een dummy artikelnummer. Daardoor blijft de dimensie in volle waarde te gebruiken.

De waarde van diensten wordt hier nonconforming in de dimensie Product betrokken, zonder dat hier een product aan ten grondslag ligt.

Voorbeeld 2: Aantallen verscheept en aantallen geproduceerd

Stel dat inzicht gewenst is in de Aantallen Verscheept en de Aantallen Geproduceerd in de fabriek. Beiden laten zich waarschijnlijk uitstekend combineren in de dimensie Product, daar ze allebei over artikelen gaan. Toch is ook hier sprake van nonconforming dimensions. Allereerst wordt deze analyse bemoeilijkt door de dimensie Tijd. Wanneer bijvoorbeeld het jaar erbij betrokken wordt, zal het onmiddellijk over twee verschillende datums gaan, te weten Datum Verscheept versus Datum Geproduceerd. Deze zijn niet hetzelfde. Het wordt nog wat lastiger wanneer uit het onderwerpsgebied Productie, waarin de Aantallen Geproduceerd zitten, een specifieke dimensie wordt gebruikt, zoals Productielijn. Deze is niet toe te passen op de meetwaarde Aantallen Verscheept.

Aangezien Aantallen Verscheept niet te splitsen is naar de dimensie Productielijn zal het bovenstaande het resultaat zijn.

Aanbevelingen:

• Scherp de definities aan
• Wees voorzichtig met Nonconforming Dimensions
• Probeer deze te vermijden
• Ook al biedt Oracle BI hier een technische oplossing voor is het raadzaam deze niet in het model toe te passen

Een beter resultaat wordt verkregen door losse rapporten of analyses in Oracle BI te bouwen, die zuiver op een enkel onderwerpsgebied zijn ontworpen. Deze rapporten zijn eenvoudig naast of in elkaar te presenteren op een dashboard, waardoor toch het gewenste resultaat wordt verkregen, zonder het logisch informatiemodel hiervoor in bochten te wringen.

Slowly Changing Dimensions

Een serieuzer fenomeen is dat van Slowly Changing Dimensions. Een goed voorbeeld hiervan is Omzet per Vertegenwoordiger. Hier gaat het om de dimensie Account Manager of Sales Representative in het onderwerpsgebied Omzet. Het vraagstuk ontstaat wanneer een dergelijke dimensie van inhoud verandert. Indien een vertegenwoordiger uit dienst gaat en een nieuwe wordt aangenomen, wat gebeurt er dan met de oudere omzet van die klanten? Enerzijds is het gewenst dat alle omzet van de klanten van die vertegenwoordiger in beeld is. Anderzijds is niet gewenst dat deze vertegenwoordiger direct een omzet van miljoenen op zijn conto heeft staan. Een ander voorbeeld is Omzet per Klantregio. Wat gebeurt er met de omzet van een klant en van die regio, wanneer deze klant verhuist en zich in een andere regio vestigt?

Beide kwesties vallen onder de noemer van Slowly Changing Dimensions en zijn uitstekend door Oracle BI te beantwoorden, zolang de definities maar juist zijn. Welbeschouwd hebben we het hier over vier verschillende vraagstukken:

1. Wat is omzet van klanten van de huidige vertegenwoordiger?
2. Wat is de omzet van klanten van de vertegenwoordigers door de tijd heen?
3. Wat is de omzet van klant Jansen?
4. Wat is de omzet van regio Noord?

Wanneer deze vragen op deze manier zuiver worden gesteld, dient het antwoord zich ook aan. Bij vraag 1 is alleen de huidige vertegenwoordiger nodig, en wordt dus alle omzet van het verleden ook meegenomen, omdat het gaat om de omzet van die klanten. Bij vraag 2 willen we deze omzet verbijzonderen naar de vertegenwoordiger, die die omzet ook daadwerkelijk gerealiseerd heeft en zal de dienstverbandsperiode erbij betrokken moeten worden.

Kimball schrijft vier mogelijke oplossingen voor:

1. Geen historie: overschrijf nieuwe waardes en dus de huidige actuele situatie
2. Introduceer een nieuwe regel met effectiviteitsdata of geldigheidsdata
3. Introduceer een nieuwe kolom zodat oude en nieuwe situatie naast elkaar kunnen worden bevraagd (bv vlag Actief/Niet Actief)
4. Introduceer een historietabel en voedt dit met de oude situatie

Het is dus essentieel eerst goed te beoordelen wat nodig is voor welke informatiebehoefte. Wanneer historisch tijdsverloop geen kwestie is, kan meestal prima toe met methode1. Indien het tijdsaspect wel een kwestie is, dan zal daar in Oracle JD Edwards rekening mee gehouden moeten worden. Zo zullen bijvoorbeeld Account Manager relaties per datum opgezet moeten worden. Maar niet alle aspecten in Oracle JD Edwards hebben hier voorzieningen voor. Denk bijvoorbeeld aan Accounts Receivable informatie. In een later artikel zal ingegaan worden op de beweegredenen voor een Datawarehouse. Dit aspect komt dan in deze context nader aan de orde.

Ragged- & Skipped Level Hierarchies

Een goede Nederlandse benaming is hier niet direct voor. Dit fenomeen kan zich voordoen in bijvoorbeeld organisatiestructuren en geografie. Een voorbeeld wordt gegeven aan de hand van de geografische hiërarchie. Deze is herkenbaar te definiëren met de volgende niveaus:

• Continent
  • Land
    • Staat
      • Provincie
        • Stad
          • Postcode
            • Straat
              • Huisnummer

Het niveau Straat en Huisnummer komt in sommige landen of bij sommige adressen mogelijk niet voor (omdat de locatie mogelijk met GPS-coordinaten is aangeduid, zoals voor een akker ergens in de landerijen). Wanneer de lagere niveaus in een hiërarchie niet altijd bereikt wordt, is er sprake van Ragged Hierarchies.

Het niveau Staat komt in Nederland niet voor. In Amerika wel. Wanneer een tussenliggend niveau in een hiërarchie niet altijd van toepassing is, is er sprake van Skipped Level Hierarchies.

Omdat beide situaties in de praktijk voor kunnen komen, en mogelijk lastig in regels te vangen zijn, heeft Oracle BI hier vernuftige technieken voor, die het zeer goed mogelijk maken deze situaties te bedienen.

In hierna volgende artikelen zullen we nader ingaan op deze fenomenen, met name wanneer Datawarehousing wordt besproken.

De implementatie van een BI-oplossing is meer dan de implementatie van een softwareoplossing. De visie van Cadran is gericht op het bepalen van de juiste informatie, die op het juiste moment bij de juiste mensen in uw organisatie beschikbaar is. Daarbij is een gedegen projectaanpak zeer belangrijk om de valkuilen van een dergelijke implementatie te voorkomen. BI gaat namelijk niet over het ontwikkelen van rapporten of het creëren van mooie dashboards. BI gaat over het managen van uw organisatie en Cadran is uw partner als het gaat om Business Intelligence en JD Edwards.

Neem contact met ons op

Auteur:  Rick Brobbel
BI Consultant bij Cadran Consultancy