Rapporten scheiden van modellen in Power BI Desktop

Bij het maken van Power BI Desktop oplossing is een van de eerste taken die u moet uitvoeren' gegevens op te halen. Het verkrijgen van gegevens kan twee verschillende resultaten tot gevolg hebben. Dit kan:

  • Maak een liveverbinding met een al gepubliceerd model. Dit kan een Power BI-gegevensset of een extern gehost Analysis Services zijn.
  • Begin met de ontwikkeling van een nieuw model, dat ofwel een import-, DirectQuery- of samengesteld model kan zijn.

Dit artikel heeft betrekking op het tweede scenario. Het bevat richtlijnen over of een rapport en model moeten worden gecombineerd tot één Power BI Desktop bestand.

Oplossing met één bestand

Eén bestandsoplossing werkt goed wanneer er slechts één rapport op basis van het model is. In dit geval zijn het model en het rapport waarschijnlijk de inspanningen van dezelfde persoon. We definiëren het als een persoonlijke BI-oplossing, hoewel het rapport kan worden gedeeld met anderen. Dergelijke oplossingen kunnen rapporten met een rolbereik of een een time-evaluatie van een zakelijke uitdaging vertegenwoordigen, vaak beschreven als ad-hocrapporten.

Eén bestand bevat een model en rapport, ontwikkeld door dezelfde persoon.

Afzonderlijke rapportbestanden

Het is zinvol om model- en rapportontwikkeling te scheiden in afzonderlijke Power BI Desktop bestanden wanneer:

  • Gegevensmodelleerders en rapportauteurs zijn verschillende personen.
  • Het is duidelijk dat een model de bron is voor meerdere rapporten, nu of in de toekomst.

Er zijn drie PBIX-bestanden. De eerste bevat alleen een model. De andere twee bevatten alleen rapporten en ze maken live verbinding met het model dat wordt gehost in de Power BI service. De rapporten zijn ontwikkeld door verschillende personen.

Gegevensmodelleerders kunnen nog steeds de ontwerpervaring Power BI Desktop rapport gebruiken om hun modelontwerpen te testen en te valideren. Maar net nadat het bestand naar de Power BI gepubliceerd, moet het rapport uit de werkruimte worden verwijderd. En ze moeten niet vergeten om het rapport te verwijderen telkens wanneer ze de gegevensset opnieuw publiceren en overschrijven.

De modelinterface behouden

Soms zijn modelwijzigingen onvermijdelijk. Gegevensmodelleerders moeten dus niet de interface van het model breken. Als dat het gebeurt, is het mogelijk dat gerelateerde rapportvisu visuals of dashboardtegels worden stuk gemaakt. Defecte visuals worden weergegeven als fouten en kunnen leiden tot frustraties voor rapportauteurs en -consumenten. En nog erger: ze kunnen het vertrouwen in de gegevens verminderen.

Beheer modelwijzigingen daarom zorgvuldig. Vermijd indien mogelijk de volgende wijzigingen:

  • De naam van tabellen, kolommen, hiërarchieën, hiërarchieniveaus of metingen wijzigen.
  • Kolomgegevenstypen wijzigen.
  • Het wijzigen van meetexpressie zodat ze een ander gegevenstype retourneren.
  • Metingen verplaatsen naar een andere starttabel. Dit komt doordat het verplaatsen van een meting metingen binnen rapportbereik kan breken die metingen volledig kwalificeren met de naam van hun starttabel. U wordt niet aangeraden DAX-expressies te schrijven met volledig gekwalificeerde metingen. Zie DAX: Kolom- en metingverwijzingen voor meer informatie.

Het toevoegen van nieuwe tabellen, kolommen, hiërarchieën, hiërarchieniveaus of metingen is veilig, met één uitzondering: het is mogelijk dat een nieuwe metingnaam kan botsen met de naam van een meting binnen rapportbereik. Om een aanrijding te voorkomen, raden we rapportauteurs aan om een naamconventie te hanteren bij het definiëren van metingen in hun rapporten. Ze kunnen namen van meetgegevens binnen rapportbereik vooraf laten gaan door een onderstrepingsteken of een of meer andere tekens.

Als u belangrijke wijzigingen moet aanbrengen in uw modellen, raden we u aan het volgende te doen:

Met beide opties kunt u snel gerelateerde rapporten en dashboards identificeren. Gegevensrageweergave is waarschijnlijk de betere keuze omdat het eenvoudig is om de contactpersoon voor elk gerelateerd artefact te zien. Het is in feite een hyperlink die een e-mailbericht opent dat is geadresseerd aan de contactpersoon.

U wordt aangeraden contact op te nemen met de eigenaar van elk gerelateerd artefact om hen te laten weten dat er geplande wijzigingen zijn die problemen met zich mee kunnen brengen. Op deze manier kunnen ze worden voorbereid en gereed zijn om hun rapporten op te lossen en opnieuw te publiceren, waardoor downtime en frustraties worden geminimaliseerd.

Volgende stappen

Bekijk de volgende resources voor meer informatie over dit artikel: