Stervormige schema's en het belang van Power BI begrijpen

Dit artikel is bedoeld voor Power BI Desktop-gegevensmodelleerders. Het beschrijft het ontwerp van stervormige schema's en de relevantie voor het ontwikkelen van Power BI-gegevensmodellen die zijn geoptimaliseerd voor prestaties en bruikbaarheid.

Dit artikel is niet bedoeld om een volledige discussie te bieden over het ontwerp van stervormige schema's. Raadpleeg voor meer informatie rechtstreeks gepubliceerde inhoud, zoals The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3e editie, 2013) door Ralph Kimball en anderen.

Overzicht van stervormige schema's

Stervormig schema is een volwassen modelleringsbenadering die veel wordt gebruikt door relationele datawarehouses. Hiervoor moeten modelleerders hun modeltabellen classificeren als dimensie of feit.

Dimensietabellen beschrijven bedrijfsentiteiten, de dingen die u modelleerde. Entiteiten kunnen producten, personen, plaatsen en concepten bevatten, waaronder tijd zelf. De meest consistente tabel die u in een stervormig schema vindt, is een datumdimensietabel. Een dimensietabel bevat een sleutelkolom (of kolommen) die fungeert als een unieke id en beschrijvende kolommen.

Feitentabellen slaan waarnemingen of gebeurtenissen op en kunnen verkooporders, aandelensaldi, wisselkoersen, temperaturen, enzovoort zijn. Een feitentabel bevat dimensiesleutelkolommen die betrekking hebben op dimensietabellen en numerieke maateenheidkolommen. De dimensiesleutelkolommen bepalen de dimensionaliteit van een feitentabel, terwijl de dimensiesleutelwaarden de granulariteit van een feitentabel bepalen. Denk bijvoorbeeld aan een feitentabel die is ontworpen voor het opslaan van verkoopdoelen met twee dimensiesleutelkolommen Date en ProductKey. Het is gemakkelijk te begrijpen dat de tabel twee dimensies heeft. De granulariteit kan echter niet worden bepaald zonder rekening te houden met de dimensiesleutelwaarden. Houd er in dit voorbeeld rekening mee dat de waarden die zijn opgeslagen in de kolom Datum de eerste dag van elke maand zijn. In dit geval is de granulariteit op maandproductniveau.

Over het algemeen bevatten dimensietabellen een relatief klein aantal rijen. Feitentabellen kunnen daarentegen een zeer groot aantal rijen bevatten en na verloop van tijd blijven groeien.

Normalisatie versus denormalisatie

Om inzicht te hebben in enkele stervormige schemaconcepten die in dit artikel worden beschreven, is het belangrijk om twee termen te kennen: normalisatie en denormalisatie.

Normalisatie is de term die wordt gebruikt om gegevens te beschrijven die zijn opgeslagen op een manier die repetitious gegevens vermindert. Overweeg een tabel met producten met een kolom met unieke sleutelwaarden, zoals de productcode, en aanvullende kolommen met een beschrijving van productkenmerken, waaronder productnaam, categorie, kleur en grootte. Een verkooptabel wordt als genormaliseerd beschouwd wanneer alleen sleutels worden opgeslagen, zoals de productcode. In de volgende afbeelding ziet u dat alleen de kolom ProductKey het product registreert.

Als in de verkooptabel echter productdetails buiten de sleutel worden opgeslagen, wordt deze beschouwd als gedenormaliseerd. In de volgende afbeelding ziet u dat de kolommen ProductKey en andere productgerelateerde kolommen het product registreren.

Wanneer u gegevens uit een exportbestand of gegevensextract ophaalt, is het waarschijnlijk dat deze een gedenormaliseerde set gegevens vertegenwoordigt. In dit geval gebruikt u Power Query om de brongegevens te transformeren en vorm te geven in meerdere genormaliseerde tabellen.

Zoals beschreven in dit artikel, moet u streven naar het ontwikkelen van geoptimaliseerde Power BI-gegevensmodellen met tabellen die genormaliseerde feiten- en dimensiegegevens vertegenwoordigen. Er is echter één uitzondering waarbij een sneeuwvlokdimensie moet worden gedenormaliseerd om één modeltabel te produceren.

