Veel-op-veel-relaties toepassen in Power BI Desktop

  • Artikel

Met relaties met een veel-op-veel-kardinaliteit in Power BI Desktop kunt u tabellen samenvoegen die gebruikmaken van een kardinaliteit van veel-op-veel. U kunt eenvoudiger en intuïtiever gegevensmodellen maken die twee of meer gegevensbronnen bevatten. Relaties met een veel-op-veel-kardinaliteit maken deel uit van de grotere mogelijkheden van samengestelde modellen in Power BI Desktop. Zie Samengestelde modellen gebruiken in Power BI Desktop voor meer informatie over samengestelde modellen

Screenshot of a many-to-many relationship in the Edit relationship pane.

Wat een relatie met een veel-op-veel-kardinaliteit oplost

Voordat relaties met een veel-op-veel-kardinaliteit beschikbaar werden, is de relatie tussen twee tabellen gedefinieerd in Power BI. Ten minste één van de tabelkolommen in de relatie moest unieke waarden bevatten. Vaak bevatten geen kolommen echter unieke waarden.

Twee tabellen hebben bijvoorbeeld een kolom met het label CountryRegion. De waarden van CountryRegion waren echter niet uniek in beide tabellen. Als u dergelijke tabellen wilt samenvoegen, moest u een tijdelijke oplossing maken. Een tijdelijke oplossing is het introduceren van extra tabellen met de benodigde unieke waarden. Met relaties met een veel-op-veel-kardinaliteit kunt u dergelijke tabellen rechtstreeks samenvoegen als u een relatie met een kardinaliteit van veel-op-veel gebruikt.

Relaties gebruiken met een veel-op-veel-kardinaliteit

Wanneer u een relatie tussen twee tabellen in Power BI definieert, moet u de kardinaliteit van de relatie definiëren. De relatie tussen ProductSales en Product, met behulp van kolommen ProductSales[ProductCode] en Product[ProductCode], wordt bijvoorbeeld gedefinieerd als Veel-1. We definiëren de relatie op deze manier, omdat elk product veel verkopen heeft en de kolom in de tabel Product (ProductCode) uniek is. Wanneer u een relatiekardinaliteit definieert als Veel-1, 1-Veel of 1-1, valideert Power BI deze, zodat de kardinaliteit die u selecteert overeenkomt met de werkelijke gegevens.

Bekijk bijvoorbeeld het eenvoudige model in deze afbeelding:

Screenshot of ProductSales and Product table in Relationship view.

Stel nu dat in de tabel Product slechts twee rijen worden weergegeven, zoals wordt weergegeven:

Screenshot of a Product table visual with two rows.

Stel ook dat de tabel Sales slechts vier rijen heeft, inclusief een rij voor een product C. Vanwege een referentiële integriteitsfout bestaat de product C-rij niet in de tabel Product .

Screenshot of a Sales table visual with four rows.

De ProductName en Price (uit de tabel Product), samen met het totale aantal voor elk product (uit de tabel ProductSales), worden weergegeven zoals weergegeven:

Screenshot of a Visual displaying the product name, price, and quantity.

Zoals u in de vorige afbeelding kunt zien, is er een lege productnaamrij gekoppeld aan de verkoop voor product C. Deze lege rij is een account voor de volgende overwegingen:

  • Rijen in de tabel ProductSales waarvoor geen overeenkomende rij bestaat in de tabel Product . Er is een probleem met referentiële integriteit, zoals we in dit voorbeeld zien voor product C.

  • Rijen in de tabel ProductSales waarvoor de kolom met refererende sleutels null is.

Om deze redenen is de lege rij in beide gevallen verantwoordelijk voor verkoop waarbij de ProductName en Price onbekend zijn.

Soms worden de tabellen samengevoegd door twee kolommen, maar is geen van beide kolommen uniek. Denk bijvoorbeeld aan deze twee tabellen:

  • In de tabel Verkoop worden verkoopgegevens per staat weergegeven en elke rij bevat het verkoopbedrag voor het type verkoop in die staat. De statussen zijn CA, WA en TX.

    Screenshot of a Sales table displaying sales by state.

  • De tabel CityData bevat gegevens over steden, waaronder de bevolking en staat (zoals CA, WA en New York).

    Screenshot of a Sales table displaying city, state, and population.

Een kolom voor State bevindt zich nu in beide tabellen. Het is redelijk om te rapporteren over zowel de totale verkoop per staat als de totale bevolking van elke staat. Er bestaat echter een probleem: de kolom Status is niet uniek in een van beide tabellen.

De vorige tijdelijke oplossing

Vóór de release van juli 2018 van Power BI Desktop kon u geen directe relatie tussen deze tabellen maken. Een veelvoorkomende tijdelijke oplossing was het volgende:

  • Maak een derde tabel die alleen de unieke status-id's bevat. De tabel kan een of meer van de volgende zijn:

    • Een berekende tabel (gedefinieerd met behulp van Data Analysis Expressions [DAX]).
    • Een tabel op basis van een query die is gedefinieerd in Power Query-editor, waarmee de unieke id's uit een van de tabellen kunnen worden weergegeven.
    • De gecombineerde volledige set.

  • Koppel vervolgens de twee oorspronkelijke tabellen aan die nieuwe tabel met behulp van algemene veel-1-relaties .

U kunt de tijdelijke tabel zichtbaar laten. Of u kunt de tijdelijke tabel verbergen, zodat deze niet wordt weergegeven in de lijst Velden . Als u de tabel verbergt, worden de veel-1-relaties meestal ingesteld om te filteren in beide richtingen en kunt u het veld Staat uit beide tabellen gebruiken. De laatste kruislings filteren zou worden doorgegeven aan de andere tabel. Deze benadering wordt weergegeven in de volgende afbeelding:

Screenshot of a hidden State table in Relationship view.

Een visual waarin Staat (uit de tabel CityData) wordt weergegeven, samen met het totale aantal inwoners en de totale verkoop, wordt vervolgens als volgt weergegeven:

Screenshot showing a table with State, Population, and Sales data.

Notitie

Omdat de status uit de tabel CityData in deze tijdelijke oplossing wordt gebruikt, worden alleen de statussen in die tabel vermeld, dus TX wordt uitgesloten. In tegenstelling tot veel-1 relaties, terwijl de totaalrij alle verkopen (inclusief die van TX) bevat, bevatten de details geen lege rij met dergelijke niet-overeenkomende rijen. Op dezelfde manier heeft geen lege rij betrekking op Verkoop waarvoor een null-waarde voor de staat is.

Stel dat u ook Plaats aan die visual toevoegt. Hoewel de bevolking per stad bekend is, herhaalt de verkoop voor de stad gewoon de verkoop voor de bijbehorende staat. Dit scenario treedt normaal op wanneer de kolomgroepering niet is gerelateerd aan een statistische meting, zoals hier wordt weergegeven:

Screenshot of a table showing State and city population and sales.

Stel dat u de nieuwe tabel Sales definieert als de combinatie van alle staten hier en dat we deze zichtbaar maken in de lijst Velden . In dezelfde visual wordt State (in de nieuwe tabel), het totale aantal inwoners en de totale verkoop weergegeven:

Screenshot of a visual showing State, population, and sales visual.

Zoals u kunt zien, zou TX , met verkoopgegevens maar onbekende populatiegegevens - en New York - met bekende populatiegegevens , maar geen verkoopgegevens , worden opgenomen. Deze tijdelijke oplossing is niet optimaal en heeft veel problemen. Voor relaties met een veel-op-veel-kardinaliteit worden de resulterende problemen opgelost, zoals beschreven in de volgende sectie.

Zie veel-op-veel-relatierichtlijnen voor meer informatie over het implementeren van deze tijdelijke oplossing.

Een relatie met een veel-op-veel-kardinaliteit gebruiken in plaats van de tijdelijke oplossing

U kunt tabellen, zoals de tabellen die we eerder hebben beschreven, rechtstreeks relateren, zonder gebruik te hoeven maken van vergelijkbare tijdelijke oplossingen. Het is nu mogelijk om de relatiekardinaliteit in te stellen op veel-op-veel. Deze instelling geeft aan dat geen van beide tabellen unieke waarden bevat. Voor dergelijke relaties kunt u nog steeds bepalen welke tabel de andere tabel filtert. U kunt ook bidirectioneel filteren, waarbij elke tabel de andere filtert.

In Power BI Desktop wordt de kardinaliteit standaard ingesteld op veel-op-veel wanneer wordt bepaald dat geen van beide tabellen unieke waarden bevat voor de relatiekolommen. In dergelijke gevallen bevestigt een waarschuwing dat u een relatie wilt instellen en dat de wijziging niet het onbedoelde effect van een gegevensprobleem is.

Wanneer u bijvoorbeeld rechtstreeks een relatie maakt tussen CityData en Sales, waar filters van CityData naar Sales moeten stromen, wordt in Power BI Desktop het dialoogvenster Relatie bewerken weergegeven:

Screenshot of the Edit relationship dialog box with Cardinality and Cross filter direction highlighted.

In de resulterende relatieweergave wordt vervolgens de directe veel-op-veel-relatie tussen de twee tabellen weergegeven. Het uiterlijk van de tabellen in de lijst Velden en hun latere gedrag wanneer de visuals worden gemaakt, zijn vergelijkbaar met wanneer we de tijdelijke oplossing hebben toegepast. In de tijdelijke oplossing wordt de extra tabel met de afzonderlijke statusgegevens niet zichtbaar gemaakt. Zoals eerder beschreven, wordt een visual met de gegevens Status, Bevolking en Verkoop weergegeven:

Screenshot of a State, Population, and Sales table.

De belangrijkste verschillen tussen relaties met een veel-op-veel-kardinaliteit en de meer typische Veel-1-relaties zijn als volgt:

  • De weergegeven waarden bevatten geen lege rij die accounts maakt voor niet-overeenkomende rijen in de andere tabel. De waarden maken ook geen rekening met rijen waarin de kolom die in de relatie in de andere tabel wordt gebruikt, null is.

  • U kunt de RELATED() functie niet gebruiken, omdat er meer dan één rij gerelateerd kan zijn.

  • Als u de ALL() functie in een tabel gebruikt, worden er geen filters verwijderd die door een veel-op-veel-relatie worden toegepast op andere gerelateerde tabellen. In het voorgaande voorbeeld worden filters voor kolommen in de gerelateerde CityData-tabel niet verwijderd door een meting die is gedefinieerd zoals hier wordt weergegeven:

    Screenshot of a script example. The example is, Sales total = Calculate(Sum('Sales'[Sales]), All('Sales')).

    Een visual met de totale gegevens State, Sales en Sales resulteert in deze afbeelding:

    Screenshot of a table visual showing State, Sales, and Sales total resulting from the formula.

Zorg er met de voorgaande verschillen in gedachten voor dat de berekeningen die worden gebruikt ALL(<Table>), zoals % van eindtotaal, de beoogde resultaten retourneren.

Overwegingen en beperkingen

Er zijn enkele beperkingen voor deze release van relaties met een veel-op-veel-kardinaliteit en samengestelde modellen.

De volgende Live Verbinding maken (multidimensionale) bronnen kunnen niet worden gebruikt met samengestelde modellen:

  • SAP HANA
  • SAP Business Warehouse
  • SQL Server Analysis Services
  • Semantische Power BI-modellen
  • Azure Analysis Services

Wanneer u verbinding maakt met deze multidimensionale bronnen met behulp van DirectQuery, kunt u geen verbinding maken met een andere DirectQuery-bron of deze combineren met geïmporteerde gegevens.

De bestaande beperkingen van het gebruik van DirectQuery gelden nog steeds wanneer u relaties met een veel-op-veel-kardinaliteit gebruikt. Er zijn nu veel beperkingen per tabel, afhankelijk van de opslagmodus van de tabel. Een berekende kolom in een geïmporteerde tabel kan bijvoorbeeld verwijzen naar andere tabellen, maar een berekende kolom in een DirectQuery-tabel kan nog steeds alleen verwijzen naar kolommen in dezelfde tabel. Andere beperkingen zijn van toepassing op het hele model als tabellen in het model DirectQuery zijn. De functies QuickInsights en Q&A zijn bijvoorbeeld niet beschikbaar op een model als een tabel in het model een opslagmodus van DirectQuery heeft.

Gerelateerde inhoud

Zie de volgende artikelen voor meer informatie over samengestelde modellen en DirectQuery: