Datatyper i Power BI Desktop
Denne artikkelen beskriver datatyper som Power BI Desktop og DAX (Data Analysis Expressions) støtter.
Når Power BI laster inn data, prøver den å konvertere datatypene for kildekolonner til datatyper som støtter mer effektiv lagring, beregninger og datavisualisering. Hvis for eksempel en kolonne med verdier du importerer fra Excel, ikke har brøkverdier, konverterer Power BI Desktop datakolonnen til en datatype for heltall, som er bedre egnet for lagring av heltall.
Dette konseptet er viktig, da noen DAX-funksjoner har krav til spesielle datatyper. I mange tilfeller konverterer DAX implisitt datatyper, men i noen tilfeller ikke. Hvis en DAX-funksjon for eksempel krever datatypen Dato , men datatypen for kolonnen er Tekst, fungerer ikke DAX-funksjonen som den skal. Så det er viktig og nyttig å bruke de riktige datatypene for kolonner.
Bestemme og angi datatypen for en kolonne
I Power BI Desktop kan du bestemme og angi datatypen for en kolonne i Power Query-redigering, i datavisning eller i rapportvisning:
Velg kolonnen i Power Query-redigering, og velg deretter Datatype i Transformer-gruppen på båndet.
Velg kolonnen i datavisning eller rapportvisning, og velg deretter rullegardinpilen ved siden av Datatype på Kolonneverktøy-fanen på båndet.
Rullegardinlisten datatype i Power Query-redigering har to datatyper som ikke finnes i datavisning eller rapportvisning: Dato/klokkeslett/tidssone og varighet. Når du laster inn en kolonne med disse datatypene i Power BI-modellen, konverteres en dato/klokkeslett/tidssonekolonne til en datatype for dato/klokkeslett , og en varighetskolonne konverteres til en datatype for desimaltall .
Den binære datatypen støttes ikke utenfor Power Query-redigering. I Power Query-redigering 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 menyene Datavisning og Rapportvisning av eldre årsaker, men hvis du prøver å laste binære kolonner inn i Power BI-modellen, kan det hende du støter på feil.
Talltyper
Power BI Desktop støtter tre talltyper: Desimaltall, Fast desimaltall og Heltall.
Du kan bruke egenskapen Tabular Object Model (TOM) Column DataType til å angi DataType Enums for talltyper. Hvis du vil ha mer informasjon om programmatisk endring av objekter i Power BI, kan du se Program Power BI-datasett med tabellobjektmodellen.
Desimaltall
Desimaltall er den vanligste talltypen, og kan håndtere tall med brøkverdier og heltall. Desimaltall representerer 64-biters (åtte byte) flyttall 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, og TOM angir denne typen som DataType.Double Opplisting.
Faste desimaltall
Datatypen Fast desimaltall har en fast plassering for desimalskilletegnet. Desimalskilletegnet har alltid fire sifre til høyre, og tillater 19 sifre av gjeldende multiplum. 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 som har små brøkverdier, kan noen ganger akkumuleres og tvinge et tall til å være litt unøyaktig. Den faste desimaltalltypen kan hjelpe deg med å unngå slike feil ved å avkorte verdiene forbi de fire sifrene til høyre for desimalskilletegnet.
Denne datatypen tilsvarer SQL Server s desimal (19,4) eller valutadatatypen i Analysis Services og Power Pivot i Excel. TOM angir denne typen som DataType.Decimal Enum.
Heltall
Heltall representerer en 64-biters heltallsverdi (åtte byte). Fordi det er et heltall, har heltall ingen sifre til høyre for desimaltegnet. 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), så kan representere flest mulige tall for de numeriske datatypene.
Som med den faste desimaltypen kan heltallstypen være nyttig når du trenger å kontrollere avrunding. TOM representerer datatypen Heltall som DataType.Int64 Enum.
Obs!
Den Power BI Desktop datamodellen støtter 64-biters heltallsverdier, men på grunn av JavaScript-begrensninger kan det største antallet Power BI-visualobjekter trygt uttrykke 9 007 199 254 740 991 (2^53-1). Hvis datamodellen har større tall, kan du redusere størrelsen gjennom beregninger før du legger dem til i visualobjekter.
Nøyaktigheten til beregninger av talltype
Kolonneverdier for datatypen Desimaltall lagres som omtrentlige datatyper, i henhold til IEEE 754 Standard for flyttall. Omtrentlige datatyper har innebygde presisjonsbegrensninger, fordi i stedet for å lagre nøyaktige tallverdier, kan de lagre ekstremt nære eller avrundede tilnærminger.
Presisjonstap, eller upresisjon, kan oppstå hvis flytpunktverdien ikke kan kvantifisere antallet flytende punktsifre på en pålitelig måte. Uprecision kan potensielt vises som uventede eller unøyaktige beregningsresultater i enkelte rapporteringsscenarioer.
Likhetsrelaterte sammenligningsberegninger mellom verdier av datatypen Desimaltall kan potensielt returnere uventede resultater. Likhetssammenligninger inkluderer likheter =som er 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, noe som resulterer i litt forskjellige tall. Rapportbrukere legger kanskje ikke merke til forskjellen mellom de to tallene, men rangeringsresultatet kan være merkbart unøyaktig. Hvis du vil unngå uventede resultater, kan du endre kolonnedatatypen fra desimaltall til enten fast desimaltall eller heltall, eller utføre en tvungen avrunding ved hjelp av AVRUND. Datatypen Fast desimaltall har større presisjon, fordi desimalskilletegnet alltid har fire sifre til høyre.
Beregninger som summerer verdiene i en kolonne med datatypen Desimaltall , kan sjelden returnere uventede resultater. Dette resultatet er mest sannsynlig med kolonner som har store mengder både positive tall og negative tall. Summeringsresultatet påvirkes av fordelingen av verdier på tvers av rader i kolonnen.
Hvis en nødvendig beregning summerer mesteparten av de positive tallene før de fleste negative tallene summeres, kan den store positive delsummen i begynnelsen potensielt forskyve resultatene. Hvis beregningen skjer for å legge til balanserte positive og negative tall, beholder spørringen mer presisjon, og returnerer derfor mer nøyaktige resultater. Hvis du vil unngå uventede resultater, kan du endre kolonnedatatypen fra desimaltall til fast desimaltall eller heltall.
Dato/klokkeslett-typer
Power BI Desktop støtter fem datatyper for dato/klokkeslett i Power Query-redigering. Både dato/klokkeslett/tidssone og varighet konverteres under innlasting til datamodellen Power BI Desktop. Modellen støtter dato/klokkeslett, eller du kan formatere verdiene som dato eller klokkeslett uavhengig av hverandre.
Dato/klokkeslett representerer både en dato- og klokkeslettverdi. Den underliggende dato/klokkeslett-verdien lagres som en desimaltalltype , slik at du kan konvertere mellom de to typene. Tidsdelen lagres som en brøk til hele multipler på 1/300 sekunder (3,33 ms). Datatypen støtter datoer mellom år 1900 og 9999.
Dato representerer bare en dato uten klokkeslettdel. En dato konverteres til modellen som en dato/klokkeslett-verdi med null for brøkverdien.
Klokkeslettet representerer bare et klokkeslett uten datodel. Et klokkeslett konverteres til modellen som en dato/klokkeslett-verdi uten sifre til venstre for desimaltegnet.
Dato/klokkeslett/tidssone representerer en UTC-dato /klokkeslett med en tidssoneforskyvning, og konverteres til dato/klokkeslett når den lastes inn i modellen. Power BI-modellen justerer ikke tidssonen basert på en brukers plassering eller nasjonale innstillinger. Verdien 09:00 lastet inn i modellen i USA vises som 09:00 uansett hvor rapporten åpnes eller vises.
Varighet representerer en tidsperiode, og konverteres til en desimaltalltype når den lastes inn i modellen. Som desimaltalltype kan du legge til eller trekke fra verdiene fra dato/klokkeslett-verdier med riktige resultater, og enkelt bruke verdiene i visualiseringer som viser størrelse.
Teksttype
Datatypen Tekst er en Datastreng for Unicode-tegn, som kan være bokstaver, tall eller datoer representert i et tekstformat. Den maksimale strenglengden er 268 435 456 Unicode-tegn (256 megategn) eller 536 870 912 byte.
Måten Power BI lagrer tekstdata på, kan føre til at dataene vises annerledes i enkelte situasjoner. De neste avsnittene beskriver vanlige situasjoner som kan føre til at tekstdata endrer utseendet litt mellom å spørre data i Power Query-redigering og laste dem inn i Power BI.
Saksfølsomhet
Motoren som lagrer og spør etter data i Power BI, skiller ikke mellom store og små bokstaver, og behandler ulike bokstaver som samme verdi. "A" er lik "a". Power Query skiller imidlertid mellom store og små bokstaver, der «A» ikke er det samme som «a». Forskjellen i tilfelle følsomhet kan føre til situasjoner der tekstdata endrer stor forbokstav tilsynelatende uforklarlig etter innlasting i Power BI.
Følgende eksempel viser ordredata: En OrderNo-kolonne som er unik for hver ordre, og en Addressee-kolonne som viser adressenavnet som er angitt manuelt på bestillingstidspunktet. Power Query-redigering viser flere ordrer med de samme adressenavnene som er angitt i systemet med varierende store bokstaver.
Når Power BI laster inn dataene, endres stor forbokstav i de dupliserte navnene i Data-fanen fra den opprinnelige oppføringen til én av variantene for stor forbokstav.
Denne endringen skjer fordi Power Query-redigering skiller mellom store og små bokstaver, så den viser dataene nøyaktig slik de er lagret i kildesystemet. Motoren som lagrer data i Power BI skiller ikke mellom store og små bokstaver, så den behandler de små og store versjonene av et tegn som identisk. Power Query data som lastes inn i Power BI-motoren, kan endres tilsvarende.
Power BI-motoren evaluerer hver rad individuelt når den laster inn data, fra toppen. For hver tekstkolonne, for eksempel Adresser, lagrer motoren en ordliste med unike verdier, for å forbedre ytelsen gjennom datakomprimering. Motoren ser de tre første verdiene i Kolonnen Adresser som unike og lagrer dem i ordlisten. Etter dette, fordi motoren ikke skiller mellom store og små bokstaver, evalueres navnene som identiske.
Motoren ser navnet "Taina Hasu" som identisk med "TAINA HASU" og "Taina HASU", så det lagrer ikke disse variasjonene, men refererer til den første variasjonen den lagret. Navnet "MURALI DAS" vises med store bokstaver, fordi det var slik navnet dukket opp første gang motoren evaluerte det når du laster inn dataene fra topp til bunn.
Dette bildet illustrerer evalueringsprosessen:
I det foregående eksemplet laster Power BI-motoren inn den første raden med data, oppretter adresseordlisten og legger til Taina Hasu i den. Motoren legger også til en referanse til denne verdien i Addressee-kolonnen i tabellen den lastes inn. Motoren gjør det samme for andre og tredje rad, fordi disse navnene ikke tilsvarer de andre når de ignorerer store og små bokstaver.
For den fjerde raden sammenligner motoren verdien med navnene i ordlisten og finner navnet. Siden motoren skiller mellom store og små bokstaver, er «TAINA HASU» og «Taina Hasu» de samme. Motoren legger ikke til et nytt navn i ordlisten, men refererer til det eksisterende navnet. Den samme prosessen skjer for de gjenværende radene.
Obs!
Fordi motoren som lagrer og spør etter data i Power BI skiller mellom store og små bokstaver, bør du være spesielt forsiktig når du arbeider i DirectQuery-modus med en kilde som skiller mellom store og små bokstaver. Power BI antar at kilden har eliminert dupliserte rader. Fordi Power BI skiller mellom store og små bokstaver, behandles to verdier som bare skiller seg etter tilfelle, som duplikat, mens kilden kanskje ikke behandler dem som sådan. I slike tilfeller er det endelige resultatet udefinert.
Hvis du bruker DirectQuery-modus med en datakilde som skiller mellom store og små bokstaver, kan du unngå denne situasjonen ved å normalisere casing i kildespørringen eller i Power Query-redigering.
Innledende og etterfølgende mellomrom
Power BI-motoren trimmer automatisk eventuelle etterfølgende mellomrom som følger tekstdata, men fjerner ikke innledende mellomrom som kommer foran dataene. Når du arbeider med data som inneholder innledende eller etterfølgende mellomrom, bør du bruke Text.Trim-funksjonen til å fjerne mellomrom i begynnelsen eller slutten av teksten for å unngå forvirring. Hvis du ikke fjerner innledende mellomrom, kan det hende at en relasjon ikke kan opprettes på grunn av dupliserte verdier, eller visualobjekter kan returnere uventede resultater.
Følgende eksempel viser data om kunder: en Navn-kolonne som inneholder navnet på kunden og en indekskolonne som er unik for hver oppføring. Navnene vises i anførselstegn for klarhet. Kundenavnet gjentas fire ganger, men hver gang med ulike kombinasjoner av innledende og etterfølgende mellomrom. Disse variasjonene kan forekomme med manuell dataregistrering over tid.
| Rad | Innledende mellomrom | Etterfølgende plass | Navn | Indeks | Tekstlengde |
|---|---|---|---|---|---|
| 1 | Nei | Nei | "Dylan Williams" | 1 | 14 |
| 2 | Nei | Ja | "Dylan Williams" | 10 | 15 |
| 3 | Ja | Nei | " Dylan Williams" | 20 | 15 |
| 4 | Ja | Ja | " Dylan Williams " | 40 | 16 |
I Power Query-redigering vises de resulterende dataene som følger.
Når du går til Data-fanen i Power BI etter at du har lastet inn dataene, ser den samme tabellen ut som bildet nedenfor, med samme antall rader som før.
Et visualobjekt basert på disse dataene returnerer imidlertid bare to rader.
I det foregående bildet har den første raden en totalverdi på 60 for Indeks-feltet , så den første raden i visualobjektet representerer de to siste radene i de innlastede dataene. Den andre raden med total indeksverdipå 11 representerer de to første radene. Forskjellen i antall rader mellom visualobjektet og datatabellen skyldes at motoren automatisk fjerner eller trimmer etterfølgende mellomrom, men ikke innledende mellomrom. Motoren evaluerer derfor de første og andre radene, og tredje og fjerde rad, som identiske, og visualobjektet returnerer disse resultatene.
Denne virkemåten kan også føre til feilmeldinger relatert til relasjoner, fordi dupliserte verdier oppdages. Avhengig av konfigurasjonen av relasjonene kan du for eksempel se en feil som ligner på følgende bilde:
I andre situasjoner kan det hende du ikke kan opprette en mange-til-én- eller én-til-én-relasjon fordi dupliserte verdier oppdages.
Du kan spore disse feilene tilbake til innledende eller etterfølgende mellomrom, og løse dem ved hjelp av Text.Trim eller Trim under Transformer for å fjerne mellomrommene i Power Query-redigering.
Sann/usann-type
Datatypen Sann/usann er en boolsk verdi av enten Sann eller Usann. For de beste og mest konsekvente resultatene, når du laster inn en kolonne som inneholder boolsk sann/usann informasjon i Power BI, angir du kolonnetypen til Sann/Usann.
Power BI konverterer og viser data annerledes i enkelte situasjoner. Denne delen beskriver vanlige tilfeller av konvertering av boolske verdier, og hvordan du håndterer konverteringer som skaper uventede resultater i Power BI.
I dette eksemplet laster du inn data om hvorvidt kundene har registrert seg for nyhetsbrevet. Verdien SANN angir at kunden har registrert seg for nyhetsbrevet, og verdien USANN angir at kunden ikke har registrert seg.
Når du publiserer rapporten til Power Bi-tjeneste, viser imidlertid statuskolonnen for registrering av nyhetsbrev 0 og -1 i stedet for de forventede verdiene sann eller USANN. Følgende trinn beskriver hvordan denne konverteringen skjer, og hvordan du forhindrer den.
Den forenklede spørringen for denne tabellen vises i følgende bilde:
Datatypen for kolonnen Abonner på nyhetsbrev er satt til Alle, og derfor laster Power BI inn dataene i modellen som tekst.
Når du legger til en enkel visualisering som viser detaljert informasjon per kunde, vises dataene i visualobjektet som forventet, både i Power BI Desktop og når de publiseres til Power Bi-tjeneste.
Når du oppdaterer datasettet i Power Bi-tjeneste, viser imidlertid kolonnen Abonner på nyhetsbrev i visualobjektene verdier som -1 og 0, i stedet for å vise dem som SANN eller USANN:
Hvis du publiserer rapporten på nytt fra Power BI Desktop, viser kolonnen Abonner på nyhetsbrev på nytt SANN eller USANN som forventet, men når en oppdatering skjer i Power Bi-tjeneste, endres verdiene på nytt til å vise -1 og 0.
Løsningen for å forhindre denne situasjonen er å angi at boolske kolonner skal skrive sann/usann i Power BI Desktop, og publisere rapporten på nytt.
Når du gjør endringen, viser visualiseringen verdiene i kolonnen Abonner på nyhetsbrev litt annerledes. I stedet for at teksten er bare stor forbokstav som angitt i tabellen, er det bare den første bokstaven som er stor forbokstav. Denne endringen er ett resultat av å endre kolonnens datatype.
Når du endrer datatypen, publiserer på nytt til Power Bi-tjeneste, og en oppdatering skjer, viser rapporten verdiene som sann eller usann, som forventet.
Hvis du vil oppsummere når du arbeider med boolske data i Power BI, må du kontrollere at kolonnene er satt til sann/usann-datatypen i Power BI Desktop.
Tom type
Tom er en DAX-datatype som representerer og erstatter SQL-nullverdier. Du kan opprette en tom celle ved hjelp av TOM CELLE-funksjonen og se etter tomme celler ved hjelp av den logiske funksjonen ERTOM.
Binærtype
Du kan bruke den binære datatypen til å representere data med et binært format. I Power Query-redigering 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 menyene Datavisning og Rapportvisning av eldre årsaker, men hvis du prøver å laste inn binære kolonner til Power BI-modellen, kan det hende du støter på feil.
Obs!
Hvis en binær kolonne er i utdataene i trinnene i en spørring, kan det oppstå feil hvis du prøver å laste inn dataene på nytt gjennom en gateway. Det anbefales at du eksplisitt fjerner eventuelle binære kolonner som siste trinn i spørringene.
Tabelltype
DAX bruker en tabelldatatype i mange funksjoner, for eksempel i aggregeringer og beregninger for tidsintelligens. Noen funksjoner krever en referanse til en tabell. Andre funksjoner returnerer en tabell som du deretter kan bruke som inndata til andre funksjoner.
I noen funksjoner som krever en tabell som inndata, kan du angi et uttrykk som evalueres til en tabell. Noen funksjoner krever en referanse til en basistabell. Hvis du vil ha informasjon om kravene til bestemte funksjoner, kan du se REFERANSE for DAX-funksjonen.
Implisitt og eksplisitt datatypekonvertering
Hver DAX-funksjon har spesifikke krav for datatypene som skal brukes som inndata og utdata. Noen funksjoner krever for eksempel heltall for enkelte argumenter og datoer for andre. Andre funksjoner krever tekst eller tabeller.
Hvis dataene i kolonnen du angir som et argument, ikke er kompatible med datatypen funksjonen krever, kan DAX returnere en feil. Men der det er mulig, forsøker DAX å implisitt konvertere dataene til den nødvendige datatypen.
Eksempel:
- Hvis du skriver inn en dato som en streng, analyserer DAX strengen og prøver å angi den som ett av dato- og klokkeslettformatene i Windows.
- 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 tillegget for et numerisk resultat. Uttrykket = "22" + 22 returnerer 44.
- Hvis du prøver å kjede sammen to tall, presenterer DAX dem som strenger, og kjeder dem deretter sammen. Uttrykket = 12 & 34 returnerer "1234".
Tabeller med implisitte datakonverteringer
Operatoren bestemmer hvilken type konvertering DAX utfører ved å kaste verdiene det krever før du utfører den forespurte operasjonen. Tabellene nedenfor viser operatorene, og dax-konverteringen gjør det på hver datatype når den pares med datatypen i den kryssende cellen.
Obs!
Disse tabellene inkluderer ikke datatypen Tekst . Når et tall representeres i et tekstformat, prøver Power BI i noen tilfeller å bestemme talltypen og representere dataene som et tall.
Addisjon (+)
| HELTALL | CURRENCY | REELL | Dato/klokkeslett | |
|---|---|---|---|---|
| HELTALL | HELTALL | CURRENCY | REELL | Dato/klokkeslett |
| CURRENCY | CURRENCY | VALUTA | REELL | Dato/klokkeslett |
| REELL | REELL | REELL | REELL | Dato/klokkeslett |
| Dato/klokkeslett | Dato/klokkeslett | Dato/klokkeslett | Dato/klokkeslett | Dato/klokkeslett |
Hvis en tilleggsoperasjon for eksempel 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 minuenden (venstre side), og kolonneoverskriften er subtrahenden (høyre side).
| HELTALL | CURRENCY | REELL | Dato/klokkeslett | |
|---|---|---|---|---|
| HELTALL | HELTALL | CURRENCY | REELL | REELL |
| CURRENCY | CURRENCY | VALUTA | REELL | REELL |
| REELL | REELL | REELL | REELL | REELL |
| Dato/klokkeslett | Dato/klokkeslett | Dato/klokkeslett | Dato/klokkeslett | Dato/klokkeslett |
Hvis en subtraksjonsoperasjon for eksempel bruker en dato med en annen datatype, konverterer DAX begge verdiene til datoer, og returverdien er også en dato.
Obs!
Datamodeller støtter den uærlige operatoren , - (negativ), men denne operatoren endrer ikke datatypen for operanden.
Multiplikasjon (*)
| HELTALL | CURRENCY | REELL | Dato/klokkeslett | |
|---|---|---|---|---|
| HELTALL | HELTALL | CURRENCY | REELL | HELTALL |
| CURRENCY | VALUTA | REELL | CURRENCY | VALUTA |
| REELL | REELL | CURRENCY | REELL | REELL |
Hvis for eksempel en multiplikasjonsoperasjon kombinerer et heltall med et reelt tall, konverterer DAX begge tallene til reelle tall, og returverdien er også REELL.
Divisjon (/)
I tabellen nedenfor er radoverskriften telleren, og kolonneoverskriften er nevneren.
| HELTALL | CURRENCY | REELL | Dato/klokkeslett | |
|---|---|---|---|---|
| HELTALL | REELL | CURRENCY | REELL | REELL |
| CURRENCY | VALUTA | REELL | CURRENCY | REELL |
| REELL | REELL | REELL | REELL | REELL |
| Dato/klokkeslett | REELL | REELL | REELL | REELL |
Hvis for eksempel 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 som er større enn strengverdier, og strengverdier som er større enn numeriske verdier eller dato/klokkeslett-verdier. Tall og dato/klokkeslett-verdier har samme rangering.
DAX utfører ingen implisitte konverteringer for boolske verdier eller strengverdier. BLANK eller en tom verdi konverteres til 0, "" eller Usann, avhengig av datatypen for den andre sammenlignede verdien.
DAX-uttrykkene nedenfor illustrerer denne virkemåten:
=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 usant».
DAX gjør implisitte konverteringer for numeriske eller dato/klokkeslett-typer som følgende tabell beskriver:
| Sammenligning Operator |
HELTALL | CURRENCY | REELL | Dato/klokkeslett |
|---|---|---|---|---|
| HELTALL | HELTALL | CURRENCY | REELL | REELL |
| CURRENCY | CURRENCY | VALUTA | REELL | REELL |
| REELL | REELL | REELL | REELL | REELL |
| Dato/klokkeslett | REELL | REELL | REELL | Dato/klokkeslett |
Tomme verdier, tomme strenger og nullverdier
DAX representerer en nullverdi, tom verdi, tom celle eller manglende verdi med samme nye verditype, en BLANK. Du kan generere tomme celler ved hjelp av TOM CELLE-funksjonen eller se etter tomme celler ved hjelp av funksjonen ERTOM.
Hvordan operasjoner, for eksempel addisjons- eller sammenkoblingshåndtak, avhenger av den individuelle funksjonen. Tabellen nedenfor oppsummerer forskjellene mellom hvordan DAX- og Microsoft Excel-formler håndterer tomme celler.
| Uttrykk | DAX | Excel |
|---|---|---|
| TOM + TOM | TOM | 0 (null) |
| TOM + 5 | 5 | 5 |
| TOM * 5 | TOM | 0 (null) |
| 5/TOMME CELLER | Uendelig | Feil |
| 0/TOMME CELLER | NaN | Feil |
| TOM/TOM | TOM | Feil |
| USANN ELLER TOM | USANN | USANN |
| USANN OG TOM | USANN | USANN |
| SANN ELLER TOM | SANN | SANN |
| SANN OG TOM | USANN | SANN |
| TOM ELLER TOM | TOM | Feil |
| TOM OG TOM | TOM | Feil |
Neste trinn
Du kan gjøre alle slags ting med Power BI Desktop og data. Hvis du vil ha mer informasjon om Power BI-funksjoner, kan du se følgende ressurser: