Als Abonnent meines Newsletters erhältst Du die Beispieldateien zu den Beiträgen dazu. Hier geht’s zum Abonnement des Newsletters!

DIE PROBLEMSTELLUNG

Die folgende Abbildung beschreibt die Problematik besser, als ich es mit Worten könnte. Die Obere Visualisierung zeigt 5 Produktverkäufe, jeweils in einer kumulierten Life-to-date Sicht, also den kumulierten Abverkauf seit Produkteinführung. Da die Produkte alle zu unterschiedlichen Zeitpunkten eingeführt wurden, beginnen die jeweiligen Grafen an unterschiedlichen Punkten auf der X-Achse. Genau dies „heilt“ die untere Grafik.

Die Lösung kannst Du wie immer meinem Video entnehmen 

LÖSUNGSVIDEO

Danke für Dein Interesse und bis zum nächsten Mal. Denk dran: Sharing is caring. Wenn Dir der Beitrag gefallen hat, dann teile ihn gerne. Falls Du Anmerkungen hast, schreibe gerne einen Kommentar, oder schicke mir eine Mail an lars@ssbi-blog.de

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag Produktverkäufe ab dem ersten Verkaufstag vergleichen erschien zuerst auf THE SELF-SERVICE-BI BLOG.

Als Abonnent meines Newsletters erhältst Du die Beispieldateien zu den Beiträgen dazu. Hier geht’s zum Abonnement des Newsletters!

DIE PROBLEMSTELLUNG

Den prozentualen Umsatzanteil eines jeden Kalendermonats am Gesamtjahr zu ermitteln ist mittels DAX nicht schwer, funktioniert jedoch vollkommen anders, als Excelnutzer dies gewohnt sind. Etwas komplexer wird es zudem, wenn man in seiner Kalendertabelle eine Sortierspalte nutzt, die es erlaubt, den Monat chronologisch zu sortieren, anstatt alphabetisch.

Die Lösung kannst Du wie immer meinem Video entnehmen 

LÖSUNGSVIDEO

Danke für Dein Interesse und bis zum nächsten Mal. Denk dran: Sharing is caring. Wenn Dir der Beitrag gefallen hat, dann teile ihn gerne. Falls Du Anmerkungen hast, schreibe gerne einen Kommentar, oder schicke mir eine Mail an lars@ssbi-blog.de

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag So kalkulierst Du prozentuale Anteile vom Ganzen in DAX erschien zuerst auf THE SELF-SERVICE-BI BLOG.

Als Abonnent meines Newsletters erhältst Du die Beispieldateien zu den Beiträgen dazu. Hier geht’s zum Abonnement des Newsletters!

Die Zielstellung

Für mein heutiges Praxisbeispiel möchte ich meinen Umsatz je Alterklasse der Kunden zum Zeitpunkt des Kaufes ausweisen. Da ich in meinem analytischen Datenmodell Umsätze potentiell über viele Jahre auswerten möchte, ergibt es keinen Sinn, das Kundenalter als Differenz des heutigen Datums zum Geburtstag des Kunden vorzunehmen. Damit mein Bericht eine nutzbare Aussage hat, muss ich das Kundenalter als Differenz aus dem Kaufdatum uns des Geburtstags kalkulieren.

Wie stelle ich das in Power BI am besten an?

Die Ausgangssituation

Als Basis für meine Auswertung dient folgendes Datenmodell. Ich habe eine Kundentabelle, die lediglich zwei Datensätze beinhaltet. Die Umsatztabelle verfügt über 8 Umsätze, jeweils vier von Kunde 1 und vier von Kunde 2.

Ein erster Ansatz, um aus diesem Datenmodell heraus eine Bericht zu erstellen, der den Umsatz nach dem Alter analysierbar macht, könnte wie folgt aussehen.

Ein erster Lösungsansatz

Da es sich beim Alter des Kunden um ein Merkmal einer Dimension (der Dimension Kunde) handelt, könnte ich jetzt auf die Idee kommen, wie in meinem letzten Beitrag über Slowly Changing Dimensions beschrieben, über den Import- und Transformationsprozess die Kundentabelle anzupassen und über einen sog. SurrogateKey mit der Umsatztabelle zu verknüpfen. Da sich das Alter des Kunden jedoch einmal pro Jahr ändert, ist das nicht die Vorgehensweise, die ich hier darstellen möchte. Stattdessen möchte ich zunächst der Umsatztabelle eine neue Spalte hinzufügen, die das Alter des Kunden zum Zeitpunkt des Kaufes ausweist.

Dafür gehe ich wie folgt vor…

Zusammenführen von Umsatz- und Kundentabelle

Ich sorge in Power Query dafür, dass ich das Kundenalter zum Zeitpunktes des Kaufes in der Umsatztabelle kalkulieren kann. Dafür führe ich einen Join zwischen der Umsatz- und der Kundentabelle aus und hole mir das Geburtsdatum des Kunden so in die Umsatztabelle.

Mit dem Geburtsdatum in der Faktentabelle, bin ich nun in der Lage, für jeden einzelnen erzeugten Umsatz (also für jeden Datensatz in der Umsatztabelle), das Alter des Kunden zu ermitteln.

Kalkulation des Alters als Spalte in der Umsatztabelle

In einem weiteren Schritt berechne ich das Alter des Kunden zum Zeitpunkt des Kaufes in einer weiteren berechneten Spalte. Die Formel für die berechnete Spalte kannst Du dem folgenden Screenshot entnehmen.

Da ich lediglich das Alter, nicht aber das Geburtsdatum in der Umsatztabelle benötige, lösche ich die Spalte Geburtstag anschließend.

Die Zwischenlösung

Mit den nun vorliegenden Tabellen und dem darauf basierenden Datenmodell, kann ich nun folgende Visualisierung erstellen.

In der vorliegenden Tabelle kann ich beispielsweise sehen, dass Gabi Schulze im Alter von 28, 43, 48 und 63 Jahren bei mir gekauft hat. Diese Darstellung ist mit jedoch zu granular. Für meine Analyse reichen mir Altersintervalle von beispielsweise 5, oder 10 Jahren. Ich zeige Dir, wie ich das angehen würde.

Ein optimierter Lösungsansatz

Natürlich könnte ich die Altersintervalle als weitere Spalte(n) in die Umsatztabelle schreiben. Jedoch wäre das u. a. für die Übersichtlichkeit beim Nutzer suboptimal. Daher wähle ich den Ansatz einer weiteren Tabelle für die Altersklassifizierungen.

Erweiterung des Datenmodells um die Tabelle Altersklassifizierung

Es ist sinnvoll, eine neue Tabelle mit ins Spiel zu bringen: die Tabelle Altersklassifizierungen. Den Inhalt und die Struktur der Tabelle, siehst Du auf der rechten Seite des nachfolgenden Screenshots:

Die zuvor in die Umsatztabelle integrierte Spalte Alter dient nun als Schlüssel für die Beziehung zwischen der Umsatztabelle und der Tabelle Altersklassifizierung. Die Spalten 5-Jahresintervall und 10-Jahresintervall können nun beispielsweise in einer Matrix genutzt werden, um den Umsatz wie folgt darzustellen:

Bis zum nächsten Mal und denk dran: Sharing is caring. Wenn Dir der Beitrag gefallen hat, dann teile ihn gerne. Falls Du Anmerkungen hast, schreibe gerne einen Kommentar, oder schicke mir eine Mail an lars@ssbi-blog.de

Viele Grüße aus Hamburg,

Lars

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag Das Kundenalter zum Zeitpunkt des Kaufes ermitteln erschien zuerst auf THE SELF-SERVICE-BI BLOG.

• Power Pivot (in Excel 2010 noch PowerPivot (ohne Leerzeichen)),
• Power Query
• Power View
• Power Map (seit Excel 2016 Microsoft 3D Maps genannt)

In dieser Episode erzähle ich ihre Geschichte und erläutere wofür diese Werkzeuge im Einzelnen da sind und auch, wofür sie nicht da sind.

Links

Welche Office-Version beinhaltet eigentlich Power Pivot?

Das Team hinter Power BI: Jeffrey Wang

Download Power Pivot für Excel 2010

Download Power Query für Excel 2010 und 2013

Offizielle Microsoft Power Query Website

Power View DEMO von Amir Netz, (Start ab 21:05)

Wie Du Power View unter Excel 2016 aktivierst (von Dominik Petri)

Warum Power View in Excel in O365 nicht mehr funktioniert

3D Maps-Beispieldaten

Transkript

Du hörst den SSBI-Podcast, den deutschen Podcast zum Microsoft Power BI. Mein Name ist Lars Schreiber.

Begrüßung

Ein fröhliches Moin aus Hamburg und herzlich willkommen zur Episode Nummer eins des SSBI-Podcast. Ich freue mich sehr, dass du eingeschaltet hast. In der Season Nummer eins dreht sich alles darum, was die Power BI-Plattform ist, und was sie für dich in Bezug auf deine Datenanalyse tun kann. Und die heutige Episode dreht sich darum, was sind die Power BI-Tools in Excel? Was sind Power Pivot, Power Query, Power View und Power Map, die mittlerweile 3D Maps heißen? Was können sie für dich in deiner täglichen Arbeit tun? Ich werde dabei auf die Historie der Tools eingehen, werde erklären, welche Aufgaben die Tools im Einzelnen übernehmen und auch, wie sie miteinander interagieren, wenn es um den Aufbau eines analytischen Werkzeugs in Excel geht. Danach werde ich darüber sprechen, wofür diese Tools meiner Meinung nach explizit NICHT geeignet sind. Ich erlebe es immer wieder in persönlichen Gesprächen oder lese es teilweise auch in Fachartikeln, dass an diesen Tools fehlende Merkmale bemängelt werden, die meiner Ansicht nach in diesen Tools auch überhaupt nichts verloren haben. Bevor ich jetzt darauf eingehe, was die Power BI-Tools in Excel im Einzelnen sind, ist es sicherlich sinnvoll, sich an dieser Stelle zwei Fragen zu stellen. Zum einen: „Was ist Business Intelligence überhaupt?“ Und zum anderen: „Warum hat Microsoft damit begonnen, Werkzeuge für Business Intelligence in Excel zu integrieren?“

Was ist Business Intelligence?

Für die Frage danach, was Business Intelligence per Definition ist, gibt es sicherlich viele unterschiedliche Erklärungen. Ich versuche es, an dieser Stelle jedoch einfach unkompliziert zu halten. Unter Business Intelligence kann man Methoden und Technologien verstehen, die es ermöglichen, aus der Vielzahl an Daten, die sich mittlerweile in Unternehmen befinden, Informationen abzuleiten, entscheidungsrelevante Informationen abzuleiten, die es entsprechend Entscheidungsträgern ermöglichen, Handlungen in Gang zu setzen, die das Unternehmen in die richtige Richtung führen.

Warum Business Intelligence in Excel?

Ich denke, die Frage danach, warum Microsoft solche BI-Tools in Excel implementiert hat, ist etwas vielschichtiger zu beantworten. BI-Tools existieren ja schon seit ewigen Zeiten, mit Sicherheit die letzten 30 Jahre, so dass viele Fachabteilungen Konsumenten von BI-Lösungen geworden sind über die Zeit. Diese BI-Tools waren im Normalfall in der IT beheimatet, dass heißt, die IT hatte die technische Obhut über diese Tools und hat eben diese Reports auch erstellen müssen, mit Sicherheitskonzepten versehen müssen, und sie dann den entsprechenden Konsumenten zur Verfügung gestellt. Das hat große Vorteile, denn solche Tools zu erstellen, erfordert ein hohes, spezialisiertes Fachwissen, die Daten zu sichern, und dafür zu sorgen, dass sie nicht in falsche Hände geraten ebenso. Und das ist häufig sehr kritisch für Unternehmen, dass das eben vernünftig gehandhabt wird. Auf der anderen Seite haben solche Tools aber auch große Nachteile, nämlich Flexibilität. Flexibilität ist ein großes Problem. Fachbereiche müssen Analysen fahren für Vorgesetzte, für andere Stakeholder, und diese Anforderung an die IT-Abteilung zu stellen und zu sagen: „Implementiere mir diese Reports in eure professionellen BI-Tools“ stößt häufig an Grenzen, weil die Mitarbeiter eben ausgelastet sind, weil dafür keine Kapazitäten da sind und dergleichen. Und das hat dann in der Vergangenheit in regelmäßigen Abständen immer wieder stattgefunden, auch wenn es niemand wirklich hören möchte. Solche Lösungen wurden händisch auf Umwegen in Excel erstellt mit den Möglichkeiten, die Excel eben zur Verfügung gestellt hat, mit S-Verweisen, mit Pivot-Tabellen, mit VBA-Skripten und dergleichen. Und Microsoft hat darauf reagiert und gesagt: „Okay, wir geben dem Datenanalysten, dem Controller, dem Vertriebsmitarbeiter, dem Marketingmitarbeiter Werkzeuge an die Hand, die es ihm, respektive ihr, ermöglichen, solche Tools selbst zu erstellen.“ Natürlich in einem viel kleineren Umgang, und natürlich auch nicht dafür gedacht, für das komplette Unternehmen ausgerollt zu werden. Aber, um die Bedarfe einer einzelnen Person, einer einzelnen Abteilung abdecken zu können. Das Ganze lief dann unter dem Label „Self-Service BI“, also Selbstbedienungs-Business Intelligence. Der Fachanwender sollte in der Lage sein, solche Lösungen selber zu bauen. Das bedeutet, all diese sich wiederholenden Tätigkeiten, die man meistens-, die ich zumindest in meiner Controlling-Tätigkeit Monatsabschluss für Monatsabschluss wiederholt habe, externe Datenquellen in Excel importieren, händisch oder per Makro, dann Spalten hinzufügen, zu einem Datum den Monat hinzufügen, Zwischenergebnisse herausfiltern, und dann schlussendlich irgendwann eine Pivot daraufsetzen, all das geschah, bevor die analytische Arbeit stattgefunden hat. Das war notwendig, dass die Analyse stattfinden konnte. Und jetzt gab Microsoft mit Power Pivot und den anderen BI-Tools in Excel einem Fachanwender zumindest die theoretische Möglichkeit, dass selber zu bauen. Natürlich müssen dafür all die Fähigkeiten erlangt werden, die es benötigt, um das tun zu können, aber man hatte die Möglichkeit, weil man die Tools dazu auf seinem Rechner hatte. Mit der Excelversion 2010 hat Microsoft dann damals reagiert und ihr Motto „BI for the masses“, also Business Intelligence für Jedermann, in Angriff genommen, indem sie ein Add-In veröffentlicht haben, dass damals kostenlos downzuloaden war, dass sich Power Pivot nannte. Und das konnte man mit Excel 2010 einfach, wie jedes andere Add-In auch, installieren und aktivieren und nutzen. Kann man heute im Übrigen immer noch, also in Excel 2010, nicht in moderneren Versionen. Und als ich das damals in 2011 das allererste Mal machte, also es installierte, hatte ich zugegebenermaßen keinen Schimmer, worum es dabei ging. Ich habe damals noch für eine Unternehmensberatung gearbeitet und wir haben das interne Reporting über Pivot-Tabellen aufgebaut, also Standard-Excel-Pivot-Tabellen, die auch Access-Datenbanken gingen und so nach fünf Millionen Datensätzen machte dann irgendwann der Pivot-Cache die Grätsche, und ich war auf der Suche nach einer Pivot, die mehr leisten konnte. Und da tauchte irgendwie Power Pivot auf. Dass es sich dabei um etwas komplett anders handelte als um eine Pivot oder gar eine große Pivot, dass habe ich dann so über die nächsten Wochen und Monate gelernt. Was ist Power Pivot hintergründig tatsächlich?

Was ist Power Pivot?

Bei Power Pivot handelt es sich um eine sehr leistungsstarke, sehr schnelle analytische Datenbank, sogenanntes OLAP, online analytical processing. Sollte man nicht verwechseln mit relationalen Datenbanken, die für OLTP gedacht sind, also für operative Systeme. Es gibt hier wirklich darum, meistens Vergangenheitsdaten, aber unveränderliche Daten zu analysieren. Ich glaube, die großen Stärken von Power Pivot lassen sich in den folgenden Punkten zusammenfassen. Wenn man heutzutage in Unternehmen Daten analysiert, Big Data ist ja so ein Buzzword geworden, ob nun big oder nicht big, auf jeden Fall hat man häufig Daten zu analysieren, die aus verschiedensten Datenquellen kommen. Also, man hat csv-Dateien, die als Austauschformat aus irgendwelchen ERP-Systemen geliefert werden. Man hat Excel höchstwahrscheinlich, man hat vielleicht relationale Datenbanken, Access, einen SQL-Server und dergleichen, und vielleicht möchte man auch noch Daten aus dem Internet ziehen. Auf jeden Fall sind die Datenquellen sehr divers, und über Power Pivot war es möglich, diese Datenquellen, diese unterschiedlichen Datenquellen anzuzapfen und in die Exceldatei zu importieren. Bei Imports sind wir auch schon an der richtigen Stelle. Während ich in Excel in einem Tabellenblatt die Möglichkeit habe, so roundabout eine Million Datensätze zu importieren und diese zu analysieren, gab es in Power Pivot auf einmal keine gesetzte physische Grenze mehr. Es gab keinen Richtwert wie „Du kannst eine Million, zwei Millionen, zehn Millionen Datensätze importieren.“ Die Anzahl der Datensätze, die ich verarbeiten kann, hängen direkt mit dem RAM zusammen, der auf meiner Maschine installiert ist, und mit der Bitversion, meiner Excelversion oder meiner Office-Version, 32 Bit oder 64 Bit. Darauf komme ich nachher noch zu sprechen. Aber, wenn ich 64-Bit Office installiert hatte, und über ausreichend RAM auf meinem Laptop zur Verfügung hatte, dann gab es quasi keine physische Grenze, die man zu berücksichtigen hatte. Ja, also es ist möglich, 400, 500, 600 Millionen Datensätze in eine Datei zu packen, in eine Exceldatei, und diese zu analysieren. Damit war man natürlich in der Lage, viel, viel detailliertere Analysen vorzunehmen. Neben den riesigen Datenmengen, die über Power Pivot jetzt also analysierbar waren, wir sind also weit an der eine Million Zeilengrenze vorbeigeschrammt, ist es zudem auch möglich, Datenmodelle zu bauen. Ich muss also nicht mehr auf einer flachen Tabelle analysieren, wie ich das in Excel immer getan habe, sondern ich bin jetzt in der Lage, komplexe Datenmodelle zu erstellen, also verschiedene Tabellen, die über Beziehungen miteinander verknüpft sind, zu nutzen, um meine Analysen zu erstellen. Das bietet einen ungeheuren Mehrwert, wenn man seine Unternehmensdaten analysieren möchte. Hinzu kommt, dass Power Pivot eine neue Sprache mit sich gebracht hat. Power Pivot brachte die Sprache DAX mit, und DAX steht kurz für „Data Analysis Expressions“, die trat eben in Power Pivot 2010 das erste Mal auf. Und DAX ist eine hochkomplexe Sprache, um analytische Datenbanken abzufragen und sogenannte „Measures“ zu erstellen. Measures, die es mir ermöglichen, meinem Datenmodell eine Businesslogik mitzugeben und entsprechend zu analysieren. Das klingt hochgestochen, ich gebe gleich mal ein praktisches Beispiel. Wenn ich in der Lage sein möchte, meine Unternehmensdaten nach Zeit zu analysieren, dann kann ich sagen: „Gib mir die Daten für Januar, gib mir die Daten für Februar, gib mir die Daten für März.“ Und wenn ich diese Daten aber nicht als Einzelmonate haben möchte, sondern beispielsweise als kumulierten Jahreswert, oder auf Englisch year to date, dann muss ich in Excel oder auch in allen relationalen Datenbanken, mir diese Logik künstlich aufbauen. In Power Pivot bin ich in der Lage, über sogenannte Time Intelligence-Funktionen, dass sind spezielle Funktionen von DAX, zu sagen: „Gib mir den year to date-Wert“, und wenn ich dann auf den Filter für März klicke, dann gibt er mir die Werte nicht für März, sondern bis März. Und wenn ich feststelle, dass mein Geschäftsjahr gar nicht im Januar beginnt, sondern zu einem anderen Zeitpunkt, beispielsweise im November, dann würde er mir die Werte von November bis März geben. Also, ich bin in der Lage, eine solche Logik aufzubauen. Und das ist ein ungeheurer Mehrwert, wenn man seine Daten analysieren möchte. Das ist natürlich nur ein kleiner Bereich, ein kleines Beispiel dafür, was mit DAX möglich ist. Und an dieser Stelle kommt halt zum Tragen, dass es sich bei Power Pivot um eine sogenannte „In-Memory-Datenbank“ handelt. Zu Beginn, wenn die Daten-, wenn die Datei geöffnet wird, wenn die Daten geladen werden, werden sie in den RAM geladen, und dass ermöglicht ungeheure Verarbeitungsgeschwindigkeiten. Es muss nicht mehr von der Festplatte gelesen werden, sondern aus dem RAM. Der hat viel höhere Zugriffsgeschwindigkeiten. Das macht es möglich, eben so große Datenmengen zu analysieren auf einem Endgerät wie einem Laptop. Man braucht keine großen Server mehr. Der letzte Vorteil, den ich jetzt erwähnen möchte, ist, was ist denn, wenn sich die Datenbasis ändert? Es kommt der nächste Monatsabschluss, es sind neue Daten im System, was mache ich dann? Ja, für gewöhnlich bin ich dann in Excel wieder herangegangen und habe den Prozess vollzogen, den ich jeden Monat vollzogen habe. Neue Daten wieder ins System, alle händischen Schritte wieder von vorne, oder wenn ich fortgeschritten war, klicke auf „Run“ und mein Makro, dass ich mir mühselig zusammengebaut habe über die letzten Monate, fing an zu laufen. Mit Power Pivot ist das anders. Habe ich mein Datenmodell auf Basis der externen Daten einmal erstellt und alles ist richtig, kann ich, sofern sich die Datenbasis im Hintergrund geändert hat, die Exceldaten, die Datenbanken et cetera, in meiner Exceldatei in Power Pivot einfach auf „Aktualisieren“ klicken. Dann gehe ich mir einen Kaffee holen, und wenn die Daten importiert sind, kann ich anfangen, zu analysieren. Das heißt, ich baue nachhaltige Analysetools, nachhaltige Analysewerkzeuge, die, wenn ich sie einmal erstellt habe und die Zeit investiert habe, danach einfach laufen, sofern sich natürlich die Datenbasis strukturell nicht verändert hat. Aber das ist mit jedem System dieser Welt der Fall.

Worauf muss ich achten, wenn ich Power Pivot verwenden will?

So, ich hoffe, ich habe bis hierher vernünftige Überzeugungsarbeit geleistet und du fragst dich jetzt, wie kommst du an Power Pivot heran und was hast du dabei zu beachten? Das sind im Wesentlichen zwei Dinge. Punkt Nummer eins ist, wie kommst du an Power Pivot heran? Power Pivot existiert seit der Excelversion 2010. Das heißt, wenn du noch eine ältere Version als 2010, also 2007 und abwärts, dein Eigen nennst, dann muss ich dich leider enttäuschen. Du musst auf eine Version gehen, die mindestens 2010 heißt. Wenn du die Version 2010 hast, dann habe ich gute Neuigkeiten für dich. Dann ist Power Pivot nach wie vor ein kostenfrei downzuloadendes Add-In. Das kannst du einfach mal googeln, wo du das findest und kannst dann, je nach der Bitigkeit deiner Excelversion, also 32 oder 64 Bit, die entsprechende Version von Power Pivot herunterladen und eben für dich installieren. Ist kostenfrei, lege einfach los. Wenn du eine Excelversion hast, die zwischen 2013 und 2016 liegt, dann ist die Beschaffung von Power Pivot erheblich komplizierter, denn ab den Versionen hat Microsoft „versucht“, mit Power Pivot Geld zu verdienen und hat verschiedene Lizenzierungsmodelle aufgesetzt, wann welche Version einen Zugriff auf die Entwicklungsumgebung der Excel-Datenmodelle zulässt. Ich habe dazu einen Artikel auf meinem Blog geschrieben, den ich in die Shownotes zu diesem Podcast setzen werde. Da kannst du dir das in Ruhe nochmal durchlesen. Das werde ich jetzt hier nicht wiederholen. Das wäre redundant. Wenn du eine Excelversion >= 2019 dein Eigen nennst, oder Office 365 besitzt, dann kann ich dich beruhigen, dann ist Power Pivot nämlich wieder Bestandteil der normalen Excellizenz. Du brauchst keine besondere Excellizenz, um Datenmodelle in Excel entwickeln zu können. Das ist eine gute Wendung, die Microsoft da in den letzten Jahren hingelegt hat. Darüber können wir uns alle freuen. Der nächste Punkt neben der Lizenzierung ist die Frage nach der Bit-Version, welche Bitigkeit meine Excelversion haben kann. So, und es stehen zur Verfügung 32 und 64 Bit, und 64 Bit entscheidet darüber, dass du nahezu unbegrenzt viel RAM allokieren kannst, während das bei 32 Bit eben leider nicht der Fall ist. Da stehen Excel eben nur 2 Gigabyte zur Verfügung. Mit Excel meine ich die gesamte Excel-Applikation inklusive Power Pivot. Das kann dann bei komplexeren Datenmodellen schon mal knapp werden. Deswegen ist aus dem Gesichtspunkt der RAM-Allokation 64 Bit auf jeden Fall zu empfehlen. Problematisch ist nur, dass das mit verschiedenen anderen Add-Ins in Excel kollidieren kann. Wenn du beispielsweise in SAP BW-Add-In hast, das hat nur eine 32 Bit-Schnittstelle zu SAP. Es gibt keine 64 Bit-Variante davon. Installierst du also 64 Bit Excel und versuchst, dieses SAP-Add-In laufen zu lassen, würde es nicht funktionieren. Das Gleiche wird für viele VBA-Skripte gelten, die du wahrscheinlich auf deinem System hast. Deswegen, wie du das dann organisierst, eine 64 Bit-Version zu haben, vielleicht parallel zu 32 Bit-Versionen, die du für andere Belange benötigst, da musst du schauen, da gibt es verschiedene Variationen. Du kannst dir natürlich virtuelle Maschinen auf deinem Rechner installieren, um beides parallel laufen zu lassen. Wenn du die Möglichkeit hast, auf 32 Bit verzichten zu können, dann tu das und installiere rein weg 64 Bit.

Wofür Power Pivot nicht gedacht ist!

So, und zu guter Letzt möchte ich in Bezug auf Power Pivot nochmal darüber sprechen, was Power Pivot meiner Ansicht nach definitiv NICHT ist. Ich habe vor einer ganzen Weile einen Artikel gelesen, einen deutschsprachigen Fachartikel zum Thema DBI-Tools in Excel, und da war die Rede darüber, dass Power Pivot eine Alternative zu Access sein soll. Also, Power Pivot wäre in Excel implementiert worden, weil viele Nutzer Access nicht im Umfang ihres Office-Pakets haben. Und da muss ich leider erheblich widersprechen, denn diese beiden Tools, Power Pivot und Access, sind Vertreter zweier völlig unterschiedlicher Datenbanktypen, während Access eine sogenannte OLTP-Datenbank ist, die im Wesentlichen zum Ändern von Daten gedacht ist, also für operative Systeme, ist Power Pivot ein Vertreter einer OLAP-Datenbank für Analysen. Das sind zwei sehr verschiedene Datenbanktypen, die natürlich in Teilen leichte Überschneidungen haben können, wenn man das möchte, aber sie sind sehr spezialisiert auf ihren jeweiligen Anwendungsfall. Schon allein deswegen kann diese Aussage nicht stimmen. Was ich dann erlebe, ist, dass Leute kritisieren, dass man Daten, die sich in Power Pivot befinden, nicht mehr ändern kann. Nun, man kann da nicht einfach reingehen und in der Zelle den Wert von 1000 auf 10000 ändern. Das ist wiederum auch kein Anwendungsfall für Power Pivot. Das ist keine Schwäche des Tools, denn es geht darum, unveränderliche Daten zu analysieren. Es soll nicht so sein wie in Excel, dass man eine Datei verschickt, und im selben Report kommen trotzdem unterschiedliche Ergebnisse heraus, weil schnell nochmal der Empfänger der Datei irgendwelche Werte überschrieben hat. Das ist Absicht, dass diese Werte nicht veränderlich sind, damit eben die gleichen Analysen bei unterschiedlichen Leuten herauskommen, oder zumindest die gleichen Werte. Wie man sie dann analysiert, ist ja nochmal ein anderes Thema. Und der Punkt Nummer drei, Power Pivot ist auch kein Tool, um Daten zu exportieren. Ja, es ist verlockend. Da sind jetzt Millionen und Abermillionen von Daten drinnen, und man möchte sie nun auch nochmal anders analysieren, als sie jetzt in dem Datenmodell aufbereitet sind. Also, schnell nochmal als csv-Datei exportieren und dann andere Dinge damit tun. Aber nein, auch das geht nicht. Und auch das hat seinen Grund, denn ist kein Tool für den ETL-Prozess, also schnell nochmal Daten exportieren und weiterverarbeiten, sondern es ist ein Tool für die Analyse, und deswegen sind diese drei Punkte für mich nicht valide. Und Power Pivot macht es an der Stelle exakt richtig.

Was ist Power Query?

So, nachdem ich mich jetzt eine ganze Weile zum Thema Power Pivot ausgelassen habe, wende ich mich jetzt mal meinem favorisierten Power BI-Tool in Excel zu, nämlich Power Query. Wie der Name Query vielleicht vermuten lässt, geht es darum, Daten aus anderen Systemen abzufragen und damit, ja, entweder in meine Exceldatei oder in mein Excel-Datenmodell einzubinden. Die eingebundenen Daten können dann auf vielfältige Art und Weise in ihrer Formatierung, in ihrem Aufbau, in ihrer Struktur verändert werden, so, wie ich es für meine weitere Verwendung, zum Beispiel die Analyse in einem Excel-Datenmodell, benötige. So, und Power Query basiert dabei auf einer anderen Sprache, als es das Excel-Datenmodell tut. In Datenmodell hatten wir DAX, Data Analysis Expressions. Hier haben wir die Sprache M, M wie Mashup. M ist der offizielle Name dieser Sprache, vor einiger Zeit geworden. Er war jahrelang der inoffizielle Name, und das ist eine sehr flexible, funktionale Programmiersprache, die es mir unter anderem auch erlaubt, eigene Funktionen zu schreiben, die dieses Tool dann nochmal flexibler machen. Ich nehme dir aber am Anfang gleich die Angst. Du musst mit M nicht unbedingt in Kontakt kommen, weil Power Query über eine hervorragende UI, ein hervorragendes User Interface verfügt. Du kannst also die wesentlichen Komponenten dieses Tools einfach über die Verwendung der Maus und den Klick auf einzelne Tasten steuern. Mit Power Query bin ich also in der Lage, sehr, sehr viele verschiedene Datenquellentypen zu importieren. Also, sowohl flat files wie csv, txt-Dateien, die ja häufig Austauschformate aus eben beispielsweise ERP-Systemen sind. Xml- und json-Dateien, Exceldateien, relationale Datenbanken wie Access oder Sequel Server, multidimensionale Datenbanken wie Sequel Server Analysis Services. Ja, es gibt nahezu keine Grenzen. Ich kann auf Datenquellen aus dem Internet zugreifen, ich kann Websites parsen und importieren. Wenn die Standardfunktionalität nicht ausreichen, kann ich mir eigene Funktionen schreiben, die das für mich übernehmen. Also, es sind fast keine Grenzen gesetzt. Und wenn diese Daten importiert sind, dann bin ich in der Lage, die Daten in ein Format zu bringen, wie es für meine weitere Verwendung notwendig ist. Das heißt, ich kann gruppieren, ich kann Zeilen und Spalten löschen, ich kann Zeilen und Spalten hinzufügen, ich kann filtern, ich kann pivotieren, ich kann entpivotieren. Auch da gibt es fast keine Grenzen. Und das Schöne ist, ich bilde eine nachhaltige Lösung. Wenn sich meine Datenquelle inhaltlich ändert, nicht strukturell, aber inhaltlich, wenn Datensätze hinzukommen, dann kann ich in Power Query einfach auf „Aktualisieren“ drücken, das gesamte Skript, das ich erstelle, im Hintergrund wird immer ein Skript erstellt in der Sprache M, wird dann wieder durchlaufen und auf Basis der neuen Daten werden all die Schritte, die ich erzeugt habe, wieder durchlaufen und das Ergebnis wird neu produziert. Und das macht das Ganze so flexibel, so großartig. Und ich kann mir dann aussuchen, ob ich die Daten in eine Exceltabelle schiebe, oder ob ich sie in mein Datenmodell lade, in mein Excel-Datenmodell. Und es ist keine Entweder-oder-Frage, ich kann auch beides parallel machen, und kann dann damit anfangen, weiter meine Analysen zu betreiben. An dieser Stelle würde es mich jetzt nicht wundern, wenn du dir die Frage stellen würdest: „Okay, jetzt kann ich meine Daten in mein Excel-Datenmodell sowohl über Power Query als auch über Power Pivot importieren. Welche Variante soll ich denn nehmen, und warum gibt es beide?“ So, und die Antwort darauf, warum es beide gibt, ist relativ simpel. Power Pivot existierte vor Power Query. Und eine Datenbank zu bauen, die nicht in der Lage ist, selbst Daten in sich zu importieren, ist relativ sinnfrei, weil, was mache ich mit einer leeren Datenbank? Aber Power Pivot ist bei weitem nicht so flexibel darin, Datenquellen anzubinden, also weder in der Vielfalt der unterschiedlichen Datenquellentypen, noch in der Möglichkeit, dann Transformationen vorzunehmen. Und da eben nicht jeder Businessuser SQL oder sogar T-SQL schreibt, was so die Standardabfragesprache in Datenbanken ist, hat man eben M entwickelt und eine wahnsinnig gut nutzbare UI vorne daraufgesetzt, dass es eben auch dem Businessuser möglich ist, externe Datenquellen anzubinden und die Daten neu zu strukturieren. Und deswegen lautet die Antwort, „Welches Tool soll ich denn nun dafür nutzen, Daten in mein Excel-Datenmodell zu bekommen? Power Query.“ Das Tool ist extra dafür gemacht worden, und deswegen sollte man auch zusehen, sich das Leben so einfach wie möglich zu machen und Power Query für seine ETL-Funktionalitäten zu nutzen, also Daten aus externen Systemen abzugreifen, neu zu strukturieren und in das Datenmodell zu schieben. Meine Empfehlung an dich ist wirklich, wenn du dich mit Power Query noch nicht auseinandergesetzt hast, tu es, tu es bald, denn dieses Tool ermöglicht dir, irrsinnig viele Prozesse zu automatisieren. Ich habe sehr viel VBA programmiert in meinem Leben, und ich habe viele VBA-Programmierer kennengelernt, und sehr viele Skripte, die ich in VBA schreibe, dienen dem Import und der Transformation von Daten. Und all das kann ich mit Power Query sehr, sehr viel flexibler, auch stabiler selber machen und muss mich dafür nicht irgendwelcher Skripte bedienen. Ja, okay, im Hintergrund wird ein M-Skript erzeugt, aber das macht mir die Sache erheblich leichter.

Wie kommst Du an Power Query heran?

Die Frage, die sich jetzt wahrscheinlich stellen wird, ist, „Wie komme ich an Power Query heran?“ Und die Antwort ist ähnlich wie bei Power Pivot, hast du eine Excelversion, die älter ist als 2010, hast du keine Chance. Hast du Excel 2010 oder 2013, dann kannst du dir Power Query als externes Add-In kostenfrei installieren. Den Link dazu packe ich in die Shownotes. Hast du eine Version, die neuer ist als 2013, also 2016 und jünger, habe ich gute Neuigkeiten für dich. Power Query ist in all diesen Versionen nativ installiert, ist jetzt ein fester Bestandteil von Excel, kein externes Add-In mehr und du solltest es bereits haben. Allerdings versteckt es sich wahrscheinlich besser, denn es heißt jetzt nicht mehr Power Query, sondern es heißt „get and transform“ im Englischen, und ich glaube, „importieren und transformieren“ auf Deutsch. Macht es nicht unbedingt einfacher, danach zu googeln. Ich würde an deiner Stelle weiterhin nach Power Query googeln, aber die Funktionalität ist in Excel enthalten und bleibt da auch drin.

Wofür Power Query nicht gedacht ist!

Wie ich es vorhin auch schon bei Power Pivot gemacht habe, hier auch nochmals kurz zu Power Query, wofür das Tool NICHT gedacht ist. Und hier sehe ich etwas weniger strikt als bei Power Pivot, denn die Funktionalität, die in Power Query leider nicht vorliegt, ist durchaus eine, die man hätte integrieren können, denn es geht um den Export der Daten. Was Power Query von einem traditionellen ETL-Tool unterscheidet, ist, hier sind die Ziele, in die ich die Daten hineinladen kann, bereits vordefiniert. Ich kann bei Power Query in Excel eben nur in ein Excel-Datenmodell oder in ein Excel-Arbeitsblatt laden, bin aber nicht in der Lage, es beispielsweise als csv-Datei zu exportieren. Und es ist durchaus schade, denn an einigen Stellen ist das sehr, sehr nützlich und es wäre sehr sinnvoll, das zu haben, aber das Microsoft-Team hat sich bisher nicht dazu bekannt, das in irgendeiner Form integrieren zu wollen, auch, wenn ich nicht der erste bin, der das nachfragt.

Was ist Power View?

Das dritte Tool, das ich in Rahmen der Power BI-Tools in Excel erwähnen möchte, ist Power View. Power View ist ein Tool für die Erstellung von interaktiven Visualisierungen. Diejenigen von euch, die bereits mit Power BI-Desktop gearbeitet haben, kennen diese Form von interaktiven Visualisierungen, bei denen man ein Visual anklickt, auf Basis eines gewissen Kriteriums Filter setzt und diese Filter sich auf allen anderen Visualisierungen auf derselben Berichtsseite auswirken. Auf diese Art und Weise kann man sogenannte „explorative Datenanalyse“ betreiben. Das heißt, die eigenen Daten erkunden und Zusammenhänge erkennen. Amir Netz, das ist eine der Schlüsselfiguren in der gesamten Microsoft BI-Welt, hat dazu eine Demo im Jahr 204 aufgebaut und auf einer Konferenz vorgestellt, bei der er die Billboard-Charts mit Power View analysiert, deren Entwicklung zeigt und das auf sehr unterhaltsame Weise darstellt. Die Demo ist für mich ganz großes Kino, und ich werde den Link dazu mal in die Shownotes packen. Wenn du dich für Power View interessiert, dann fragst du dich, wie du es bekommen kannst, und sofern du eine Excelversion älter als 2010 nutzt, also 2013 und aufwärts, kannst du die Office Professional Plus-Version oder eine Standalone-Version von Excel 2013 nutzen, um an Power View heranzukommen. Sofern du Excel in der Version 2016 nutzt, wirst du dich wundern, dass Power View bei dir nicht einfach in der Multifunktionsleiste auftaucht. Microsoft hat irgendwann angefangen, die Schaltfläche für Power View per default auszublenden. Das war ein gehöriges Signal an die Community, dass diese Technologie nicht weiter in Excel unterstützt wird, also nicht weiterentwickelt wird. Sie ist aber zumindest in 2016 noch vorhanden, und wenn du Power View nutzen möchtest, musst du es über die Option aktiv einblenden. Mein Freund Dominik Petri hat dazu auf seinem Blog einen Artikel verfasst, der beschreibt, wie das funktioniert. Den werde ich auch mit in die Shownotes einfügen. Wenn du eine O 365-Version, also Office 365 nutzt, dann habe ich in Sachen Power View schlechte Neuigkeiten für dich, denn Microsoft hat die selbstentwickelte Technologie Silverlight, die die Basis ist für Power View, anscheinend als bedenklich eingestuft, als Sicherheitsrisiko eingestuft. Auf jeden Fall ist die Nutzung von Silverlight unter Office 365 nicht mehr möglich, so dass Power View, obwohl du es in der Multifunktionsleiste noch findest, nicht mehr nutzbar ist. Du kannst keine Reportseite einblenden, um einen Power View-Report einzustellen. Wenn du diese Technologie nutzen willst, kann ich dir nur DRINGEND empfehlen, auf Power BI-Desktop umzusteigen.

Was ist Power Map?

Als letztes Power BI-Tool in Excel ist Power Map zu erwähnen. Power Map ist ein Add-In für Excel, dass für 3D-Visualisierungen von Geodaten gedacht ist. Sofern ich also in meiner Exceldatei in Form einer Tabelle oder in Form eines Excel-Datenmodells Geodaten vorliegen habe, können diese als 3D-Karte visualisiert werden. Hierbei reichen Ortsnamen, Städte, Länder. Aber, wie immer bei Geodaten, kann ich nur dann sicher sein, dass die jeweiligen Orte oder Lokalitäten in meiner Karte korrekt angezeigt werden, wenn ich mit Längen- und Breitengraden arbeite. Nur so erhalte ich ein perfektes Ergebnis. Diese Daten werden dann anschließend auf einem Erdball dargestellt. Ich kann dabei verschiedene Kartenschichten erzeugen. Das bedeutet, wenn ich beispielsweise Verkaufsstellen habe, die ich auf einer Karte darstellen möchte, kann ich eine Schicht nehmen, die die Verkaufsstellen nach Umsätzen darstellt und eine weitere Schicht, die vielleicht darstellt, in welchen der Verkaufsstellen bereits Raubüberfälle stattgefunden haben und wie häufig. Dann kann ich diese Schichten miteinander kombinieren, übereinanderlegen oder eben auch sequentiell ein- und ausblenden. Das ist ein ganz neckisches Feature. All dies kann anschließend als Film abgespeichert werden. In diesem Film kann ich einen Soundtrack hinzufügen und das ganze sogar anschließend als HD-Video exportieren. Wenn das für dich interessant klingt, möchtest du sicher wissen, wie kommst du an Power Map heran, und dazu ist vielleicht zu Beginn zu erwähnen, dass Power Map mittlerweile als „Microsoft 3D Map“ bezeichnet wird. Nächst hat 2013 hat Power Map das erste Mal das Licht der Welt erblickt und wurde in 2016 in 3D Maps unbenannt. Um dieses Tool zu testen, fehlt es einem häufig selbst an Geodaten. So ging es mir zumindest in der Vergangenheit immer, und Microsoft hat da Abhilfe geschaffen und auf der offiziellen Microsoft-Seite Beispieldaten zum Download zur Verfügung gestellt. Die sind ganz hilfreich, um selber mal zu testen, wie 3D Maps funktioniert. Ich packe den Link mit den Download-Dateien in die Shownotes zu diesem Podcast. Geht in dem Dokument einfach mal ziemlich an das Ende. Oben wird erklärt, wie 3D Maps funktionieren, und ganz am Ende findet ihr die Dateien zum Download.

Verabschiedung

Ja, und das war sie jetzt auch schon, die erste Folge des SSBI-Podcast zu den Themen Power BI-Tools in Excel. Ich hoffe, du fandest es informativ. Ich danke dir für das Zuhören. Wenn es dir gefallen hat, abonniere den Podcast, empfehle ihn weiter, höre das nächste Mal wieder zu. Wenn du Anmerkungen zu meinen Ausführungen hast, immer fleißig unten in die Kommentare auf meinen Blog. Wenn dir irgendetwas gefallen hat, sag Bescheid. Wenn dir irgendetwas nicht gefallen hat, äußere es bitte auch. Konstruktive Kritik ist immer gern gesehen, und ich freue mich auf ein Wiederhören beim nächsten Mal, und wünsche dir bis dahin eine wunderbare Zeit. Viele Grüße aus Hamburg. Lars.

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag Podcast – Die Power BI-Tools in Excel erschien zuerst auf THE SELF-SERVICE-BI BLOG.

• Mastering the CUBE Functions in Excel 2013 by Peter Myers and
• Introduction to MDX for PowerPivot users by Chris Webb.

A customer recently asked me how I can query periods from the Excel data model using entries in cells. What he wanted to achieve should look like this:

From my point of view, the solution presented here can be divided into three sub-steps, which I will show below. You can download my example file from here: Download Example file.

Step #1: Reference date values correctly in CUBE formulas

Referencing a date column of the data model within the CUBEVALUE() function did not initially produce a result for me. I got the following message all the time, when trying a syntax like this:

To find the correct syntax, I created a PivotTable from the data model and converted it into CUBE formulas to see how Excel converts it internally. To do this, follow these steps:

1. Switch to Power Pivot window
2. Create a PivotTable from the data model (press Home → PivotTable)…
3. …in a new Worksheet
4. Drag the field date from the fields pane to the line caption of the PivotTable
5. Put the Measure Sum Values into the values area
6. If the rows of the PivotTable are grouped by years, quarters, … expand at least one year, so that you can see a specific day
7. With the PivotTable selected to Analyze in the ribbon and choose OLAP Tools → Convert to formulas

With the 2nd of January 2008 selected, you can see this formula:

The interesting part of the formula is the one marked red. It shows how a date reference should be used in a corresponding CUBE formula. The correct syntax is thus structured as follows: „YYYY-MM-DDThh:mm:ss„, where the time here always contains zero values. If I want to display the value of my measure „Sum Values“ for January 2nd in a CUBEVALUE() formula, the formula could look like this:

So I know at this point how to correctly reference date values in CUBE formulas. But what about periods?

Step #2: Reference seamless time periods in CUBE formulas

The thing about time periods in CUBE formulas is that I can’t create them in Excel logic (via >=/ <=), but have to resort to another CUBE function: On CUBESET(). Since I am not an MDX person, I explain the behavior of the CUBESET() function, related to my example, with my own non-technical words: It let’s me define a (seamless) time period, which I can send to the data model and let’s me retrieve my measure for this time period. A solution for the period January 1st 2018 to May 1st 2018 could look like this:

While the first parameter of the CUBESET() function is the connection to the data model, the second parameter let’s me specify the period. The colon is particularly important because it defines a time period from the start value (January 1st 2018) to the end value (May 1st 2018). This function now returns correct values, but is not yet linked to the cells in Excel. I’ll take care of that now.

Step #3: Making the CUBE formula refer to cell entries

Linking the CUBE formula to the Excel cells is not very difficult. But you have to pay attention to the correct formatting of the dates and here I have two possibilities:

1. I can correctly format the date in the CUBE formula, or
2. include auxiliary cells.

For didactic reasons I use variant b).

The values in column E refer to the values in column D which are in the ‚ordinary‘ (German) date format which I have to convert to be suitable for the CUBE functions.

I can now reference these auxiliary cells in my CUBESET() function to make the result react on the entries in cells D4 and D5:

I hope this is usefull for one or the other 🙂

Many greetings from Germany,

Lars

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag Query time periods with CUBE formulas in Excel erschien zuerst auf THE SELF-SERVICE-BI BLOG.

Note the yellow cells where the project manager is missing. The pivot table was as follows:

In the pivot table Mike Schuhmacher appeared as project manager, although he was not included anywhere in the data model. Even a refresh of the data model did not change the situation. The only solution was to create a new pivot table. This then showed the expected result:

But I still had no explanation for the result. Suddenly my customer said: „Maybe someone has overwritten the value in the pivot, too.“ And then I learned something about pivot tables that I’ve never seen in the last 11 years I’ve used them:

One empty value was overwritten manually , which automatically replaced all empty values by Mike Schuhmacher. This remained unchanged even after a refresh. I was aware that I could change the column caption of pivots manually, but this behavior was new to me and the solution to the problem was all the more surprising for me. Maybe this is also helpful for one or the other.

Many greetings from Germany and a Merry Christmas and a Happy New Year for you.

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag Pivot shows values that are not part of the excel data model erschien zuerst auf THE SELF-SERVICE-BI BLOG.

Als Abonnent meines Newsletters erhältst Du die Beispieldateien zu den Beiträgen dazu. Hier geht’s zum Abonnement des Newsletters!

Die Ausgangssituation

Die Basis für diese Lösung ist, wie auch im vorangegangenen Beitrag, das folgende Datenmodell:

Da sich Beginn und Ende des Geschäftsjahres verändert haben, muss ich eine kleine Anpassung des Datenmodells vornehmen.

Anpassung der Geschäftsjahresspalte mittels Power Query

Wie schon im letzten Post, muss die Spalte Geschäftsjahr jeden Kalendermonat dem entsprechenden Geschäftsjahr zuordnen. Um dies anzupassen, gehe ich in Power Query in die Abfrage Datum und ändere die Berechnung der Spalte Geschäftsjahr, wie im folgenden Screenshot zu sehen ist:

Basierend auf diesem Datenmodell gilt es nun, ein entsprechendes DAX-Measure zu schreiben, das dem Schaltjahr Rechung trägt.

Die Lösung: Ein DAX-Measure, das dem Schaltjahr Rechnung trägt

Um ein DAX-Measure zu schreiben, das auch bei Schaltjahren den korrekten Year-to-date-Wert kalkuliert, greife ich auf eine Lösung zurück, welche die Kollegen von SQLBI auf ihrer Website DAXPatterns.com als Vorlage erstellt haben. Der folgende DAX-Code kalkuliert den Year-to-date-Wert auch dann richtig, wenn das Geschäftsjahr im Februar endet:

=
CALCULATE (
    SUM ( Umsaetze[Wert] );
    FILTER (
        ALL ( Datum );
        AND (
Datum[Datum] <= MAX ( Datum[Datum] );
Datum[Geschäftsjahr] = MAX ( Datum[Geschäftsjahr] )
        )
    )
)

Auf diese Weise umgehe ich das Problem, dass bei der TOTALYTD()-Funktion im letzten Parameter ein einzelner Wert, als Jahresendwert angegeben werden muss. Dies führt im Falle des Februar zu Problemen, da dieser am 28.02., oder am 29.02. enden kann.

Der Code mag auf den ersten Blick verwirren. So ging es mir zumindest, als ich ihn vor Jahren das erste Mal gesehen habe. Daher widme ich den restlichen Beitrag der Funktionsweise dieses Measures, um ein grundlegendes Verständnis dafür zu erzeugen. Falls Du also „nur“ an einer Lösung Deines Problems interessiert bist und Dich ein tieferes Verständnis dieser Lösung nicht interessiert, dann kannst Du an dieser Stelle aufhören weiterzulesen. Nimm Dir den oben stehenden Code, passe ihn an Dein Datenmodell an und fertig. Falls Du verstehen möchtest, was dieser Code tut, dann schnall Dich jetzt besser an. Es gibt viel zu betrachten.

Die Funktionsweise des Measures verstehen

Meiner Ansicht nach besteht die beste Möglichkeit, dieses Measure zu verstehen darin, es gemeinsam zu entwickeln. Genau dies werde ich jetzt mit Dir machen.

Bei DAX dreht sich alles um Filter

Jedes DAX-Measure wird im Rahmen eines bestimmten, sog. Evaluierungskontextes berechnet. Ein Bestandteil dieses Evaluierungskontextes, ist der sog. Filterkontext. Was darunter zu verstehen ist, kann zumindest oberflächlich einfach beantwortet werden. Schau Dir folgende Pivottabelle an:

Filter in DAX werden immer durch Tabellen definiert. Betrachte ich den rot umrahmten Wert 1.827,00 €, so ist der Filter, der diesen Wert definiert, über drei Spalten im Datenmodell definiert:

• Datum[Geschaeftsjahr] = 2017
• Datum[MonatImKalender] = Mai 2017
• Verkaufsstellen[Verkaufsstelle] = VK01

Diese drei Filterkriterien filtern die Datensätze in den Tabellen Datum und Verkaufstellen ein. Über die im Datenmodell befindlichen Beziehungen wirken sich diese Filter von den beiden Tabellen Datum und Verkaufsstellen auf die Tabelle Umsaetze aus und grenzen damit auch die dort befindlichen Datensätze ein. Visuell kann man sich das wie folgt vorstellen:

Auf diese Art und Weise werden diejenigen Datensätze selektiert, die dann den Wert 1.827,00 € ergeben. Mein Ziel ist jedoch, den durch die Pivottabelle gesetzten Filter auf der Datumstabelle zu verändern. Schließlich soll der entsprechende Wert nicht die Werte des angezeigten Monats (hier Mai) wiedergeben, sondern alle Werte von März bis zum angezeigten Monat. Im aktuellen Fall soll der Filter also wie folgt aussehen:

• Datum[Geschaeftsjahr] = 2017
• Datum[MonatImKalender] = März oder April oder Mai 2017
• Verkaufsstellen[Verkaufsstelle] = VK01

Die einzige DAX-Funktion, die es bewerkstelligen kann, den bestehenden Filterkontext zu überwinden, ist die Funktion CALCULATE(). Ihre Schwesterfunktion CALCULATETABLE() ist hierzu auch in der Lage, soll an dieser Stelle jedoch vernachlässigt werden.

Mit CALCULATE() den Filterkontext überwinden

Damit wäre erklärt, dass CALCULATE() der Schlüssel zum Erfolg ist. Mein erster Ansatz für ein Measure sieht also wie folgt aus:

=
CALCULATE ( SUM ( Umsaetze[Wert] ) )

Setze ich nun dieses Measure in meine Pivottabelle ein, dann sieht das Ergebnis so aus:

Wie Du sehen kannst, ist das Ergebnis immer noch das gleiche. Somit hat diese DAX-Formel (noch) nicht den gewünschten Effekt gebracht. Schauen wir uns doch mal die Syntax von CALCULATE() an:

CALCULATE(<Ausdruck>;<Filter1>;<Filter2>…)

CALCULATE() nimmt einen Ausdruck auf (in meinem Beispiel SUM ( Umsaetze[Wert] ) ) und ermittelt diesen unter Zuhilfenahme diverser optionaler Filterkriterien. Diese Filterkriterien sind der Schlüssel zum Erfolg.

Die Filterkriterien von CALCULATE definieren

Was ich nun erreichen möchte ist das korrekte Definieren der Filterkriterien für die CALCULATE()-Funktion. Die Ausgangssituation hierfür sieht also wie folgt aus:

=
CALCULATE ( SUM ( Umsaetze[Wert] ); Filterkriterien )

Da in meinem Datenmodell zwischen den Tabellen Datum und Umsaetze eine 1:n-Beziehung herrscht (die Linien, die die Tabellen im Datenmodell miteinander verbinden symbolisieren dies) wirkt sich ein Filter auf der Tabellen Datum automatisch auf die Tabelle Umsaetze aus. Meine DAX-Formel muss jetzt folgendes schaffen: Obwohl der Filterkontext (durch die Pivotüberschrift) auf Monat Mai eingrenzt, muss der Filterkontext in meinem Measure März, April und Mai beinhalten.

Um einen entsprechenden Filter in meiner CALCULATE()-Funktion zu erzeugen, nutze ich die Funktion FILTER().

Die Nutzung der Funktion FILTER(), um die Filter in CALCULATE() zu definieren

Die DAX-Funktion FILTER() hat folgende Syntax:

FILTER(<Tabelle>;<Filter>)
Dieser Funktion muss eine Tabelle übergeben werden, die dann entsprechend gefiltert wird.

FILTER() verbindet zwei nützliche Eigenschaften:

1. Es handelt sich um eine Tabellenfunktion. Diese Funktion gibt also eine Tabelle zurück, die dann als Filterkriterum in CALCULATE genutzt werden kann.
2. FILTER() ist zugleich ein sog. Iterator und ist daher in der Lage, auf der Tabelle (erster Parameter) zeilenweise Filteroperationen auszuführen.

Mit der Kenntnis um die Funktion FILTER() und dem Wissen, dass ich auf Basis der Tabelle Datum filtern muss, kann ich meine bisheriges Measure wie folgt erweitern:

=
CALCULATE ( SUM ( Umsaetze[Wert] ); FILTER ( Datum; FILTERKRITERIEN ) )

Die Filterfunktion wird die Tabelle Datum also zeilenweise durchlaufen und nach bestimmten Filterkriterien filtern, die ich bisher noch nicht definiert habe. Diese definiere ich jetzt.

Die Filterkriterien für die Funktion FILTER() definieren

Damit die Funktion FILTER() eine korrekt eingeschränkte Tabelle zurückliefern kann, die für die CALCULATE()-Funktion als Filter dient, müssen nun die Filterkriterien in der FILTER()-Funktion definiert werden. Ich beschreibe zunächst in Worten, wie dies inhaltlich aussehen soll, bevor ich es als Formel definiere:

=
FILTER (

führe alle nachfolgend definierten Filteroperationen zeilenweise auf der gesamten Tabelle Datum aus;
           Monat in der entsprechenden Zeile in Tabelle Datum <= Monat in der Überschrift der Pivot UND
           Geschäftsjahr in der entsprechenden Zeile in Tabelle Datum = Geschäftsjahr (ausgewählt über den Datenschnitt in der Pivot)
)

Verformelt sieht das ganze dann wie folgt aus:

=
FILTER (
    Datum;
    AND (
Datum[MonatImJahr] <= MAX ( Datum[MonatImJahr] );
Datum[Geschäftsjahr] = MAX ( Datum[Geschäftsjahr] )
    )
)

Was an dieser Formel wohl am schwierigsten zu verstehen ist, sind die folgenden zwei Sachverhalte:

1. Der Ausdruck MAX ( Datum[Geschäftsjahr] ) ermittelt den über den Datenschnitt erzeugten Filter auf der Spalte Datum[Geschaeftsjahr], in meinem Beispiel 2017
2. Der bisher genutzte Beispielwert 1.827,00 € hat bzgl. der Datumstabelle den Filterkontext Datum[MonatImKalender] = „Mai 2017“, denn die Spalte Datum[MonatImKalender] wird als Spaltenüberschrift für die Pivot benutzt und hat beim Wert 1.827,00 € den Wert Mai 2017. Dadurch ist die Datumstabelle bereits auf Zeilen eingeschränkt, die zum Mai 2017 gehören. Der Ausdruck MAX ( Datum[MonatImJahr] ) ermittelt jetzt auf Basis dieser gefilterten Datumstabelle den maximalen Wert der Spalte Datum[MonatImJahr], der für das genannte Beispiel 5 ergibt.

Der folgende Screenshot veranschaulicht dies noch einmal:

Basierend auf den nun erstellten Filterkriterien, sieht das Measure wie folgt aus:

=
CALCULATE (
    SUM ( Umsaetze[Wert] );
    FILTER (
        Datum;
        AND (
Datum[MonatImJahr] <= MAX ( Datum[MonatImJahr] );
Datum[Geschäftsjahr] = MAX ( Datum[Geschäftsjahr] )
        )
    )
)

Lass uns auf das Ergebnis schauen:

Ja, Du siehst richtig: Wir haben immer noch nicht das gewünschte Ergebnis erzielt. Genaugenommen ist das Ergebnis (zumindest der Zahlenwert) identisch. Aber glaube mir, wir sind kurz davor. Zunächst eine Frage an Dich: Hast Du eine Idee, wieso der Wert immer noch unverändert ist, obwohl wir doch den Filter auf der Tabelle Datum so ausführlich definiert haben? Da muss doch jetzt der April mit in das Ergebnis einfließen!

Die Antwort ist folgende: März und April fehlen in unserem Ergebnis deshalb, weil noch bevor die FILTER()-Funktion dazu kommt, über die Tabelle Datum zu iterieren und nach bestimmten Kriterien zu filtern, der Filterkontext der Pivot bereits gegriffen hat. Das bedeutet, dass noch bevor FILTER() über die Datumstabelle iteriert, diese bereits auf den Monat Mai eingeschränkt ist, weil dieser zum Filterkontext der Pivot gehört. Verwirrend, oder?! Daran gewöhnt man sich mit der Zeit 😉 Die FILTER()-Funktion ist also nie über alle Zeilen der Datumstabelle iteriert, sondern immer nur über diejenigen, die zum Monat Mai 2017 gehören. Es gibt eine weitere (und für dieses Beispiel letzte) DAX-Funktion, die die Rettung bringt: ALL().

Die Rettung durch ALL()

Um die korrekten Werte zu erhalten, muss ich abschließend dafür sorgen, dass die genutzte FILTER()-Funktion auf der gesamten Datumstabelle filtern kann und nicht auf der, die bereits durch den Filterkontext der Pivot eingeschränkt wurde. Wirf einen Blick auf die abschließende Lösung, die Du bereits vom Anfang des Beitrags kennst:

=
CALCULATE (
    SUM ( Umsaetze[Wert] );
    FILTER (
        ALL ( Datum );
        AND (
Datum[MonatImJahr] <= MAX ( Datum[MonatImJahr] );
Datum[Geschäftsjahr] = MAX ( Datum[Geschäftsjahr] )
        )
    )
)

Die ALL()-Funktion ignoriert den bestehenden Filterkontext durch die Datumstabelle. ALL( Datum ) liefert die gesamte (nicht gefilterte) Datumstabelle an die FILTER()-Funktion zurück, so dass diese auf Basis der gesamten Datumstabelle filtern kann. Auf diese Weise ist es möglich den durch die Pivot auf Mai 2017 gesetzten Filter zu überschreiben und auf März, April und Mai 2017 zu erweitern. Dadurch ist die CALCULATE()-Funktion in der Lage, die gewünschten Year-to-date-Werte zu kalkulieren und das folgende Ergebnis zu erzeugen:

Fazit

Ich weiß: Das war lang und nicht trivial. Ich habe dieses Measure in dieser Ausführlichkeit beschrieben, weil es viele DAX-Konzepte beinhaltet, die Dir in Deinem Umgang mit DAX regelmäßig begegnen werden. Ich hoffe, ich habe damit ein wenig zum besseren Verständnis dieser Sprache beitragen können 🙂

Bis zum nächsten Mal und denk dran: Sharing is caring. Wenn Dir der Beitrag gefallen hat, dann teile ihn gerne. Falls Du Anmerkungen hast, schreibe gerne einen Kommentar, oder schicke mir eine Mail an lars@ssbi-blog.de

Viele Grüße aus Hamburg,

Lars

Ich schreibe meine Beiträge für Dich, den Leser. Bitte schenke mir eine Minute Deiner Zeit und bewerte die folgenden Kategorien, um mir zu helfen meine Beiträge so gut wie möglich zu schreiben. Danke 🙂

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag Ein vom Kalenderjahr abweichendes Geschäftsjahr mit Power BI abbilden, Teil2 erschien zuerst auf THE SELF-SERVICE-BI BLOG.

Als Abonnent meines Newsletters erhältst Du die Beispieldateien zu den Beiträgen dazu. Hier geht’s zum Abonnement des Newsletters!

Die Problematik

Was bedeutet es, wenn das Geschäftsjahr eines Unternehmens vom Kalenderjahr abweicht? Ich nehme den Fall, dass ein Geschäftsjahr nicht wie das Kalenderjahr am 31.12. endet, sondern erst am 31.3. des Folgejahres. Die folgende Abbildung veranschaulicht dies:

Unter der Annahme, dass das erste Datum in Zelle A2 steht, kann das Geschäftsjahr in Excel also mit folgender Formel berechnet werden: =WENN(MONAT(A2)<4;JAHR(A2)-1;JAHR(A2)).

Ziel

Das Ziel, das ich für die Gestaltung meines Berichts verfolge, besteht aus zwei Teilen.

1. Ich möchte einen bestimmten Einfluss auf den Aufbau der Pivottabelle nehmen. Diese Lösung kann natürlich auch auf alle anderen Visualisierungen übertragen werden, die man in Power BI Desktop nutzen kann.
2. Die Berechnung eines entsprechenden Year-to-Date-Wertes soll nicht mit dem Januar beginnen, sondern sich an meinen spezifischen Geschäftsjahresanfang orientieren.

Für das bessere Verständnis zeige ich jetzt die gewünschten Resultate.

Teilziel 1 – Die Beeinflussung des Pivotaufbaus

Das Ziel ist, dass bei der Auswahl des Geschäftsjahres 2017 über den oben befindlichen Datenschnitt, die Pivottabelle automatisch mit dem April 2017 beginnt und mit dem März 2018 endet. Der folgende Screenshot zeigt dies:

Teilziel 2 – Die Berechnung eines Year-to-Date-Wertes, bezogen auf das Geschäftsjahr

Ein Year-to-Date-Wert gibt einen kumulierten Jahreswert zurück, der standardmäßig alle Werte vom 1.1. des Jahres bis zum gewünschten Berichtstag widergibt. In meinem Falle startet das Jahr jedoch am 1. April:

Diese beiden Ziele gilt es umzusetzen, um ein korrektes Reporting zu gewährleisten. Bevor ich jedoch auf die Lösung eingehe, erkläre ich kurz die Augangssituation.

Die Ausgangssituation

Die Basis für meine Lösung ist das folgende, sehr einfache Datenmodell. Gegeben ist eine Faktentabelle (Umsaetze) mit den Umsätzen. Hinzu kommen zwei Dimensionstabellen Datum und Verkaufsstellen, die mit der Faktentabelle in Beziehung stehen.

Mit diesem Wissen, mache ich mich nun an die Beeinflussung der Pivotstruktur, indem ich das Datenmodell entsprechend anpasse.

Den Aufbau der Pivot beeinflussen: Das Datenmodell anpassen

Ich hatte bereits beim Erläutern der Problematik gezeigt, wie sich das Geschäftsjahr als Formel in Excel ergibt. Da ich meine Daten über Power Query ins Datenmodell in Excel geladen habe, ist eine valide Lösung genau diese Excelformel in Power Query über eine neue berechnete Spalte hinzuzufügen. Dies gestaltet sich wie folgt:

• Ich gehe in Power Query in die Abfrage meiner Datumstabelle
• Dort füge ich eine neue Spalte hinzu und nutze hierfür die folgende Formel:

Dies führt zu der neuen Spalte Geschäftsjahr in meiner Dimensionstabelle Datum. Ich speichere meine Abfrage und verlasse Power Query. Ein Blick auf die Pivottabelle zeigt folgendes:

In dieser Lösung sind nun die Monate April 2017 bis März 2018 enthalten – so wie es sein soll. Allerdings ist die Sortierung der Monate in alphabetischer Reihenfolge erfolgt. Dies ist für den Nutzer kaum hilfreich. Deshalb sorge ich jetzt dafür, dass die Sortierung der Monate in chronologischer Reihenfolge erfolgt. Hierfür gehe ich zurück ins Datenmodell. Nun gehe ich wie folgt vor:

• Ich markiere in der Tabelle Datum diejenige Spalte, die in meiner Pivottabelle den Monat beinhaltet (Spalte MonatImKalenderjahr).
• Dann klicke ich auf die Schaltfläche Startseite → Nach Spalte sortieren.
• Hier wähle ich aus, dass die als Text formatierte Spalte MonatImKalender, die in der Pivottabelle bisher alphabetisch sortiert wird, nach der numerischen Spalte JahrMonat sortiert werden soll.

Der folgende Screenshot zeigt die Vorgehensweise bildlich:

Das Ergebnis sieht daraufhin wie gewünscht aus:

Bevor ich mich der Kalkulation der YTD-Kennzahl widme, definiere ich zunächst im Datenmodell, auf Basis welcher Spalte die datumsbezogenen Kalkulationen stattfinden können.

Die Datumstabelle markieren

Die sog. Time Intelligence-Funktionen, wie beispielsweise die TOTALYTD()-Funktion, müssen definiert bekommen, welche Tabelle im Datenmodell die Kalendertabelle ist. Dies macht eine korrekte Kalkulation erst möglich. Ich markiere die Tabelle Datum wie folgt als Datumstabelle:

Nachdem die Datumstabelle nun markiert ist, kann mit der Kalkulation des YTD-Measures begonnen werden.

Die Kalkulation der Kennzahl beeinflussen: DAX – TOTALYTD()

Um einen YTD-Wert zu kalkulieren, bietet es sich in der Regel an, die DAX-Funktion TOTALYTD() zu nutzen. Diese hat die folgende Syntax:

TOTALYTD(<Ausdruck>,<Datumswerte>[,<Filter>][,<Jahresenddatum>])
Hier eine kurze Erläuterung der einzelnen Parameter:

• Ausdruck: Der Wert, aus dem der YTD-Wert gebildet werden soll. In meinem Beispiel die Spalte Umsaetze[Wert].
• Datumswerte: Eine Spalte mit Datumswerten, anhand derer der YTD-Zeitraum kalkuliert werden kann. In meinem Beispiel die Spalte Datum[Datum].
• Filter: Ein optionaler Parameter, der zum gegenwärtigen Kontext, unter dem die Formel evaluiert wird, einen weiteren Filter ergänzt. Dies ist für mein Beispiel nicht notwendig und wird vernachlässigt.
• Jahresenddatum: Ein optionaler Parameter, der das (Geschäfts-) Jahresende als Text übergibt. Hierbei sollte die US-amerikanische Reihenfolge „Monat/Tag“ eingehalten werden. Varianten wie „6/30“, „6-30“ und „Jun 30“ sind möglich.

Die folgende Formel bildet den korrekten YTD-Wert für mein Beispiel in DAX ab:

=
TOTALYTD ( SUM ( Umsaetze[Wert] ); Datum[Datum]; „3/31“ )

Ziehe ich dieses neue Measure nun mit in meine Pivottabelle, so entspricht das Ergebnis meiner Zielstellung:

Diese Lösung funktioniert hervorragend in 11 von 12 Fällen. Falls das Geschäftsjahr jedoch im Februar endet, stehe ich vor einem Problem, denn ich müßte meiner TOTALYTD()-Funktion mitgeben, dass mein Geschäftsjahr am 28.02. oder am 29.2. enden kann, je nachdem, ob es sich um ein Schaltjahr handelt, oder nicht. Dies ist mit der TOTALYTD()-Funktion jedoch nicht möglich. Wie dieses Problem dennoch zu lösen ist, erkläre ich im nächsten Post.

Bis zum nächsten Mal und denk dran: Sharing is caring. Wenn Dir der Beitrag gefallen hat, dann teile ihn gerne. Falls Du Anmerkungen hast, schreibe gerne einen Kommentar, oder schicke mir eine Mail an lars@ssbi-blog.de

Viele Grüße aus Hamburg,

Lars

Ich schreibe meine Beiträge für Dich, den Leser. Bitte schenke mir eine Minute Deiner Zeit und bewerte die folgenden Kategorien, um mir zu helfen meine Beiträge so gut wie möglich zu schreiben. Danke 🙂

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag Ein vom Kalenderjahr abweichendes Geschäftsjahr mit Power BI abbilden, Teil1 erschien zuerst auf THE SELF-SERVICE-BI BLOG.

Die persönliche Power BI Journey von Miguel Escobar

Miguel ist ein ehemaliger Microsoft MVP aus Panama City, Panama, der Gitarren und Datenanalyse liebt. Er ist Berater und Trainer für kostengünstige Business Intelligence-Lösungen. Zusammen mit MVP Ken Puls verfasste er das Buch „M is for Data Monkey„. Beide führen Power Query Trainings auf der ganzen Welt über www.powerquery.training und in Persona durch. Miguels Blog findest Du unter https://www.poweredsolutions.co/blog/.

Hi Miguel,

es ist Dezember und ich hoffe, du bist schon in Weihnachtsstimmung?! Ich danke Dir, dass Du an meinem Projekt teilnimmst, um Power BI und seine Vorteile noch populärer zu machen. Ich möchte Deine Erfahrungen mit dem Erlernen von Power BI aus einer Excel-Perspektive teilen und bin an den Vorteilen interessiert, die Power BI für Deine tägliche Arbeit mit sich gebracht hat. Los geht’s 🙂

Lars: Kannst Du Dich erinnern, wann Du zum ersten Mal von Power BI/ Power Excel Add-Ins gehört hast? Wie bist Du mit Power BI in Kontakt gekommen und warum dachtest Du, dass es etwas ist, das Du lernen solltest?

Miguel: Ich glaube, es war Mitte 2011, als ich dank eines YouTube-Videos von Bill „MrExcel“ Jelen das erste Mal von PowerPivot erfuhr. Ich fand es faszinierend, weil ich so tat, als wäre ich MacGyver mit meinen Excel-Dateien und Pivot-Tabellen, und immer versuchte, Excel über seine Grenzen hinaus zu bringen und nie das zu erreichen, was ich wollte… bis ich PowerPivot entdeckte. Später in diesem Jahr nahm ich an dem PowerPivot-Workshop teil, den Marco & Alberto geleitet haben, und dort habe ich die Reise offiziell begonnen. Zwei Jahre später gab ich meinen Job auf, den ich hatte, was für manche wahrscheinlich ein Traumjob war, und gründete meine Firma Powered Solutions, die heute ein Microsoft-Partner ist, der sich auf Power BI spezialisiert hat.

Lars: Es gab diesen kürzlich erschienenen Zeitungsartikel im Wall Street Journal, in dem es hieß: „Hört auf Excel zu nutzen„. Adobes Finanzchef (Mark Garrett) wird wie folgt zitiert: „Ich möchte nicht, dass die Finanzplaner ihre Zeit damit verbringen, Daten zu importieren und zu exportieren und zu manipulieren, ich möchte, dass sie sich auf das konzentrieren, was uns die Daten sagen“,… Er arbeitet daran, Excel aus diesem Prozess herauszuschneiden, sagte er. Wie ist Deine Wahrnehmung: Ist das Wissen über die Power Tools in Excel schon weit genug verbreitet, denn Mark Garrett scheint noch nie von den Power Tools in Excel gehört zu haben.

Miguel: Ich kann nachvollziehen, woher manche Leute kommen, wenn sie unter anderem sagen: „Ich will nicht, dass die Leute Excel benutzen“, denn manchmal beziehen sie sich nicht auf die Analytik, sondern auf die Datenplattform und das Datenmanagement. Sieh …sie beziehen sich nicht auf Analytik (Power Pivot und Pivot Tabellen), Datenvorbereitung (Power Query) oder Datenvisualisierung (Pivot Tabellen, Charts, etc.), sondern eher auf Datenmanagement (Datenbank-Engine, Sicherheit, Front-End App und mehr). Manche Leute benutzen Excel buchstäblich als Datenbank (ich war einer von ihnen!) und wenn sie sich darauf beziehen, kann ich verstehen, warum sie nicht wollen, dass die Leute Excel dafür benutzen. Dies ist ein stichhaltiger Punkt, den sie auf Dinge hinweisen, für die Sie Excel nicht verwenden sollten:

„Vor einem Jahr verbrachte Mr. Bells Team Stunden damit, hunderte von Excel-Tabellen an regionale und Unit-Leiter zu verteilen, die jeden Monat für die Planung und Leistungsverfolgung der 415 US-Restaurants des Unternehmens verwendet wurden, sagte er. Jetzt dauert der gleiche Vorgang nur noch Minuten.“

Du weißt, was sie stattdessen nehmen sollten? PowerApps für ihre Front-End-Anwendung und eine Cloud-Datenbank (wie SQL Azure), so dass sie jederzeit und überall auf die Daten zugreifen können. Nun, von diesem Artikel, wissen wir nicht, wie viel Brian Jones (MSFT) mit dem Autor (Tatyana Shumsky) über Power Query und Power Pivot geplaudert hat, aber es ist traurig zu sehen, dass der Artikel nicht einmal anerkennt, dass es sich um eines der besten Werkzeuge in seiner Kategorie weltweit handelt – zweifellos. Der Artikel ist auch ziemlich vage über die Dinge, die sie sagen, wie: „Excel war einfach nicht dafür ausgelegt, einige der schweren Aufgaben zu erledigen, die Unternehmen im Finanzbereich zu bewältigen haben“. Worauf beziehen sie sich genau, wenn sie von schweren Aufgaben sprechen? Ist es Data Analytics? PowerPivot gehört zu den Besten seiner Klasse. Ist es Data Prep? Du wirst im Moment kein besseres und benutzerfreundlicheres Tool als Power Query auf der Welt finden. Ist es Datenvisualisierung? Wenn Du die Dinge wirklich auf die nächste Stufe bringen musst, dann kannst Du von Excel auf Power BI upgraden. Dies beweist nur, dass das Wissen über die Power Tools bei weitem nicht da ist, wo es sein sollte, und Microsoft ist sich dessen bewusst. Es klingt einfach bizarr, dass der Autor die Informationen über die Power Tools von Brian Jones nicht erhalten hat.

Lars: Wenn Du eine Power BI-Lösung für einen Kunden erstellst, tust Du dies primär in Excel (mit den Power Add-Ins), oder eher in Power BI Desktop? Gibt es einen Trend, den Du in der Vergangenheit erkennen konntest?

Miguel: Die Dinge haben sich im vergangenen Jahr oder so verändert. Jetzt geht es vor allem um Fragen zu Power BI Desktop, aber vorher war alles in Excel. Dies liegt daran, wie sehr sich Power BI von seiner V1 (Power BI in Office auf SharePoint Online) auf die neueste Version geändert hat, die wir heute kennen und lieben.

Lars: Ich erinnere mich an eine Situation mit einem Kunden, der viel mit CSV-Importen gearbeitet hat. Ich habe ihm gezeigt, wie man 100 CSV-Dateien in 60 Sekunden in Excel importiert und er war begeistert. Kannst Du Dich an so einen Power BI Schlüsselmoment erinnern, den Du mit uns teilen kannst?

Miguel: Ich hatte einen Moment mit Power Pivot vor ein paar Jahren mit einer Datei, die Rob Collie mit mir geteilt hat. Diese Datei hatte über 300 Millionen Zeilen von Daten in ungefähr 3 Tabellen. Ich habe diese Excel-Datei auf einer wirklich netten regionalen Konferenz hier in Panama vorgestellt und…yeah. Die Leute dachten zuerst, dass ich lüge, aber dann sahen sie alle Daten und merkten, wie sehr sich Excel verändert hat.

Lars: Ich weiß, dass Du viel mit Custom Data Connectors arbeitest, die im Mai 2017 eingeführt wurden. Diese Konnektoren sind in M programmiert und stehen derzeit nur für Power BI Desktop zur Verfügung. Welche Erfahrungen hast Du bisher mit diesen Konnektoren gemacht und welche Verbesserungsvorschläge hast Du?

Miguel: Custom Connectors sind ziemlich genial! Ich bin zuversichtlich, dass sich die Dinge in naher Zukunft drastisch verbessern werden, aber meine größte Sorge in diesem Moment ist, dass die meisten kundenspezifischen Konnektoren den Endbenutzer dazu zwingen werden, das Data Gateway zu verwenden, um ihre Modelle auf dem Power BI Service aktualisieren zu können. Ich habe meine Vorschläge dazu mit dem Power Query-Team geäußert, so dass die Konnektoren, die keiner besonderen Behandlung bedürfen, über den Office Store erworben und im Power BI Service aktualisiert werden können, ohne dass ein Data Gateway erforderlich ist. Auf diese Weise benötigen Sie kein Data Gateway, um z.B. Daten von diesem Konnektor zu aktualisieren.

Authentifizierung von Custom Connectors, die eine besondere Behandlung erfordern: OAuth 2, ODBC, OLEDB, etc.

Lars: Du und Ken habt gerade Euren Power Query Online-Kurs veröffentlicht. Würdest Du dem Leser etwas darüber erzählen?

Miguel: Kurz gesagt, dies ist der beste Kurs, den wir in unserem ganzen Leben geschaffen haben. Hoher Produktionswert und noch bessere und einzigartige Inhalte, die wir noch nie zuvor geteilt haben. Wenn Du auf der Suche nach dem besten Kurs auf dem Markt für Power Query bist, dann bist Du hier genau richtig.

Lars: Bis vor einigen Jahren habe ich hauptsächlich an Reporting-Lösungen mit Excel gearbeitet und in der Vergangenheit viel in VBA (Visual Basic for Applications) programmiert. Seitdem Power BI verfügbar ist, musste ich nur sehr wenige Zeilen VBA schreiben. Habst Du ähnliche Beobachtungen gemacht?

Miguel: Ich schätze, man könnte sagen, dass ich zu den „millennials“ gehöre, die nie versucht haben, VBA zu erlernen. Ich erinnere mich daran, dass ich darüber nachgedacht habe, 2011 etwas über VBA zu lernen, als ich Probleme damit hatte, wie langsam und langweilig die Dinge in Excel waren, aber dann bemerkte ich, dass VBA keine Webstory hatte. Der VBA-Code, den ich erstellen würde, würde nur auf meinem Desktop funktionieren, und ich wurde hauptsächlich von Lösungen angezogen, die skalierbar sind, wie z.B. Power Query und Power Pivot, die auf so etwas wie SQL Server Analysis Services skalieren können, oder wie Dein M-Code jetzt auf einen tatsächlichen benutzerdefinierten Connector skaliert werden kann, der später in Microsoft Flow, PowerApps und einigen anderen Diensten verwendet werden kann.

Lars: Wenn du nach einem neuen Feature in Power BI fragen könntest (was jeder über ideas.powerbi.com kann), was wäre das?

Miguel: Ich habe das Gefühl, dass Power BI sich endlich in einem Stadium befindet, in dem es innovativ sein kann und nicht versuchen muss, das Aufholspiel zu spielen, also würde ich gerne die Dinge sehen, die das Microsoft Research-Team in seinem Tresorraum hat und diese in die Power Query-Erfahrung einfließen lassen. Möglicherweise eine KI (Anm.: KI = Künstliche Intelligenz) Weise, dass es einen Scan auf Deinen Daten durchführen kann, Muster finden und Dir Vorschläge machen kann, wie diese Daten transformiert oder einfach nur bereinigt werden können. Wenn Du mit der Erstellung Deiner Lösung fertig bist, kannst Du vielleicht auf einen Knopf (den Optimierungsknopf) klicken und Power Query wird einen noch optimaleren Weg finden, um Deine gewünschte Ausgabe dank seiner KI zu erreichen. Vielleicht ein neuer, optimierter On-Memory-Caching-Algorithmus, damit die Dinge schneller laufen können.

Lars: Könntest Du 3 Dinge nennen, die Power BI zu einem großartigen Produkt machen?

Miguel: 

• Benutzerfreundlich – Power Query ist der Beweis dafür, dass Microsoft eine wirklich schöne Benutzeroberfläche und noch bessere UX (anm.: UX = User Experience = Benutzerfreundlichkeit) erzeugen kann.
• Effektiv – Du kannst Dinge in Sekundenschnelle erledigen.
• Hochgradig anpassbar – etwas verändert? Du kannst jeden Teil Deiner Lösung modifizieren und die neue Lösung in wenigen Sekunden oder Minuten in Betrieb nehmen.

Miguel, danke, dass Du Deine Geschichte mit uns teilst und danke für die großartigen Power Query-Kurse, die Du und Ken kreiert habt. Frohe Weihnachten und einen guten Rutsch ins neue Jahr!

Um mit Miguel in Kontakt zu treten, nutzen Sie bitte die folgende Website.

The personal Power BI journey of Miguel Escobar

Miguel is a former Microsoft MVP from Panama City, Panama who loves Guitars and Data Analytics. He is a consultant and trainer for cost-effective Business Intelligence solutions. Together with MVP Ken Puls he authored the book „M is for Data Monkey„. Both are running Power Query Trainings all over the world via www.powerquery.training and in persona. You can find Miguel’s blog at https://www.poweredsolutions.co/blog/.

Hi Miguel,

it’s December and I hope you’re already in Christmas mood?! 🙂 Thank you for participating in my project to make Power BI and its benefits even more popular.

I would like to share your experience of learning Power BI from an Excel perspective and I am interested in the benefits Power BI has brought to your daily work. Let’s go 🙂

Lars: Can you remember, when you first heard about Power BI/ Power Excel Add-Ins? How did you get in contact with Power BI and why did you think it’s something you should learn?

Miguel: I believe it was in mid-2011 when I first found out about PowerPivot thanks to a YouTube video from Bill ‘MrExcel’ Jelen. I found it fascinating because I was pretending to be MacGyver with my Excel Workbooks and pivot tables, trying to push Excel beyond its limits and never reaching what I wanted…until I discovered PowerPivot. Later that year I took the PowerPivot workshop that Marco & Alberto ran and that’s where I formally started the journey. Two years later I resigned to the job that I had, what was probably a dream job to some people, and started my company Powered Solutions which is, nowadays, a Microsoft Partner specialized in Power BI.

Lars: There was this recent newspaper article in the Wall Street Journal that said „Stop Using Excel„. Adobe’s finance chief (Mark Garrett) is quoted as follows: „I don’t want financial planning people spending their time importing and exporting and manipulating data, I want them to focus on what is the data telling us, … He is working on cutting Excel out of this process, he said.“ How is your perception: Is the knowledge about Power tools in Excel already widespread enough, because Mark Garrett seems to have never heard of the Power tools in Excel.

Miguel: I can understand where some people are coming from when they say something among the lines of: “I don’t want people to use Excel”, because, at times, they are not referring to the Analytics side of things, but rather the Data Platform and Data Management side of things. See…they are not referring to Analytics (Power Pivot and Pivot Tables), Data Prep (Power Query) or Data Visualization (Pivot Tables, Charts, etc), but rather to Data Management (a database engine, security, front-end app and more). Some people literally use Excel as a Database (I was one of them!) and, if they refer to that, I can understand why they don’t want people to use Excel for that. This is a valid point that they make on things that you shouldn’t use Excel for:

“A year ago, Mr. Bell’s team spent hours distributing hundreds of Excel spreadsheets to regional and unit leaders each month for planning and performance tracking of the company’s 415 U.S. restaurants, he said. Now the same process takes minutes.”

You know what they should be using instead? PowerApps for their Front-end application and a cloud database (like SQL Azure) so they can access the data from anywhere always. Now, from this article, we don’t know how much Brian Jones (MSFT) chatted with the writer (Tatyana Shumsky) about Power Query and Power Pivot, but it’s sad to see that the article doesn’t even acknowledge that these are ones of the best tools in their category worldwide – hands down. The article is also pretty vague on the things that they say like:

“Excel just wasn’t designed to do some of the heavy lifting that companies need to do in finance,”

What exactly are they referring to when they say heavy lifting? Is it Data Analytics? PowerPivot is one of the best in its class. Is it Data Prep? You won’t find a better and more user-friendly tool than Power Query in the world at this moment. Is it Data Visualization? If you really need to take things to the next level, then you can upgrade from Excel to Power BI. This just proves that the knowledge of the Power tools is nowhere near where it should be, and Microsoft is aware of that. It just sounds bizarre that the writer didn’t get the information about the Power Tools from Brian Jones.

Lars: When you create a Power BI solution for a customer, do you do this primarily in Excel (with the Power add-ins), or rather in Power BI Desktop? Was there a trend for you to recognize in the past?

Miguel: Things have changed in the past year or so. Now it’s primarily Power BI Desktop related questions, but before it was all within Excel. This is because of how much Power BI has changes from its v1 (Power BI with Office on SharePoint Online) to the latest version that we know and love today.

Lars: I can remember a situation with a customer who worked a lot with csv imports. I showed him how to import 100 csv files into Excel in 60 seconds and he was thrilled. Can you remember such a Power BI key moment that you can share with us?

Miguel: I had a moment with Power Pivot a few years ago with a file that Rob Collie shared with me. This file had over 300M rows of data cross 3 tables or so. I showcased this Excel file at a really nice regional conference here in Panama and…yeah. People thought that I was lying at first, but then they saw all the data and realized how much Excel has changed.

Lars: I know you are working with Custom Data Connectors a lot, which were introduced in May 2017. These connectors are programmed in M and they are only available for Power BI Desktop yet. What is your experience with these connectors so far and what suggestions would you have with regard to improvements?

Miguel: Custom Connectors are pretty awesome! I’m confident that things will improve dramatically in the near future, but my biggest concern at this moment is that most of the custom connectors will require the end user to use the Data Gateway to be able to refresh their models on the Power BI Service. I’ve voiced my suggestions with the Power Query team about this, so the connectors that don’t need any special handling can be acquired through the office store and be refreshed on the Power BI Service without the need for a Data Gateway. That way you won’t need a Data Gateway to refresh data from this connector for example.

Authentications of Custom Connectors that require special handling: OAuth 2, ODBC, OLEDB, etc

Lars: You and Ken just released your now Power Query online course. Would you tell the reader something about it?

Miguel: In short, this is the best course that we’ve created in our entire lives. High production value and even better and unique content that we’ve never shared before. If you’re looking for the best course in the market about Power Query, then this is it.

Lars: Until a few years ago, I mainly worked on reporting solutions with Excel and programmed a lot in VBA (Visual Basic for Applications) in the past. Since Power BI is available, I have only had to write very few lines of VBA. Did you make similar observations?

Miguel: I guess that you could say that I’m one of those millennials that never even tried learning VBA. I remember thinking about learning about VBA in 2011 when I was having issues with how slow and tedious things were in Excel, but then I noticed that VBA did not have a web story. The VBA code that I’d create would only work on my desktop, and I’ve been mainly attracted to solutions that can scale up like how Power Query and Power Pivot can scale up to something like SQL Server Analysis Services, or how your M code can now scale up to an actual custom connector that can be later used in Microsoft Flow, PowerApps and some other services.

Lars: If you could ask for a new feature in Power BI (what everyone can via ideas.powerbi.com) what would that be?

Miguel: I feel like Power BI is finally in a stage where it can innovate and not try to play the ‘catching-up’ game, so I’d like to see the things that the Microsoft Research team has inside their vault and have those put inside the Power Query experience. Perhaps an AI way that it can do a scan on your data, find patterns and provide you with suggestions on how that data can be transformed or simply cleaned. Perhaps once you finish creating your solution, you can click a button (the optimize button) and Power Query will figure out an even more optimal way to reach your desired output thanks to its AI. Perhaps a new an optimized on-memory caching algorithm so things can run faster.

Lars: Could you name 3 things about Power BI, which make it a great product?

Miguel: 

• User-friendly – Power Query is the proof that Microsoft can create a really nice UI and even better UX.
• Effective – you can get things done in a matter of seconds
• Highly customizable – something changed? You can modify any part of your solution and have the new solution up and running in just a few seconds or minutes.

Miguel, thank you for sharing your story and for the great Power Query courses you and Ken have created. Have a merry Christmas and a happy new year!

To get in touch with Miguel, please use the following website.

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag Die persönliche Power BI Journey von Miguel Escobar (in English as well) erschien zuerst auf THE SELF-SERVICE-BI BLOG.

Die persönliche Power BI Journey von Marco Russo

Marco ist seit 2009 MVP für Data Platform, aus Turin, Italien. Er ist Business Intelligence Berater und Mentor und spricht regelmäßig auf Konferenzen wie TechEd und PASS Summit. Zusammen mit Alberto Ferrari gründete er SQLBI, die weltweit beste Ressource für tabellarische Datenmodellierung mit Power Pivot, Power BI und SQL Server Analysis Services Tabular und der Sprache DAX.

Hallo Marco,

ich freue mich sehr, dass mein Projekt ständig wächst. Vielen Dank für Deine Teilnahme. Die letzten Jahre der Nutzung von Power BI haben mich überzeugt, dass es ein erstaunliches Produkt ist, das jede Mühe wert ist, es zu erlernen. Meine Idee mit diesem Beitrag ist, Deine Geschichte als Business Intelligence-Experte zu teilen, der zum Power BI-Experten wurde und wie es Dein Berufsleben verändert hat. Los geht‘s 🙂

Lars: Kannst Du Dich daran erinnern, wann Du das erste Mal von Power BI/ Power Excel Add-Ins gehört hast? Wie bist Du mit Power BI in Berührung gekommen?

Marco: Ich habe die erste Version von Power Pivot im August 2009 benutzt. Damals hieß sie Gemini, und ich wusste nicht sofort, was auf lange Sicht dessen Wirkung sein würde. Aber auf dem PASS Summit in Seattle im selben Jahr, als ich mit Leuten des Entwicklungsteams sprach, wurde mir klar, dass es etwas Großes war.

Ich hörte von Power BI im Jahr 2014, es war die natürliche Evolution von Power Pivot, aber meine Sorge war die Geschwindigkeit der Veröffentlichung. Als sie mir sagten: „Wir werden jeden Monat eine neue Version veröffentlichen“, sagte ich: „Ich werde es erst nach einem Jahr glauben, dass ihr das jeden Monat tun werdet“. Ich war skeptisch, aber es hat gut funktioniert!

Lars: DAX sieht auf den ersten Blick einfach aus, vor allem weil die Syntax der Excel-Sprache sehr nahe ist. Aber die ganze Evaluierungskontext-Sache ist viel schwieriger zu verstehen. Zusätzlich muss man vor dem Schreiben der ersten Zeile DAX, die Daten modellieren. Hältst Du es für realistisch, dass viele Analysten, die heute täglich mit Excel arbeiten, in naher Zukunft eigene Datenmodelle erstellen und DAX-Measures schreiben werden? Oder anders ausgedrückt: Glaubst Du, dass der Begriff Self-Service BI hauptsächlich Marketing ist?

Marco: Ich würde die Antworten trennen. Wenn man 1984 gefragt hätte, ob es realistisch sei, dass jede Person in der Buchhaltung eine Tabellenkalkulation benutzen würde, hätte man ein großes „Nein“ gehört. Heute ist es für uns selbstverständlich, dass wir auf dem Handy eine Tabellenkalkulation ansehen und bearbeiten können. Verschiedene Benutzer haben unterschiedliche Grade von Kenntnissen über die benötigte Formelsprache, aber jeder kann einfache Formeln erstellen.

In bestimmten Job-Rollen sind tiefe Kenntnisse der Excel-Features Voraussetzung. Wenn eine Tabelle nicht ausreicht, was sind dann die Alternativen? Das Erstellen eines semantischen Modells ist ein mächtiges Werkzeug, aber es erfordert Fähigkeiten, die wir immer noch DBAs oder BI-Entwicklern zuschreiben (z.B. Datenmodellierung). Aber viele Nutzer können lernen, was es bedarf viele Tabellen zu handhaben und sie können dies im Verlauf der Zeit verfeinern.

Betrachten sich Anwender, die Excel-Makros schreiben, als „Entwickler“? Nein. Aber sie schreiben Code. Genauso erstellen Power-BI-Anwender Datenmodelle. Wenn Sie Daten analysieren müssen, ist in 10 Jahren Datenmodellierung eine erforderliche Fähigkeit, zumindest dessen Grundlagen.

Was ist mit Self-Service BI? Nenne es Marketing, aber wir brauchen immer eine „Vision“, eine Roadmap. Ich glaube nicht, dass 100% der Benutzer, die Daten verarbeiten, Modelle erstellen, nur weil sie ein Self-Service-BI-Tool besitzen. Aber es ist eine Tatsache, dass viele Benutzer ihre eigenen Berichte erstellen, eine kleinere Zahl von Benutzern ihre Berechnungen anpassen und eine Nische von ihnen semantische Modelle erstellen. Sie alle verwenden „self-service BI“ oder wie auch immer man es nennen mag, auf verschiedenen Ebenen. Genauso wie es viele verschiedene Excel-Nutzer gibt.

Lars: Im April 2017 wurden in Power BI Desktop Quick Measures eingeführt, die das Erstellen von Measures vereinfachen sollen. Bist Du der Meinung, dass Quick Measures ein geeigneter Weg sind, um die Komplexität der Sprache DAX zu überwinden?

Marco: Ich habe hier widersprüchliche Gefühle. Ich verstehe den Zweck von Quick Measures. Ich mag dessen aktuelle Implementierung nicht. Es gibt zu viele Einschränkungen, die Workarounds könnten die Berechnungen kaputt machen (z. B. „Autom. Datum/Uhrzeit“ zu aktivieren, wenn Du eine benutzerdefinierte Datumstabelle hast und Quick Measures über Datumswerte nutzen willst).

Es ist ein Feature, das dem gelegentlichen Benutzer helfen könnte, aber es ist nicht genug für fortgeschrittenere Benutzer. Ich weiß, dass Microsoft daran arbeitet, aber ich würde einen völlig anderen Ansatz vorziehen.Ein DAX-Measure ist einfacher, wenn das Datenmodell gut aufgebaut ist. Wenn man versucht, ein schlechtes Datenmodell zu umgehen, erhöhen das die Komplexität des benötigten DAX-Codes.

Eine viel bessere Lösung wäre eine Interaktion zwischen Datenmodell und DAX-Measure, die es erlaubt, beide Teile des Problems via Wizards/ Vorlagen zu berücksichtigen, definiert, um die gleichen Probleme zu lösen, die Quick Measures zu lösen versuchen. Den Nutzer zu befähigen, gängige Kalkulationen auf eine einfach und sichere Weise zu schreiben. So kann man Quick Measures betrachten, aber sie erhöhen nicht die Produktivität fortgeschrittener Benutzer und lösen nicht alle Probleme für Newbies. In diesem Bereich gibt es viel zu tun.

Lars: Alberto und Du habt auf SQLBI viele Angebote für alle, die sich mit tabellarischer Datenmodellierung und DAX vertraut machen wollen. Von Büchern, über Präsenzschulungen bis hin zu Videokursen. Kannst Du dem Leser etwas darüber sagen? Vom Einsteiger bis zum Profi: Mit welchem Eurer Produkte soll ich beginnen und aufhören?

Marco: Unsere Mission ist es, Wissen zu vermitteln und die Einführung einer neuen Technologie zu beschleunigen. Wir bieten Bücher, Videokurse, Klassenraumkurse, Konferenzen und Beratung an. Diese Dienstleistungen bieten wir auf unserer Website www.sqlbi.com an, auf der wir kostenlose Artikel, Whitepaper und Tools produzieren. Außerdem bieten wir einen kostenlosen Videokurs Introduction to DAX an, der unser Vorschlag ist, um mit dem Erlernen von DAX zu beginnen. Der Weg zum Erlernen von DAX erfordert auch einige Erfahrung in der Datenmodellierung. Wir haben eine spezielle Webseite, die den Lernweg in Abhängigkeit von den verwendeten Produkten vorschlägt. Wir werden diese Seite in der neuen Website aktualisieren und verbessern, die vor Ende 2017 fertig sein wird.

Lars: Was ist aus Deiner Berufserfahrung als Trainer der häufigste Fehler, den Studenten machen, wenn sie DAX lernen? Kannst Du uns sagen, wie man das vermeiden kann?

Marco: Der häufigste Fehler ist der Versuch, durch Beispiele zu lernen. Die einzige Komplexität von DAX besteht darin, dass es einige abstrakte Konzepte gibt, die in dieser Sprache einzigartig sind und in keiner anderen Sprache existieren.

Der Begriff des „filter context“ und der „context transition“ ist eine brillante Lösung für ein komplexes Problem. Grundsätzlich ist es einfach zu erklären und zu lernen, aber es braucht Zeit, um es zu verdauen, weil es anders ist als alles andere, was man bereits kennt. Ich habe sehr kluge Entwickler und erfahrene BI-Entwickler gesehen, die den gleichen Fehler gemacht haben.

Du sparst viel Zeit, wenn Du akzeptierst, dass es ein neues Konzept geben könnte, das Du noch nie zuvor gesehen hast. Ein ähnliches Problem habe ich bei der Einführung der objektorientierten Programmierung gesehen. Einige Entwickler, die ein neues Konzept mit der alten Syntax erklären wollten, hatten Probleme. Es gab etwas „Verstecktes“, das nicht so funktionierte, wie sie es erwartet hatten. Wenn du einmal akzeptiert hast, dass es etwas Neues zu lernen gibt, kannst du loslegen.

Lars: Meiner Erfahrung nach lehnen viele Kunden die Cloud als Ort für ihre Geschäftsdaten ab. Zumindest in Deutschland ist das ein großes Thema. Aber die gemeinsame Nutzung von Daten mit Power BI erfordert Power BI Report Server, was ziemlich teuer ist. Wie gehen Deine Kunden in der Regel mit dem Cloud-Thema um und wie handhabst Du das?

Marco: Ich bin in einer verzerrten Position. Meine Kunden rufen uns an, weil sie bereits Analysis Services oder Power BI einsetzen. In der Regel nehme ich nicht an der Vorverkaufsdiskussion teil, bei der es um die Wahlmöglichkeiten zwischen on premise und Cloud-Optionen geht. Ich weiß, dass es Unternehmen gibt, die Daten on premise behalten wollen, und Unternehmen, die in die Cloud wollen.

Meiner Ansicht nach ist dies so, dass auf lange Sicht alle Unternehmen in die Cloud gehen werden, mit kleinen Ausnahmen: Militär und bestimmte Regierungsbehörden. Diese Ausnahmen führen wahrscheinlich dieselben Cloud-Technologien vor Ort in einer kontrollierten und isolierten Umgebung ein. Außerhalb dieser Ausnahmen stellt sich nicht die Frage, ob, sondern wann. Der Grund ist ein guter: Geld. Die Verwaltung des gleichen Services in der Cloud ist kostengünstiger, sobald Sie die Total Cost of Ownership berechnen. Die Zeit für die Cloud-Akzeptanz wird je nach Markt, Kultur, Politik, Gesetzen, Bandbreite, Fähigkeiten und wahrscheinlich noch viel mehr variieren. Aber das wird geschehen. Aus dem gleichen Grund, warum Unternehmen kein eigenes Betriebssystem mehr entwickeln, keinen eigenen Compiler, kein eigenes ERP und so weiter.

Aus der kurzen Geschichte der Informatik können wir lernen, dass das, was in einem Jahrzehnt unmöglich schien, ein paar Jahre später völlig überholt war. Ich sehe, dass die Technologie-Akzeptanz in Europa einen viel konservativeren Ansatz verfolgt als auf anderen Kontinenten. Aber ich sehe keine einzige Technologie, die in den Vereinigten Staaten, aber nicht in Europa (vielleicht Jahre später) übernommen wurde. Europa hat das Kabelfernsehen übersprungen, um direkt zum Satellitenfernsehen zu gehen. Aber es ist wahrscheinlich die Ausnahme, die die Regel bestätigt.

Lars: Mit SQLBI habt Ihr vor einiger Zeit OKViz  gegründet und stellt Eure eigenen Visualisierungen zur Verfügung. Wie kritisch für den Erfolg von Power BI ist die Tatsache, dass die Visualisierungen Open Source sind und von jedem, der dazu technisch in der Lage ist, entwickelt werden können?

Marco: Mit OKViz haben wir eine Marke für „custom visualizations“ geschaffen. Bis heute ist es ein „reines Startup“, weil es Kosten verursacht, ohne Einnahmen zu generieren. Der Marketplace ist noch nicht fertig, die Plattform ist noch nicht fertig, und „custom visuals“ sind gegenwärtig Bürger zweiter Klasse. Das wird sich hoffentlich ändern, und OKViz kann die Produktion von „custom visuals“ steigern, sobald die Voraussetzungen für ein nachhaltiges Wirtschaftsmodell gegeben sind.

Im Moment sind „custom visuals“ ein wichtiges Werkzeug für den Erfolg von Power BI, aber im Hinblick auf die reale Akzeptanz werden native Visualisierungen viel häufiger verwendet. Die größten Herausforderungen sind Versionierung, Support und automatische Updates. Es ist unglaublich schwierig, eine stabile Plattform für „custom visuals“ in einer Umgebung zu schaffen, die sich jeden Monat weiterentwickelt. Wir können die Fehler leicht sehen, aber nicht die Menge der versteckten Arbeit, um das aufrechtzuerhalten.

Ich bin optimistisch, wenn es um „custom visuals“ in Power BI geht, falls es einen echten Marketplace geben wird. Ich bin skeptisch, wenn es darum geht jemanden zu befähigen, „custom visuals“ zu erstellen. Wir werden niemals sehen, dass Power BI-Nutzer Visualisierungen schreiben, so wie ein Excel-Nutzer ein Makro schreibt. Möglich ist es, einen existierenden Entwickler in die Lage zu versetzen, „custom visuals“ für Power BI zu erstellen. Open Source ist ein sehr relativer Vorteil. Die gesamte Plattform ist nicht Open Source, man kann den Code der Plattform nicht erweitern, man kann lediglich andere „custom visuals“ kopieren und anpassen. Native Visualisierungen werden ohne die „custom visuals“-Plattform geschrieben, so dass man keine „custom visuals“ aus nativen Visualisierungen ableiten kann.

Um es kurz zu wiederholen: Ich glaube, dass „custom visuals“ extrem wichtig sind, und wir haben viel in sie investiert. Allerdings würde ich „custom visuals“ nicht als etwas verkaufen, das jeder Power-BI-Nutzer an jede spezifische Anforderung anpassen kann. Die Lernkurve zum Schreiben von „custom visuals“ ist nicht so schnell.

Lars: Wenn du nach einem neuen Feature in Power BI fragen könntest (was jeder über ideas.powerbi.com kann), was wäre das?

Marco: Meine Nummer eins ist, die API zu Power BI Desktop zu öffnen. Ich bitte Euch hierfür um Eure Stimme: https://ideas.powerbi.com/forums/265200-power-bi-ideas/suggestions/7345565-power-bi-designer-api. Dieses Feature würde die Erstellung vieler neuer Tools und Lösungen ermöglichen.

Lars: Könntest Du 3 Dinge nennen, die Power BI zu einem großartigen Produkt machen?

Marco:

• Freier Zugang zu fast allen Funktionen, um einen Proof of Concept zu starten.
• Integration zwischen Query Editor (M), Datenmodell (DAX) und Visualisierung.
• Rechenleistung der Engine: Es ist sehr schwer, etwas schnelleres auf dem Markt zu finden.

Marco, ich danke Dir, Alberto, Daniele und all deinen Kollegen hinter den Kulissen für die tollen Beiträge, Bücher, Produkte und Community-Arbeit. Ich weiß, es gibt viele Leute (einschließlich mir selbst), die sehr dankbar sind für all die Arbeit, die Ihr leistet. Um mit Marco in Kontakt zu treten, nutzt bitte die folgende Website.

The personal Power BI journey of Marco Russo

Marco is a MVP for Data Platform since 2009 from Torino, Italy. He is a Business Intelligence consultant and mentor and speaks regularly at conferences such as TechEd and PASS Summit. Together with Alberto Ferrari he founded SQLBI, indisputable the world’s best resource for tabular Data Modeling with Power Pivot, Power BI and SQL Server Analysis Services Tabular and the DAX language.

Hello Marco,

I am very happy, that my project is constantly growing. Thanks a lot for participating. The last years of using Power BI convinced me, this is an amazing product, worth any effort learning it. My idea with this post is, to share your story as a Business Intelligence expert, who became a Power BI expert and how it changed your professional life. Let’s go 🙂

Lars: Can you remember, when you first heard about Power BI/ Power Excel Add-Ins? How did you get in contact with Power BI?

Marco: I used the first version of Power Pivot in August 2009. It was called Gemini at that time, and I didn’t realize immediately what would have been its impact in the long term. But at PASS Summit in Seattle the same year, talking with people of the development team, I realized that it was something big.

I heard about Power BI in 2014, it was the natural evolution of Power Pivot, but my concern was the speed of release. When they told “we will release a new version every month” I said, “I will believe it only after one year you will do that every month”. I was skeptical, but it worked well!

Lars: DAX looks easy at first sight, especially because the syntax is close to the Excel language. But the whole evaluation context thing is a lot harder to understand. Additionally, before you write your first line of DAX, you have to model your data. Do you think it is realistic, that many analysts, who are now doing their daily work with Excel, will create their own data models and write DAX measures in near future? Or in other words: Do you think the term Self-Service BI is mainly marketing?

Marco: I would separate the answers. If you asked in 1984 whether it was realistic that every person in accounting would use a spreadsheet, you would have heard a big “no”. Today we take for granted that on a mobile phone we can view and edit a spreadsheet. Different users have different degrees of knowledge of the formula language required, but anyone can create simple formulas.

In certain job roles, a deep knowledge of Excel features is a requirement. Now, when a table is not enough, what are the alternatives? Creating a semantic model is a powerful tool, but it requires skills that we still think are for DBAs or BI Developers (e.g. data modeling). But many users can learn what they need to manage multiple tables, and they can refine that over time.

Do users who write Excel macros consider themselves “developer”? No. But they write code. Thus, Power BI users create data models. If you need to analyze data, in 10 years data modeling will be a required skill, at least for the basics.

What about self-service BI? Call it marketing, but we always need a “vision”, a roadmap. I don’t think that 100% of users consuming data will create models just because they have a self-service BI tool. But it’s a matter of fact that many users create their own reports, a smaller number of users customize calculations, and a niche of them create semantic models. They are all using “self-service BI” or whatever other name you use, at different levels. Just like there are many different types of Excel users.

Lars: Quick measures were introduced in Power BI Desktop in April 2017 and aim to simplify the creation of measures. Do you think Quick Measures are a proper way to overcome the complexity of the DAX language?

Marco: I have conflicting feelings here. I understand the purpose of Quick Measures. I don’t like its current implementation. There are too many limitations, the workarounds could break the calculations (e.g. enabling auto Date/Time when you have a custom Date table just to use Quick Measures over dates).

It is a feature that could help the occasional user, but they are not enough for more advanced ones. I know that Microsoft is working on that, but I would prefer a completely different approach. A DAX measure is simpler if the data model is well designed. Trying to work around a bad data model just increase the complexity of the DAX code required.

A much better solution would be an interaction between data model and DAX measure that allow to consider both parts of the problem to wizards/templates defined to solve the very same problems that the Quick Measures try to solve. Enabling user to write common calculations in an easy and safe way. Thus, you can look at Quick Measures, but they are not increasing productivity of advanced users, and don’t solve all the problems to newbies. There is a lot of work to do in that area.

Lars: Alberto and you have many offers for people willing to learn tabular Data Modeling and DAX at SQLBI. From books, to in-persona trainings and video courses. Can you tell the reader something about that? From newbie to professional: With which of your products should I start and end?

Marco: Our mission is to transfer knowledge and accelerate the adoption of a new technology. We do that providing books, video courses, classroom courses, conferences, and consulting. We offer these services on our website, www.sqlbi.com, which hosts our production of free articles, whitepapers, and tools. We also have a free video course, Introduction to DAX, which is our suggestion to start learning DAX. The road to learn DAX also require some data modeling experience. We have a dedicated web page that suggest the learning path depending on the products used. We will update and improve that page in the new website that will be ready before the end of 2017.

Lars: From your professional experience as a trainer, what is the most common mistake, students make when learning DAX? Can you tell us how to avoid that?

Marco: The most common mistake is trying to learn by example. The only complexity of the DAX is that there are a few abstract concepts that are unique to this language and do not exists in any other one.

The notion of filter context and context transition is a brilliant solution to a complex problem. Basically, it is simple to explain and to learn, but it takes time to digest because it is different from everything else you already know. I have seen very smart developers and seasoned BI developers doing the same mistake.

You will save a lot of time if you accept that there could be a new concept that you have never seen before. I have seen a similar issue with the introduction of object oriented programming. Some developers who wanted to explain a new concept using the old syntax were in trouble. There was something “hidden” that was not working as they expect. Once you accept that there could be something new to learn, you are good to go.

Lars: In my experience many customers are refusing the cloud as the place for their business data. At least in Germany that’s a big issue. But sharing data with Power BI on premise, requires Power BI Report Server, which is pretty expensive. How do your clients usually deal with the cloud topic and how do you handle that?

Marco: I am in a biased position. My customers call us because they already adopted Analysis Services or Power BI. Usually, I do not participate to the presales discussion involving choices between on-premises and cloud options. I know that there are companies that want to keep data on premises, and companies that want to go to the cloud.

My point of view about this is that in the long run, all the companies will go to the cloud, with small exceptions: military and certain government agencies. These exceptions will probably run the same cloud technologies on-premises in a controlled and isolated environment. Outside these exceptions, the question is not if but when. The reason is a good one: money. Managing the same service at scale in the cloud is less expensive, once you compute the total cost of ownership. The time for the cloud adoption will vary based on differences in markets, culture, policy, laws, bandwidth, skills, and probably much else. But this will happen. For the same reason why companies no longer develop their own operating system, their own compiler, their own ERP, and so on.

We can learn from the short history of computer science that what seemed impossible to change in a decade, was completely outdated a few years later. I see that technology adoption in Europe has a much more conservative approach than in other continents. But I do not see a single technology that has been adopted in United States but not in Europe (maybe years later). Well, Europe skipped cable TV going straight to satellite TV. But it is probably the exception that proves the rule.

Lars: With SQLBI you founded OKViz some time ago and provide your own custom visualizations. How critical to Power BI’s success is the fact that the visualizations are open source and can be developed from everybody who is technically capable?

Marco: With OKViz, we created a brand for custom visualizations. As of today, it is a “pure startup”, because it has costs without producing any revenue. The marketplace is not ready, the platform is not ready, and custom visuals are second class citizen by now. Hopefully this will change, and OKViz will be able to increase the production of custom visuals once there will be the conditions for a sustainable economic model.

At the moment, custom visuals are an important tool for Power BI success, but in terms of real adoption, native visualizations are much more used. The biggest challenges are versioning, support, and automatic updates. Creating a stable platform for custom visuals in an environment that evolves every month is incredibly hard. We can easily see the bugs, but not the amount of hidden work to sustain that.

I am optimist for custom visuals in Power BI if this will create a true marketplace. I am skeptical about enabling anyone to create custom visuals. We will never see Power BI users writing visualizations just as an Excel user writes a macro. What is possible is enabling an existing developer to create custom visuals for Power BI. The open source is a very relative advantage. The entire platform is not open source, you cannot extend the code of the platform, you can just copy and adapt other custom visuals. Native visuals are written without using the custom visuals platform, so you cannot derive custom visuals from native visuals.

To recap: I believe custom visuals are extremely important, and we invested a lot on them. However, I would not sell custom visual as something that any Power BI user can adapt according to any specific requirement. Learning curve to write custom visuals is not so quick.

Lars: If you could ask for a new feature in Power BI (what everyone can via ideas.powerbi.com) what would that be?

Marco: My number one is opening API to interact with Power BI Desktop. Let me ask the vote for this: https://ideas.powerbi.com/forums/265200-power-bi-ideas/suggestions/7345565-power-bi-designer-api

This feature would enable the creation of many new tools and solutions.

Lars: Could you name 3 things about Power BI, which make it a great product?

Marco:

• Free access to almost all of the features to start a proof of concept.
• Integration between Query Editor (M), data model (DAX) and visualization.
• Computing power of the engine: it is very hard to find something faster on the market.

Marco, thank you, Alberto, Daniele and all your colleagues behind the scenes, for all the great posts, books, products and community work. I know, there are many people out there (including myself) who are very thankful for all the work you do. To get in touch with Marco, please use the following website.

Lars Schreiber

Lars ist Berater, Entwickler und Trainer für Microsoft Power BI. Er ist zertifizierter Power BI-Experte und Microsoft Trainer. Für sein Engagement in der internationalen Community wurde Lars seit 2017 jährlich durch Microsoft der MVP-Award verliehen. Lies hier mehr…

ssbi-blog.de

Der Beitrag Die persönliche Power BI Journey von Marco Russo (in English as well) erschien zuerst auf THE SELF-SERVICE-BI BLOG.