Relevantie van stervormige schema's voor Power BI-modellen

Stervormig schemaontwerp en veel gerelateerde concepten die in dit artikel zijn geïntroduceerd, zijn zeer relevant voor het ontwikkelen van Power BI-modellen die zijn geoptimaliseerd voor prestaties en bruikbaarheid.

Houd er rekening mee dat elke Power BI-rapportvisual een query genereert die naar het Power BI-model wordt verzonden (die door de Power BI-service een semantisch model aanroept, voorheen een gegevensset genoemd). Deze query's worden gebruikt voor het filteren, groeperen en samenvatten van modelgegevens. Een goed ontworpen model is dan een model dat tabellen biedt voor filteren en groeperen, en tabellen om samen te vatten. Dit ontwerp past goed bij de principes van stervormige schema's:

• Dimensietabellen ondersteunen filteren en groeperen
• Feitentabellen ondersteunen samenvatting

Er is geen tabeleigenschap die modelleerders hebben ingesteld om het tabeltype als dimensie of feit te configureren. Het wordt in feite bepaald door de modelrelaties. Een modelrelatie brengt een pad voor filterdoorgifte tussen twee tabellen tot stand en het is de eigenschap Kardinaliteit van de relatie die het tabeltype bepaalt. Een veelvoorkomende relatiekardinaliteit is een-op-veel of de inverse veel-op-een. De 'een'-zijde is altijd een dimensietabel, terwijl de 'veel'-zijde altijd een feitentabel is. Zie Modelrelaties in Power BI Desktop voor meer informatie over relaties.

Een goed gestructureerd modelontwerp moet tabellen bevatten die dimensietabellen of feitentabellen zijn. Vermijd het combineren van de twee typen voor één tabel. We raden u ook aan om te streven naar het juiste aantal tabellen met de juiste relaties. Het is ook belangrijk dat feitentabellen altijd gegevens met een consistente korrel laden.

Tot slot is het belangrijk om te begrijpen dat optimaal modelontwerp deel uitmaakt van wetenschap en kunst. Soms kunt u breken met goede richtlijnen wanneer het zinvol is om dit te doen.

Er zijn veel aanvullende concepten met betrekking tot het ontwerp van stervormige schema's die kunnen worden toegepast op een Power BI-model. Deze concepten zijn onder andere:

• Maatregelen
• Surrogaatsleutels
• Sneeuwvlokdimensies
• Dimensies voor rollenspel
• Langzaam veranderende dimensies
• Dimensies voor ongewenste e-mail
• Ontsaarde dimensies
• Feitentabellen zonder feiten

Metingen

In het ontwerp van een stervormig schema is een meting een feitentabelkolom waarin waarden worden opgeslagen die moeten worden samengevat.

In een Power BI-model heeft een meting een andere, maar vergelijkbare definitie. Het is een formule die is geschreven in DAX (Data Analysis Expressions) waarmee een samenvatting wordt bereikt. Metingexpressies maken vaak gebruik van DAX-aggregatiefuncties zoals SUM, MIN, MAX, AVERAGE, enzovoort om een scalaire waarderesultaat te produceren tijdens de query (waarden worden nooit opgeslagen in het model). Metingexpressie kan variëren van eenvoudige kolomaggregaties tot geavanceerdere formules die filtercontext en/of relatiedoorgifte overschrijven. Lees het artikel over DAX Basics in Power BI Desktop voor meer informatie.

Het is belangrijk om te begrijpen dat Power BI-modellen een tweede methode ondersteunen voor het bereiken van samenvattingen. Elke kolom, en meestal numerieke kolommen, kan worden samengevat met een rapportvisual of Q&A. Deze kolommen worden impliciete metingen genoemd. Ze bieden een gemak voor u als modelontwikkelaar, omdat u in veel gevallen geen metingen hoeft te maken. De kolom Sales Amount van Adventure Works-reseller kan bijvoorbeeld op verschillende manieren worden samengevat (som, aantal, gemiddelde, mediaan, min, max, enzovoort), zonder dat u een meting hoeft te maken voor elk mogelijk aggregatietype.

