Veel-op-veel-relaties toepassen in Power BI DesktopApply many-many relationships in Power BI Desktop

Met relaties met veel-op-veel-kardinaliteit in Power BI Desktop kunt u tabellen samenvoegen die gebruikmaken van de kardinaliteit Veel-op-veel.With relationships with a many-many cardinality in Power BI Desktop, you can join tables that use a cardinality of many-to-many. U kunt gemakkelijker en intuïtief gegevensmodellen maken die twee of meer gegevensbronnen bevatten.You can more easily and intuitively create data models that contain two or more data sources. Relaties met een veel-op-veel-kardinaliteit maken deel uit van de overkoepelende voorziening voor samengestelde modellen in Power BI Desktop.Relationships with a many-many cardinality are part of the larger composite models capabilities in Power BI Desktop.

Een veel-op-veel-relatie in het deelvenster 'Relatie bewerken', Power BI Desktop

Een relatie met een veel-op-veel-kardinaliteit in Power BI Desktop bestaat uit drie gerelateerde functies:A relationship with a many-many cardinality in Power BI Desktop is composed of one of three related features:

  • Samengestelde modellen: Met een samengesteld model wordt het mogelijk dat een rapport twee of meer gegevensverbindingen heeft, inclusief DirectQuery-verbindingen of importverbindingen, in elke gewenste combinatie.Composite models: A composite model allows a report to have two or more data connections, including DirectQuery connections or Import, in any combo. Zie Samengestelde modellen in Power BI Desktop gebruiken voor meer informatie.For more information, see Use composite models in Power BI Desktop.

  • Relaties met een veel-op-veel-kardinaliteit: met samengestelde modellen kunt u relaties met een veel-op-veel-kardinaliteit tussen tabellen tot stand brengen.Relationships with a many-many cardinality: With composite models, you can establish relationships with a many-many cardinality between tables. Door deze aanpak hoeven tabellen geen unieke waarden meer te bevatten.This approach removes requirements for unique values in tables. Ook zijn eerdere tijdelijke oplossingen niet meer nodig, zoals de introductie van nieuwe tabellen alleen maar om relaties tot stand te brengen.It also removes previous workarounds, such as introducing new tables only to establish relationships. De functie wordt verderop in dit artikel beschreven.The feature is described further in this article.

  • Opslagmodus: u kunt nu opgeven voor welke visualisaties een query naar de back-endgegevensbronnen is vereist.Storage mode: You can now specify which visuals require a query to back-end data sources. Visuals waarvoor geen query is vereist, worden geïmporteerd zelfs als ze zijn gebaseerd op DirectQuery.Visuals that don't require a query are imported even if they're based on DirectQuery. De functie helpt de prestaties te verbeteren en de back-end minder te belasten.This feature helps improve performance and reduce back-end load. Eerder werden zelfs voor eenvoudige visuals, zoals slicers, query's verzonden naar back-endbronnen.Previously, even simple visuals, such as slicers, began queries that were sent to back-end sources. Zie Opslagmodus in Power BI Desktop voor meer informatie.For more information, see Storage mode in Power BI Desktop.

Wat u met een relatie met een veel-op-veel-kardinaliteit kunt oplossenWhat a relationship with a many-many cardinality solves

Voordat er relaties met een veel-op-veel-kardinaliteit beschikbaar waren, werd de relatie tussen twee tabellen gedefinieerd in Power BI.Before relationships with a many-many cardinality became available, the relationship between two tables was defined in Power BI. Ten minste één van de tabelkolommen in de relatie moest unieke waarden bevatten.At least one of the table columns involved in the relationship had to contain unique values. Vaak bevatte echter geen enkele kolom unieke waarden.Often, though, no columns contained unique values.

Twee tabellen hebben bijvoorbeeld een kolom met het label Land.For example, two tables might have had a column labeled Country. De waarden van Land zijn echter in geen van beide tabellen uniek.The values of Country weren't unique in either table, though. Er was een tijdelijke oplossing nodig om zulke tabellen samen te voegen.To join such tables, you had to create a workaround. Een tijdelijke oplossing is het maken van extra tabellen met de benodigde unieke waarden.One workaround might be to introduce extra tables with the needed unique values. Met relaties met een veel-op-veel-kardinaliteit kunt u deze tabellen direct samenvoegen met behulp van een relatie met de kardinaliteit veel-op-veel.With relationships with a many-many cardinality, you can join such tables directly, if you use a relationship with a cardinality of many-to-many.

Relaties met een veel-op-veel-kardinaliteit gebruikenUse relationships with a many-many cardinality

Als u een relatie tussen twee tabellen wilt definiëren in Power BI, moet u de kardinaliteit van de relatie opgeven.When you define a relationship between two tables in Power BI, you must define the cardinality of the relationship. De relatie tussen ProductSales en Product—met de kolommen ProductSales[ProductCode] en Product[ProductCode]—zou bijvoorbeeld worden gedefinieerd als Veel-1.For example, the relationship between ProductSales and Product—using columns ProductSales[ProductCode] and Product[ProductCode]—would be defined as Many-1. De relatie wordt op deze manier gedefinieerd omdat er voor elk product veel verkopen zijn en de kolom in de tabel Product (ProductCode) uniek is.We define the relationship in this way, because each product has many sales, and the column in the Product table (ProductCode) is unique. Als u een relatiekardinaliteit definieert als Veel-1, 1-veel of 1-1 wordt dit door Power BI gevalideerd, zodat de kardinaliteit die u selecteert overeenkomt met de werkelijke de gegevens.When you define a relationship cardinality as Many-1, 1-Many, or 1-1, Power BI validates it, so the cardinality that you select matches the actual data.

Laten we eens kijken naar het eenvoudige model in deze afbeelding:For example, take a look at the simple model in this image:

Tabellen ProductSales en Product, weergave Relatie, Power BI Desktop

Stel nu dat de tabel Product slechts twee rijen bevat, zoals weergegeven:Now, imagine that the Product table displays just two rows, as shown:

Visual van de tabel Product met twee rijen, Power BI Desktop

Laten we er ook van uitgaan dat de tabel Sales maar vier rijen heeft, waaronder een voor een product C. Vanwege een fout met betrekking tot referentiële integriteit komt de rij voor product C niet voor in de tabelProduct.Also imagine that the Sales table has just four rows, including a row for a product C. Because of a referential integrity error, the product C row doesn't exist in the Product table.

Visual van de tabel Sales met vier rijen, Power BI Desktop

De ProductName en Price (uit de tabel Product), samen met het totale aantal Qty voor elk product (uit de tabel ProductSales), zou als volgt worden weergegeven:The ProductName and Price (from the Product table), along with the total Qty for each product (from the ProductSales table), would be displayed as shown:

Visual met de productnaam, prijs en hoeveelheid, Power BI Desktop

Zoals u in de vorige afbeelding ziet, is er een lege rij ProductName, die is gekoppeld aan de verkoop van product C. Deze lege rij vertegenwoordigt het volgende:As you can see in the preceding image, a blank ProductName row is associated with sales for product C. This blank row accounts for the following:

  • Alle rijen in de tabel ProductSales waarvoor geen overeenkomende rij bestaat in de tabel Product.Any rows in the ProductSales table for which no corresponding row exists in the Product table. Er is een probleem met betrekking tot referentiële integriteit, zoals we in dit voorbeeld zien voor product C.There's a referential integrity issue, as we see for product C in this example.

  • Alle rijen in de tabel ProductSales waarvoor de kolom met de refererende sleutel null is.Any rows in the ProductSales table for which the foreign key column is null.

Om deze redenen vertegenwoordigt de lege rij in beide gevallen verkopen waarvoor de ProductName en Price onbekend zijn.For these reasons, the blank row in both cases accounts for sales where the ProductName and Price are unknown.

Soms worden de tabellen samengevoegd via twee kolommen, maar is geen van beide kolommen uniek.Sometimes the tables are joined by two columns, yet neither column is unique. Laten we maar eens kijken naar de volgende twee tabellen:For example, consider these two tables:

  • De tabel Sales bevat verkoopgegevens per State. Elke rij bevat de omzet voor het type verkoop in die staat.The Sales table displays sales data by State, and each row contains the sales amount for the type of sale in that state. De staten zijn CA, WA en TX.The states include CA, WA, and TX.

    De tabel Sales met de verkoop per staat, Power BI Desktop

  • De tabel CityData bevat gegevens van steden, waaronder het aantal inwoners en de staat (zoals CA, WA en New York).The CityData table displays data on cities, including the population and state (such as CA, WA, and New York).

    De tabel Sales met de stad, staat en het aantal inwoners, Power BI Desktop

Beide tabellen bevatten nu de kolom State.A column for State is now in both tables. Het is handig om een rapport te maken van zowel de totale verkoop per staat als het totale inwonertal van elke staat.It's reasonable to want to report on both total sales by state and total population of each state. Er bestaat echter een probleem: de kolom State is in geen van de tabellen uniek.However, a problem exists: the State column isn't unique in either table.

De vorige tijdelijke oplossingThe previous workaround

Voor de versie van Power BI Desktop van juli 2018 konden gebruikers geen directe relatie tussen deze tabellen maken.Before the July 2018 release of Power BI Desktop, you couldn't create a direct relationship between these tables. Een veelgebruikte tijdelijke oplossing voor dit probleem was:A common workaround was to:

  • Maak een derde tabel die alleen de unieke id's voor State bevat.Create a third table that contains only the unique State IDs. Het mag een of alle van de volgende tabellen zijn:The table could be any or all of:

    • Een berekende tabel (gedefinieerd met behulp van Data Analysis Expressions (DAX)).A calculated table (defined by using Data Analysis Expressions [DAX]).
    • Een tabel op basis van een query die is gedefinieerd in Query-editor, met de unieke id's die zijn opgehaald uit een van de tabellen.A table based on a query that's defined in Query Editor, which could display the unique IDs drawn from one of the tables.
    • De gecombineerde volledige set.The combined full set.
  • Koppel de twee oorspronkelijke tabellen vervolgens aan de nieuwe tabel door algemene Veel-1-relaties te gebruiken.Then relate the two original tables to that new table by using common Many-1 relationships.

U kunt de tijdelijke tabel zichtbaar laten.You could leave the workaround table visible. Of u kunt de tijdelijke tabel verbergen, zodat deze niet wordt weergegeven in de lijst Velden.Or you may hide the workaround table, so it doesn't appear in the Fields list. Als u de tabel verbergt, worden de Veel-1-relaties gewoonlijk ingesteld op filteren in beide richtingen en u kunt het veld State uit elk van de tabellen gebruiken.If you hide the table, the Many-1 relationships would commonly be set to filter in both directions, and you could use the State field from either table. Het daaropvolgende kruislingse filteren wordt doorgeven aan de andere tabel.The later cross filtering would propagate to the other table. Deze aanpak wordt weergegeven in de volgende afbeelding:That approach is shown in the following image:

Verborgen tabel State, weergave Relatie, Power BI Desktop

Een visualisatie met State (uit de tabel CityData), samen met het totale aantal inwoners (Population) en de totale omzet (Sales) ziet er dan zo uit:A visual that displays State (from the CityData table), along with total Population and total Sales, would then appear as follows:

Tabellen State, Population en Sales, Power BI Desktop

Notitie

Omdat in deze tijdelijke oplossing de staat uit de tabel CityData wordt gebruikt, worden alleen de staten in die tabel weergegeven en wordt TX dus uitgesloten.Because the state from the CityData table is used in this workaround, only the states in that table are listed, so TX is excluded. In tegenstelling tot Veel-1-relaties bevat de totaalrij wel alle Sales, inclusief die van TX, maar bevatten de details geen lege rij om rijen zonder overeenkomst te vertegenwoordigen.Also, unlike Many-1 relationships, while the total row includes all Sales (including those of TX), the details don't include a blank row covering such mismatched rows. Zo is er ook geen lege rij voor Sales met een null-waarde voor de State.Similarly, no blank row would cover Sales for which there's a null value for the State.

Stel dat u ook een plaats toevoegt aan die visual.Suppose you also add City to that visual. In Sales voor City worden gewoon de Sales voor de bijbehorende State herhaald, ook al is de bevolking per City wel bekend.Although the population per City is known, the Sales shown for City simply repeats the Sales for the corresponding State. Dit scenario treedt normaal gesproken op wanneer de groepering van kolommen niet is gerelateerd aan een statistische meting, zoals hier wordt weergegeven:This scenario normally occurs when the column grouping is unrelated to some aggregate measure, as shown here:

Staat, bevolking van de stad en verkoop, Power BI Desktop

