Datatyper i Power BI Desktop

Denne artikkelen beskriver datatypene som støttes i Power BI Desktop og Data Analysis Expressions (DAX).

Når du laster inn data i Power BI Desktop, forsøker den å konvertere datatypen til kildekolonnen til en datatype som støtter mer effektiv lagring, beregninger og datavisualisering på en bedre måte. Hvis en verdikolonne du importerer fra Excel, ikke har brøkverdier, konverterer Power BI Desktop hele datakolonnen til en heltallsdatatype, som er bedre når du skal lagre heltall.

Dette konseptet er viktig, da noen DAX-funksjoner har krav til spesielle datatyper. I mange tilfeller konverterer DAX implisitt en datatype for deg, men det finnes noen tilfeller der den ikke gjør det også. Hvis en DAX-funksjon krever en datodatatype, og datatypen i kolonnene er Tekst, fungerer ikke DAX-funksjonen slik den skal. Derfor er det både viktig og nyttig å få den riktige datatypen for en kolonne. Implisitte konverteringer er beskrevet senere i denne artikkelen.

Bestem og angi datatypen til en kolonne

I Power BI Desktop kan du bestemme og angi datatypen for en kolonne i Power Query-redigering, eller i datavisning eller rapportvisning:

Datatyper i Power Query-redigering

Screenshot of the Data type ribbon, showing it in the Query Editor.

Datatyper i datavisning eller rapportvisning

Screenshot of the Data type ribbon, showing it in the Data View.

Datatype-rullegardinlisten i Power Query-redigering har to datatyper som for øyeblikket ikke finnes i data- eller rapportvisning: Dato/klokkeslett/tidssone og varighet. Når en kolonne med disse datatypene lastes inn i modellen og vises i data- eller rapportvisning, konverteres kolonnene med datatypen Dato/klokkeslett/tidssone til dato/klokkeslett. Kolonnen med datatypen Varighet konverteres til et desimaltall.

Den binære datatypen støttes for øyeblikket ikke utenfor Power Query-redigering. I Power Query-redigering kan du bruke den 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. Av kompatibilitetsgrunner finnes den i menyene for Datavisning og Rapportvisning, men hvis du prøver å laste opp binære kolonner til Power BI-modellen, kan det være at det oppstår feil.

Talltyper

Power BI Desktop støtter tre talltyper:

Desimaltall – viser et 64-biters (åtte byte) flyttall. Det er den vanligste talltypen og tilsvarer tall slik du vanligvis ser dem. Selv om den er utformet til å håndtere tall med brøkverdier, kan den også håndtere hele tall. Desimaltalltypen kan håndtere negative verdier fra -1, 79E +308 til -2,23E -308, 0 og positive verdier fra 2, 23E -308 til 1,79E + 308. Tall som 34, 34,01 og 34,000367063 er gyldige desimaltall. Den største presisjonen som kan vises som et desimaltall, har 15 siffer. Desimalskilletegnet kan forekomme hvor som helst i tallet. Desimaltalltypen samsvarer med lagring av tall i Excel. Datatypen Desimaltall er angitt i tabellobjektmodellen (TOM) som DataType.Double Enum type 1.

Faste desimaltall – har en fast plassering for desimalskilletegnet. Desimalskilletegnet har alltid fire sifre til høyre og tillater 19 signifikante sifre. Den største verdien den kan vise, er 922 337 203 685 477,5807 (positivt eller negativt). Den faste desimaltalltypen brukes når det ikke er mulig å avrunde tallet. Når du arbeider med mange tall som har små brøkverdier, kan de noen ganger akkumulere, og tallet kan bli feil. Siden verdiene etter de fire sifrene til høyre for desimalskilletegnet er avkuttet, kan du unngå slike typer feil ved å bruke den faste desimaltalltypen. Hvis du er kjent med SQL Server, tilsvarer denne datatypen SQL Server desimal (19,4) eller valutadatatypen i Analysis Services og Power Pivot i Excel. Datatypen Fast desimaltall er angitt i TOM som DataType.Decimal Enum type 1.

Heltall – viser en 64-biters (åtte byte) heltallsverdi. Siden det er et heltall, har det ingen sifre til høyre for desimaltegnet. Det tillater 19 sifre: 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). Det kan vise den størst mulige presisjonen for flere numeriske datatyper. I likhet med Faste desimaltall-typen, kan Heltall-typen være nyttig når du må kontrollere avrunding. Datatypen Heltall er angitt i TOM som DataType.Int64 Enum type 1.

Obs!

Power BI Desktop-datamodellen støtter 64-bitersheltall, men det høyeste tallet visualobjekter trygt kan uttrykke, er 9 007 199 254 740 991 (2^53-1) på grunn av begrensninger for JavaScript. Hvis du arbeider med tall i datamodellen ovenfor dette, kan du redusere størrelsen gjennom beregninger før du legger dem til i et visualobjekt.

1 - DataType Opplistinger er angitt i egenskapen tabellkolonneDataType. Hvis du vil lære mer om programmatisk endring av objekter i Power BI, kan du se Programmering Power BI datasett med tabellobjektmodellen.

Sikre nøyaktigheten av talltypeberegninger

Kolonneverdier av datatypen Desimaltall lagres som omtrentlige datatyper i henhold til IEEE 754 Standard for flyttall. Omtrentlige datatyper har innebygde begrensninger i presisjonen fordi i stedet for å lagre den nøyaktige verdien av et tall, kan de lagres som en ekstremt nær, eller avrundet, tilnærming av det. Dette betyr at det er mulig for presisjonstap, eller upresisjon, å skje hvis antall flytende punktsifre ikke kan kvantifiseres pålitelig i flytpunktverdien. Potensialet for upresisjon kan vises som uventede eller unøyaktige beregningsresultater i enkelte rapporteringsscenarioer.

Beregninger som utfører likhetsrelaterte sammenligninger (=, <>, >= og <=) mellom verdier av datatypen Desimaltall, kan potensielt returnere uventede resultater. Dette er mest tydelig når du bruker RANKX-funksjonen i et DAX-uttrykk der resultatet beregnes to ganger, noe som resulterer i litt forskjellige tall. Forskjellen mellom de to tallene er ikke merkbar av rapportbrukeren, 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.

Selv om det er sjeldent, kan beregninger som summerer verdiene i en kolonne med datatypen Desimaltall, potensielt returnere uventede resultater. Dette er mest sannsynlig med kolonner som har både en stor mengde positive tall og en stor mengde negative tall. Resultatet av summen påvirkes av fordelingen av verdier på tvers av rader i kolonnen. Hvis beregningen som kreves for å returnere et spørringsresultat summerer de fleste positive tallene før de fleste negative tallene summeres, kan den delvise summen i begynnelsen potensielt miste presisjon, da den kan bli skjev av den store positive delsummen. På den annen side, hvis en spørring tilfeldigvis legger til balanserte positive og negative tall, vil summen beholde mer presisjon og derfor returneres 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 Query View. Både Dato/klokkeslett/tidssone og Varighet konverteres når det lastes inn i modellen. Power BI Desktop-datamodellen støtter bare dato/klokkeslett, men de kan formateres uavhengig som datoer eller tider.

Dato/klokkeslett – viser både en dato og en tidsverdi. Verdien for dato/klokkeslett lagres som en desimaltalltype. Så du kan konvertere mellom dem. Klokkeslettet til en dato lagres som en brøk av hele multipler av 1/300 sekunder (3,33 ms). Datoer mellom år 1900 og 9999 støttes.

Dato – viser bare en dato (ikke et klokkeslett). Dato er det samme som verdien for dato/klokkeslett der brøkverdien er null, når den konverteres i modellen.

Klokkeslett – viser bare et klokkeslett (ikke en dato). Verdien for klokkeslett er den samme som for dato/klokkeslett, uten sifre til venstre for desimaltegnet, når den konverteres i modellen.

Dato/Klokkeslett/Tidssone – Representerer UTC Dato/Klokkeslett med en tidssoneforskyvning. Denne konverteres til Dato/Klokkeslett når den lastes inn i modellen. Power BI-modellen tilpasser ikke tidssonen basert på en brukers plassering eller lokale osv. Hvis verdien 09:00 lastes inn i modellen i USA vil den vises som 09:00 samme hvor rapporten åpnes eller vises.

Varighet – viser et tidsrom. Denne konverteres til en desimaltalltype når den lastes inn i modellen. Når den er en desimaltalltype, kan den legges til eller trekkes fra et dato/klokkeslett-felt med riktige resultater. Desimaltalltypen kan enkelt brukes i visualiseringer som viser størrelse.

Teksttype

Tekst – en datastreng med Unicode-tegn. Det kan være strenger, numre eller datoer som vises i et tekstformat. Maksimal strenglengde er 268 435 456 Unicode-tegn (256 store tegn) eller 536 870 912 byte.

Power BI lagrer data på måter som kan føre til at dataene vises annerledes i enkelte situasjoner. Denne delen beskriver vanlige situasjoner når du arbeider med tekstdata kan se ut til å endres litt mellom spørring av data ved hjelp av Power Query, og deretter etter at dataene er lastet inn.

Skille mellom store og små bokstaver (i-)følsomhet

Motoren som lagrer og spør etter data i Power BI skiller ikke mellom store og små bokstaver , noe som betyr at motoren behandler ulike store bokstaver som samme verdi: a er lik A. Power Query skiller imidlertid mellom store og små bokstaver: a er ikke lik A. Forskjellen i tilfelle følsomhet fører til situasjoner der tekstdata lastes inn i Power BI og deretter endrer stor forbokstav, tilsynelatende uforklarlig. I det følgende enkle eksemplet lastet vi inn data om ordrer: en OrderNo-kolonne som er unik for hver ordre og en Addressee-kolonne som inneholder adressens navn, som angis manuelt på bestillingstidspunktet. I Power Query vises disse dataene på følgende måte:

Textual data with various capitalizations in Power Query

Legg merke til at det finnes flere ordrer med samme navn som adresser, men angitt i systemet litt annerledes.

Når vi går til Data-fanen i Power BI etter at dataene ble lastet inn, ser den samme tabellen ut som tabellen nedenfor.

The same textual data after loading into Power BI has changed capitalization

Legg merke til at store/små bokstaver for noen av navnene er endret fra måten det opprinnelig ble angitt på. Denne endringen er fordi motoren som lagrer data i Power BI skiller ikke mellom store og små bokstaver, og behandler den store og små bokstaver-versjonen med samme tegn som det samme. Power Query skiller mellom store og små bokstaver, og viser derfor dataene nøyaktig slik de ble lagret i kildesystemet. Dataene i det andre skjermbildet er imidlertid lastet inn i motoren til Power BI og er derfor endret.

Når du laster inn data, evaluerer motoren hver rad, én etter én, fra toppen. For hver tekstkolonne (for eksempel Addressee) lagrer motoren en ordliste med unike verdier for å oppnå ytelse gjennom datakomprimering. Når du behandler Addressee-kolonnen , er de tre første verdiene motoren kommer over, unike og lagres i ordlisten. Men fra det fjerde navnet (ordre 1004) og fremover, siden motoren skiller mellom store og små bokstaver, blir navnene sett på som de samme: Taina Hasu er den samme som TAINA HASU samt Taina HASU. Som et resultat lagrer ikke motoren det navnet, men refererer i stedet til fornavnet den kom over. Det forklarer også hvorfor navnet MURALI DAS er skrevet i store bokstaver, da det bare er slik navnet ble skrevet da motoren først evaluerte det når du laster dataene fra topp til bunn.

Dette bildet forklarer denne prosessen: Depiction of the data load process and mapping text values to a dictionary of unique values

I eksemplet ovenfor laster motoren inn den første raden med data, oppretter addressee-ordlisten og legger til Taina Hasu i den. Den legger også til en referanse til denne verdien i Addressee-kolonnen i tabellen den lastet inn. Den gjør dette også for andre og tredje rad, da begge disse navnene ikke tilsvarer de andre når de sammenlignes med store og små bokstaver.

Addressee for den fjerde raden sammenlignes med navnene i ordlisten og blir funnet: siden motoren skiller mellom store og små bokstaver, er TAINA HASU og Taina Hasu de samme. Derfor legger ikke motoren til et nytt navn i adresseordlisten , i stedet refererer den til det eksisterende navnet. Dette er det samme for de gjenværende radene.

Obs!

Siden motoren som lagrer og spør etter data i Power BI skiller mellom store og små bokstaver, må det tas spesiell forsiktighet når du arbeider i DirectQuery-modus med en kilde som skiller mellom store og små bokstaver. Power BI forutsetter at kilden har eliminert dupliserte rader. Siden Power BI ikke skiller mellom store og små bokstaver, behandles to verdier som er forskjellige etter tilfelle, som dupliserte, mens kilden kanskje ikke behandles som sådan. I slike tilfeller er det endelige resultatet udefinert og bør unngås. Hvis du bruker DirectQuery-modus og datakilden skiller mellom store og små bokstaver, må du normalisere casing i kildespørringen eller i Power Query.

Etterfølgende mellomrom

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, siden Power BI-motoren automatisk trimmer eventuelle etterfølgende mellomrom, men ikke innledende mellomrom. Uten å fjerne innledende eller etterfølgende mellomrom, kan det hende du ikke kan opprette en relasjon fordi dupliserte verdier oppdages eller visualobjekter kan returnere uventede resultater. Som et enkelt eksempel lastet vi inn data om kunder: en navnekolonne som inneholder navnet på kunden og en indekskolonne som er unik for hver oppføring. Legg merke til at kundenavnet gjentas fire ganger, men hver gang med ulike kombinasjoner av innledende og etterfølgende mellomrom:

Rad Innledende mellomrom Etterfølgende plass Navn (i anførselstegn for klarhet) 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

Disse variasjonene kan forekomme med manuell dataregistrering over tid. I Power Query vises de resulterende dataene som følger.

Screenshot of textual data with various leading and trailing spaces in Power Query

Når vi går til Data-fanen i Power BI etter at dataene ble lastet inn, ser den samme tabellen ut som bildet nedenfor.

Screenshot of the same textual data after loading into Power BI returns the same number of rows as before.

Et visualobjekt basert på disse dataene returnerer imidlertid bare to rader.

Screenshot of a table visual based on the same data returns just two lines of data - the first row has a total index of 60 and the second row has a total index of 11.

Som bildet ovenfor viser, har den første raden en totalverdi på 60 for indeksfeltet , noe som fører til at den første raden i visualobjektet representerer de to siste radene av dataene som ble lastet inn tidligere, mens den andre raden med den totale indeksverdien på 11 representerer de to første radene. Forskjellen mellom antall rader mellom visualobjektet og datatabellen skyldes at motoren automatisk fjerner (trimmer) eventuelle etterfølgende mellomrom, men ikke innledende mellomrom. Så første og andre rad og tredje og fjerde rad anses som de samme, og derfor returnerer visualobjektet disse resultatene.

Denne virkemåten kan oppstå når du arbeider med visualobjekter, og også med feilmeldinger relatert til relasjoner fordi dupliserte verdier oppdages. Avhengig av konfigurasjonen av relasjonene, kan du for eksempel se en feil som ligner på bildet nedenfor.

Screenshot of an error message showing: Column 'Name' in Table 'Customers' contains a duplicate value 'Dylan Williams' and this is not allowed for columns on the one side of a many-to-one relationship or for columns that are used as the primary key of a table.

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

Screenshot of the relationship dialog showing a 'the cardinality you selected isn't valid for this relationship' error, which is related to duplicate values being detected.

Disse feilene spores tilbake til innledende eller etterfølgende mellomrom og kan løses ved hjelp av Text.Trim-funksjonen for å fjerne mellomrommene i datatransformasjonsvinduet.

Sann/usann-type

Sann/Usann – en boolsk verdi som er Sann eller Usann.

Power BI konverterer og viser data på en annen måte 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.

Hvis du vil ha de beste og mest konsekvente resultatene når du laster inn en kolonne som inneholder boolsk informasjon (sann/usann) i Power BI, angir du kolonnetypen til Sann/Usann som beskrevet og forklart i eksemplet nedenfor.

I dette eksemplet lastet vi inn data om hvorvidt kundene våre har registrert seg for nyhetsbrevet vårt: En verdi av SANN indikerer at kunden har registrert seg for nyhetsbrevet, en verdi av USANN indikerer at kunden ikke har registrert seg. Når vi publiserer rapporten til Power Bi-tjeneste, legger vi imidlertid merke til at kolonnen som sporer registreringsstatusen for nyhetsbrevet, vises som 0 og -1 i stedet for de forventede verdiene SANN eller USANN. Følgende samlinger av trinn som involverer spørring, publisering og oppdatering av dataene, beskriver hvordan konverteringer skjer, og hvordan de skal håndteres.

Den forenklede spørringen for denne tabellen vises i illustrasjonen nedenfor.

Columns set to boolean

Datatypen for kolonnen Abonnert på nyhetsbrev er satt til Alle, og som et resultat av denne datatypeinnstillingen lastes dataene inn som tekst i den Power BI modellen:

Data loaded into Power B I appears as expected

Når vi 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.

Visual shows data appearing as expected

Men når vi oppdaterer datasettet 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:

Visual shows data appearing in an unexpected format after refresh

Hvis vi 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 å sikre at dette ikke skjer, er å angi boolske kolonner til å skrive sann/usann i Power BI Desktop, og publisere rapporten på nytt.

Change the data type of the column to true false

Når endringen er gjort, viser visualiseringen verdiene i kolonnen Abonner på nyhetsbrev litt annerledes. I stedet for at teksten er bare store bokstaver (som angitt i tabellen), er de nå kursiv og bare den første bokstaven er stor forbokstav, som er resultatet av endring av kolonnens datatype.

Values appear differently when the data type is changed

Når datatypen er endret og publisert på nytt til Power Bi-tjeneste, og når en oppdatering oppstår, vises verdiene som Sann eller Usann, som forventet.

When true or false values use the true false data type, data appears as expected after refresh

I sammendraget, 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.

Tomme celler/nullverdier

Tomme celler – er en datatype i DAX som viser 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ær datatype

Den binære datatypen kan brukes til å representere andre data med et binært format. I Power Query-redigering kan du bruke den 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. Av kompatibilitetsgrunner finnes den i menyene for Datavisning og Rapportvisning, men hvis du prøver å laste opp binære kolonner til Power BI-modellen, kan det være at det oppstår 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.

Tabelldatatype

DAX bruker en tabelldatatype i mange funksjoner, for eksempel i aggregeringer og beregninger for tidsintelligens. Noen funksjoner krever en referanse til en tabell, mens andre funksjoner går tilbake til en tabell som kan brukes som inndata i andre funksjoner. I noen funksjoner som krever en tabell som inndata, kan du velge et uttrykk som returneres til en tabell. Noen funksjoner krever en referanse til en grunntabell. Hvis du vil ha mer informasjon om kravene til de bestemte funksjonene, kan du se Referanse for DAX-funksjoner.

Implisitt og eksplisitt konvertering av datatyper i DAX-formler

Hver DAX-funksjon har bestemte krav til hvilke typer data som brukes som inndata og utdata. Noen funksjoner krever for eksempel heltall for noen 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 som kreves av funksjonen, returnerer DAX, i mange tilfeller, en feil. Uansett prøver DAX å konvertere dataene implisitt til den påkrevde datatypen, der det er mulig. Eksempel:

  • Du kan skrive inn data som en streng, og DAX deler opp strengen og prøver å bruke den som dato- og tidsformater i Windows.
  • Du kan legge til SANN+1 og få resultatet 2, fordi SANN konverteres implisitt til tallet 1 og utfører operasjonen 1+1.
  • Hvis du legger til verdier i to kolonner, der én av verdiene vises som tekst ("12"), og den andre som et tall (12), konverterer DAX implisitt strengen til et tall og utfører addisjonen for å få et numerisk resultat. Uttrykket nedenfor returnerer 44: = "22"+22.
  • Hvis du prøver å sette sammen to tall, viser Excel dem som strenger og setter dem sammen. Følgende uttrykk returnerer "1234": = 12 & 34.

Tabell med implisitte datakonverteringer

Konverteringstypen som utføres, bestemmes av operatoren. Den konverterer verdiene som kreves, før den utfører den forespurte operasjonen. Disse tabellene viser operatorene og konverteringene som utføres på hver datatype i kolonnene, når de er sammenkoblet med datatypen i den kryssende raden.

Obs!

Tekstdatatyper inkluderes ikke i disse tabellene. Når et tall vises i et tekstformat, forsøker Power BI i noen tilfeller å bestemme talltypen og viser den som et tall.

Addisjon (+)

Operator (+) 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 et heltall brukes sammen med valutadata i en addisjon, konverteres begge verdiene til REELL, og resultatene returneres som REELLE.

Subtraksjon (-)

I tabellen nedenfor er radoverskriften minuenden (venstre side), og kolonneoverskriften er subtrahenden (høyre side).

Operator (-) 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 dato brukes i en subtraksjon med en annen datatype, konverteres begge verdiene til datoer. Returverdien blir også en dato.

Obs!

Datamodellene støtter også monooperatoren, - (negativ), men denne operatoren endrer ikke datatypen til operanden.

Multiplikasjon (*)

Operator (*) HELTALL CURRENCY REELL Dato/klokkeslett
HELTALL HELTALL CURRENCY REELL HELTALL
CURRENCY VALUTA REELL CURRENCY VALUTA
REELL REELL CURRENCY REELL REELL

Hvis et heltall kombineres med et reelt tall i en multiplikasjon, konverteres begge tallene til reelle tall, og returverdien er også REELL.

Divisjon (/)

I tabellen nedenfor er radoverskriften telleren, og kolonneoverskriften er nevneren.

Operator(/) (rad/kolonne) 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 et heltall kombineres med en valutaverdi i en deling, konverteres begge verdiene til reelle tall, og resultatet er også et reelt tall.

Sammenligningsoperatorer

I sammenligningsuttrykk er boolske verdier større enn strengverdier, og strengverdier er større enn numeriske verdier eller dato/klokkeslett-verdier. Verdier for tall og dato/klokkeslett har samme rangering. Det utføres ingen implisitte konverteringer for boolske verdier eller strengverdier. En TOM CELLE eller en tom verdi konverteres til 0/""/usann, avhengig av datatypen til den andre sammenligningsverdien.

DAX-uttrykkene nedenfor illustrerer denne virkemåten:

=HVIS(USANT()>"sant", "Uttrykket er sant", "Uttrykket er usant"), returnerer "Uttrykket er sant"

=HVIS("12">12, "Uttrykket er sant", "Uttrykket er usant"), returnerer "Uttrykket er sant"

=HVIS("12"=12, "Uttrykket er sant", "Uttrykket er usant"), returnerer "Uttrykket er usant"

Konverteringer utføres implisitt for numeriske typer eller dato/klokkeslett-typer, som beskrevet i tabellen nedenfor:

Sammenligningsoperator 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

Håndtere tomme celler, tomme strenger og nullverdier

Nullverdier, tomme verdier, tomme celler eller manglende verdier i DAX vises alle som den nye verditypen TOM CELLE. Du kan generere tomme celler ved hjelp av TOM CELLE-funksjonen eller se etter tomme celler ved hjelp av funksjonen ERTOM.

Måten du håndterer tomme celler i operasjoner på, for eksempel addisjoner eller sammenkoblinger, avhenger av de individuelle funksjonene. Tabellen nedenfor viser forskjellene mellom håndteringen av tomme celler i DAX- og Microsoft Excel-formler.

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 funksjonene til programmet, kan du sjekke ut følgende ressurser: