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

Stel, we willen een totaaloverzicht van de omzet, inclusief productgroepen. Dienstenomzet kan hierbij echter wegvallen, omdat diensten mogelijk niet als voorraadartikel staan ingesteld. Dit kan resulteren in een splitsing tussen Productomzet en Dienstenomzet. Om beide omzetgegevens te combineren, kunnen we Dienstenomzet koppelen aan de dimensie Product, maar dan op het hoogste niveau van de hiërarchie. Een andere optie is om een vangnet, zoals een dummy-artikel, toe te voegen om alle omzetgegevens onder één dimensie te houden.

Voorbeeld 2: Aantallen verscheept en aantallen geproduceerd

Stel dat we inzicht willen in de Aantallen Verscheept en Aantallen Geproduceerd. Hoewel beide gegevens betrekking hebben op producten, zorgt het verschil in tijdsdimensie voor complexiteit. De datum van verzending en productiedatum zijn immers niet hetzelfde. Verder kunnen productiegerelateerde dimensies, zoals de Productielijn, niet worden toegepast op het aantal verscheepte eenheden, wat leidt tot een mismatch.

Aanbevelingen:

• Zorg voor duidelijke definities
• Wees voorzichtig met Nonconforming Dimensions
• Probeer deze te vermijden

Hoewel Oracle BI technische oplossingen biedt, is het vaak effectiever om specifieke rapporten of analyses per onderwerp te maken. Door ze naast elkaar te tonen op een dashboard, behoud je overzicht zonder het model te compliceren.

Slowly Changing Dimensions

Een ander bekend fenomeen is Slowly Changing Dimensions. Neem bijvoorbeeld Omzet per Vertegenwoordiger. Dit gaat om de dimensie Account Manager in het omzetgebied. Maar wat gebeurt er met de omzet van een vertegenwoordiger als hij vertrekt en er een nieuwe vertegenwoordiger komt? Enerzijds wil je alle omzet van die klanten in beeld brengen, maar anderzijds wil je niet dat een nieuwe vertegenwoordiger direct miljoenen aan omzet krijgt toegewezen. Hetzelfde geldt voor omzet per klantregio: wat gebeurt er als een klant verhuist naar een andere regio?

Slowly Changing Dimensions stellen vragen die Oracle BI goed kan beantwoorden, mits de definities scherp zijn. Hier zijn vier veelvoorkomende vragen:

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

1. Wat is de omzet van regio Noord?

Met zulke heldere vragen wordt het eenvoudiger om antwoorden te vinden. Zo gaat vraag 1 over de huidige vertegenwoordiger en de totale omzet van die klanten, inclusief eerdere omzet. Bij vraag 2 willen we de omzet per vertegenwoordiger specifiek kunnen terugkijken, waarvoor we de dienstverbandperiodes nodig hebben.

Kimball schrijft vier mogelijke oplossingen voor:

1. Geen historie: vervang de waarde met de nieuwe situatie
2. Nieuwe regel met effectiviteitsdata
3. Nieuwe kolom om oude en nieuwe situatie te tonen (bijv. Actief/Niet Actief)
4. Een historietabel met de oude situatie

Bepaal eerst wat nodig is. Als tijd geen rol speelt, volstaat methode 1 vaak. Als tijd wél van belang is, moet Oracle JD Edwards rekening houden met datumgebaseerde relaties, zoals Account Manager relaties per datum. Niet alle aspecten hebben deze mogelijkheden, bijvoorbeeld bij Accounts Receivable-informatie. In een later artikel gaan we in op het opzetten van een Datawarehouse en de voordelen in dit kader.

Ragged- & Skipped Level Hierarchies

Een goede Nederlandse benaming is hier niet direct voor. Dit fenomeen kan zich voordoen in bijvoorbeeld organisatiestructuren en geografische indelingen. Neem bijvoorbeeld een geografische hiërarchie, opgebouwd uit de volgende niveaus:

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

In sommige landen of gebieden ontbreken bepaalde niveaus, zoals Straat of Huisnummer, bijvoorbeeld wanneer een locatie wordt aangeduid met GPS-coördinaten (zoals een akker). Als niet elk niveau altijd wordt ingevuld, spreken we van een Ragged Hierarchy.

Ook kunnen niveaus soms worden overgeslagen. Bijvoorbeeld: het niveau Staat bestaat wel in Amerika, maar niet in Nederland. Dit noemen we een Skipped Level Hierarchy.

Omdat deze situaties in de praktijk veel voorkomen en moeilijk in vaste regels te vangen zijn, biedt Oracle BI slimme technieken om ze goed te kunnen weergeven.

In de komende artikelen gaan we dieper in op deze onderwerpen, vooral wanneer we het hebben over datawarehousing.

Een BI-oplossing is meer dan alleen het installeren van software. De visie van Cadran draait om het leveren van de juiste informatie, precies op het juiste moment, aan de juiste mensen binnen jouw organisatie. Een zorgvuldige projectaanpak is cruciaal om valkuilen te vermijden. Business Intelligence gaat niet alleen om rapporten maken of mooie dashboards creëren. Het draait om het effectief managen van je organisatie, en Cadran staat naast je als partner in Business Intelligence en JD Edwards.

Neem contact met ons op

Auteur:  Rick Brobbel
BI Consultant bij Cadran Consultancy