Datatyper i Power BI Desktop
Denne artikkelen beskriver datatyper som støttes av Power BI Desktop og DAX (Data Analysis Expressions).
Når Power BI laster inn data, prøver de å 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 noen brøkverdier, konverterer Power BI Desktop datakolonnen til en datatype for Hvem le tall, som er bedre egnet for lagring av heltall.
Dette konseptet er viktig fordi noen DAX-funksjoner har spesielle krav til datatype. 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 .
Binærdatatypen støttes ikke utenfor Power Query-redigering. I Power Query-redigering kan du bruke binærdatatypen 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. Det binære utvalget 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 Hvem nummer.
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 semantiske modeller for Program Power BI 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 gir 19 sifre av gjeldende betydning. Den største verdien det faste desimaltallet kan representere, er positiv eller negativ 922 337 203 685 477,5807.
Den faste desimaltalltypen er nyttig i tilfeller der avrunding kan introdusere 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-desimal (19,4) eller valutadatatypen i Analysis Services og Power Pivot i Excel. TOM angir denne typen som DataType.Decimal Opplisting.
Heltall
Hvem all representerer en 64-biters heltallsverdi (åtte byte). Fordi det er et heltall, har Hvem all ingen sifre til høyre for desimaltegnet. Denne typen gir 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 størst mulig antall numeriske datatyper.
I likhet med den faste desimaltypenkan talltypen Hvem le være nyttig når du trenger å kontrollere avrunding. TOM representerer datatypen Hvem le tall som DataType.Int64 Opplisting.
Merk
Power BI Desktop-datamodellen støtter 64-biters heltallsverdier, men på grunn av JavaScript-begrensninger er det største antallet Power BI-visualobjekter trygt kan 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øyaktighet av talltypeberegninger
Kolonneverdier for datatypen Desimaltall lagres som omtrentlige datatyper, i henhold til IEEE 754 Standard for flyttall. Omtrentlige datatyper har iboende 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 den flytende punktverdien ikke kan kvantifisere antallet flytende punktsifre på en pålitelig måte. Imprecision kan potensielt vises som uventede eller unøyaktige beregningsresultater i noen 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 Hvem le tall, eller foreta 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 for 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 de fleste positive tallene før de summerer de fleste negative tallene, kan den store positive delvise summen 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 Hvem nummer.
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 i Datamodellen for 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 verdien for dato/klokkeslett 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 tidsdel. En dato konverteres til modellen som en dato/klokkeslett-verdi med null for brøkverdien.
Klokkeslett 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 tilpasser ikke tidssonen basert på en brukers plassering eller lokale. En verdi på 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
Tekstdatatypen er en Unicode-tegndatastreng, som kan være bokstaver, tall eller datoer representert i et tekstformat. Den praktiske maksimumsgrensen for strenglengde er omtrent 32 000 Unicode-tegn, basert på Power BIs underliggende Power Query-motor, og grensene for tekstdatatypelengder . Tekstdatatyper utover 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 enkelte situasjoner. De neste inndelingene beskriver vanlige situasjoner som kan føre til at tekstdata endrer utseendet litt mellom spørring av data i Power Query-redigering og innlasting av dem i Power BI.
Skille mellom store og små bokstaver
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.
Eksemplet nedenfor 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 samme Adressernavn angitt i systemet med ulike store bokstaver.
Når Power BI laster inn dataene, endres stor forbokstav for de dupliserte navnene i datafanen 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 og store bokstaver 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 Addressee, lagrer motoren en ordliste med unike verdier, for å forbedre ytelsen gjennom datakomprimering. Motoren ser de tre første verdiene i Addressee-kolonnen som unike og lagrer dem i ordlisten. Etter dette, fordi motoren 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 saken.
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.
Merk
Fordi motoren som lagrer og spør etter data i Power BI, ikke skiller mellom store og små bokstaver, bør du passe på det 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, behandler den to verdier som bare varierer etter tilfelle som duplikat, mens kilden kanskje ikke behandler dem som sådan. I slike tilfeller er det endelige resultatet udefinert.
Hvis du vil unngå denne situasjonen hvis du bruker DirectQuery-modus med en datakilde som skiller mellom store og små bokstaver, normaliserer du foringsrør 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. Hvis du vil unngå forvirring, bør du bruke text.Trim-funksjonen til å fjerne mellomrom i begynnelsen eller slutten av teksten når du arbeider med data som inneholder innledende eller etterfølgende mellomrom. 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 navnekolonne 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.
| Row | Innledende mellomrom | Etterfølgende plass | Name | Index | Text length |
|---|---|---|---|---|---|
| 1 | Nei | No | "Dylan Williams" | 1 | 14 |
| 2 | Nei | Ja | "Dylan Williams" | 10 | 15 |
| 3 | Ja | Nei | " Dylan Williams" | 20 | sept. |
| 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 indeksfeltet , 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. Så motoren evaluerer første og andre rader, og tredje og fjerde rader, 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 Transform, for å fjerne mellomrom i Power Query-redigering.
Sann/usann type
Datatypen Sann/usann er en boolsk verdi av enten Sann eller Usann. Når du laster inn en kolonne som inneholder boolsk sann/usann informasjon i Power BI, kan du angi kolonnetypen til Sann/Usann når du laster inn en kolonne som inneholder boolsk sann/usann-informasjon i Power BI.
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 indikerer at kunden har registrert seg for nyhetsbrevet, og verdien USANN indikerer 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 som et resultat 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 den semantiske modellen i Power Bi-tjeneste, viser 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 forekommer i Power Bi-tjeneste, endres verdiene på nytt til å vise -1 og 0.
Løsningen for å forhindre denne situasjonen er å angi boolske kolonner til å 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 stor forbokstav som angitt i tabellen, er bare den første bokstaven stor. 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 datatypen Sann/usann i Power BI Desktop.
Tom type
Tom er en DAX-datatype som representerer og erstatter SQL-nullverdier. Du kan opprette en tom funksjon ved hjelp av BLANK-funksjonen , og teste for tomme celler ved hjelp av den logiske funksjonen ISBLANK .
Binærtype
Du kan bruke binærdatatypen 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.
Merk
Hvis en binær kolonne er i utdataene fra trinnene i en spørring, kan det føre til feil ved forsøk på å oppdatere dataene via en gateway. Det anbefales at du eksplisitt fjerner binære kolonner som siste trinn i spørringene.
Tabelltype
DAX bruker en tabelldatatype i mange funksjoner, for eksempel aggregasjoner og tidsintelligensberegninger. 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 DAX-funksjonsreferansen.
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 å kaste den som ett av Dato- og klokkeslettformatene i Windows.
- Du kan legge til SANN + 1 og få resultatet 2, fordi DAX implisitt konverterer TRUE til tallet 1, og gjør 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 og 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øres på hver datatype når den pares med datatypen i den kryssende cellen.
Merk
Disse tabellene inkluderer ikke tekstdatatype . Når et tall representeres i et tekstformat, prøver Power BI i noen tilfeller å bestemme talltypen og representere dataene som et tall.
Tillegg (+)
| HELTALL | CURRENCY | VIRKELIGE | Dato/klokkeslett | |
|---|---|---|---|---|
| HELTALL | HELTALL | CURRENCY | VIRKELIGE | Dato/klokkeslett |
| VALUTA | CURRENCY | CURRENCY | VIRKELIGE | Dato/klokkeslett |
| VIRKELIGE | VIRKELIGE | VIRKELIGE | VIRKELIGE | 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 minuend (venstre side), og kolonneoverskriften er undertrahend (høyre side).
| HELTALL | CURRENCY | VIRKELIGE | Dato/klokkeslett | |
|---|---|---|---|---|
| HELTALL | HELTALL | CURRENCY | VIRKELIGE | VIRKELIGE |
| VALUTA | CURRENCY | CURRENCY | VIRKELIGE | VIRKELIGE |
| VIRKELIGE | VIRKELIGE | VIRKELIGE | VIRKELIGE | VIRKELIGE |
| 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.
Merk
Datamodeller støtter den uary operatoren , - (negativ), men denne operatoren endrer ikke datatypen for operanden.
Multiplikasjon (*)
| HELTALL | CURRENCY | VIRKELIGE | Dato/klokkeslett | |
|---|---|---|---|---|
| HELTALL | HELTALL | CURRENCY | VIRKELIGE | HELTALL |
| VALUTA | CURRENCY | VIRKELIGE | CURRENCY | CURRENCY |
| VIRKELIGE | VIRKELIGE | CURRENCY | VIRKELIGE | VIRKELIGE |
Hvis en multiplikasjonsoperasjon for eksempel kombinerer et heltall med et reelt tall, konverterer DAX begge tallene til reelle tall, og returverdien er også REAL.
Divisjon (/)
I tabellen nedenfor er radoverskriften telleren, og kolonneoverskriften er nevneren.
| HELTALL | CURRENCY | VIRKELIGE | Dato/klokkeslett | |
|---|---|---|---|---|
| HELTALL | VIRKELIGE | CURRENCY | VIRKELIGE | VIRKELIGE |
| VALUTA | CURRENCY | VIRKELIGE | CURRENCY | VIRKELIGE |
| VIRKELIGE | VIRKELIGE | VIRKELIGE | VIRKELIGE | VIRKELIGE |
| Dato/klokkeslett | VIRKELIGE | VIRKELIGE | VIRKELIGE | VIRKELIGE |
Hvis en divisjonsoperasjon for eksempel 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 False, avhengig av datatypen til den andre sammenlignede verdien.
Følgende DAX-uttrykk 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 Operatør |
HELTALL | CURRENCY | VIRKELIGE | Dato/klokkeslett |
|---|---|---|---|---|
| HELTALL | HELTALL | CURRENCY | VIRKELIGE | VIRKELIGE |
| VALUTA | CURRENCY | CURRENCY | VIRKELIGE | VIRKELIGE |
| VIRKELIGE | VIRKELIGE | VIRKELIGE | VIRKELIGE | VIRKELIGE |
| Dato/klokkeslett | VIRKELIGE | VIRKELIGE | VIRKELIGE | Dato/klokkeslett |
Tomme verdier, tomme strenger og nullverdier
DAX representerer en nullverdi, tom verdi, tom celle eller manglende verdi av samme nye verditype, en BLANK. Du kan også generere tomme verdier ved hjelp av BLANK-funksjonen, eller teste for tomme celler ved hjelp av ISBLANK-funksjonen.
Hvordan operasjoner som addisjon eller sammenkoblingshåndtak er tomme, avhenger av den individuelle funksjonen. Tabellen nedenfor oppsummerer forskjellene mellom hvordan DAX- og Microsoft Excel-formler håndterer tomme verdier.
| Uttrykk | DAX | Excel |
|---|---|---|
| BLANK + BLANK | TOM | 0 (null) |
| BLANK + 5 | 5 | 5 |
| BLANK * 5 | TOM | 0 (null) |
| 5/BLANK | Infinity | Error |
| 0/BLANK | NaN | Error |
| TOM/TOM | TOM | Error |
| USANN ELLER TOM | USANN | USANN |
| USANN OG TOM | USANN | USANN |
| SANN ELLER TOM | SANT | SANT |
| SANN OG TOM | USANN | SANT |
| TOM ELLER TOM | TOM | Error |
| TOM OG TOM | TOM | Error |
Relatert innhold
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: