Role-playing dimension

Wat is een role-playing dimension?

Een role-playing dimension is één fysieke dimensietabel waar een feittabel meerdere keren naar verwijst, telkens in een andere rol. Elke rol heeft zijn eigen vreemde sleutel in de feittabel. Het klassieke geval is een datumtabel: één order kan een besteldatum, een verzenddatum en een leverdatum hebben, en alle drie wijzen ze naar dezelfde datumdimensie.

De term komt uit de Kimball-methode voor dimensioneel modelleren. Kimball omschrijft het als een dimensie die meerdere keren aangesproken wordt in een feittabel, waarbij elke verwijzing naar een logisch aparte rol wijst.

Vergelijk het met een acteur die in hetzelfde stuk drie personages speelt. Er is maar één acteur, maar op elk moment weet je welke rol hij invult. Zo hou je één zuivere datumtabel in plaats van drie bijna identieke kopieën.

Waarom niet gewoon drie datumtabellen?

Je zou voor elke datum een aparte tabel kunnen aanmaken, maar dan onderhoud je dezelfde feestdagen, boekjaren en weeknummers op drie plaatsen. Eén gedeelde datumtabel is een vorm van conformed dimension: dezelfde definitie geldt overal, dus "vorige maand" betekent hetzelfde of je nu op besteldatum of op leverdatum filtert. Welke rol de tabel invult, hangt af van welke sleutelkolom in de feittabel je gebruikt om te joinen.

Een voorbeeld op een ordersfeit

Neem een feittabel Orders met drie datumsleutels: BesteldatumId, VerzenddatumId en LeverdatumId. Alle drie verwijzen ze naar dezelfde tabel Datum.

• Vraag je "hoeveel omzet per besteldag?", dan join je op BesteldatumId.

• Vraag je "hoeveel pakketten per verzendweek?", dan join je op VerzenddatumId.

• Vraag je "gemiddelde tijd tussen bestellen en leveren?", dan gebruik je beide sleutels tegelijk.

Datums zijn het bekendste geval, maar het patroon geldt breder. Een feittabel Vluchten verwijst twee keer naar dezelfde luchthaventabel: één keer als vertrekluchthaven, één keer als aankomstluchthaven.

Hoe implementeer je het?

In een data warehouse of in SQL hou je één fysieke datumtabel en maak je per rol een aparte database-view of alias erbovenop: een view Datum, een view Verzenddatum, een view Leverdatum. Elke vreemde sleutel joint op zijn eigen view, zodat de rollen los van elkaar staan. Geef de kolommen in elke view sprekende namen (Verzendjaar in plaats van gewoon Jaar), anders weet niemand in een rapporttitel nog welke datum je bekijkt.

In Power BI heb je twee opties:

1. Meerdere relaties naar dezelfde tabel. Je legt drie relaties van Orders naar Datum, maar Power BI staat er maar één actief toe. De andere zet je op inactief. Per maat activeer je de juiste relatie met de DAX-functie USERELATIONSHIP, bijvoorbeeld een maat Omzet verzonden die de verzenddatum-relatie inschakelt. Handig als één rol overheerst, maar je krijgt snel veel maten en een drukke veldenlijst.

2. De datumtabel kopiëren per rol. Je maakt een Datum-, een Verzenddatum- en een Leverdatumtabel, elk met een eigen actieve relatie, via een verwijzende query in Power Query of een berekende tabel in DAX. Zo kan je in één visual tegelijk op besteldatum en verzenddatum filteren, zonder USERELATIONSHIP. Dat kost wat extra opslag, maar dimensietabellen zijn klein tegenover feittabellen, dus dat weegt bijna nooit door. Microsoft raadt deze aanpak aan zodra je rollen tegelijk moet filteren.

Waar moet je op letten bij het gebruik van een role-playing dimension

Een inactieve relatie propageert geen row-level security, ook niet met USERELATIONSHIP. Heb je RLS op je datumtabel, dan is de gekopieerde-tabel-aanpak veiliger.

Met één actieve relatie kan je niet tegelijk op twee rollen filteren. Wil je besteldatum tegen verzenddatum uitzetten in dezelfde grafiek, dan heb je aparte tabellen nodig.