Forstå, hvad et stjerneskema er, og hvorfor det er vigtigt for Power BIUnderstand star schema and the importance for Power BI

Denne artikel henvender sig til personer, der skaber Power BI Desktop-datamodeller.This article targets Power BI Desktop data modelers. Heri beskrives, hvad et stjerneskemadesign er, og hvilken relevans det har for udvikling af Power BI-datamodeller, der er optimeret til ydeevne og anvendelighed.It describes star schema design and its relevance to developing Power BI data models optimized for performance and usability.

Det er ikke meningen, at denne artikel skal indeholde en komplet beskrivelse af stjerneskemadesign.This article isn't intended to provide a complete discussion on star schema design. Du kan finde flere oplysninger ved at se publiceret indhold, såsom The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3. udgave, 2013) af Ralph Kimball et al.For more details, refer directly to published content, like The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3rd edition, 2013) by Ralph Kimball et al.

Oversigt over stjerneskemaStar schema overview

Et stjerneskema er en fuldt udviklet udformningstilgang, som en lang række relationelle data warehouses anvender.Star schema is a mature modeling approach widely adopted by relational data warehouses. Det kræver, at modeludviklere klassificerer deres modeltabeller som enten dimension eller fakta.It requires modelers to classify their model tables as either dimension or fact.

Dimensionstabeller beskriver forretningsenheder – de ting, du udformer.Dimension tables describe business entities—the things you model. Enheder kan omfatte produkter, personer, steder og begreber, inklusive tid.Entities can include products, people, places, and concepts including time itself. Den mest ensartede tabel, du finder i et stjerneskema, er en datodimensionstabel.The most consistent table you'll find in a star schema is a date dimension table. En dimensionstabel indeholder en nøglekolonne (eller kolonner), der fungerer som et entydigt id, og beskrivende kolonner.A dimension table contains a key column (or columns) that acts as a unique identifier, and descriptive columns.

Faktatabeller gemmer observationer eller hændelser og kan være salgsordrer, lageropgørelser, valutakurser, temperaturer osv. En faktatabel indeholder dimensionsnøglekolonner, der er relateret til dimensionstabeller og numeriske målingskolonner.Fact tables store observations or events, and can be sales orders, stock balances, exchange rates, temperatures, etc. A fact table contains dimension key columns that relate to dimension tables, and numeric measure columns. Dimensionsnøglekolonnerne bestemmer dimensionaliteten for en faktatabel, mens dimensionsnøgleværdierne bestemmer granulariteten for en faktatabel.The dimension key columns determine the dimensionality of a fact table, while the dimension key values determine the granularity of a fact table. Tag f.eks. en faktatabel, der er designet til at gemme salgsmål, som har to dimensionsnøglekolonner: Dato og Produktnøgle.For example, consider a fact table designed to store sale targets that has two dimension key columns Date and ProductKey. Det er nemt at forstå, at tabellen har to dimensioner.It's easy to understand that the table has two dimensions. Det er dog ikke muligt at bestemme granulariteten uden at tage højde for dimensionsnøgleværdierne.The granularity, however, can't be determined without considering the dimension key values. I dette eksempel er de værdier, der er gemt i kolonnen Dato, den første dag i måneden.In this example, consider that the values stored in the Date column are the first day of each month. I dette tilfælde er granulariteten på måned-produkt-niveauet.In this case, the granularity is at month-product level.

Dimensionstabeller indeholder generelt et relativt lille antal rækker.Generally, dimension tables contain a relatively small number of rows. Faktatabeller kan omvendt indeholde et meget stort antal rækker og fortsætte med at vokse over tid.Fact tables, on the other hand, can contain a very large number of rows and continue to grow over time.

Illustration af et stjerneskema

Relevans af stjerneskema i forhold til Power BI-modellerStar schema relevance to Power BI models

Stjerneskemadesign og mange af de relaterede begreber, der introduceres i denne artikel, er yderst relevante for udvikling af Power BI-modeller, der er optimeret til ydeevne og anvendelighed.Star schema design and many related concepts introduced in this article are highly relevant to developing Power BI models that are optimized for performance and usability.

Hver visualisering i en Power BI-rapport genererer en forespørgsel, der sendes til Power BI-modellen (som Power BI-tjenesten kalder for et datasæt).Consider that each Power BI report visual generates a query that is sent to the Power BI model (which the Power BI service calls a dataset). Disse forespørgsler bruges til at filtrere, gruppere og opsummere modeldata.These queries are used to filter, group, and summarize model data. En veldesignet model er derfor en model, der indeholder tabeller til filtrering og gruppering samt tabeller til opsummering.A well-designed model, then, is one that provides tables for filtering and grouping, and tables for summarizing. Dette design passer godt med principperne for et stjerneskema:This design fits well with star schema principles:

  • Dimensionstabeller understøtter filtrering og grupperingDimension tables support filtering and grouping
  • Faktatabeller understøtter opsummeringFact tables support summarization

Der er ingen tabelegenskab, som modeludviklere angiver for at konfigurere tabeltypen som dimension eller fakta.There's no table property that modelers set to configure the table type as dimension or fact. Det bestemmes faktisk af modelrelationerne.It's in fact determined by the model relationships. En modelrelation etablerer en filteroverførselssti mellem to tabeller, og det er relationens egenskab for Kardinalitet, der bestemmer tabeltypen.A model relationship establishes a filter propagation path between two tables, and it's the Cardinality property of the relationship that determines the table type. En almindelig kardinalitet for en relation er en til mange eller den omvendte mange til en.A common relationship cardinality is one-to-many or its inverse many-to-one. "En"-siden er altid en dimensionstabel, hvorimod "mange"-siden altid er en faktatabel.The "one" side is always a dimension-type table while the "many" side is always a fact-type table. Du kan finde flere oplysninger om relationer i Modelrelationer i Power BI Desktop.For more information about relationships, see Model relationships in Power BI Desktop.

Konceptuelt stjerneskema

Et velstruktureret modeldesign bør omfatte tabeller, der enten er af typen dimensionstabel eller af typen faktatabel.A well-structured model design should include tables that are either dimension-type tables or fact-type tables. Undgå at blande de to typer sammen i en enkelt tabel.Avoid mixing the two types together for a single table. Det anbefales også, at du stræber efter at levere det rette antal tabeller med de rigtige relationer på plads.We also recommend that you should strive to deliver the right number of tables with the right relationships in place. Det er også vigtigt, at faktatabeller altid indlæser data i en ensartet retning.It's also important that fact-type tables always load data at a consistent grain.

Endelig er det vigtigt at forstå, at det optimale modeldesign er delvist videnskab og delvist kunst.Lastly, it's important to understand that optimal model design is part science and part art. Nogle gange kan du se bort fra gode råd, når det giver mening for dig at gøre det.Sometimes you can break with good guidance when it makes sense to do so.

Der er mange andre begreber, som er relateret til stjerneskemadesign, der kan anvendes på en Power BI-model.There are many additional concepts related to star schema design that can be applied to a Power BI model. Disse begreber omfatter:These concepts include:

MålingerMeasures

I et stjerneskemadesign er en måling en kolonne i en faktatabel, der gemmer værdier, som skal opsummeres.In star schema design, a measure is a fact table column that stores values to be summarized.

I en Power BI-model har en måling en anden – men lignende – definition.In a Power BI model, a measure has a different—but similar—definition. Det er en formel, som er skrevet i DAX (Data Analysis Expressions), der resulterer i opsummering.It's a formula written in Data Analysis Expressions (DAX) that achieves summarization. DAX-sammenlægningsfunktioner, som SUM, MIN., MAKS., GENNEMSNIT osv., bruges ofte i målingsudtryk til at skabe et skalarværdisæt på forespørgselstidspunktet (værdierne gemmes aldrig i modellen).Measure expressions often leverage DAX aggregation functions like SUM, MIN, MAX, AVERAGE, etc. to produce a scalar value result at query time (values are never stored in the model). Målingsudtryk kan variere fra simple kolonnesammenlægninger til mere avancerede formler, der tilsidesætter filterkontekst og/eller relationsoverførsler.Measure expression can range from simple column aggregations to more sophisticated formulas that override filter context and/or relationship propagation. Du kan finde flere oplysninger i artiklen Grundlæggende om DAX i Power BI Desktop.For more information, read the DAX Basics in Power BI Desktop article.

Det er vigtigt at forstå, at Power BI-modeller understøtter en anden metode for at resultere i opsummering.It's important to understand that Power BI models support a second method for achieving summarization. En hvilken som helst kolonne – og som regel numeriske kolonner – kan opsummeres i en visualisering i en rapport eller ved hjælp af Spørgsmål og svar.Any column—and typically numeric columns—can be summarized by a report visual or Q&A. Disse kolonner kaldes implicitte målinger.These columns are referred to as implicit measures. De er praktiske for dig som modeludvikler, da du i mange tilfælde ikke har brug for at oprette målinger.They offer a convenience for you as a model developer, as in many instances you do not need to create measures. Kolonnen Salgsbeløb for Adventure Works-forhandlersalg kan opsummeres på flere måder (sum, antal, gennemsnit, median, min., maks. osv.), uden at det er nødvendigt at oprette en måling for hver mulige sammenlægningstype.For example, the Adventure Works reseller sales Sales Amount column could be summarized in numerous ways (sum, count, average, median, min, max, etc.), without the need to create a measure for each possible aggregation type.

Eksempel på ikon på feltliste