Stel dat u de nieuwe tabel Sales definieert als de combinatie van alle staten die hier worden vermeld en dat u deze zichtbaar maakt in de lijst Velden.Let's say you define the new Sales table as the combination of all States here, and we make it visible in the Fields list. In dezelfde visual worden State (in de nieuwe tabel), de totale Population en de totale Sales weergegeven:The same visual would display State (on the new table), the total Population, and total Sales:

De visual voor staat, bevolking en verkoop, Power BI Desktop

Zoals u ziet, is TX— afgebeeld met Sales-gegevens, maar onbekende Population-gegevens— en is —New Yorkafgebeeld met bekendePopulation -gegevens, maar zonder Sales—-gegevens.As you can see, TX—with Sales data but unknown Population data—and New York—with known Population data but no Sales data—would be included. Deze oplossing is niet optimaal en veroorzaakt veel problemen.This workaround isn't optimal, and it has many issues. Voor relaties met een veel-op-veel-kardinaliteit kunnen de resulterende problemen worden opgelost, zoals beschreven in de volgende sectie.For relationships with a many-many cardinality, the resulting issues are addressed, as described in the next section.

Een relatie met een veel-op-veel-kardinaliteit gebruiken in plaats van de tijdelijke oplossingUse a relationship with a many-many cardinality instead of the workaround

Vanaf de versie van juli 2018 van Power BI Desktop kunt u tabellen, zoals degene die eerder zijn beschreven, rechtstreeks koppelen, zonder dat u gebruik hoeft te maken van vergelijkbare tijdelijke oplossingen.With the July 2018 version of Power BI Desktop, you can directly relate tables, such as the ones we described earlier, without having to resort to similar workarounds. Het is nu mogelijk om de relatiekardinaliteit in te stellen als Veel-op-veel.It's now possible to set the relationship cardinality to many-to-many. Deze instelling geeft aan dat geen van beide tabellen unieke waarden bevat.This setting indicates that neither table contains unique values. Voor dergelijke relaties kunt u nog steeds bepalen met welke tabel de andere tabel wordt gefilterd.For such relationships, you may still control which table filters the other table. U kunt ook bidirectionele filters toepassen, waarbij elke tabel door de andere tabel wordt gefilterd.Or you can apply bidirectional filtering, where each table filters the other.

In Power BI Desktop wordt de kardinaliteit standaard ingesteld op Veel-op-veel als is vastgesteld dat geen van beide tabellen unieke waarden bevat voor de kolommen in de relatie.In Power BI Desktop, the cardinality defaults to many-to-many when it determines neither table contains unique values for the relationship columns. In dergelijke gevallen bevestigt een waarschuwingsbericht dat u een relatie wilt instellen; de wijziging is niet het onbedoelde effect van een probleem met gegevens.In such cases, a warning message confirms you want to set a relationship, and the change isn't the unintended effect of a data issue.

Als u bijvoorbeeld een rechtstreekse relatie maakt tussen CityData en Sales—waarbij filters moeten worden doorgegeven van CityData naar Sales—wordt in Power BI Desktop het dialoogvenster Relatie bewerken weergegeven:For example, when you create a relationship directly between CityData and Sales—where filters should flow from CityData to Sales—Power BI Desktop displays the Edit relationship dialog box:

Het dialoogvenster Relatie bewerken, Power BI Desktop

De resulterende Relatie-weergave bevat dan de directe veel-op-veelrelatie tussen de twee tabellen.The resulting Relationship view would then display the direct, many-to-many relationship between the two tables. De weergave van de tabellen in de lijst Velden en het daaropvolgende gedrag bij het maken van de visuals, is vergelijkbaar met die na het toepassen van de tijdelijke oplossing.The tables' appearance in the Fields list, and their later behavior when the visuals are created, are similar to when we applied the workaround. In de tijdelijke oplossing wordt de extra tabel die de afzonderlijke State-gegevens bevat, niet zichtbaar gemaakt.In the workaround, the extra table that displays the distinct State data isn't made visible. Zoals eerder beschreven, wordt een visual met gegevens over State, Population en Sales weergegeven:As described earlier, a visual that shows State, Population, and Sales data would be displayed:

Tabellen State, Population en Sales, Power BI Desktop

Hier volgen de belangrijkste verschillen tussen relaties met een veel-op-veel-kardinaliteit en de meer gebruikelijke Veel-1-relaties:The major differences between relationships with a many-many cardinality and the more typical Many-1 relationships are as follows:

  • De weergegeven waarden bevatten geen lege rij die de niet-overeenkomende rijen in de andere tabel vertegenwoordigt.The values shown don't include a blank row that accounts for mismatched rows in the other table. Ook vertegenwoordigen de waarden geen rijen waarvan de kolom die in de relatie in de andere tabel wordt gebruikt, null is.Also, the values don't account for rows where the column used in the relationship in the other table is null.

  • U kunt de functie RELATED() niet gebruiken, aangezien meer dan één rij gerelateerd kan zijn.You can't use the RELATED() function, because more than one row could be related.

  • Het gebruik van de functie ALL() voor een tabel betekent niet dat filters worden verwijderd die zijn toegepast op andere tabellen die via een veel-op-veelrelatie zijn gerelateerd.Using the ALL() function on a table doesn't remove filters that are applied to other, related tables by a many-to-many relationship. In het voorgaande voorbeeld heeft een meting die is gedefinieerd zoals hier is weergegeven, niet tot gevolg dat filters voor kolommen in de gerelateerde tabel CityData worden verwijderd:In the preceding example, a measure that's defined as shown here wouldn't remove filters on columns in the related CityData table:

    Voorbeeld van een script

    Een visual met de gegevens State-, Sales- en Sales total zou dan deze grafische afbeelding opleveren:A visual showing State, Sales, and Sales total data would result in this graphic:

    Visual van tabel

Zorg er, met de voorgaande verschillen in gedachten, voor dat de berekeningen die gebruikmaken van ALL(<Table>), zoals % van eindtotaal, de beoogde resultaten retourneren.With the preceding differences in mind, make sure the calculations that use ALL(<Table>), such as % of grand total, are returning the intended results.

Beperkingen en overwegingenLimitations and considerations

Er gelden enkele beperkingen voor deze relaties met een veel-op-veel-kardinaliteit en samengestelde modellen.There are a few limitations for this release of relationships with a many-many cardinality and composite models.

De volgende, multidimensionale Live Connect-bronnen kunnen niet worden gebruikt met samengestelde modellen:The following Live Connect (multidimensional) sources can't be used with composite models:

  • SAP HANASAP HANA
  • SAP Business WarehouseSAP Business Warehouse
  • SQL Server Analysis ServicesSQL Server Analysis Services
  • Power BI-gegevenssetsPower BI datasets
  • Azure Analysis ServicesAzure Analysis Services

Als u met behulp van DirectQuery verbinding maakt met deze multidimensionale bronnen, is het niet mogelijk om verbinding te maken met een andere DirectQuery-bron of deze te combineren met geïmporteerde gegevens.When you connect to these multidimensional sources by using DirectQuery, you can't connect to another DirectQuery source or combine it with imported data.

De bestaande beperkingen voor het gebruik van DirectQuery gelden nog steeds wanneer u relaties met een veel-op-veel-kardinaliteit gebruikt.The existing limitations of using DirectQuery still apply when you use relationships with a many-many cardinality. Veel van deze beperkingen gelden nu per tabel, al naargelang de opslagmodus van de tabel.Many limitations are now per table, depending upon the storage mode of the table. Zo kan een berekende kolom in een geïmporteerde tabel verwijzen naar andere tabellen, maar kan een berekende kolom in een DirectQuery-tabel nog steeds alleen verwijzen naar kolommen in dezelfde tabel.For example, a calculated column on an imported table can refer to other tables, but a calculated column on a DirectQuery table can still refer only to columns on the same table. Andere beperkingen gelden voor het gehele model als een van de tabellen in het model DirectQuery gebruikt.Other limitations apply to the whole model if any tables within the model are DirectQuery. De functies QuickInsights en Q&A zijn bijvoorbeeld niet beschikbaar voor een model als een van de tabellen in het model de opslagmodus DirectQuery heeft.For example, the QuickInsights and Q&A features are unavailable on a model if any table within it has a storage mode of DirectQuery.

Volgende stappenNext steps

Zie de volgende artikelen voor meer informatie over samengestelde modellen en DirectQuery:For more information about composite models and DirectQuery, see the following articles: