Tabellen in LuckyTemplates: typen en onderscheidingen

Ik wil vandaag wat tijd besteden aan het praten over tabellen in LuckyTemplates. We komen bij elk probleem de hele tijd tafels tegen, maar we besteden er niet echt veel tijd aan om er alleen aan te denken. Je kunt de volledige video van deze tutorial onderaan deze blog bekijken.

Er was onlangs een bericht van LuckyTemplates-lid Ashton, die altijd met goede, tot nadenken stemmende vragen komt. Zijn vraag zette me aan het denken over een patroon dat ik vrij regelmatig zie en dat ik in deze tutorial wil behandelen.

Het was geen fout die hij maakte, maar het is een veelgemaakte fout. Ik zie vaak dat mensen zeggen dat ze bijvoorbeeld problemen hebben met een virtuele tafel, terwijl het in de eerste plaats geen virtuele tafel is.

Er is een echt onderscheid tussen de typen tabellen in LuckyTemplates.

De analogie die ik zou geven is als iemand zou zeggen: "Hé, ik heb onlangs een hond geadopteerd en ik heb problemen met de hond en vraag me af of je kunt helpen" en het is geen hond, maar een wolf. Het zijn allebei hoektanden, maar er zijn behoorlijk grote verschillen waar je rekening mee wilt houden.

Dus hoewel ze allemaal tot dezelfde familie behoren, net als de tabellen in LuckyTemplates, zijn het belangrijke verschillen die echt van invloed zijn op de oplossing en hoe u die tabellen gebruikt. Dus wat ik wilde doen, was de vraag van Ashton opnieuw bekijken, en dan wat dieper ingaan op de verschillen tussen de tabellen die je in LuckyTemplates aantreft, en laten zien hoe dat van invloed is op de manier waarop je ermee omgaat.

De vraag was vrij eenvoudig, maar er komt iets meer bij kijken dan er in eerste instantie lijkt. Hij had een eenvoudige dataset die alleen klanten vermeldt, het soort fruit dat ze kochten, de hoeveelheid en dan alleen een indexnummer.

Hij wilde een snijmachine met een multi-select-mogelijkheid , zodat als je bijvoorbeeld sinaasappel selecteert, alle klanten die sinaasappels kochten, zouden worden opgehaald, maar het zou ook laten zien wat ze nog meer kochten.

Dus als we deze selectie (oranje) uitzetten, kunnen we de volledige dataset zien. We kunnen ook zien dat dit de twee klanten zijn (Joe en Mary) die sinaasappels kochten, maar ze hadden ook elk een extra aankoop.

En dus, het eerste dat we weten, is dat de fruitschaaf een losgekoppelde snijtafel moet zijn. Als het een gewone snijmachine was, zou je oranje raken en zou het eigenlijk alles behalve sinaasappel in de tafel eruit halen. We weten ook, omdat dit dynamisch is, dat we een probleem hebben met een virtuele tafel.

Dus laten we hier een beetje op ingaan, maar voordat we dat doen, laten we eens kijken naar de verschillende soorten tabellen die we in LuckyTemplates vinden.

Inhoudsopgave

• Drie soorten tabellen in LuckyTemplates
• DAX Meetoplossing voor een virtuele tafel
• Conclusie

Drie soorten tabellen in LuckyTemplates

Er zijn drie soorten tafels die we regelmatig tegenkomen. De eerste is de meest voorkomende en het is een fysieke tabel, en dit zijn echt uw primaire gegevens. Telkens wanneer u gegevens ophaalt of gegevens rechtstreeks invoert via deze optie of in Power Query , doet u een referentie of dupliceert u of laadt u gegevens via een lege query, zoals een datumtabel, dat is een fysieke tabel.

Een fysieke tabel is niet volledig dynamisch, maar heeft wel al deze andere kenmerken die de bestandsgrootte vergroten omdat het fysieke gegevens zijn. Het is toegankelijk in Power Query. Meestal worden de relaties in het datamodel opgebouwd door middel van fysieke relaties. Dat hoeven ze niet te zijn, maar dat zijn ze meestal wel. Ze worden gebruikt voor primaire gegevens en u visualiseert deze via de gegevensweergave of via Power Query.

Een fysieke tabel is niet volledig dynamisch, maar heeft wel al deze andere kenmerken die de bestandsgrootte vergroten omdat het fysieke gegevens zijn. Het is toegankelijk in Power Query. Meestal worden de relaties in het datamodel opgebouwd door middel van fysieke relaties. Dat hoeven ze niet te zijn, maar dat zijn ze meestal wel. Ze worden gebruikt voor primaire gegevens en u visualiseert deze via de gegevensweergave of via Power Query.

Degene die vaak wordt verward met de virtuele tabel is deze berekende tabel of wat we ook wel een DAX-expressietabel kunnen noemen. Dit heeft een directe analogie met berekende kolommen die worden gemaakt via DAX- expressies. Dit doet u via het tabblad Modellering en de optie Nieuwe tabel, waarna u de DAX-expressie invoert.

Degene die vaak wordt verward met de virtuele tabel is deze berekende tabel of wat we ook wel een DAX-expressietabel kunnen noemen. Dit heeft een directe analogie met berekende kolommen die worden gemaakt via DAX-expressies. Dit doet u via het tabblad Modellering en de optie Nieuwe tabel, waarna u de DAX-expressie invoert.

Zoals u kunt zien in de onderstaande vergelijkingstabel, verschilt de berekende tabel qua profiel nogal van de fysieke tabel of de virtuele tafel. Het is niet volledig dynamisch.

Het moet worden vernieuwd om de nieuwe informatie op te pikken. Het vergroot de fysieke bestandsgrootte. In tegenstelling tot een gewone fysieke tabel is deze niet toegankelijk in Power Query. Net zoals een berekende kolom niet wordt weergegeven in Power Query, wordt een berekende tabel dat ook niet. Maar het bezit wel de andere aspecten van een fysieke tafel.

Doorgaans worden berekende tabellen gebruikt voor het ondersteunen van tabellen en vaker gebruikt voor foutopsporing. Er zijn nu betere tools zoals DAX Studio en Tabular Editor, dus daar wordt het niet zo vaak voor gebruikt. U bekijkt deze tabel via de gegevensweergave.

En eerlijk gezegd, net als berekende kolommen, is het over het algemeen iets om bij weg te blijven. Er zijn betere manieren om dingen te doen dan via berekende tabellen.

En dan zijn de analogie met metingen de echte virtuele tabellen . Deze komen tot stand in het kader van maatregelen middels de DAX Maatregelcode. Ze zijn volledig dynamisch, in tegenstelling tot de andere twee soorten tabellen. Ze vergroten de bestandsgrootte niet omdat ze on-demand zijn. Net als metingen worden virtuele tabellen on-demand in het geheugen berekend en worden ze allemaal gebruikt in de loop van de contexten waarvoor ze nodig zijn.

Ze zijn niet toegankelijk in Power Query. Daar kun je geen fysieke relatie op leggen. Als u ze relateert in uw gegevensmodel, doet u dat met behulp van virtuele relaties, meestal met .

Virtuele tabellen worden gebruikt voor tussentijdse berekeningen in meetwaarden omdat een meetwaarde geen tabelwaarde kan retourneren en een scalaire waarde moet retourneren. U gebruikt deze dus meestal als tussentijdse berekening waarop u uw scalers genereert, die het resulterende product van uw meting zijn.

U kunt deze tabellen visualiseren in tools zoals DAX Studio, Tabular Editor of New Table, wat wederom waarschijnlijk de minst wenselijke manier is, omdat het uw datamodel volzet met een heleboel extra tabellen, tenzij u deze verwijdert.

DAX Meetoplossing voor een virtuele tafel

Terugkomend op de vraag van Ashton, door naar de tafel te kijken, kunnen we zien dat deze dynamisch is. We kunnen ook meerdere keuzes maken en dit verandert volledig on the fly. En daarom weten we dat het een virtuele tabel is, omdat de andere twee (fysieke en berekende tabellen) niet volledig dynamisch zijn. We weten ook dat het een niet-verbonden tabel is, zoals ik in het begin al zei.

Ik heb het Rubber Duck-concept gebruikt om dit op te lossen. In een eerdere tutorial heb ik het gehad over dit concept van rubber ducking, waarbij een conceptuele oplossing voor het probleem wordt ontwikkeld voordat je je gaat verdiepen in de specifieke DAX.

En dus, voor de rubberen eend-oplossing hier, was wat ik deed in feite deze losgekoppelde snijtafel in elkaar gezet. Vervolgens oogstte ik de waarde van die snijmachines. Vervolgens bedacht ik een virtuele tafel die klanten filterde op degenen die de selecties in de losgekoppelde tafel hadden gekocht.

Vervolgens nam ik die klantenlijst en filterde onze originele dataset door die klanten om de klanten en de aankopen van die klanten te vinden, naast de slicerwaarde.

Laten we eens kijken naar de specifieke maatstaf om te zien hoe dit uitpakte en enkele van de overwegingen die u heeft bij het werken met virtuele tabellen.

Het eerste was het ontwikkelen van twee oogstmaatstaven voor onze waarden. De eerste is de waarde van de losgekoppelde slicer.

Omdat we de multi-select in de vereiste hadden, betekende dit dat we niet zomaar konden gebruiken . gebruiken om mogelijk een of meer selecties vast te leggen in die losgekoppelde slicer. Voor klanten, aangezien we één klant zullen hebben op elke rij die we evalueren, kunnen we SELECTEDVALUE gebruiken.

Het volgende dat ik deed was deze virtuele tabelvariabele ( VAR Buyers ) die begint met . Vervolgens filtert het de klanten op het feit of ze al dan niet een fruitaankoop hebben gedaan die binnen onze waarden van de losgekoppelde snijmachine viel.

We kunnen dit controleren door een DAX-query uit te voeren. We kunnen dat doen in DAX Studio of in Tabular Editor. Dus laten we onze virtuele tabelmaat hier nemen, kopiëren naar de Tabular Editor. We zullen ervoor zorgen dat het ons de waarden geeft die we verwachten te zien, namelijk Joe en Mary.

DAX-query's retourneren altijd tabellen en ze begonnen altijd met EVALUATE, dus voegen we hier EVALUATE toe. We krijgen echter niets in het resultaat. Dit komt omdat de geselecteerde oogstvariabele voor het ontkoppelen van fruit ( SelDisconnFruit ) niet op de hoogte is van de snijmachine. Het is uit zijn verband.

Dus de manier om dat te testen, is door die slicerwaarde kunstmatig in te stellen. We vervangen SelDisconnFruit hier door een kleine tafel. Typ Orange (de waarde van die slicer) tussen kronkelige haakjes . En nu krijgen we het resultaat hier, dat is Joe en Mary. Daarmee werkt de virtuele tafel precies zoals we dachten dat het zou werken.

We kunnen nu dus teruggaan naar onze maatuitdrukking. Een van de uitdagende dingen van virtuele tabellen is dat ze gemakkelijk virtuele tabellen binnen een maat kunnen maken . Maar u kunt geen virtuele tabel retourneren als resultaat van een meting . We moeten dus een scalair teruggeven, maar dat geeft het relevante aspect van de virtuele tabel weer.

Dus hier hebben we de virtuele tabel die ons vertelt welke klanten het fruit kochten dat in de waardesnijder zat. We kunnen een andere variabele instellen ( VAR BuyerIn ) die zegt dat als de geselecteerde klant in de tafel van die koper zat, deze een één krijgt . En zo niet, dan krijgt het een nul .

Vervolgens nemen we de resultaten daarvan en plaatsen dat in het filtervenster. De Key Buyers- maatstaf, zeggen we, is er één en dat zijn de klanten die in dit geval sinaasappelen hebben gekocht.

En door dat te doen, filteren we onze oorspronkelijke gegevenstabel tot de juiste records. U kunt zien dat het nu die virtuele tabel maakt en dat filteren op de juiste manier doet op basis van elke selectie.

Virtuele tabellen binnen Itererende functies in LuckyTemplates – DAX-concepten
Virtuele relaties creëren in LuckyTemplates De TREATAS-functie gebruiken
Hoe de COUNTROWS DAX-functie in virtuele tabellen te gebruiken

Conclusie

Dat is het grootste deel van wat ik vandaag wilde behandelen. Het is een vrij eenvoudig voorbeeld van een virtuele tabel, maar met de nadruk op het verschil tussen fysieke tabellen, berekende tabellen en virtuele tabellen.

Er zijn veel interessante kwesties om opnieuw te bekijken met betrekking tot virtuele tabellen, vooral met betrekking tot het debuggen van virtuele tabelmetingen. Dat is iets waar ik de komende weken op terugkom, maar voor nu is dat alles van deze tutorial.

Proost!