Datatyper i Power BI

Denne artikkelen beskriver datatyper som Power BI og Data Analysis Expressions (DAX) støtter.

Når Power BI laster inn data, prøver det å konvertere datatypene i kildekolonnene til datatyper som støtter mer effektiv lagring, beregninger og datavisning. For eksempel, hvis en kolonne med verdier du importerer fra Excel ikke har brøkdelsverdier, konverterer Power BI datakolonnen til en heltallsdatatype , som egner seg bedre til å lagre heltall.

Dette konseptet er viktig fordi noen DAX-funksjoner har spesielle krav til datatyper. I mange tilfeller konverterer DAX implisitt datatyper, men i noen tilfeller gjør det ikke det. For eksempel, hvis en DAX-funksjon krever en datodatatype , men datatypen for kolonnen din er tekst, vil ikke DAX-funksjonen fungere riktig. Derfor er det viktig og nyttig å bruke riktige datatyper for kolonner.

Bestem og spesifiser en kolonnes datatype

I Power BI kan du bestemme og spesifisere en kolonnes datatype i Power Query Editor, i tabellvisning eller i rapportvisning:

• I Power Query Editor, velg kolonnen og velg deretter Datatype i Transform-gruppen på båndet.

  

• I tabellvisning eller rapportvisning, velg kolonnen, og velg deretter rullegardinpilen ved siden av Datatype under fanen Kolonneverktøy på båndet.

  

Du kan også sette datatyper i Power Query M-koden ved å bruke Advanced Editor. For mer informasjon om M datatyper og funksjonen Table.TransformColumnTypes , se Datatyper i Power Query og Typer og typekonvertering.

Nedtrekksmenyen for datatyper i Power Query Editor har to datatyper som ikke finnes i tabellvisning eller rapportvisning: dato/tid/tidssone og varighet. Når du laster inn en kolonne med disse datatypene i Power BI-modellen, konverteres en Dato/Tid/Tidssone-kolonne til en dato/tid-datatype , og en varighetskolonne konverteres til en desimaltallsdatatype .

Den binære datatypen støttes ikke utenfor Power Query Editor. I Power Query Editor kan du bruke den binære datatypen når du laster inn binære filer hvis du konverterer den til andre datatyper før du laster den inn i Power BI-modellen. Binærvalget finnes i tabellvisnings- og rapportvisningsmenyene av legacy-grunner, men hvis du prøver å laste binære kolonner inn i Power BI-modellen, kan du støte på feil.

Talltyper

Power BI støtter tre talltyper: desimaltall, fast desimaltall og heltall.

Du kan bruke Tabular Object Model (TOM) Column-egenskapen DataType for å spesifisere DataType Enums for talltyper. For mer informasjon om programmatisk modifisering av objekter i Power BI, se Program Power BI semantiske modeller med Tabular Object Model.

Desimaltall

Desimaltall er den vanligste talltypen, og kan håndtere tall med brøkverdier og hele tall. Desimaltall representerer 64-bits (åttebyte) flyttallsverdier med negative verdier fra -1,79E +308 til -2,23E -308, positive verdier fra 2,23E -308 til 1,79E +308, og 0. Tall som 34, 34.01 og 34.000367063 er gyldige desimaltall.

Den høyeste presisjonen som desimaltalltypen kan representere, er 15 sifre. Desimalskilletegnet kan forekomme hvor som helst i tallet. Denne typen tilsvarer hvordan Excel lagrer tallene sine, og TOM spesifiserer denne typen som DataType.Double Enum.

Fast desimaltall

Datatypen for fast desimaltall har en fast plassering for desimalseparatoren. Desimalseparatoren har alltid fire sifre til høyre, og tillater 19 sifre med betydning. Den største verdien det faste desimaltallet kan representere er positiv eller negativ 922 337 203 685 477,5807.

Typen fast desimaltall er nyttig i tilfeller der avrunding kan føre til feil. Tall med små brøkverdier kan noen ganger akkumuleres og tvinge et tall til å være litt unøyaktig. Typen fast desimaltall kan hjelpe deg å unngå denne typen feil ved å kutte verdiene forbi de fire sifrene til høyre for desimalskillet.

Denne datatypen tilsvarer SQL Servers Desimal (19,4), eller Valuta-datatypen i Analysis Services og Power Pivot i Excel. TOM spesifiserer denne typen som DataType.Decimal Enum.

Heltall

Heltall representerer en 64-bits (åtte byte) heltallsverdi. Fordi det er et heltall, har hele tall ingen sifre til høyre for desimalplassen. Denne typen tillater 19 sifre med positive eller negative heltall mellom -9 223 372 036 854 775 807 (-2^63+1) og 9 223 372 036 854 775 806 (2^63-2), og kan dermed representere de største mulige tallene av de numeriske datatypene.

Som med fast desimaltype kan heltallstypen være nyttig når du trenger å kontrollere avrunding. TOM representerer heltalldatatypen som DataType.Int64 Enum.

Nøyaktighet av talltypeberegninger

Kolonneverdier for desimaltalldatatypen lagres som omtrentlige datatyper, i henhold til IEEE 754-standarden for flyttall. Omtrentlige datatyper har iboende presisjonsbegrensninger, fordi de i stedet for å lagre eksakte tallverdier, kan lagre svært nære, eller avrundede, tilnærminger.

Presisjonstap, eller upresisjon, kan oppstå hvis flyttallsverdien ikke pålitelig kan kvantifisere antall flyttalsifre. Unøyaktighet kan potensielt oppstå som uventede eller unøyaktige beregningsresultater i enkelte rapporteringsscenarier.

Likhetsrelaterte sammenligningsberegninger mellom verdier av desimaltalldatatypen kan potensielt gi uventede resultater. Likhetssammenligninger inkluderer lik =, større enn >, mindre enn <, større enn eller lik >=, og mindre enn eller lik <=.

Dette problemet er mest tydelig når du bruker RANKX-funksjonen i et DAX-uttrykk, som beregner resultatet to ganger og gir litt forskjellige tall. Rapportbrukere legger kanskje ikke merke til forskjellen mellom de to tallene, men rangeringsresultatet kan være merkbart unøyaktig. For å unngå uventede resultater kan du endre kolonnedatatypen fra desimaltall til enten fast desimaltall eller heltall, eller gjøre en tvungen avrunding ved å bruke ROUND. Datatypen for fast desimaltall har større presisjon, fordi desimalseparatoren alltid har fire sifre til høyre.

Sjelden kan beregninger som summerer verdiene til en kolonne med desimal-datatype gi uventede resultater. Dette resultatet er mest sannsynlig med kolonner som har store mengder både positive og negative tall. Summeresultatet påvirkes av fordelingen av verdier over radene i kolonnen.

Hvis en nødvendig beregning summerer de fleste positive tallene før de fleste negative summeres, kan den store positive partialsummen i starten potensielt forvrenge resultatene. Hvis beregningen tilfeldigvis legger sammen balanserte positive og negative tall, beholder spørringen mer presisjon, og gir dermed mer nøyaktige resultater. For å unngå uventede resultater kan du endre kolonnedatatypen fra desimaltall til fast desimaltall eller heltall.

Dato-/tidstyper

Power BI støtter fem dato/tid-datatyper i Power Query Editor. Både dato/tid/tidssone og varighet konverteres under lasting til datamodellen, som følger:

Dato/Tid representerer både en dato- og en tidsverdi. Den underliggende dato-/tidsverdien lagres som et desimaltall, så du kan faktisk konvertere mellom de to. Tidsdelen lagres som en brøkdel til hele multipler av 1/300 sekund (3,33 ms). Datatypen støtter datoer mellom årene 1900 og 9999.

Dato representerer bare en del med dato uten tid. En dato konverteres til modellen som en dato/tid-verdi med null som brøkverdi.

Tid representerer bare en del med tid uten dato. A Time konverteres til modellen som en Date/Time-verdi uten sifre til venstre for desimalpunktet.

Dato/Tid/Tidssone representerer en UTC-dato/tid med tidssoneforskyvning, og konverteres til Dato/Tid når den lastes inn i modellen. Power BI-modellen justerer ikke tidssonen basert på brukerens lokasjon eller lokalitet. En verdi på 09:00 lastet inn i modellen i USA vises som 09:00 der rapporten åpnes eller vises.

Varighet representerer en tidslengde, og konverteres til et desimaltall når det lastes inn i modellen. Derfor kan du legge til eller trekke fra verdier fra dato/tid med riktige resultater, og enkelt bruke det i visualiseringer som viser størrelse.

Teksttype

Tekstdatatypen er en Unicode-tegndatastreng, som kan bestå av bokstaver, tall eller datoer representert i et tekstformat. Den praktiske maksimale grensen for strenglengde er omtrent 32 000 Unicode-tegn, basert på Power BIs underliggende Power Query-motor, og dens begrensninger på tekstdatatypelengder. Tekstdatatyper utenfor den praktiske maksimumsgrensen vil sannsynligvis føre til feil.

Måten Power BI lagrer tekstdata på kan føre til at dataene vises annerledes i visse situasjoner. De neste seksjonene beskriver vanlige situasjoner som kan føre til at tekstdata endrer utseende litt mellom å spørre data i Power Query Editor og laste dem inn i Power BI.

Skille mellom store og små bokstaver

Motoren som lagrer og spør data i Power BI er småbokstavssensitiv, og behandler ulike bokstaver som samme verdi. "A" er lik "a". Power Query er imidlertid kasussensitiv, der "A" ikke er det samme som "a". Forskjellen i kasusfølsomhet kan føre til situasjoner der tekstdata endrer store bokstaver tilsynelatende uforklarlig etter at Power BI er lastet inn.

Følgende eksempel viser ordredata: En OrderNo-kolonne som er unik for hver ordre, og en Addressee-kolonne som viser adressenavnet som manuelt skrives inn ved bestillingstidspunktet. Power Query Editor viser flere bestillinger med de samme adressenavnene lagt inn i systemet med varierende store bokstaver.

Etter at Power BI laster inn dataene, endres store bokstaver i duplikatnavnene i Data-fanen fra den opprinnelige oppføringen til en av variantene av store bokstaver.

Denne endringen skjer fordi Power Query Editor er kasussensitiv, så den viser dataene nøyaktig slik de er lagret i kildesystemet. Motoren som lagrer data i Power BI er ikke avhengig av små og små bokstaver, så den behandler små og store bokstaver som identiske. Power Query-data lastet inn i Power BI-motoren kan endres deretter.

Power BI-motoren evaluerer hver rad individuelt når den laster inn data, med start fra toppen. For hver tekstkolonne, som Addressee, lagrer motoren en ordbok med unike verdier for å forbedre ytelsen gjennom datakomprimering. Motoren ser de tre første verdiene i Addressee-kolonnen som unike og lagrer dem i ordboken. Etter det, fordi motoren er ufølsom for små og små bokstaver, evaluerer den navnene som identiske.

Motoren ser navnet "Taina Hasu" som identisk med "TAINA HASU" og "Taina HASU", så den lagrer ikke disse variantene, men refererer til den første varianten den lagret. Navnet "MURALI DAS" vises med store bokstaver, fordi det var slik navnet dukket opp første gang motoren evaluerte det når dataene ble lastet fra topp til bunn.

Dette bildet illustrerer evalueringsprosessen:

I det foregående eksempelet laster Power BI-motoren den første raden med data, lager Addressee-ordboken og legger til Taina Hasu . Motoren legger også til en referanse til denne verdien i kolonnen Adresseee-en i tabellen den laster inn. Motoren gjør det samme for andre og tredje rad, fordi disse navnene ikke tilsvarer de andre når man ser bort fra kasus.

For fjerde rad sammenligner motoren verdien med navnene i ordboken og finner navnet. Siden motoren ikke er kasussensitiv, er "TAINA HASU" og "Taina Hasu" like. Motoren legger ikke til et nytt navn i ordboken, men refererer til det eksisterende navnet. Den samme prosessen skjer for de gjenværende radene.

Ledende og etterfølgende rom

Power BI-motoren trimmer automatisk alle etterfølgende mellomrom som følger tekstdata, men fjerner ikke ledende mellomrom som kommer før dataene. For å unngå forvirring, når du jobber med data som inneholder ledende eller etterfølgende mellomrom, bør du bruke Text.Trim-funksjonen for å fjerne mellomrom i begynnelsen eller slutten av teksten. Hvis du ikke fjerner ledende mellomrom, kan en relasjon mislykkes i å opprettes på grunn av dupliserte verdier, eller visuelle effekter kan gi uventede resultater.

Følgende eksempel viser data om kunder: en navnekolonne som inneholder kundens navn og en indekskolonne som er unik for hver oppføring. Navnene står i anførselstegn for klarhet. Kundens navn gjentas fire ganger, men hver gang med ulike kombinasjoner av ledende og bakerste mellomrom. Disse variasjonene kan oppstå ved manuell dataregistrering over tid.

I Power Query Editor vises de resulterende dataene som følger.

Når du går til Tabell-fanen i Power BI etter at du har lastet inn dataene, ser den samme tabellen ut som det følgende bildet, med samme antall rader som før.

Men et visuelt bilde basert på disse dataene returnerer bare to rader.

I bildet før har den første raden en total verdi på 60 for Index-feltet, så den første raden i det visuelle bildet representerer de to siste radene med de lastede dataene. Den andre raden med total indeksverdipå 11 representerer de to første radene. Forskjellen i antall rader mellom det visuelle og datatabellen skyldes at motoren automatisk fjerner eller trimmer etterfølgende mellomrom, men ikke ledende mellomrom. Så motoren evaluerer første og andre rad, og tredje og fjerde rad, som identiske, og det visuelle gir disse resultatene.

