Modelldaten in einem Lagerhaus

Ohne Datenmodellierung muss jeder Verbraucher herausfinden, welche Tabellen miteinander verknüpft sind, seine eigene Aggregationslogik schreiben und die Bedeutungen der Spalten erraten. Die Datenmodellierung löst dieses Problem durch Einbetten von Struktur, Geschäftslogik und Dokumentation direkt in das Lager. In einem Microsoft Fabric Lager bereiten Sie Daten für die Klarheit vor, definieren Beziehungen zwischen Tabellen, standardisieren den Zugriff durch Ansichten und Kennzahlen und veröffentlichen semantische Modelle für die Berichterstellung. Diese Modellierungsoptionen wirken sich auf jede nachgelagerte Erfahrung aus, einschließlich T-SQL-Abfragen, Power BI-Berichten und KI-gesteuerten Analysen natürlicher Sprachen.

Vorbereiten von Daten für den Verbrauch

Bevor Sie Beziehungen definieren oder Berechnungen hinzufügen, müssen Sie bereinigen, was Verbraucher sehen. Rohdaten von Warehouse-Tabellen enthalten oft Staging-Tabellen, künstliche Schlüsselspalten und interne Kennzeichen, die für die ETL-Verarbeitung und nicht für die Analyse gedacht sind. Diese Objekte erzeugen Rauschen, wenn Verbraucher die Daten durchsuchen. Die Vorbereitung des Lagers für die Nutzung bedeutet, nur relevante Informationen sichtbar zu machen und verständlich zu gestalten.

In der Modellansicht können Sie mehrere Schritte ausführen, um die consumer Erfahrung zu verbessern:

• Interne Objekte ausblenden wie Stagingtabellen, Ersatzschlüsselspalten und ETL-Artefakte, die die Feldliste unübersichtlich machen.
• Benennen Sie Spalten um, um geschäftsfreundliche Namen zu verwenden, bei denen die Lagerspaltennamen technisch oder abgekürzt sind. Beispiel: Umbenennen CustRgn in Customer Region.
• Fügen Sie Beschreibungen zu Tabellen und Spalten hinzu, damit Nutzer verstehen, was die Daten darstellen, ohne auf externe Dokumentation zu verweisen.

Diese Schritte gehen über die bloße Ordnung hinaus. Copilot in Power BI und Fabric-IQ-Daten-Agents basieren auf Tabellennamen, Spaltennamen und Beschreibungen, um Fragen in natürlicher Sprache zu interpretieren und genauen SQL- oder DAX-Code zu generieren. Eine Spalte Customer Region mit einer Beschreibung wie "Geografische Region der primären Adresse des Kunden" erzeugt bessere Ergebnisse in natürlicher Sprache als CustRgn ohne Beschreibung.

Mit sauberen, gut benannten Tabellen können Sie definieren, wie sich diese Tabellen miteinander verbinden.

Grundlegendes zu Beziehungen zwischen Tabellen

Eine Beziehung ist eine logische Verbindung zwischen zwei Tabellen, die das Filtern, Gruppieren und Aggregation über diese Tabellen hinweg ermöglicht. In einem Sternschema verbinden Beziehungen Faktentabellen mit Dimensionstabellen über gemeinsame Schlüsselspalten.

Eine CustomerKey Spalte, die sowohl in FactSales als auch in DimCustomer vorhanden ist, stellt die Verbindung her, die die Analyse von Umsätzen nach Kundenattributen wie Region, Segment oder Kontotyp ermöglicht.

Jede Beziehung hat zwei wichtige Eigenschaften.

• Die Kardinalität beschreibt, wie Zeilen in den beiden Tabellen übereinstimmen. In einem Sternschema sind die Beziehungen zwischen Fakten und Dimensionen typischerweise Viele-zu-Eins, was bedeutet, dass viele Faktenzeilen einer einzigen Dimensionszeile zugeordnet sind.
• Kreuzfilterrichtung bestimmt, auf welche Weise Filter zwischen den Tabellen verteilt werden. Einfache Richtung, bei der die Dimension die Faktentabelle filtert, ist die Standardeinstellung für die meisten Sternschema-Designs, da das Filterverhalten vorhersehbar und effizient bleibt.

Ohne definierte Beziehungen müssen alle Verbraucher, die Daten über Tabellen hinweg kombinieren möchten, explizite Verknüpfungslogik schreiben. Beziehungen beseitigen diese Wiederholung, indem die Verbindung einmal codiert wird. Wenn Sie ein semantisches Modell aus dem Lager erstellen, informieren diese Beziehungen, wie Power BI-, Copilot- und Fabric IQ-Datenagenten die Daten interpretieren. Daten-Agents verwenden z. B. Beziehungen, um genaue Verknüpfungen zu generieren, wenn Fragen in natürlicher Sprache in SQL übersetzt werden.

Standardisieren des Datenzugriffs mit Ansichten und Maßen

Nachdem Ihre Tabellen sauber und verbunden sind, besteht der nächste Schritt darin, Verbrauchern zuverlässige, konsistente Methoden zum Abfragen und Berechnen dieser Daten zu geben. Ohne Standardisierung schreibt jedes Team seine eigene Verknüpfungslogik, wendet seine eigenen Filter an und definiert seine eigenen Formeln, was zu widersprüchlichen Ergebnissen führt.

Ansichten bieten diese Konsistenz für T-SQL-Nutzer. Eine Ansicht kapselt Verknüpfungslogik, Filter und Spaltenauswahlen in einer wiederverwendbaren Abfrage, auf die Verbraucher wie eine Tabelle verweisen. Beispielsweise bietet eine Ansicht, die Fakten- und Dimensionstabellen verknüpft, nach abgeschlossenen Bestellungen filtert und nur die benötigten Spalten für Analysten anzeigt, jedem T-SQL-Verbraucher einen zuverlässigen Ausgangspunkt. Ansichten dienen auch als stabile Datenquellen für Berichte. Anstatt Berichte direkt anhand von Basistabellen zu erstellen, die sich ändern könnten, können Sie Berichte auf Ansichten verweisen, die ein konsistentes Shape darstellen.

Measures bieten die gleiche Konsistenz für DAX-Berechnungen. Ein Measure ist ein wiederverwendbarer DAX-Ausdruck, der Berechnungen wie Summe, Mittelwert, Verhältnis oder Anzahl definiert. Sie erstellen Measures direkt in der Lagermodellansicht, indem Sie eine Tabelle auswählen und ein neues Measure hinzufügen. Beispielsweise stellt ein Total Sales Maß, das die Spalte SalesAmount summiert, sicher, dass jeder Verbraucher dieselbe Berechnung verwendet.

Da die Measuredefinition mit den Daten lebt, wird sie zur einzigen Quelle der Wahrheit für diese Metrik. Wenn das Unternehmen die Berechnung des Umsatzes ändert, aktualisieren Sie die Maßzahl an einer zentralen Stelle, anstatt jeden Bericht durchsuchen zu müssen, der seine eigene Formel enthält.

Zusammen decken Ansichten und Maßnahmen beide Seiten des Verbrauchs ab: Ansichten standardisieren, wie T-SQL-Konsumenten auf Daten zugreifen und diese abfragen, während Maßnahmen die Darstellung von Geschäftsberechnungen in Berichten und Dashboards standardisieren.

Erstellen eines semantischen Modells für Die Power BI-Berichterstellung

Mit vorbereiteten Tabellen, definierten Beziehungen und standardisierten Ansichten und Kennzahlen ist das Lager für nachgelagerte Berichte bereit. Teams, die das Lager direkt mithilfe von T-SQL abfragen oder über Drittanbietertools verbinden, können mit dem Lagermodell as-isarbeiten. Wenn Sie jedoch interaktive Power BI-Berichte und Dashboards erstellen möchten, ist das Erstellen eines semantischen Modells der nächste Schritt.

Semantische Modelle, die aus einem Fabric Warehouse erstellt wurden, verwenden den Direct Lake-Modus. Im Gegensatz zum herkömmlichen Importmodus, der Daten in den Power BI-Speicher kopiert, liest Direct Lake Daten direkt aus OneLake-Parkettdateien. Dies bedeutet, dass Berichte die neuesten Lagerdaten widerspiegeln, ohne dass geplante Aktualisierungen erforderlich sind. Es bedeutet auch, dass Sie den Speicher- und Verarbeitungsaufwand für die Erhaltung einer separaten Kopie der Daten vermeiden.