Entwurf eines Data Warehouse mit mehreren Faktentabellen
Ich bin neu im Data Warehousing. Zuerst möchte ich präzisieren, als meine Kopie von The Datawarehouse Toolkit auf dem Weg zu meinem Postfach ist (snail mail: P). Aber ich studiere schon all diese Sachen mit dem, was ich im Internet finde.
Was ich nicht im Netz finde, ist jedoch, was zu tun ist, wenn man in einer DW mehr als eine Tatsache zu haben scheint. In meinem Fall (Versicherung) habe ich Rückerstattungen, die nicht regelmäßig stattfinden. Ein Kunde kann für 3 Monate keine und dann 10 in den gleichen Monaten haben. Auf der anderen Seite habe ich "Abonnementgebühr" (nicht sicher, was ist der korrekte englische Begriff, aber Sie bekommen den Punkt), die jeden Monat oder alle drei Monate auftreten. Das scheint genau wie zwei verschiedene Fakten für mich.
Auch diese sind durch einige Dimensionen, wie den Kunden oder das "Versicherungsprodukt", locker verbunden. Nun sind diese beiden differents Warehouses, auf denen ich zwei verschiedene Berichte erstellen muss und verbinde dann die Berichte außerhalb der DW? Oder gibt es eine Möglichkeit, dies für einen einzelnen Abstieg DW zu entwerfen. Oder sollte ich diese beiden Fakten in einem zusammenfassen? Ich würde wahrscheinlich Granularität auf Erstattungen dann verlieren.
Einige Blogs, die ich gelesen habe, sagen, dass ein DW immer eine Faktentabelle hat. Andere erwähnen den Schritt des Entwerfens, was die Faktentabellen mit einem S sind, aber es gibt keine klare Anweisung, ob es eine Verbindung zwischen ihnen gibt, oder sie sind nur unterschiedliche Komponenten eines DW-Projekts.
Kennt jemand Referenzen zu diesem präzisen Teil des DW-Designs?
3 Antworten
Nehmen Sie Ihre Fragen zurück.
Ein Data Warehouse kann mehr als eine Faktentabelle haben. Sie möchten jedoch Verknüpfungen zwischen Faktentabellen minimieren. Es ist in Ordnung, Fakteninformationen in verschiedenen Faktentabellen zu duplizieren.
Von den von Ihnen erwähnten Objekten:
Rückerstattung ist eine Tatsache. Timestamp ist die Dimension des Rückerstattungsfaktors.
Abonnementgebühr ist eine Tatsache. Timestamp ist die Dimension der Abonnementgebühr Tatsache.
Eine Rückerstattung kann mehr als einmal vorkommen. Ich schätze, dass jeder Kunde eine Abonnementgebühr hat. So scheint es, dass wir bisher zwei Faktentabellen, Kunden und Kundenrückerstattung haben.
Wenn Sie wüssten, dass es höchstens 3 Rückerstattungen geben kann (als Beispiel), dann würden Sie die Faktura-Tabelle für Kundenrückerstattung entfernen und 3 Rückerstattungsspalten in die Kundentabelle einfügen.
Sie erwähnen auch Versicherung. Ein Kunde kann mehr als eine Richtlinie haben. Also haben wir eine dritte Faktentabelle.
Ein Data Warehouse wird normalerweise mithilfe eines Sternschemas erstellt. Das Sternschema ist im Grunde eine Faktentabelle, die mit einer oder mehreren Dimensionstabellen verbunden ist. Wahrscheinlich haben Sie mehr als einen Stern in einem Data Warehouse, da wir bereits 3 Faktentabellen definiert haben.
Sie können so viele Faktentabellen haben, wie Sie möchten. In Ihrem Beispiel haben Sie vielleicht etwas wie:
dimProduct listet mehrere Produkte auf - das Abonnement gehört dazu. dimTransactionType listet mögliche Transaktionen auf (Kauf, Erstattung, wiederkehrende Abonnementgebühr ...)
Wenn Sie jetzt an einer vereinfachten Abonnementberichterstattung interessiert sind, können Sie eine factSubscription wie folgt hinzufügen:
Mir ist klar, dass ich einen alten Beitrag beantworte, aber ich bin mit keiner der Antworten zufrieden. Ich fühle, dass beide die Frage nicht beantwortet haben.
Ein Schema kann einen oder mehrere Fakten haben, aber diese Fakten sind nicht durch irgendeine Schlüsselbeziehung verknüpft. Es empfiehlt sich, Faktentabellen nicht in einer einzigen Abfrage zusammenzufassen, wie dies bei der Abfrage einer normalisierten / transaktionalen Datenbank der Fall wäre. Aufgrund der Art von vielen zu vielen Joins usw. - die Ergebnisse wären falsch, wenn sie versucht werden.
Die Antwort, nach der Sie suchen, ist, dass Sie "bohren" müssen, was bedeutet, dass Sie jede Faktentabelle (Schema) einzeln abfragen und die Ergebnisse zusammenführen. Dies kann mithilfe von SQl oder vorzugsweise mithilfe eines Berichts- / Analysetools erfolgen, das möglicherweise auf das Data Warehouse verweist. Anstatt die Antworten darauf zu kopieren, werde ich alle zu zwei sehr guten Artikeln führen:
Drei Wege, um durch Chris Adamson zu bohren
>und
Tags und Links data-warehouse fact-table