Denne oppførselen kan også forårsake feilmeldinger knyttet til relasjoner, fordi dupliserte verdier oppdages. For eksempel, avhengig av konfigurasjonen av relasjonene dine, kan du se en feil som ligner på følgende bilde:

I andre situasjoner kan det hende du ikke klarer å opprette en mange-til-én- eller én-til-én-relasjon fordi dupliserte verdier oppdages.

Du kan spore disse feilene tilbake til ledende eller etterfølgende mellomrom, og løse dem ved å bruke Text.Trim, eller Format>Trim under Transform, for å fjerne mellomrommene i Power Query Editor.

Sant/usant-type

Sann/falsk-datatypen er en boolsk verdi av enten Sann eller Falsk. For de beste og mest konsistente resultatene, når du laster inn en kolonne som inneholder boolsk sann/falsk-informasjon i Power BI, sett kolonnetypen til Sann/Falsk.

Power BI konverterer og viser data annerledes i visse situasjoner. Denne seksjonen beskriver vanlige tilfeller av konvertering av boolske verdier, og hvordan man håndterer konverteringer som skaper uventede resultater i Power BI.

I dette eksempelet laster du inn data om hvorvidt kundene dine har meldt seg på nyhetsbrevet ditt. En verdi i TRUE indikerer at kunden har meldt seg på nyhetsbrevet, og en verdi på FALSE indikerer at kunden ikke har meldt seg på.

Men når du publiserer rapporten til Power BI-tjenesten, viser statuskolonnen for nyhetsbrevets påmelding 0 og -1 i stedet for forventede verdier TRUE eller FALSE. Følgende steg beskriver hvordan denne omvendingen skjer, og hvordan den kan forhindres.

Den forenklede spørringen for denne tabellen vises i følgende bilde:

Datatypen i kolonnen Abonnert på nyhetsbrev settes til Any, og som et resultat laster Power BI dataene inn i modellen som tekst.

Når du legger til en enkel visualisering som viser detaljert informasjon per kunde, vises dataene i visualiseringen som forventet, både i Power BI Desktop og når de publiseres til Power BI-tjenesten.

Men når du oppdaterer den semantiske modellen i Power BI-tjenesten, viser kolonnen Abonnert på nyhetsbrev i visuals verdiene som -1 og 0, i stedet for å vise dem som TRUE eller FALSE:

Hvis du publiserer rapporten på nytt fra Power BI Desktop, viser kolonnen Abonnert til nyhetsbrev igjen TRUE eller FALSE som forventet, men når en oppdatering skjer i Power BI-tjenesten, endres verdiene igjen til å vise -1 og 0.

Løsningen for å forhindre dette er å sette alle boolske kolonner til å skrive True/False i Power BI Desktop, og publisere rapporten på nytt.

Når du gjør endringen, viser visualiseringen verdiene i kolonnen Abonnert på nyhetsbrev litt annerledes. I stedet for at teksten består av store bokstaver som skrevet inn i tabellen, er det kun den første bokstaven som skrives med stor forbokstav. Denne endringen er et resultat av å endre kolonnens datatype.

Når du endrer datatypen, publiserer på nytt til Power BI-tjenesten, og en oppdatering skjer, viser rapporten verdiene som Sann eller Falsk, som forventet.

For å oppsummere, når du jobber med boolske data i Power BI, sørg for at kolonnene dine er satt til True/Falne-datatypen i Power BI Desktop.

Blanktype

Blank er en DAX-datatype som representerer og erstatter SQL-nulltall. Du kan lage en blank ved å bruke BLANK-funksjonen , og teste for blanks ved å bruke ISBLANK-logisk funksjon.

Binær type

Du kan bruke den binære datatypen for å representere hvilken som helst data med et binærformat. I Power Query Editor kan du bruke denne datatypen når du laster inn binære filer hvis du konverterer den til andre datatyper før du laster den inn i Power BI-modellen.

Binære kolonner støttes ikke i Power BI-datamodellen. Binærvalget finnes i tabellvisnings- og rapportvisningsmenyene av legacy-grunner, men hvis du prøver å laste binære kolonner til Power BI-modellen, kan du støte på feil.

Tabelltype

DAX bruker en tabelldatatype i mange funksjoner, som aggregeringer og tidsintelligensberegninger. Noen funksjoner krever en referanse til en tabell. Andre funksjoner returnerer en tabell som du så kan bruke som input til andre funksjoner.

I noen funksjoner som krever en tabell som input, kan du spesifisere et uttrykk som evaluerer til en tabell. Noen funksjoner krever en referanse til en basetabell. For informasjon om kravene til spesifikke funksjoner, se DAX-funksjonsreferansen.

Implisitt og eksplisitt datatypekonvertering

Hver DAX-funksjon har spesifikke krav til hvilke typer data som skal brukes som innganger og utganger. For eksempel krever noen funksjoner heltall for noen argumenter og datoer for andre. Andre funksjoner krever tekst eller tabeller.

Hvis dataene i kolonnen du spesifiserer som argument er inkompatible med datatypen funksjonen krever, kan DAX returnere en feilmelding. Men der det er mulig, forsøker DAX å implisitt konvertere dataene til den nødvendige datatypen.

Eksempel:

• Hvis du skriver en dato som streng, parser DAX strengen og prøver å tolke den som et av Windows-dato- og tidsformatene.
• Du kan legge til TRUE + 1 og få resultatet 2, fordi DAX implisitt konverterer TRUE til tallet 1, og utfører operasjonen 1+1.
• Hvis du legger til verdier i to kolonner med én verdi representert som tekst ("12") og den andre som et tall (12), konverterer DAX implisitt strengen til et tall, og gjør deretter addisjonen for et numerisk resultat. Uttrykket = "22" + 22 gir 44.
• Hvis du prøver å sette sammen to tall, presenterer DAX dem som strenger, og så konkatenerer den. Uttrykket = 12 & 34 gir "1234".

Tabeller over implisitte datakonverteringer

Operatøren bestemmer hvilken type konvertering DAX utfører ved å kaste verdiene den trenger før den forespurte operasjonen utføres. Følgende tabeller lister operatorene, og konverteringen DAX gjør på hver datatype når den pares med datatypen i den kryssende cellen.

Addisjon (+)

For eksempel, hvis en addisjonsoperasjon bruker et reelt tall i kombinasjon med valutadata, konverterer DAX begge verdiene til REAL og returnerer resultatet som REAL.

Subtraksjon (-)

I tabellen nedenfor er radoverskriften minuend (venstre side) og kolonneoverskriften subtrahend (høyre side).

For eksempel, hvis en subtraksjonsoperasjon bruker en dato med en annen datatype, konverterer DAX begge verdiene til datoer, og returverdien er også en dato.

Multiplikasjon (*)

For eksempel, hvis en multiplikasjonsoperasjon kombinerer et heltall med et reelt tall, konverterer DAX begge tallene til reelle tall, og returverdien er også REELL.

Inndeling (/)

I tabellen nedenfor er radoverskriften telleren og kolonneoverskriften nevneren.

For eksempel, hvis en divisjonsoperasjon kombinerer et heltall med en valutaverdi, konverterer DAX begge verdiene til reelle tall, og resultatet er også et reelt tall.

Sammenligningsoperatorer

I sammenligningsuttrykk vurderer DAX boolske verdier større enn strengverdier, og strengverdier større enn numeriske eller dato/tid-verdier. Tall og dato-/tidsverdier har samme rang.

DAX gjør ingen implisitte konverteringer for boolske eller strengverdier. BLANK eller en blank verdi konverteres til 0, "", eller False, avhengig av datatypen til den andre sammenlignede verdien.

Følgende DAX-uttrykk illustrerer denne oppførselen:

• =IF(FALSE()>"true","Expression is true", "Expression is false") returnerer «Uttrykket er sant».

• =IF("12">12,"Expression is true", "Expression is false") returnerer «Uttrykket er sant».

• =IF("12"=12,"Expression is true", "Expression is false") returnerer «Uttrykket er falskt».

DAX gjør implisitte konverteringer for numeriske eller dato/tid-typer som tabellen nedenfor beskriver:

Blanks, tomme strenger og nullverdier

DAX representerer en null, blank verdi, tom celle eller manglende verdi med samme nye verditype, en BLANK. Du kan også generere blanks ved å bruke BLANK-funksjonen, eller teste for blanks ved å bruke ISBLANK-funksjonen.

Hvordan operasjoner som addisjon eller konkatenasjon håndterer blanks avhenger av den enkelte funksjonen. Følgende tabell oppsummerer forskjellene mellom hvordan DAX- og Microsoft Excel-formler håndterer tomme skjemaer.

Relatert innhold

Du kan gjøre alle slags ting med Power BI og data. For mer informasjon om Power BI-funksjonalitet, se følgende ressurser:

• Hva er Power BI?
• Oversikt over spørring i Power BI Desktop
• Datakilder i Power BI Desktop
• Forme og kombinere data i Power BI Desktop
• Vanlige spørringsoppgaver i Power BI Desktop