Meer informatie over stervormige schema's en het belang daarvan voor Power BIUnderstand star schema and the importance for Power BI

Dit artikel is bedoeld voor ontwikkelaars van Power BI Desktop-gegevensmodellen.This article targets Power BI Desktop data modelers. Hierin wordt het ontwerp van een stervormig schema beschreven en wordt uitgelegd wat het belang daarvan is voor de ontwikkeling van Power BI-gegevensmodellen die voor prestaties en bruikbaarheid zijn geoptimaliseerd.It describes star schema design and its relevance to developing Power BI data models optimized for performance and usability.

Dit artikel is niet bedoeld om een volledige uitleg te geven over het ontwerpen van stervormige schema's.This article isn't intended to provide a complete discussion on star schema design. Voor meer informatie kunt u rechtstreeks gepubliceerde inhoud bekijken, zoals The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3e editie, 2013) door Ralph Kimball et al.For more details, refer directly to published content, like The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3rd edition, 2013) by Ralph Kimball et al.

Overzicht stervormige schema'sStar schema overview

Een stervormig schema is een volwaardige modelleringsmethode die op grote schaal wordt gebruikt door relationele datawarehouses.Star schema is a mature modeling approach widely adopted by relational data warehouses. Hiervoor moeten modelleerders hun modeltabellen ofwel als dimensie of als feit classificeren.It requires modelers to classify their model tables as either dimension or fact.

Met Dimensietabellen worden bedrijfsentiteiten beschreven, oftewel de dingen die u modelleert.Dimension tables describe business entities—the things you model. Entiteiten zijn bijvoorbeeld producten, personen, locaties en concepten zoals tijd.Entities can include products, people, places, and concepts including time itself. De meest consistente tabel in een stervormig schema is een datumdimensietabel.The most consistent table you'll find in a star schema is a date dimension table. Een dimensietabel bevat een of meer sleutelkolommen die als unieke id fungeren, en beschrijvende kolommen.A dimension table contains a key column (or columns) that acts as a unique identifier, and descriptive columns.

In Feitentabellen worden waarnemingen of gebeurtenissen opgeslagen. Dit kunnen verkooporders, inventarissen, wisselkoersen, temperaturen, enzovoort zijn. Een feitentabel bevat sleutelkolommen voor dimensies die betrekking hebben op dimensietabellen, en kolommen met numerieke meetwaarden.Fact tables store observations or events, and can be sales orders, stock balances, exchange rates, temperatures, etc. A fact table contains dimension key columns that relate to dimension tables, and numeric measure columns. De sleutelkolommen voor dimensies bepalen de dimensionaliteit van een feitentabel; de sleutelwaarden voor dimensies bepalen de granulariteit van een feitentabel.The dimension key columns determine the dimensionality of a fact table, while the dimension key values determine the granularity of a fact table. Stel bijvoorbeeld dat u een feitentabel hebt ontworpen om verkoopdoelen op te slaan. Deze tabel bevat de twee dimensiesleutelkolommen Datum en Productsleutel.For example, consider a fact table designed to store sale targets that has two dimension key columns Date and ProductKey. Het moge duidelijk zijn dat de tabel uit twee dimensies bestaat.It's easy to understand that the table has two dimensions. De granulariteit kan echter niet worden bepaald zonder rekening te houden met de dimensiesleutelwaarden.The granularity, however, can't be determined without considering the dimension key values. In dit voorbeeld beschouwen we de waarden die in de kolom Datum zijn opgeslagen als de eerste dag van elke maand.In this example, consider that the values stored in the Date column are the first day of each month. In dit geval ligt de granulariteit op het niveau van maand-product.In this case, the granularity is at month-product level.

Over het algemeen bevatten dimensietabellen een relatief klein aantal rijen.Generally, dimension tables contain a relatively small number of rows. Feitentabellen kunnen daarentegen een groot aantal rijen bevatten en zelfs na verloop van tijd toenemen.Fact tables, on the other hand, can contain a very large number of rows and continue to grow over time.

Afbeelding van een stervormig schema

Relevantie van stervormig schema ten opzichte van Power BI-modellenStar schema relevance to Power BI models

Het ontwerp van stervormige schema's en vele gerelateerde concepten waarover in dit artikel wordt gesproken, zijn uiterst relevant voor de ontwikkeling van Power BI-modellen die voor prestaties en bruikbaarheid zijn geoptimaliseerd.Star schema design and many related concepts introduced in this article are highly relevant to developing Power BI models that are optimized for performance and usability.

Houd er rekening mee dat door elke visual in een Power BI-rapport een query wordt gegenereerd die wordt verzonden naar het Power BI-model (dat in de Power BI-service een gegevensset wordt genoemd).Consider that each Power BI report visual generates a query that is sent to the Power BI model (which the Power BI service calls a dataset). Deze query's worden gebruikt om modelgegevens te filteren, te groepen en samen te vatten.These queries are used to filter, group, and summarize model data. Een goed ontworpen model is dus een model dat tabellen biedt om te filteren en te groeperen en tabellen om gegevens samen te vatten.A well-designed model, then, is one that provides tables for filtering and grouping, and tables for summarizing. Dit ontwerp sluit goed aan op de principes voor stervormige schema's:This design fits well with star schema principles:

  • Dimensietabellen bieden ondersteuning voor filtering en groeperingDimension tables support filtering and grouping
  • Feitentabellen bieden ondersteuning voor samenvattingFact tables support summarization

Er is geen tabeleigenschap die ontwikkelaars van modellen instellen om het tabeltype te configureren als een dimensie- of feitentabel.There's no table property that modelers set to configure the table type as dimension or fact. Dit wordt in feite bepaald door de modelrelaties.It's in fact determined by the model relationships. Via een modelrelatie wordt een doorgiftepad voor filters tussen twee tabellen tot stand gebracht; het is de eigenschap Kardinaliteit van de relatie waardoor het tabeltype wordt bepaald.A model relationship establishes a filter propagation path between two tables, and it's the Cardinality property of the relationship that determines the table type. Een algemene relatiekardinaliteit is één-op-veel, of het omgekeerde veel-op-één.A common relationship cardinality is one-to-many or its inverse many-to-one. De 'één' in deze term verwijst altijd naar een tabel van het type Dimensie; 'veel' verwijst altijd naar een feitentabel.The "one" side is always a dimension-type table while the "many" side is always a fact-type table. Raadpleeg Modelrelaties in Power BI Desktop voor meer informatie over relaties.For more information about relationships, see Model relationships in Power BI Desktop.

Conceptueel stervormig schema

Een modelontwerp met een goede structuur moet tabellen bevatten die ofwel dimensietabellen of feitentabellen zijn.A well-structured model design should include tables that are either dimension-type tables or fact-type tables. Gebruik geen combinatie van de twee typen voor één tabel.Avoid mixing the two types together for a single table. U wordt ook aangeraden ernaar te streven het juiste aantal tabellen te leveren waarvoor de juiste relaties zijn ingesteld.We also recommend that you should strive to deliver the right number of tables with the right relationships in place. Ook is het belangrijk dat gegevens altijd met een consistente nauwkeurigheid in feitentabellen worden geladen.It's also important that fact-type tables always load data at a consistent grain.

Als laatste is het van belang dat u begrijpt dat het ontwerpen van het optimale model deels wetenschap en deels pure kunst is.Lastly, it's important to understand that optimal model design is part science and part art. Soms is het mogelijk om de teugels wat te laten vieren als dit het meest logisch lijkt.Sometimes you can break with good guidance when it makes sense to do so.

Er kunnen vele aanvullende concepten zijn die betrekking hebben op het ontwerp van een stervormig schema die op een Power BI-model kunnen worden toegepast.There are many additional concepts related to star schema design that can be applied to a Power BI model. Dit zijn de volgende concepten:These concepts include:

MetingenMeasures

In een stervormig schemaontwerp is een meting een kolom in een feitentabel waarin de samen te vatten waarden worden opgeslagen.In star schema design, a measure is a fact table column that stores values to be summarized.

In een Power BI-model wordt een meting op een andere, maar wel vergelijkbare manier gedefinieerd.In a Power BI model, a measure has a different—but similar—definition. Het is een formule die wordt geschreven in Data Analysis Expressions (DAX) waarmee u een samenvatting kunt maken.It's a formula written in Data Analysis Expressions (DAX) that achieves summarization. Voor expressies voor metingen worden vaak DAX-aggregatiefuncties gebruikt zoals SUM, MIN, MAX, AVERAGE, enzovoort om een scalair waarderesultaat te produceren tijdens de query (de waarden worden nooit opgeslagen in het model).Measure expressions often leverage DAX aggregation functions like SUM, MIN, MAX, AVERAGE, etc. to produce a scalar value result at query time (values are never stored in the model). Expressies voor metingen kunnen eenvoudige aggregaties met een kolom zijn tot uitgekiende formules waarmee context- en/of relatiedoorgifte worden overschreven.Measure expression can range from simple column aggregations to more sophisticated formulas that override filter context and/or relationship propagation. Lees het artikel DAX basics in Power BI Desktop (Basisbeginselen van DAX in Power BI Desktop) voor meer informatie.For more information, read the DAX Basics in Power BI Desktop article.

Belangrijk: Power BI-modellen bieden ondersteuning voor een tweede methode om een samenvatting te maken.It's important to understand that Power BI models support a second method for achieving summarization. Elke kolom kan met behulp van een visual in een rapport of een Q&A worden samengevat, met name numerieke kolommen.Any column—and typically numeric columns—can be summarized by a report visual or Q&A. Deze kolommen worden impliciete metingen genoemd.These columns are referred to as implicit measures. Ze zijn handig voor u als modelontwerper, omdat u in veel gevallen niet zelf metingen hoeft te maken.They offer a convenience for you as a model developer, as in many instances you do not need to create measures. De kolom Verkoophoeveelheid van de reseller Adventure Works kan bijvoorbeeld op verschillende manieren worden samengevat (som, aantal, gemiddelde, mediaanwaarde, min, max, enzovoort), zonder een meting te hoeven maken voor elk mogelijke aggregatietype.For example, the Adventure Works reseller sales Sales Amount column could be summarized in numerous ways (sum, count, average, median, min, max, etc.), without the need to create a measure for each possible aggregation type.

Voorbeeld van pictogram in lijst met velden

