Dimensionsmodellering i Microsoft Fabric Warehouse: Dimensionstabeller

Gäller för: SQL-analysslutpunkt och lager i Microsoft Fabric

Kommentar

Den här artikeln är en del av serien Dimensionsmodellering av artiklar. Den här serien fokuserar på vägledning och metodtips för design som rör dimensionsmodellering i Microsoft Fabric Warehouse.

Den här artikeln innehåller vägledning och metodtips för att utforma dimensionstabeller i en dimensionsmodell. Det ger praktisk vägledning för Warehouse i Microsoft Fabric, vilket är en upplevelse som stöder många T-SQL-funktioner, till exempel att skapa tabeller och hantera data i tabeller. Därför har du fullständig kontroll över att skapa dina dimensionsmodelltabeller och läsa in dem med data.

Kommentar

I den här artikeln refererar termen informationslager till ett informationslager för företag, som ger omfattande integrering av kritiska data i hela organisationen. Det fristående termlagret refererar däremot till ett infrastrukturlager, som är en saaS-relationsdatabas (programvara som en tjänst) som du kan använda för att implementera ett informationslager. För tydlighetens skull nämns den senare i den här artikeln som Infrastrukturlager.

Dricks

Om du är oerfaren med dimensionsmodellering bör du överväga den här artikelserien som ditt första steg. Det är inte avsett att ge en fullständig diskussion om dimensionsmodelleringsdesign. 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.

I en dimensionsmodell beskriver en dimensionstabell en entitet som är relevant för dina affärs- och analyskrav. Dimensionstabeller representerar i stort sett de saker som du modellerar. Saker kan vara produkter, personer, platser eller något annat koncept, inklusive datum och tid. För att enkelt identifiera dimensionstabeller prefixar du vanligtvis deras namn med d_ eller Dim_.

Dimensionstabellstruktur

Om du vill beskriva strukturen för en dimensionstabell bör du överväga följande exempel på en dimensionstabell för säljare med namnet d_Salesperson. Det här exemplet tillämpar bra designmetoder. Var och en av grupperna med kolumner beskrivs i följande avsnitt.

CREATE TABLE d_Salesperson
(
    --Surrogate key
    Salesperson_SK INT NOT NULL,
    
    --Natural key(s)
    EmployeeID VARCHAR(20) NOT NULL,
    
    --Dimension attributes
    FirstName VARCHAR(20) NOT NULL,
    <…>
    
    --Foreign key(s) to other dimensions
    SalesRegion_FK INT NOT NULL,
    <…>
    
    --Historical tracking attributes (SCD type 2)
    RecChangeDate_FK INT NOT NULL,
    RecValidFromKey INT NOT NULL,
    RecValidToKey INT NOT NULL,
    RecReason VARCHAR(15) NOT NULL,
    RecIsCurrent BIT NOT NULL,
    
    --Audit attributes
    AuditMissing BIT NOT NULL,
    AuditIsInferred BIT NOT NULL,
    AuditCreatedDate DATE NOT NULL,
    AuditCreatedBy VARCHAR(15) NOT NULL,
    AuditLastModifiedDate DATE NOT NULL,
    AuditLastModifiedBy VARCHAR(15) NOT NULL
);

Surrogatnyckel

Exempeldimensionstabellen har en surrogatnyckel med namnet Salesperson_SK. En surrogatnyckel är en unik identifierare med en kolumn som genereras och lagras i dimensionstabellen. Det är en primärnyckelkolumn som används för att relatera till andra tabeller i dimensionsmodellen.

Surrogatnycklar strävar efter att isolera informationslagret från ändringar i källdata. De ger också många andra fördelar, så att du kan:

• Konsolidera flera datakällor (undvika konflikt mellan dubblettidentifierare).
• Konsolidera naturliga nycklar med flera kolumner till en effektivare nyckel med en kolumn.
• Spåra dimensionshistorik med en långsamt föränderlig dimension (SCD) typ 2.
• Begränsa faktatabellens bredd för lagringsoptimering (genom att välja den minsta möjliga heltalsdatatypen).

En surrogatnyckelkolumn är en rekommenderad metod, även när en naturlig nyckel (beskrivs härnäst) verkar vara en acceptabel kandidat. Du bör också undvika att ge betydelse till nyckelvärdena (förutom datum- och tidsdimensionsnycklar, enligt beskrivningen senare).

Naturliga nycklar

Exempeldimensionstabellen har också en naturlig nyckel med namnet EmployeeID. En naturlig nyckel är nyckeln som lagras i källsystemet. Det gör det möjligt att relatera dimensionsdata till dess källsystem, vilket vanligtvis görs av en ETL-process (Extract, Load, and Transform) för att läsa in dimensionstabellen. Ibland kallas en naturlig nyckel för en affärsnyckel och dess värden kan vara meningsfulla för företagsanvändare.

Ibland har dimensioner inte en naturlig nyckel. Det kan vara fallet för datumdimensionen eller uppslagsdimensionerna, eller när du genererar dimensionsdata genom att normalisera en platt fil.

Dimensionsattribut

En exempeldimensionstabell har även dimensionsattribut, till exempel FirstName kolumnen. Dimensionsattribut ger kontext till numeriska data som lagras i relaterade faktatabeller. De är vanligtvis textkolumner som används i analysfrågor för att filtrera och gruppera (segment och tärningar), men som inte ska aggregeras själva. Vissa dimensionstabeller innehåller få attribut, medan andra innehåller många attribut (så många som krävs för att stödja frågekraven för dimensionsmodellen).

Dricks

Ett bra sätt att avgöra vilka dimensioner och attribut du behöver är att hitta rätt personer och ställa rätt frågor. Mer specifikt, håll dig uppmärksam för omnämnandet av ordet av. När någon till exempel säger att de behöver analysera försäljning per säljare, per månad och efter produktkategori, säger de att de behöver dimensioner som har dessa attribut.

Om du planerar att skapa en Direct Lake-semantisk modell bör du inkludera alla möjliga kolumner som krävs för filtrering och gruppering som dimensionsattribut. Det beror på att Direct Lake-semantiska modeller inte stöder beräknade kolumner.

Sekundärnycklar

Exempeldimensionstabellen har också en sekundärnyckel med namnet SalesRegion_FK. Andra dimensionstabeller kan referera till en sekundärnyckel och deras närvaro i en dimensionstabell är ett specialfall. Den anger att tabellen är relaterad till en annan dimensionstabell, vilket innebär att den kan ingå i en snowflake-dimension eller är relaterad till en utriggardimension.

Infrastrukturlager stöder begränsningar för sekundärnyckel, men de kan inte tillämpas. Därför är det viktigt att ETL-processen testar integriteten mellan relaterade tabeller när data läses in.

Det är fortfarande en bra idé att skapa sekundärnycklar. En bra anledning till att skapa oforcerade sekundärnycklar är att tillåta modelleringsverktyg, till exempel Power BI Desktop, att automatiskt identifiera och skapa relationer mellan tabeller i den semantiska modellen.

Historiska spårningsattribut

Exempeldimensionstabellen har också olika historiska spårningsattribut. Historiska spårningsattribut är valfria baserat på ditt behov av att spåra specifika ändringar när de sker i källsystemet. De gör det möjligt att lagra värden för att stödja den primära rollen för ett informationslager, vilket är att beskriva det förflutna korrekt. Mer specifikt lagrar dessa attribut historiska kontexter när ETL-processen läser in nya eller ändrade data i dimensionen.

Mer information finns i Hantera historiska ändringar senare i den här artikeln.

Granska attribut

Exempeldimensionstabellen har också olika granskningsattribut. Granskningsattribut är valfria men rekommenderas. De gör att du kan spåra när och hur dimensionsposter skapades eller ändrades, och de kan innehålla diagnostik- eller felsökningsinformation som genereras under ETL-processer. Du vill till exempel spåra vem (eller vilken process) som har uppdaterat en rad och när. Granskningsattribut kan också hjälpa dig att diagnostisera ett utmanande problem, till exempel när en ETL-process oväntat stoppas. De kan också flagga dimensionsmedlemmar som fel eller härledda medlemmar.

Storlek på dimensionstabell

Ofta är de mest användbara och mångsidiga dimensionerna i en dimensionsmodell stora, breda dimensioner. De är stora när det gäller rader (över miljoner) och breda när det gäller antalet dimensionsattribut (potentiellt hundratals). Storleken är inte så viktig (även om du bör utforma och optimera för minsta möjliga storlek). Det viktiga är att dimensionen stöder nödvändig filtrering, gruppering och korrekt historisk analys av faktadata.

Stora dimensioner kan komma från flera källsystem. I det här fallet måste dimensionsbearbetningen kombinera, sammanfoga, deduplicera och standardisera data. och tilldela surrogatnycklar.

Som jämförelse är vissa dimensioner små. De kan representera uppslagstabeller som bara innehåller flera poster och attribut. Ofta lagrar dessa små dimensions kategorivärden relaterade till transaktioner i faktatabeller, och de implementeras som dimensioner med surrogatnycklar för att relatera till faktaposterna.

Dricks

När du har många små dimensioner bör du överväga att konsolidera dem till en skräpdimension.

Designbegrepp för dimension

I det här avsnittet beskrivs olika dimensionsdesignbegrepp.

Avormalisering jämfört med normalisering

Det är nästan alltid så att dimensionstabeller ska avnormaliseras. Normalisering är den term som används för att beskriva data som lagras på ett sätt som minskar repetitious-data, men avnormalisering är den term som används för att definiera var förberäknade redundanta data finns. Redundanta data finns vanligtvis på grund av lagringen av hierarkier (beskrivs senare), vilket innebär att hierarkier plattas ut. En produktdimension kan till exempel lagra underkategorier (och dess relaterade attribut) och kategori (och dess relaterade attribut).

Eftersom dimensionerna vanligtvis är små (jämfört med faktatabeller) uppvägs kostnaden för att lagra redundanta data nästan alltid av den förbättrade frågeprestandan och användbarheten.

Snowflake-dimensioner

Ett undantag för avnormalisering är att utforma en snowflake-dimension. En snowflake-dimension normaliseras och lagrar dimensionsdata i flera relaterade tabeller.

Följande diagram visar en snowflake-dimension som består av tre relaterade dimensionstabeller: Product, Subcategoryoch Category.

Överväg att implementera en snowflake-dimension när:

• Dimensionen är extremt stor och lagringskostnaderna överväger behovet av höga frågeprestanda. (Med jämna mellanrum omvärderas dock att detta fortfarande är fallet.)
• Du behöver nycklar för att relatera dimensionen till fakta med högre kornighet. Tabellen försäljningsfakta lagrar till exempel rader på produktnivå, men faktatabellen för försäljningsmål lagrar rader på underkategorinivå.
• Du måste spåra historiska ändringar på högre detaljnivå.

Kommentar

Tänk på att en hierarki i en Power BI-semantisk modell bara kan baseras på kolumner från en enda semantisk modelltabell. Därför bör en snowflake-dimension leverera ett avnormaliserat resultat med hjälp av en vy som kopplar samman snowflake-tabellerna.

Hierarkier

Vanligtvis skapar dimensionskolumner hierarkier. Med hierarkier kan du utforska data på distinkta sammanfattningsnivåer. Den första vyn för ett visuellt matrisobjekt kan till exempel visa årlig försäljning och rapportkonsumenten kan välja att öka detaljnivån för att visa kvartals- och månadsförsäljning.

Det finns tre sätt att lagra en hierarki i en dimension. Du kan använda:

• Kolumner från en enda, avnormaliserad dimension.
• En snowflake-dimension som består av flera relaterade tabeller.
• En överordnad-underordnad relation (självrefererande) i en dimension.

Hierarkier kan balanseras eller obalanseras. Det är också viktigt att förstå att vissa hierarkier är ojämna.

Balanserade hierarkier

Balanserade hierarkier är den vanligaste typen av hierarki. En balanserad hierarki har samma antal nivåer. Ett vanligt exempel på en balanserad hierarki är en kalenderhierarki i en datumdimension som omfattar nivåer för år, kvartal, månad och datum.

Följande diagram visar en balanserad hierarki med försäljningsregioner. Den består av två nivåer, som är försäljningsregiongrupp och försäljningsregion.

Nivåerna i en balanserad hierarki baseras antingen på kolumner från en enda, avnormaliserad dimension eller från tabeller som utgör en snowflake-dimension. När de baseras på en enda, avnormaliserad dimension innehåller kolumnerna som representerar de högre nivåerna redundanta data.

För balanserade hierarkier relaterar fakta alltid till en enda nivå i hierarkin, som vanligtvis är den lägsta nivån. På så sätt kan fakta aggregeras (summeras) till den högsta nivån i hierarkin. Fakta kan relatera till vilken nivå som helst, vilket bestäms av faktatabellens kornighet. Tabellen för försäljningsfakta kan till exempel lagras på datumnivå, medan faktatabellen för försäljningsmål kan lagras på kvartalsnivå.

Obalanserade hierarkier

Obalanserade hierarkier är en mindre vanlig typ av hierarki. En obalanserad hierarki har nivåer baserade på en överordnad-underordnad relation. Därför bestäms antalet nivåer i en obalanserad hierarki av dimensionsraderna och inte specifika dimensionstabellkolumner.

Ett vanligt exempel på en obalanserad hierarki är en medarbetarhierarki där varje rad i en medarbetardimension relaterar till en reporting manager-rad i samma tabell. I det här fallet kan alla anställda vara en chef med rapporterande anställda. Naturligtvis kommer vissa grenar i hierarkin att ha fler nivåer än andra.

Följande diagram visar en obalanserad hierarki. Den består av fyra nivåer och varje medlem i hierarkin är säljare. Observera att säljare har ett annat antal överordnade i hierarkin beroende på vem de rapporterar till.

Andra vanliga exempel på obalanserade hierarkier är materialräkning, företagsägarmodeller och redovisning.

För obalanserade hierarkier är fakta alltid relaterade till dimensionskornet. Försäljningsfakta relaterar till exempel till olika säljare som har olika rapporteringsstrukturer. Dimensionstabellen skulle ha en surrogatnyckel (med namnet Salesperson_SK) och en ReportsTo_Salesperson_FK sekundärnyckelkolumn som refererar till primärnyckelkolumnen. Varje säljare utan någon att hantera är inte nödvändigtvis på den lägsta nivån i någon gren av hierarkin. När de inte är på den lägsta nivån kan en säljare sälja produkter och rapportera säljare som också säljer produkter. Därför måste sammanslagningen av faktadata ta hänsyn till den enskilda säljaren och alla deras underordnade.

Att köra frågor mot överordnade och underordnade hierarkier kan vara komplext och långsamt, särskilt för stora dimensioner. Källsystemet kan lagra relationer som överordnad-underordnad, men vi rekommenderar att du naturaliserar hierarkin. I det här fallet innebär naturalize att transformera och lagra hierarkinivåerna i dimensionen som kolumner.

Dricks

Om du väljer att inte naturalisera hierarkin kan du fortfarande skapa en hierarki baserat på en överordnad-underordnad relation i en Power BI-semantisk modell. Den här metoden rekommenderas dock inte för stora dimensioner. Mer information finns i Förstå funktioner för överordnade-underordnade hierarkier i DAX.

Ojämna hierarkier

Ibland är en hierarki ojämn eftersom den överordnade för en medlem i hierarkin finns på en nivå som inte är omedelbart ovanför den. I dessa fall upprepar saknade nivåvärden värdet för den överordnade nivån.

Överväg ett exempel på en balanserad geografihierarki. Det finns en ojämn hierarki när ett land/en region inte har några delstater eller provinser. Nya Zeeland har till exempel varken stater eller provinser. När du infogar raden Nya Zeeland bör du därför även lagra värdet för land/region i StateProvince kolumnen.

Följande diagram visar en ojämn hierarki med geografiska regioner.

Hantera historisk ändring

Vid behov kan historiska ändringar hanteras genom att implementera en långsamt föränderlig dimension (SCD). En SCD upprätthåller historisk kontext när nya eller ändrade data läses in i den.

Här är de vanligaste SCD-typerna.

• Typ 1: Skriv över den befintliga dimensionsmedlemmen.
• Typ 2: Infoga en ny tidsbaserad version av dimensionsmedlemmen.
• Typ 3: Spåra begränsad historik med attribut.

Det är möjligt att en dimension kan ha stöd för både SCD-typ 1- och SCD-typ 2-ändringar.

SCD typ 3 används inte ofta, delvis på grund av att det är svårt att använda i en semantisk modell. Överväg noggrant om en SCD typ 2-metod skulle passa bättre.

Dricks

Om du förväntar dig en snabbt föränderlig dimension, vilket är en dimension som har ett attribut som ändras ofta, bör du överväga att lägga till attributet i faktatabellen i stället. Om attributet är numeriskt, till exempel produktpriset, kan du lägga till det som ett mått i faktatabellen. Om attributet är ett textvärde kan du skapa en dimension baserat på alla textvärden och lägga till dess dimensionsnyckel i faktatabellen.

SCD-typ 1

SCD-typ 1-ändringar skriver över den befintliga dimensionsraden eftersom det inte finns något behov av att hålla reda på ändringar. Den här SCD-typen kan också användas för att korrigera fel. Det är en vanlig typ av SCD och bör användas för de flesta föränderliga attribut, till exempel kundnamn, e-postadress och andra.

Följande diagram visar tillståndet före och efter för en säljares dimensionsmedlem där deras telefonnummer har ändrats.

