Modelrelaties in Power BI DesktopModel relationships in Power BI Desktop

Dit artikel is geschreven voor iedereen die Import-gegevensmodellen maakt met Power BI Desktop.This article targets Import data modelers working with Power BI Desktop. Het is een belangrijk onderwerp over het ontwerpen van modellen dat essentieel is voor het leveren van intuïtieve, nauwkeurige en optimale modellen.It's an important model design topic that's essential to delivering intuitive, accurate, and optimal models.

Voor een diepgaande bespreking over optimaal modelontwerp, met inbegrip van tabelrollen en -relaties, raadpleegt u het artikel Het sterschema en het belang ervan voor Power BI begrijpen artikel.For a deeper discussion on optimal model design, including table roles and relationships, see the Understand star schema and the importance for Power BI article.

Doel van relatieRelationship purpose

Eenvoudig gezegd worden Power BI-relaties gebruikt om filters die zijn toegepast op de kolommen van modeltabellen, door te geven aan andere modeltabellen.Put simply, Power BI relationships propagate filters applied on the columns of model tables to other model tables. Filters worden doorgegeven zolang er een relatiepad is dat kan worden gevolgd. Hierbij kunnen filters aan meerdere tabellen worden doorgegeven.Filters will propagate so long as there's a relationship path to follow, which can involve propagation to multiple tables.

Relatiepaden zijn deterministisch, wat betekent dat filters altijd op dezelfde manier worden doorgegeven en zonder willekeurige variatie.Relationship paths are deterministic, meaning that filters are always propagated in the same way and without random variation. Relaties kunnen echter worden uitgeschakeld of gewijzigde filtercontext door modelberekeningen hebben die gebruikmaken van specifieke DAX-functies.Relationships can, however, be disabled, or have filter context modified by model calculations that use particular DAX functions. Raadpleeg het onderwerp Relevante DAX-functies verderop in dit artikel voor meer informatie.For more information, see the Relevant DAX functions topic later in this article.

Belangrijk

Het is belangrijk om te begrijpen dat modelrelaties geen gegevensintegriteit afdwingen.It's important to understand that model relationships do not enforce data integrity. Raadpleeg het onderwerp Beoordeling van relaties verderop in dit artikel voor meer informatie.For more information, see the Relationship evaluation topic later in this article. In deze onderwerpen wordt uitgelegd hoe modelrelaties zich gedragen wanneer er problemen zijn met de gegevensintegriteit van uw gegevens.This topics explains how model relationships behave when there are data integrity issues with your data.

Laten we eens kijken hoe relaties filters doorgeven met een geanimeerd voorbeeld.Let's see how relationships propagate filters with an animated example.

Geanimeerd voorbeeld van het doorgeven van filters door relatie

In dit voorbeeld bestaat het model uit vier tabellen: Categorie, Product, Jaar en Verkoop.In this example, the model consists of four tables: Category, Product, Year, and Sales. De tabel Categorie is gekoppeld aan de tabel Product en de tabel Product is gekoppeld aan de tabel Verkoop.The Category table relates to the Product table, and the Product table relates to the Sales table. De tabel Jaar is ook gekoppeld aan de tabel Verkoop.The Year table also relates to the Sales table. Alle relaties zijn een-op-veel (de details worden verderop in dit artikel beschreven).All relationships are one-to-many (the details of which are described later in this article).

Een query (die mogelijk is gegenereerd via een Power BI-kaartvisual) vraagt de totale verkopen aan voor verkooporders die zijn geplaatst voor één categorie, Cat-A, en voor één jaar, CY2018.A query—possibly generated by a Power BI card visual—requests the total sales quantity for sales orders made for a single category, Cat-A, and for a single year, CY2018. Daarom ziet u filters toegepast op de tabellen Categorie en Jaar.It's why you can see filters applied on the Category and Year tables. Het filter voor de tabel Categorie wordt doorgegeven aan de tabel Product om twee producten te isoleren die zijn toegewezen aan de categorie Cat-A.The filter on the Category table propagates to the Product table to isolate two products that are assigned to the category Cat-A. Vervolgens worden de filters van de tabel Product doorgegeven aan de tabel Verkoop om slechts twee verkooprijen voor deze producten te isoleren.Then the Product table filters propagate to the Sales table to isolate just two sales rows for these products. Deze twee verkooprijen vertegenwoordigen de verkoop van producten die zijn toegewezen aan de categorie Cat-A.These two sales rows represent the sales of products assigned to category Cat-A. De gecombineerde hoeveelheid is 14 eenheden.Their combined quantity is 14 units. Tegelijkertijd wordt het filter in de tabel Jaar doorgegeven om de tabel Verkoop verder te filteren, wat resulteert in slechts één verkooprij voor producten die zijn toegewezen aan categorie Cat-A en die zijn besteld in jaar CY2018.At the same time, the Year table filter propagates to further filter the Sales table, resulting in just the one sales row that is for products assigned to category Cat-A and that was ordered in year CY2018. De hoeveelheid die door de query wordt geretourneerd, is 11 eenheden.The quantity value returned by the query is 11 units. Houd er rekening mee dat als er meerdere filters worden toegepast op een tabel (zoals de tabel Verkoop in dit voorbeeld), het altijd gaat om een AND-bewerking, waarbij alle voorwaarden waar moeten zijn.Note that when multiple filters are applied to a table (like the Sales table in this example), it's always an AND operation, requiring that all conditions must be true.

Losgekoppelde tabellenDisconnected tables

Het is ongebruikelijk dat een modeltabel niet aan een andere modeltabel is gekoppeld.It's unusual that a model table isn't related to another model table. Een dergelijke tabel in een geldig modelontwerp kan worden beschreven als een losgekoppelde tabel.Such a table in a valid model design can be described as a disconnected table. Een losgekoppelde tabel is niet bedoeld om filters door te geven aan andere modeltabellen.A disconnected table isn't intended to propagate filters to other model tables. In plaats daarvan wordt invoer van de gebruiker geaccepteerd (mogelijk met een slicervisual), zodat modelberekeningen de invoerwaarde op een zinvolle manier kunnen gebruiken.Instead, it's used to accept "user input" (perhaps with a slicer visual), allowing model calculations to use the input value in a meaningful way. Denk bijvoorbeeld aan een losgekoppelde tabel die wordt geladen met verschillende wisselkoersen.For example, consider a disconnected table that is loaded with a range of currency exchange rate values. Zolang een filter is toegepast voor één valutawaarde, kan deze waarde worden gebruikt voor een meetexpressie om verkoopwaarden te converteren.As long as a filter is applied to filter by a single rate value, the value can be used by a measure expression to convert sales values.

Met de What if-parameter van Power BI Desktop kan een losgekoppelde tabel worden gemaakt.The Power BI Desktop what-if parameter is a feature that creates a disconnected table. Lees het artikel Een What if-parameter maken en gebruiken om variabelen in Power BI Desktop te visualiseren voor meer informatie.For more information, see the Create and use a What if parameter to visualize variables in Power BI Desktop article.

Eigenschappen van relatiesRelationship properties

Een modelrelatie verbindt één kolom in een tabel met één kolom in een andere tabel.A model relationship relates one column in a table to one column in a different table. (Er is één gespecialiseerd geval waarbij deze vereiste niet waar is, en dit geldt alleen voor relaties met meerdere kolommen in DirectQuery-modellen.(There's one specialized case where this requirement isn't true, and it applies only to multi-column relationships in DirectQuery models. Lees het artikel over de DAX-functie COMBINEVALUES voor meer informatie.)For more information, see the COMBINEVALUES DAX function article.)

Notitie

Het is niet mogelijk om een kolom te koppelen aan een andere kolom in dezelfde tabel.It's not possible to relate a column to a different column in the same table. Dit wordt soms verward met het definiëren van een beperking op de refererende sleutel voor een relationele database, die naar dezelfde tabel verwijst.This is sometimes confused with the ability to define a relational database foreign key constraint that is table self-referencing. Dit concept voor relationele databases kan worden gebruikt voor het opslaan van relaties tussen bovenliggende en onderliggende items (bijvoorbeeld elk werknemersrecord is gerelateerd aan de werknemer 'rapporten aan').This relational database concept can be used to store parent-child relationships (for example, each employee record is related to a "reports to" employee). Een modelhiërarchie op basis van dit type relatie kan niet worden opgelost door modelrelaties te maken.Generating a model hierarchy based on this type of relationship can't be solved by creating model relationships. Bekijk het artikel Bovenliggende en onderliggende functies om dit te bewerkstelligen.To achieve this, see the Parent and Child functions article.

KardinaliteitCardinality

Elke modelrelatie moet worden gedefinieerd met een type kardinaliteit.Each model relationship must be defined with a cardinality type. Er zijn vier opties voor het type kardinaliteit, die de gegevenskenmerken van de gerelateerde kolommen 'van' en 'aan' vertegenwoordigen.There are four cardinality type options, representing the data characteristics of the "from" and "to" related columns. De 'een'-zijde betekent dat de kolom unieke waarden bevat. De 'twee'-zijde betekent dat de kolom dubbele waarden kan bevatten.The "one" side means the column contains unique values; the "two" side means the column can contain duplicate values.

Notitie

Als een bewerking voor gegevensvernieuwing probeert dubbele waarden te laden in een kolom met een 'een'-zijde, mislukt de volledige gegevensvernieuwing.If a data refresh operation attempts to load duplicate values into a "one" side column, the entire data refresh will fail.

De vier opties en hun verkorte notaties worden beschreven in de volgende lijst:The four options—together with their shorthand notations—are described in the following bulleted list:

  • Een-op-veel (1:*)One-to-many (1:*)
  • Veel-op-een (*:1)Many-to-one (*:1)
  • Een-op-een (1:1)One-to-one (1:1)
  • Veel-op-veel (*:*)Many-to-many (*:*)