Er zijn voor u echter drie aantrekkelijke redenen om metingen te maken, zelfs voor eenvoudige samenvattingen op kolomniveau:However, there are three compelling reasons for you to create measures, even for simple column-level summarizations:

  • Wanneer u weet dat uw rapportauteurs query's op het model gaan uitvoeren met behulp van Multidimensional Expressions (MDX), moet het model expliciete metingen bevatten.When you know your report authors will query the model by using Multidimensional Expressions (MDX), the model must include explicit measures. Expliciete metingen worden gedefinieerd met behulp van DAX.Explicit measures are defined by using DAX. Deze ontwerpmethode is vooral handig wanneer een query op een Power BI-gegevensset wordt uitgevoerd met behulp van MDX, omdat met MDX geen kolomwaarden kunnen worden samengevat.This design approach is highly relevant when a Power BI dataset is queried by using MDX, because MDX can't achieve summarization of column values. MDX wordt vooral gebruikt bij het uitvoeren van Analyseren in Excel, omdat u met draaitabellen MDX-query’s krijgt).Notably, MDX will be used when performing Analyze in Excel, because PivotTables issue MDX queries.
  • Wanneer u weet dat uw rapportauteurs gepagineerde Power BI-rapporten gaan maken met behulp van de MDX-queryontwerpfunctie, moet het model expliciete metingen bevatten.When you know your report authors will create Power BI paginated reports using the MDX query designer, the model must include explicit measures. Alleen de MDX-queryontwerpfunctie ondersteunt serveraggregaties.Only the MDX query designer supports server aggregates. Als de rapportauteurs dus metingen nodig hebben die zijn geëvalueerd door Power BI (in plaats van de engine voor gepagineerde rapporten), moeten ze de MDX-queryontwerpfunctie gebruiken.So, if report authors need to have measures evaluated by Power BI (instead of by the paginated report engine), they must use the MDX query designer.
  • Als u ervoor wilt zorgen dat uw rapportauteurs kolommen alleen op specifieke manieren kunnen samenvatten.When you need to ensure that your report authors can only summarize columns in specific ways. De kolom Eenheidsprijs (die een tarief per eenheid vertegenwoordigt) voor de verkoop bij de reseller kan bijvoorbeeld worden samengevat, maar alleen door specifieke aggregatiefuncties te gebruiken.For example, the reseller sales Unit Price column (which represents a per unit rate) can be summarized, but only by using specific aggregation functions. De waarden in deze kolom mogen nooit worden opgeteld, maar kunnen wel worden gebruikt om een samenvatting te maken met behulp van andere aggregatiefuncties, zoals min, max en gemiddelde. In dit geval kan de modelleerder de kolom Eenheidsprijs verbergen en metingen maken voor alle toepasselijke aggregatiefuncties.It should never be summed, but it's appropriate to summarize by using other aggregation functions like min, max, average, etc. In this instance, the modeler can hide the Unit Price column, and create measures for all appropriate aggregation functions.

Deze ontwerpmethode werkt goed voor rapporten die in de Power BI-service en voor Q&A zijn geschreven.This design approach works well for reports authored in the Power BI service and for Q&A. Tijdens live-verbindingen van Power BI Desktop kunnen rapportauteurs echter verborgen velden laten zien in het deelvenster Velden, waardoor deze ontwerpmethode zal worden omzeild.However, Power BI Desktop live connections allow report authors to show hidden fields in the Fields pane, which can result in circumventing this design approach.

SurrogaatsleutelsSurrogate keys

Een surrogaatsleutel is een unieke id die u aan een tabel toevoegt om het maken van modellen met een stervormig schema te ondersteunen.A surrogate key is a unique identifier that you add to a table to support star schema modeling. Per definitie worden deze sleutels niet gedefinieerd of opgeslagen in de brongegevens.By definition, it's not defined or stored in the source data. Over het algemeen worden surrogaatsleutels toegevoegd aan relationele dimensietabellen van datawarehouses om een unieke id te bieden voor elke rij in de dimensietabel.Commonly, surrogate keys are added to relational data warehouse dimension tables to provide a unique identifier for each dimension table row.

Power BI-modelrelaties zijn gebaseerd op één unieke kolom in één tabel, waardoor filters voor één kolom in een andere tabel worden doorgegeven.Power BI model relationships are based on a single unique column in one table, which propagates filters to a single column in a different table. Wanneer een dimensietabel in uw model niet één unieke kolom bevat, moet u een unieke id toevoegen die het 'één'-deel van een relatie wordt.When a dimension-type table in your model doesn't include a single unique column, you must add a unique identifier to become the "one" side of a relationship. In Power BI Desktop kunt u eenvoudig voldoen aan deze vereiste door een Power BI-indexkolom te maken.In Power BI Desktop, you can easily achieve this requirement by creating a Power Query index column.

Een indexkolom maken in de Power Query-werkbalk

U moet deze query samenvoegen met de query aan de 'veel'-zijde, zodat u hieraan ook de indexkolom kunt toevoegen.You must merge this query with the "many"-side query so that you can add the index column to it also. Wanneer u deze query's in het model laadt, kunt u vervolgens een één-op-veel-relatie tussen de modeltabellen maken.When you load these queries to the model, you can then create a one-to-many relationship between the model tables.

SneeuwvlokdimensiesSnowflake dimensions

Een sneeuwvlokdimensie is een set genormaliseerde tabellen voor één bedrijfsentiteit.A snowflake dimension is a set of normalized tables for a single business entity. Adventure Works classificeert producten bijvoorbeeld op categorie en subcategorie.For example, Adventure Works classifies products by category and subcategory. Categorieën worden toegewezen aan subcategorieën en producten worden op hun beurt toegewezen aan subcategorieën.Categories are assigned to subcategories, and products are in turn assigned to subcategories. In de relationele datawarehouse van Adventure Works wordt de productdimensie genormaliseerd en opgeslagen in drie gerelateerde tabellen: DimProductCategory, DimProductSubcategory en DimProduct.In the Adventure Works relational data warehouse, the product dimension is normalized and stored in three related tables: DimProductCategory, DimProductSubcategory, and DimProduct.

Met een beetje fantasie kunt u een beeld vormen van de genormaliseerde tabellen die vanuit de feitentabel naar buiten zijn gericht en een sneeuwvlokontwerp vormen.If you use your imagination, you can picture the normalized tables positioned outwards from the fact table, forming a snowflake design.

Voorbeeld van een sneeuwvlokdiagram

In Power BI Desktop kunt u ervoor kiezen een ontwerp van een sneeuwvlokdimensie na te bootsen (mogelijk omdat dit ook voor uw brongegevens wordt gedaan) of de brontabellen in één modeltabel te integreren (denormaliseren).In Power BI Desktop, you can choose to mimic a snowflake dimension design (perhaps because your source data does) or integrate (denormalize) the source tables into a single model table. Over het algemeen wegen de voordelen van meerdere modeltabellen niet op tegen de voordelen van één modeltabel.Generally, the benefits of a single model table outweigh the benefits of multiple model tables. Welke beslissing het meest optimaal is, kan afhangen van de gegevensvolumes en de bruikbaarheidsvereisten voor het model.The most optimal decision can depend on the volumes of data and the usability requirements for the model.

Wanneer u ervoor kiest om een sneeuwvlokdimensieontwerp na te bootsen:When you choose to mimic a snowflake dimension design:

  • In Power BI kunnen meer tabellen worden geladen; dit is minder efficiënt met het oog op opslag en prestaties.Power BI loads more tables, which is less efficient from storage and performance perspectives. Deze tabellen moeten kolommen bevatten om ondersteuning te bieden voor modelrelaties; dit kan leiden tot een groter model.These tables must include columns to support model relationships, and it can result in a larger model size.
  • Langere ketens voor het doorgeven van relatiefilters moeten worden gepasseerd, wat waarschijnlijk minder efficiënt zal zijn dan filters die worden toegepast op één tabel.Longer relationship filter propagation chains will need to be traversed, which will likely be less efficient than filters applied to a single table.
  • In het deelvenster Velden staan meer modeltabellen voor rapportauteurs, wat kan leiden tot een minder intuïtieve ervaring, met name wanneer sneeuwvlokdimensietabellen slechts één of twee kolommen bevatten.The Fields pane presents more model tables to report authors, which can result in a less intuitive experience, especially when snowflake dimension tables contain just one or two columns.
  • Het is niet mogelijk om een hiërarchie te maken die de tabellen omspant.It's not possible to create a hierarchy that spans the tables.

Wanneer u ervoor kiest om alles in één modeltabel te integreren, kunt u ook een hiërarchie definiëren met daarin de hoogste en laagste vezel van de dimensie.When you choose to integrate into a single model table, you can also define a hierarchy that encompasses the highest and lowest grain of the dimension. Mogelijk kan de opslag van redundante gedenormaliseerde gegevens leiden tot een grotere modelopslag, met name voor zeer grote dimensietabellen.Possibly, the storage of redundant denormalized data can result in increased model storage size, particularly for very large dimension tables.

Hiërarchie in een dimensie

Langzaam veranderende dimensiesSlowly changing dimensions

Een langzaam veranderende dimensie (SCD) is een dimensie waarmee de wijziging van dimensieleden over een bepaalde tijd kan worden beheerd.A slowly changing dimension (SCD) is one that appropriately manages change of dimension members over time. Het is van toepassing wanneer waarden van bedrijfsentiteiten over een bepaalde tijd en ad hoc worden gewijzigd.It applies when business entity values change over time, and in an ad hoc manner. Een goed voorbeeld van een langzaam veranderende dimensie is een klantendimensie, met name de kolommen met contactgegevens zoals e-mailadres en telefoonnummer.A good example of a slowly changing dimension is a customer dimension, specifically its contact detail columns like email address and phone number. Andere dimensies worden daarentegen beschouwd als snel veranderende dimensies wanneer een dimensiekenmerk vaak verandert, zoals de prijs op een aandelenmarkt.In contrast, some dimensions are considered to be rapidly changing when a dimension attribute changes often, like a stock's market price. De algemene ontwerpmethode in deze gevallen is snel veranderende kenmerkwaarden op te slaan in een meting in een feitentabel.The common design approach in these instances is to store rapidly changing attribute values in a fact table measure.

De ontwerptheorie waarbij een stervormig schema wordt gemaakt, verwijst naar twee algemene SCD-typen: Type 1 en Type 2.Star schema design theory refers to two common SCD types: Type 1 and Type 2. Een dimensietabel kan van Type 1 of Type 2 zijn, of ondersteuning bieden voor beide typen tegelijk voor verschillende kolommen.A dimension-type table could be Type 1 or Type 2, or support both types simultaneously for different columns.

SCD van type 1Type 1 SCD

Een SCD van Type 1 weerspiegelt altijd de meest recente waarden. Wanneer wijzigingen in de brongegevens worden gedetecteerd, worden de gegevens in de dimensietabel overschreven.A Type 1 SCD always reflects the latest values, and when changes in source data are detected, the dimension table data is overwritten. Dit is de algemene ontwerpmethode voor kolommen waarin aanvullende waarden worden opgeslagen, zoals het e-mailadres of telefoonnummer van een klant.This design approach is common for columns that store supplementary values, like the email address or phone number of a customer. Wanneer het e-mailadres of telefoonnummer van een klant wordt gewijzigd, wordt de rij waarin deze klant staat in de dimensietabel bijgewerkt met de nieuwe waarden.When a customer email address or phone number changes, the dimension table updates the customer row with the new values. Het ziet er dan uit alsof de klant altijd al deze contactgegevens had.It's as if the customer always had this contact information.

Een niet-incrementele vernieuwing van een dimensietabel in een Power BI-model leidt tot een SCD van type 1.A non-incremental refresh of a Power BI model dimension-type table achieves the result of a Type 1 SCD. De tabelgegevens worden vernieuwd om er zeker van te zijn dat de meest recente waarden worden geladen.It refreshes the table data to ensure the latest values are loaded.

SCD van type 2Type 2 SCD

Een SCD van Type 2 biedt ondersteuning voor versiebeheer van dimensieleden.A Type 2 SCD supports versioning of dimension members. Als er geen versies in het bronsysteem worden opgeslagen, worden wijzigingen doorgaans door het laadproces van de datawarehouse gedetecteerd en wordt de wijziging in een dimensietabel beheerd.If the source system doesn't store versions, then it's usually the data warehouse load process that detects changes, and appropriately manages the change in a dimension table. In dit geval moet voor de dimensietabel een surrogaatsleutel worden gebruikt om een unieke verwijzing naar een versie van het dimensielid op te geven.In this case, the dimension table must use a surrogate key to provide a unique reference to a version of the dimension member. Het bevat ook kolommen waarmee de geldigheid van het datumbereik wordt gedefinieerd voor de versie (bijvoorbeeld StartDate en EndDate) en mogelijk een vlagkolom (bijvoorbeeld IsCurrent) om eenvoudig te filteren op huidige dimensieleden.It also includes columns that define the date range validity of the version (for example, StartDate and EndDate) and possibly a flag column (for example, IsCurrent) to easily filter by current dimension members.

Adventure Works wijst bijvoorbeeld verkooppersoneel toe aan een verkoopregio.For example, Adventure Works assigns salespeople to a sales region. Wanneer een verkoopmedewerker naar een andere regio overstapt, moet een nieuwe versie van de verkoopmedewerker worden gemaakt om ervoor te zorgen dat historische feiten gekoppeld blijven aan de voormalige regio.When a salesperson relocates region, a new version of the salesperson must be created to ensure that historical facts remain associated with the former region. Ter ondersteuning van accurate historische analyse van verkoop per verkoopmedewerker moeten in de dimensietabel versies van verkooppersoneel en de aan hun gekoppelde regio('s) worden opgeslagen.To support accurate historic analysis of sales by salesperson, the dimension table must store versions of salespeople and their associated region(s). De tabel moet ook waarden voor de begin- en einddatum bevatten om de geldigheid van de tijd te definiëren.The table should also include start and end date values to define the time validity. In de huidige versies kan een lege einddatum (of 31-12-9999) worden gedefinieerd, waarmee wordt aangegeven dat de rij de huidige versie is.Current versions may define an empty end date (or 12/31/9999), which indicates that the row is the current version. In de tabel moet ook een surrogaatsleutel worden gedefinieerd omdat de bedrijfssleutel (in dit geval de werknemers-id) niet uniek zal zijn.The table must also define a surrogate key because the business key (in this instance, employee ID) won't be unique.

Het is belangrijk om te weten dat wanneer er geen versies worden opgeslagen in de brongegevens, u een tussenliggend systeem moet gebruiken (zoals een datawarehouse) om wijzigingen te detecteren en op te slaan.It's important to understand that when the source data doesn't store versions, you must use an intermediate system (like a data warehouse) to detect and store changes. Tijdens het laadproces voor de tabel moeten bestaande gegevens worden bewaard en wijzigingen worden gedetecteerd.The table load process must preserve existing data and detect changes. Wanneer een wijziging wordt gedetecteerd, moet tijdens het laadproces van de tabel de huidige versie komen te vervallen.When a change is detected, the table load process must expire the current version. Deze wijzigingen worden vastgelegd door de EndDate-waarde bij te werken en een nieuwe versie in te voegen waarbij de StartDate-waarde begint vanaf de vorige EndDate-waarde.It records these changes by updating the EndDate value and inserting a new version with the StartDate value commencing from the previous EndDate value. Daarnaast moet voor gerelateerde feiten een op tijd gebaseerde zoekfunctie worden gebruikt om de dimensiesleutelwaarde op te halen die relevant is voor de datum van het feit.Also, related facts must use a time-based lookup to retrieve the dimension key value relevant to the fact date. Met een Power BI-model waarbij u Power Query gebruikt, kan dit resultaat niet worden bereikt.A Power BI model using Power Query can't produce this result. Er kunnen echter wel gegevens vanuit een vooraf geladen SCD-dimensietabel van type 2 worden geladen.It can, however, load data from a pre-loaded SCD Type 2 dimension table.

Het Power BI-model moet ondersteuning bieden voor het uitvoeren van query's op historische gegevens voor een lid, ongeacht eventuele wijzigingen, en voor een versie van het lid, die een specifieke status van het lid over tijd vertegenwoordigt.The Power BI model should support querying historical data for a member, regardless of change, and for a version of the member, which represents a particular state of the member in time. In de context van Adventure Works stelt dit ontwerp u in staat om een query uit te voeren op de verkoopmedewerker, ongeacht de toegewezen verkoopregio, of voor een specifieke versie van de verkoopmedewerker.In the context of Adventure Works, this design enables you to query the salesperson regardless of assigned sales region, or for a particular version of the salesperson.

Hiervoor moet de dimensietabel van het Power BI-model een kolom bevatten om de verkoopmedewerker te filteren en een andere kolom om een specifieke versie van de verkoopmedewerker te filteren.To achieve this requirement, the Power BI model dimension-type table must include a column for filtering the salesperson, and a different column for filtering a specific version of the salesperson. Het is belangrijk dat in de versiekolom een non-ambigue beschrijving staat, zoals 'Maarten Schalkwijk (15-12-2008 tot 26-06-2019)' of 'Maarten Schalkwijk (huidig)'.It's important that the version column provides a non-ambiguous description, like "Michael Blythe (12/15/2008-06/26/2019)" or "Michael Blythe (current)". Ook is het belangrijk om rapportauteurs en -consumenten de basisprincipes te leren van SCD-type 2 en dat zij weten hoe ze geschikte rapportontwerpen kunnen maken door de juiste filters toe te passen.It's also important to educate report authors and consumers about the basics of SCD Type 2, and how to achieve appropriate report designs by applying correct filters.

Ook is het bij ontwerpen handig om een hiërarchie op te nemen zodat in visuals kan worden ingezoomd op versieniveau.It's also a good design practice to include a hierarchy that allows visuals to drill down to the version level.

Voorbeeld van een hiërarchie in de veldenlijst

Voorbeeld van uitvoer in een hiërarchie

RollenspeldimensiesRole-playing dimensions

Een rollenspeldimensie is een dimensie waarin op een andere manier op gerelateerde feiten kan worden gefilterd.A role-playing dimension is a dimension that can filter related facts differently. Bij Adventure Works bestaat de datumdimensietabel bijvoorbeeld uit drie relaties met de verkoopfeiten van de reseller.For example, at Adventure Works, the date dimension table has three relationships to the reseller sales facts. Dezelfde dimensietabel kan worden gebruikt om de feiten te filteren op orderdatum, verzenddatum of bezorgdatum.The same dimension table can be used to filter the facts by order date, ship date, or delivery date.

In een datawarehouse bestaat de geaccepteerde ontwerpmethode uit het definiëren van één datumdimensietabel.In a data warehouse, the accepted design approach is to define a single date dimension table. Op het moment van de query wordt de 'rol' van de datumdimensie vastgesteld. Van deze rol gebruikt u de feitenkolom om de tabellen aan elkaar te koppelen.At query time, the "role" of the date dimension is established by which fact column you use to join the tables. Wanneer u bijvoorbeeld de verkoop op orderdatum analyseert, heeft de tabelkoppeling betrekking op de kolom Orderdatum van de verkoop van de reseller.For example, when you analyze sales by order date, the table join relates to the reseller sales order date column.

In een Power BI-model kan dit ontwerp worden geïmiteerd door meerdere relaties tussen twee tabellen te maken.In a Power BI model, this design can be imitated by creating multiple relationships between two tables. In het voorbeeld van Adventure Works zouden de tabellen voor de verkoop op datum en de verkoop op reseller drie relaties hebben.In the Adventure Works example, the date and reseller sales tables would have three relationships. Hoewel dit ontwerp wel mogelijk is, is het belangrijk om te weten dat er maar één actieve relatie tussen twee Power BI-modeltabellen kan bestaan.While this design is possible, it's important to understand that there can only be one active relationship between two Power BI model tables. Alle overige relaties worden op inactief ingesteld.All remaining relationships must be set to inactive. Als u één actieve relatie hebt, betekent dit dat er een standaarddoorgifte van filters van verkoop op datum naar verkoop op reseller wordt gebruikt.Having a single active relationship means there is a default filter propagation from date to reseller sales. In dit geval wordt de actieve relatie ingesteld op het meest algemene filter dat in rapporten wordt gebruikt; bij Adventure Works is dit de relatie op basis van de orderdatum.In this instance, the active relationship is set to the most common filter that is used by reports, which at Adventure Works is the order date relationship.

Voorbeeld van één rollenspeldimensie en relaties

De enige manier om een inactieve relatie te gebruiken, is door een DAX-expressie te definiëren waarvoor de functie USERELATIONSHIP wordt gebruikt.The only way to use an inactive relationship is to define a DAX expression that uses the USERELATIONSHIP function. In ons voorbeeld moet de modelontwikkelaar metingen instellen om de analyse van de verkoop van een reseller op verzenddatum en bezorgdatum in te schakelen.In our example, the model developer must create measures to enable analysis of reseller sales by ship date and delivery date. Dit kan een lastige klus zijn, met name wanneer in de resellertabel vele metingen worden gedefinieerd.This work can be tedious, especially when the reseller table defines many measures. Ook ontstaat hierdoor een chaos in het deelvenster Velden, met een overvloed aan metingen.It also creates Fields pane clutter, with an overabundance of measures. Er zijn meer beperkingen:There are other limitations, too:

  • Wanneer rapportauteurs niet op het definiëren van metingen maar op het samenvatten van kolommen vertrouwen, kunnen ze geen samenvatting voor de inactieve relaties krijgen zonder een meting op rapportniveau te schrijven.When report authors rely on summarizing columns, rather than defining measures, they can't achieve summarization for the inactive relationships without writing a report-level measure. Metingen op rapportniveau kunnen alleen worden gedefinieerd wanneer rapporten in Power BI Desktop worden geschreven.Report-level measures can only be defined when authoring reports in Power BI Desktop.
  • Met maar één actief relatiepad tussen de verkoop op datum en de verkoop op reseller, is het niet mogelijk om de verkoop op reseller gelijktijdig te filteren op verschillende datumtypen.With only one active relationship path between date and reseller sales, it's not possible to simultaneously filter reseller sales by different types of dates. U kunt bijvoorbeeld geen visual produceren waarin de verkoop op orderdatum wordt uitgezet op basis van verzonden verkoop.For example, you can't produce a visual that plots order date sales by shipped sales.

Als u deze beperkingen wilt vermijden, is het een algemene Power BI-modelleringstechniek om voor elke rollenspelinstantie een dimensietabel te maken.To overcome these limitations, a common Power BI modeling technique is to create a dimension-type table for each role-playing instance. Doorgaans maakt u de extra dimensietabellen als berekende tabellen met behulp van DAX.You typically create the additional dimension tables as calculated tables, using DAX. Met behulp van berekende tabellen kan het model de tabellen Datum, Verzenddatum en Bezorgdatum bevatten, elk met één actieve relatie met hun respectieve kolommen over de verkoop per reseller.Using calculated tables, the model can contain a Date table, a Ship Date table and a Delivery Date table, each with a single and active relationship to their respective reseller sales table columns.

Voorbeeld van rollenspeldimensies en relaties

Voor deze ontwerpmethode hoeft u niet meerdere metingen voor verschillende datumrollen te definiëren en kunt u bovendien tegelijkertijd verschillende datumrollen filteren.This design approach doesn't require you to define multiple measures for different date roles, and it allows simultaneous filtering by different date roles. Het enige kleine nadeel van deze ontwerpmethode is echter dat er duplicatie van de datumdimensietabel zal optreden, waardoor de modelopslaggrootte zal toenemen.A minor price to pay, however, with this design approach is that there will be duplication of the date dimension table resulting in an increased model storage size. Maar omdat er, in vergelijking met feitentabellen, doorgaans minder rijen in dimensietabellen worden opgeslagen, is dit nauwelijks een probleem.As dimension-type tables typically store fewer rows relative to fact-type tables, it is rarely a concern.

Bekijk de volgende handige ontwerpprocedures wanneer u voor elke rol modeldimensietabellen gaat maken:Observe the following good design practices when you create model dimension-type tables for each role:

  • Zorg ervoor dat de kolomnamen een goede eigen beschrijving bevatten.Ensure that the column names are self-describing. Het is mogelijk om in alle datumtabellen een kolom Jaar op te nemen (kolomnamen zijn uniek binnen hun tabel), maar de standaardinstellingen voor titels van visuals bevatten geen goede eigen beschrijving.While it's possible to have a Year column in all date tables (column names are unique within their table), it's not self-describing by default visual titles. U kunt de naam van kolommen in elke tabel van een dimensierol wijzigen, zodat de tabel Verzenddatum een jaarkolom heeft met de naam Jaar van verzending, enzovoort.Consider renaming columns in each dimension role table, so that the Ship Date table has a year column named Ship Year, etc.
  • Indien relevant moet u ervoor zorgen dat rapportauteurs via tabelbeschrijvingen feedback krijgen (via de knopinfo in het deelvenster Velden) over de manier waarop filterdoorgifte wordt geconfigureerd.When relevant, ensure that table descriptions provide feedback to report authors (through Fields pane tooltips) about how filter propagation is configured. Deze verduidelijking is belangrijk wanneer het model een tabel met een generieke naam bevat, zoals Datum, welke wordt gebruikt om een groot aantal feitentabellen te filteren.This clarity is important when the model contains a generically named table, like Date, which is used to filter many fact-type tables. In het geval deze tabel bijvoorbeeld een actieve relatie heeft met de kolom Verkoop van de reseller op orderdatum, is het wellicht handig om een tabelbeschrijving op te geven, zoals 'Filtert de verkoop van de reseller op orderdatum'.In the case that this table has, for example, an active relationship to the reseller sales order date column, consider providing a table description like "Filters reseller sales by order date".

Raadpleeg Richtlijnen voor actieve versus inactieve relaties voor meer informatie.For more information, see Active vs inactive relationship guidance.

RestdimensiesJunk dimensions

Een restdimensie is handig wanneer er vele dimensies bestaan, die met name dimensies die uit maar een aantal kenmerken (of zelfs maar één kenmerk) bestaan en wanneer deze kenmerken een aantal waarden bevatten.A junk dimension is useful when there are many dimensions, especially consisting of few attributes (perhaps one), and when these attributes have few values. Denk hierbij bijvoorbeeld aan kolommen over de orderstatus of kolommen met demografische klantgegevens (geslacht, leeftijdsgroep, enzovoort).Good candidates include order status columns, or customer demographic columns (gender, age group, etc.).

De ontwerpdoelstelling van een restdimensie is het grote aantal 'kleine' dimensies samen te voegen in één dimensie om zowel de opslaggrootte van het model te verkleinen als de chaos op het deelvenster Velden te verminderen door minder modeltabellen weer te geven.The design objective of a junk dimension is to consolidate many "small" dimensions into a single dimension to both reduce the model storage size and also reduce Fields pane clutter by surfacing fewer model tables.

Een restdimensietabel is doorgaans het Cartesisch product van alle leden van een dimensiekenmerk, met de kolom met een surrogaatsleutel.A junk dimension table is typically the Cartesian product of all dimension attribute members, with a surrogate key column. De surrogaatsleutel biedt een unieke verwijzing naar elke rij in de tabel.The surrogate key provides a unique reference to each row in the table. U kunt de dimensie in een datawarehouse bouwen, of u bouwt deze met behulp van Power Query om een query te maken waarmee een volledige outer join van query's wordt uitgevoerd en waarmee vervolgens een surrogaatsleutel (indexkolom) wordt toegevoegd.You can build the dimension in a data warehouse, or by using Power Query to create a query that performs full outer query joins, then adds a surrogate key (index column).

Voorbeeld van een restdimensie

U laadt deze query in het model als een dimensietabel.You load this query to the model as a dimension-type table. Daarnaast moet u deze query samenvoegen met de feitenquery, zodat de indexkolom in het model wordt geladen om een 'één-op-veel'-modelrelatie te helpen maken.You also need to merge this query with the fact query, so the index column is loaded to the model to support the creation of a "one-to-many" model relationship.

Losstaande dimensiesDegenerate dimensions

Een losstaande dimensie verwijst naar een kenmerk van de feitentabel dat vereist is om te filteren.A degenerate dimension refers to an attribute of the fact table that is required for filtering. Bij Adventure Works is het aantal verkooporders van de reseller een goed voorbeeld.At Adventure Works, the reseller sales order number is a good example. In dit geval is het niet handig om een onafhankelijke tabel te maken die alleen uit deze ene kolom bestaat, omdat de modelopslaggrootte hierdoor zou toenemen en zou leiden tot in chaos in het deelvenster Velden.In this case, it doesn't make good model design sense to create an independent table consisting of just this one column, because it would increase the model storage size and result in Fields pane clutter.

In het Power BI-model kan het nuttig zijn om de kolom met verkoopordernummers aan de feitentabel toe te voegen, zodat kan worden gefilterd of gegroepeerd op verkoopordernummer.In the Power BI model, it can be appropriate to add the sales order number column to the fact-type table to allow filtering or grouping by sales order number. Dit is een uitzondering op de eerder geïntroduceerde regel dat u geen tabeltypen mag combineren (over het algemeen moeten modeltabellen ofwel van het type Dimensie of van het type Feiten zijn).It is an exception to the formerly introduced rule that you should not mix table types (generally, model tables should be either dimension-type or fact-type).

Voorbeeld van een losstaande dimensie

Als de tabel voor de verkoop door Adventure Works-wederverkopers kolommen voor ordernummers en orderregelnummers bevat en deze vereist zijn voor het filteren, is een tabel met losstaande dimensies een goed ontwerp.However, if the Adventure Works resellers sales table has order number and order line number columns, and they're required for filtering, a degenerate dimension table would be a good design. Raadpleeg Richtlijnen voor een-op-een-relaties (losstaande dimensies) voor meer informatie.For more information, see One-to-one relationship guidance (Degenerate dimensions).

Feitloze feitentabellenFactless fact tables

Een feitloze feitentabel bevat geen enkele metingkolom.A factless fact table doesn't include any measure columns. Deze tabel bevat uitsluitend dimensiesleutels.It contains only dimension keys.

In een feitloze feitentabel kunnen observaties worden opgeslagen die worden gedefinieerd door dimensiesleutels.A factless fact table could store observations defined by dimension keys. Bijvoorbeeld op een specifieke datum en tijd heeft een specifieke klant zich bij uw website aangemeld.For example, at a particular date and time, a particular customer logged into your web site. U kunt een meting definiëren om de rijen van de feitloze feitentabel te tellen, zodat u kunt analyseren wanneer en hoeveel klanten zich hebben aangemeld.You could define a measure to count the rows of the factless fact table to perform analysis of when and how many customers have logged in.

Een aantrekkelijker gebruik van een feitloze feitentabel is de opslag van relaties tussen dimensies; het is de ontwerpmethode voor Power BI-modellen die wij aanbevelen voor het definiëren van veel-op-veel-dimensierelaties.A more compelling use of a factless fact table is to store relationships between dimensions, and it's the Power BI model design approach we recommend defining many-to-many dimension relationships. In een ontwerp met een veel-op-veel-dimensierelatie wordt de feitloze feitentabel een brugtabel genoemd.In a many-to-many dimension relationship design, the factless fact table is referred to as a bridging table.

Houd er bijvoorbeeld rekening mee dat verkooppersoneel kan worden toegewezen aan een of meer verkoopregio's.For example, consider that salespeople can be assigned to one or more sales regions. De brugtabel wordt ontworpen als een feitloze feitentabel die uit twee kolommen bestaat: de verkoopmedewerkersleutel en de regiosleutel.The bridging table would be designed as a factless fact table consisting of two columns: salesperson key and region key. Dubbele waarden kunnen worden opgeslagen in beide kolommen.Duplicate values can be stored in both columns.

Voorbeeld van een feitloze feitentabel

Deze veel-op-veel-ontwerpmethode is goed beschreven en kan worden bereikt zonder een brugtabel.This many-to-many design approach is well documented, and it can be achieved without a bridging table. De brugtabelmethode wordt echter als best practice beschouwd wanneer u een relatie tussen twee dimensies tot stand brengt.However, the bridging table approach is considered the best practice when relating two dimensions. Raadpleeg Richtlijnen voor veel-op-veel-relaties (twee dimensietabellen relateren) voor meer informatie.For more information, see Many-to-many relationship guidance (Relate two dimension-type tables).

Volgende stappenNext steps

Raadpleeg de volgende artikelen voor meer informatie over stervormig schemaontwerp of het ontwerpen van Power BI-modellen:For more information about star schema design or Power BI model design, see the following articles: