Dimensionale Modellierung in Microsoft Fabric Warehouse: Tabellen laden

Gilt für:✅ SQL-Analyseendpunkt und Warehouse in Microsoft Fabric

Dieser Artikel enthält Anleitungen und bewährte Methoden zum Laden von Dimensions- und Faktentabellen in einem dimensionalen Modell. Er bietet eine praktische Anleitung für das Warehouse in Microsoft Fabric, das viele T-SQL-Funktionen wie die Erstellung von Tabellen und die Verwaltung von Daten in Tabellen unterstützt. Sie haben also die vollständige Kontrolle über die Erstellung Ihrer Dimensionsmodelltabellen und das Laden dieser mit Daten.

Laden eines dimensionalen Modells

Das Laden eines dimensionalen Modells umfasst in regelmäßigen Abständen das Ausführen eines ETL-Prozesses (Extrahieren, Transformieren und Laden). Ein ETL-Prozess koordiniert die Ausführung anderer Prozesse, die sich im Allgemeinen mit dem Staging von Quelldaten, der Synchronisierung von Dimensionsdaten, dem Einfügen von Zeilen in Faktentabellen und der Aufzeichnung von Überwachungsdaten und Fehlern befassen.

Für eine Fabric Warehouse-Lösung können Sie Data Factory verwenden, um Ihren ETL-Prozess zu entwickeln und auszuführen. Der Prozess kann Quelldaten in Ihre dimensionalen Modelltabellen stufen, transformieren und laden.

Insbesondere bestehen die folgenden Möglichkeiten:

• Verwenden Sie Datenpipelines, um Workflows zu erstellen, um den ETL-Prozess zu koordinieren. Datenpipelines können SQL-Skripts, gespeicherte Prozeduren und vieles mehr ausführen.
• Verwenden Sie Dataflows, um Logik mit geringem Code zu entwickeln, um Daten aus Hunderten von Datenquellen aufzunehmen. Dataflows unterstützen das Kombinieren von Daten aus mehreren Quellen, das Transformieren von Daten und das anschließende Laden in ein Ziel, z. B. eine dimensionale Modelltabelle. Dataflows werden mithilfe der vertrauten Power Query-Oberfläche erstellt, die heute in vielen Microsoft-Produkten verfügbar ist, einschließlich Microsoft Excel und Power BI Desktop.

Orchestrierung

Der allgemeine Workflows eines ETL-Prozesses umfasst Folgendes:

1. Laden Sie optional Stagingtabellen.
2. Prozessdimensionstabellen.
3. Prozess-Faktentabellen.
4. Führen Sie optional Nachbearbeitungsaufgaben aus, z. B. das Auslösen der Aktualisierung abhängiger Fabric-Inhalte (z. B. ein Semantikmodell).

Dimensionstabellen sollten zuerst verarbeitet werden, um sicherzustellen, dass alle Dimensionsmitglieder gespeichert werden, einschließlich derjenigen, die seit dem letzten ETL-Prozess zu Quellsystemen hinzugefügt wurden. Wenn Abhängigkeiten zwischen Dimensionen vorhanden sind, wie bei ausgehenden Dimensionen, sollten Dimensionstabellen in der Reihenfolge der Abhängigkeit verarbeitet werden. Beispielsweise sollte eine Geografiedimension, die von einer Kundendimension und einer Anbieterdimension verwendet wird, vor den anderen beiden Dimensionen verarbeitet werden.

Faktentabellen können verarbeitet werden, sobald alle Dimensionstabellen verarbeitet werden.

Wenn alle dimensionalen Modelltabellen verarbeitet werden, können Sie die Aktualisierung abhängiger Semantikmodelle auslösen. Es ist auch ratsam, eine Benachrichtigung an relevante Mitarbeiter zu senden, um sie über das Ergebnis des ETL-Prozesses zu informieren.

Bereitstellen von Daten

Das Staging von Quelldaten kann dazu beitragen, dass Daten geladen und Transformationsanforderungen erfüllt werden. Es umfasst das Extrahieren von Quellsystemdaten und das Laden in Stagingtabellen, die Sie zur Unterstützung des ETL-Prozesses erstellen. Es wird empfohlen, Quelldaten bereitzustellen, da dies möglich ist:

• Minimieren Sie die Auswirkungen auf Betriebssysteme.
• Wird verwendet, um die ETL-Verarbeitung zu unterstützen und zu optimieren.
• Bietet die Möglichkeit, den ETL-Prozess neu zu starten, ohne dass die Daten aus den Quellsystemen neu geladen werden müssen.

Daten in Stagingtabellen sollten niemals Geschäftsbenutzern zur Verfügung gestellt werden. Es ist nur für den ETL-Prozess relevant.

Es wird empfohlen, ein Schema im Lager zu erstellen, möglicherweise mit dem Namen staging. Stagingtabellen sollten den Quelltabellen in Bezug auf Spaltennamen und Datentypen so nah wie möglich ähneln. Der Inhalt jeder Tabelle sollte zu Beginn des ETL-Prozesses entfernt werden. Beachten Sie jedoch, dass Fabric Warehouse-Tabellen nicht abgeschnitten werden können. Stattdessen können Sie jede Stagingtabelle ablegen und neu erstellen, bevor Sie sie mit Daten laden.

Sie können auch Datenvirtualisierungsalternativen als Teil Ihrer Stagingstrategie in Betracht ziehen. Verwenden Sie Folgendes:

• Spiegelung, eine kostengünstige und latenzarme Turnkey-Lösung, mit der Sie eine Kopie Ihrer Daten in OneLake erstellen können. Weitere Informationen finden Sie unter Warum Spiegelung in Fabric verwenden?.
• OneLake-Verknüpfungen, die auf andere Speicherorte verweisen, die Ihre Quelldaten enthalten können. Verknüpfungen können als Tabellen in T-SQL-Abfragen verwendet werden.
• PolyBase in SQL Server, eine Datenvirtualisierungsfunktion für SQL Server. PolyBase ermöglicht T-SQL-Abfragen, Daten aus externen Quellen mit relationalen Tabellen in einer Instanz von SQL Server zu verknüpfen.
• Mit der Datenvirtualisierung von Azure SQL Managed Instance können Sie T-SQL-Abfragen für Dateien ausführen, die Daten in gängigen Datenformaten in Azure Data Lake Storage (ADLS) Gen2 oder Azure Blob Storage speichern, und sie über Joins mit lokal gespeicherten relationalen Daten kombinieren.

Transformieren von Daten

Die Struktur Ihrer Quelldaten ähnelt möglicherweise nicht den Zielstrukturen ihrer dimensionalen Modelltabellen. Daher muss Ihr ETL-Prozess die Quelldaten so ändern, dass sie an der Struktur der dimensionalen Modelltabellen ausgerichtet sind.

Außerdem muss das Data Warehouse bereinigte und konforme Daten liefern, sodass Quelldaten möglicherweise transformiert werden müssen, um Qualität und Konsistenz sicherzustellen.

Hier sind einige Transformationen, die ihr ETL-Prozess ausführen könnte.

• Kombinieren von Daten: Daten aus verschiedenen Quellen können auf der Grundlage übereinstimmender Schlüssel integriert (zusammengeführt) werden. Beispielsweise werden Produktdaten in verschiedenen Systemen (z. B. Herstellung und Marketing) gespeichert, die jedoch alle eine gemeinsame Lagermengeneinheit (SKU) verwenden. Daten können auch angehängt werden, wenn sie eine gemeinsame Struktur haben. Verkaufsdaten werden beispielsweise in mehreren Systemen gespeichert. Eine Vereinigung der Verkäufe aus den einzelnen Systemen kann eine Obermenge aller Verkaufsdaten erzeugen.
• Datentypen konvertieren: Datentypen können in diejenigen konvertiert werden, die in den dimensionalen Modelltabellen definiert sind.
• Berechnungen: Berechnungen können durchgeführt werden, um Werte für die dimensionalen Modelltabellen zu erzeugen. Bei einer Dimensionstabelle für Mitarbeiter können Sie beispielsweise Vor- und Nachnamen verketten, um den vollständigen Namen zu erstellen. Ein weiteres Beispiel: Für Ihre Umsatzfaktentabelle könnten Sie den Bruttoumsatz berechnen, der das Produkt aus Stückpreis und Menge ist.
• Erkennen und Verwalten von historischen Änderungen: Änderungen können erkannt und entsprechend in Dimensionstabellen gespeichert werden. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Historische Änderungen verwalten.
• Aggregierte Daten: Aggregation kann verwendet werden, um die Faktentabellendimensionalität zu reduzieren und/oder die Granularität der Fakten zu erhöhen. Die Umsatzfaktentabelle muss zum Beispiel keine Auftragsnummern speichern. Daher kann ein aggregiertes Ergebnis, das nach allen Dimensionsschlüsseln gruppiert ist, zur Speicherung der Faktentabellendaten verwendet werden.

Laden der Daten

Sie können Tabellen in einem Fabric Warehouse laden, indem Sie die folgenden Datenerfassungsoptionen verwenden.

• COPY INTO (T-SQL): Diese Option ist nützlich, wenn die Quelldaten Parquet- oder CSV-Dateien umfassen, die in einem externen Azure-Speicherkonto gespeichert sind, z. B. ADLS Gen2 oder Azure Blob Storage.
• Datenpipelines: Neben der Orchestrierung des ETL-Prozesses können Datenpipelines auch Aktivitäten enthalten, die T-SQL-Anweisungen ausführen, Lookups durchführen oder Daten von einer Datenquelle zu einem Ziel kopieren.
• Dataflows: Als Alternative zu Datenpipelines bieten Dataflows eine codefreie Möglichkeit zur Transformation und Bereinigung von Daten.
• Lagerübergreifende Erfassung: Wenn die Daten im selben Arbeitsbereich gespeichert sind, ermöglicht die lagerhausübergreifende Aufnahme die Verknüpfung verschiedener Lagerhaus- oder Lakehouse-Tabellen. Sie unterstützt T-SQL-Befehle wie INSERT…SELECT, SELECT INTO und CREATE TABLE AS SELECT (CTAS). Diese Befehle sind besonders hilfreich, wenn Sie Daten aus Stagingtabellen innerhalb desselben Arbeitsbereichs transformieren und laden möchten. Außerdem handelt es sich um mengenbasierte Operationen, was wahrscheinlich die effizienteste und schnellste Methode zum Laden von Dimensionsmodelltabellen ist.

Logging

ETL-Prozesse erfordern in der Regel dedizierte Überwachung und Wartung. Aus diesen Gründen wird empfohlen, die Ergebnisse des ETL-Prozesses in nichtdimensionalen Modelltabellen in Ihrem Lager zu protokollieren. Sie sollten eine eindeutige ID für jeden ETL-Prozess generieren und verwenden, um Details zu jedem Vorgang zu protokollieren.

Erwägen Sie die Protokollierung:

• Der ETL-Prozess:
  • Eine eindeutige ID für jede ETL-Ausführung
  • Startzeit und Beendigungszeit
  • Status (Erfolg oder Fehler)
  • Alle aufgetretenen Fehler
• Jede Staging- und dimensionale Modelltabelle:
  • Startzeit und Beendigungszeit
  • Status (Erfolg oder Fehler)
  • Eingefügte, aktualisierte und gelöschte Zeilen
  • Anzahl der endgültigen Tabellenzeilen
  • Alle aufgetretenen Fehler
• Andere Vorgänge:
  • Startzeit und Endzeit der Aktualisierungsvorgänge des semantischen Modells

Prozessdimensionstabellen

Die Verarbeitung einer Dimensionstabelle umfasst die Synchronisierung der Data Warehouse-Daten mit den Quellsystemen. Quelldaten werden zuerst transformiert und für das Laden in die Dimensionstabelle vorbereitet. Diese Daten werden dann mit den vorhandenen Dimensionstabellendaten abgeglichen, indem sie mit den Geschäftsschlüsseln verknüpft werden. Anschließend können Sie ermitteln, ob die Quelldaten neue oder geänderte Daten darstellen. Wenn die Dimensionstabelle die langsam ändernde Dimension (SCD) Typ 1 anwendet, werden die Änderungen durch Aktualisierung der bestehenden Dimensionstabellenzeilen vorgenommen. Wenn die Tabelle SCD-Typ 2 anwendet, ist die vorhandene Version abgelaufen und eine neue Version eingefügt.

Das folgende Diagramm zeigt die Logik, die zum Verarbeiten einer Dimensionstabelle verwendet wird.

Betrachten Sie den Prozess der Product-Dimensionstabelle.

• Wenn dem Quellsystem neue Produkte hinzugefügt werden, werden Zeilen in die Product-Dimensionstabelle eingefügt.
• Wenn Produkte geändert werden, werden vorhandene Zeilen in der Dimensionstabelle entweder aktualisiert oder eingefügt.
  • Wenn SCD-Typ 1 angewendet wird, werden Aktualisierungen an den vorhandenen Zeilen vorgenommen.
  • Beim SCD-Typ 2 werden Aktualisierungen vorgenommen, um die aktuellen Zeilenversionen ablaufen zu lassen und es werden neue Zeilen eingefügt, die die aktuelle Version darstellen.
  • Wenn SCD-Typ 3 angewendet wird, tritt ein Prozess auf, der dem SCD-Typ 1 ähnelt, und aktualisiert die vorhandenen Zeilen, ohne neue Zeilen einzufügen.

Ersatzschlüssel

Es wird empfohlen, dass jede Dimensionstabelle über einen Ersatzschlüssel verfügt, der den kleinsten möglichen Integer-Datentyp verwenden sollte. In SQL Server-basierten Umgebungen erfolgt dies in der Regel durch Erstellen einer Identitätsspalte. Dieses Feature wird jedoch nicht in Fabric Warehouse unterstützt. Stattdessen müssen Sie eine Problemumgehungsmethode verwenden, die eindeutige Bezeichner generiert.

Verwalten von historischen Änderungen

Wenn eine Dimensionstabelle historische Änderungen speichern muss, müssen Sie eine sich langsam ändernde Dimension (SCD) implementieren.

Es ist möglich, dass eine Dimension SCD-Typ 1- und/oder SCD-Typ 2-Änderungen unterstützen kann.

SCD Typ 1

Wenn SCD-Typ 1-Änderungen erkannt wird, verwenden Sie die folgende Logik.

1. Aktualisieren Sie alle geänderten Attribute.
2. Wenn die Tabelle die Spalten Datum der letzten Änderung und Letzte Änderung durch enthält, geben Sie das aktuelle Datum und den Prozess an, der die Änderungen vorgenommen hat.

SCD Typ 2

Wenn SCD-Typ 2-Änderungen erkannt wird, verwenden Sie die folgende Logik.

1. Lassen Sie die aktuelle Version ablaufen, indem Sie die Spalte Enddatum Gültigkeit auf das ETL-Verarbeitungsdatum (oder einen geeigneten Zeitstempel im Quellsystem) und das aktuelle Kennzeichen auf FALSE setzen.
2. Wenn die Tabelle die Spalten Datum der letzten Änderung und Letzte Änderung durch enthält, geben Sie das aktuelle Datum und den Prozess an, der die Änderungen vorgenommen hat.
3. Fügen Sie neue Elemente ein, bei denen die Spalte mit dem Gültigkeitsbeginn auf den Wert der Spalte mit dem Gültigkeitsende gesetzt ist (zur Aktualisierung der vorherigen Version) und bei denen das Kennzeichen für die aktuelle Version auf TRUE gesetzt ist.
4. Wenn die Tabelle die Spalten Erstellungsdatum und Erstellung durch enthält, legen Sie das aktuelle Datum und den Prozess fest, der die Einfügungen vorgenommen hat.

SCD Typ 3

Wenn SCD-Typ 3-Änderungen erkannt werden, aktualisieren Sie die Attribute mithilfe einer ähnlichen Logik zur Verarbeitung von SCD-Typ 1.

Löschungen von Dimensionselementen

Seien Sie vorsichtig, wenn die Quelldaten darauf hinweisen, dass Dimensionselemente gelöscht wurden (entweder weil sie nicht aus dem Quellsystem abgerufen werden oder weil sie als gelöscht gekennzeichnet wurden). Sie sollten Löschungen nicht mit der Dimensionstabelle synchronisieren, es sei denn, Dimensionselemente wurden irrtümlich erstellt und es gibt keine zugehörigen Faktdatensätze.

Die geeignete Möglichkeit zum Behandeln von Quelllöschvorgängen besteht darin, sie als vorläufiges Löschen aufzuzeichnen. Ein vorläufiges Löschen markiert ein Dimensionselement als nicht mehr aktiv oder gültig. Um diesen Fall zu unterstützen, sollte Ihre Dimensionstabelle ein boolesches Attribut mit dem Datentyp Bit enthalten, z. B. IsDeleted. Aktualisieren Sie diese Spalte für alle gelöschten Dimensionselemente auf TRUE (1). Die aktuelle, neueste Version eines Dimensionselements kann in ähnlicher Weise mit einem booleschen (Bit)-Wert in den IsCurrent- oder IsActive-Spalten markiert werden. Alle Berichtsabfragen und Power BI-Semantikmodelle sollten Datensätze herausfiltern, die vorläufig gelöscht werden.

Datumsdimension

Kalender- und Zeitdimensionen sind spezielle Fälle, da sie in der Regel keine Quelldaten enthalten. Stattdessen werden sie mithilfe fester Logik generiert.

Sie sollten die Datumsdimensionstabelle zu Beginn eines jeden neuen Jahres laden, um ihre Zeilen auf eine bestimmte Anzahl von Jahren zu erweitern. Möglicherweise gibt es andere Geschäftsdaten, z. B. Geschäftsjahresdaten, Feiertage, Wochennummern, die regelmäßig aktualisiert werden müssen.

Wenn die Datendimensionstabelle relative Offset-Attribute enthält, muss der ETL-Prozess täglich ausgeführt werden, um Offset-Attributwerte basierend auf dem aktuellen Datum (heute) zu aktualisieren.

Es wird empfohlen, dass die Logik zum Erweitern oder Aktualisieren der Datumsdimensionstabelle in T-SQL geschrieben und in einer gespeicherten Prozedur gekapselt wird.

Prozess-Faktentabellen

Die Verarbeitung einer Faktentabelle umfasst die Synchronisierung der Data Warehouse-Daten mit den Fakten des Quellsystems. Quelldaten werden zuerst transformiert und für das Laden in die Faktentabelle vorbereitet. Dann wird für jeden Dimensionsschlüssel durch einen Lookup der Ersatzschlüsselwert ermittelt, der in der Faktenzeile zu speichern ist. Wenn eine Dimension SCD-Typ 2 unterstützt, sollte der Ersatzschlüssel für die aktuelle Version des Dimensionselements abgerufen werden.

Wenn die Suche nach einem Dimensionsschlüssel fehlschlägt, könnte dies ein Hinweis auf ein Integritätsproblem im Quellsystem sein. In diesem Fall muss die Faktenzeile noch in die Faktentabelle eingefügt werden. Ein gültiger Dimensionsschlüssel muss weiterhin gespeichert werden. Ein Ansatz besteht darin, ein spezielles Dimensionselement (z. B. Unbekannt) zu speichern. Für diesen Ansatz ist eine spätere Aktualisierung erforderlich, um den Wert des tatsächlichen Dimensionsschlüssels ordnungsgemäß zuzuweisen, wenn bekannt.

Ein anderer Ansatz, der relevant ist, wenn der natürliche Schlüssel gültig ist, besteht darin, ein neues Dimensionselement einzufügen und dann seinen Ersatzschlüsselwert zu speichern. Weitere Informationen finden Sie weiter unten in diesem Abschnitt unter Abgeleitete Dimensionselemente.

Das folgende Diagramm zeigt die Logik, die zum Verarbeiten einer Faktentabelle verwendet wird.

Wenn möglich, sollte eine Faktentabelle inkrementell geladen werden, was bedeutet, dass neue Fakten erkannt und eingefügt werden. Eine inkrementelle Ladestrategie ist skalierbarer und reduziert den Workload sowohl für die Quellsysteme als auch für die Zielsysteme.

Hoffentlich können Sie neue Fakten effizient erkennen, indem Sie sich auf Quellsystembezeichner oder Zeitstempel verlassen. Wenn z. B. ein Quellsystem zuverlässig Verkaufsaufträge erfasst, die sequenziert sind, können Sie die neueste abgerufene Verkaufsauftragsnummer speichern (auch als hoher Grenzwert bezeichnet). Der nächste Prozess kann diese Verkaufsauftragsnummer verwenden, um neu erstellte Verkaufsaufträge abzurufen und wiederum die zuletzt abgerufene Verkaufsauftragsnummer zur Verwendung durch den nächsten Prozess speichern. Es wäre auch denkbar, dass eine Spalte mit dem Erstellungsdatum verwendet wird, um neue Bestellungen zuverlässig zu erkennen.

Wenn Sie sich nicht auf die Quellsystemdaten verlassen können, um neue Fakten effizient zu erkennen, können Sie sich möglicherweise auf eine Funktion des Quellsystems verlassen, um ein inkrementelles Laden auszuführen. Beispielsweise verfügen SQL Server und Azure SQL Managed Instance über ein Feature namens Change Data Capture (CDC), das Änderungen an jeder Zeile in einer Tabelle nachverfolgen kann. Darüber hinaus verfügen SQL Server, Azure SQL Managed Instance und Azure SQL-Datenbank über ein Feature namens Änderungsnachverfolgung, mit dem Zeilen identifiziert werden können, die geändert wurden. Wenn diese Option aktiviert ist, können Sie neue oder geänderte Daten in einer beliebigen Datenbanktabelle effizient erkennen. Möglicherweise können Sie auch Trigger zu relationalen Tabellen hinzufügen, die Schlüssel von eingefügten, aktualisierten oder gelöschten Tabellendatensätzen speichern.

Schließlich können Sie Quelldaten möglicherweise mithilfe von Attributen mit der Faktentabelle korrelieren. Beispielsweise die Verkaufsauftragnummer und die Nummer der Verkaufsauftragszeile. Bei großen Faktentabellen kann es sich jedoch um einen sehr kostspieligen Vorgang zum Erkennen neuer, geänderter oder gelöschter Fakten handelt. Es könnte auch problematisch sein, wenn das Quellsystem Betriebsdaten archiviert.

Abgeleitete Dimensionselemente

Wenn ein Faktenladeprozess ein neues Dimensionselement einfügt, wird es als abgeleitetes Element bezeichnet. Wenn ein Hotelgast zum Beispiel eincheckt, wird er gebeten, der Hotelkette als Treuemitglied beizutreten. Eine Mitgliedsnummer wird sofort ausgestellt, aber die Details über den Gast folgen möglicherweise erst, wenn der Gast die Unterlagen einreicht (falls überhaupt).

Alles, was über das Dimensionselement bekannt ist, ist der natürliche Schlüssel. Der Prozess zum Laden von Fakten muss mithilfe von Unbekannten Attributwerten ein neues Dimensionselement erstellen. Wichtig ist, dass er das Überwachungsattribut IsInferredMember auf TRUE festlegen muss. Auf diese Weise kann der Dimensionsladeprozess die notwendigen Aktualisierungen an der Dimensionszeile vornehmen, wenn die spät eintreffenden Details bezogen werden. Weitere Informationen finden Sie unter Verwaltung historischer Änderungen in diesem Artikel.

Faktenaktualisierungen oder Löschungen

Möglicherweise müssen Sie Faktendaten aktualisieren oder löschen. Wenn z. B. ein Verkaufsauftrag storniert wird oder eine Auftragsmenge geändert wird. Wie bereits beim Laden von Faktentabellen beschrieben, müssen Sie Änderungen effizient erkennen und entsprechende Modifikationen an den Faktdaten vornehmen. In diesem Beispiel für den stornierten Auftrag würde sich der Status des Verkaufsauftrags wahrscheinlich von Offen auf Storniert ändern. Diese Änderung würde eine Aktualisierung der Faktendaten und nicht das Löschen einer Zeile erfordern. Für die Mengenänderung wäre eine Aktualisierung der Mengenkennzahl für die Faktenzeile erforderlich. Diese Strategie zur Verwendung von vorläufigen Löschungen behält den Verlauf bei. Ein vorläufiges Löschen markiert eine Zeile als nicht mehr aktiv oder gültig und alle Berichtsabfragen und Power BI-Semantikmodelle sollten Datensätze herausfiltern, die vorläufig gelöscht werden.

Wenn Sie Aktualisierungen oder Löschungen von Fakten vorhersehen, sollten Sie Attribute (wie eine Verkaufsauftragsnummer und die zugehörige Nummer der Verkaufsauftragszeile) in die Faktentabelle aufnehmen, um die zu ändernden Faktenzeilen zu identifizieren. Stellen Sie sicher, dass Sie diese Spalten indizieren, um effiziente Änderungsvorgänge zu unterstützen.

Wenn Faktdaten mit Hilfe eines speziellen Dimensionselements (z. B. Unbekannt) eingefügt wurden, müssen Sie einen periodischen Prozess ausführen, der die aktuellen Quelldaten für solche Faktzeilen abruft und die Dimensionsschlüssel auf gültige Werte aktualisiert.

Zugehöriger Inhalt

Weitere Informationen zum Laden von Daten in ein Fabric Warehouse finden Sie unter:

• Erfassung von Daten im Warehouse
• Erfassen von Daten in Ihrem Warehouse mithilfe von Datenpipelines
• Erfassen von Daten in Ihr Warehouse mithilfe der COPY-Anweisung
• Erfassen von Daten in Ihrem Warehouse mithilfe von Transact-SQL
• Tutorial: Einrichten von dbt für Fabric Warehouse