Wanneer u een relatie maakt in Power BI Desktop wordt het type kardinaliteit automatisch gedetecteerd en ingesteld door de ontwerper.When you create a relationship in Power BI Desktop, the designer will automatically detect and set the cardinality type. De ontwerper doorzoekt het model om te achterhalen welke kolommen unieke waarden bevatten.The designer queries the model to know which columns contain unique values. Bij Import-modellen wordt gebruikgemaakt van interne opslagstatistieken. Bij DirectQuery-modellen worden de profileringsquery's verzonden naar de gegevensbron.For Import models, it uses internal storage statistics; for DirectQuery models it sends profiling queries to the data source. Soms kan de ontwerper zich echter vergissen.Sometimes, however, it can get it wrong. Dit gebeurt omdat er nog gegevens moeten worden geladen in de tabellen, of omdat kolommen waarvan u verwacht dat deze dubbele waarden bevatten, momenteel enkele waarden bevatten.It happens because tables are yet to be loaded with data, or because columns that you expect to contain duplicate values currently contain unique values. In beide gevallen kunt u het type kardinaliteit bijwerken als een kolom met een 'een'-zijde enkele waarden bevat (of als de tabel nog moet worden geladen met rijen gegevens).In either case, you can update the cardinality type as long as any "one" side columns contain unique values (or the table is yet to be loaded with rows of data).

De kardinaliteitsopties Een-op-veel en Veel-op-een zijn in wezen hetzelfde, en ze zijn ook de meest voorkomende typen kardinaliteit.The One-to-many and Many-to-one cardinality options are essentially the same, and they're also the most common cardinality types.

Bij het configureren van een een-op-veel- of veel-op-een-relatie, kiest u de opties die overeenkomt met de volgorde waarin u de kolommen hebt gekoppeld.When configuring a One-to-many or Many-to-one relationship, you'll choose the one that matches the order in which you related the columns. Denk na over hoe u de relatie van de tabel Product met de tabel Verkoop zou configureren met behulp van de kolom ProductID die in elke tabel staat.Consider how you would configure the relationship from the Product table to the Sales table by using the ProductID column found in each table. Het type kardinaliteit wordt Een-op-veel, omdat de kolom ProductID in de tabel Product enkele waarden bevat.The cardinality type would be One-to-many, as the ProductID column in the Product table contains unique values. Als u de tabellen in omgekeerde volgorde hebt gekoppeld, Verkoop aan Product, wordt de kardinaliteit Veel-op-een.If you related the tables in the reverse direction, Sales to Product, then the cardinality would be Many-to-one.

Een Een-op-een-relatie betekent dat beide kolommen enkele waarden bevatten.A One-to-one relationship means both columns contain unique values. Dit type kardinaliteit is niet gebruikelijk en doet vermoeden dat het modelontwerp niet optimaal is, omdat er redundante gegevens worden opgeslagen.This cardinality type isn't common, and it likely represents a suboptimal model design because of the storage of redundant data. Raadpleeg Richtlijnen voor een-op-een-relaties voor meer informatie over het gebruik van dit type kardinaliteit.For more information on using this cardinality type, see One-to-one relationship guidance.

Een Veel-op-veel-relatie betekent dat beide kolommen dubbele waarden kunnen bevatten.A Many-to-many relationship means both columns can contain duplicate values. Dit type kardinaliteit wordt zelden gebruikt.This cardinality type is infrequently used. Het is doorgaans handig bij het ontwerpen van complexe modelvereisten.It's typically useful when designing complex model requirements. Zie Richtlijnen voor veel-op-veel-relaties voor hulp bij het gebruik van dit type kardinaliteit.For guidance on using this cardinality type, see Many-to-many relationship guidance.

Notitie

Het type kardinaliteit Veel-op-veel wordt momenteel niet ondersteund voor modellen die zijn ontwikkeld voor Power BI Report Server.The Many-to-many cardinality type isn't currently supported for models developed for Power BI Report Server.

Tip

In de modelweergave van Power BI Desktop kunt u het type kardinaliteit van een relatie bekijken door de indicatoren (1 of *) aan beide zijden van de relatielijn te bekijken.In Power BI Desktop model view, you can interpret a relationship's cardinality type by looking at the indicators (1 or *) on either side of the relationship line. Als u wilt bepalen welke kolommen gekoppeld zijn, moet u de relatielijn selecteren of de muisaanwijzer op de relatielijn houden om de kolommen te markeren.To determine which columns are related, you'll need to select—or hover the cursor over—the relationship line to highlight the columns.

KruisfilterrichtingCross filter direction

Elke modelrelatie moet worden gedefinieerd met een kruisfilterrichting.Each model relationship must be defined with a cross filter direction. Uw selectie bepaalt de richting(en) die door de filters worden doorgegeven.Your selection determines the direction(s) that filters will propagate. De mogelijke opties voor kruislings filteren zijn afhankelijk van het type kardinaliteit.The possible cross filter options are dependent on the cardinality type.

Type kardinaliteitCardinality type KruisfilteroptiesCross filter options
Een-op-veel (of veel-op-een)One-to-many (or Many-to-one) EnkelSingle
BeideBoth
Een-op-eenOne-to-one BeideBoth
Veel-op-veelMany-to-many Enkel (Tabel1 naar tabel2)Single (Table1 to Table2)
Enkel (Tabel2 naar tabel1)Single (Table2 to Table1)
BeideBoth

De kruisfilterrichting Enkel betekent 'een richting' en Beide betekent 'beide richtingen'.Single cross filter direction means "single direction", and Both means "both directions". Een relatie die wordt gefilterd in beide richtingen, wordt doorgaans beschreven als bidirectioneel.A relationship that filters in both directions is commonly described as bi-directional.

Voor een-op-veel-relaties is de kruisfilterrichting altijd vanaf de 'een'-zijde en optioneel vanaf de 'veel'-zijde (bidirectioneel).For One-to-many relationships, the cross filter direction is always from the "one" side, and optionally from the "many" side (bi-directional). Voor een-op-een-relaties is de kruisfilterrichting altijd vanuit beide tabellen.For One-to-one relationships, the cross filter direction is always from both tables. Ten slotte kunt u voor de veel-op-veel-relaties een kruisfilterrichting van één van de tabellen of van beide tabellen gebruiken.Lastly, for the Many-to-many relationships, cross filter direction can be from either one of the tables, or from both tables. Houd er rekening mee dat wanneer het type kardinaliteit een 'een'-zijde bevat, deze filters altijd van die zijde worden doorgegeven.Notice that when the cardinality type includes a "one" side, that filters will always propagate from that side.

Als de kruisfilterrichting is ingesteld op Beide, is er een extra eigenschap beschikbaar.When the cross filter direction is set to Both, an additional property is available. Bidirectionele filtering kan worden toegepast wanneer RLS-regels (beveiliging op rijniveau) worden geforceerd.It can apply bi-directional filtering when row-level security (RLS) rules are enforced. Raadpleeg het artikel RLS (beveiliging op rijniveau) met Power BI Desktop voor meer informatie over RLS.For more information about RLS, see the Row-level security (RLS) with Power BI Desktop article.

Het wijzigen van de kruisfilterrichting voor relaties, inclusief het uitschakelen van het doorgeven van filters, kan ook worden uitgevoerd door een modelberekening.Modifying the relationship cross filter direction—including the disabling of filter propagation—can also be done by a model calculation. Dit wordt bereikt met behulp van de DAX-functie CROSSFILTER.It's achieved by using the CROSSFILTER DAX function.

Bidirectionele relaties kunnen een negatieve invloed hebben op de prestaties.Bi-directional relationships can impact negatively on performance. Als u een bidirectionele relatie wilt configureren, kan dit leiden tot dubbelzinnige paden voor het doorgeven van filters.Further, attempting to configure a bi-directional relationship could result in ambiguous filter propagation paths. In dit geval kan Power BI Desktop de relatiewijziging mogelijk niet doorvoeren en wordt er een foutbericht weer gegeven.In this case, Power BI Desktop may fail to commit the relationship change and will alert you with an error message. Soms kan Power BI Desktop echter toestaan dat er ambigue relatiepaden tussen tabellen worden gedefinieerd.Sometimes, however, Power BI Desktop may allow you to define ambiguous relationship paths between tables. Prioriteitsregels die van invloed zijn op de oplossing van dubbelzinnigheid en paden, worden verderop in dit artikel beschreven in het onderwerp Prioriteitsregels.Precedence rules that affect ambiguity detection and path resolution are described later in this article in the Precedence rules topic.

We raden u aan om bidirectionele filtering alleen naar behoefte te gebruiken.We recommend using bi-directional filtering only as needed. Raadpleeg Richtlijnen voor bidirectionele relaties voor meer informatie.For more information, see Bi-directional relationship guidance.

Tip

In de modelweergave van Power BI Desktop kunt u de kruisfilterrichting van een relatie interpreteren door de pijlpunt(en) op de relatielijn te bekijken.In Power BI Desktop model view, you can interpret a relationship's cross filter direction by noticing the arrowhead(s) along the relationship line. Een enkele pijlpunt vertegenwoordigt een filter met één richting in de richting van de pijlpunt en een dubbele pijlpunt vertegenwoordigt een bidirectionele relatie.A single arrowhead represents a single-direction filter in the direction of the arrowhead; a double arrowhead represents a bi-directional relationship.

Deze relatie activerenMake this relationship active

U kunt slechts één actief pad voor het doorsturen van filters tussen twee modeltabellen gebruiken.There can only be one active filter propagation path between two model tables. Het is echter mogelijk om extra relatiepaden in te voeren, maar deze relaties moeten allemaal worden geconfigureerd als inactief.However, it's possible to introduce additional relationship paths, though these relationships must all be configured as inactive. Inactieve relaties kunnen alleen actief worden gemaakt tijdens de evaluatie van een modelberekening.Inactive relationships can only be made active during the evaluation of a model calculation. Dit wordt bereikt met behulp van de DAX-functie USERELATIONSHIP.It is achieved by using the USERELATIONSHIP DAX function.

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

Tip

In de modelweergave van Power BI Desktop kunt u de status Actief of Inactief van een relatie bekijken.In Power BI Desktop model view, you can interpret a relationship's active vs inactive status. Een actieve relatie wordt weergegeven met een ononderbroken lijn en een inactieve relatie wordt weergegeven als een stippellijn.An active relationship is represented by a solid line; an inactive relationship is represented as a dashed line.

Referentiële integriteit aannemenAssume referential integrity

De eigenschap Referentiële integriteit aannemen is alleen beschikbaar voor een-op-veel- en een-op-een-relaties tussen twee DirectQuery-opslagmodustabellen die zijn gebaseerd op dezelfde gegevensbron.The Assume referential integrity property is available only for One-to-many and One-to-one relationships between two DirectQuery storage mode tables that are based on the same data source. Wanneer deze eigenschap is ingeschakeld, voegen systeemeigen query's die worden verzonden naar de gegevensbron, de twee tabellen samen met een INNER JOIN in plaats van een OUTER JOIN.When enabled, native queries sent to the data source will join the two tables together by using an INNER JOIN rather than an OUTER JOIN. Het inschakelen van deze eigenschap is in het algemeen beter voor de queryprestaties, hoewel de specifieke gegevensbron hierbij ook een rol speelt.Generally, enabling this property improves query performance, though it does depend on the specifics of the data source.

Schakel deze eigenschap altijd in als er een beperking bestaat voor de refererende databasesleutel tussen de twee tabellen.Always enable this property when a database foreign key constraint exists between the two tables. Als er geen beperking is voor de refererende sleutel, kunt u de eigenschap alsnog inschakelen, zolang u maar zeker weet dat er sprake is van gegevensintegriteit.When a foreign key constraint doesn't exist, you can still enable the property as long as you're certain data integrity exists.

Belangrijk

Als de gegevensintegriteit is aangetast, worden de niet-overeenkomende rijen tussen de tabellen door de inner join geëlimineerd.If data integrity should become compromised, the inner join will eliminate unmatched rows between the tables. Stel dat een model de tabel Verkoop heeft met een kolomwaarde voor ProductID die niet bestaat in de gerelateerde tabel Product.For example, consider a model Sales table with a ProductID column value that did not exist in the related Product table. Bij het doorgeven van filters uit de tabel Product naar de tabel Verkoop worden verkooprijen voor onbekende producten verwijderd.Filter propagation from the Product table to the Sales table will eliminate sales rows for unknown products. Dit zou resulteren in een negatief beeld van de verkoopresultaten.This would result in an understatement of the sales results.

Lees het artikel Instellingen voor referentiële integriteit aannemen in Power BI Desktop voor meer informatie.For more information, see the Assume referential integrity settings in Power BI Desktop article.

Relevante DAX-functiesRelevant DAX functions

Er zijn verschillende DAX-functies die relevant zijn voor modelrelaties.There are several DAX functions that are relevant to model relationships. In de volgende lijst wordt elke functie kort beschreven:Each function is described briefly in the following bulleted list:

  • RELATED: Hiermee haalt u de waarde op uit de 'een'-zijde.RELATED: Retrieves the value from "one" side.
  • RELATEDTABLE: Hiermee haalt u een tabel met rijen op van de 'veel'-zijde.RELATEDTABLE: Retrieve a table of rows from "many" side.
  • USERELATIONSHIP: Hiermee wordt het gebruik van een specifieke inactieve modelrelatie geforceerd.USERELATIONSHIP: Forces the use of a specific inactive model relationship.
  • CROSSFILTER: Hiermee wijzigt u de richting van de relatie tussen filters (van enkel naar beide), of wordt het doorgeven van filters uitgeschakeld (geen).CROSSFILTER: Modifies the relationship cross filter direction (to one or both), or it disables filter propagation (none).
  • COMBINEVALUES: Hiermee worden twee of meer tekenreeksen samengevoegd tot één tekenreeks.COMBINEVALUES: Joins two or more text strings into one text string. Het doel van deze functie is ondersteuning bieden aan relaties tussen DirectQuery-modellen met meerdere kolommen.The purpose of this function is to support multi-column relationships in DirectQuery models.
  • TREATAS: Hiermee wordt het resultaat van een tabelexpressie toegepast als filters voor kolommen uit een losgekoppelde tabel.TREATAS: Applies the result of a table expression as filters to columns from an unrelated table.
  • Bovenliggende en onderliggende functies: Een groep verwante functies die kunnen worden gebruikt om berekende kolommen te genereren voor het maken van een hiërarchie met boven- en onderliggende elementen.Parent and Child functions: A family of related functions that can be used to generate calculated columns to naturalize a parent-child hierarchy. Deze kolommen kunnen vervolgens worden gebruikt voor het maken van een hiërarchie met een vast niveau.These columns can then be used to create a fixed-level hierarchy.

Relaties evaluerenRelationship evaluation

Modelrelaties worden bij een evaluatie geclassificeerd als sterk of zwak.Model relationships, from an evaluation perspective, are classified as either strong or weak. Dit is geen configureerbare relatie-eigenschap.It's not a configurable relationship property. Het wordt in feite afgeleid van het type kardinaliteit en de gegevensbron van de twee gerelateerde tabellen.It is in fact inferred from the cardinality type and the data source of the two related tables. Het is belangrijk om inzicht te krijgen in het evaluatietype omdat de prestaties kunnen worden beïnvloed als de gegevensintegriteit wordt aangetast.It's important to understand the evaluation type because there may be performance implications or consequences should data integrity be compromised. Deze implicaties en gevolgen voor de integriteit worden in dit onderwerp beschreven.These implications and integrity consequences are described in this topic.

Allereerst is het belangrijk dat u enige theoretische kennis over modellen hebt om de evaluatie van relaties volledig te begrijpen.First, some modeling theory is required to fully understand relationship evaluations.

Een Import- of DirectQuery-model haalt alle gegevens uit de Vertipaq-cache of de brondatabase.An Import or DirectQuery model sources all of its data from either the Vertipaq cache or the source database. In beide gevallen kan Power BI bepalen dat er een 'een'-zijde van een relatie bestaat.In both instances, Power BI is able to determine that a "one" side of a relationship exists.

Een samengesteld model kan echter bestaan uit tabellen die gebruikmaken van verschillende opslagmodi (Import, DirectQuery of Dual), of meerdere DirectQuery-bronnen.A Composite model, however, can comprise tables using different storage modes (Import, DirectQuery or Dual), or multiple DirectQuery sources. Elke bron, met inbegrip van de Vertipaq-cache voor Import-gegevens, wordt beschouwd als een gegevenseiland.Each source, including the Vertipaq cache of Import data, is considered to be a data island. Modelrelaties kunnen vervolgens worden geclassificeerd als intra-eiland of kruis-eiland.Model relationships can then be classified as intra-island or cross-island. Met een intra-eilandrelatie worden twee tabellen in een gegevenseiland gekoppeld, terwijl een kruis-eilandrelatie tabellen uit verschillende gegevenseilanden verbindt.An intra-island relationship is one that relates two tables within a data island, while a cross-island relationship relates tables from different data islands. Houd er rekening mee dat relaties in Import- of DirectQuery-modellen altijd intra-eiland zijn.Note that relationships in Import or DirectQuery models are always intra-island.

Laten we een voorbeeld van een samengesteld model bekijken.Let's see an example of a Composite model.

Voorbeeld van een samengesteld model dat bestaat uit twee eilanden

In dit voor beeld bestaat het samengestelde model uit twee eilanden: een Vertipaq-gegevenseiland en een DirectQuery-brongegevenseiland.In this example, the Composite model consists of two islands: a Vertipaq data island and a DirectQuery source data island. Het Vertipaq-gegevenseiland bevat drie tabellen en het DirectQuery-brongegevenseiland bevat twee tabellen.The Vertipaq data island contains three tables, and the DirectQuery source data island contains two tables. Er bestaat één kruis-eilandrelatie om een tabel in het Vertipaq-gegevenseiland te koppelen aan een tabel in het DirectQuery-brongegevenseiland.One cross-island relationship exists to relate a table in the Vertipaq data island to a table in the DirectQuery source data island.

Sterke relatiesStrong relationships

Een modelrelatie is sterk wanneer de query-engine de 'een'-zijde van de relatie kan bepalen.A model relationship is strong when the query engine can determine the "one" side of relationship. Er wordt bevestigd dat de 'een'-zijde enkele waarden bevat.It has confirmation that the "one" side column contains unique values. Alle een-op-veel-relaties binnen eilanden zijn een sterke relatie.All One-to-many intra-island relationships are strong relationships.

Het volgende voorbeeld bevat twee sterke relaties, gemarkeerd met een S. Deze relaties zijn de een-op-veel-relatie in het Vertipaq-eiland en de een-op-veel-relatie in de DirectQuery-bron.In the following example, there are two strong relationships, both marked as S. Relationships include the One-to-many relationship contained within the Vertipaq island, and the One-to-many relationship contained within the DirectQuery source.

Voorbeeld van een samengesteld model dat bestaat uit twee eilanden waarbij de sterke relaties zijn gemarkeerd

Bij Import-modellen, waarbij alle gegevens worden opgeslagen in de Vertipaq-cache, wordt bij het vernieuwen van gegevens een gegevensstructuur gemaakt voor elke sterke relatie.For Import models, where all data is stored in the Vertipaq cache, a data structure is created for each strong relationship at data refresh time. De gegevensstructuren bestaan uit geïndexeerde toewijzingen van alle kolom-naar-kolom-waarden. Het doel hiervan is het koppelen van tabellen tijdens het uitvoeren van query's te versnellen.The data structures consist of indexed mappings of all column-to-column values, and their purpose is to accelerate joining tables at query time.

Bij het uitvoeren van query's kunnen tabeluitbreidingen worden uitgevoerd voor sterke tabellen.At query time, strong relationships permit table expansion to take place. Tabeluitbreiding resulteert in het maken van een virtuele tabel. Hierin worden de systeemeigen kolommen van de basistabel opgenomen en deze worden vervolgens uitgebreid naar gekoppelde tabellen.Table expansion results in the creation of a virtual table by including the native columns of the base table and then expanding into related tables. Bij Import-tabellen wordt dit gedaan in de query-engine. Bij DirectQuery-tabellen wordt dit gedaan in de systeemeigen query die wordt verzonden naar de brondatabase (zolang de eigenschap Referentiële integriteit aannemen niet is ingeschakeld.For Import tables, it's done in the query engine; for DirectQuery tables it is done in the native query sent to the source database (as long as the Assume referential integrity property isn't enabled). De query-engine past vervolgens de filters toe op de uitgebreide tabel en groepeert de waarden in de kolommen van deze tabel.The query engine then acts upon the expanded table, applying filters and grouping by the values in the expanded table columns.

Notitie

Inactieve relaties worden ook uitgebreid, zelfs wanneer de relatie niet wordt gebruikt door een berekening.Inactive relationships are expanded also, even when the relationship isn't used by a calculation. Bidirectionele relaties hebben geen invloed op tabeluitbreiding.Bi-directional relationships have no impact on table expansion.

Bij een-op-veel-relaties vindt tabeluitbreiding plaats van de 'veel'-zijde naar de 'een'-zijde door gebruik te maken van de semantiek van LEFT OUTER JOIN.For One-to-many relationships, table expansion takes place from the "many" to the "one" sides by using LEFT OUTER JOIN semantics. Als er geen overeenkomende waarde bestaat tussen de 'veel'-zijde en de 'een'-zijde, wordt er een lege virtuele rij toegevoegd aan de 'een'-zijde van de tabel.When a matching value from the "many" to the "one" side doesn't exist, a blank virtual row is added to the "one" side table.

Tabeluitbreidingen vinden ook plaats voor een-op-een-relaties binnen eilanden, maar met behulp van de semantiek FULL OUTER JOIN.Table expansion also occurs for One-to-one intra-island relationships, but by using FULL OUTER JOIN semantics. Het zorgt ervoor dat lege virtuele rijen aan beide zijden worden toegevoegd als dat nodig is.It ensures that blank virtual rows are added on either side, when necessary.

De lege virtuele rijen worden onbekende leden.The blank virtual rows are effectively Unknown Members. Onbekende leden vertegenwoordigen schendingen van referentiële integriteit, waarbij de 'veel'-zijde geen bijbehorende waarde heeft aan de 'een'-zijde.Unknown members represent referential integrity violations where the "many" side value has no corresponding "one" side value. In het ideale geval zijn deze lege items niet aanwezig en ze kunnen worden verwijderd door de brongegevens op te schonen of te herstellen.Ideally these blanks should not exist, and they can be eliminated by cleansing or repairing the source data.

Laten we eens kijken hoe tabeluitbreidingen werken aan de hand van een geanimeerd voorbeeld.Let's see how table expansion works with an animated example.

Geanimeerd voorbeeld van tabeluitbreiding

In dit voorbeeld bestaat het model uit drie tabellen: Categorie, Product en Verkoop.In this example, the model consists of three tables: Category, Product, and Sales. De tabel Categorie is gekoppeld aan de tabel Product met een een-op-veel-relatie en de tabel Product is gekoppeld aan de tabel Verkoop met een een-op-veel-relatie.The Category table relates to the Product table with a One-to-many relationship, and the Product table relates to the Sales table with a One-to-many relationship. De tabel Categorie bevat twee rijen, de tabel Product bevat drie rijen en de tabellen Verkoop bevatten vijf rijen.The Category table contains two rows, the Product table contains three rows, and the Sales tables contains five rows. Er zijn overeenkomende waarden aan beide zijden van alle relaties, wat betekent dat er geen schendingen van de referentiële integriteit zijn.There are matching values on both sides of all relationships meaning that there are no referential integrity violations. Tijdens het uitvoeren van de query wordt er een uitgebreide tabel getoond.A query-time expanded table is revealed. De tabel bestaat uit de kolommen van alle drie de tabellen.The table consists of the columns from all three tables. Het is in feite een gedenormaliseerd perspectief van de gegevens in de drie tabellen.It's effectively a denormalized perspective of the data contained in the three tables. Er wordt een nieuwe rij toegevoegd aan de tabel Verkoop en deze heeft een productie-id-waarde (9) die geen overeenkomende waarde bevat in de tabel Product.A new row is added to the Sales table, and it has a production identifier value (9) that has no matching value in the Product table. Dit is een schending van de referentiële integriteit.It's a referential integrity violation. In de uitgebreide tabel bevat de nieuwe rij (lege) waarden in de kolommen van de tabellen Categorie en Product.In the expanded table, the new row has (Blank) values for the Category and Product table columns.

Zwakke relatiesWeak relationships

Een model relatie is zwak wanneer er geen gegarandeerde 'een'-zijde is.A model relationship is weak when there's no guaranteed "one" side. Dit kan twee oorzaken hebben:It can be the case for two reasons:

  • De relatie maakt gebruik van het type kardinaliteit veel-op-veel (zelfs als een of beide kolommen enkele waarden bevatten)The relationship uses a Many-to-many cardinality type (even if one or both columns contain unique values)
  • Het is een kruis-eilandrelatie (wat alleen het geval kan zijn bij gecombineerde modellen)The relationship is cross-island (which can only ever be the case for Composite models)

Het volgende voorbeeld bevat twee zwakke relaties, gemarkeerd met een Z. Deze twee relaties zijn de veel-op-veel-relatie in het Vertipaq-eiland en de een-op-veel-relatie tussen eilanden in de DirectQuery-bron.In the following example, there are two weak relationships, both marked as W. The two relationships include the Many-to-many relationship contained within the Vertipaq island, and the One-to-many cross-island relationship.

Voorbeeld van een samengesteld model dat bestaat uit twee eilanden waarbij de zwakke relaties zijn gemarkeerd

Bij Import-modellen worden nooit gegevensstructuren voor zwakke relaties gemaakt.For Import models, data structures are never created for weak relationships. Dit betekent dat tabelsamenvoegingen moeten worden opgelost tijdens het uitvoeren van de query.This means table joins must be resolved at query time.

Tabeluitbreidingen vindt nooit plaats voor zwakke relaties.Table expansion never occurs for weak relationships. Tabellen worden samengevoegd met behulp van de semantiek INNER JOIN en daarom worden er geen lege virtuele rijen toegevoegd om schendingen van de referentiële integriteit te compenseren.Table joins are achieved by using INNER JOIN semantics, and for this reason, blank virtual rows are not added to compensate for referential integrity violations.

Er gelden extra beperkingen voor zwakke relaties:There are additional restrictions related to weak relationships:

  • De DAX-functie RELATED kan niet worden gebruikt om de kolomwaarden van de 'een'-zijde op te halenThe RELATED DAX function can't be used to retrieve the "one" side column values
  • Het afdwingen van beveiliging op rijniveau heeft topologische beperkingenEnforcing RLS has topology restrictions

Notitie

In de modelweergave van Power BI Desktop is het niet altijd mogelijk om te bepalen of een modelrelatie sterk of zwak is.In Power BI Desktop model view, it's not always possible to determine whether a model relationship is strong or weak. Een veel-op-veel-relatie is altijd zwak, evenals een een-op-veel-relatie wanneer het een kruis-eilandrelatie is.A Many-to-many relationship will always be weak, as is a One-to-many relationship when it's a cross-island relationship. Als u wilt bepalen of er sprake is van een kruis-eilandrelatie, moet u de opslagmodi en gegevensbronnen van de tabel controleren om de juiste conclusie te kunnen trekken.To determine whether it's a cross-island relationship, you'll need to inspect the table storage modes and data sources to arrive at the correct determination.

PrioriteitsregelsPrecedence rules

Bidirectionele relaties kunnen leiden tot meerdere, en daardoor dubbelzinnige paden voor het doorgeven van filters tussen modeltabellen.Bi-directional relationships can introduce multiple—and therefore ambiguous—filter propagation paths between model tables. De volgende lijst geeft een overzicht van de prioriteitsregels die Power BI gebruikt voor het detecteren van dubbelzinnigheid en het oplossen van paden:The following list presents precedence rules that Power BI uses for ambiguity detection and path resolution:

  1. Veel-op-een- en een-op-een-relaties, met inbegrip van zwakke relatiesMany-to-one and One-to-one relationships, including weak relationships
  2. Veel-op-veel-relatiesMany-to-many relationships
  3. Bidirectionele relaties, in omgekeerde richting (vanuit de 'veel'-zijde)Bi-directional relationships, in the reverse direction (that is, from the "Many" side)

Voorkeuren voor prioriteitPerformance preference

De volgende lijst geeft een overzicht van de prestaties bij het doorgeven van filters, van de snelste tot de langzaamste prestaties:The following list orders filter propagation performance, from fastest to slowest performance:

  1. Een-op-veel-relaties binnen een eilandOne-to-many intra-island relationships
  2. Veel-op-veel-kardinaliteitsrelatiesMany-to-many cardinality relationships
  3. Veel-op-veel-modelrelaties die tot stand zijn gebracht met een intermediaire tabel en die ten minste één bidirectionele relatie bevattenMany-to-many model relationships achieved with an intermediary table and that involves at least one bi-directional relationship
  4. Relaties tussen eilandenCross-island relationships

Volgende stappenNext steps

Bekijk de volgende bronnen voor meer informatie over dit artikel:For more information about this article, check out the following resources: