Samengestelde modellen gebruiken in Power BI

Semantische Power BI-modellen kunnen tabellen uit een of meer gegevensbronnen bevatten met behulp van een van de ondersteunde tabelopslagmodi. Wanneer tabellen verschillende opslagmodi gebruiken, is het model een samengesteld semantisch model. Voor de DirectQuery-tabelopslagmodus wordt het model samengesteld wanneer de DirectQuery-tabellen verschillende gegevensbronnen gebruiken.

Als u bijvoorbeeld verbinding maakt met een ander semantisch Power BI-model met behulp van DirectQuery (waarmee tabellen worden toegevoegd in de DirectQuery-opslagmodus) en ook lokale tabellen hebt in de importmodus, wordt uw model een samengesteld model omdat het tabellen met verschillende opslagmodi bevat.

Typen samengestelde modellen

Er bestaan verschillende typen samengestelde modellen, afhankelijk van de combinatie van tabelopslagmodi in het semantische model. Elk type heeft zijn eigen overwegingen voor functionaliteit en hulpprogramma's.

Samengestelde modellen maken in Power BI Desktop

In Power BI Desktop kunt u semantische modellen maken met import- of DirectQuery-tabellen lokaal. U kunt vervolgens meer tabellen toevoegen via de knop Gegevenslint ophalen in de andere opslagmodus om een samengesteld model te maken.

Het toevoegen van DirectQuery-tabellen uit een ander semantisch Power BI-model heeft een aantal verschillende maakpaden.

1. Maak in een leeg Power BI-bestand eerst verbinding met het semantische Power BI-model. Zodra live is verbonden, hebt u de mogelijkheid om wijzigingen aan te brengen in dit model. Als u Wijzigingen aanbrengen in dit model selecteert op het lint of de voettekst, wordt de liveverbinding geconverteerd naar een DirectQuery-verbinding. De DirectQuery-verbinding maakt een nieuw lokaal semantisch model met de tabellen in de DirectQuery-opslagmodus. U kunt nieuwe tabellen toevoegen in de import- of DirectQuery-opslagmodus en u de mogelijkheid geven om bepaalde kolomeigenschappen in het semantische bronmodel te overschrijven.

2. In een semantisch model met al import- of DirectQuery-tabellen, maak verbinding met een Power BI-semantisch model. De tabellen die u kiest worden als DirectQuery toegevoegd.

Semantische modellen die zijn gemaakt met Direct Lake-tabellen, worden live bewerkt in Power BI Desktop. U kunt meer Direct Lake-tabellen toevoegen. Als u importtabellen wilt toevoegen, opent u het semantische model in Power BI-webmodellering. Als u DirectQuery-tabellen wilt toevoegen, gebruikt u XMLA.

U kunt een Direct Lake live bewerken en semantisch model importeren in Desktop, maar u kunt niet meer tabellen toevoegen. U kunt alleen tabellen toevoegen vanuit Power BI-webmodellering voor Direct Lake en samengestelde modellen importeren.

Samengestelde modellen maken in webmodellering

In Power BI-webmodellering kunt u semantische modellen maken met import- of Direct Lake-tabellen. U kunt geen DirectQuery-tabellen toevoegen. U kunt meer tabellen toevoegen in de andere opslagmodus om een samengesteld model te maken.

Samengestelde modellen gebruiken

Met samengestelde modellen kunt u verbinding maken met verschillende soorten gegevensbronnen wanneer u Power BI Desktop of de Power BI-service gebruikt. U kunt deze gegevensverbindingen op een aantal manieren maken:

• Door gegevens te importeren in Power BI, wat de meest voorkomende manier is om gegevens op te halen.
• Door rechtstreeks verbinding te maken met gegevens in de oorspronkelijke bronopslagplaats met behulp van DirectQuery. Zie DirectQuery in Power BI voor meer informatie over DirectQuery.

Wanneer u DirectQuery gebruikt, maken samengestelde modellen het mogelijk om een Power BI-model te maken, zoals één PBIX Power BI Desktop-bestand dat een of beide van de volgende acties uitvoert:

• Combineert gegevens uit een of meer DirectQuery-bronnen.
• Hiermee worden gegevens uit DirectQuery-bronnen gecombineerd en gegevens geïmporteerd.

Met samengestelde modellen kunt u bijvoorbeeld een model bouwen waarin de volgende typen gegevens worden gecombineerd:

• Verkoopgegevens uit een datawarehouse voor ondernemingen.
• Verkoopdoelgegevens uit een afdelings-SQL Server-database.
• Gegevens die zijn geïmporteerd uit een spreadsheet.

Een semantisch model dat tabellen uit meer dan één DirectQuery-bron combineert of DirectQuery-, Direct Lake- en importtabellen combineert, is een samengesteld semantisch model.

U kunt relaties tussen tabellen maken zoals u altijd hebt, zelfs wanneer deze tabellen afkomstig zijn uit verschillende bronnen. Relaties die meerdere bronnen zijn, worden gemaakt met een kardinaliteit van veel-op-veel, ongeacht de werkelijke kardinaliteit. U kunt ze wijzigen in een-op-veel, veel-op-een of een-op-een. Welke kardinaliteit u ook instelt, relaties tussen meerdere bronnen hebben ander gedrag. U kunt geen DAX-functies (Data Analysis Expressions) gebruiken om waarden aan de one zijkant op te halen.many Mogelijk ziet u ook een impact op de prestaties ten opzichte van veel-op-veel-relaties binnen dezelfde bron.

Voorbeeld van een samengesteld model

Voor een voorbeeld van een samengesteld model kunt u een rapport overwegen dat verbinding maakt met een bedrijfsdatawarehouse in SQL Server met behulp van DirectQuery. In dit geval bevat het datawarehouse de gegevens Verkoop per land, Kwartaal en Fiets (Product), zoals wordt weergegeven in de volgende afbeelding:

Op dit moment kunt u eenvoudige visuals maken met behulp van velden uit deze bron. In de volgende afbeelding ziet u de totale verkoop per ProductName voor een geselecteerd kwartaal.

Maar wat als u gegevens in een Excel-spreadsheet hebt over de productmanager die aan elk product is toegewezen, samen met de marketingprioriteit? Als u verkoopbedrag per productmanager wilt weergeven, is het mogelijk niet mogelijk om deze lokale gegevens toe te voegen aan het datawarehouse van het bedrijf. Of het kan maanden duren.

Het is mogelijk om die verkoopgegevens uit het datawarehouse te importeren in plaats van DirectQuery te gebruiken. En de verkoopgegevens kunnen vervolgens worden gecombineerd met de gegevens die u hebt geïmporteerd uit het werkblad. Deze aanpak is echter onredelijk, om de redenen die ervoor hebben gezorgd dat DirectQuery in de eerste plaats werd gebruikt. De volgende redenen kunnen zijn:

• Een combinatie van de beveiligingsregels die in de onderliggende bron worden afgedwongen.
• De noodzaak om de meest recente gegevens weer te geven.
• De enorme schaal van de gegevens.

Hier komen samengestelde modellen binnen. Met samengestelde modellen kunt u verbinding maken met het datawarehouse met behulp van DirectQuery en vervolgens Gegevens ophalen gebruiken voor meer bronnen. In dit voorbeeld maken we eerst de DirectQuery-verbinding met het zakelijke datawarehouse. We gebruiken Gegevens ophalen, kiezen Excel en gaan vervolgens naar het spreadsheet dat onze lokale gegevens bevat. Ten slotte importeren we het spreadsheet met de productnamen, de toegewezen verkoopmanager en de prioriteit.

In de lijst Velden ziet u twee tabellen: de oorspronkelijke fietstabel van SQL Server en een nieuwe Tabel ProductManagers . De nieuwe tabel bevat de gegevens die zijn geïmporteerd uit Excel.

Op dezelfde manier zien we in de weergave Relatie in Power BI Desktop een andere tabel met de naam ProductManagers.

We moeten deze tabellen nu koppelen aan de andere tabellen in het model. Zoals altijd maken we een relatie tussen de fietstabel van SQL Server en de geïmporteerde Tabel ProductManagers . Dat wil gezegd, de relatie is tussen Bike[ProductName] en ProductManagers[ProductName]. Zoals eerder is besproken, worden alle relaties die over de bron gaan, standaard ingesteld op veel-op-veel-kardinaliteit.

Nu deze relatie tot stand is gebracht, wordt deze zoals verwacht weergegeven in de weergave Relatie in Power BI Desktop.

We kunnen nu visuals maken met behulp van een van de velden in de lijst Velden . Deze benadering combineert naadloos gegevens uit meerdere bronnen. Het totale verkoopbedrag voor elke productmanager wordt bijvoorbeeld weergegeven in de volgende afbeelding:

In het volgende voorbeeld ziet u een veelvoorkomend geval van een dimensietabel , zoals Product of Klant, die wordt uitgebreid met enkele extra gegevens die ergens anders zijn geïmporteerd. Het is ook mogelijk om tabellen DirectQuery te laten gebruiken om verbinding te maken met verschillende bronnen. Als u wilt doorgaan met ons voorbeeld, stelt u zich voor dat verkoopdoelen per land en periode worden opgeslagen in een afzonderlijke afdelingsdatabase. Zoals gebruikelijk kunt u Get-gegevens gebruiken om verbinding te maken met die gegevens, zoals wordt weergegeven in de volgende afbeelding:

Zoals we eerder hebben gedaan, kunnen we relaties maken tussen de nieuwe tabel en andere tabellen in het model. Vervolgens kunnen we visuals maken die de tabelgegevens combineren. Laten we eens kijken naar de weergave Relaties , waar we de nieuwe relaties hebben ingesteld:

De volgende afbeelding is gebaseerd op de nieuwe gegevens en relaties die we hebben gemaakt. In de visual linksonder ziet u het totale verkoopbedrag versus het doel en in de variantieberekening ziet u het verschil. De verkoopbedrag - en doelgegevens zijn afkomstig uit twee verschillende SQL Server-databases.

De opslagmodus instellen

Elke tabel in een samengesteld model heeft een opslagmodus die aangeeft of de tabel is gebaseerd op DirectQuery of importeren. U kunt de opslagmodus weergeven en wijzigen in het deelvenster Eigenschappen . De opslagmodus weergeven:

1. Selecteer de tabel in de modelweergave .
2. Vouw in het deelvenster Eigenschappen de sectie Geavanceerd uit en vouw vervolgens de lijst met opslagmodus uit.

U kunt de opslagmodus ook weergeven in de tooltip voor elke tabel wanneer u er met de muisaanwijzer boven zweeft in het deelvenster Gegevens.

Voor elk Power BI Desktop-bestand (een PBIX-bestand ) dat enkele tabellen uit DirectQuery en sommige importtabellen bevat, wordt op de statusbalk een opslagmodus weergegeven met de naam Mixed. U kunt deze term selecteren op de statusbalk en eenvoudig alle tabellen om te importeren.

Zie Opslagmodus beheren in Power BI Desktop voor meer informatie over de opslagmodus.

Berekende tabellen

U kunt berekende tabellen toevoegen aan een model in Power BI Desktop dat DirectQuery gebruikt. De DAX (Data Analysis Expressions) die de berekende tabel definiëren, kunnen verwijzen naar geïmporteerde of DirectQuery-tabellen of een combinatie van de twee.

Berekende tabellen worden altijd geïmporteerd en de bijbehorende gegevens worden vernieuwd wanneer u de tabellen vernieuwt. Als een berekende tabel verwijst naar een DirectQuery-tabel, worden in visuals die verwijzen naar de DirectQuery-tabel altijd de meest recente waarden in de onderliggende bron weergegeven. Visuals die naar de berekende tabel verwijzen, geven ook de waarden weer op het moment dat de berekende tabel voor het laatst is vernieuwd.

Gevolgen voor beveiliging

Samengestelde modellen hebben enkele gevolgen voor de beveiliging. Een query die naar een gegevensbron wordt verzonden, kan gegevenswaarden bevatten die uit een andere bron worden opgehaald. In het eerdere voorbeeld stuurt de visual die (Verkoopbedrag) door Product Manager weergeeft een SQL-query naar de relationele verkoopdatabase. Deze SQL-query kan de namen van productmanagers en de bijbehorende producten bevatten.

Informatie die is opgeslagen in het werkblad, wordt nu opgenomen in een query die naar de relationele database wordt verzonden. Als deze informatie vertrouwelijk is, moet u rekening houden met de gevolgen voor de beveiliging. Houd met name rekening met de volgende punten:

• Elke beheerder van de database die traceringen of auditlogboeken kan bekijken, kan deze informatie bekijken, zelfs zonder machtigingen voor de gegevens in de oorspronkelijke bron. In dit voorbeeld heeft de beheerder machtigingen nodig voor het Excel-bestand.

• De versleutelingsinstellingen voor elke bron. U wilt voorkomen dat gegevens uit één bron worden opgehaald door een versleutelde verbinding en deze vervolgens per ongeluk op te halen in een query die door een niet-versleutelde verbinding naar een andere bron wordt verzonden.

Power BI Desktop geeft een waarschuwingsbericht weer wanneer u een samengesteld model maakt om te bevestigen dat u rekening hebt gehouden met de gevolgen van de beveiliging.

Als een auteur Tabel1 van Model A toevoegt aan een samengesteld model (laten we het model C ter referentie noemen), kan een gebruiker die een rapport bekijkt dat is gebaseerd op Model C een query uitvoeren op elke tabel in Model A die niet wordt beveiligd door beveiliging op rijniveau (RLS).

Wees om vergelijkbare redenen voorzichtig wanneer u een Power BI Desktop-bestand opent dat is verzonden vanuit een niet-vertrouwde bron. Als het bestand samengestelde modellen bevat, wordt informatie die iemand ophaalt uit één bron, met behulp van de referenties van de gebruiker die het bestand opent, verzonden naar een andere gegevensbron als onderdeel van de query. De kwaadwillende auteur van het Power BI Desktop-bestand kan de informatie bekijken. Wanneer u in eerste instantie een Power BI Desktop-bestand opent dat meerdere bronnen bevat, wordt in Power BI Desktop een waarschuwing weergegeven. De waarschuwing is vergelijkbaar met de waarschuwing die wordt weergegeven wanneer u een bestand opent dat systeemeigen SQL-query's bevat.

Gevolgen voor de prestaties

Wanneer u DirectQuery gebruikt, moet u altijd rekening houden met de prestaties. Zorg ervoor dat de back-endbron voldoende resources heeft om gebruikers een goede ervaring te bieden. Een goede ervaring betekent dat de visuals binnen vijf seconden of minder worden vernieuwd. Zie DirectQuery in Power BI voor meer prestatieadvies.

Door samengestelde modellen te gebruiken, worden andere prestatieoverwegingen toegevoegd. Eén visual kan query's verzenden naar meerdere bronnen. Vaak geeft één query de resultaten door aan een tweede bron. Deze situatie kan leiden tot de volgende uitvoeringsvormen:

• Een bronquery die een groot aantal letterlijke waarden bevat: een visual die bijvoorbeeld het totale verkoopbedrag aanvraagt voor een set geselecteerde productmanagers , moet eerst vinden welke producten deze productmanagers beheren. Deze reeks moet plaatsvinden voordat de visual een SQL-query verzendt die alle product-id's in een WHERE component bevat.

• Een bronquery die query's uitvoert op een lager granulariteitsniveau, waarbij de gegevens later lokaal worden samengevoegd: Naarmate het aantal producten dat voldoet aan de filtercriteria voor Product Manager groot wordt, kan het inefficiënt of onbereikbaar worden om alle producten in een WHERE component op te nemen. In plaats daarvan kunt u een query uitvoeren op de relationele bron op het lagere niveau van Producten en vervolgens de resultaten lokaal aggregeren. Als de kardinaliteit van Producten een limiet van 1 miljoen overschrijdt, mislukt de query.

• Meerdere bronquery's, één per groep per waarde: Wanneer de aggregatie DistinctCount gebruikt en wordt gegroepeerd op een kolom uit een andere bron, en als de externe bron geen ondersteuning biedt voor het efficiënt doorgeven van veel letterlijke waarden die de groepering definiëren, moet u één SQL-query per groep per waarde verzenden.

  Een visual die een afzonderlijk aantal CustomerAccountNumber aanvraagt uit de SQL Server-tabel door Productmanagers die zijn geïmporteerd uit het werkblad, moet de details van de tabel Productmanagers doorgeven in de query die naar SQL Server wordt verzonden. Deze actie is bijvoorbeeld onfeilbaar ten opzichte van andere bronnen, redshift. In plaats daarvan zou er één SQL-query per Sales Manager worden verzonden, tot een praktische limiet, waarna de query zou mislukken.

Elk van deze gevallen heeft zijn eigen gevolgen voor de prestaties en de exacte details variëren voor elke gegevensbron. Hoewel de kardinaliteit van de kolommen die worden gebruikt in de relatie waarmee de twee bronnen worden samengevoegd laag blijft (een paar duizend), moeten de prestaties niet worden beïnvloed. Naarmate deze kardinaliteit groeit, moet u meer aandacht besteden aan de impact op de resulterende prestaties.

Daarnaast betekent het gebruik van veel-op-veel-relaties dat afzonderlijke query's moeten worden verzonden naar de onderliggende bron voor elk totaal- of subtotaalniveau, in plaats van de gedetailleerde waarden lokaal te aggregeren. Een eenvoudige tabelweergave met totalen verzendt twee bronquery's in plaats van één.

Brongroepen

Een brongroep is een verzameling items, zoals tabellen en relaties, van een DirectQuery-bron of alle importbronnen die betrokken zijn bij een gegevensmodel. Een samengesteld model bestaat uit een of meer brongroepen. Bekijk de volgende voorbeelden:

• Een samengesteld model dat verbinding maakt met een semantisch Power BI-model met de naam Sales en het semantische model verrijkt door een verkoop-YTD-meting toe te voegen, die niet beschikbaar is in het oorspronkelijke semantische model. Dit model bestaat uit één brongroep.
• Een samengesteld model dat gegevens combineert door een tabel te importeren uit een Excel-blad met de naam Doelen en een CSV-bestand met de naam Regio's, en een DirectQuery-verbinding te maken met een semantisch Power BI-model met de naam Sales. In dit geval zijn er twee brongroepen, zoals wordt weergegeven in de volgende afbeelding:
  • De eerste brongroep bevat de tabellen uit het Excel-blad Doelen en het CSV-bestand Regio's .
  • De tweede brongroep bevat de items uit het semantische Power BI-model verkoop .

Als u een andere DirectQuery-verbinding met een andere bron toevoegt, zoals een DirectQuery-verbinding met een SQL Server-database met de naam Inventory, worden de items uit die bron toegevoegd als een andere brongroep:

Brongroepen en relaties

Een samengesteld model heeft twee typen relaties:

• Relaties tussen brongroepen binnen de brongroep. Met deze relaties worden items in een brongroep verbonden. Deze relaties zijn altijd gewone relaties, tenzij ze veel-op-veel zijn, in welk geval ze beperkt zijn.
• Relaties tussen brongroepen. Deze relaties beginnen in één brongroep en eindigen in een andere brongroep. Deze relaties zijn altijd beperkte relaties.

Lees meer over het onderscheid tussen reguliere en beperkte relaties en hun impact.

In de volgende afbeelding hebben we bijvoorbeeld drie kruisbrongroeprelaties toegevoegd, waarbij tabellen over de verschillende brongroepen heen worden gekoppeld:

Lokaal en extern

Elk item in een brongroep die een DirectQuery-brongroep is, is extern, tenzij u het item lokaal definieert als onderdeel van een extensie of verrijking voor de DirectQuery-bron en deze geen deel uitmaakt van de externe bron, zoals een meting of een berekende tabel. Een berekende tabel op basis van een tabel uit de DirectQuery-brongroep behoort tot de brongroep Importeren en is lokaal. Elk item in de brongroep Importeren is lokaal. Als u bijvoorbeeld de volgende meting definieert in een samengesteld model dat gebruikmaakt van een DirectQuery-verbinding met de inventarisbron, is de meting lokaal:

[Average Inventory Count] = Average(Inventory[Inventory Count])

Berekeningsgroepen, query's en metingsevaluatie

Met berekeningsgroepen kunt u het aantal redundante metingen verminderen en algemene metingexpressies groeperen. Typische gebruiksvoorbeelden zijn time intelligence-berekeningen waarbij u wilt overschakelen van werkelijke waarden naar maand-naar-datum-, kwartaal-tot-datum- of jaar-tot-datumberekeningen. Wanneer u met samengestelde modellen werkt, is het belangrijk om rekening te houden met de interactie tussen berekeningsgroepen en of een meting alleen verwijst naar items uit één externe brongroep. Als een meting alleen verwijst naar items uit één externe brongroep en het externe model definieert een berekeningsgroep die van invloed is op de meting, wordt de berekeningsgroep toegepast, zelfs als u de meting definieert in het externe model of in het lokale model. Als een meting echter niet uitsluitend verwijst naar items uit één externe brongroep, maar verwijst naar items uit een externe brongroep waarop een externe berekeningsgroep wordt toegepast, kunnen de resultaten van de meting nog steeds worden beïnvloed door de externe berekeningsgroep. Kijk een naar het volgende voorbeeld:

• Reseller Sales is een meting die is gedefinieerd in het externe model.
• Het externe model bevat een berekeningsgroep die het resultaat van Reseller Sales wijzigt.
• Internetverkoop is een meting die is gedefinieerd in het lokale model.
• Totale verkoop is een meting die is gedefinieerd in het lokale model en heeft de volgende definitie:

[Total Sales] = [Internet Sales] + [Reseller Sales]

In dit scenario wordt de meting Internet Sales niet beïnvloed door de berekeningsgroep die is gedefinieerd in het externe model, omdat deze geen deel uitmaken van hetzelfde model. De berekeningsgroep kan echter het resultaat van de meting Reseller Sales wijzigen, omdat deze zich in hetzelfde model bevinden. Dit betekent dat de resultaten die worden geretourneerd door de meting Totale verkoop zorgvuldig moeten worden geëvalueerd. Stel dat u de berekeningsgroep in het externe model gebruikt om jaar-tot-datumresultaten te retourneren. Het resultaat dat wordt geretourneerd door Reseller Sales is nu een jaar-tot-datum-waarde, terwijl het resultaat dat wordt geretourneerd door Internet Sales nog steeds een werkelijke waarde is. Het resultaat van de totale verkoop is nu waarschijnlijk onverwacht, omdat het een werkelijk resultaat van een jaar tot heden toevoegt.

Samengestelde modellen in semantische Power BI-modellen en Analysis Services

Met behulp van samengestelde modellen met semantische Power BI-modellen en Analysis Services kunt u een samengesteld model bouwen met behulp van een DirectQuery-verbinding om verbinding te maken met semantische Power BI-modellen, Azure Analysis Services (AAS) en SQL Server 2022 Analysis Services. Met een samengesteld model kunt u de gegevens in deze bronnen combineren met andere DirectQuery en geïmporteerde gegevens. Auteurs van rapporten die de gegevens uit hun bedrijfssemantische model willen combineren met andere gegevens die ze bezitten, zoals een Excel-spreadsheet, of die de metagegevens van hun bedrijfssemantische model willen personaliseren of verrijken, vinden deze functionaliteit met name nuttig.

Samengestelde modellen beheren in semantische Power BI-modellen

Als u samengestelde modellen wilt maken en gebruiken in semantische Power BI-modellen, moet voor uw tenant de volgende schakelopties zijn ingeschakeld:

• XMLA-eindpunten toestaan en analyseren in Excel met on-premises semantische modellen. Als u deze schakeloptie uitschakelt, kunt u geen DirectQuery-verbinding maken met een semantisch Power BI-model.
• Gebruikers kunnen werken met semantische Power BI-modellen in Excel met behulp van een liveverbinding. Als u deze schakeloptie uitschakelt, kunnen gebruikers geen liveverbindingen maken met semantische Power BI-modellen, zodat de knop Wijzigingen aanbrengen in dit model niet beschikbaar is.
• DirectQuery-verbinding met semantische Power BI-modellen toestaan. Zie de volgende alinea's voor meer informatie over deze schakeloptie en het effect van het uitschakelen ervan.

Daarnaast moet voor Premium-capaciteiten en Premium per gebruiker de instelling XMLA-eindpunt zijn ingeschakeld en ingesteld op Alleen-lezen of Lezen/Schrijven.

Tenantbeheerders kunnen DirectQuery-verbindingen met semantische Power BI-modellen in- of uitschakelen in de beheerportal. Hoewel deze instelling standaard is ingeschakeld, wordt het onmogelijk voor gebruikers om nieuwe samengestelde modellen naar de service van Power BI-semantische modellen te publiceren.

Bestaande rapporten die gebruikmaken van een samengesteld model in een semantisch Power BI-model blijven werken. Gebruikers kunnen nog steeds het samengestelde model maken in Power BI Desktop, maar kunnen het niet publiceren naar de service. Wanneer u in plaats daarvan een DirectQuery-verbinding met het semantische Power BI-model maakt door Wijzigingen aanbrengen in dit model te selecteren, ziet u het volgende waarschuwingsbericht:

Op deze manier kunt u het semantische model nog steeds verkennen in uw lokale Power BI Desktop-omgeving en het samengestelde model maken. U kunt het rapport echter niet op de service publiceren. Wanneer u het rapport en model publiceert, ziet u het volgende foutbericht en wordt de publicatie geblokkeerd:

Liveverbindingen met semantische Power BI-modellen worden niet beïnvloed door de switch, noch zijn live- of DirectQuery-verbindingen met Analysis Services. Deze verbindingen blijven werken, ongeacht de switchinstelling. Ook blijven gepubliceerde rapporten die gebruikmaken van een samengesteld model in een semantisch Power BI-model werken, zelfs als de switch is uitgeschakeld nadat ze zijn gepubliceerd.

Een samengesteld model bouwen op een semantisch model of model

Als u een samengesteld model wilt bouwen op een semantisch Power BI-model of Analysis Services-model, heeft uw rapport een lokaal model nodig. U kunt beginnen met een liveverbinding en een lokale model toevoegen of upgraden, of beginnen met een DirectQuery-verbinding of geïmporteerde gegevens, waarmee automatisch een lokaal model in uw rapport wordt gemaakt.

Als u wilt zien welke verbindingen in uw model worden gebruikt, controleert u de statusbalk in de rechterbenedenhoek van Power BI Desktop. Als u alleen verbinding hebt met een Analysis Services-bron, ziet u een bericht zoals in de volgende afbeelding:

Als u bent verbonden met een semantisch Power BI-model, ziet u een bericht waarin wordt aangegeven met welk power BI-semantisch model u verbonden bent:

Als u de metagegevens van velden in uw live verbonden semantische model wilt aanpassen, selecteert u Wijzigingen aanbrengen in dit model op de statusbalk. U kunt ook de knop Wijzigingen aanbrengen in dit model selecteren op het lint, zoals wordt weergegeven in de volgende afbeelding. In De rapportweergave bevindt de knop Wijzigingen aanbrengen in dit model zich op het tabblad Modelleren . In de modelweergave bevindt de knop zich op het tabblad Start .

Wanneer u de knop selecteert, wordt er een dialoogvenster weergegeven dat de toevoeging van een lokaal model bevestigt. Selecteer Een lokaal model toevoegen om het maken van nieuwe kolommen in te schakelen of de metagegevens voor velden van semantische Power BI-modellen of Analysis Services te wijzigen. In de volgende afbeelding ziet u het dialoogvenster.

Wanneer u live bent verbonden met een Analysis Services-bron, is er geen lokaal model. Als u DirectQuery wilt gebruiken voor live verbonden bronnen, zoals semantische Power BI-modellen en Analysis Services, moet u een lokaal model toevoegen aan uw rapport. Wanneer u een rapport met een lokaal model publiceert naar de Power BI-service, wordt ook een semantisch model voor dat lokale model gepubliceerd.

Ketenvorming

Semantische modellen en de semantische modellen waarop ze zijn gebaseerd vormen een keten. Met dit proces, dat ketening wordt genoemd, kunt u een rapport en een semantisch model publiceren op basis van andere semantische Power BI-modellen.

Stel dat uw collega een semantisch Power BI-model met de naam Verkoop en Budget publiceert op basis van een Analysis Services-model met de naam Verkoop en combineert het met een Excel-blad met de naam Budget. Vervolgens maakt en publiceert u een samengesteld semantisch model en rapport met als naam Sales and Budget Europe, met behulp van het Power BI-semantische model Sales and Budget en uw eigen wijzigingen. Dit semantische model is de derde in de keten.

1. De eerste keten is het Sales Analysis Services-model.
2. De tweede keten is het Sales and Budget samengestelde semantische Power BI-model.
3. De derde keten is uw composiet Power BI semantisch model voor Verkoop en Budget in Europa.

In de volgende afbeelding wordt dit ketenproces gevisualiseerd.

De lengte van de keten in de vorige afbeelding is drie, wat de maximale lengte is. Uitbreiden buiten een ketenlengte van drie wordt niet ondersteund en resulteert in fouten.

Machtigingen en licenties

Gebruikers die rapporten openen met behulp van een samengesteld model hebben de juiste machtigingen nodig voor alle semantische modellen en modellen in de keten.

De eigenaar van het samengestelde model heeft samenstellingsmachtigingen nodig voor de semantische modellen die worden gebruikt als bronnen, zodat andere gebruikers namens de eigenaar toegang hebben tot deze modellen. Als gevolg hiervan vereist het maken van de verbinding met het samengestelde model in Power BI Desktop of het maken van het rapport in Power BI Build-rechten voor de semantische modellen die als bronnen worden gebruikt.

Gebruikers die rapporten weergeven met behulp van het samengestelde model hebben over het algemeen leesmachtigingen nodig voor het samengestelde model zelf en de semantische modellen die worden gebruikt als bronnen. Samenstellingsmachtigingen zijn mogelijk vereist als de rapporten zich in een Pro-werkruimte bevinden. Deze tenantswitches moeten zijn ingeschakeld voor de gebruiker.

In het volgende voorbeeld ziet u de vereiste machtigingen:

• Samengesteld model A (eigendom van eigenaar A)

  • Gegevensbron A1: Semantisch model B.
    Eigenaar A moet bouwmachtiging hebben op Semantic Model B zodat gebruikers het rapport kunnen bekijken dat het samengestelde model A gebruikt.

• Samengestelde model C (eigendom van eigenaar C)

  • Gegevensbron C1: Semantisch model D
    Eigenaar C moet Bouwmachtiging hebben voor Semantic Model D zodat gebruikers het rapport kunnen weergeven dat Samengesteld model C gebruikt.
  • Gegevensbron C2: Samengesteld model A
    Eigenaar C moet samenstellingsmachtigingen hebben voor samengestelde model A en leesmachtigingen voor Semantisch model B.

Een gebruiker die rapporten bekijkt die samengestelde model A gebruiken, moet leesmachtigingen hebben voor zowel samengesteld model A als Semantisch model B, terwijl een gebruiker die rapporten bekijkt die samengesteld model C gebruiken leesmachtigingen moet hebben voor samengestelde model C, Semantische model D, samengestelde model A en Semantisch model B.

Als een semantisch model in de keten zich in een Premium Per User-werkruimte bevindt, heeft de gebruiker die toegang heeft tot het een Premium Per User-licentie nodig. Als een semantisch model in de keten zich in een Pro-werkruimte bevindt, heeft de gebruiker die toegang heeft tot het een Pro-licentie nodig. Als alle semantische modellen in de keten Premium-capaciteiten of Fabric F64 of meer capaciteit hebben, heeft een gebruiker er toegang toe met behulp van een gratis licentie.

Beveiligingswaarschuwing

Wanneer u de samengestelde modellen op semantische Power BI-modellen en Analysis Services-modellen gebruikt, ziet u een dialoogvenster met beveiligingswaarschuwingen, weergegeven in de volgende afbeelding.

Gegevens kunnen worden gepusht van de ene gegevensbron naar een andere gegevensbron. Deze beveiligingswaarschuwing is van toepassing op het combineren van DirectQuery- en importbronnen in een gegevensmodel. Zie het gebruik van samengestelde modellen in Power BI Desktop voor meer informatie over dit gedrag.

Ondersteunde scenario's

U kunt samengestelde modellen bouwen met behulp van gegevens uit semantische Power BI-modellen of Analysis Services-modellen voor de volgende scenario's:

• Verbinding maken met gegevens uit verschillende bronnen: Importeren (zoals bestanden), semantische Power BI-modellen, Analysis Services-modellen
• Relaties tussen verschillende gegevensbronnen maken
• Metingen schrijven die gebruikmaken van velden uit verschillende gegevensbronnen
• Nieuwe kolommen maken voor tabellen van semantische Power BI-modellen of Analysis Services-modellen
• Visuals maken die kolommen uit verschillende gegevensbronnen gebruiken
• Verwijder een tabel uit uw model met behulp van de lijst met velden om modellen zo beknopt en slank mogelijk te houden (als u verbinding maakt met een perspectief, kunt u geen tabellen uit het model verwijderen)
• Geef op welke tabellen moeten worden geladen, in plaats van dat u alle tabellen moet laden wanneer u alleen een specifieke subset van tabellen wilt. Zie Een subset met tabellen later in dit document laden.
• Geef op of u tabellen wilt toevoegen die u later aan het semantische model toevoegt nadat u de verbinding in uw model hebt aangebracht.

Werken met een samengesteld model op basis van een semantisch model

Houd bij het werken met DirectQuery voor semantische Power BI-modellen en Analysis Services rekening met de volgende informatie:

• Als u uw gegevensbronnen vernieuwt en er fouten zijn met conflicterende veld- of tabelnamen, worden de fouten voor u opgelost.

• U kunt geen nieuwe relaties bewerken, verwijderen of maken in hetzelfde semantische Power BI-model of Analysis Services-bron. Als u bewerkingstoegang tot deze bronnen hebt, kunt u de wijzigingen rechtstreeks in de gegevensbron aanbrengen.

• U kunt geen gegevenstypen wijzigen van kolommen die worden geladen vanuit een semantisch Power BI-model of Analysis Services-bron. Als u het gegevenstype wilt wijzigen, wijzigt u het in de bron of gebruikt u een berekende kolom.

• Als u rapporten wilt maken in de Power BI-service op basis van een samengesteld model op basis van een ander semantisch model, moet u alle referenties instellen.

• Verbindingen met een SQL Server 2022- en hoger Analysis Services-server on-premises of IAAS vereisen een on-premises gegevensgateway (standaardmodus).

• Alle verbindingen met externe semantische Power BI-modellen maken gebruik van eenmalige aanmelding. Verificatie met een service-principal wordt momenteel niet ondersteund.

• RLS-regels zijn van toepassing op de bron waarop ze zijn gedefinieerd, maar zijn niet van toepassing op andere semantische modellen in het model. RLS die in het rapport is gedefinieerd, is niet van toepassing op externe bronnen en RLS die is ingesteld op externe bronnen, zijn niet van toepassing op andere gegevensbronnen. U kunt RLS ook niet definiëren voor een tabel die is geladen vanuit een externe bron en RLS die is gedefinieerd in lokale tabellen, filteren geen tabellen die zijn geladen vanuit een externe bron.

• KPI's, beveiliging op rijniveau en vertalingen worden niet geïmporteerd uit de bron.

• Mogelijk ziet u onverwacht gedrag bij het gebruik van een datumhiërarchie. Gebruik in plaats daarvan een datumkolom om dit probleem op te lossen. Nadat u een datumhiërarchie aan een visual hebt toegevoegd, kunt u overschakelen naar een datumkolom door de pijl-omlaag in de veldnaam te selecteren en vervolgens de naam van dat veld te selecteren in plaats van datumhiërarchie te gebruiken:

  

  Zie Automatische datum of tijd toepassen in Power BI Desktop voor meer informatie over het gebruik van datumkolommen versus datumhiërarchieën.

• De maximale lengte van een keten van modellen is drie. Uitbreiden buiten de ketenlengte van drie wordt niet ondersteund en resulteert in fouten.

• U kunt een markering om ketens te ontmoedigen instellen op een model om te voorkomen dat een keten wordt gemaakt of uitgebreid. Zie DirectQuery-verbindingen beheren met een gepubliceerd semantisch model voor meer informatie.

• Power Query geeft de verbinding met een semantisch Power BI-model of Analysis Services-model niet weer.

De volgende beperkingen gelden voor het werken met DirectQuery voor semantische Power BI-modellen en Analysis Services:

• Parameters voor database- en servernamen zijn momenteel uitgeschakeld.
• Het definiëren van beveiliging op rijniveau voor tabellen vanuit een externe bron wordt niet ondersteund.
• Het gebruik van een van de volgende bronnen als een DirectQuery-bron wordt niet ondersteund:
  • Tabellaire modellen van SQL Server Analysis Services (SSAS) vóór versie 2022
  • Multidimensionale SSAS-modellen
  • SAP HANA
  • SAP Business Warehouse
  • Realtime semantische modellen
  • Voorbeeld van semantische modellen
  • Excel Online vernieuwen
  • Gegevens geïmporteerd uit Excel- of CSV-bestanden in de service
  • Metrische gebruiksgegevens
  • Semantische modellen die zijn opgeslagen in 'Mijn werkruimte'
• Het gebruik van Power BI Embedded met semantische modellen die een DirectQuery-verbinding met een extern Analysis Services-model (Azure Analysis Services/SQL Server Analysis Services) bevatten, wordt momenteel niet ondersteund.
• Het publiceren van een rapport op internet met behulp van de functie Publiceren op internet wordt niet ondersteund.
• Berekeningsgroepen op externe bronnen worden niet ondersteund, met niet-gedefinieerde queryresultaten.
• Berekende tabellen en berekende kolommen die verwijzen naar een DirectQuery-tabel vanuit een gegevensbron met verificatie met eenmalige aanmelding (SSO) worden ondersteund in de Power BI-service met een toegewezen deelbare cloudverbinding en/of gedetailleerd toegangsbeheer.
• Als u de naam van een werkruimte wijzigt nadat u de DirectQuery-verbinding hebt ingesteld, moet u de gegevensbron in Power BI Desktop bijwerken zodat het rapport blijft werken.
• Automatische paginavernieuwing (APR) wordt alleen ondersteund voor sommige scenario's, afhankelijk van het gegevensbrontype. Zie Pagina automatisch vernieuwen in Power BI voor meer informatie.
• Het overnemen van een semantisch model dat de DirectQuery-functie naar andere semantische modellen gebruikt, wordt momenteel niet ondersteund.
• Net als bij een DirectQuery-gegevensbron worden hiërarchieën die zijn gedefinieerd in een Analysis Services-model of het semantische Power BI-model niet weergegeven wanneer u verbinding maakt met het model of semantische model in de DirectQuery-modus met behulp van Excel.

Houd bij het werken met DirectQuery voor semantische Power BI-modellen en Analysis Services rekening met de volgende richtlijnen:

• Gebruik kolommen met lage kardinaliteit in relaties tussen meerdere brongroepen: wanneer u een relatie maakt tussen twee verschillende brongroepen, moeten de kolommen die deelnemen aan de relatie (ook wel de joinkolommen genoemd) een lage kardinaliteit hebben, idealiter 50.000 of minder. Deze overweging is van toepassing op niet-getekende sleutelkolommen; zie de volgende overweging voor kolommen met tekenreekssleutels.
• Vermijd het gebruik van sleutelkolommen met grote tekenreeksen in relaties tussen meerdere brongroepen: vermijd bij het maken van een relatie tussen meerdere brongroepen het gebruik van grote tekenreekskolommen als de relatiekolommen, met name voor kolommen met een grotere kardinaliteit. Wanneer u tekenreekskolommen als relatiekolom moet gebruiken, berekent u de verwachte tekenreekslengte voor het filter door kardinaliteit (C) te vermenigvuldigen met de gemiddelde lengte van de tekenreekskolom (A). Zorg ervoor dat de verwachte tekenreekslengte lager is dan 250.000, zodat A ∗ C < 250.000.

Raadpleeg de richtlijnen voor samengestelde modellen voor meer overwegingen en richtlijnen.

Overwegingen voor tenants

U moet elk model publiceren met een DirectQuery-verbinding met een semantisch Power BI-model of naar Analysis Services in dezelfde tenant. Deze vereiste is vooral belangrijk bij het openen van een semantisch Power BI-model of een Analysis Services-model met behulp van B2B-gastidentiteiten, zoals wordt weergegeven in het volgende diagram.

Bekijk het volgende diagram. De genummerde stappen in het diagram worden beschreven in de volgende alinea's.

In het diagram werkt Ash met Contoso en krijgt toegang tot gegevens die worden geleverd door Fabrikam. Met Power BI Desktop maakt Ash een DirectQuery-verbinding met een Analysis Services-model dat Fabrikam host.

Voor verificatie gebruikt Ash een B2B-gastgebruikersidentiteit (stap 1 in het diagram).

Als Ash het rapport publiceert naar de Power BI-service van Contoso (stap 2), kan het semantische model dat is gepubliceerd in de Contoso-tenant, niet worden geverifieerd met het Analysis Services-model van Fabrikam (stap 3). Als gevolg hiervan werkt het rapport niet.

In dit scenario moet u, omdat Fabrikam als host fungeert voor het Analysis Services-model, ook het rapport publiceren in de tenant van Fabrikam. Na een geslaagde publicatie in de tenant van Fabrikam (stap 4) heeft het semantische model toegang tot het Analysis Services-model (stap 5) en werkt het rapport goed.

Werken met beveiliging op objectniveau

Wanneer een samengesteld model gegevens ophaalt uit een semantisch Power BI-model of Analysis Services via DirectQuery en dat bronmodel wordt beveiligd door beveiliging op objectniveau, kunnen consumenten van het samengestelde model onverwachte resultaten zien. In de volgende sectie wordt uitgelegd hoe deze resultaten kunnen ontstaan.

Met beveiliging op objectniveau (OLS) kunnen modelauteurs objecten verbergen waaruit het modelschema bestaat (dat wil gezegd, tabellen, kolommen, metagegevens, enzovoort) van modelgebruikers (bijvoorbeeld een rapportbouwer of een auteur van een samengesteld model). Bij het configureren van OLS voor een object maakt de auteur van het model een rol en wordt vervolgens de toegang tot het object verwijderd voor gebruikers die zijn toegewezen aan die rol. Vanuit het oogpunt van deze gebruikers bestaat het verborgen object gewoon niet.

OLS is gedefinieerd voor en toegepast op het bronmodel. U kunt het niet definiëren voor een samengesteld model dat is gebaseerd op het bronmodel.

Wanneer u een samengesteld model bouwt boven op een met OLS beveiligd Power BI-semantisch model of Analysis Services-model via de DirectQuery-verbinding, kopieert u het modelschema van het bronmodel naar het samengestelde model. Wat u kopieert, is afhankelijk van wat u in het bronmodel mag zien volgens de OLS-regels die daar van toepassing zijn. U kopieert de gegevens niet naar het samengestelde model. U haalt deze altijd op via DirectQuery uit het bronmodel wanneer dat nodig is. Met andere woorden, het ophalen van gegevens gaat altijd terug naar het bronmodel, waar OLS-regels van toepassing zijn.

Omdat het samengestelde model niet wordt beveiligd door OLS-regels, zijn de objecten die consumenten van het samengestelde model zien degene die u in het bronmodel kunt zien in plaats van waartoe ze zelf toegang hebben. Deze situatie kan leiden tot de volgende resultaten:

• Iemand die naar het samengestelde model kijkt, kan objecten zien die verborgen zijn in het bronmodel door OLS.
• Omgekeerd zien ze mogelijk GEEN object in het samengestelde model dat ze in het bronmodel kunnen zien, omdat dat object is verborgen voor de auteur van het samengestelde model door de OLS-regels waarmee de toegang tot het bronmodel wordt beheerd.

Een belangrijk punt is dat gebruikers van het samengestelde model, ondanks de case die in het eerste opsommingsteken wordt beschreven, nooit werkelijke gegevens zien die ze niet mogen zien, omdat de gegevens zich niet in het samengestelde model bevinden. Vanwege DirectQuery wordt deze, indien nodig, opgehaald uit het semantische bronmodel, waarbij OLS onbevoegde toegang blokkeert.

Houd rekening met dit scenario:

1. Admin_user publiceert een semantisch ondernemingsmodel met behulp van een semantisch Power BI-model of een Analysis Services-model met een tabel Klant en een Gebiedstabel. Admin_user publiceert het semantische model naar de Power BI-service en stelt OLS-regels in die het volgende effect hebben:

   • Financiële gebruikers kunnen de tabel Klant niet zien
   • Marketinggebruikers kunnen de tabel Gebied niet zien

2. Finance_user publiceert een semantisch model met de naam 'Semantisch financieel model' en een rapport met de naam 'Financieel rapport' dat via DirectQuery is verbonden met het semantische bedrijfsmodel dat in stap 1 is gepubliceerd. Het rapport Financiën bevat een visual die gebruikmaakt van een kolom uit de tabel Territory.

3. Marketing_user opent u het financieel rapport. De visual die gebruikmaakt van de tabel Territory wordt weergegeven, maar retourneert een fout. Wanneer het rapport wordt geopend, probeert DirectQuery de gegevens op te halen uit het bronmodel met behulp van de referenties van de Marketing_user, die wordt geblokkeerd om de tabel Territory te zien volgens de OLS-regels die zijn ingesteld op het semantische bedrijfsmodel.

4. Marketing_user maakt een nieuw rapport met de naam 'Marketingrapport' dat gebruikmaakt van het semantische financiële model als bron. De lijst met velden bevat de tabellen en kolommen waartoe Finance_user toegang heeft. Daarom wordt de tabel Gebied weergegeven in de veldenlijst, maar de tabel Klant niet. Wanneer de Marketing_user echter probeert een visual te maken die gebruikmaakt van een kolom uit de tabel Gebied, wordt er een fout geretourneerd, omdat DirectQuery op dat moment probeert gegevens op te halen uit het bronmodel met behulp van de referenties van Marketing_user, en OLS-regels opnieuw toegang starten en blokkeren. Hetzelfde gebeurt wanneer Marketing_user een nieuw semantisch model en rapport maakt dat verbinding maakt met het semantische model Financiën met een DirectQuery-verbinding. Ze zien de tabel Gebied in de lijst met velden, omdat dat Finance_user kunnen zien, maar wanneer ze een visual proberen te maken die die tabel gebruikt, worden ze geblokkeerd door de OLS-regels in het semantische bedrijfsmodel.

5. Stel nu dat Admin_user de OLS-regels op het semantische ondernemingsmodel bijwerken om te voorkomen dat Finance de tabel Territory ziet.

6. De bijgewerkte OLS-regels worden alleen weergegeven in het semantische finance-model wanneer deze wordt vernieuwd. Wanneer het Finance_user het semantische model Financiën vernieuwt, wordt de tabel Gebied niet meer weergegeven in de lijst met velden en de visual in het rapport Financiën die gebruikmaakt van een kolom uit de tabel Gebied, retourneert een fout voor Finance_user, omdat ze nu geen toegang hebben tot de tabel Gebied.

Samenvatting:

• Consumenten van een samengesteld model zien de resultaten van de OLS-regels die van toepassing waren op de auteur van het samengestelde model toen ze het model maakten. Wanneer er dus een nieuw rapport wordt gemaakt op basis van het samengestelde model, worden in de lijst met velden de tabellen weergegeven waartoe de auteur van het samengestelde model toegang had bij het maken van het model, ongeacht waartoe de huidige gebruiker toegang heeft in het bronmodel.
• U kunt geen OLS-regels definiëren voor het samengestelde model zelf.
• Een consument van een samengesteld model ziet nooit werkelijke gegevens die ze niet mogen zien, omdat relevante OLS-regels op het bronmodel deze blokkeren wanneer DirectQuery de gegevens probeert op te halen met behulp van hun referenties.
• Als het bronmodel de OLS-regels bijwerkt, zijn deze wijzigingen alleen van invloed op het samengestelde model wanneer het wordt vernieuwd.

Een subset tabellen laden van een semantisch Power BI-model of Analysis Services-model

Wanneer u verbinding maakt met een semantisch Power BI-model of Analysis Services-model met behulp van een DirectQuery-verbinding, kiest u met welke tabellen u verbinding wilt maken. U kunt er ook voor kiezen om automatisch een tabel toe te voegen die kan worden toegevoegd aan het semantische model of model nadat u de verbinding met uw model hebt tot stand gebracht. Wanneer u verbinding maakt met een perspectief, bevat uw model alle tabellen in het semantische model en zijn alle tabellen die niet in het perspectief zijn opgenomen, verborgen. Bovendien wordt elke tabel die aan het perspectief kan worden toegevoegd, automatisch toegevoegd. In het menu Instellingen kunt u besluiten om automatisch verbinding te maken met tabellen die worden toegevoegd aan het semantische model nadat u de verbinding hebt ingesteld.

Dit dialoogvenster wordt niet weergegeven voor liveverbindingen.

Ontdubbelingsregels instellen

U kunt ontdubbelingsregels opgeven om metings- en tabelnamen uniek te houden in een samengesteld model met behulp van de optie Instellingen in het dialoogvenster dat u eerder hebt weergegeven:

In het vorige voorbeeld hebben we '(marketing)' toegevoegd als achtervoegsel aan een tabel of metingnaam die conflicteert met een andere bron in het samengestelde model. U kunt:

• Voer een tekst in die moet worden toegevoegd aan de naam van conflicterende tabellen of metingen.
• Geef op of de tekst moet worden toegevoegd aan de tabel- of metingnaam als voorvoegsel of achtervoegsel.
• Pas de ontdubbelingsregel toe op tabellen, metingen of beide.
• Kies ervoor om de ontdubbelingsregel alleen toe te passen wanneer er een naamconflict optreedt of pas deze altijd toe. De standaardinstelling is om de regel alleen toe te passen wanneer duplicatie plaatsvindt. In ons voorbeeld krijgt een tabel of meting van de marketingbron die geen duplicaat in de verkoopbron heeft geen naamwijziging.

Nadat u de verbindingen hebt uitgevoerd en de ontdubbelingsregel hebt ingesteld, worden in de lijst met velden zowel Klant als Klant (marketing) weergegeven volgens de regel voor ontdubbeling die is ingesteld in ons voorbeeld:

Als u geen ontdubbelingsregel opgeeft of als de ontdubbelingsregels die u opgeeft, het naamconflict niet oplossen, worden de standaardontdubbelingsregels nog steeds toegepast. De standaardontdubbelingsregels voegen een getal toe aan de naam van het conflicterende item. Als er een naamconflict optreedt in de tabel 'Klant', wordt een van deze tabellen hernoemd naar ‘Customer 2’.

XMLA-wijzigingen en samengestelde modellen

Wanneer u een semantisch model wijzigt met behulp van XMLA, werkt u de ChangedProperties en PBI_RemovedChildren verzamelingen voor het gewijzigde object bij om gewijzigde of verwijderde eigenschappen op te nemen. Als u deze verzamelingen niet bijwerkt, worden uw wijzigingen mogelijk overschreven wanneer het schema de volgende keer wordt gesynchroniseerd met de gegevensbron.

Zie herkomsttags voor Power BI-semantische modellen voor meer informatie over de herkomsttags van semantische modelobjecten.

Overwegingen en beperkingen

Samengestelde modellen bieden enkele overwegingen en beperkingen:

Verbindingen in gemengde modus: wanneer u een verbinding in gemengde modus gebruikt die onlinegegevens (zoals een semantisch Power BI-model) en een on-premises semantisch model (zoals een Excel-werkmap) bevat, moet u een gateway-toewijzing instellen om de visuals correct weer te geven.

Op dit moment wordt incrementeel vernieuwen ondersteund voor samengestelde modellen die alleen verbinding maken met SQL-, Oracle- en Teradata-gegevensbronnen.

De volgende tabellaire bronnen voor Live Connect kunnen niet worden gebruikt met samengestelde modellen:

• SAP HANA
• SAP Business Warehouse
• SQL Server Analysis Services ouder dan versie 2022
• Metrische gegevens over gebruik (Mijn werkruimte)

Het gebruik van semantische streamingmodellen in samengestelde modellen wordt niet ondersteund.

De bestaande beperkingen van DirectQuery gelden nog steeds wanneer u samengestelde modellen gebruikt. Veel van deze beperkingen zijn nu per tabel, afhankelijk van de opslagmodus van de tabel. Een berekende kolom in een importtabel kan bijvoorbeeld verwijzen naar andere tabellen die zich niet in DirectQuery bevinden, maar een berekende kolom in een DirectQuery-tabel kan nog steeds alleen verwijzen naar kolommen in dezelfde tabel. Andere beperkingen gelden voor het model als geheel, als een van de tabellen in het model DirectQuery is. De functie QuickInsights is bijvoorbeeld niet beschikbaar voor een model als een van de tabellen in het model een opslagmodus van DirectQuery heeft.

Als u beveiliging op rijniveau gebruikt in een samengesteld model met een aantal tabellen in de DirectQuery-modus, moet u het model vernieuwen om nieuwe updates uit de DirectQuery-tabellen toe te passen. Als een tabel Gebruikers in de DirectQuery-modus bijvoorbeeld nieuwe gebruikersrecords aan de bron bevat, worden de nieuwe records alleen opgenomen nadat het volgende model is vernieuwd. Power BI Service slaat de query Gebruikers op in de cache om de prestaties te verbeteren en laadt de gegevens pas opnieuw uit de bron tot de volgende handmatige of geplande vernieuwing.

Gerelateerde inhoud

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

• Veel-op-veel-relaties toepassen in Power BI Desktop
• Opslagmodus beheren in Power BI Desktop
• DirectQuery in Power BI
• Power BI-gegevensbronnen
• Modelrelaties in Power BI Desktop