Power BI proeftuin (2/3)

Inleiding

Microsoft timmert de laatste paar jaar enorm aan de weg met Power BI. Het product wordt maandelijks verrijkt met nieuwe functies en daarmee steeds beter. Dit wordt ook gezien door de markt en marktonderzoekers zoals Gartner met hun ‘magic quadrant for BI and Analytics’.

Dit artikel is het tweede in een serie van drie.

In dit artikel gaan we aan de hand van een demonstratie dataset (2 dimensionele modellen) aan de slag om in concrete stappen toe te werken naar bruikbare ‘analytics’.
Daarbij lopen we tegen praktische zaken aan, en zullen dan ook ingaan op de wijze waarop we die hebben aangepakt.

Alhoewel we soms een vergelijking maken met OBIEE, is dit artikel vooral niet bedoeld om de twee producten te vergelijken en een oordeel te geven. De vergelijking is vooral gedaan, omdat onze kennis en kunde van oorsprong ligt bij de Oracle technologie.

We willen in een serie van 3 artikelen vooral laten zien waar we tegenaan gelopen zijn bij lastiger onderwerpen, en hoe we dit hebben opgelost.

  • Artikel 1: Uitleg van de proeftuin en samenvatting bevindingen
  • Artikel 2: Modelleren en “shapen” van de data (dit artikel)
  • Artikel 3: Visualisaties maken en publicatie

Maken van het model

Het maken van het model is feitelijk het importeren van de data en definities (metadata) uit de technische bron. In deze proeftuin hebben we enkele tabellen in SQLServer staan. De data wordt dus ook ingelezen, en in-memory gezet. Dit is een belangrijke eigenschap van het tabular model, want daarmee wordt de snelheid van gegevens tonen in de rapporten aanzienlijk versneld. Je kunt overigens ook kiezen voor het inlezen van data op het moment dat deze nodig is.

Daarna kun je visueel de relaties tussen de verschillende tabellen leggen. Aangezien we in de proeftuin werken met een tweetal dimensionele modellen werken, leggen we N:1 relaties van de twee feittabellen naar de de dimensietabellen.


Op het moment dat je verwijst naar een sleutelveld in de dimensietabel controleert Power BI of de waarde uniek is. Overigens kun je in artikelen van diverse personen lezen dat dimensionele modellen nog steeds het beste uitgangspunt zijn voor tabular modellen. Dit is vooral door gedeelde data (common and conformed dimensions), waardoor je gemakkelijk feiten uit verschillende feittabellen kunt combineren.

Het is niet noodzakelijk om een aparte dimensietabel voor de tijd gereed te hebben staan, omdat Power BI op basis van een datum zelf bovenliggende niveaus als jaar, kwartaal en maand toevoegt. Maar in de praktijk blijkt het toch handiger om alsnog een dimensie te maken, omdat je dan meer vrijheid hebt in andere niveaus (week, trimester).

Een optie dbij de relaties is “cross-filtering”; deze laten we nu op de standaardwaarde staan. Zie dit artikel voor een nadere uitleg.

Gedeelde dimensies met ongelijke niveaus (common, non-conformed dimensions)

Een van de onderwerpen die we bij de uitwerking aan de kaak willen stellen zijn hoe we feiten bij elkaar brengen met dezelfde dimensie tijd, maar niet gelijke niveaus (actuals per dag, forecasts per maand). Het modelleren in het tabular model biedt daarvoor weinig ondersteuning. De enige optie die overblijft om beide feiten straks bij elkaar te tonen, is door de forecasts ook te koppelen aan dagen. Je moet dan voor een maand altijd een dag (1e of laatste) kiezen en deze gebruiken voor de “join”.

Als we dit vergelijken met de Oracle BI Suite, dan zien we dat dit product op dit gebied volwassener is.
Je kunt twee fysieke tabellen hebben in je model (tijd per dag en tijd per maand) en deze “mappen” op 1 logische dimensie tijd met 2 bronnen:

  • Dag die data kan leveren tot op de dag
  • Maand die data kan leveren tot aan maand en niet gedetailleerder. Dit is een soort geaggregeerde bron.

De Oracle BI Suite weet door de vraag die je stelt of hij kan lezen uit de geaggregeerde bron (jaar, kwartaal, maand), of data moet lezen uit de detailtabel (dagen).

Feiten niet gerelateerd aan dimensies

Dit is vooral een punt van aandacht voor later bij het maken van de visualisaties. Voor nu is het simpelweg niet “joinen” van forecasts aan product en medewerker/verkoper.

Afronden van het model

In deze stap worden allerlei technische kolommen nodig voor de joins verborgen gemaakt. Ook worden de datatypes – voor zover nog niet correct – goed gezet.
Power BI heeft de neiging om van elk numeriek attribuut, zoals jaar, direct een standaard sommatie te willen toepassen. Nu is een jaar een attribuut van een dimensie en geen meetwaarde, dus willen we in dit geval geen sommatie toepassen.

Het afronden van het model gaat vrij eenvoudig, en is vooral veel muisklik-werk. Een bulkactie om diverse kolommen in een keer verborgen te maken lijkt niet te kunnen.

Bij het maken van het model voegen we voor elke meetwaarde die we vanuit het model hebben bedacht een “measure” toe in het tabular model. Dit doen we met een simpele DAX formule als SUM(<feit>.<meetwaarde>). Het is niet noodzakelijk, alleen zorg je met het maken van measures voor eenvoud bij de business users. Nadeel is dat je hen beperkt tot de van te voren bedachte sommaties. Stel dat iemand een gemiddelde wilt, dan kan dat dus niet zomaar meer zonder de meetwaarde toe te voegen.

Het grote voordeel van het maken van measures is dat je altijd weet dat een meetwaarde uniek voor het complete model.

Voor de presentatie en snelheid van zoeken hebben we alle measures in een eigen nieuwe folder bij elkaar gezet.

De oorspronkelijke feittabellen met sales (actuals) en forecasts verbergen we dan vervolgens om verwarring te voorkomen.

Tot slot nog een kritische kanttekening: Het lastige in het afronden van het model is wel dat je niet eenvoudig folders van tabellen kunt groeperen of sorteren. Alles staat alfabetisch.

In deel 3 van dit artikel gaan we verder in op de datavisualisaties.

Reacties zijn gesloten.