Er zijn echter drie aantrekkelijke redenen om metingen te maken, zelfs voor eenvoudige samenvattingen op kolomniveau:

• Wanneer u weet dat auteurs van rapporten query's uitvoeren op het model met behulp van MDX (Multidimensional Expressions), moet het model expliciete metingen bevatten. Expliciete metingen worden gedefinieerd met behulp van DAX. Deze ontwerpbenadering is zeer relevant wanneer een Query wordt uitgevoerd op een Power BI-gegevensset met behulp van MDX, omdat MDX geen samenvatting van kolomwaarden kan bereiken. MDX wordt met name gebruikt bij het uitvoeren van Analyseren in Excel, omdat in draaitabellen MDX-query's worden uitgevoerd.
• Wanneer u weet dat uw rapportauteurs gepagineerde Power BI-rapporten maken met behulp van de MDX-ontwerpfunctie voor query's, moet het model expliciete metingen bevatten. Alleen de MDX-ontwerpfunctie voor query's ondersteunt serveraggregaties. Dus als rapportauteurs metingen moeten laten evalueren door Power BI (in plaats van door de gepagineerde rapportengine), moeten ze de MDX-ontwerpfunctie voor query's gebruiken.
• Wanneer u ervoor wilt zorgen dat uw rapportauteurs alleen kolommen op specifieke manieren kunnen samenvatten. De kolom Verkoopeenheidsprijs van wederverkopers (die een tarief per eenheid vertegenwoordigt) kan bijvoorbeeld worden samengevat, maar alleen met behulp van specifieke aggregatiefuncties. Het mag nooit worden opgeteld, maar het is geschikt om samen te vatten met behulp van andere aggregatiefuncties zoals min, max, gemiddelde, enzovoort. In dit geval kan de modeller de kolom Eenheidsprijs verbergen en metingen maken voor alle geschikte aggregatiefuncties.

Deze ontwerpbenadering werkt goed voor rapporten die zijn geschreven in de Power BI-service en voor Q&A. Met liveverbindingen van Power BI Desktop kunnen rapportauteurs echter verborgen velden weergeven in het deelvenster Velden , wat kan leiden tot het omzeilen van deze ontwerpbenadering.

Surrogaatsleutels

Een surrogaatsleutel is een unieke id die u aan een tabel toevoegt om modellering van stervormige schema's te ondersteunen. Per definitie wordt deze niet gedefinieerd of opgeslagen in de brongegevens. Over het algemeen worden surrogaatsleutels toegevoegd aan relationele datawarehousedimensietabellen om een unieke id te bieden voor elke dimensietabelrij.

Power BI-modelrelaties zijn gebaseerd op één unieke kolom in één tabel, waarmee filters worden doorgegeven aan één kolom in een andere tabel. Wanneer een dimensietabel in uw model geen enkele unieke kolom bevat, moet u een unieke id toevoegen om de 'een'-kant van een relatie te worden. In Power BI Desktop kunt u deze vereiste eenvoudig bereiken door een Power Query-indexkolom te maken.

U moet deze query samenvoegen met de query aan de 'veel'-zijde, zodat u de indexkolom er ook aan kunt toevoegen. Wanneer u deze query's in het model laadt, kunt u vervolgens een een-op-veel-relatie tussen de modeltabellen maken.

Sneeuwvlokdimensies

Een snowflake-dimensie is een set genormaliseerde tabellen voor één bedrijfsentiteit. Adventure Works classificeert bijvoorbeeld producten op categorie en subcategorie. Producten worden toegewezen aan subcategorieën en subcategorieën worden op hun beurt toegewezen aan categorieën. In het relationele datawarehouse van Adventure Works wordt de productdimensie genormaliseerd en opgeslagen in drie gerelateerde tabellen: DimProductCategory, DimProductSubcategory en DimProduct.

Als u uw verbeelding gebruikt, kunt u de genormaliseerde tabellen uit de feitentabel weergeven en een sneeuwvlokontwerp vormen.

In Power BI Desktop kunt u ervoor kiezen om een ontwerp voor sneeuwvlokdimensie na te bootsen (mogelijk omdat uw brongegevens dat doen) of om de brontabellen te integreren (denormaliseren) in één modeltabel. Over het algemeen wegen de voordelen van één modeltabel op tegen de voordelen van meerdere modeltabellen. De meest optimale beslissing kan afhankelijk zijn van de gegevensvolumes en de bruikbaarheidsvereisten voor het model.

Wanneer u ervoor kiest om een sneeuwvlokdimensieontwerp na te bootsen:

• Power BI laadt meer tabellen, wat minder efficiënt is vanuit opslag- en prestatieperspectief. Deze tabellen moeten kolommen bevatten ter ondersteuning van modelrelaties en kunnen leiden tot een grotere modelgrootte.
• Langere doorgifteketens van relatiefilters moeten worden doorkruist, wat waarschijnlijk minder efficiënt is dan filters die worden toegepast op één tabel.
• Het deelvenster Velden bevat meer modeltabellen voor rapportauteurs, wat kan leiden tot een minder intuïtieve ervaring, met name wanneer tabellen met sneeuwvlokdimensie slechts één of twee kolommen bevatten.
• Het is niet mogelijk om een hiërarchie te maken die de tabellen omvat.

Wanneer u ervoor kiest om te integreren in één modeltabel, kunt u ook een hiërarchie definiëren die het hoogste en laagste deel van de dimensie omvat. Mogelijk kan de opslag van redundante gedenormaliseerde gegevens leiden tot een grotere modelopslag, met name voor zeer grote dimensietabellen.

Langzaam veranderende dimensies

Een langzaam veranderende dimensie (SCD) is een dimensie die de wijziging van dimensieleden in de loop van de tijd op de juiste manier beheert. Deze is van toepassing wanneer de waarden van bedrijfsentiteiten na verloop van tijd veranderen en op een ad-hoc manier. Een goed voorbeeld van een langzaam veranderende dimensie is een klantdimensie, met name de kolommen met contactgegevens, zoals e-mailadres en telefoonnummer. Sommige dimensies worden daarentegen beschouwd als snel veranderen wanneer een dimensiekenmerk vaak verandert, zoals de marktprijs van een aandelen. De algemene ontwerpbenadering in deze exemplaren is het opslaan van snel veranderende kenmerkwaarden in een feitentabelmeting.

Ontwerptheorie van stervormige schema's verwijst naar twee algemene SCD-typen: Type 1 en Type 2. Een dimensietabel kan Type 1 of Type 2 zijn, of beide typen tegelijk ondersteunen voor verschillende kolommen.

Type 1 SCD

Een SCD van type 1weerspiegelt altijd de meest recente waarden en wanneer wijzigingen in brongegevens worden gedetecteerd, worden de dimensietabelgegevens overschreven. Deze ontwerpbenadering is gebruikelijk voor kolommen met aanvullende waarden, zoals het e-mailadres of telefoonnummer van een klant. Wanneer een e-mailadres of telefoonnummer van een klant wordt gewijzigd, werkt de dimensietabel de rij van de klant bij met de nieuwe waarden. Het is alsof de klant altijd deze contactgegevens had.

Een niet-incrementele vernieuwing van een dimensietabel van een Power BI-model bereikt het resultaat van een SCD van type 1. De tabelgegevens worden vernieuwd om ervoor te zorgen dat de meest recente waarden worden geladen.

Type 2 SCD

Een SCD van type 2ondersteunt versiebeheer van dimensieleden. Als het bronsysteem geen versies opslaat, is het meestal het laadproces van het datawarehouse dat wijzigingen detecteert en de wijziging in een dimensietabel op de juiste manier beheert. In dit geval moet de dimensietabel een surrogaatsleutel gebruiken om een unieke verwijzing naar een versie van het dimensielid op te geven. Het bevat ook kolommen die de geldigheid van het datumbereik van de versie definiëren (bijvoorbeeld StartDate en EndDate) en mogelijk een vlagkolom (bijvoorbeeld IsCurrent) om eenvoudig te filteren op huidige dimensieleden.

Adventure Works wijst bijvoorbeeld verkopers toe aan een verkoopregio. Wanneer een verkoper een regio verplaatst, moet er een nieuwe versie van de verkoper worden gemaakt om ervoor te zorgen dat historische feiten gekoppeld blijven aan de voormalige regio. Ter ondersteuning van een nauwkeurige historische analyse van de verkoop door verkoper moet de dimensietabel versies van verkopers en hun bijbehorende regio's opslaan. De tabel moet ook waarden voor de begin- en einddatum bevatten om de geldigheid van de tijd te definiëren. Huidige versies kunnen een lege einddatum definiëren (of 12-31-9999), wat aangeeft dat de rij de huidige versie is. De tabel moet ook een surrogaatsleutel definiëren omdat de zakelijke sleutel (in dit geval werknemer-id) niet uniek is.

Het is belangrijk te begrijpen dat wanneer de brongegevens geen versies opslaan, u een tussenliggend systeem (zoals een datawarehouse) moet gebruiken om wijzigingen te detecteren en op te slaan. Het laadproces van de tabel moet bestaande gegevens behouden en wijzigingen detecteren. Wanneer een wijziging wordt gedetecteerd, moet het laadproces van de tabel de huidige versie verlopen. Deze wijzigingen worden vastgelegd door de waarde EndDate bij te werken en een nieuwe versie in te voegen met de Waarde Begindatum die begint met de vorige EndDate-waarde. Gerelateerde feiten moeten ook een op tijd gebaseerde zoekactie gebruiken om de dimensiesleutelwaarde op te halen die relevant is voor de feitendatum. Een Power BI-model dat Power Query gebruikt, kan dit resultaat niet produceren. Het kan echter gegevens laden uit een vooraf geladen SCD Type 2-dimensietabel.

Het Power BI-model moet ondersteuning bieden voor het opvragen van historische gegevens voor een lid, ongeacht de wijziging en voor een versie van het lid, die een bepaalde status van het lid in de tijd vertegenwoordigt. In de context van Adventure Works kunt u met dit ontwerp een query uitvoeren op de verkoper, ongeacht de toegewezen verkoopregio of voor een bepaalde versie van de verkoper.

Om deze vereiste te bereiken, moet de dimensietabel van het Power BI-model een kolom bevatten voor het filteren van de verkoper en een andere kolom voor het filteren van een specifieke versie van de verkoper. Het is belangrijk dat de versiekolom een niet-dubbelzinnige beschrijving biedt, zoals 'Michael Blythe (12-15-2008-06-26-2019)' of 'Michael Blythe (huidig)'. Het is ook belangrijk om rapportauteurs en consumenten te informeren over de basisprincipes van SCD Type 2 en hoe u geschikte rapportontwerpen kunt bereiken door de juiste filters toe te passen.

Het is ook een goede ontwerppraktijk om een hiërarchie op te nemen waarmee visuals kunnen inzoomen op het versieniveau.

Rollenspeldimensies

Een rolspeldimensie is een dimensie waarmee gerelateerde feiten anders kunnen worden gefilterd. In Adventure Works heeft de datumdimensietabel bijvoorbeeld drie relaties met de verkoopcijfers van de reseller. Dezelfde dimensietabel kan worden gebruikt om de feiten te filteren op orderdatum, verzenddatum of leveringsdatum.

In een datawarehouse is de geaccepteerde ontwerpbenadering het definiëren van één datumdimensietabel. Op het moment van de query wordt de 'rol' van de datumdimensie ingesteld door welke feitenkolom u gebruikt om de tabellen samen te voegen. Wanneer u bijvoorbeeld de verkoop per orderdatum analyseert, heeft de tabeldeelname betrekking op de kolom verkooporderdatum van reseller.

In een Power BI-model kan dit ontwerp worden geïmiteerd door meerdere relaties tussen twee tabellen te maken. In het voorbeeld van Adventure Works hebben de verkooptabellen voor datum en reseller drie relaties. Hoewel dit ontwerp mogelijk is, is het belangrijk om te begrijpen dat er slechts één actieve relatie tussen twee Power BI-modeltabellen kan zijn. Alle resterende relaties moeten worden ingesteld op inactief. Als u één actieve relatie hebt, betekent dit dat er een standaardfilterdoorgifte is van de verkoopdatum tot de reseller. In dit geval wordt de actieve relatie ingesteld op het meest voorkomende filter dat wordt gebruikt door rapporten, die in Adventure Works de orderdatumrelatie is.

De enige manier om een inactieve relatie te gebruiken, is door een DAX-expressie te definiëren die gebruikmaakt van de functie USERELATIONSHIP. In ons voorbeeld moet de modelontwikkelaar metingen maken om de verkoop van wederverkopers op verzenddatum en leveringsdatum mogelijk te maken. Dit werk kan tijdrovend zijn, met name wanneer de resellertabel veel metingen definieert. Er wordt ook een rommelig deelvenster Velden gemaakt, met een overmaat aan metingen. Er zijn ook andere beperkingen:

• Wanneer rapportauteurs afhankelijk zijn van het samenvatten van kolommen in plaats van metingen te definiëren, kunnen ze geen samenvatting bereiken voor de inactieve relaties zonder een meting op rapportniveau te schrijven. Metingen op rapportniveau kunnen alleen worden gedefinieerd bij het ontwerpen van rapporten in Power BI Desktop.
• Met slechts één actief relatiepad tussen datum- en resellerverkoop is het niet mogelijk om de verkoop van resellers tegelijkertijd te filteren op verschillende soorten datums. U kunt bijvoorbeeld geen visual maken waarmee de verkoop van orderdatums wordt uitgezet per verzonden verkoop.

Om deze beperkingen te verhelpen, is het maken van een dimensietabel voor elk rolspelexemplaren een veelgebruikte Power BI-modelleringstechniek. Normaal gesproken maakt u de extra dimensietabellen als berekende tabellen met behulp van DAX. Met behulp van berekende tabellen kan het model een datumtabel , een verzenddatumtabel en een leveringsdatumtabel bevatten, elk met één en actieve relatie met de kolommen van de respectieve resellerverkooptabellen.

Voor deze ontwerpbenadering hoeft u niet meerdere metingen voor verschillende datumrollen te definiëren en kunt u tegelijkertijd filteren op verschillende datumrollen. Een kleine prijs om te betalen, met deze ontwerpbenadering is echter dat er duplicatie zal zijn van de datumdimensietabel, wat resulteert in een grotere modelopslaggrootte. Aangezien dimensietabellen doorgaans minder rijen opslaan ten opzichte van feitentabellen, is dit zelden een probleem.

Bekijk de volgende goede ontwerpprocedures wanneer u modeldimensietabellen voor elke rol maakt:

• Zorg ervoor dat de kolomnamen zelf beschrijvend zijn. Hoewel het mogelijk is om een kolom Year in alle datumtabellen te hebben (kolomnamen zijn uniek binnen de tabel), is het niet zelfbeschrijfd voor visuele titels. Overweeg de naam van kolommen in elke dimensieroltabel te wijzigen, zodat de tabel Verzenddatum een jaarkolom heeft met de naam Ship Year, enzovoort.
• Zorg ervoor dat tabelbeschrijvingen feedback geven aan rapportauteurs (via knopinfo in het deelvenster Velden ) over de configuratie van filterdoorgifte. Deze duidelijkheid is belangrijk wanneer het model een algemeen benoemde tabel bevat, zoals Date, die wordt gebruikt om veel feitentabellen te filteren. In het geval dat deze tabel bijvoorbeeld een actieve relatie heeft met de kolom verkooporderdatum van de reseller, kunt u een tabelbeschrijving opgeven zoals 'Reseller sales by order date'.

Zie richtlijnen voor actieve versus inactieve relaties voor meer informatie.

Dimensies voor ongewenste e-mail

Een ongewenste dimensie is handig wanneer er veel dimensies zijn, met name bestaande uit enkele kenmerken (misschien één) en wanneer deze kenmerken weinig waarden hebben. Goede kandidaten zijn kolommen met orderstatussen of demografische kolommen van klanten (geslacht, leeftijdsgroep, enzovoort).

Het ontwerpdoel van een ongewenste dimensie is om veel 'kleine' dimensies samen te voegen in één dimensie om zowel de grootte van de modelopslag te verminderen als het deelvenster Velden overzichtelijker te maken door minder modeltabellen weer te geven.

Een tabel met ongewenste dimensies is doorgaans het Cartesische product van alle leden van het dimensiekenmerk, met een kolom met surrogaatsleutels. De surrogaatsleutel biedt een unieke verwijzing naar elke rij in de tabel. U kunt de dimensie bouwen in een datawarehouse of door Power Query te gebruiken om een query te maken waarmee volledige outer query-joins worden uitgevoerd en vervolgens een surrogaatsleutel (indexkolom) wordt toegevoegd.

U laadt deze query als een dimensietabel in het model. U moet deze query ook samenvoegen met de feitenquery, zodat de indexkolom wordt geladen in het model om het maken van een een-op-veel-modelrelatie te ondersteunen.

Gedegenereerde dimensies

Een degenereerde dimensie verwijst naar een kenmerk van de feitentabel die is vereist voor het filteren. Bij Adventure Works is het verkoopordernummer van de reseller een goed voorbeeld. In dit geval is het niet handig om een onafhankelijke tabel te maken die alleen uit deze ene kolom bestaat, omdat hiermee de opslaggrootte van het model wordt vergroot en het deelvenster Velden overzichtelijker wordt.

In het Power BI-model kan het handig zijn om de kolom verkoopordernummer toe te voegen aan de feitentabel om filteren of groeperen op verkoopordernummer toe te staan. Het is een uitzondering op de eerder geïntroduceerde regel dat u geen tabeltypen moet combineren (over het algemeen moeten modeltabellen dimensietype of feitentype zijn).

Als de verkooptabel Adventure Works-resellers echter kolommen met ordernummers en orderregelnummers bevat en ze vereist zijn voor het filteren, is een tabel met een ontaarde dimensietabel een goed ontwerp. Zie Richtlijnen voor een-op-een-relatie (Degenerate dimensions) voor meer informatie.

Feitentabellen zonder feiten

Een feitentabel bevat geen maateenheidkolommen. Deze bevat alleen dimensiesleutels.

Een feitentabel kan waarnemingen opslaan die zijn gedefinieerd door dimensiesleutels. Bijvoorbeeld op een bepaalde datum en tijd, een bepaalde klant die zich heeft aangemeld bij uw website. U kunt een meting definiëren om de rijen van de feitentabel te tellen om een analyse uit te voeren van wanneer en hoeveel klanten zich hebben aangemeld.

Een aantrekkelijker gebruik van een feitentabel is het opslaan van relaties tussen dimensies en het is de ontwerpbenadering van het Power BI-model die we aanbevelen om veel-op-veel dimensierelaties te definiëren. In een veel-op-veel-dimensierelatieontwerp wordt de feitentabel een overbruggingstabel genoemd.

Denk er bijvoorbeeld aan dat verkopers kunnen worden toegewezen aan een of meer verkoopregio's. De overbruggingstabel zou worden ontworpen als een feitentabel die bestaat uit twee kolommen: verkopersleutel en regiosleutel. Dubbele waarden kunnen in beide kolommen worden opgeslagen.

Deze veel-op-veel-ontwerpbenadering is goed gedocumenteerd en kan worden bereikt zonder een overbruggingstabel. De benadering van de overbruggingstabel wordt echter beschouwd als de best practice bij het relateeren van twee dimensies. Zie Richtlijnen voor veel-op-veel-relaties (twee dimensietabellen relateren) voor meer informatie.

Gerelateerde inhoud

Zie de volgende artikelen voor meer informatie over het ontwerpen van stervormige schema's of power BI-modellen:

• Wikipedia-artikel over dimensionale modellering
• Relaties maken en beheren in Power BI Desktop
• Richtlijnen voor een-op-een-relatie
• Richtlijnen voor veel-op-veel-relaties
• Richtlijnen voor bidirectionele relaties
• Richtlijnen voor actieve versus inactieve relaties
• Vragen? Vraag het Power BI-community
• Suggesties? Ideeën bijdragen om Power BI te verbeteren