Den här SCD-typen bevarar inte historiska perspektiv eftersom den befintliga raden uppdateras. Det innebär att SCD typ 1-ändringar kan resultera i olika aggregeringar på högre nivå. Om en säljare till exempel tilldelas till en annan försäljningsregion skulle en SCD-typ 1-ändring skriva över dimensionsraden. Sammanslagningen av säljares historiska försäljningsresultat till regionen skulle sedan ge ett annat resultat eftersom den nu använder den nya aktuella försäljningsregionen. Det är som om säljaren alltid har tilldelats till den nya försäljningsregionen.

SCD-typ 2

SCD-typ 2-ändringar resulterar i nya rader som representerar en tidsbaserad version av en dimensionsmedlem. Det finns alltid en aktuell versionsrad och den återspeglar tillståndet för dimensionsmedlemmen i källsystemet. Historiska spårningsattribut i dimensionstabellens lagringsvärden som gör det möjligt att identifiera den aktuella versionen (aktuell flagga är TRUE) och dess giltighetsperiod. En surrogatnyckel krävs eftersom det kommer att finnas dubbletter av naturliga nycklar när flera versioner lagras.

Det är en vanlig typ av SCD, men den bör reserveras för attribut som måste bevara historiska perspektiv.

Om en säljare till exempel tilldelas till en annan försäljningsregion innebär en SCD-typ 2-ändring en uppdateringsåtgärd och en infogningsåtgärd.

1. Uppdateringsåtgärden skriver över den aktuella versionen för att ange de historiska spårningsattributen. Mer specifikt är kolumnen för slut giltighet inställd på ETL-bearbetningsdatumet (eller en lämplig tidsstämpel i källsystemet) och den aktuella flaggan är inställd på FALSE.
2. Infogningsåtgärden lägger till en ny, aktuell version som anger kolumnen start giltighet till kolumnvärdet för slut giltighet (används för att uppdatera den tidigare versionen) och den aktuella flaggan till TRUE.

Det är viktigt att förstå att kornigheten för relaterade faktatabeller inte är på säljpersonsnivå, utan snarare på versionsnivån för säljare. Sammanslagningen av deras historiska försäljningsresultat till regionen ger korrekta resultat, men det kommer att finnas två (eller fler) medlemsversioner för säljare att analysera.

Följande diagram visar tillståndet före och efter för en säljares dimensionsmedlem där deras försäljningsregion har ändrats. Eftersom organisationen vill analysera säljarnas arbete efter den region de är tilldelade till utlöser den en SCD-typ 2-ändring.

Dricks

När en dimensionstabell stöder SCD-typ 2-ändringar bör du inkludera ett etikettattribut som beskriver medlemmen och versionen. Tänk dig ett exempel när säljaren Lynn Tsoflias från Adventure Works ändrar tilldelningen från den australiska försäljningsregionen till försäljningsregionen Storbritannien. Etikettattributet för den första versionen kan läsa "Lynn Tsoflias (Australien)" och etikettattributet för den nya, aktuella versionen kan läsa "Lynn Tsoflias (Storbritannien)." Om det är användbart kan du även inkludera giltighetsdatumen i etiketten.

Du bör balansera behovet av historisk noggrannhet jämfört med användbarhet och effektivitet. Försök att undvika för många SCD typ 2-ändringar i en dimensionstabell eftersom det kan resultera i ett överväldigande antal versioner som kan göra det svårt för analytiker att förstå.

För många versioner kan också tyda på att ett föränderligt attribut kan lagras bättre i faktatabellen. Om du utökar det tidigare exemplet, om försäljningsregionen ändras ofta, kan försäljningsregionen lagras som en dimensionsnyckel i faktatabellen i stället för att implementera en SCD-typ 2.

Överväg följande historiska spårningsattribut av SCD-typ 2.

CREATE TABLE d_Salesperson
(
    <…>

    --Historical tracking attributes (SCD type 2)
    RecChangeDate_FK INT NOT NULL,
    RecValidFromKey INT NOT NULL,
    RecValidToKey INT NOT NULL,
    RecReason VARCHAR(15) NOT NULL,
    RecIsCurrent BIT NOT NULL,

    <…>
);

Här är syftet med de historiska spårningsattributen.

• Kolumnen RecChangeDate_FK lagrar datumet då ändringen trädde i kraft. Det gör att du kan fråga när ändringar har gjorts.
• Kolumnerna RecValidFromKey och RecValidToKey lagrar giltighetsdatumen för raden. Överväg att lagra det tidigaste datumet som finns i datumdimensionen för att RecValidFromKey representera den ursprungliga versionen och lagra 01/01/9999 för de RecValidToKey aktuella versionerna.
• Kolumnen RecReason är valfri. Det gör det möjligt att dokumentera orsaken till att versionen infogades. Det kan koda vilka attribut som har ändrats, eller så kan det vara en kod från källsystemet som anger en viss affärsorsak.
• Kolumnen RecIsCurrent gör det möjligt att endast hämta aktuella versioner. Den används när ETL-processen letar upp dimensionsnycklar vid inläsning av faktatabeller.

Kommentar

Vissa källsystem lagrar inte historiska ändringar, så det är viktigt att dimensionen bearbetas regelbundet för att identifiera ändringar och implementera nya versioner. På så sätt kan du identifiera ändringar kort efter att de har inträffat, och deras giltighetsdatum kommer att vara korrekta.

SCD-typ 3

SCD-typ 3 ändrar spåra begränsad historik med attribut. Den här metoden kan vara användbar när det finns ett behov av att registrera den senaste ändringen eller ett antal av de senaste ändringarna.

Den här SCD-typen bevarar ett begränsat historiskt perspektiv. Det kan vara användbart när endast de initiala och aktuella värdena ska lagras. I det här fallet krävs inte interimsändringar.

Om en säljare till exempel tilldelas till en annan försäljningsregion skriver en SCD-ändring av typ 3 över dimensionsraden. En kolumn som specifikt lagrar den tidigare försäljningsregionen anges som den tidigare försäljningsregionen och den nya försäljningsregionen anges som den aktuella försäljningsregionen.

Följande diagram visar tillståndet före och efter för en säljares dimensionsmedlem där deras försäljningsregion har ändrats. Eftersom organisationen vill fastställa en tidigare tilldelning av försäljningsregion utlöser den en SCD-typ 3-ändring.

Specialdimensionsmedlemmar

Du kan infoga rader i en dimension som representerar saknade, okända, N/A eller feltillstånd. Du kan till exempel använda följande surrogatnyckelvärden.

Nyckelvärde	Syfte
0	Saknas (inte tillgängligt i källsystemet)
-1	Okänd (uppslagsfel under en faktatabellinläsning)
-2	Ej tillämpligt
-3	Fel

Kalender och tid

Nästan utan undantag lagrar faktatabeller mått vid specifika tidpunkter. För att stödja analys efter datum (och eventuellt tid) måste det finnas kalenderdimensioner (datum och tid).

Det är ovanligt att ett källsystem skulle ha kalenderdimensionsdata, så det måste genereras i informationslagret. Vanligtvis genereras den en gång, och om det är en kalenderdimension utökas den med framtida datum när det behövs.

Datumdimension

Dimensionen datum (eller kalender) är den vanligaste dimensionen som används för analys. Den lagrar en rad per datum och stöder det vanliga kravet på att filtrera eller gruppera efter specifika datumperioder, till exempel år, kvartal eller månader.

Viktigt!

En datumdimension får inte innehålla ett korn som sträcker sig till tid på dagen. Om tidsanalys krävs bör du ha både en datumdimension och en tidsdimension (beskrivs härnäst). Faktatabeller som lagrar tid på dagen-fakta bör ha två sekundärnycklar, en till var och en av dessa dimensioner.

Den naturliga nyckeln för datumdimensionen bör använda datumdatatypen . Surrogatnyckeln ska lagra datumet med hjälp YYYYMMDD av format och int-datatypen . Den här godkända metoden bör vara det enda undantaget (tillsammans med tidsdimensionen) när surrogatnyckelvärdet har betydelse och är läsbar för människor. Lagring YYYYMMDD som int-datatyp är inte bara effektivt och sorterat numeriskt, utan överensstämmer också med iso-datumformatet (UNambiguous International Standards Organization) 8601.

Här följer några vanliga attribut som ska inkluderas i en datumdimension.

• Year, Quarter, , MonthDay
• QuarterNumberInYear, MonthNumberInYear – som kan krävas för att sortera textetiketter.
• FiscalYear, FiscalQuarter – vissa företagsredovisningsscheman börjar mitt i året, så att start/slutet av kalenderåret och räkenskapsåret skiljer sig åt.
• FiscalQuarterNumberInYear, FiscalMonthNumberInYear – som kan krävas för att sortera textetiketter.
• WeekOfYear – Det finns flera sätt att märka veckan på året, inklusive en ISO-standard som har antingen 52 eller 53 veckor.
• IsHoliday, HolidayText – om din organisation verkar i flera geografiska områden bör du underhålla flera uppsättningar med semesterlistor som varje geografi ser som en separat dimension eller naturaliserad i flera attribut i datumdimensionen. Att lägga till ett HolidayText attribut kan hjälpa dig att identifiera helgdagar för rapportering.
• IsWeekday – På samma sätt är standardarbetsveckan inte måndag till fredag i vissa geografiska områden. Arbetsveckan är till exempel söndag till torsdag i många regioner i Mellanöstern, medan andra regioner har en arbetsvecka på fyra dagar eller sex dagar.
• LastDayOfMonth
• RelativeYearOffset, RelativeQuarterOffset, RelativeMonthOffset, RelativeDayOffset – som kan krävas för att stödja relativ datumfiltrering (till exempel föregående månad). Aktuella perioder använder en förskjutning på noll (0); tidigare perioder lagrar förskjutningar på -1, -2, -3...; framtida perioder lagrar förskjutningar på 1, 2, 3....

Precis som med alla dimensioner är det viktigt att den innehåller attribut som stöder kända krav för filtrering, gruppering och hierarki. Det kan också finnas attribut som lagrar översättningar av etiketter till andra språk.

När dimensionen används för att relatera till fakta med högre kornighet kan faktatabellen använda datumperiodens första datum. Till exempel skulle en faktatabell för försäljningsmål som lagrar kvartalsförsäljningsmål lagra det första datumet i kvartalet i datumdimensionen. En annan metod är att skapa nyckelkolumner i datumtabellen. En kvartalsnyckel kan till exempel lagra kvartalsnyckeln med hjälp YYYYQ av format och den lilla datatypen.

Dimensionen bör fyllas i med det kända datumintervallet som används av alla faktatabeller. Det bör också innehålla framtida datum när informationslagret lagrar fakta om mål, budgetar eller prognoser. Precis som med andra dimensioner kan du inkludera rader som representerar saknade, okända, N/A eller felsituationer.

Dricks

Sök på Internet efter "datumdimensionsgenerator" för att hitta skript och kalkylblad som genererar datumdata.

I början av nästa år bör ETL-processen vanligtvis utöka datumdimensionsraderna till ett visst antal år framåt. När dimensionen innehåller relativa offsetattribut måste ETL-processen köras dagligen för att uppdatera förskjutningsattributvärden baserat på aktuellt datum (idag).

Tidsdimension

Ibland måste fakta lagras vid en tidpunkt (som i tid på dagen). I det här fallet skapar du en tidsdimension (eller klocka). Det kan ha ett korn av minuter (24 x 60 = 1 440 rader) eller till och med sekunder (24 x 60 x 60 = 86 400 rader). Andra möjliga korn inkluderar halvtimme eller timme.

Den naturliga nyckeln för en tidsdimension bör använda tidsdatatypen. Surrogatnyckeln kan använda ett lämpligt format och lagra värden som har betydelse och är läsbara för människor, till exempel med hjälp HHMM av formatet eller HHMMSS .

Här följer några vanliga attribut som ska ingå i en tidsdimension.

• Hour, HalfHour, , QuarterHourMinute
• Tidsetiketter (morgon, eftermiddag, kväll, natt)
• Arbetsskiftsnamn
• Flaggor med hög eller låg topp

Anpassade dimensioner

Vissa dimensioner kan vara anpassade dimensioner. Anpassade dimensioner relaterar till många faktatabeller och delas därför av flera stjärnor i en dimensionsmodell. De ger konsekvens och kan hjälpa dig att minska pågående utveckling och underhåll.

Det är till exempel typiskt att faktatabeller lagrar minst en datumdimensionsnyckel (eftersom aktiviteten nästan alltid registreras efter datum och/eller tid). Därför är en datumdimension en gemensam anpassad dimension. Du bör därför se till att datumdimensionen innehåller attribut som är relevanta för analysen av alla faktatabeller.

Följande diagram visar faktatabellen Sales och faktatabellen Inventory . Varje faktatabell relaterar till dimensionen Date och Product dimensionen, som är anpassade dimensioner.

Som ett annat exempel kan din medarbetare och användare vara samma uppsättning personer. I det här fallet kan det vara klokt att kombinera attributen för varje entitet för att skapa en anpassad dimension.

Dimensioner med olika roller

När en dimension refereras flera gånger i en faktatabell kallas den för en rollspelsdimension.

Om en faktatabell för försäljning till exempel har dimensionsnycklar för orderdatum, leveransdatum och leveransdatum relaterar datumdimensionen på tre sätt. Varje sätt representerar en distinkt roll, men det finns bara en fysisk datumdimension.

I följande diagram visas en Flight faktatabell. Dimensionen Airport är en rollspelsdimension eftersom den är två gånger relaterad till faktatabellen Departure Airport som dimension och Arrival Airport dimension.

Skräpdimensioner

En skräpdimension är användbar när det finns många oberoende dimensioner, särskilt när de består av några attribut (kanske en), och när dessa attribut har låg kardinalitet (få värden). Målet med en skräpdimension är att konsolidera många små dimensioner till en enda dimension. Den här designmetoden kan minska antalet dimensioner och minska antalet faktatabellnycklar och därmed faktatabelllagringsstorleken. De bidrar också till att minska datafönstrets oreda eftersom de presenterar färre tabeller för användare.

En skräpdimensionstabell lagrar vanligtvis kartesisk produkt av alla dimensionsattributvärden med ett surrogatnyckelattribut.

Bra kandidater inkluderar flaggor och indikatorer, orderstatus och kunddemografitillstånd (kön, åldersgrupp och andra).

Följande diagram visar en skräpdimension med namnet Sales Status som kombinerar orderstatusvärden och leveransstatusvärden.

Degenerera dimensioner

En degenerera dimension kan inträffa när dimensionen är i samma kornighet som de relaterade fakta. Ett vanligt exempel på en degenererad dimension är en försäljningsordernummerdimension som relaterar till en försäljningsfaktatabell. Vanligtvis är fakturanumret ett enda, icke-hierarkiskt attribut i faktatabellen. Därför är det en godkänd metod att inte kopiera dessa data för att skapa en separat dimensionstabell.

Följande diagram visar en Sales Order dimension som är en degenererad dimension baserat på SalesOrderNumber kolumnen i en försäljningsfaktatabell. Den här dimensionen implementeras som en vy som hämtar de distinkta försäljningsordernummervärdena.

Dricks

Det går att skapa en vy i ett infrastrukturlager som presenterar den degenererade dimensionen som en dimension i frågesyfte.

Ur ett semantiskt power BI-modelleringsperspektiv kan en degenererad dimension skapas som en separat tabell med hjälp av Power Query. På så sätt överensstämmer den semantiska modellen med bästa praxis att fält som används för att filtrera eller gruppera hämtas från dimensionstabeller, och fält som används för att sammanfatta fakta kommer från faktatabeller.

Utriggardimensioner

När en dimensionstabell relaterar till andra dimensionstabeller kallas den för en utriggardimension. En utriggardimension kan hjälpa till att anpassa och återanvända definitioner i dimensionsmodellen.

Du kan till exempel skapa en geografidimension som lagrar geografiska platser för varje postnummer. Den dimensionen kan sedan refereras till av kunddimensionen och säljdimensionen, som lagrar surrogatnyckeln för geografidimensionen. På så sätt kan kunder och säljare sedan analyseras med hjälp av konsekventa geografiska platser.

Följande diagram visar en Geography dimension som är en utriggardimension. Den relaterar inte direkt till faktatabellen Sales . I stället är den indirekt relaterad via dimensionen Customer och dimensionen Salesperson .

Tänk på att datumdimensionen kan användas som en utriggardimension när andra dimensionstabellattribut lagrar datum. Till exempel kan födelsedatumet i en kunddimension lagras med hjälp av surrogatnyckeln för datumdimensionstabellen.

Flervärdesdimensioner

När ett dimensionsattribut måste lagra flera värden måste du utforma en flervärdesdimension. Du implementerar en flervärdesdimension genom att skapa en bryggtabell (kallas ibland en kopplingstabell). En bryggtabell lagrar en många-till-många-relation mellan entiteter.

Anta till exempel att det finns en säljdimension och att varje säljare tilldelas till en eller möjligen fler försäljningsregioner. I det här fallet är det klokt att skapa en försäljningsregiondimension. Den dimensionen lagrar endast varje försäljningsregion en gång. En separat tabell, som kallas bryggtabellen, lagrar en rad för varje säljare och försäljningsregionrelation. Fysiskt finns det en en-till-många-relation från säljdimensionen till bridge-tabellen och en annan en-till-många-relation från försäljningsregiondimensionen till bryggtabellen. Logiskt sett finns det en många-till-många-relation mellan säljare och försäljningsregioner.

I följande diagram relaterar dimensionstabellen Account till faktatabellen Transaction . Eftersom kunder kan ha flera konton och konton kan ha flera kunder är dimensionstabellen Customer relaterad via bryggtabellen Customer Account .

Relaterat innehåll

I nästa artikel i den här serien får du lära dig mer om vägledning och metodtips för faktatabeller.