Transformation von OLTP -relationaler Datenbank in das Data Warehousing -Modell

Question

Was sind die gängigen Designansätze, die beim Laden von Daten aus einem typischen OLTP-Datenbankmodell für Entitätsbeziehungen in ein Kimball Star Schema Data Warehouse/Marts-Modell verfolgt werden?

• Verwenden Sie einen Staging -Bereich, um die Transformation durchzuführen und dann in das Lagerhaus zu laden?
• Wie verknüpfen Sie Daten zwischen dem Lagerhaus und der OLTP -Datenbank?
• Wo/wie verwalten Sie den Transformationsprozess - in der Datenbank als Sprocs, DTS/SSIS -Pakete oder SQL aus dem Anwendungscode?

Answer 1

Persönlich neige ich dazu, wie folgt zu arbeiten:

1. Entwerfen Sie zuerst das Data Warehouse. Entwerfen Sie insbesondere die Tabellen, die im Rahmen des DW benötigt werden, und ignoriert alle Inszenierungstische.
2. Entwerfen Sie die ETL mit SSIS, aber manchmal mit SSIS -aufgerufenen gespeicherten Verfahren in den beteiligten Datenbanken.
3. Wenn im Rahmen der ETL Staging -Tabellen erforderlich sind, sollten Sie gleichzeitig aufgeräumt werden. Eine Staging -Tabelle, die nur als Teil einer einzelnen Reihe von ETL -Schritten verwendet wird, sollte nach Abschluss dieser Schritte mit oder ohne Erfolg abgeschnitten werden.
4. Ich habe die SSIS -Pakete beziehen sich zumindest auf die OLTP -Datenbank, um Daten in die Staging -Tabellen zu ziehen. Abhängig von der Situation können sie die OLTP -Tabellen direkt in das Data Warehouse verarbeiten. Alle diese Abfragen werden mit (Nolock) durchgeführt.
5. Dokument, Dokument, Dokument. Machen Sie klar, welche Eingaben von jedem Paket verwendet werden und wohin der Ausgang geht. Stellen Sie sicher, dass Sie die Kriterien dokumentieren, nach denen die Eingabe ausgewählt sind (letzte 24 Stunden? Seit dem letzten Erfolg? Neue Identitätswerte? Alle Zeilen?)

Das hat für mich gut funktioniert, obwohl ich zu gebe zu gebe, dass ich nicht viele dieser Projekte oder wirklich große gemacht habe.

Answer 2

Ich arbeite derzeit an einem kleinen/mittleren Dataware -Haus. Wir übernehmen einige der Konzepte, die Kimball vorstellt, dh das Sternschema mit Tatsachen- und Dimensionstabellen. Wir strukturieren es so, dass Fakten nur mit Dimensionen verbunden sind (nicht Fakten zu Tatsachen oder Dimension zu Dimension - aber dies ist unsere Wahl, nicht zu sagen, dass es so ist, wie es getan werden sollte), also flachen wir alle Dimensionen mit dem Tatsachentisch ab.

Wir verwenden SSIs, um die Daten aus der Produktion DB -> Quelle DB -> Staging DB -> DB zu melden (wir hätten wahrscheinlich weniger DBs verwendet können, aber so ist sie gefallen).

SSIS ist wirklich schön, da Sie Ihre Daten sehr logisch strukturieren können. Wir verwenden eine Kombination von SSIS-Komponenten und gespeicherten Procs, bei denen eine schöne Funktion von SSIS die Möglichkeit ist, SQL-Befehle als Transformation zwischen einem Quell-/Zieldatenfluss bereitzustellen. Dies bedeutet, dass wir gespeicherte Procs in jeder Reihe anrufen können, wenn wir möchten, was nützlich sein kann (wenn auch etwas langsamer).

Wir verwenden auch eine neue SQL Server 2008 -Funktion namens Change Data Capture (CDC), mit der Sie alle Änderungen in einer Tabelle prüfen können (Sie können angeben, welche Spalten Sie in diesen Tabellen betrachten möchten). Produktion DB, um zu sagen, was sich geändert hat, damit wir nur diese Datensätze zur Verarbeitung auf die Quell -DB verschieben können.

Answer 3

Ich stimme der hoch bewerteten Antwort zu, aber ich dachte, ich würde Folgendes hinzufügen:

* Do you use a staging area to perform the transformation and then

In das Lagerhaus beladen?

Es hängt von der Art der Transformation ab, ob es eine Inszenierung erfordert. Staging bietet Vorteile, die ETL in überschaubarere Brocken zu zerlegen, bietet aber auch einen Arbeitsbereich, der es ermöglicht, die Manipulationen auf den Daten zu ermitteln, ohne das Lager zu beeinflussen. Es kann dazu beitragen, (zumindest) einige Dimensions -Lookups in einem Staging -Bereich zu haben, in dem die Schlüssel über das OLTP -System und den Schlüssel des neuesten DIM -Datensatzes gespeichert werden, um beim Laden Ihrer Tatsachenaufzeichnungen als Suche zu verwenden. Die Transformation erfolgt im ETL -Prozess selbst, kann jedoch eine gewisse Inszenierung erfordern oder nicht, um sie auf dem Weg zu helfen.

* How do you link data between the warehouse and the OLTP database?

Es ist nützlich, die Geschäftsschlüssel (oder die tatsächlichen Primärschlüssel) als Referenz zurück zum OLTP -System in das Data Warehouse zu laden. Außerdem sollte die Prüfung im DW -Prozess die Linie jedes Datenbits aufzeichnen, indem der geladene Lastprozess aufgezeichnet wird.

* Where/How do you manage the transformation process - in the

Datenbank als Sprocs, DTS/SSIS -Pakete oder SQL aus dem Anwendungscode?

Dies wäre normalerweise in SSIS -Paketen, aber oft ist es leistungsfähiger, sich in der Quellabfrage zu verwandeln. Leider macht dies die Quellabfrage ziemlich kompliziert zu verstehen und daher zu pflegen. Wenn also Leistung kein Problem ist, ist es am besten, im SSIS -Code zu transformieren. Wenn Sie dies tun, ist dies ein weiterer Grund für einen Staging -Bereich, wie Sie dann mehr Verbindungen in der Quellabfrage zwischen verschiedenen Tabellen vornehmen können.

Answer 4

Die Erklärung von John Saunders 'Prozess Erklärung ist gut.

Wenn Sie ein DataWarehouse -Projekt in SQL Server implementieren möchten, finden Sie alle Informationen, die Sie für die Bereitstellung des gesamten Projekts innerhalb des hervorragenden Textes benötigen. "Das Microsoft Data Warehouse Toolkit".

Preisig genug, einer der Autoren ist Ralph Kimball :-)

Answer 5

Vielleicht möchten Sie sich ansehen Datengewölbemodellierung. Es behauptet, einige Loner -Begriffsfragen wie Änderungen von Attributen zu lösen.