Category: Christmas calendar

Rekursioita tarvitsee DAX:ssa aina välillä. Nyt olisi tavoitteena laajentaa DimEmployee -taulua yhdellä kolumnilla. Tässä kolumnissa olisi arvoina kaikki henkilöt yrityksen toimitusjohtajasta aina kyseisen rivin henkilöön saakka erotinmerkillä eroteltuina. Käytännössä siis kentän tulosjoukko näyttää seuraavalta:

Ken on siis firman johtaja, jolla on Peter alaisena, jonka alaisena toimii Jo ja hänen alaisensa on Guy. Tämä sama päätelmä tulee laskea jokaiselle riville. Et saa lisätä malliin kuin yhden kolumnin. Kaikki koodi on siis kirjoitettava tämän kolumnin esittelyyn. Erotinmerkki on /-merkki.

Palauta kolumnin lisäyskoodisi vastauksessasi.

Tehtävässä tarvitsemasi Power BI desktop tiedoston voit ladata oheisesta linkistä.

Jos haluat palauttaa pähkinän, onnistuu se tuttuun tyyliin Microsoft Forms-lomakkeella.

Pähkinän #15 vastaus – Calculation group

Pähkinään #15 tuli 7 vastausta, joista kolme oli juuri se ominaisuus, jota minä hain. Calculation Groupit ovat ihan uusi ominaisuus, jolla voi tehdä contextinvaihtosuureita. Eli juuri suureita joka laskevat saman asian kuin aikaisemmin, mutta toisessa kontekstissa, kuten esimerkiksi erilaisella Wherellä.

Niihin on hyvä ohje osoitteessa: Calculation groups in Analysis Services tabular models | Microsoft Docs

Nyt asiakkaalle oli vanhempi Analysis Services ja minun oli pakko päätyä ratkaisuun, jossa oli välitaulu. Käytännössä siis 2 uutta taulua niin että keskimmäisessä taulussa oli kaksi kolumnia “koko” ja “linkkiId”. Tässä oli *-liitos ja toisessa päässä aina 1-liitos. Sitten toinen uusi taulu, jossa oli “linkkiId” ja “muuttujajoukko”, jossa muuttujajoukko sai arvot “all” ja “without44”. Sitten suodatus 2-suuntaisilla nuolilla. Käytännössä tällöin pystyi filteroimaan tällä uudella taululla ja datajoukko osittui oikein. Mutta paljon elegantimpi ratkaisu on tuo calculation groups.

Joulupähkinä #14 on yksi oikea asiakascase, tosin tietty data on eri kun tässä mennään AdventureWorksilla. Kyseessä on malli, jossa on n. 50 erilaista mittaria (suuretta). Jokaisesta mittarista tulisi saada versio, jossa yksi koko-komponentti otetaan pois. Tämä sen takia, että tietyissä laskennoissa sillä on väliä, toisissa ei niin paljoa.

Oheinen kuva kuvastaa tilanteen. Mittari on Sum([SalesAmount]) ja siitä on toinen versio, jonka koodi on:

SalesWithout44 =
var size = VALUES(‘DimProduct'[Size])
RETURN
CALCULATE(SUM(‘FactInternetSales'[SalesAmount]),’DimProduct'[Size]<>”44″, ‘DimProduct'[Size] in size)

Nyt tuo sama Without44 – tyyppinen laskenta pitäisi saada kaikille 50 muulle mittarille. Tietty voisi tehdä toiset mittarit ja mallissa olisi sen jälkeen 100 mittaria, mutta ei olisi käytännöllistä, eikä asiakas ole valmis maksamaan tuollaisesta apinan hommasta ja siitä seuraavasta ylläpitovaivasta sen jälkeen. Miten siis saisimme jotenkin järkevästi molemmat mittarit käyttöön ilman että kaikkea tulee kopioida.

Erilaiset mittarit ovat siis:

1. Ihan normaali, kuten nytkin.
2. Muuten sama, mutta tulee ottaa pois DimProduct[Size]=44, eli tuota ei tule huomioida missään mittarissa.

Minun tapauksessani asiakkaalla oli Analysis Services 2017, joten lopputulos ei oo niin elegantti, kuin se voisi olla mutta sinä saat tehdä sen käyttäen kaikkia viimeisimpiä komponentteja.

Vastaa kuvauksella mitä tekisit, ei tartte pilkuntarkasti kuvata jokaisen mahdollisen koodin syntaksia, vaan ratkaisumalli.

Palauta tuttuun tapaan Microsoft Formsilla

Joulupähkinä #13 – vastaus

Ensiksi: Sain palautetta että pähkinä on myöhässä! Ihan huippua, sunnuntaina oltiin valmiina pähkinään ja minä nukuin myöhään… Pyydän anteeksi. Mutta samalla olen tosi otettu siitä että ratkaisette näitä pähkinöitä! Vastauksia tuli 6kpl vaikka en edes mainostanut tämän päivän pähkinää kun olin koko päivän lasten harrastuksissa.

Vastaus: 22 067 218 Oikean vastauksen sai 3 henkilöä, pitää lukea vähän tarkemmin mikä noissa muissa meni metsään, eli miten vastaaja on ymmärtänyt tuon väärin. Tärkeät jutut ovat kuitenkin:

• VAR sumvalue – tämä evaluoidaan esittelyn yhteydessä. Tähän ei siis vaikuta myöhemmät filterit vaan sumvalue muuttujassa on ihan numero sisällä (ei siis koodia joka suoritettaisiin myöhemmin). Se saa siis arvon: 273 374.
• VAR classvalues – tämä on taulukko, jossa on yksi kolumni (joku voisi sanoa lista arvoista), mutta tätä ei käytetä varsinaisessa suureessa, joten tästä ei tartte välittää.
• CALCULATEN – Sum on siis ‘DimProduct’-taulusta kaikki muut, paitsi Class-filter. Se vie siis tavallaan lihavoidulle riville “H”, koska H oli class. Sitten ALL(DimDate) poistaa aika-filterin, jolloin mennään H-rivin loppuun Total-sarakkeelle. Saadaan arvo 22 340 592. Tämä tulee Sum-funktiosta, siitä sitten vähennetään tuo sumvalue-muuttujan arvo. Eli: 22340592-273374 = 22067218

Se, mitä halusin tässä tuoda esiin on tuo VAR-evaluoidaan aina silloin kun se esitellään. Sillä voi oikeasti tehdä aika jänniä juttuja kun antaa mahdollisuuden käsitellä lukuja ihan eri laskentacontexteista.

Pähkinä #13 menee VAR,Return, Calculate laskentakontekstien juurelle. Kysymys kuuluu, Mikä luku palautuu kohtaan:

Class=H
Color=Black
Year=2005

Näet näytöllä luvut, kuten ne ovat silloin kun käytetään suuretta SUM(‘FactInternetSales'[SalesAmount]),

Jos suure vaihdetaan seuraavaksi:

Sales2 =
VAR classvalues = values(‘DimProduct'[Class])
var sumvalue=CALCULATE(SUM(‘FactInternetSales'[SalesAmount]))
RETURN
CALCULATE(SUM(‘FactInternetSales'[SalesAmount])-sumvalue,ALLEXCEPT(‘DimProduct’,DimProduct[Class]),ALL(‘DimDate’))

Mitä tulee ko. kohtaan?
Class=H
Color=Black
Year=2005

Malli on tarvittavilta osin tässä:

Palauta suureen summa forms-lomakkeella.

Pähkinän #12 ratkaisu

Pähkinässä #12 ihmeteltiin uutta adaptiivista join-operaattoria SQL Serverissä. Ko. operaattori avasi portit dynaamiselle suoritussuunnitelmalle! Aikaisemmin SQL Server päätti tehdä jotain etukäteen ja sitten itsepäisesti suoritti ko. operaattoria vaikka arvaus olisi mennyt metsään.

Nyt tämä uusi operaattori mahdollistaa kyselylle suoritussuunnitelman tallentamisen ja sitten annettujen parametrien perusteella se voi tilastoista päätellä kumpaa haaraa se alkaisi suorittamaan. Ja sitten jos suorituksen aikana arvaus menee pieleen, se voi vielä vaihtaa operaattoria lennosta. Tämä operaattorin vaihtaminen on harvinainen, mutta tilanteessa missä adaptiivinen join on tehnyt HASH-match vs. NestedLoop parin ja lähtee liikkeelle nestedloopilla, voi operaattori vaihtaa scaniin jos looppi palauttaakin ihan liikaa rivejä arvaukseen nähden. Tämä sen takia, että loopissa joka iteroinnilla saadaan vain yksi arvo ja jos työmäärä arvon saamiseksi on yhtään isompi, voi scan olla itseasiassa paljon nopeampi tapa.

Vastauksia tuli 3, kaikki olivat vähän eri sanamuotoja mutta just oikein! Huhupuheita on ollut että adaptiivisuus tulee myös muutamaan muuhun operaattoriin, kuten sort-group tai hash-group tyyppisiin rakenteisiin, toivottavasti nähdään!

Lyhyt sanallinen pähkinä. Mikä operaattori punaisella merkitty operaattori on? Mitä siinä on tässä tapauksessa tapahtunut.

Viikonloppupähkinät pyrin tekemään niin että puhelimella onnistuu vastata.

Palauta vastaus Microsoft Forms -lomakkeella.

Pähkinän #11 vastaus – indeksin luonti

Pähkinän vastaus tulee päivän 12 aikana. Vastauksia tuli 10 ja pakko kokeilla jokainen vastaus, koska oli erilaisia.

SQL-ongelma: Luo parhaat mahdolliset indeksit kyselylle. Kyselyä et saa muuttaa muilta osin, kuin lähdetaulujen nimien suhteen, koska joudut luomaan kopion olemassa olevista tauluista. Yritä saada mahdollisimman tehokas indeksi niin, että levyoperaatiot jäävät mahdollisimman pieniksi.

Kysely, josta saat siis muuttaa vain taulujen nimiä niiltä osin, kuin olet ottanut kopion alkuperäisistä tauluista:

select sum(SalesAmount),
c.CurrencyName,d.DayNumberOfWeek
from
dbo.FactInternetSales –tätä riviä saa muuttaa
as f inner join
dbo.DimCurrency –tätä riviä saa muuttaa
as c ON
f.CurrencyKey=c.CurrencyKey
inner join
dbo.DimDate –tätä riviä saa muuttaa
as d ON f.OrderDateKey=d.DateKey where d.EnglishMonthName=’April’
group by c.CurrencyName,d.DayNumberOfWeek;

Ongelma on taas siellä tutulla palvelimella

Palvelin: qsql.database.windows.net
Käyttäjätunnus: joulu
Salasana: kalenteri123!
Tietokanta: AdventureWorksLT

Kun ajat komentoa, laita tilastot näkyviin komennoilla:

set statistics io on;
set statistics time on;

Silloin saat messages-välilehdelle näkyviin montako loogista levy-io:ta kysely teki. Ilman mitään muutoksia tulos näyttää tältä:

Eli kysely teki yhteensä: 0+56+0+1439+40 = 1535 levy-io:ta. Tuon alle pitäisi päästä mahdollisimman paljon.

Saat luoda tauluista kopion ottamalla select * into jouludelete.omataulu… Eli Esimerkiksi: select * into jouludelete.FactInternetSales_vesa from dbo.FactInternetSales

Sen jälkeen sinulla on oikeus luoda indeksejä tuohon luomaasi tauluun ja tietenkin sitten muutat selectiä niin että se kyselee siitä sun versiosta, eikä alkuperäisestä. Palauta tuo levy-io listaus ihan sellaisenaan ja mielellään valmiiksi laskettuna summa noista loogisista levy-io:sta.

Palauta tehtävä taas Microsoft Formsiin

Joulupähkinä #10 vastaus

Vastauksia tuli 6 kpl, joten nyt oli taas tylsä tai jotain… Mutta harmittavasti ei ainoatakaan oikeaa vastausta. Pähkinän vaikea knoppi oli se, että Azure Data Factory laskuttaa jokaisesta laatikosta jonka se suorittaa käytetyn ajan, tai vähintään 1 minuutin. Tämä 1 minuuttia voi näytellä tällaisissa loopeissa tosi isoa merkitystä.

Tein esimerkkiajon niin että tuo lookupin palauttava objekti oli 10 riviä, jolloin suoritusaika oli seuraava:

External activities on noita stored proceja. Niitä on siis 20, koska 10 kertaa 2 procia. Se on 0,333h, eli 0,333*60 = 20 minuuttia. Lisäksi tulee pipeline aktiviteetteja 0,016h, eli 0,16*60 = 1. Tämä tarkoittaa siis sitä ekaa lookupia.

Jos tuon olisi pyöräyttänyt 500 objektille, olisi kustannus ollut

• 1 min pipeline
• 1000 min external activities

yhteensä 1001 minuuttia, eli 16,7 tuntia, vaikka suoritus olisi ollut ohi 2 minuutissa. Kustannuksia tämä testi olisi aiheuttanut (1000/60)*0,085eur + (1/60)*0,211 eur = 1,4 euroa.

Tämä on yksi Data Factoryn väärin ymmärretyin ominaisuus. Se on tosi hyvä vekotin siirtämään dataa paikasta toiseen, mutta jos sitä käytetään kuten SSIS:ää on aina käytetty, mennään metsään ja pahasti.

Päivän pähkinä on yksinkertainen: Montako minuuttia Azure Data Factory ajo maksaa? Azure Data Factoryssä compute-resursseista maksetaan käytetyn ajan mukaan. Onko se siis kallista vai halpaa?

Katso oheinen kuvio, laske paljonko oheinen pipeline maksaa ja palauta se vastauksena.

Eli oheisessa lookup kestää 20 sekuntia, se palauttaa 500 objektia jotka syötetään for-each elementille.

For-each iteraattorissa on 2 aktiviteettia. Toinen kestää 5 sekuntia ja toinen 7 sekuntia joka kerta kun ne suoritetaan.

Paljonko maksaa siis kokonaissuoritus?

Palauta tähän Formsiin.

Pähkinän #9 vastaus

Vastauksissa oli monessa sanottu “en oikeasti koskaan tarttisi tällaista”… jokainen vastaus oli oikein ja niitä oli 12 kpl. Olen samaa mieltä, että tuskin tässä muodossa koskaan tarttee, mutta esimerkiksi datan generoinnissa tms voisi joskus tulla tarpeen muokata tietty osuus datasta jonkinlaiseksi.

Ja kun lauserakenne DELETE TOP (28) percent from jouludelete.joku on vähemmän tuttu. Eli sekä update, että delete-lauseisiin voi laittaa tuon top(xx) percent – rakenteen. Kun pitää generoida demodataa on tuo oikeasti hyödyksi!

Päivän pähkinä on seuraava: “Poista taulusta 28% riveistä”. Yksinkertaista.

Voit käyttää testipenkkinä tuota vanhaa tuttua Azure SQL tietokantaa.

Palvelin: qsql.database.windows.net
Tietokanta: AdventureWorksLT
Käyttäjätunnus: joulu
Salasana: kalenteri123!

Siellä on stored procedure generateTable @taulunnimi nvarchar(200) joka luo sinulle taulun harjoittelua varten jouludelete-schemaan. Käytännössä siis esimerkiksi:

Tuo ylempi komento luo tuon taulun, sit alempi tietty selectoi siitä ekat 1000 riviä. Mutta nyt pitäisi siis muodostaa delete-lause jolla tuosta taulusta saadaan 28% riveistä pois. Rivejä alun perin 60398. Pois pitäisi saada 16912 riviä.

Kun olet valmis, poista taulusi drop table jouludelete.xxxxx – komennolla jossa tuo xxxxx on taulusi nimi.

Palauta delete-lause jota käytit.

Pähkinä #8 pohdiskeluja

Vastauksia tuli 8 kpl. Oikeaa vastausta on tietenkin mahdoton antaa koska jokaisella se oli eri. Ehkä pähkinän tarkoitus oli kertoa että q4.fi -palvelulla on oikeasti helppo luoda datayhteys vaikka mihin julkiseen datasettiin. Jos siis tarvitset jotain tilastoa raportillasi, tuolla vekottimella se onnistuu näppärästi.

Jos et oo vielä työkaluun tutustunut, niin q4.fi. Tuota työkalua käyttää jo aika moni toimija. Google Analytics joka tilastoi vain kävijöitä (en tilastoi luotuja kyselyitä millään tavalla) näyttää että sivulla on sellainen 40-50 päivittäistä kävijää, joka on aika paljon kun se tarkoittaa että 40-50 uutta raporttia syntyy joka päivä!

Joulupähkinä #8 on Tilastokeskuksen virallisten tilastojen analysointia Power BI:llä. Jos et vielä ole kertaakaan kokeillut, niin kannattaa! Tilastokeskus ja muut viranomaistahot tekevät tosi paljon tutkimusta, joka julkaistaan avoimena datana. Tämä data on helppo hyödyntää Power BI:ssä tai Excelissä. Päivän tehtävänä on selvittää oman ammattiluokituksesi ansiorakenne Suomessa.

Tilastokeskus tilastoi keskimääräisiä kuukausipalkkoja ammattiluokittain ja ikärakenteen, sekä sukupuolen perusteella.

Minä olen 38-vuotias, Tieto- ja viestintäteknologian erityisasiantuntija, joten tilastojen mukaan säännöllisen työajan mediaanipalkka on minun tehtävissä 4257 euroa/kk. Haluan sinun tutkivan myös dataa ja kertovan vastauksessa minulle Tilastokeskuksen ilmoittaman mediaani ja keskiansion toimessasi. Voit myös katsoa 9. desiiliä, joka on siis se ylin 10% henkilöistä, paljonko he ansaitsevat siinä alarajalla.

Tehtävä onnistuu menemällä osoitteeseen http://q4.fi Valitsemalla sieltä oheisen kuvan mukainen taulukko:

Eli tuo 124q.

Sen jälkeen kaikki raksit päälle ja generoi PowerQuery.

Eli kaikki raksit jokaiseen dimensioon, lopuksi generate power query ja avot. Sulla on Power Query liitettäväksi omaan Power BI raporttiisi ja voit luoda siitä raportin.

Minä suosin sitä, että teen “unpivot columns” noille arvo-kolumneille, koska silloin saa mukavammin slicerin josta voi valita mitä suuretta haluaa käyttää, mutta onnistuu se ilmankin (ne on vain silloin omissa kolumneissaan). Muista että noi on lukuja, joten sun tulee osittaa aina visualisointi sille alimmalle tasolle, kun kaikkia lukuja ei voi mitenkään laskea yhteen tai ottaa keskiarvoa tms.

Myöskin numero-kolumnit sun tulee tunnistaa itse ja merkitä ne numeroiksi.

Palauta siis oman tilastojen mukaisen keskipalkkasi ja mediaanipalkkasi, ei tartte mainita ammattiryhmää tai ikää, koska tärkeintä on oppia käyttämään tätä, ei kerätä taustatietoja.

Palautuksen voit tehdä tästä.

Joulupähkinä #7 ratkaisu

Ihan huippua, ratkaisuja oli kolmea erilaista. Yhtä en kerro, koska opin itse sen aikaisemmin syksyllä ja se on varattu yhteen sql-pähkinään muutaman päivän päästä 🙂

Mutta ensiksi se, miten minä olen ongelman käytännössä aina ratkaissut:

CREATE VIEW uusinakyma AS SELECT TOP 9999999 * from dbo.FactInternetSales Order by OrderDateKey – eli otetaan joku iso luku ja sen avulla voi sit tehdä topin. Tuon ongelma on se, että teoriassa se voi katkaista tulosjoukon. Tietty aina voi laittaa isomman luvun ja sitä kautta tuo on lähinnä teoreettinen ongelma.

Mutta nyt se, minkä minä opin ihan uutena: create view [jouluviews].[nakyma] as select * from dbo.FactInternetSales order by OrderDateKey offset 0 rows – Tuo uusi offset lauserakenne! Oon varmaan liian vanha kun tuo ei oo tullut mieleen… Ihan täydellistä, ei pelkoa siitä onko top-liian pieni, ei pelkoa että top-huijaa kyselymoottoria luulemaan tulosjoukkoa liian isoksi… vaan just oikein. Kiitos tästä!

Ja se kolmas oli yhtä hyvä kuin tuo offset, mutta koska se on tulossa sql-kyselypulmaan parin päivän päästä en sitä tässä paljasta.

Nyt voi olla helppo. Näkymiin ei pysty laittamaan order-by lausetta, mutta miten saada näkymä tuottamaan luvut just haluamassasi järjestyksessä?

Tämä kysely ei onnistu, moottori sanoo että order by-lauserakenne ei ole sallittu näkymissä. Miten ratkaisisit ongelman?

Voit kokeilla mille komennolle näkymän luonti onnistuu samalla tutulla palvelimella. Sinne on luotu schema jouluviews, johon voit näkymiä luoda. Muista poistaa näkymä jotteivat muut näe ratkaisuehdostustasi 🙂

Palvelin: qsql.database.windows.net
käyttäjätunnus: joulu
salasana: kalenteri123!
Tietokanta: AdventureWorksLT

Vastauksen voit lähettää taas Microsoft Form -lomakkeella.

Joulupähkinän #6 ajatuksia

Pähkinä #6 oli sellainen, johon minulla ei ollut varsinaista ratkaisua vaan pikemminkin törmäsin ihan itse seinään. Idea oli että voisiko PowerQueryllä jotenkin muuttaa enterit solun sisällä entereiksi niin, että muutetetaan jokainen kolumni ilman että aineisto jotenkin hajoaa.

Ongelma oli vaikea ja itsenäisyyspäivänä ihmisillä oli muutakin tekemistä. 4 vastausta. Ratkaisut menivät kaikki siihen muotoon, että tunnistamme PowerQueryllä enterin #(lf), jonk jälkeen pivotoimme sen suhteen. Ongelma tuossa on, että joko meillä on oltava kaikissa rikkinäisissä soluissa saman verran virheitä (eli ei voi olla jossain 4 virhettä ja joissain 2 jne. Ongelma tulee kun niissä on eri määrä virheitä jokaisella rivillä. Se voisi onnistua, jos iteroisi rivi kerrallaan ja jokaisen rivin muodostaisi omaan tauluun, jonka pivotoisi ja liittäisi sitten uuteen tauluun appendilla… eli funktiolla voisi toimia.

Ratkaisuista näkyi kuitenkin että niitä oli työstetty ihan tosissaan, joten ihan huippu propsit jokaiselle!

Minä menin itse yli siitä mistä aita oli katkennut… Tein tuosta raportin, jossa loin uuden kolumnin, laskin kolumniin #(lf)-countin nimi kentästä ja plussasin yhdellä. Sitten se suure jolla visualisoin ylennetyt laitoin vaan sum-tuosta uudesta kolumnista. Silloin tuo pahan onnen kolumni sai arvon 3 ja kaikki kolme herraa olivat sitten yhdessä solussa aina…

Tämän päivän pähkinä on todellinen pähkinä. Minä en tuota mitenkään huijaamatta ja elegantisti saanut ratkaistua ja se vähän harmittaa. Tasavallan presidentti on tänään ylentänyt 536 reservin upseeria ja olisin halunnut tehdä siitä Power BI raportin. Lähdeaineistona halusin käyttää virallista listaa puolustusvoimien sivuilta. Kyseisessä PDF-tiedostossa on kuitenkin muotoilussa yhdessä kohtaa virhe, joka johtaa siihen että 3 kapteenia luetaan samaan soluun.

Ylennysuutinen on luettavissa osoitteessa: Ylennykset itsenäisyyspäivänä 2020 – Puolustusvoimat

Ja varsinainen Power BI raportin lähde on: A4Pysty (puolustusvoimat.fi)

Kun Power BI:llä lukee pdf-tiedostoa, ja valitsee jokaisen sivun lähteeksi, lukee se hienosti aineiston sisään. Ainoastaan seuraava kohta tulee huonosti:

Pystyisikö tuon jotenkin Power Queryllä splittaamaan oikein useammaksi riviksi edelleen. Enterin pystyy yhdestä kolumnista jakamaan, mutta tässä ongelma on tuo että pitäisi saada useita kolumneja jaettua. Minä en tätä reilussa tunnissa osannut ratkaista. Aineiston voi tietty exportoida tästä CSV:ksi ja importoida takaisin mutta silloin se ei olisi aitoa suoraan lähteeltä lukemista.

Päivän kysymys on siis voiko tuota jotenkin Power Queryllä muuttaa? Ja jos olet sitä mieltä että liian iso homma, on vaihtoehtoinen kysymys, montako luutnanttia ylennettiin Suomessa ja mistä kaupungista niitä löytyi eniten? Oikeaa vastausta minä en siis osaa antaa ja katsotaan löytyisikö parviälystä voimaa!

Ohessa käyttämäni Power BI dokumentti.

Linkki Microsoft Forms lomakkeelle.

Pähkinä #5 ja DAX-suureen lopputulos

Eilisessä pähkinässä oli ymmärrettävä, että suure tuottaa yhtäkkiä lukuja useammalle kuukaudelle. Eli taulukkoon PowerBI:ssä tulostuvat aina ne kombinaatiot, jotka tuottavat rivejä näytölle. Nyt userelationship-funktio aktivoi eri liitoksen ja aktivoituvassa order ja ship liitoksissa on eri kuukaudet. Eli vaikka suureessa on plus-lasku ja äkkiä tuntuisi että siitähän tulee vain yksi tulos, pitää se ajatella niin että se evaluoidaan kaikille päiville ja jokainen päivä on oma solunsa. Sitten katsotaan tuleeko soluun arvoa ja jos tulee niin se näkyy. Lisäksi DAX:ssa pluslasku Blank():n kanssa on reaalilukujen summa, eli ei blank().

6 vastausta vaikka oli lauantai! Hienoa! Oikesti ihan huippua kun sivulle tulee käyntejä ja jotkut miettivät pulmia 🙂 Olisi tosi työlästä jos kukaan ei palauttaisi yhtään vastausta… Kiitos kaikille jotka ovat sivulla käyneet!