Experten-Talk – Power BI: Warum Ihr Datenmodell über Erfolg oder Scheitern entscheidet

00:00:00: Herzlich willkommen zu unserer heutigen Analyse.

00:00:03: Schön, dass du bei diesem tiefen Einblick wieder mit dabei bist!

00:00:06: Unsere Mission heute ist ja so alltäglich wie frustrieren für eigentlich jeden der mit Daten arbeitet.

00:00:14: Wir wollen nämlich herausfinden, warum so viele unglaublich schicke optisch echt beeindruckende Power BI der Sports in der Praxis einfach extrem langsam sind.

00:00:24: Du klickst auf einen Filter und

00:00:26: hast plötzlich genug Zeit dir einen Kaffee zu holen!

00:00:28: Genau das kleine Ladesymbol kreist endlos.

00:00:31: Wir schauen uns heute an, wie man diese Berichte in echte Performance-Maschinen verwandelt.

00:00:36: Die Grundlage dafür ist ein sehr detaillierter Fachbeitrag über Power BI Datenmodellierung den wir uns heute vornehmen.

00:00:43: Es geht da stark um die Abkehr von der sogenannten Exelfalle hin zu echter Skalierbarkeit

00:00:48: Und das Kernproblem liegt meistens gar nicht dort wo die Leute zuerst suchen.

00:00:52: es geht um eine fundamentale Transformation in der Denkweise.

00:00:58: Wenn wir über Power BI sprechen, müssen wir verstehen dass das visuelle Frontend also das was der Nutzer am Ende sieht wirklich nur die absolute Spitze des Eisbergs ist.

00:01:08: Diese Exelfalle ist eigentlich ein perfekter Einstieg.

00:01:11: lass uns das Problem direkt mal mit einem Bild aus unserem Material greifbar machen.

00:01:15: Also stell dir vor du baust einen Gartenhaus.

00:01:18: Okay

00:01:19: Da reicht ein einfaches Fundament völlig aus.

00:01:21: Du verdichtest den Boden vielleicht ein bisschen, legst ein paar Gehwegplatten hin und das Ding steht stabil!

00:01:27: Wenn du aber ein dreißigstöckiges Hochhaus bauen willst, brauchst du ein massives tiefes Fundiment aus Stahlbeton.

00:01:34: Richtig – andernfalls stürzt dir die ganze Konstruktion beim ersten Windstoß ein.

00:01:38: Exakt….

00:01:40: Und viele Unternehmen behandeln Power BI genau wie dieses Gartenhaus oder, ich sag mal noch schlimmer einfach wie Echsel auf Steroiden.

00:01:50: Sie investieren wahnsinnig viel Zeit und Geld in dieses optische Dashboard die Farben, die tollen Diagramme aber sie ignorieren das Fundament also das Datenmodell darunter.

00:02:01: Das wird komplett vernachlässigt.

00:02:03: Was hier faszinierend ist, ist die Tatsache dass Power BI seine wache Stärke absolut nicht im Dashboard entfaltet sondern unsichtbar im Hintergrund, eben genau in diesem Datenmodell.

00:02:14: Wenn man dieses Fundament vernachlässigt ist ein langsamer Bericht eigentlich noch das geringste Problem dass man sich einhandelt.

00:02:21: Ohne eine saubere Struktur drohen handfestes Datenkaus und enorme technische Schulden

00:02:26: Was dann richtig teuer wird?

00:02:28: Absolut!

00:02:29: Ein schlechtes Modell nervt nicht nur durch ihre Ladezeiten es produziert irgendwann schlichtweg falsche und widersprüchliche Zahlen Und das ist für jede datengetriebene Entscheidung in einem Unternehmen einfach fatal.

00:02:42: Okay, lass uns das mal entpacken!

00:02:44: Wir müssen zuerst auf die technische Ebene gehen und verstehen wie diese Daten überhaupt physisch verarbeitet werden?

00:02:50: Wir müssen über Zeilen gegen Spalten sprechen.

00:02:53: Ein ganz wichtiger Punkt.

00:02:55: In der klassischen Welt – gerade wenn Leute stark aus dieser Echselrichtung kommen – denken wir immer in geschlossenen Daten setzen… also in Zeilen.

00:03:03: Genau, eine Zeile repräsentiert dann einen Verkauf, einen Kunden oder ein bestimmtes Datum.

00:03:09: Richtig!

00:03:10: Wenn ein klassisches System den Gesamtumsatz berechnen soll muss es theoretisch jeden einzelnen Datensatz also jede Zeile in den Speicherladen und durcharbeiten.

00:03:20: Bei kleinen Datenmengen ist das ein Wimpernschlag.

00:03:23: Aber wenn wir im Power BI plötzlich von Millionen, also zig Millionen Zeilen sprechen

00:03:29: Dann zwingt dieser Ansatz jedem normalen Rechner in die Knie.

00:03:32: Der Rechner wird zur Heizung.

00:03:34: Ja, exakt!

00:03:35: Das ist der Moment in dem wir über den technologischen Quantensprung von Power BI sprechen müssen – die Vertipack-Engine.

00:03:42: Das ist das absolute Herzstück des Software.

00:03:45: Vertipak ist eine In-Memory-Datenbank.

00:03:48: D.h.,

00:03:48: die Daten liegen im Arbeitsspeicher?

00:03:50: Richtig.

00:03:51: Das bedeutet erstens dass die Daten nicht bei jeder Abfrage mühsam von einer langsamen Festplatte gelesen werden sondern komplett im super schnellen Arbeitsspeichern dem Ram liegen.

00:04:03: Und zweitens – und das ist der entscheidende Unterschied zu Excel, speichert Vertipack die Daten nicht in Zeilen sondern spaltenbasiert.

00:04:12: Lass uns das mal veranschaulichen um es richtig zu greifen!

00:04:16: Stell dir vor du hast eine riesige Tabelle aus deinem EAP-System importiert, die hundert verschiedene Spalten hat.

00:04:23: Dein Bericht den Du Dir gerade im Dashboard anschaust zeigt aber im Moment nur ein simples Balkendiagramm sagen wir Umsatz nach Region.

00:04:31: Ein absoluter Klassiker.

00:04:33: Ja, eine klassische Zeilenbasierte Datenbank würde jetzt trotzdem den kompletten Datensatz also alle hundert Spalten für jede einzelne Zeile in den Arbeitssprecher wuchten nur um diese einfache Berechnung durchzuführen.

00:04:48: Was völliger Verschwendung ist?

00:04:49: Total!

00:04:50: Die spaltenbasierte Fattypack-Engine macht aber etwas sehr Schlaues.

00:04:55: sie greift sich exakt nur diese zwei benötigten Spalten nämlich Umsatz und Region.

00:05:01: Die restlichen Achtundneunzig-Spalten existieren für diesen spezifischen Rechenvorgang praktisch gar nicht.

00:05:07: Das spart unfassbar viel Leistung.

00:05:10: Exakt!

00:05:11: Und genau hier schnappt diese Echselfalle, von der wir am Anfang sprachen, erbarmungslos zu.

00:05:17: Aus reiner Gewohnheit importieren viele Anwender riesige Flachetabellen – sogenannte Flat Tables.

00:05:24: Wo dann alles in einer endlosen Wurst

00:05:27: steht?

00:05:28: Ganz genau….

00:05:29: Da steht dann in jeder einzelnen Zeile nicht nur der Verkaufsbetrag, sondern auch der Kundenname die komplette Lieferadresse, die Branche, der zuständige Vertriebler und vielleicht noch ein langes Freitextfeld mit Notizen.

00:05:43: Alles wiederholt sich Millionenfach bei jedem einzelnen Kauf dieses Kunden.

00:05:47: Puh!

00:05:48: Ich warne da wirklich eindringlich davor denn die Forti-Pack Engine ist auf maximale Datenkompression optimiert.

00:05:55: sie nutzt dafür sogenanntes Dictionary Encoding

00:05:58: Warte, lass mich das kurz einordnen.

