In dit artikel richten we ons op het doorbreken van rigide verbanden. In eerste instantie lijkt een strikte verhouding logisch, als gevolg van een van de ontwerpprincipes van dimensioneel modelleren.
De relatie tussen feiten en dimensies wordt gedefinieerd in het sterschema en omvat doorgaans een ‘inner join’, wat betekent dat er een relatie moet bestaan tussen twee entiteiten om gegevens weer te geven. Deze aanpak heeft verschillende voordelen:
Voor standaardanalyses in Oracle BI is deze aanpak voldoende. Als we bijvoorbeeld de omzet per productgroep per jaar willen weten, zijn we niet geïnteresseerd in productgroepen zonder omzet in een specifiek jaar.
Bovendien is het belangrijk om onderscheid te maken tussen geen omzet en nul omzet. Het laatste geval houdt in dat een productgroep een omzet van €0,- heeft, bijvoorbeeld vanwege gratis producten.
Toch kan het in bepaalde gevallen nodig zijn om van deze regel af te wijken en gegevens te combineren die theoretisch niet gerelateerd zijn.
Oracle BI biedt hiervoor enkele mechanismen die rechtstreeks zijn afgeleid van de theorieën van Ralph Kimball.
Over het algemeen kan het probleem van dimensionale gegevens aanzienlijk worden verminderd als dimensies niet onnodig worden genormaliseerd.
Als een verkooporderregel valt onder klant Jansen en klant Jansen valt onder regio Noord, ontstaat het risico van ‘Slowly Changing Dimensions’. Als een verkooporder zelf rechtstreeks onder regio Noord valt, is het veel eenvoudiger om de omzet toe te wijzen aan een specifieke regio.
Oracle JD Edwards heeft dit deels opgelost door verschillende categoriecodes uit de stamgegevens over te dragen naar de transactiegegevens.
Dit omvat verschillende attributen van de klantenstamgegevens die worden gerepliceerd naar de orderheader en diverse categoriecodes van productbranches die worden gerepliceerd naar de orderregels. Wat aanvankelijk redundant lijkt in Oracle JD Edwards, kan gunstig zijn voor Oracle BI.
Een dimensie zoals ‘Product’ moet bij voorkeur eenduidig zijn opgezet en kan worden gebruikt voor meerdere onderwerpsgebieden.
Het komt immers voor in Inkoop, Verkoop, Productie en Voorraad. Dit vereist echter een consistente definitie van de dimensie ‘Product’. Maar geldt deze definitie voor alle onderwerpsgebieden?
Een grondstof wordt bijvoorbeeld gebruikt in Inkoop, Productie en Voorraad, maar niet in Verkoop. Hierdoor kan een dimensie niet altijd de gewenste relatie met feiten hebben.
Als een dimensie niet altijd direct kan worden gerelateerd aan gecombineerde feiten, spreken we van ‘Afwijkende Dimensies’.
Oracle BI biedt technieken om hiermee om te gaan. Dit introduceert echter de noodzaak van nog nauwkeurigere definities en een interpretatie. Een voorbeeld verduidelijkt dit:
Als we een overzicht van de totale omzet willen hebben, inclusief de omzet van diensten, moeten we ervoor zorgen dat de omzet van diensten wordt opgenomen.
Als deze diensten niet zijn opgenomen als Non Stock Item in de Item Master, worden ze uitgesloten wanneer de dimensie ‘Product’ wordt toegevoegd.
Als dit niet de bedoeling is, ontstaat een tweedeling in de feiten, namelijk Productomzet en Dienstenomzet.
Deze kunnen op verschillende definities zijn gebaseerd. Als we deze twee feiten in een analyse willen combineren, kan dat door de Dienstenomzet te relateren aan de dimensie ‘Product’, maar op het hoogste niveau van de hiërarchie.
Dit omzeilt effectief de dimensie. Het is raadzaam om hier een vangnet aan te koppelen, zoals een ‘Non Stock Item’ of een fictief artikelnummer, om de dimensie volledig te benutten.
Stel dat we inzicht willen in de aantallen verscheepte producten en de aantallen geproduceerde producten in de fabriek.
Beide kunnen waarschijnlijk goed worden gecombineerd in de dimensie ‘Product’, omdat ze betrekking hebben op artikelen. Toch zijn er afwijkende dimensies.
Het wordt gecompliceerder wanneer de dimensie ‘Tijd’ wordt toegevoegd. Bijvoorbeeld, als we het jaar toevoegen, zullen we te maken krijgen met verschillende datums, namelijk de verzenddatum versus de productiedatum. Deze datums zijn niet gelijk.
Het wordt nog complexer als we een specifieke dimensie uit het Productie-onderwerpgebied gebruiken, zoals ‘Productielijn’. Deze kan niet worden toegepast op de meetwaarde ‘Aantallen Verscheept’. Gezien deze complexiteit geeft Kimball vier mogelijke oplossingen:
Het is van cruciaal belang om de informatiebehoefte grondig te beoordelen voordat een keuze wordt gemaakt.
Als historische gegevens geen rol spelen, kan methode 1 meestal worden toegepast. Als het tijdsaspect wel van belang is, moeten dergelijke overwegingen worden geïmplementeerd in Oracle JD Edwards.
Dit fenomeen doet zich voor in bijvoorbeeld organisatiestructuren en geografie. Een voorbeeld wordt gegeven aan de hand van de geografische hiërarchie, die in niveaus kan worden opgesplitst:
In sommige landen of bij sommige adressen kunnen de niveaus ‘Straat’ en ‘Huisnummer’ ontbreken. Als lagere niveaus in een hiërarchie niet altijd worden bereikt, spreken we van ‘Ragged Hierarchies’.
Als een tussenliggend niveau in een hiërarchie niet altijd van toepassing is, spreken we van ‘Skipped Level Hierarchies’. Oracle BI biedt slimme technieken om met beide situaties om te gaan.
De implementatie van een BI-oplossing gaat verder dan alleen de implementatie van software. De visie van Cadran draait om het verstrekken van de juiste informatie aan de juiste mensen op het juiste moment.
Een gedegen projectaanpak is essentieel om valkuilen tijdens de implementatie te vermijden. BI gaat niet alleen over het ontwikkelen van rapporten of het creëren van prachtige dashboards. BI gaat over het effectief beheren van uw organisatie, en Cadran is uw partner voor Business Intelligence en JD Edwards.
