Den här artikeln riktar sig till Power BI Desktop-datamodellerare. Den beskriver star-schemadesign och dess relevans för att utveckla Power BI-semantiska modeller som är optimerade för prestanda och användbarhet.
Viktigt
Power BI-semantiska modeller är beroende av Power Query för att importera eller ansluta till data. Det innebär att du måste använda Power Query för att transformera och förbereda källdata, vilket kan vara svårt när du har stora datavolymer eller om du behöver implementera avancerade begrepp som långsamt föränderliga dimensioner (beskrivs senare i den här artikeln).
När du får dessa utmaningar rekommenderar vi att du först utvecklar ett informationslager och ETL-processer (Extract, Transform, and Load) för att regelbundet läsa in informationslagret. Din semantiska modell kan sedan ansluta till informationslagret. Mer information finns i Dimensionsmodellering i Microsoft Fabric Warehouse.
Tips
Den här artikeln är inte avsedd att ge en fullständig diskussion om star-schemadesign. Mer information finns direkt i allmänt antaget publicerat innehåll, till exempel The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3rd edition, 2013) av Ralph Kimball och andra.
Översikt över Star-schema
Star-schema är en mogen modelleringsmetod som används i stor utsträckning av relationsdatalager. Det kräver att modellerare klassificerar sina modelltabeller som antingen dimension eller fakta.
Dimensionstabeller beskriver affärsentiteter – de saker som du modellerar. Entiteter kan innehålla produkter, personer, platser och begrepp, inklusive själva tiden. Den mest konsekventa tabellen som du hittar i ett stjärnschema är en datumdimensionstabell. En dimensionstabell innehåller en nyckelkolumn (eller kolumner) som fungerar som en unik identifierare och andra kolumner. Andra kolumner stöder filtrering och gruppering av dina data.
Faktatabeller lagrar observationer eller händelser och kan vara försäljningsorder, lagersaldon, växelkurser, temperaturer med mera. En faktatabell innehåller dimensionsnyckelkolumner som relaterar till dimensionstabeller och numeriska måttkolumner. Dimensionsnyckelkolumnerna bestämmer dimensionaliteten i en faktatabell, medan dimensionsnyckelvärdena bestämmer kornigheten i en faktatabell. Tänk dig till exempel en faktatabell som är utformad för att lagra försäljningsmål som har två dimensionsnyckelkolumner Date och ProductKey. Det är lätt att förstå att tabellen har två dimensioner. Kornigheten kan dock inte fastställas utan hänsyn till dimensionsnyckelvärdena. I det här exemplet bör du tänka på att de värden som lagras i kolumnen är den första dagen i Date varje månad. I det här fallet är kornigheten på månadsnivå.
I allmänhet innehåller dimensionstabeller ett relativt litet antal rader. Faktatabeller kan däremot innehålla ett stort antal rader och fortsätta växa med tiden.
Normalisering jämfört med avnormalisering
För att förstå några star-schemabegrepp som beskrivs i den här artikeln är det viktigt att känna till två termer: normalisering och avnormalisering.
Normalisering är den term som används för att beskriva data som lagras på ett sätt som minskar repetitious-data. Överväg en tabell med produkter som har en unik nyckelvärdekolumn, till exempel produktnyckeln, och andra kolumner som beskriver produktegenskaper, till exempel produktnamn, kategori, färg och storlek. En försäljningstabell anses normaliserad när den endast lagrar nycklar, till exempel produktnyckeln. Observera att endast ProductKey kolumnen registrerar produkten i följande bild.
Men om försäljningstabellen lagrar produktinformation utanför nyckeln anses den avnormaliserad. Observera att de ProductKey och andra produktrelaterade kolumnerna registrerar produkten i följande bild.
När du hämtar data från en exportfil eller ett dataextrahering är det troligt att det representerar en avnormaliserad uppsättning data. I det här fallet använder du Power Query för att transformera och forma källdata till flera normaliserade tabeller.
Som beskrivs i den här artikeln bör du sträva efter att utveckla optimerade Power BI-semantiska modeller med tabeller som representerar normaliserade fakta- och dimensionsdata. Det finns dock ett undantag där en snowflake-dimension kan avnormaliseras för att skapa en enda modelltabell.
Star-schema relevans för Power BI-semantikmodeller
Star-schemadesign och många relaterade begrepp som introduceras i den här artikeln är mycket relevanta för att utveckla Power BI-modeller som är optimerade för prestanda och användbarhet.
Tänk på att varje visuellt Power BI-rapportobjekt genererar en fråga som skickas till Power BI-semantikmodellen. I allmänhet filtrerar, grupperar och sammanfattar frågor modelldata. En väl utformad modell är alltså en modell som tillhandahåller tabeller för filtrering och gruppering samt tabeller för sammanfattning. Den här designen passar bra med star-schemaprinciper:
Dimensionstabeller möjliggör filtrering och gruppering.
Faktatabeller aktiverar sammanfattning.
Det finns ingen tabellegenskap som modellerare har angett för att ange tabelltypen som dimension eller fakta. Det bestäms faktiskt av modellrelationerna. En modellrelation upprättar en filterspridningssökväg mellan två tabeller och det är kardinalitetsegenskapen för relationen som avgör tabelltypen. En vanlig relations kardinalitet är en-till-många eller dess omvända många-till-en. Sidan "en" är alltid en dimensionstabell medan "många"-sidan alltid är en faktatabell.
En välstrukturerad modelldesign innehåller tabeller som antingen är dimensionstabeller eller faktatabeller. Undvik att blanda ihop de två typerna för en enda tabell. Vi rekommenderar också att du strävar efter att leverera rätt antal tabeller med rätt relationer på plats. Det är också viktigt att faktatabeller alltid läser in data i ett konsekvent korn.
Slutligen är det viktigt att förstå att optimal modelldesign är en del av vetenskap och delkonst. Ibland kan du bryta med bra vägledning när det är vettigt att göra det.
Det finns många begrepp som rör star-schemadesign som kan tillämpas på en Power BI-semantisk modell. Dessa begrepp omfattar:
I star-schemadesign är ett mått en faktatabellkolumn som lagrar värden som ska sammanfattas. I en Power BI-semantisk modell har ett mått en annan definition, men liknande. En modell stöder både explicita och implicita mått.
Explicita mått skapas uttryckligen och de baseras på en formel som skrivits i DAX (Data Analysis Expressions) som uppnår sammanfattning. Måttuttryck använder ofta DAX-aggregeringsfunktioner som SUM, MIN, MAX, AVERAGEoch andra för att skapa ett skalärt värderesultat vid frågetillfället (värden lagras aldrig i modellen). Måttuttrycket kan variera från enkla kolumnaggregeringar till mer avancerade formler som åsidosätter filterkontext och/eller relationsspridning. Mer information finns i DAX Basics i Power BI Desktop.
Implicita mått är kolumner som kan sammanfattas av ett visuellt rapportobjekt eller Q&A. De erbjuder en bekvämlighet för dig som modellutvecklare, eftersom du i många fall inte behöver skapa (explicita) mått. Till exempel kan kolumnen Adventure Works återförsäljares försäljning Sales Amount sammanfattas på flera sätt (summa, antal, medelvärde, median, min, max och andra), utan att du behöver skapa ett mått för varje möjlig aggregeringstyp.
I fönstret Data representeras explicita mått av kalkylatorikonen medan implicita mått representeras av sigmasymbolen (∑).
Det finns dock tre övertygande orsaker till varför du kan skapa mått, även för enkla sammanfattningar på kolumnnivå:
När du vet att rapportförfattarna kommer att köra frågor mot den semantiska modellen med hjälp av flerdimensionella uttryck (MDX) måste modellen innehålla explicita mått. Det beror på att MDX inte kan uppnå sammanfattning av kolumnvärden. I synnerhet används MDX när du utför Analysera i Excel eftersom pivottabeller utfärdar MDX-frågor.
När du vet att rapportförfattarna skapar sidnumrerade Power BI-rapporter med hjälp av MDX-frågedesignern måste den semantiska modellen innehålla explicita mått. Endast MDX-frågedesignern stöder serveraggregat. Om rapportförfattarna behöver ha mått utvärderade av Power BI (i stället för av den sidnumrerade rapportmotorn) måste de använda MDX-frågedesignern.
När du vill styra hur rapportförfattarna sammanfattar kolumner på specifika sätt. Till exempel kan återförsäljarsäljarkolumnen Unit Price (som representerar en pris per enhet) sammanfattas, men bara med hjälp av specifika aggregeringsfunktioner. Den bör aldrig summeras, men det är lämpligt att sammanfatta med hjälp av andra aggregeringsfunktioner som min, max eller genomsnitt. I det här fallet kan modelleraren dölja Unit Price kolumnen och skapa mått för alla lämpliga sammansättningsfunktioner.
Den här designmetoden fungerar bra för rapporter som skapats i Power BI-tjänst och för Q&A. Med Power BI Desktop-liveanslutningarkan rapportförfattare dock visa dolda fält i fönstret Data, vilket kan leda till att den här designmetoden kringgås.
Surrogatnycklar
En surrogatnyckel är en unik identifierare som du lägger till i en tabell för att stödja star-schemamodellering. Per definition är den inte definierad eller lagrad i källdata. Surrogatnycklar läggs vanligtvis till i relationsdatalagerdimensionstabeller för att tillhandahålla en unik identifierare för varje dimensionstabellrad.
Power BI-semantiska modellrelationer baseras på en enda unik kolumn i en tabell, som sprider filter till en enda kolumn i en annan tabell. När en dimensionstabell i din semantiska modell inte innehåller en enda unik kolumn måste du lägga till en unik identifierare för att bli "en"-sidan av en relation. I Power BI Desktop kan du uppnå det här kravet genom att lägga till en Power Query-indexkolumn.
Du måste sammanfoga den här frågan med frågan "många"-sidan så att du kan lägga till indexkolumnen i den också. När du läser in dessa frågor till den semantiska modellen kan du sedan skapa en en-till-många-relation mellan modelltabellerna.
Snowflake-dimensioner
En snowflake-dimension är en uppsättning normaliserade tabeller för en enskild affärsentitet. Adventure Works klassificerar till exempel produkter efter kategori och underkategori. Produkter tilldelas till underkategorier och underkategorier tilldelas i sin tur till kategorier. I relationsinformationslagret för Adventure Works normaliseras och lagras produktdimensionen i tre relaterade tabeller: DimProductCategory, DimProductSubcategoryoch DimProduct.
Om du använder din fantasi kan du föreställa dig de normaliserade tabellerna som placeras utåt från faktatabellen och bilda en snowflake-design.
I Power BI Desktop kan du välja att efterlikna en snowflake-dimensionsdesign (kanske för att dina källdata gör det) eller kombinera källtabellerna för att bilda en enda, avnormaliserad modelltabell. I allmänhet uppväger fördelarna med en enskild modelltabell fördelarna med flera modelltabeller. Det mest optimala beslutet kan bero på datavolymerna och användbarhetskraven för modellen.
När du väljer att efterlikna en snowflake-dimensionsdesign:
Power BI läser in fler tabeller, vilket är mindre effektivt ur lagrings- och prestandaperspektiv. Dessa tabeller måste innehålla kolumner för att stödja modellrelationer, och det kan resultera i en större modellstorlek.
Längre distributionskedjor för relationsfilter måste passeras, vilket kan vara mindre effektivt än filter som tillämpas på en enda tabell.
Fönstret Data visar fler modelltabeller för rapportförfattare, vilket kan resultera i en mindre intuitiv upplevelse, särskilt när snowflake-dimensionstabeller bara innehåller en eller två kolumner.
Det går inte att skapa en hierarki som består av kolumner från mer än en tabell.
När du väljer att integrera i en enskild modelltabell kan du också definiera en hierarki som omfattar dimensionens högsta och lägsta korn. Eventuellt kan lagring av redundanta avnormaliserade data leda till ökad modelllagringsstorlek, särskilt för stora dimensionstabeller.
Långsamt föränderliga dimensioner
En långsamt föränderlig dimension (eller SCD) är en dimension som hanterar ändringar av dimensionsmedlemmar över tid. Det gäller när affärsentitetsvärden ändras långsamt över tid på ett oplanerat sätt. Ett bra exempel på en SCD är en kunddimension, eftersom dess kolumner med kontaktinformation som e-postadress och telefonnummer ändras sällan. Däremot anses vissa dimensioner förändras snabbt när ett dimensionsattribut ändras ofta, till exempel börskursen för en aktie. Den vanliga designmetoden i dessa instanser är att lagra snabbt föränderliga attributvärden i ett faktatabellmått.
Designteori för star-schema refererar till två vanliga SCD-typer: Typ 1 och Typ 2. En dimensionstabell kan vara typ 1 eller typ 2, eller ha stöd för båda typerna samtidigt för olika kolumner.
Typ 1 SCD
En SCD av typ 1 återspeglar alltid de senaste värdena, och när ändringar i källdata identifieras skrivs dimensionstabelldata över. Den här designmetoden är vanlig för kolumner som lagrar tilläggsvärden, till exempel en kunds e-postadress eller telefonnummer. När en kunds e-postadress eller telefonnummer ändras uppdaterar dimensionstabellen kundraden med de nya värdena. Det är som om kunden alltid hade den här kontaktinformationen.
En icke-inkrementell uppdatering av en Power BI-modelldimensionstabell uppnår resultatet av en SCD av typ 1. Den uppdaterar tabelldata för att säkerställa att de senaste värdena läses in.
Typ 2 SCD
En SCD av typ 2 stöder versionshantering av dimensionsmedlemmar. Om källsystemet inte lagrar versioner är det vanligtvis informationslagrets inläsningsprocess som identifierar ändringar och hanterar ändringen i en dimensionstabell på rätt sätt. I det här fallet måste dimensionstabellen använda en surrogatnyckel för att ge en unik referens till en version av dimensionsmedlemmen. Den innehåller också kolumner som definierar datumintervallets giltighet för versionen (till exempel StartDate och EndDate) och eventuellt en flaggkolumn (till exempel IsCurrent) för att enkelt filtrera efter aktuella dimensionsmedlemmar.
Adventure Works tilldelar till exempel varje säljare till en försäljningsregion. När en säljare flyttar region måste en ny version av säljaren skapas för att säkerställa att historiska fakta förblir associerade med den tidigare regionen. För att stödja korrekt historisk analys av försäljning efter säljare måste dimensionstabellen lagra versioner av säljare och deras associerade regioner. Tabellen bör också innehålla start- och slutdatumvärden för att definiera tids giltigheten. Aktuella versioner kan definiera ett tomt slutdatum (eller 12/31/9999), vilket anger att raden är den aktuella versionen. Tabellen måste också ha en surrogatnyckel eftersom affärsnyckeln (i det här fallet medarbetar-ID) inte är unik.
Det är viktigt att förstå att när källdata inte lagrar versioner måste du använda ett mellanliggande system (t.ex. ett informationslager) för att identifiera och lagra ändringar. Tabellinläsningsprocessen måste bevara befintliga data och identifiera ändringar. När en ändring identifieras måste tabellinläsningsprocessen förfalla den aktuella versionen. Den registrerar dessa ändringar genom att uppdatera EndDate värdet och infoga en ny version med värdet StartDate från föregående EndDate värde. Dessutom måste relaterade fakta använda en tidsbaserad sökning för att hämta dimensionsnyckelvärdet som är relevant för faktadatumet. En Power BI-semantisk modell använder Power Query och kan därför inte generera det här resultatet. Den kan dock läsa in data från en förinläst SCD-dimensionstabell av typ 2.
Tips
Information om hur du implementerar en SCD-dimensionstabell av typ 2 i ett infrastrukturlager finns i Hantera historiska ändringar.
Power BI-semantikmodellen bör ha stöd för att fråga efter historiska data för en medlem, oavsett ändring, och för en version av medlemmen, som representerar ett visst tillstånd för medlemmen i tid. I samband med Adventure Works gör den här designen att du kan fråga säljaren oavsett tilldelad försäljningsregion eller för en viss version av säljaren.
För att uppnå detta krav måste power BI-semantisk modelldimensionstabell innehålla en kolumn för filtrering av säljaren och en annan kolumn för filtrering av en viss version av säljaren. Det är viktigt att versionskolumnen innehåller en icke-tvetydig beskrivning, t.ex David Campbell (12/15/2008-06/26/2019) . eller David Campbell (06/27/2019-Current). Det är också viktigt att utbilda rapportförfattare och konsumenter om grunderna i SCD Typ 2 och hur du uppnår lämpliga rapportdesigner genom att använda rätt filter.
Det är en bra designmetod att inkludera en hierarki som gör att visuella objekt kan öka detaljnivån till versionsnivån.
Dimensioner med olika roller
En rollspelsdimension är en dimension som kan filtrera relaterade fakta på olika sätt. I Adventure Works har till exempel datumdimensionstabellen tre relationer till återförsäljarförsäljningsfakta. Samma dimensionstabell kan användas för att filtrera fakta efter orderdatum, leveransdatum eller leveransdatum.
I ett informationslager är den godkända designmetoden att definiera en enda datumdimensionstabell. Vid frågetillfället upprättas "rollen" för datumdimensionen med vilken faktakolumn du använder för att ansluta tabellerna. När du till exempel analyserar försäljning efter orderdatum relaterar tabellkopplingen till kolumnen försäljningsorderdatum för återförsäljare.
I en Power BI-semantisk modell kan den här designen imiteras genom att skapa flera relationer mellan två tabeller. I Adventure Works-exemplet skulle tabellerna för datum- och återförsäljares försäljning ha tre relationer.
Även om den här designen är möjlig kan det bara finnas en aktiv relation mellan två Power BI-semantiska modelltabeller. Alla återstående relationer måste vara inaktiva. Att ha en enda aktiv relation innebär att det finns en standardfilterspridning från datum till återförsäljares försäljning. I det här fallet är den aktiva relationen inställd på det vanligaste filtret som används av rapporter, som i Adventure Works är orderdatumrelationen.
Det enda sättet att använda en inaktiv relation är att definiera ett DAX-uttryck som använder funktionen USERELATIONSHIP . I vårt exempel måste modellutvecklaren skapa mått för att möjliggöra analys av återförsäljares försäljning efter leveransdatum och leveransdatum. Det här arbetet kan vara omständligt, särskilt när återförsäljartabellen definierar många mått. Det skapar också ett rörigt datafönster som har ett överflöd av mått. Det finns även andra begränsningar:
När rapportförfattarna förlitar sig på att sammanfatta kolumner i stället för att definiera mått, kan de inte uppnå sammanfattning för de inaktiva relationerna utan att skriva ett mått på rapportnivå. Mått på rapportnivå kan bara definieras vid redigering av rapporter i Power BI Desktop.
Med bara en aktiv relationssökväg mellan datum- och återförsäljares försäljning går det inte att samtidigt filtrera återförsäljares försäljning efter olika typer av datum. Du kan till exempel inte skapa ett visuellt objekt som ritar orderdatumförsäljning genom levererad försäljning.
För att övervinna dessa begränsningar är en vanlig Power BI-modelleringsteknik att skapa en dimensionstabell för varje rollspelsinstans. Du kan skapa varje dimensionstabell som en referensfråga med hjälp av Power Query eller en beräknad tabell med DAX. Modellen kan innehålla en Date tabell, en Ship Date tabell och en Delivery Date tabell, var och en med en enda och aktiv relation till respektive återförsäljares försäljningstabellkolumner.
Den här designmetoden kräver inte att du definierar flera mått för olika datumroller och tillåter samtidig filtrering efter olika datumroller. Ett lägre pris att betala med den här designmetoden är dock att det kommer att finnas duplicering av datumdimensionstabellen som resulterar i en ökad modelllagringsstorlek. Eftersom dimensionstabeller vanligtvis lagrar färre rader i förhållande till faktatabeller är det sällan ett problem.
Vi rekommenderar att du följer bra designmetoder när du skapar modelldimensionstabeller för varje roll:
Kontrollera att kolumnnamnen är självbeskrivande. Även om det är möjligt att ha en Year kolumn i alla datumtabeller (kolumnnamn är unika i deras tabell), är det inte självbeskrivande som standardrubriker för visuella objekt. Överväg att byta namn på kolumner i varje dimensionsrolltabell så att Ship Date tabellen har en årskolumn med namnet Ship Year, och så vidare.
När det är relevant ska du se till att tabellbeskrivningar ger feedback till rapportförfattare (via knappbeskrivningar för datafönstret ) om hur filterspridning konfigureras. Den här tydligheten är viktig när modellen innehåller en allmänt namngiven tabell, till exempel Date, som används för att filtrera många faktatabeller. Om den här tabellen till exempel har en aktiv relation till kolumnen reseller sales order date kan du överväga att ange en tabellbeskrivning som Filters reseller sales by order date.
Mer information finns i Vägledning för aktiva kontra inaktiva relationer.
Skräpdimensioner
En skräpdimension är användbar när det finns många dimensioner, särskilt som består av få attribut (kanske en), och när dessa attribut har få värden. Bra kandidater inkluderar orderstatuskolumner eller kunddemografikolumner som kön eller åldersgrupp.
Designmålet för en skräpdimension är att konsolidera många små dimensioner till en enda dimension för att minska modellens lagringsstorlek och även minska skräpet i datafönstret genom att visa färre modelltabeller.
En skräpdimensionstabell är vanligtvis kartesisk produkt för alla dimensionsattributmedlemmar, med en surrogatnyckelkolumn som unikt identifierar varje rad. Du kan skapa dimensionen i ett informationslager eller genom att använda Power Query för att skapa en fråga som utför fullständiga yttre frågekopplingar och sedan lägga till en surrogatnyckel (indexkolumn).
Du läser in den här frågan till modellen som en dimensionstabell. Du måste också sammanfoga den här frågan med faktafrågan så att indexkolumnen läses in i modellen för att stödja skapandet av en "en-till-många"-modellrelation.
Degenerera dimensioner
En degenererad dimension refererar till ett attribut för faktatabellen som krävs för filtrering. På Adventure Works är återförsäljarens försäljningsordernummer ett bra exempel. I det här fallet är det inte meningsfullt att skapa en oberoende tabell som bara består av den här kolumnen eftersom det skulle öka modellens lagringsstorlek och leda till att datafönstret blir rörigt.
I Power BI-semantikmodellen kan det vara lämpligt att lägga till kolumnen försäljningsordernummer i faktatabellen för att tillåta filtrering eller gruppering efter försäljningsordernummer. Det är ett undantag från den tidigare introducerade regeln att du inte bör blanda tabelltyper (i allmänhet bör modelltabeller vara antingen dimension eller fakta).
Men om adventure works-återförsäljarnas försäljningstabell har kolumner för ordernummer och orderradsnummer, och de krävs för filtrering, skulle det vara en bra design att skapa en degenererad dimensionstabell. Mer information finns i Vägledning om en-till-en-relation (Degenererade dimensioner).
Faktalösa faktatabeller
En faktalös faktatabell innehåller inga måttkolumner. Den innehåller endast dimensionsnycklar.
En faktalös faktatabell kan lagra observationer som definierats av dimensionsnycklar. Till exempel vid ett visst datum och en viss tidpunkt loggade en viss kund in på din webbplats. Du kan definiera ett mått för att räkna raderna i den faktalösa faktatabellen för att utföra en analys av när och hur många kunder som är inloggade.
En mer övertygande användning av en faktalös faktatabell är att lagra relationer mellan dimensioner, och det är en power BI-semantisk modelldesignmetod som vi rekommenderar för att definiera många-till-många-dimensionsrelationer. I en många-till-många-dimensionsrelationsdesign kallas den faktalösa faktatabellen för en bryggningstabell.
Anta till exempel att säljare kan tilldelas till en eller flera försäljningsregioner. Bryggningstabellen skulle utformas som en faktalös faktatabell som består av två kolumner: säljnyckel och regionnyckel. Dubblettvärden kan lagras i båda kolumnerna.
Processen att skapa en komplicerad semantisk modell i Power BI är enkel. Om dina data kommer från fler än ett transaktionssystem kan du, innan du vet ordet av, har dussintals tabeller som du måste arbeta med. Att skapa en bra semantisk modell handlar om att förenkla oredan. Ett star schema är ett sätt att förenkla en semantisk modell och du lär dig mer om terminologin och implementeringen av dem i den här modulen. Du får också lära dig om varför det är viktigt att välja rätt detaljnivå för data för att dina
Demonstrate methods and best practices that align with business and technical requirements for modeling, visualizing, and analyzing data with Microsoft Power BI.