00:06:01: Das bedeutet wenn in einer Spalte eine Million Mal das Wort Nord für die Region steht dann speichert Power BI diesen Text Nord nicht eine Million mal ab – richtig?

00:06:11: Richtig!

00:06:12: Es erstellt quasi ein internes Wörterbuch, weiß dem Wort Nord eine winzige Zahl zu sagen.

00:06:18: wir einfach die eins und speichern dann in der Spalten nur noch diese winzigen Zahlen

00:06:23: Ganz genau.

00:06:24: Das Wort wird nur ein einziges Mal gespeichert.

00:06:27: Aber wenn du jetzt diese extrem breiten, flachen Tabellen nutzt.

00:06:30: In denen jede Zeile durch redundante Textwüsten und Freitextfelder aufgebläht ist.

00:06:35: In den fast jeder Wert minimal anders geschrieben ist.

00:06:38: Minus Dann zerstörst du diesen Kompressionsvorteil völlig?

00:06:42: Absolut!

00:06:42: Das Wörterbuch wird gigantisch – die Engine kann nicht mehr effizient komprimieren.

00:06:48: Die unmittelbaren Folgen sind explodierende Dateigrößen in deinen Projekten, quälend lange Ladezeiten Und spätestens, wenn du das Ganze in den Power BI-Service in die Cloud publizierst stürzt der Bericht mit Out of Memory Fehlern ab.

00:07:03: Weil das Limit des Arbeitsspeichers einfach gesprengt wird.

00:07:06: Wow!

00:07:08: Hier wird es wirklich interessant.

00:07:09: Denn wenn diese breiten flachen Tabellen so schlecht für die Performance sind stellt sich natürlich die Frage wie bringen wir stattdessen Anatomie und Ordnung in unsere Daten?

00:07:20: Die Antwort der Experten darauf ist das sogenannte Starschema.

00:07:24: Ja Das Starshema ist das A und O.

00:07:27: Ein wunderschöner Vergleich aus unserer Quelle dafür, ist unser Sonnensystem.

00:07:31: Wir nehmen diese eine riesige flache Tabelle und brechen sie auf!

00:07:36: In der Mitte haben wir die Sonne – das sind unsere Fakten-Tabelle.

00:07:40: Sie ist das Gravitationszentrum unseres Modells.

00:07:43: Genau

00:07:44: Hier liegen die harten messbaren Fakte, die Zahlen Verkaufsbeträge Stückzahlen Temperaturen Rabatte.

00:07:52: Diese Fakten-Tabelle kann unfassbar lang sein, hunderte Millionen von Zeilen.

00:07:57: Aber sie ist extrem schmal – Sie enthält fast keinen Text sondern nur Zahlen und IDs.

00:08:03: Richtig!

00:08:04: Und um diese Sonne herum kreisen die Planeten.

00:08:08: Das sind unsere Dimensionstabellen.

00:08:10: Hier liegen all'die beschreibenden Attribute der Kontext zu den nackten Zahlen Die Dinge nach denen du später in deinem Dashboard filtern oder gruppieren willst

00:08:19: Also sowas wie eine Produktdimension

00:08:22: Genau, eine Produktdimension mit Kategorien, Farben und Herstellern.

00:08:26: Eine Zeitdimension von Jahren, Quartalen und Monaten oder eine Kundendimension mit Adressen und Branchen.

00:08:33: Jeder Kunde jedes Produkt existiert in diesen Planetentabellen genau ein einziges

00:08:39: Mal.".

00:08:39: Das macht es strukturell total ein.

00:08:42: aber warum macht das den Gericht am Ende so viel schneller als wenn ich einfach alles in einer Tabelle lasse?

00:08:47: Es müssen ja trotzdem ständig Verbindungen zwischen den Tabellen berechnet werden!

00:08:51: Der enorme Geschwindigkeitsvorteil entsteht durch die Magie der Filterpropagation.

00:08:56: Das ist der technische Mechanismus, wie Filter in Power BI durch das Modell fließen.

00:09:01: In einem sauberen Starschema fließen Filter immer nur in eine einzige Richtung Von der einen Seite also dem Planeten zur M-Seite der Sonne

00:09:11: Also von der Dimension.

00:09:12: zu den Fakten?

00:09:13: Exakt!

00:09:14: Wenn du jetzt in deinem Dashboard sagst Zeige mir nur den Umsatz für die Region Süd, dann durch Sucht Power BI eben nicht die Fakten-Tabelle mit ihren hundert Millionen Zeilen nach dem Wort Süd.

00:09:23: Das würde ewig dauern!

00:09:25: Stattdessen filtert die Engine zuerst die winzig kleine Kundendimensionen.

00:09:29: Dort bleiben vielleicht nur fünfhundert Kundenids übrig – die im Süden liegen.

00:09:33: Dies an die riesige Faktentabelle weiter.

00:09:36: Wird die Pack muss jetzt nur noch nach diesen Zahlenwerten greifen?

00:09:39: Das ist hoch effizient und passiert in Millisekunden.

00:09:42: Wahnsinn Wenn wir schon beim Auftein von Tabellen sind, manchmal sehe ich Modelle wo die Planeten noch eigene Munde haben.

00:09:51: Also ich habe eine Dimension für Produkte und an diese Produkttabelle hänge ich noch eine weitere Tabelle für Produktkategorien und daran vielleicht noch eine für den Hersteller.

00:10:01: Ja das sieht man oft!

00:10:02: Man normalisiert die Daten also komplett durch wie man es in klassischen relationalen Datenbanken mal gelernt hat um wirklich jedes Reduzante beizusparen.

00:10:11: Das nennt man dann das Snowflake-Schema, weil es sich wie eine Schneeflocke verästelt.

00:10:15: Und genau da sprichst du ne weitere gefährliche Falle an!

00:10:19: In der klassischen IT bei transaktionalen SQL Datenbanken ist diese Normalisierung völlig richtig – aber für Power BI und die Vertipack Engine muss ich davor wirklich warn'n.

00:10:31: Warum genau?

00:10:32: Jede zusätzliche Verknüpfung jeder extra Sprunk den die Engine über diese Tabellen machen muss kostet wertvolle CPU Zyklen.

00:10:40: Die Engine muss den Filter von der Kategorie zum Produkt und dann erst zu den Fakten durchreichen.

00:10:45: Das bremst das System massiv aus!

00:10:48: Die goldene Regel für Power BI lautet daher, baue dein Modell so flach wie möglich – eben als Stern mit nur einem Ring von Planeten aber so strukturiert wie nötig.

00:10:59: Ziehe die Dimensionen nicht künstlich in die Länge.

00:11:01: Nimm die Kategori und den Hersteller und packe sie direkt mit in die Produktabelle.

00:11:06: Dimension dürfen ruhig etwas breiter sein und Redundanzen enthalten.

00:11:10: Dafür haben wir ja die spaltenbasierte Kompression.

00:11:13: Wir haben jetzt also schmale Faktentabellen in der Mitte und flache Dimensionstabellen außen herum.

00:11:20: Lass uns noch einen Schritt tiefer gehen, quasi in die Spalten selbst!

00:11:24: Hier begegnen wir dem oft lautlosen Performance-Killer der ganzen Geschichte – der Kardinalität.

00:11:32: Wenn wir uns das aus der Perspektive des Anwenders anschauen, was genau bedeutet dieses eher sperrige Wort überhaupt in unserem Kontext?

00:11:55: Je mehr Wiederholungen eine Spalte hat, desto kleiner ist das interne Wörterbuch und desto extremer kann komprimiert werden.

00:12:02: Das heißt, eine gute, also nierige Kardinalität wäre zum Beispiel eine Sparte für das Geschlecht oder den Status einer Bestellung – da gibt es vielleicht nur drei oder vier mögliche Ausprägungen wie offen, versendet, storniert!

00:12:17: Diese wenigen Werte wiederholen sich bei Millionen von Bestellungen ständig.

00:12:22: Das lässt sich fantastisch komprimmieren….

