Zum Hauptinhalt springen
Suche
0
Scalefree - Wissen - Webinare - Data Vault Friday - Nicht-historisierte Verbindungen und ihre Satelliten

In der Welt der data vault-Modellierung treffen wir häufig auf Situationen, in denen wir mit nicht-historisierten Verbindungen umgehen müssen. Ein nicht-historisierter Link ist eine Struktur, die verwendet wird, um Beziehungen zwischen Entitäten (Hubs) in einem data vault zu erfassen. Im Gegensatz zu historisierten Links sind diese Strukturen nicht darauf ausgelegt, Änderungen im Laufe der Zeit zu verfolgen, was sie in bestimmten Hochleistungsszenarien besonders nützlich macht.

Bei der Integration mit Systemen, die Transaktionen für neuere Zeiträume aktualisieren können, werden jedoch zusätzliche Strukturen wie nicht-historisierte Satelliten unerlässlich. Diese Satelliten ermöglichen es uns, Aktualisierungen der mit der Verknüpfung verbundenen Attribute zu verfolgen und gleichzeitig die Integrität und Leistung des Datenmodells zu erhalten.

Der Entwurf von nicht-historisierten Verknüpfungen erfordert eine sorgfältige Planung, insbesondere wenn es sich um umfangreiche Datensätze oder Plattformen mit spezifischen Speicherbeschränkungen handelt. Eine umfangreiche Verknüpfung kann beispielsweise Attribute wie Transaktions-ID, Kontensegmente, Buchhaltungsbeleg, Buchhaltungsperiode und Zeitstempel enthalten. Diese Attribute identifizieren eine Transaktion eindeutig und stellen Beziehungen zu anderen Entitäten in der data vault her.

Hier sind die wichtigsten Überlegungen für die Gestaltung nicht-historisierter Verbindungen:

  • Wesentliche Identifikatoren einbeziehen: Attribute, die zur eindeutigen Identifizierung einer Transaktion und zur Herstellung von Beziehungen mit Hubs erforderlich sind, sollten immer Teil der Verknüpfung sein. Dazu gehören in der Regel die Transaktions-ID und alle erforderlichen alternativen Schlüssel.
  • Ausgewogene Zeilenbreite: Die Aufnahme zu vieler Attribute in den Link kann bei zeilenbasierten Speichersystemen zu Leistungsproblemen führen, da breite Zeilen die Anzahl der pro Seite gespeicherten Datensätze verringern.
  • Verwenden Sie Satelliten für zusätzliche Attribute: Attribute, die für gelegentliche Abfragen oder die Aggregation von Dashboards nicht unbedingt erforderlich sind, sollten in eine Satellitenstruktur verschoben werden, um die Verbindung schlank und effizient zu halten.

Die Rolle der nicht historisierten Satelliten

Nicht-historisierte Satelliten spielen eine entscheidende Rolle bei der Ergänzung nicht-historisierter Verbindungen. Sie speichern zusätzliche beschreibende Attribute, die von typischen Benutzern nicht häufig abgefragt oder aggregiert werden. Dieser Ansatz minimiert die bei der Abfrage erforderlichen Verknüpfungsoperationen und verbessert so die Leistung.

Während beispielsweise Attribute wie Soll- und Haben-Beträge aufgrund ihrer Bedeutung für Aggregationen in die Verknüpfung aufgenommen werden können, können andere, weniger häufig verwendete Attribute wie die Transaktionsart oder Rechnungsbeschreibungen im Satelliten untergebracht werden. Diese Aufteilung gewährleistet ein Gleichgewicht zwischen Speichereffizienz und Abfrageleistung.

Optimierung der Abfrageleistung

Eine große Herausforderung bei der Entwicklung besteht darin, eine optimale Abfrageleistung zu gewährleisten, insbesondere bei spaltenbasierten Speichersystemen. Das Verbinden eines Links mit seinem Satelliten kann die Leistung erheblich beeinträchtigen. Um dies abzumildern, ist Folgendes zu beachten:

  • Prejoin häufig abgefragter Attribute: Verschieben Sie Attribute, die häufig in Aggregationen oder Group-by-Operationen verwendet werden, in die Verknüpfungsstruktur, um die Notwendigkeit von Joins zu vermeiden.
  • Maßgeschneiderte Satelliten für spezifische Anwendungsfälle: Entwerfen Sie Satelliten für spezielle Anforderungen, wie z. B. Datenwissenschaft oder detaillierte Analysen, bei denen sich die Nutzer die höheren Kosten für einen gemeinsamen Betrieb leisten können.
  • Führen Sie hybride Speicherstrategien ein: Nutzen Sie hybride Speicherlösungen wie die Mini-Partitionen von Snowflake, um zeilenbasierte und spaltenbasierte Vorteile zu kombinieren und breitere Zeilen für häufig abgefragte Daten zu unterstützen.

Praktisches Beispiel

Betrachten wir ein Szenario mit einer Finanztransaktionstabelle, die über eine Milliarde Zeilen enthält. Die Tabelle enthält Attribute wie Transaktions-ID, Kontosegmente, Buchhaltungsbeleg, Buchhaltungsperiode, Sollbetrag, Habenbetrag und Zeitstempel.

So können wir die nicht-historisierte Verbindung und den Satelliten strukturieren:

  • Nicht-historisierte Verknüpfung: Dazu gehören Transaktions-ID, Kontosegmente, Buchhaltungsbeleg, Buchhaltungsperiode, Soll- und Haben-Betrag. Diese Attribute sind für Aggregationen und Dimensionsreferenzen unerlässlich.
  • Nicht-historisierte Satelliten: Speichern Sie zusätzliche Attribute wie Transaktionsart und Rechnungsbeschreibungen, die von gelegentlichen Benutzern nicht häufig abgefragt werden.

Diese Struktur stellt sicher, dass typische Abfragen für Dashboards und Berichte effizient sind, während sie gleichzeitig detaillierte Analysen für spezialisierte Benutzer unterstützen.

Schlussfolgerung

Die Entwicklung von nicht-historisierten Links und ihren Satelliten erfordert ein tiefes Verständnis der Datennutzungsmuster und der Einschränkungen der Speicherplattform. Durch die sorgfältige Auswahl der Attribute, die in den Link aufgenommen werden sollen, und der Attribute, die auf einen Satelliten ausgelagert werden sollen, können wir ein Gleichgewicht zwischen Abfrageleistung und Speichereffizienz herstellen. Für die meisten Szenarien ist es wichtig, Attribute zu priorisieren, die häufige Aggregationen und Gruppierungen in der Link-Struktur unterstützen, während Satelliten als Speicher für weniger wichtige Details dienen.

Da sich die Datenmodellierung ständig weiterentwickelt, ist die Anpassung dieser Grundsätze an moderne Speichertechnologien und hybride Plattformen entscheidend für den Aufbau robuster und leistungsfähiger data vault-Systeme.

Das Video ansehen

Treffen mit dem Sprecher

Profilbild von Michael Olschimke

Michael Olschimke

Michael hat mehr als 20 Jahre Erfahrung in der Informationstechnologie. In den letzten acht Jahren hat er sich auf Business Intelligence-Themen wie OLAP, dimensionale Modellierung und Data Mining spezialisiert. Fordern Sie ihn mit Ihren Fragen heraus!

Eine Antwort hinterlassen

Menü schließen