Samengestelde modellen gebruiken in Power BI Desktop

Voorheen in Power BI Desktop, toen u een DirectQuery in een rapport gebruikte, waren er geen andere gegevensverbindingen, ongeacht of DirectQuery of importeren, voor dat rapport is toegestaan. Bij samengestelde modellen wordt die beperking verwijderd. Een rapport kan naadloos gegevensverbindingen uit meer dan één DirectQuery-verbinding opnemen of gegevensverbinding importeren, in elke gewenste combinatie.

De mogelijkheden voor samengestelde modellen in Power BI Desktop bestaan uit drie gerelateerde functies:

• Samengestelde modellen: Hiermee kan een rapport twee of meer gegevensverbindingen van verschillende brongroepen hebben. Deze brongroepen kunnen een of meer DirectQuery-verbindingen zijn en een importverbinding, twee of meer DirectQuery-verbindingen of een combinatie daarvan. In dit artikel worden samengestelde modellen uitgebreid beschreven.

• Veel-op-veel-relaties: Met samengestelde modellen kunt u veel-op-veel-relaties tussen tabellen tot stand brengen. Met deze benadering worden de vereisten voor unieke waarden in tabellen verwijderd. Ook eerdere tijdelijke oplossingen, zoals het introduceren van nieuwe tabellen om relaties tot stand te brengen, hoeven in dit geval niet te worden gebruikt. Zie Veel-op-veel-relaties toepassen in Power BI Desktop voor meer informatie.

• Opslagmodus: U kunt nu opgeven welke visuals query's uitvoeren op back-endgegevensbronnen. Deze functie helpt de prestaties te verbeteren en de back-endbelasting te verminderen. Voorheen hebben zelfs eenvoudige visuals, zoals slicers, query's naar back-endbronnen geïnitieerd. Zie De opslagmodus beheren in Power BI Desktop voor meer informatie.

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 model dat gegevens uit meer dan één DirectQuery-bron combineert of die DirectQuery combineert met importgegevens, wordt een samengesteld model genoemd.

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.

Notitie

Binnen de context van samengestelde modellen zijn alle geïmporteerde tabellen effectief één bron, ongeacht de werkelijke onderliggende gegevensbronnen.

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. De opslagmodus kan worden bekeken en gewijzigd in het deelvenster Eigenschappen . Als u de opslagmodus wilt weergeven, klikt u met de rechtermuisknop op een tabel in de lijst Velden en selecteert u Eigenschappen. In de volgende afbeelding ziet u de opslagmodus voor de tabel SalesTargets .

De opslagmodus kan ook worden weergegeven op de knopinfo voor elke tabel.

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.

Notitie

U kunt de modus Gemengde opslag gebruiken in Power BI Desktop en in de Power BI-service.

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.

Belangrijk

Berekende tabellen worden niet ondersteund in de Power BI-service die deze functie gebruiken, tenzij u aan specifieke vereisten voldoet. Zie voor meer informatie hierover het werken met een samengesteld model op basis van een semantische modelsectie in dit artikel.

Gevolgen voor beveiliging

Samengestelde modellen hebben enkele gevolgen voor de beveiliging. Een query die naar een gegevensbron wordt verzonden, kan gegevenswaarden bevatten die zijn opgehaald uit een andere bron. In het vorige voorbeeld verzendt de visual die (Verkoopbedrag) door Product Manager weergeeft een SQL-query naar de relationele database Verkoop. 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 moeten worden overwogen. 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 waarschuwing weer wanneer u een samengesteld model maakt om bevestiging te geven dat u rekening hebt gehouden met eventuele gevolgen voor 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.

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, worden gegevens 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 informatie kan worden bekeken door de kwaadwillende auteur van het Power BI Desktop-bestand. 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 prestaties, met name om ervoor te zorgen 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 leiden tot het verzenden van query's naar meerdere bronnen, die vaak de resultaten van één query doorgeven aan een tweede bron. Deze situatie kan leiden tot de volgende uitvoeringsvormen:

• Een bronquery met een groot aantal letterlijke waarden: een visual die bijvoorbeeld het totale verkoopbedrag aanvraagt voor een set geselecteerde productmanagers , moet eerst vinden welke producten door deze productmanagers zijn beheerd. 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 op 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, is het nodig om één SQL-query per groep per waarde te 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, 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 tabelvisual 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 hebt toegevoegd aan een andere bron, zoals een DirectQuery-verbinding met een SQL Server-database met de naam Inventory, worden de items uit die bron toegevoegd aan een andere brongroep:

Notitie

Als u gegevens uit een andere bron importeert, wordt er geen andere brongroep toegevoegd, omdat alle items uit alle geïmporteerde bronnen zich in één brongroep bevinden.

Brongroepen en relaties

Er zijn twee typen relaties in een samengesteld model:

• Relaties tussen brongroepen binnen de brongroep. Deze relaties relateren items binnen een brongroep aan elkaar. 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 relaties tussen meerdere brongroepen toegevoegd, waarbij tabellen in de verschillende brongroepen samen worden gerelateerd:

Lokaal en extern

Elk item dat zich in een brongroep bevindt die een DirectQuery-brongroep is, wordt beschouwd als extern, tenzij het item lokaal is gedefinieerd als onderdeel van een extensie of verrijking voor de DirectQuery-bron en 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 wordt beschouwd als lokaal. Elk item dat zich in de brongroep Importeren bevindt, wordt beschouwd als lokaal. Als u bijvoorbeeld de volgende meting definieert in een samengesteld model dat gebruikmaakt van een DirectQuery-verbinding met de inventarisbron, wordt de meting beschouwd als lokaal:

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

Berekeningsgroepen, query's en metingsevaluatie

Berekeningsgroepen bieden een manier om het aantal redundante metingen en het groeperen van algemene meetexpressies samen te verminderen. Typische gebruiksvoorbeelden zijn time intelligence-berekeningen waarbij u wilt kunnen 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 die berekeningsgroep toegepast, zelfs als de meting is gedefinieerd 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 we de berekeningsgroep in het externe model gebruiken 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 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 behulp van een samengesteld model kunt u de gegevens in deze bronnen combineren met andere DirectQuery- en geïmporteerde gegevens. Rapportauteurs 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, zullen deze functionaliteit met name nuttig vinden.

Samengestelde modellen beheren in semantische Power BI-modellen

Als u het maken en verbruik van samengestelde modellen op semantische Power BI-modellen wilt inschakelen, moet voor uw tenant de volgende schakelopties zijn ingeschakeld:

• XMLA-eindpunten toestaan en analyseren in Excel met on-premises semantische modellen. Als deze schakeloptie is uitgeschakeld, kan er geen DirectQuery-verbinding met een semantisch Power BI-model worden gemaakt.
• Gebruikers kunnen werken met semantische Power BI-modellen in Excel met behulp van een liveverbinding. Als deze schakeloptie is uitgeschakeld, kunnen gebruikers geen liveverbindingen maken met semantische Power BI-modellen, zodat de knop Wijzigingen aanbrengen in dit model niet kan worden bereikt.
• 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. Als dit standaard is ingeschakeld, kunnen gebruikers geen nieuwe samengestelde modellen publiceren op semantische Power BI-modellen naar de service.

Bestaande rapporten die gebruikmaken van een samengesteld model in een semantisch Power BI-model blijven werken en gebruikers kunnen nog steeds het samengestelde model maken in Desktop, maar kunnen 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 publiceren naar de Service. 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 blijven werken, ongeacht of de schakelaar is uitgeschakeld. 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

Voor het bouwen van een samengesteld model op een semantisch Power BI-model of Analysis Services-model moet uw rapport een lokaal model hebben. 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 opgegeven 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 Rapportweergave kunt u wijzigingen aanbrengen in deze modelknop op het tabblad Modellering . In de modelweergave bevindt de knop zich op het tabblad Start .

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

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 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 semantisch model publiceren op basis van andere semantische Power BI-modellen, een functie die eerder niet mogelijk was.

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.

Wanneer u een nieuw rapport (en semantisch model) met de naam Sales and Budget Europe publiceert op basis van het semantische Power BI-model van Sales and Budget Power BI dat door uw collega is gepubliceerd, brengt u enkele verdere wijzigingen of uitbreidingen aan zoals u dat doet, voegt u effectief een rapport en semantisch model toe aan een keten van lengte drie, die is begonnen met het Sales Analysis Services-model, en eindigt met uw semantisch Power BI-model voor Verkoop en Budget Europe . In de volgende afbeelding wordt dit ketenproces gevisualiseerd.

De keten in de vorige afbeelding is van lengte 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, moeten over de juiste machtigingen beschikken voor alle semantische modellen en modellen in de keten.

De eigenaar van het samengestelde model vereist samenstellingsmachtigingen voor de semantische modellen die worden gebruikt als bronnen, zodat andere gebruikers namens de eigenaar toegang hebben tot deze modellen. Als gevolg hiervan is het maken van de samengestelde modelverbinding in Power BI Desktop of het ontwerpen van het rapport in Power BI samenstellingsmachtigingen vereist voor de semantische modellen die worden gebruikt als bronnen.

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 als bronnen worden gebruikt. Samenstellingsmachtigingen zijn mogelijk vereist als de rapporten zich in een Pro-werkruimte bevinden. Deze tenantswitches moeten zijn ingeschakeld voor de gebruiker.

De vereiste machtigingen kunnen worden geïllustreerd met het volgende voorbeeld:

• Samengesteld model A (eigendom van eigenaar A)

  • Gegevensbron A1: Semantisch model B.
    Eigenaar A moet samenstellingsmachtigingen hebben voor Semantisch model B, zodat gebruikers het rapport kunnen bekijken met behulp van samengestelde model A.

• Samengestelde model C (eigendom van eigenaar C)

  • Gegevensbron C1: Semantisch model D
    Eigenaar C moet samenstellingsmachtigingen hebben voor Semantic Model D, zodat gebruikers het rapport kunnen bekijken met behulp van samengestelde model C.
  • 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 met samengestelde model A, moet leesmachtigingen hebben voor zowel samengestelde model A als Semantische model B, terwijl een gebruiker die rapporten bekijkt met samengestelde model C leesmachtigingen moet hebben voor samengestelde model C, Semantische model D, samengestelde model A en Semantisch model B.

Notitie

Raadpleeg deze blogpost voor belangrijke informatie over machtigingen die vereist zijn voor samengestelde modellen op semantische Power BI-modellen en Analysis Services-modellen.

Als een gegevensset in de keten zich in een Premium Per User-werkruimte bevindt, heeft de gebruiker die toegang heeft tot de gegevensset een Premium Per User-licentie nodig. Als een gegevensset in de keten zich in een Pro-werkruimte bevindt, heeft de gebruiker die toegang heeft tot de gegevensset een Pro-licentie nodig. Als alle gegevenssets in de keten Premium-capaciteiten of Fabric F64 of een grotere capaciteit hebben, heeft een gebruiker er toegang toe met behulp van een gratis licentie.

Beveiligingswaarschuwing

Als u de functie Samengestelde modellen op semantische Power BI-modellen en Analysis Services-modellen gebruikt, ziet u een dialoogvenster met een beveiligingswaarschuwing, zoals wordt weergegeven in de volgende afbeelding.

Gegevens kunnen van de ene gegevensbron naar de andere worden gepusht. Dit is dezelfde beveiligingswaarschuwing voor 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
• U kunt een tabel uit uw model verwijderen met behulp van de lijst met velden, om modellen zo beknopt mogelijk en mager te houden (als u verbinding maakt met een perspectief, kunt u geen tabellen uit het model verwijderen)
• U kunt opgeven 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.
• U kunt opgeven of u tabellen wilt toevoegen die later aan het semantische model worden toegevoegd 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 een samengesteld model op basis van een ander semantisch model, moeten alle referenties worden ingesteld.

• 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 worden gemaakt met behulp van eenmalige aanmelding. Verificatie met een service-principal wordt momenteel niet ondersteund.

• RLS-regels worden toegepast op de bron waarop ze zijn gedefinieerd, maar worden niet toegepast op andere semantische modellen in het model. RLS die in het rapport is gedefinieerd, worden niet toegepast op externe bronnen en RLS die is ingesteld op externe bronnen, worden niet toegepast 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 op de pijl-omlaag in de veldnaam te klikken en vervolgens op de naam van dat veld te klikken in plaats van op datumhiërarchie:

  

  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.

• Een vlag voor het afraden van ketens kan worden ingesteld 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.

• De verbinding met een semantisch Power BI-model of Analysis Services-model wordt niet weergegeven in Power Query.

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 Analysis Services-model bevatten, wordt momenteel niet ondersteund.
• Het publiceren van een rapport op internet met 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 de DirectQuery-verbinding is ingesteld, moet u de gegevensbron in Power BI Desktop bijwerken zodat het rapport kan blijven 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.
• Overname van een semantisch model dat de Functie DirectQuery 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 power BI-semantisch model niet weergegeven wanneer u verbinding maakt met het model of het semantische model in de DirectQuery-modus met behulp van Excel.

Er zijn enkele andere zaken waarmee u rekening moet houden bij het werken met DirectQuery voor semantische Power BI-modellen en Analysis Services:

• 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

Elk model met een DirectQuery-verbinding met een semantisch Power BI-model of analysis Services moet worden gepubliceerd in dezelfde tenant. Dit is vooral belangrijk bij het openen van een semantisch Power BI-model of een Analysis Services-model met B2B-gastidentiteiten, zoals wordt weergegeven in het volgende diagram. Zie Gastgebruikers die inhoud kunnen bewerken en beheren om de tenant-URL voor publicatie te vinden.

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 wordt gehost in de tenant van Fabrikam.

As gebruikt een B2B-gastgebruikersidentiteit (stap 1 in het diagram) om te verifiëren.

Als het rapport wordt gepubliceerd naar het 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.

Omdat in dit scenario het Gebruikte Analysis Services-model wordt gehost in de tenant van Fabrikam, moet het rapport ook worden gepubliceerd 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. Het kan niet worden gedefinieerd voor een samengesteld model dat is gebouwd op het bronmodel.

Wanneer een samengesteld model is gebouwd op basis van een met OLS beveiligd Power BI-semantisch model of Analysis Services-model via directQuery-verbinding, wordt het modelschema van het bronmodel gekopieerd naar het samengestelde model. Wat er wordt gekopieerd, is afhankelijk van wat de auteur van het samengestelde model in het bronmodel mag zien volgens de OLS-regels die daar van toepassing zijn. De gegevens worden niet gekopieerd naar het samengestelde model, maar worden altijd opgehaald 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 die de auteur van het samengestelde model in het bronmodel kan zien in plaats van waartoe ze zelf toegang hebben. Dit kan leiden tot de volgende situaties:

• 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 een semantisch ondernemingsmodel gepubliceerd met behulp van een semantisch Power BI-model of een Analysis Services-model met een tabel Customer en een Territory-tabel. 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.
• OLS-regels kunnen niet worden gedefinieerd 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 probeert de gegevens op te halen met 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, kunt u bepalen met welke tabellen verbinding moet worden gemaakt. 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.

Notitie

Dit dialoogvenster wordt alleen weergegeven als u een DirectQuery-verbinding toevoegt aan een semantisch Power BI-model of Analysis Services-model aan een bestaand model. U kunt dit dialoogvenster ook openen door de DirectQuery-verbinding te wijzigen in het semantische Power BI-model of Analysis Services-model in de gegevensbroninstellingen nadat u deze hebt gemaakt.

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 in conflict is 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
• de ontdubbelingsregel toepassen 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 opgegeven ontdubbelingsregels 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 de naam van een van de tabellen Klant 2 gewijzigd.

XMLA-wijzigingen en samengestelde modellen

Wanneer u een semantisch model wijzigt met XMLA, moet u de ChangeProperties en PBI_RemovedChildren verzameling voor het gewijzigde object bijwerken om gewijzigde of verwijderde eigenschappen op te nemen. Als u deze update niet uitvoert, kunnen power BI-modelleringshulpprogramma's wijzigingen overschrijven wanneer het schema de volgende keer wordt gesynchroniseerd met het bijbehorende Lakehouse.

De ondersteunde modellen voor het wijzigen van een semantisch model met XMLA zijn het volgende:

• Naam van tabel/kolom (ChangeProperty = name)
• Tabel verwijderen (tabel toevoegen aan PBI_RemovedChildren aantekening in de query-expressie)

Overwegingen en beperkingen

Samengestelde modellen bieden enkele overwegingen en beperkingen:

Verbindingen in gemengde modus: wanneer u een gemengde modusverbinding gebruikt die onlinegegevens (zoals een semantisch Power BI-model) en een on-premises semantisch model (zoals een Excel-werkmap) bevat, moet u gatewaytoewijzing hebben ingesteld om 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 van 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