00:12:25: Ein echter Albtraum für den Arbeitsspeicher wäre dann eine extrem hohe Kardinalität.

00:12:31: Ein gutes Beispiel dafür ist so ein Zeitstempel auf die Sekunde genau in der Fakten-Tabelle, also ne Spalte in der steht zwölf Uhr, eine Minute und vierundfünfzig Sekunden.

00:12:41: Wenn du so eine Spalte bei Millionen von Transaktionen hast, ist fast jede verdammte Zeile ein Unikat.

00:12:47: Die Engine findet kaum Wiederholungen – das Wörterbuch wird genauso groß wie die Tabelle selbst, die Kompression versagt komplett und der Ram läuft voll!

00:12:56: Ganz genau so ist es….

00:12:58: Viele Anwender importieren aus reiner Gewohnheit oder einem falschen Sicherheitsbedürfnis heraus?

00:13:03: Jede System-ID, jeden kryptischen Belegnummernschlüssel und eben diese hoch detaillierten Zeitstempel aus ihrem ERP-System in Power BI.

00:13:13: Auch wenn Sie es gar nicht brauchen!

00:13:14: Genau, auch wenn sie im finalen Bericht niemals danach filtern oder suchen werden.

00:13:20: Diese Spalten fressen völlig unsichtbar oft achtzig bis neunzig Prozent des gesamten Speicherplatzes des Modells aber wir können daraus sehr konkrete Strategien ableiten um das in den Griff zu bekommen.

00:13:32: ich nenne dass gerne die spalten Diät

00:13:35: Eine Diät für Daten, das gefällt mir.

00:13:37: Wie sieht dieser Trainingsplan aus?

00:13:39: Der Plan hat drei eisene Regeln.

00:13:41: Erstens – Zeitsplitting.

00:13:43: Wenn du wirklich die Uhrzeit brauchst, trenne das Datum und die Zeit ins Weise paratisch balten.

00:13:49: Ein Datum hat pro Jahr nur dreihundertfünfundsechzig eindeutige Werte Und bei der Zeit fragt dich kritisch Brauchst Du für eine Managementanalyse wirklich diese Kunde?

00:13:58: Wahrscheinlich eher selten.

00:13:59: Eben, wenn du die Zeit auf die volle Stunde abrundest oder reduzierst, schrumpft die Kardinalität dieser Spalte von über sixundachtzigtausendvierhundert möglichen Werten an einem Tag auf exakt vierundzwanzig!

00:14:10: Das ist eine massive Ersparnis.

00:14:12: Okay das ist ein riesiger Hebel!

00:14:14: Zweitens – Die Rundung von Dezimalzahlen Ein Währungsbetrag oder ein Gewicht mit fünf- oder sechs Nachkommersstellen ist absolutes Gift für die Engine weil es kaum exakte Übereinstimmungen gibt.

00:14:26: Runde auf zwei Stellen, das reicht analytisch auf aggregierter Ebene fast immer völlig aus.

00:14:30: Macht Sinn!

00:14:32: Und die dritte Regel?

00:14:33: Die absolut wichtigste Regel der Spaltendiät.

00:14:36: Lösche rigoros alles worauf im Bericht nicht explizit gefiltert, gruppiert oder gerechnet wird.

00:14:42: Wenn eine Spalte nur nice to have ist, wirf sie raus.

00:14:46: Was nicht da ist muss nicht komprimiert und nicht dem Speicher gehalten werden.

00:14:50: Also was bedeutet das alles, wenn wir jetzt zu dem Punkt kommen an den die meisten Anwender graue Haare bekommen?

00:14:56: DAX.

00:14:56: Data Analysis Expressions – Die Formel Sprache in Power BI.

00:15:00: Oft sieht man in Foren oder bei Kunden diese absoluten Monsterformeln.

00:15:05: Oh ja!

00:15:05: Die kenne ich gut.

00:15:06: Die Gehen über zehn Zeilen sind verschachtelt mit Calculate, Filter, L-Accept und am Ende weiß nicht mal mehr der Entwickler selbst was da eigentlich passiert.

00:15:15: Man schiebt es dann oft darauf dass DAX einfach eine furchtbar komplizierte Sprache

00:15:20: ist.

00:15:23: Das Problem ist meistens gar nicht fehlendes DAX Wissen oder?

00:15:27: Das Problem is ein unsauberes Datenmodell das regelrecht gegen den Entwickler arbeitet.

00:15:32: Wenn ich kein sauberes Dar-Schema habe, muss sich DAX zwingen Beziehungen und Filterkontexte künstlich herzustellen die physisch gar nicht existieren.

00:15:46: In einem chaotischen Modell vielleicht mit vielen flachen Tabellen und bidirektionalen Filterbeziehungen verbringst du Stunden damit, mit komplexem DAX mühsam um Ecken herum zu programmieren.

00:16:03: Nur um strukturelle Fehler im Modell auszugleichen.

00:16:06: Das frustriert dann total

00:16:07: Richtig!

00:16:08: In einem sauberen strikten Starschema hingegen definierst Du einen Measure sagen wir den nettoumsatz hier to date ein einziges mal ganz zentral in der Fakten-Tabelle.

00:16:19: Und weil die Filterpropagation sauber von den Dimensionen dorthin fließt, ist die DAX-Formel extrem kurz und elegant – oft nur ein simples Summen.

00:16:28: Ein echter Power BI-Profi verbringt siebzig Prozent seiner Entwicklungszeit im Power QE Editor und in der Datenmodellierung um das Fundament zu gießen und nur dreißig Prozent mit DAX und dem eigentlichen Dashboarddesign.

00:16:41: Diese siebzig Prozent im Backend aufzuwenden baut auch einen unglaublich wichtigen Schutzschild auf.

00:16:47: Wir sprechen hier über technische Schulden, in der Praxis steht man ja oft unter enormem Zeitdruck.

00:16:52: Der Chef will das Dashboard am Freitag sehen also lädt man die Tabellen einfach schnell rein zieht ein paar bunte Balken auf und zack fertig.

00:16:59: Das rächt sich aber ganz schnell

00:17:01: Genau!

00:17:01: Das Problem ist dass solche schnell Unsauberen Lösungen, dich später ein vielfaches an Zeit kosten.

00:17:09: Stell dir vor du hast als Datenquelle einen historisch gewachsenes völlig chaotisches RP-System.

00:17:14: Da ändern sich mal Spaltennamen Tabellen werden von der IT umgebaut Datentypen wechseln.

00:17:19: Wenn du deine Berichte direkt auf dieses Chaos baust verschießt es dir bei jeder Änderung sofort alle der Sports

00:17:26: Völlig richtig.

00:17:27: Ein gutes Datenmodell, das schon vorne in Power Query sauber transformiert und dann in ein Starschema gegossen wird wirkt wie eine dicke Isolationsschicht gegen dieses Chaos der Quellsysteme.

00:17:38: Wenn die IT im ERP-System plötzlich die Spalte Umsatz Netto V II in NetRevenue Global umbenennt bricht bei dir keine Panik aus!

00:17:45: Weil du es an einem zentralen Ort fixen kannst.

00:17:48: Genau Du gehst in.

00:17:49: dein Power BI-Model passt genau an einer einzigen Stelle im Power Querry Die Verbindung und den Namen an Und dein sauberes Modell, mitsamt allen DAX-Measures bleibt völlig intakt.

00:18:00: Alle Berichte die auf diesem Modell basieren funktionieren sofort und gestört weiter.

00:18:05: Ohne diese Isolationsschicht müsstest du jetzt in fünfzig verschiedenen Dashboards manuell die kaputten Diagramme flicken!

00:18:20: Viele Firmen kennen dieses spezielle Chaos.

00:18:23: Power BI wird eingeführt, die ersten Dashboards sind ein Riesenerfolg und plötzlich denkt sich jede Fachabteilung hey das können wir auch!

00:18:31: Der klassische Wildwuchs.

00:19:00: Das ist der absolute Worst Case, aber leider in der Praxis extrem weit verbreitet.

00:19:07: Die Enterprise-Lösung dafür ist die strikte physische Trennung von Modell und Bericht.

00:19:13: Man baut nicht mehr beides in einer Datei – stattdessen setzt sich ein Team von echten Datenexperten hin und baut ein einziges hochoptimiertes blitzschnelles Datenmodell!

00:19:23: eben dieses golden Data Set.

00:19:25: Die eine Quelle der Wahrheit, garl

00:19:27: ob HR, Vertrieb oder Marketing öffnen nur noch leere Power BI-Dateien und verbinden sich über eine sogenannte Live Connection mit genau diesem zentralen Modell.

00:19:38: Sie konsumieren die vorgefertigten korrekten Measures ohne die Logik verändern zu können.

00:19:43: Das ist auch genau der Moment wo diese richtig mächtigen fortgeschrittenen Techniken ins Spiel kommen, die ein Modell extrem performant machen.

00:19:52: Wir reden da zum Beispiel über Aggregationen.

00:19:55: Wenn man das greifbar machen will, ist es wie in einem großen Restaurant.

00:19:59: Ein schönes Bild!

00:20:00: Wenn der Geschäftsführer am Ende des Monats wissen will, wie viele Burger insgesamt verkauft wurden muss der Buchhalter ja nicht in die Küche gehen und jeden einzelnen Kassenzettel mit allen Zutaten von jeder einzelne Bestellung des Monates durchlesen.

00:20:14: Das wären ja Millionen von Zeilen.

00:20:16: Er schaut sich einfach das Tagesabschlussbuch an wo die Summen schon fertig drin stehen.

00:20:20: Genau

00:20:21: Aggregationen in Power BI machen genau das.

00:20:24: Man baut kleine, vorgerechnete Tabellen für die groben Übersichten unsichtbar in das Modell ein.

00:20:30: Wenn der Nutzer nur den Jahresumsatz sehen will, greift das System auf diese winzige Aggregations-Tabelle zu und ist in Millisekunden fertig!

00:20:38: Erst wenn der Nutzar per Drilldown tief ins Detail geht und einen bestimmten Tag sehen will – weckt Power BI die große Faktentabelle auf.

00:20:51: Wenn du eine Fakten-Tabelle mit Hundert Millionen Transaktionen aus den letzten fünf Jahren hast, ist es absoluter Wahnsinn diese Datenmassen jede Nacht beim automatischen Refresh komplett neu aus dem Quellsystem zu laden.

00:21:04: Das dauert ja Stunden!

00:21:06: Genau.

00:21:06: Beim inkrementellen Laden teilt man Power BI mit – pass auf….

00:21:10: Die historischen Daten der letzten Jahre sind abgeschlossen die verändern sich nicht mehr.

00:21:15: also friere sie im Speicher ein Lade jeden Tag nur die frischen Daten der letzten vierundzwanzig Stunden neu dazu.

00:21:22: Das reduziert die Ladezeiten von Stunden auf wenige Minuten und entlastet die RT-Systeme

00:21:27: enorm.".

00:21:27: Wenn man all das kombiniert, dass Starschema, die Spaltendiet, sauberes DAX durch ein zentrales Golden Data Set – dann erreicht man erst das was immer so großmundig versprochen wird, echte Demokratisierung von Daten!

00:21:41: Erst wenn dieses felsenfeste Fundament steht, können auch Mitarbeiter ohne großen IT-Hintergrund ihre eigenen Berichte im Selbstservice zusammenklicken.

00:21:50: Sie müssen sich keine Sorgen mehr machen, ob sie die Zahlen verfälschen oder ob sie den Firmenserver zum Absturz bringen, wenn sie einen Filter setzen – weil das robuste Modell im Hintergrund die ganze Schwerarbeit und Fehlervermeidung

00:22:01: übernimmt.".

00:22:02: Genau das ist die Definition von erfolgreichem Safe Service BI!

00:22:06: Es funktioniert ausschließlich auf einem sicheren zentralisierten und hochperformanten Fundament.

00:22:12: Wahnsinnig spannend!

00:22:13: Wir sind damit auch schon am Ende unserer heutigen Analyse angekommen, lass uns das Wichtigste für dich zusammenfassen.

00:22:19: Warum solltest du dir all diese Konzepte heute überhaupt merken?

00:22:24: Die optische Gestaltung – Das schicke Dashboard mit den abgerundeten Ecken – ist buchstäblich nur die Spitze des Eisbergs.

00:22:30: Absolut

00:22:32: Wenn du in deinem nächsten Projekt vor der Wahl stehst, deine knappe Zeit in ein noch cooleres Design oder in die Bereinigung und Strukturierung deines Datenmodells zu investieren, wähle immer – wirklich ausnahmslos immer das Modell.

00:22:45: Ein brillantes super-schnelles Modell rettet auch ein mittelmäßiges Design weil die Nutzer schnelle korrekte Antworten einfach lieben!

00:22:53: Aber kein Design der Welt, keine noch so schönen Farben können ein langsames fehlerhaftes Modell kompensieren bei dem die Nutzer dem Ergebnis am Ende nicht vertrauen.

00:23:02: So ist es!

00:23:03: Ohne Tränne strickt in Fakten und Dimensionen.

00:23:07: Achte auf die Kardinalität deiner Spalten und verabschiede dich von riesigen flachen Tabellen.

00:23:14: Nur durch diesen technischen Perspektivenwechsel wird Power BI vom teuren Spielzeug zum mächtigen skalierbaren Hebel für dich und dein gesamtes Unternehmen.

00:23:24: Das wirft eine wichtige Frage auf, wenn wir zum Abschluss mal einen Schritt weiter in die nahe Zukunft denken.

00:23:30: Wir stehen ja alle gerade am Anfang dieses riesigen KI-Zeitalters.

00:23:34: Überall in der Softwarewelt heißt es Co-Pilots und KI Tools sollen uns in Sekundenschnelle fertige Dashboards und tiefe Analysen per Sprachbefehl aus unseren Daten generieren.

00:23:44: Ja das ist das große Versprechen grade!

00:23:47: Aber überleg dir mal folgendes... Wenn wir als Menschen schon enorme Probleme haben, ein chaotisches Spaghetti-Modell mit flachen Tabellen unsauberer Kardinalität und fehlender Struktur richtig zu interpretieren.

00:24:01: Was passiert dann eigentlich wenn wir eine künstliche Intelligenz auf genau so einen unstrukturiertes Fundament loslassen?

00:24:08: Wird die KI dieses Chaos auf wundersame Weise ordnen und unsere Fehler ausbügeln Oder wird sie einfach nur noch viel, viel schneller völlig falsche Zusammenhänge herstellen und diese falschen Zahlen dann auch noch mit absoluter maschineller Überzeugung als Fakt präsentieren.

00:24:22: Wow!

00:24:23: Ein wirklich großartiger und zugleich etwas beängstigender Gedanke zum Abschluss.

00:24:29: Eine KI ist eben auch nur genau so schlau wie die zugrunde liegende Datenstruktur, auf der sie trainiert und arbeitet.

00:24:35: Wenn das Fundament wackelt, baut die KI das Kartenhaus nur noch schneller auf!

00:24:40: Das ist definitiv ein perfekter Grund, dass eigene Datenfundament am besten noch heute aufzuräumen.

00:24:46: Damit verabschieden wir uns für heute von dir.

00:24:48: Vielen Dank, dass du dich mit uns durch dieses absolut essentielle, wenn auch manchmal technische Thema gegraben hast!

00:24:54: Wir hoffen, Du konntest einige echte Aharmomente für deine eigene Architektur und deine tägliche Arbeit mitnehmen.

00:25:00: Bis zum nächsten tiefen Einblick – mach's gut!

00:25:03: Halte Deine Fakten tabellenschmal und baue fleißig Star-Schemas

00:25:07: Auf Wiedersehen und vergiss Deine Spalten dieet nicht.