Der er dog tre overbevisende grunde til, at du bør oprette målinger selv for simple opsummeringer på kolonneniveau:However, there are three compelling reasons for you to create measures, even for simple column-level summarizations:

  • Når du ved, at rapportforfatterne sender forespørgsler til modellen ved hjælp af flerdimensionelle udtryk (MDX), skal modellen indeholde eksplicitte målinger.When you know your report authors will query the model by using Multidimensional Expressions (MDX), the model must include explicit measures. Eksplicitte målinger defineres ved hjælp af DAX.Explicit measures are defined by using DAX. Denne designmetode er yderst relevant, når der sendes en forespørgsel til et Power BI-datasæt ved hjælp af MDX, da MDX ikke kan opnå opsummering af kolonneværdier.This design approach is highly relevant when a Power BI dataset is queried by using MDX, because MDX can't achieve summarization of column values. MDX bruges især, når der udføres analyser i Excel, fordi pivottabeller udsteder MDX-forespørgsler.Notably, MDX will be used when performing Analyze in Excel, because PivotTables issue MDX queries.
  • Når du ved, at rapportforfatterne opretter sideinddelte rapporter i Power BI ved hjælp af MDX-forespørgselsdesigneren, skal modellen indeholde eksplicitte metoder.When you know your report authors will create Power BI paginated reports using the MDX query designer, the model must include explicit measures. Det er kun MDX-forespørgselsdesigneren, der understøtter serversamlinger.Only the MDX query designer supports server aggregates. Hvis det er nødvendigt for rapportforfatterne at have målinger, der evalueres af Power BI (i stedet for af det sideinddelte rapportprogram), skal de derfor bruge MDX-forespørgselsdesigneren.So, if report authors need to have measures evaluated by Power BI (instead of by the paginated report engine), they must use the MDX query designer.
  • Hvis du vil sikre dig, at dine rapportforfattere kun kan opsummere kolonner på bestemte måder.When you need to ensure that your report authors can only summarize columns in specific ways. Kolonnen Enhedspris for forhandlersalg (der repræsenterer en pris pr. enhed) kan f.eks. opsummeres, men kun ved hjælp af bestemte sammenlægningsfunktioner.For example, the reseller sales Unit Price column (which represents a per unit rate) can be summarized, but only by using specific aggregation functions. Den bør aldrig lægges sammen, men den kan passende opsummeres ved hjælp af andre sammenlægningsfunktioner som f.eks. min., maks., gennemsnit osv. I dette tilfælde kan modeludvikleren skjule kolonnen Enhedspris og oprette målinger for alle relevante sammenlægningsfunktioner.It should never be summed, but it's appropriate to summarize by using other aggregation functions like min, max, average, etc. In this instance, the modeler can hide the Unit Price column, and create measures for all appropriate aggregation functions.

Denne designtilgang fungerer godt til rapporter, der forfattes i Power BI-tjenesten, og til Spørgsmål og svar.This design approach works well for reports authored in the Power BI service and for Q&A. Direkte forbindelser i Power BI Desktop giver dog rapportforfattere mulighed for at få vist skjulte felter i ruden Felter, der kan resultere i omgåelse af denne designtilgang.However, Power BI Desktop live connections allow report authors to show hidden fields in the Fields pane, which can result in circumventing this design approach.

SurrogatnøglerSurrogate keys

En surrogatnøgle er et entydigt id, som du føjer til en tabel for at understøtte udformning af et stjerneskema.A surrogate key is a unique identifier that you add to a table to support star schema modeling. Den er pr. definition hverken defineret eller gemt i kildedata.By definition, it's not defined or stored in the source data. Surrogatnøgler føjes ofte til dimensionstabeller for relationelle data warehouses for at angive et entydigt id for hver række i dimensionstabellen.Commonly, surrogate keys are added to relational data warehouse dimension tables to provide a unique identifier for each dimension table row.

Power BI-modelrelationer er baseret på en enkelt entydig kolonne i én tabel, der overfører filtre til en enkelt kolonne i en anden tabel.Power BI model relationships are based on a single unique column in one table, which propagates filters to a single column in a different table. Når en dimensionstabel i modellen ikke indeholder en enkelt entydig kolonne, skal du tilføje et entydigt id for at blive til "en"-siden af en relation.When a dimension-type table in your model doesn't include a single unique column, you must add a unique identifier to become the "one" side of a relationship. I Power BI Desktop kan du nemt opfylde dette krav ved at oprette en Power Query-indekskolonne.In Power BI Desktop, you can easily achieve this requirement by creating a Power Query index column.

Opret en indekskolonne i Power Query-værktøjslinjen

Du skal flette denne forespørgsel med "mange"-siden af forespørgslen, så du også kan føje indekskolonnen til den.You must merge this query with the "many"-side query so that you can add the index column to it also. Når du indlæser disse forespørgsler i modellen, kan du oprette en en-til-mange-relation mellem modeltabellerne.When you load these queries to the model, you can then create a one-to-many relationship between the model tables.

Snowflake-dimensionerSnowflake dimensions

En Snowflake-dimension er et sæt normaliserede tabeller til en enkelt forretningsenhed.A snowflake dimension is a set of normalized tables for a single business entity. Produkter klassificeres f.eks. efter kategori og underkategori i Adventure Works.For example, Adventure Works classifies products by category and subcategory. Der tildeles kategorier til underkategorier, og produkterne tildeles omvendt underkategorier.Categories are assigned to subcategories, and products are in turn assigned to subcategories. I det relationelle data warehouse, Adventure Works, er produktdimensionen normaliseret og gemt i tre relaterede tabeller: DimProductCategory, DimProductSubcategory og DimProduct.In the Adventure Works relational data warehouse, the product dimension is normalized and stored in three related tables: DimProductCategory, DimProductSubcategory, and DimProduct.

Hvis du bruger din fantasi, kan du forestille dig, at de normaliserede tabeller er placeret ud fra faktatabellen, som danner et snefnugdesign.If you use your imagination, you can picture the normalized tables positioned outwards from the fact table, forming a snowflake design.

Eksempel på Snowflake-diagram

I Power BI Desktop kan du vælge at efterligne et design med en Snowflake-dimension (måske fordi dine kildedata gør) eller integrere (denormalisere) kildetabellerne i en enkelt modeltabel.In Power BI Desktop, you can choose to mimic a snowflake dimension design (perhaps because your source data does) or integrate (denormalize) the source tables into a single model table. Generelt opvejer fordelene ved en enkelt modeltabel fordelene ved flere modeltabeller.Generally, the benefits of a single model table outweigh the benefits of multiple model tables. Den mest optimale beslutning kan være afhængig af datamængderne og kravene til anvendelighed for modellen.The most optimal decision can depend on the volumes of data and the usability requirements for the model.

Når du vælger at efterligne et design med en Snowflake-dimension:When you choose to mimic a snowflake dimension design:

  • Power BI indlæser flere tabeller, hvilket er mindre effektivt set fra et lager- og ydeevneperspektiv.Power BI loads more tables, which is less efficient from storage and performance perspectives. Disse tabeller skal indeholde kolonner, der understøtter modelrelationer, og det kan medføre, at modellen bliver større.These tables must include columns to support model relationships, and it can result in a larger model size.
  • Længere overførselskæder for relationsfiltre skal gennemgås, hvilket er mindre effektivt end filtre, der anvendes på en enkelt tabel.Longer relationship filter propagation chains will need to be traversed, which will likely be less efficient than filters applied to a single table.
  • Ruden Felter præsenterer flere modeltabeller til rapportforfattere, hvilket kan resultere i en mindre intuitiv oplevelse, især når Snowflake-dimensionstabeller kun indeholder én eller to kolonner.The Fields pane presents more model tables to report authors, which can result in a less intuitive experience, especially when snowflake dimension tables contain just one or two columns.
  • Det er ikke muligt at oprette et hierarki, der spænder over tabellerne.It's not possible to create a hierarchy that spans the tables.

Når du vælger at integrere til en enkelt modeltabel, kan du også definere et hierarki, der omfatter den højeste og laveste retning i dimensionen.When you choose to integrate into a single model table, you can also define a hierarchy that encompasses the highest and lowest grain of the dimension. Lagring af redundante, denormaliserede data kan f.eks. resultere i, at modellageret bliver større, især for meget store dimensionstabeller.Possibly, the storage of redundant denormalized data can result in increased model storage size, particularly for very large dimension tables.

Hierarki i en dimension

Dimension, der langsomt ændrer sigSlowly changing dimensions

En dimension, der langsomt ændrer sig er en, der styrer ændringer af dimensionsmedlemmer korrekt over tid.A slowly changing dimension (SCD) is one that appropriately manages change of dimension members over time. Det gælder, når værdier for forretningsenheder ændres over tid og på en ad hoc-måde.It applies when business entity values change over time, and in an ad hoc manner. Et godt eksempel på en dimension, der langsomt ændrer sig, er en kundedimension, især kolonner med kontaktoplysninger, f.eks. mailadresse og telefonnummer.A good example of a slowly changing dimension is a customer dimension, specifically its contact detail columns like email address and phone number. I modsætning hertil anses nogle dimensioner for at ændre sig hurtigt, når en dimensionsattribut ændres ofte, f.eks. en akties markedspris.In contrast, some dimensions are considered to be rapidly changing when a dimension attribute changes often, like a stock's market price. Den almindelige designtilgang i disse tilfælde er at gemme attributværdier, der ændrer sig hurtigt, i en måling i en faktatabel.The common design approach in these instances is to store rapidly changing attribute values in a fact table measure.

Teorien bag et stjerneskemadesign refererer til to almindelige typer af dimensioner, der langsomt ændrer sig: Type 1 og Type 2.Star schema design theory refers to two common SCD types: Type 1 and Type 2. En dimensionstabel kan være Type 1 eller Type 2 eller understøtte begge typer samtidig for forskellige kolonner.A dimension-type table could be Type 1 or Type 2, or support both types simultaneously for different columns.

Type 1 af en dimension, der langsomt ændrer sigType 1 SCD

En Type 1 af en dimension, der langsomt ændrer sig, afspejler altid de nyeste værdier, og når der registreres ændringer i kildedataene, overskrives dataene i dimensionstabellen.A Type 1 SCD always reflects the latest values, and when changes in source data are detected, the dimension table data is overwritten. Denne designtilgang er almindelig for kolonner, der gemmer supplerende værdier, f.eks. en kundes mailadresse eller telefonnummer.This design approach is common for columns that store supplementary values, like the email address or phone number of a customer. Når en kundes mailadresse eller telefonnummer ændres, opdateres kundens række med de nye værdier i dimensionstabellen.When a customer email address or phone number changes, the dimension table updates the customer row with the new values. Det bliver ligesom om, at kunden altid har haft disse kontaktoplysninger.It's as if the customer always had this contact information.

En opdatering, der ikke er trinvis, af en dimensionstabel i en Power BI-model resulterer i en Type 1 af en dimension, der langsomt ændrer sig.A non-incremental refresh of a Power BI model dimension-type table achieves the result of a Type 1 SCD. Tabeldataene opdateres for at sikre, at de nyeste værdier indlæses.It refreshes the table data to ensure the latest values are loaded.

Type 2 af en dimension, der langsomt ændrer sigType 2 SCD

En Type 2 af en dimension, der langsomt ændrer sig, understøtter versionering af dimensionsmedlemmer.A Type 2 SCD supports versioning of dimension members. Hvis kildesystemet ikke gemmer versioner, er det som regel indlæsningsprocessen for det pågældende data warehouse, der registrerer ændringer, og som styrer ændringen i en dimensionstabel korrekt.If the source system doesn't store versions, then it's usually the data warehouse load process that detects changes, and appropriately manages the change in a dimension table. I dette tilfælde skal dimensionstabellen bruge en surrogatnøgle til at angive en entydig reference til en version af dimensionsmedlemmet.In this case, the dimension table must use a surrogate key to provide a unique reference to a version of the dimension member. Den indeholder også kolonner, der definerer gyldigheden af datoområdet for versionen (f.eks. Startdato og Slutdato) og muligvis en kolonne med flag (f.eks. ErAktuel), så der nemt kan filtreres efter aktuelle dimensionsmedlemmer.It also includes columns that define the date range validity of the version (for example, StartDate and EndDate) and possibly a flag column (for example, IsCurrent) to easily filter by current dimension members.

Adventure Works tildeler f.eks. sælgere til en salgsregion.For example, Adventure Works assigns salespeople to a sales region. Når en sælger skifter område, skal der oprettes en ny version af sælgeren for at sikre, at de historiske fakta forbliver knyttet til det tidligere område.When a salesperson relocates region, a new version of the salesperson must be created to ensure that historical facts remain associated with the former region. Der skal gemmes versioner af sælgere og deres tilknyttede områder i dimensionstabellen for at understøtte nøjagtig historisk analyse af salg efter sælger.To support accurate historic analysis of sales by salesperson, the dimension table must store versions of salespeople and their associated region(s). Tabellen skal også indeholde værdier for start- og slutdato for at definere gyldigheden af tid.The table should also include start and end date values to define the time validity. Der kan defineres en tom slutdato (eller 31-12-9999) for aktuelle versioner, hvilket angiver, at rækken er den aktuelle version.Current versions may define an empty end date (or 12/31/9999), which indicates that the row is the current version. Der skal også defineres en surrogatnøgle i tabellen, da forretningsnøglen (i denne forekomst er det medarbejder-id) ikke er entydig.The table must also define a surrogate key because the business key (in this instance, employee ID) won't be unique.

Det er vigtigt at forstå, at du skal bruge et mellemliggende system (f.eks. et data warehouse) for at registrere og gemme ændringer, når kildedataene ikke gemmer versioner.It's important to understand that when the source data doesn't store versions, you must use an intermediate system (like a data warehouse) to detect and store changes. Indlæsningsprocessen for tabellen skal bevare eksisterende data og registrere ændringer.The table load process must preserve existing data and detect changes. Når der registreres en ændring, skal den aktuelle version udløbe under indlæsningsprocessen for tabellen.When a change is detected, the table load process must expire the current version. Den registrerer ændringerne ved at opdatere værdien Slutdato og indsætte en ny version, hvor værdien Startdato starter fra den forrige Slutdato.It records these changes by updating the EndDate value and inserting a new version with the StartDate value commencing from the previous EndDate value. Relaterede fakta skal også bruge et tidsbaseret opslag for at hente den værdi for dimensionsnøglen, som er relevant for faktadatoen.Also, related facts must use a time-based lookup to retrieve the dimension key value relevant to the fact date. En Power BI-model, der bruger Power Query, kan ikke give dette resultat.A Power BI model using Power Query can't produce this result. Den kan dog indlæse data fra en forudindlæst Type 2-dimensionstabel, som er en dimension, der langsomt ændrer sig.It can, however, load data from a pre-loaded SCD Type 2 dimension table.

Power BI-modellen bør understøtte forespørgsler om historiske data for et medlem, uanset om de er ændret, og for en version af medlemmet, hvilket repræsenterer en bestemt tilstand for medlemmet over tid.The Power BI model should support querying historical data for a member, regardless of change, and for a version of the member, which represents a particular state of the member in time. I forbindelse med Adventure Works giver dette design dig mulighed for at sende en forespørgsel om sælgeren, uanset hvilket salgsområde der er tildelt, eller om en bestemt version af sælgeren.In the context of Adventure Works, this design enables you to query the salesperson regardless of assigned sales region, or for a particular version of the salesperson.

For at opnå dette krav skal dimensionstabellen i Power BI-modellen indeholde en kolonne til filtrering af sælgeren og en anden kolonne til filtrering af en bestemt version af sælgeren.To achieve this requirement, the Power BI model dimension-type table must include a column for filtering the salesperson, and a different column for filtering a specific version of the salesperson. Det er vigtigt, at kolonnen med versionen indeholder en entydig beskrivelse, f.eks. "Michael Blythe (15-12-2008-26-06-2019)" eller "Michael Blythe (aktuel)".It's important that the version column provides a non-ambiguous description, like "Michael Blythe (12/15/2008-06/26/2019)" or "Michael Blythe (current)". Det er også vigtigt at uddanne forfattere og forbrugere af rapporter i de grundlæggende funktioner i Type 2 af en dimension, der langsomt ændrer sig, og hvordan de opnår et passende rapportdesign ved at anvende korrekte filtre.It's also important to educate report authors and consumers about the basics of SCD Type 2, and how to achieve appropriate report designs by applying correct filters.

Det er også en god designpraksis at inkludere et hierarki, der giver mulighed for at zoome ind på versionsniveauer i visualiseringer.It's also a good design practice to include a hierarchy that allows visuals to drill down to the version level.

Eksempel på hierarki på feltliste

Output fra et eksempel på et hierarki

Dimension med forskellige rollerRole-playing dimensions

En dimension med forskellige roller, er en dimension, der kan filtrere relaterede fakta på en anden måde.A role-playing dimension is a dimension that can filter related facts differently. I Adventure Works har datodimensionstabellen f.eks. tre relationer med fakta for forhandlersalg.For example, at Adventure Works, the date dimension table has three relationships to the reseller sales facts. Den samme dimensionstabel kan bruges til at filtrere fakta efter ordredato, afsendelsesdato eller leveringsdato.The same dimension table can be used to filter the facts by order date, ship date, or delivery date.

I et data warehouse er den accepterede designtilgang at definere en enkelt datodimensionstabel.In a data warehouse, the accepted design approach is to define a single date dimension table. På forespørgselstidspunktet etableres "rollen" for datodimensionen efter, hvilken faktakolonne du bruger til at forene tabellerne.At query time, the "role" of the date dimension is established by which fact column you use to join the tables. Når du f.eks. analyserer salg efter ordredato, forenes der efter den relaterede kolonne med ordredato for forhandlersalg i tabellen.For example, when you analyze sales by order date, the table join relates to the reseller sales order date column.

I en Power BI-model kan dette design efterlignes ved at oprette flere relationer mellem to tabeller.In a Power BI model, this design can be imitated by creating multiple relationships between two tables. I eksemplet med Adventure Works ville der være tre relationer mellem salgstabellerne for dato og forhandler.In the Adventure Works example, the date and reseller sales tables would have three relationships. Dette design er muligt, men det er vigtigt at forstå, at der kun kan være én aktiv relation mellem to Power BI-modeltabeller.While this design is possible, it's important to understand that there can only be one active relationship between two Power BI model tables. Alle resterende relationer skal være angivet til inaktive.All remaining relationships must be set to inactive. Hvis du har en enkelt aktiv relation, betyder det, at der er en standardfilteroverførsel fra dato til forhandlersalg.Having a single active relationship means there is a default filter propagation from date to reseller sales. I denne forekomst angives den aktive relation til det mest almindelige filter, der bruges af rapporter, hvilket hos Adventure Works er relationen for ordredato.In this instance, the active relationship is set to the most common filter that is used by reports, which at Adventure Works is the order date relationship.

Eksempel på en enkelt dimension med forskellige roller og relationer

Den eneste måde, du kan bruge en inaktiv relation på, er ved at definere et DAX-udtryk, der bruger funktionen BRUGRELATION.The only way to use an inactive relationship is to define a DAX expression that uses the USERELATIONSHIP function. I vores eksempel skal modeludvikleren oprette målinger for at aktivere analyse af forhandlersalg efter afsendelsesdato og leveringsdato.In our example, the model developer must create measures to enable analysis of reseller sales by ship date and delivery date. Det kan være kedeligt arbejde, især når der defineres mange målinger i forhandlertabellen.This work can be tedious, especially when the reseller table defines many measures. Det skaber også rod i ruden Felter, hvor der en overflod af målinger.It also creates Fields pane clutter, with an overabundance of measures. Der er også andre begrænsninger:There are other limitations, too:

  • Når rapportforfatterne sætter deres lid til opsummering af kolonner i stedet for at definere målinger, kan de ikke opsummere de inaktive relationer uden at skrive en måling på rapportniveau.When report authors rely on summarizing columns, rather than defining measures, they can't achieve summarization for the inactive relationships without writing a report-level measure. Målinger på rapportniveau kan kun defineres, når der forfattes rapporter i Power BI Desktop.Report-level measures can only be defined when authoring reports in Power BI Desktop.
  • Med kun én aktiv relationssti mellem dato og forhandlersalg, er det ikke muligt at filtrere forhandlersalg efter forskellige typer af datoer samtidigt.With only one active relationship path between date and reseller sales, it's not possible to simultaneously filter reseller sales by different types of dates. Du kan f.eks. ikke oprette en visualisering, der afbilder salg efter ordredato ved hjælp af afsendt salg.For example, you can't produce a visual that plots order date sales by shipped sales.

Hvis du vil overvinde disse begrænsninger, er en almindelig udformningsteknik i Power BI at oprette en dimensionstabel for hver dimension med forskellige roller.To overcome these limitations, a common Power BI modeling technique is to create a dimension-type table for each role-playing instance. Du opretter typisk de ekstra dimensionstabeller som beregnede tabeller ved hjælp af DAX.You typically create the additional dimension tables as calculated tables, using DAX. Ved hjælp af beregnede tabeller kan modellen indeholde en tabel for Dato, en tabel for Afsendelsesdato og en tabel for Leveringsdato, der hver har en enkelt aktiv relation til deres respektive kolonner i tabeller med forhandlersalg.Using calculated tables, the model can contain a Date table, a Ship Date table and a Delivery Date table, each with a single and active relationship to their respective reseller sales table columns.

Eksempel på en dimension med forskellige roller og relationer

Denne designtilgang kræver ikke, at du definerer flere målinger for forskellige datoroller, og den tillader samtidig filtrering efter forskellige datoroller.This design approach doesn't require you to define multiple measures for different date roles, and it allows simultaneous filtering by different date roles. En mindre pris, der skal betales med denne designtilgang, er dog, at der vil være en gentagelse af datodimensionstabellen, hvilket resulterer i, at modellageret bliver større.A minor price to pay, however, with this design approach is that there will be duplication of the date dimension table resulting in an increased model storage size. Da der typisk gemmes færre rækker i dimensionstabeller i forhold til faktatabeller, er dette sjældent et problem.As dimension-type tables typically store fewer rows relative to fact-type tables, it is rarely a concern.

Se følgende gode designpraksis, når du opretter modeller med dimensionstabeller for hver rolle:Observe the following good design practices when you create model dimension-type tables for each role:

  • Sørg for, at kolonnenavnene beskriver sig selv.Ensure that the column names are self-describing. Selvom det er muligt at have en kolonne af typen År i alle datotabeller (kolonnenavne er entydige i deres tabel), beskriver den ikke sig selv ved hjælp af standardtitlerne i visualiseringen.While it's possible to have a Year column in all date tables (column names are unique within their table), it's not self-describing by default visual titles. Overvej at omdøbe kolonner i hver dimensionsrolletabel, så tabellen Afsendelsesdato indeholder en kolonne af typen År med navnet Afsendelsesår osv.Consider renaming columns in each dimension role table, so that the Ship Date table has a year column named Ship Year, etc.
  • Når det er relevant, skal du sørge for, at tabelbeskrivelser giver feedback til rapportforfatterne (via værktøjstip i ruden Felter) om, hvordan filteroverførsel er konfigureret.When relevant, ensure that table descriptions provide feedback to report authors (through Fields pane tooltips) about how filter propagation is configured. Denne klarhed er vigtig, når modellen indeholder en generisk navngiven tabel, f.eks. Dato, som bruges til at filtrere mange faktatabeller.This clarity is important when the model contains a generically named table, like Date, which is used to filter many fact-type tables. Hvis denne tabel f.eks. har en aktiv relation til kolonnen med ordredato for forhandlersalg, kan du overveje at angive en tabelbeskrivelse såsom "Filtrerer forhandlersalg efter ordredato".In the case that this table has, for example, an active relationship to the reseller sales order date column, consider providing a table description like "Filters reseller sales by order date".

Du kan finde flere oplysninger i Vejledning til aktive i forhold til inaktive relationer.For more information, see Active vs inactive relationship guidance.

Dimensioner til tilfældige attributterJunk dimensions

En dimension til tilfældige attributter er nyttig, når der er mange dimensioner, som især består af få attributter (måske én), og når disse attributter har få værdier.A junk dimension is useful when there are many dimensions, especially consisting of few attributes (perhaps one), and when these attributes have few values. Gode kandidater omfatter kolonner med ordrestatus eller kolonner med kundegrupper (køn, aldersgruppe osv.).Good candidates include order status columns, or customer demographic columns (gender, age group, etc.).

Designformålet med dimension til tilfældige attributter er at konsolidere mange "små" dimensioner i en enkelt dimension for at reducere størrelsen af modellageret og samtidig reducere rodet i ruden Felter ved at vise færre modeltabeller.The design objective of a junk dimension is to consolidate many "small" dimensions into a single dimension to both reduce the model storage size and also reduce Fields pane clutter by surfacing fewer model tables.

En tabel med en dimension til tilfældige attributter er typisk det kartesianske produkt for alle dimensionsattributmedlemmer med en kolonne for surrogatnøgle.A junk dimension table is typically the Cartesian product of all dimension attribute members, with a surrogate key column. Surrogatnøglen indeholder en entydig reference til hver række i tabellen.The surrogate key provides a unique reference to each row in the table. Du kan oprette dimensionen i et data warehouse eller ved at bruge Power Query til at oprette en forespørgsel, der udfører komplet ydre joinforbindelse for forespørgslen og derefter tilføjer en surrogatnøgle (indekskolonne).You can build the dimension in a data warehouse, or by using Power Query to create a query that performs full outer query joins, then adds a surrogate key (index column).

Eksempel på dimension til tilfældige attributter

Du indlæser denne forespørgsel i modellen som en dimensionstabel.You load this query to the model as a dimension-type table. Du skal også flette denne forespørgsel med faktaforespørgslen, så indekskolonnen indlæses i modellen for at understøtte oprettelsen af en relation med en "en til mange"-model.You also need to merge this query with the fact query, so the index column is loaded to the model to support the creation of a "one-to-many" model relationship.

Forringede dimensionerDegenerate dimensions

En forringet dimension refererer til en attribut i faktatabellen, der kræves til filtrering.A degenerate dimension refers to an attribute of the fact table that is required for filtering. Hos Adventure Works er forhandlerens salgsordrenummer et godt eksempel.At Adventure Works, the reseller sales order number is a good example. I dette tilfælde er det ikke et godt modeldesign at oprette en uafhængig tabel, der kun består af denne ene kolonne, da det ville øge modellagerets størrelse og resultere i rod i ruden Felter.In this case, it doesn't make good model design sense to create an independent table consisting of just this one column, because it would increase the model storage size and result in Fields pane clutter.

I Power BI-modellen kan det være hensigtsmæssigt at føje kolonnen med salgsordrenummeret til en faktatabel, så der kan filtreres eller grupperes efter salgsordrenummer.In the Power BI model, it can be appropriate to add the sales order number column to the fact-type table to allow filtering or grouping by sales order number. Dette er en undtagelse i forhold til den tidligere introducerede regel om, at du ikke må blande tabeltyper (generelt bør modeltabeller være enten dimensionstabeller eller faktatabeller).It is an exception to the formerly introduced rule that you should not mix table types (generally, model tables should be either dimension-type or fact-type).

Eksempel på forringet dimension

Hvis Adventure Works' tabel over forhandlersalg har kolonnerne ordrenummer og ordrelinjenummer, og de er påkrævet til filtrering, ville det dog være et godt design at oprette en dimensionstabel.However, if the Adventure Works resellers sales table has order number and order line number columns, and they're required for filtering, a degenerate dimension table would be a good design. Du kan finde flere oplysninger i Vejledning til en til en-relationer (Forringede dimensioner).For more information, see One-to-one relationship guidance (Degenerate dimensions).

Faktafrie faktatabellerFactless fact tables

En faktafri faktatabel indeholder ingen målingskolonner.A factless fact table doesn't include any measure columns. Den indeholder kun dimensionsnøgler.It contains only dimension keys.

Der kan gemmes observationer, defineret af dimensionsnøgler, i en faktafri faktatabel.A factless fact table could store observations defined by dimension keys. En bestemt kunde kan f.eks. være logget på dit websted på en bestemt dato og et bestemt klokkeslæt.For example, at a particular date and time, a particular customer logged into your web site. Du kan definere en måling for at tælle rækkerne i den faktafrie faktatabel for at analysere, hvornår og hvor mange kunder der er logget på.You could define a measure to count the rows of the factless fact table to perform analysis of when and how many customers have logged in.

En bedre måde at bruge faktatabeller på er ved at gemme relationer mellem dimensioner, og det er den designtilgang til Power BI-modeller, vi anbefaler, hvor du også definerer mange til mange-dimensionsrelationer.A more compelling use of a factless fact table is to store relationships between dimensions, and it's the Power BI model design approach we recommend defining many-to-many dimension relationships. I et design med mange til mange-dimensionsrelationer refereres der til den faktafrie faktatabel som en brotabel.In a many-to-many dimension relationship design, the factless fact table is referred to as a bridging table.

Du kan f.eks. overveje, at sælgere kan tildeles et eller flere salgsområder.For example, consider that salespeople can be assigned to one or more sales regions. Brotabellen er designet som en faktafri faktatabel, der består af to kolonner: sælgernøglen og områdenøglen.The bridging table would be designed as a factless fact table consisting of two columns: salesperson key and region key. Duplikerede værdier kan gemmes i begge kolonner.Duplicate values can be stored in both columns.

Eksempel på faktafri faktatabel

Denne mange til mange-designtilgang er veldokumenteret, og den kan opnås uden en brotabel.This many-to-many design approach is well documented, and it can be achieved without a bridging table. Tilgangen med brotabellen anses dog for at være bedste praksis, når der skal oprettes en relation mellem to dimensioner.However, the bridging table approach is considered the best practice when relating two dimensions. Du kan finde flere oplysninger i Vejledning til mange til mange-relationer (Relater to tabeller af dimensionstypen).For more information, see Many-to-many relationship guidance (Relate two dimension-type tables).

Næste trinNext steps

Du kan finde flere oplysninger om stjerneskemadesign eller design af en Power BI-model i følgende artikler:For more information about star schema design or Power BI model design, see the following articles: