Tabele în LuckyTemplates: tipuri și distincții

Vreau să petrec ceva timp astăzi vorbind despre tabelele din LuckyTemplates. Ne întâlnim tot timpul la mese cu fiecare problemă, dar nu petrecem prea mult timp gândindu-ne singuri la ele. Puteți viziona videoclipul complet al acestui tutorial în partea de jos a acestui blog.

A existat recent o postare de la membrul LuckyTemplates, Ashton, care vine mereu cu întrebări bune, care provoacă gânduri. Interogarea sa m-a făcut să mă gândesc la un model pe care îl văd destul de regulat și pe care vreau să îl abordez în acest tutorial.

Nu a fost o greșeală pe care a făcut-o, dar este o greșeală comună. Văd de multe ori unde oamenii ar spune că au probleme cu o masă virtuală, de exemplu, când nu este o masă virtuală în primul rând.

Există o distincție reală între tipurile de tabele din LuckyTemplates.

Analogia pe care aș face-o este dacă cineva ar spune: „Hei, am adoptat recent un câine și am probleme cu câinele și mă întreb dacă mă poți ajuta” și nu este un câine, ci un lup. Ambii sunt canini, dar există câteva distincții destul de mari de care doriți să țineți cont.

Deci, deși toate fac parte din aceeași familie, la fel ca tabelele din LuckyTemplates, sunt distincții importante care afectează cu adevărat soluția și modul în care utilizați aceste tabele. Și așa că ceea ce am vrut să fac a fost să reexaminăm întrebarea lui Ashton și apoi să mă aprofundez puțin în diferențele dintre tabelele pe care le găsiți în LuckyTemplates și să arăt cum influențează asta modul în care le gestionați.

Întrebarea a fost destul de simplă, dar este puțin mai mult decât pare inițial. Avea un set simplu de date care spune doar clienți, tipul de fructe pe care l-au cumpărat, cantitatea și apoi doar un număr index.

El a vrut să aibă un feliător cu o capacitate de selecție multiplă, astfel încât, dacă ați selectat să spuneți portocaliu, să atragă în sus toți clienții care au cumpărat portocale, dar să arate și ce altceva au cumpărat.

Deci, dacă dezactivăm această selecție (portocaliu), putem vedea setul complet de date. De asemenea, putem observa că aceștia sunt cei doi clienți (Joe și Mary) care au achiziționat portocale, dar au avut fiecare și câte o achiziție suplimentară.

Și astfel, primul lucru despre care știm este că feliatorul de fructe trebuie să fie o masă de feliere deconectată. Dacă ar fi un feliator obișnuit, ați lovi portocaliu și, practic, ar scoate tot, în afară de portocaliu, din masă. Știm, de asemenea, pentru că este dinamic, avem o problemă cu masa virtuală.

Așa că haideți să ne aprofundăm puțin, dar înainte de a face acest lucru, să aruncăm o privire la diferitele tipuri de tabele pe care le găsim în LuckyTemplates.

Cuprins

• Trei tipuri de tabele în LuckyTemplates
• Soluție de măsurare DAX pentru un tabel virtual
• Concluzie

Trei tipuri de tabele în LuckyTemplates

Există trei tipuri de mese pe care le găsim în mod regulat. Primul este cel mai comun și este un tabel fizic, iar acestea sunt cu adevărat datele tale primare. Ori de câte ori obțineți date sau introduceți date direct prin această opțiune sau în Power Query , faceți o referință sau o duplicare sau încărcați date printr-o interogare goală, cum ar fi un tabel de date, acesta este un tabel fizic.

Un tabel fizic nu este complet dinamic, dar are toate aceste alte caracteristici care măresc dimensiunea fișierului, deoarece sunt date fizice. Este accesibil în Power Query. De obicei, relațiile din modelul de date sunt construite prin relații fizice. Nu trebuie să fie, dar de obicei sunt. Sunt folosite pentru datele primare și le vizualizați fie prin vizualizarea datelor, fie prin Power Query.

Un tabel fizic nu este complet dinamic, dar are toate aceste alte caracteristici care măresc dimensiunea fișierului, deoarece sunt date fizice. Este accesibil în Power Query. De obicei, relațiile din modelul de date sunt construite prin relații fizice. Nu trebuie să fie, dar de obicei sunt. Sunt folosite pentru datele primare și le vizualizați fie prin vizualizarea datelor, fie prin Power Query.

Cel care se confundă adesea cu tabelul virtual este acest tabel calculat sau ceea ce ne putem referi și ca un tabel de expresii DAX. Aceasta are o analogie directă cu coloanele calculate care sunt create prin expresii DAX . Acest lucru se face prin fila Modelare și opțiunea Tabel nou și apoi introduceți expresia DAX.

Cel care se confundă adesea cu tabelul virtual este acest tabel calculat sau ceea ce ne putem referi și ca un tabel de expresii DAX. Aceasta are o analogie directă cu coloanele calculate care sunt create prin expresii DAX. Acest lucru se face prin fila Modelare și opțiunea Tabel nou și apoi introduceți expresia DAX.

După cum puteți vedea din tabelul de comparație de mai jos, tabelul calculat este destul de diferit în profil fie de tabelul fizic, fie de cel virtual. Nu este complet dinamic.

Trebuie reîmprospătat pentru a prelua noile informații. Mărește dimensiunea fișierului fizic. Spre deosebire de un tabel fizic direct, acesta nu este accesibil în Power Query. La fel cum o coloană calculată nu apare în Power Query, nici un tabel calculat nu apare. Dar posedă celelalte aspecte ale unei mese fizice.

În mod obișnuit, tabele calculate sunt utilizate pentru tabelele suport și mai frecvent utilizate pentru depanare. Acum există instrumente mai bune, cum ar fi DAX Studio și Tabular Editor, deci nu este folosit atât de frecvent pentru asta. Vizualizați acest tabel prin vizualizarea de date.

Și sincer, ca și coloanele calculate, este în general ceva de care să stai departe. Există moduri mai bune de a face lucrurile decât prin tabele calculate.

Și apoi analogia cu măsurile sunt adevăratele tabele virtuale . Acestea sunt create în contextul măsurilor prin Codul de Măsuri DAX. Sunt complet dinamice, spre deosebire de celelalte două tipuri de mese. Nu măresc dimensiunea fișierului deoarece sunt la cerere. La fel ca și măsurile, tabelele virtuale sunt calculate la cerere în memorie și sunt toate utilizate pe parcursul contextelor pentru care sunt necesare.

Acestea nu sunt accesibile în Power Query. Nu poți pune o relație fizică pe acestea. Dacă le raportați în modelul dvs. de date, faceți acest lucru folosind relații virtuale, cel mai frecvent cu .

Tabelele virtuale sunt folosite pentru calcule intermediare în măsuri, deoarece o măsură nu poate returna o valoare de tabel și trebuie să returneze o valoare scalară. Deci, de obicei, le folosiți ca calcul intermediar pe baza căruia generați scalatorii, care sunt produsul rezultat al măsurării dvs.

Puteți vizualiza aceste tabele în instrumente precum DAX Studio, Tabular Editor sau New Table, care este din nou, probabil cea mai puțin dorită, deoarece vă aglomera modelul de date cu o grămadă de tabele suplimentare, dacă nu ștergeți acest lucru.

Soluție de măsurare DAX pentru un tabel virtual

Revenind la întrebarea lui Ashton, uitându-ne la tabel, putem spune că este dinamică. De asemenea, putem face mai multe alegeri și acest lucru se schimbă complet din mers. Și din această cauză, știm că este un tabel virtual, deoarece celelalte două (tabele fizice și tabele calculate) nu sunt complet dinamice. De asemenea, știm că este o masă deconectată, așa cum am menționat la început.

Am folosit conceptul Rubber Duck pentru a rezolva acest lucru. Într-un tutorial anterior, am vorbit despre acest concept de ducking de cauciuc, care dezvoltă o soluție conceptuală a problemei înainte de a începe să sapă în DAX-ul specific.

Și așa, pentru soluția de rață de cauciuc de aici, ceea ce am făcut a fost practic să pun împreună această masă de tăiat deconectată. Apoi, am recoltat valoarea acelor feliere. În continuare, am venit cu un tabel virtual care filtra clienții după cei care cumpăraseră selecțiile din tabelul deconectat.

Apoi, am luat acea listă de clienți și am filtrat setul nostru original de date de către acești clienți pentru a veni cu clienții și achizițiile făcute de acești clienți, în plus față de valoarea slicer.

Să aruncăm o privire la măsura specifică pentru a vedea cum s-a desfășurat aceasta și câteva dintre considerentele pe care le aveți în lucrul cu mesele virtuale.

Primul lucru a fost să dezvoltăm două măsuri de recoltare pentru valorile noastre. Prima fiind valoarea slicer-ului deconectat.

Deoarece am avut selecția multiplă în cerință, aceasta însemna că nu puteam folosi doar . Deci, ceea ce am făcut a fost să folosesc funcția pentru a captura potențial una sau mai multe selecții în acel slicer deconectat. Pentru clienți, deoarece vom avea câte un client pe fiecare rând pe care îl evaluăm, putem folosi SELECTEDVALUE.

Următorul lucru pe care l-am făcut a fost această variabilă de tabel virtual ( VAR Buyers ) care începe cu . Apoi, se trece la filtrarea clienților în funcție de faptul că au făcut sau nu o achiziție de fructe care a fost în valorile noastre ale felitorului deconectat.

Putem verifica acest lucru făcând o interogare DAX. Putem face asta fie în DAX Studio, fie în Tabular Editor. Deci, să luăm măsura noastră de tabel virtual aici, să o copiem în Editorul tabelar. Ne vom asigura că ne oferă valorile pe care ne așteptăm să le vedem, care ar fi Joe și Mary.

Interogările DAX returnează întotdeauna tabele și au început întotdeauna cu EVALUATE, așa că adăugăm EVALUATE aici. Cu toate acestea, nu obținem nimic în rezultat. Acest lucru se datorează faptului că variabila de recoltare a fructelor de deconectare selectată ( SelDisconnFruit ) nu are cunoștință de feliere. Este în afara contextului.

Deci modalitatea de a testa aceasta este setarea artificială a valorii acelei slicer. Vom înlocui SelDisconnFruit cu o masă mică aici. Introduceți portocaliu (valoarea acelui slicer) între paranteze ondulate . Și acum, obținem rezultatul aici, care este Joe și Mary. Cu asta, masa virtuală funcționează exact așa cum ne-am gândit.

Așa că ne putem întoarce acum la expresia noastră de măsură. Unul dintre lucrurile provocatoare despre tabelele virtuale este că sunt ușor de creat tabele virtuale într-o măsură . Dar nu puteți returna un tabel virtual ca rezultat al unei măsuri . Deci trebuie să returnăm un scalar, dar care surprinde aspectul relevant al tabelului virtual.

Deci, aici, avem tabelul virtual care ne spune ce clienți au achiziționat fructele care se aflau în feliatorul de valoare. Putem seta o altă variabilă ( VAR BuyerIn ) care spune, dacă clientul selectat a fost în tabelul respectivului cumpărător, atunci primește unul . Și dacă nu, primește un zero .

Apoi luăm rezultatele și le punem în panoul de filtru. Măsura Cumpărătorilor Cheie , spunem noi, este una și acestea vor fi clienții care au achiziționat, în acest caz, portocale.

Și astfel, făcând asta, filtrem tabelul nostru de date inițial până la înregistrările corecte. Puteți vedea că acum creează acel tabel virtual și face acea filtrare în mod corespunzător în funcție de fiecare selecție.

Tabele virtuale în interiorul funcțiilor de iterare în LuckyTemplates – Concepte DAX
Crearea de relații virtuale în LuckyTemplates Utilizarea funcției TREATAS
Cum se utilizează funcția COUNTROWS DAX în tabelele virtuale

Concluzie

Asta e cea mai mare parte a ceea ce am vrut să acopăr astăzi. Este un exemplu de tabel virtual destul de simplu, dar cu accent pe diferența dintre tabele fizice, tabele calculate și tabele virtuale.

Există o mulțime de probleme interesante de revizuit în ceea ce privește tabelele virtuale, în special cu depanarea măsurilor tabelelor virtuale. Este ceva la care voi reveni în următoarele câteva săptămâni, dar pentru moment, asta este tot acest tutorial.

Noroc!