Separera rapporter från modeller i Power BI Desktop
När du skapar en ny Power BI Desktop-lösning är en av de första uppgifterna du behöver göra "hämta data". Att hämta data kan resultera i två tydligt olika resultat. Det kan:
- Skapa en live-anslutning till en redan publicerad modell, som antingen kan vara en Power BI-semantisk modell eller en Analysis Services-modell med fjärrvärd.
- Påbörja utvecklingen av en ny modell, som kan vara en import-, DirectQuery- eller sammansatt modell.
Den här artikeln handlar om det andra scenariot. Den ger vägledning om huruvida en rapport och modell ska kombineras till en enda Power BI Desktop-fil.
Lösning med en fil
En enda fillösning fungerar bra när det bara finns en enda rapport baserad på modellen. I det här fallet är det troligt att både modellen och rapporten är samma persons arbete. Vi definierar det som en personlig BI-lösning , även om rapporten kan delas med andra. Sådana lösningar kan representera rapporter med rollomfattning eller engångsutvärderingar av en affärsutmaning – som ofta beskrivs som ad hoc-rapporter .
Separata rapportfiler
Det är klokt att separera modell- och rapportutveckling i separata Power BI Desktop-filer när:
- Datamodellerare och rapportförfattare är olika personer.
- Det är underförstått att en modell kommer att vara källan för flera rapporter, nu eller i framtiden.
Datamodellerare kan fortfarande använda Power BI Desktop-rapportens redigeringsupplevelse för att testa och validera modelldesignen. Men strax efter publiceringen av filen till Power BI-tjänst bör de ta bort rapporten från arbetsytan. Och de måste komma ihåg att ta bort rapporten varje gång de publicerar om och skriver över den semantiska modellen.
Bevara modellgränssnittet
Ibland är modelländringar oundvikliga. Datamodellerare måste därför vara försiktiga, inte bryt modellgränssnittet. Om de gör det är det möjligt att relaterade visuella rapportobjekt eller paneler på instrumentpanelen bryts. Brutna visuella objekt visas som fel, och de kan leda till frustration för rapportförfattare och konsumenter. Och ännu värre – de kan minska förtroendet för data.
Hantera därför modelländringar noggrant. Undvik om möjligt följande ändringar:
- Byta namn på tabeller, kolumner, hierarkier, hierarkinivåer eller mått.
- Ändra kolumndatatyper.
- Ändra måttuttryck så att de returnerar en annan datatyp.
- Flytta mått till en annan hemtabell. Det beror på att en flytt av ett mått kan bryta rapportomfattningar som helt kvalificerar mått med deras starttabellnamn. Vi rekommenderar inte att du skriver DAX-uttryck med fullständigt kvalificerade måttnamn. Mer information finns i DAX: Kolumn- och måttreferenser.
Det är säkert att lägga till nya tabeller, kolumner, hierarkier, hierarkinivåer eller mått, med ett undantag: Det är möjligt att ett nytt måttnamn kan kollidera med ett måttnamn med rapportomfattning. För att undvika kollision rekommenderar vi att rapportförfattarna antar en namngivningskonvention när de definierar mått i sina rapporter. De kan prefixa rapportomfångsbegränsade måttnamn med ett understreck eller några andra tecken.
Om du måste göra icke-bakåtkompatibla ändringar i dina modeller rekommenderar vi att du antingen:
- Visa relaterat innehåll för den semantiska modellen i Power BI-tjänst.
- Utforska vyn Data härkomst i Power BI-tjänst.
Med båda alternativen kan du snabbt identifiera relaterade rapporter och instrumentpaneler. Data härkomstvyn är förmodligen det bättre valet eftersom det är enkelt att se kontaktpersonen för varje relaterat objekt. Det är faktiskt en hyperlänk som öppnar ett e-postmeddelande som är adresserat till kontakten.
Vi rekommenderar att du kontaktar ägaren av varje relaterat objekt för att informera dem om eventuella planerade icke-bakåtkompatibla ändringar. På så sätt kan de vara förberedda och redo att åtgärda och publicera om sina rapporter, vilket hjälper till att minimera stilleståndstid och frustration.
Relaterat innehåll
Mer information om den här artikeln finns i följande resurser: