Delen via

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

Schermopname van een veel-op-veel-relatie in het deelvenster Relatie bewerken.

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:

Schermopname van de tabel ProductSales en Product in de relatieweergave.

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

Schermopname van een visual producttabel met twee rijen.

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 .

Schermopname van een visual verkooptabel met vier rijen.

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

Schermopname van een visual met de productnaam, prijs en hoeveelheid.

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.

    Schermopname van een tabel Sales met verkoop per staat.

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

    Schermopname van een tabel Sales met plaats, staat en populatie.

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:

Schermopname van een verborgen statustabel in de relatieweergave.

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:

Schermopname van een tabel met de gegevens State, Population en Sales.

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:

Schermopname van een tabel met de bevolking en verkoop van staten en steden.

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:

Schermopname van een visual met de visual State, population en sales.

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:

Schermopname van het dialoogvenster Relatie bewerken met kardinaliteit en kruisfilterrichting gemarkeerd.

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:

Schermopname van de tabel State, Population en Sales.

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:

    Schermopname van een voorbeeldscript. Het voorbeeld is: Verkooptotaal = Calculate(Sum('Sales'[Sales]), All('Sales')).

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

    Schermopname van een tabelvisual met staat, verkoop en verkooptotaal als gevolg van de formule.

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 Connect-bronnen (multidimensionale) 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: