Beitrag von Ceteris AG

Transcript

[Musik] Ein herzliches Hallo mal wieder von Markus�� Raatz von der Ceteris AG zum lustigen Video���� zum technischen Thema! Heute gibt es mal�� wieder einen ganz normalen technischen���� Tipp den man bei Power bi benutzen kann�� oder bei Microsoft fabric benutzen kann,���� n��mlich: wie man Plan- und Ist-vergleiche�� richtig modelliert. Und das ist schon das���� dritte Video von mir zu dem Thema wie man Plan�� und Istwerte richtig miteinander vergleicht,���� und das ist jetzt keine Voraussetzung, aber�� man k��nnte sich nat��rlich die beiden hier���� noch mal angucken, damit man noch tiefer im�� Thema drin ist. Aber ich erkl��re einfach mal���� im Power BI Desktop in der Berichtsansicht�� worum es geht, es geht n��mlich genau darum:���� ich habe hier echte Umsatzwerte wie in dem�� Fall meine Modellflugzeuge verkauft werden���� (ich nehme wieder die Beispieldaten von der Firma�� Trudelflug) und daneben habe ich eben Plandaten���� die ich vergleichen will wo ich so eine h��bsche�� Grafik haben will wie hier unten. Eigentlich das���� einfachste auf der Welt, und das ganze dann auch�� noch nat��rlich dynamisch ��ber mehrere Jahre und���� so weiter was dabei das Problem ist erkl��re ich am�� besten mal mit einem Blick auf die Tabellenansicht���� das hier ist unsere Planungstabelle und da sieht�� man schon: geplant wird nat��rlich auf der Ebene���� des Jahres es gibt einen Wert f��r den Jahr f��r�� das Jahr und einen Wert f��r die Produktkategorie���� jeweils immer eine Zahl logischerweise, weil�� niemand Lust hat, auf der Ebene des einzelnen���� Produkts und auf den einzelnen Tag zu planen!�� Also wir haben immer Plandaten und Istdaten���� einer anderen Granularit��t klar dann wenn wir�� uns mal die ist Faktendaten ansehen, dann dann���� geht's dann nat��rlich um ein einzelnes Datum und�� um ein einzelnes Produkt nat��rlich nur durch eine���� ID dargestellt okay und wie sieht man wie l��st man�� das jetzt nat��rlich ��ber Beziehungen wie so vieles���� im Leben l��st man das ��ber Beziehungen. Eine�� m��gliche L��sung habe ich hier an der Stelle���� und zwar zwischen der Datumstabelle und der�� Plantabelle es gibt ja in beiden ein Jahr���� logischerweise es gibt eine Datumstabelle die eine�� Liste aller Datumswerte hat und da ist nat��rlich���� auch eine Jahrespalte drin und genauso in der�� Plantabelle, und dazwischen habe ich einfach���� eine Beziehung gemacht ich gehe mal auf die�� Details und dann sieht man die ganze schmutzige���� Wahrheit n��mlich es handelt sich um eine m zu N�� Beziehung, und wenn ich sowas mache - das h��rt���� sich schon schief an finde ich - dann kriege ich�� hier sogar noch eine Warnung dar��ber dass ich die���� doch bitte nicht benutzen soll und nachdem ich�� das mal in einem Video vorgestellt habe bekam���� ich sogar gesagt, das sei ja eine gruselige�� L��sung ja ich gebe zu das ist gruselig aber���� es funktioniert halt und es muss eben sein wenn�� ich auf der auf beiden Seiten doppelte Werte habe���� nat��rlich habe ich in der plantabelle kommt Malin�� Jahr mehrfach vor und nat��rlich habe ich in der���� datumstabelle logischerweise ein Jahr vielfach�� vielfach wiederholt und deswegen muss ich m:n���� machen und damit ��berhaupt noch was funktioniert�� muss ich die kreuzfilterrichtung hier auf einzeln���� stellen so dass Datum faktPlan eben dann filtern�� kann also schmutzig aber funktioniert und die���� Schwierigkeiten kommen meistens erst dann wenn�� man z.B Sicherheit auf Zeilenebene macht oder wenn���� man DAX Statements schreibt die diese Beziehung�� benutzen ich habe es aber der Einfachheit halber���� und besser zeigen zu k��nnen mal hier drin gelassen�� ich will es aber auch besser machen besser machen���� m��chte ich die Beziehung zwischen Plandaten und�� Produkt es gibt jetzt auch ein Produkt ja eine���� Produktkategorie und hier gibt's eine also ich�� k��nnte einfach ganz schmutzig hier auch so eine���� m:n Beziehung machen nein nein nein diesmal nicht�� die richtige Beziehung wenn man sie baut m��sste ja���� zur Produkt ID gehen weil das das Schl��sselfeld�� ist aber ich habe nun mal nicht geplant auf der���� Ebene der Produkt ID also habe ich mir einen Trick�� ausgedacht mit Dax und auf dieses Statement hier���� bin ich relativ stolz das ist eine berechnete�� Spalte und was die macht das zeige ich am besten���� einfach hier in der Tabellenansicht ich lasse mir�� n��mlich wenn ich jetzt mal in die Plandaten schaue���� lasse ich mir f��r jede Produktkategorie einfach�� die kleinste dazugeh��rige produktd ausrechnen���� man k��nnte auch die gr����te nehmen ist v��llig egal�� aber ich hole mir die produktid von einem Produkt���� was in der Kategorie ist z.B das Produkt mit der�� ID 1 ist offensichtlich in der Kategorie Gleiter���� drin und 1 ist die kleinste ID dabei, das hei��t�� ich habe hier eine berechnete produktid und die���� k��nnte ich doch direkt mit der produkttabelle�� verbinden w��re das nicht super ich probiere���� es einfach mal aus ist ja nicht so schwierig hier�� habe ich meine minimale produktid und die verbinde���� ich jetzt einfach mit der produktid hier und das�� sieht doch schon mal gut aus halt das ist jetzt���� jetzt keine viele zu eins ja doch genau perfekt so�� h��tte ich gerne diese Beziehung wunderbar oh und���� dann bekommt man aber eine ringabh��ngigkeit eine�� circular dependency und er sagt nee mein lieber���� so kannst du die Beziehung nicht herstellen�� tja der merkt einfach dass ich nat��rlich hier���� in meiner vermeintlich genialen Berechnung mich�� nat��rlich auf die Tabelle dimProduct beziehe oder���� dimProdukt und das dann mit der Beziehung�� ja logischerweise eine ringabh��ngigkeit���� ja erzeugt wird wie kann man das jetzt l��sen ohne�� irgendwas am Datenimport zu ��ndern dazu habe ich���� eine ganz nette L��sung wie in jeder guten kochshow�� schon mal vorbereitet der Trick ist dass ich eine���� br��ckentabelle brauche zwischen meinem Platen und�� den Produktdaten direkt verbinden haben wir gerade���� eben gesehen konnte ich sie nicht also brauche�� ich dazwischen eine br��ckentabelle wie soll die���� aussehen klar in der tabellensicht wird das klar�� hier sieht man die enth��lt jede Kategorie einmal���� und dann immer die kleinste produktid dazu und�� wie man das berechnet das kann man hier in diesem���� kleinen summarize-Befehl sehr sch��n sehen ich�� diese Tabelle muss ich also ��berhaupt nicht bauen���� sondern sie ist berechnet die wird quasi bei jedem�� mal aktualisieren automatisch neu berechnet und���� mit so einer k��nstlichen br��ckentabelle kann man�� dann eben diese m zun Beziehung die ist ja w��re���� zwischen Produkt und Plan die kann ich einfach�� aufl��sen durch zwei ganz vern��nftige Beziehungen���� zum einen die hier logischerweise diese minimale�� produktid die geht hier r��ber zum Plan und auf der���� anderen Seite kann ich die produktid auch hier mit�� der produkttabelle verbinden so rum funktioniert���� einzige Einschr��nkung bitte darauf achten das geht�� nur dann wenn man hier die kreuzfilterrichtung in���� beide Richtungen erlaubt und auch hier muss ich�� zugeben ja ��h hier bekommt die L��sung etwas extra���� Komplexit��t ist zwar leicht zu machen aber wie�� gesagt bei daxberechnungen die darauf passieren���� oder eben bei sicherheit auf zeilenebene k��nnte�� das noch ein bisschen schwieriger werden aber���� so funktioniert es dann eigentlich ganz prima und�� es irritiert auch meine Nutzer nicht denn wie man���� hier sieht habe ich diese Tabelle ausgeblendet die�� sieht er also nicht nur die Beziehungen helfen ihm���� wenn er eben Analysen macht und funktionieren�� tut's eben wirklich voll und ganz hier sieht���� man Umsatzzahlen Planzahlen die jeweils immer�� unterschiedlich sind sehr sch��n nebeneinander���� dargestellt werden k��nnen und auch ��ber die Jahre�� hinweg beide dynamisch funktionieren das w��re also���� die die dritte L��sung des guten alten Problems�� ��ber das ich jetzt schon ein Video gemacht habe���� wie gut euch die L��sung gef��llt k��nnt ihr mir�� ja gerne in den Kommentaren mitteilen aber ohne���� ein kleines Fazit von mir kommt ihr aus diesem�� Modell nicht raus ihr merkt also Modellierung���� ist super wichtig egal ob Power bi oder fabric da�� muss man einfach die grauen Zellen anwerfen eine���� KI daf��r gibt es noch nicht das Grundproblem ist�� glaube ich klar es trifft vor allen eben bei ist���� und Plandaten auf weil die in unterschiedlichen�� Ebenen vorliegen und nicht so einfach miteinander���� verbunden werden k��nnen klar kann man dar��ber�� dazwischen Beziehungen herstellen und wir haben���� heute allein zwei Varianten gesehen wie man das�� machen kann damit es eben trotzdem funktioniert���� und diese M��glichkeiten haben vor und Nachteile�� das h��ngt vor allem daran welche Skills man hat���� was man n benutzen kann ob man z.B so wie ich�� jetzt heute mit DAX arbeite ist man eher ein���� sqlritter dann muss man gucken dass man in der�� Datenquelle mit SQL einiges machen kann kann���� man M, also powerquery, das ist ja eigentlich�� die Script Sprache M, dann kann man das Ganze���� im powerquery machen und je nachdem sollte man�� einfach auch danach entscheiden ob der Report���� Bauer der also nachher den Report benutzt damit�� m��glichst wenig Schwierigkeiten hat deswegen habe���� ich ja auch ein paar Tabellen ausgeblendet damit�� er meine vielleicht komplizierte Modellierung���� ��berhaupt nicht sieht nat��rlich gibt's Performance�� Auswirkung ist ja vollkommen klar manches wird in���� memory gemacht anderes wird auf der Platte�� gemacht und so weiter das sollte man sich���� mal bei gr����eren Datenmengen auf jeden Fall�� angucken, aber: Leute, Leute, macht euch keinen���� Kopf, ihr m��sst nicht erst gro��e Fachb��cher lesen�� und Pauken um vielleicht das richtige Modell in���� power bi herzustellen grunds��tzlich gilt wer�� einfach die korrekten Zahlen liefert der hat���� recht und in diesem Sinne munter losprobiert�� mit der Modellierung, und: danke f��rs Zuh��ren! [Musik]