gebeurtenis
31 mrt, 23 - 2 apr, 23
De ultieme Microsoft Fabric-, Power BI-, SQL- en AI-communitygebeurtenis. 31 maart tot 2 april 2025.
Zorg dat u zich vandaag nog registreertDeze browser wordt niet meer ondersteund.
Upgrade naar Microsoft Edge om te profiteren van de nieuwste functies, beveiligingsupdates en technische ondersteuning.
Dit artikel is bedoeld voor Power BI Desktop-gegevensmodelleerders. Het beschrijft het ontwerp van een stervormig schema en de relevantie voor het ontwikkelen van semantische Power BI-modellen die zijn geoptimaliseerd voor prestaties en bruikbaarheid.
Belangrijk
Semantische Power BI-modellen zijn afhankelijk van Power Query om gegevens te importeren of er verbinding mee te maken. Dit betekent dat u Power Query moet gebruiken om de brongegevens te transformeren en voor te bereiden. Dit kan lastig zijn wanneer u grote gegevensvolumes hebt of als u geavanceerde concepten moet implementeren, zoals langzaam veranderende dimensies (verderop in dit artikel beschreven).
Wanneer u deze uitdagingen te zien krijgt, raden we u aan eerst een datawarehouse te ontwikkelen en ETL-processen (Extract, Transform and Load) te ontwikkelen om het datawarehouse periodiek te laden. Uw semantische model kan vervolgens verbinding maken met het datawarehouse. Zie Dimensionale modellering in Microsoft Fabric Warehouse voor meer informatie.
Tip
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.
Stervormig schema is een volwassen modelleringsbenadering die veel wordt gebruikt door relationele datawarehouses. Hiervoor moeten modelleerders hun modeltabellen classificeren als dimensie of feit.
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 Date
kolom 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 groot aantal rijen bevatten en na verloop van tijd blijven groeien.
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 een unieke sleutelwaarde, zoals de productcode en andere kolommen die productkenmerken beschrijven, zoals 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 ProductKey
kolom 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 ProductKey
en andere productgerelateerde kolommen het product vastleggen.
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 semantische Power BI-modellen met tabellen die genormaliseerde feiten- en dimensiegegevens vertegenwoordigen. Er is echter één uitzondering waarbij een sneeuwvlokdimensie kan worden gedenormaliseerd om één modeltabel te produceren.
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 semantische Power BI-model wordt verzonden. Over het algemeen filteren query's, 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:
Er is geen tabeleigenschap die modelleerders hebben ingesteld om het tabeltype in te stellen als dimensie of feit. Het wordt in feite bepaald door de modelrelaties. Een modelrelatie brengt een pad voor filterdoorgifte tussen twee tabellen tot stand en het is de kardinaliteitseigenschap 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.
Een goed gestructureerd modelontwerp bevat tabellen die dimensietabellen of feitentabellen zijn. Vermijd het combineren van de twee typen voor één tabel. We raden u ook aan om het juiste aantal tabellen met de juiste relaties te leveren. Het is ook belangrijk dat feitentabellen altijd gegevens laden met een consistente korrel.
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 concepten met betrekking tot het ontwerp van stervormige schema's die kunnen worden toegepast op een semantisch Power BI-model. Deze concepten zijn onder andere:
In het ontwerp van een stervormig schema is een meting een feitentabelkolom waarin waarden worden opgeslagen die moeten worden samengevat. In een semantisch Power BI-model heeft een meting een andere, maar vergelijkbare definitie. Een model ondersteunt zowel expliciete als impliciete metingen.
SUM
, MIN
, MAX
, en AVERAGE
andere om een scalaire waarderesultaat te produceren op het moment van query 's (waarden worden nooit opgeslagen in het model). Metingexpressie kan variëren van eenvoudige kolomaggregaties tot geavanceerdere formules die filtercontext en/of relatiedoorgifte overschrijven. Lees voor meer informatie over DAX Basics in Power BI Desktop.Sales Amount
kan bijvoorbeeld op verschillende manieren worden samengevat (som, aantal, gemiddelde, mediaan, min, max en andere), zonder dat u een meting hoeft te maken voor elk mogelijk aggregatietype.In het deelvenster Gegevens worden expliciete metingen vertegenwoordigd door het rekenmachinepictogram terwijl impliciete metingen worden weergegeven door het sigmasymbool (∑).
Er zijn echter drie aantrekkelijke redenen waarom u metingen kunt maken, zelfs voor eenvoudige samenvattingen op kolomniveau:
Wanneer u weet dat uw rapportauteurs een query uitvoeren op het semantische model met behulp van MDX (Multidimensional Expressions), moet het model expliciete metingen bevatten. Dat komt doordat 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 semantische 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 wilt bepalen hoe uw rapportauteurs kolommen op specifieke manieren samenvatten. De kolom resellerverkoop Unit Price
(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 of gemiddelde. In dit geval kan de modeller de Unit Price
kolom 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 Gegevens , wat kan leiden tot het omzeilen van deze ontwerpbenadering.
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.
Semantische Power BI-modelrelaties zijn gebaseerd op één unieke kolom in één tabel, die filters doorgeeft aan één kolom in een andere tabel. Wanneer een dimensietabel in uw semantische 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 bereiken door een Power Query-indexkolom toe te voegen.
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 laadt in het semantische model, kunt u vervolgens een een-op-veel-relatie tussen de modeltabellen maken.
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 de brontabellen te combineren om één gedenormaliseerde modeltabel te vormen. 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:
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 grote dimensietabellen.
Een langzaam veranderende dimensie (of 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 waarden van bedrijfsentiteiten langzaam in de loop van de tijd veranderen op een niet-geplande manier. Een goed voorbeeld van een SCD is een klantdimensie, omdat de kolommen met contactgegevens, zoals e-mailadres en telefoonnummer, onregelmatig worden gewijzigd. Sommige dimensies worden daarentegen als snel gewijzigd 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.
Een SCD van type 1 weerspiegelt 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 het type 1. De tabelgegevens worden vernieuwd om ervoor te zorgen dat de meest recente waarden worden geladen.
Een SCD van type 2 ondersteunt 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 elke verkoper 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 (of 31-31-9999) definiëren die aangeeft dat de rij de huidige versie is. De tabel moet ook een surrogaatsleutel hebben omdat de bedrijfssleutel (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 EndDate
waarde bij te werken en een nieuwe versie in te voegen met de StartDate
waarde 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 semantisch Power BI-model maakt gebruik van Power Query en kan dit resultaat dus niet produceren. Het kan echter gegevens laden uit een vooraf geladen SCD Type 2-dimensietabel.
Tip
Zie Historische wijziging beheren voor informatie over het implementeren van een SCD-dimensietabel van Type 2 in een Fabric-magazijn.
Het semantische 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 op 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 semantische 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 bevat, zoals David Campbell (12/15/2008-06/26/2019)
of David Campbell (06/27/2019-Current)
. 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 een goede ontwerppraktijk om een hiërarchie op te nemen waarmee visuals kunnen inzoomen op het versieniveau.
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 semantisch 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, kan er slechts één actieve relatie zijn tussen twee semantische Power BI-modeltabellen. 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, wat bij 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 onbelangrijke gegevensvenster gemaakt met een overmaat aan metingen. Er zijn ook andere beperkingen:
Om deze beperkingen te overwinnen, is het maken van een dimensietabel voor elke rolspelinstantie een veelgebruikte Power BI-modelleringstechniek. U kunt elke dimensietabel maken als een verwijzende query met behulp van Power Query of een berekende tabel met behulp van DAX. Het model kan een Date
tabel, een Ship Date
tabel en een Delivery Date
tabel 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 die moet worden betaald met deze ontwerpbenadering, is echter dat er duplicatie zal zijn van de datumdimensietabel, wat resulteert in een grotere modelopslaggrootte. Omdat dimensietabellen doorgaans minder rijen ten opzichte van feitentabellen opslaan, is dit zelden een probleem.
We raden u aan goede ontwerpprocedures te volgen bij het maken van modeldimensietabellen voor elke rol:
Year
kolom in alle datumtabellen te hebben (kolomnamen zijn uniek binnen de tabel), worden standaard geen visuele titels zelf beschreven. U kunt de naam van kolommen in elke dimensieroltabel wijzigen, zodat de Ship Date
tabel een jaarkolom heeft met de naam Ship Year
, enzovoort.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 Filters reseller sales by order date
.Zie richtlijnen voor actieve versus inactieve relaties voor meer informatie.
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 orderstatus of demografische kolommen van klanten, zoals geslacht of leeftijdsgroep.
Het ontwerpdoel van een ongewenste dimensie is het samenvoegen van veel kleine dimensies in één dimensie om de grootte van de modelopslag te verminderen en het gegevensvenster 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 om elke rij uniek te identificeren. 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 ter ondersteuning van het maken van een een-op-veel-modelrelatie.
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 zinvol om een onafhankelijke tabel te maken die bestaat uit slechts deze ene kolom, omdat hiermee de opslaggrootte van het model wordt vergroot en het gegevensvenster overzichtelijker wordt.
In het semantische 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 dimensies of feiten zijn).
Als de verkooptabel Adventure Works-resellers echter kolommen met ordernummers en orderregelnummers bevat en ze vereist zijn voor het filteren, is het maken van een tabel met een degenerate dimensie een goed ontwerp. Zie Richtlijnen voor een-op-een-relatie (Degenerate dimensions) voor meer informatie.
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 is 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 interessanter gebruik van een feitentabel is het opslaan van relaties tussen dimensies en het is een semantische modelontwerpbenadering van Power BI die we aanbevelen voor het definiëren van veel-op-veel dimensierelaties. 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.
Zie de volgende artikelen voor meer informatie over het ontwerp van stervormige schema's of het semantische modelontwerp van Power BI:
gebeurtenis
31 mrt, 23 - 2 apr, 23
De ultieme Microsoft Fabric-, Power BI-, SQL- en AI-communitygebeurtenis. 31 maart tot 2 april 2025.
Zorg dat u zich vandaag nog registreertTraining
Module
Een semantisch model ontwerpen in Power BI - Training
Het proces voor het maken van een ingewikkeld semantisch model in Power BI is eenvoudig. Als uw gegevens afkomstig zijn uit meer dan één transactioneel systeem, kunt u voordat u het weet tientallen tabellen krijgen waarmee u moet werken. Het bouwen van een geweldig semantisch model gaat over het vereenvoudigen van de verwarring. Een star schema is één manier om een semantisch model te vereenvoudigen. In deze module leert u meer over de terminologie en implementatie ervan. U leert ook waarom het kiezen van d
Certificering
Microsoft Certified: Power BI Data Analyst Associate - Certifications
Demonstrate methods and best practices that align with business and technical requirements for modeling, visualizing, and analyzing data with Microsoft Power BI.
Documentatie
Gegevensreductiemethoden voor importmodellen - Power BI
Krijg inzicht in verschillende technieken om de gegevens te verminderen die in importmodellen worden geladen.
Richtlijnen voor veel-op-veel-relaties - Power BI
Richtlijnen voor het ontwikkelen van veel-op-veel-modelrelaties.
Richtlijnen voor een-op-een-relatie - Power BI
Richtlijnen voor het begrijpen, ontwikkelen en werken met een-op-een-modelrelaties in Power BI.