Ist mein Verständnis der Granularität von Faktentabellen korrekt?

Ich selbst und ein anderer DBA in unserem Unternehmen haben die Aufgabe, ein Datenbankdesign zu überprüfen, das ein Anbieter für uns entwickelt hat. Der Verkäufer hat gesagt, dass sie Kimball als Grundlage für ihr Design verwenden. (HINWEIS: Ich suche nicht nach Argumenten von Kimball gegen Inmon usw.) Sie haben einen Mart mit mehreren Fakten und Dimensionen entworfen.

Um ehrlich zu sein, hat unser Unternehmen noch nie einen einzigen Markt entworfen. Wir haben es immer von den Beratern machen lassen. Und wir wurden noch nie in den Unterricht geschickt oder so. Unser Wissen über Lagerhaltung / Marts / Dimensionsmodellierung usw. basiert also auf der geringen Erfahrung, die wir im Internet finden können, und dem Selbstlesen (wir haben Inmons und Kimballs Bücher und versuchen, uns durch sie hindurchzuarbeiten). .

Jetzt, da die Voraussetzungen für meinen Wissensstand geschaffen sind, kommen wir zur Designherausforderung.

Es gibt eine Faktentabelle mit dem Namen "Claim Loss Statistics" (dies gilt für Versicherungen). Und sie versuchen, sowohl die Zahlungen für Forderungen (auf ein monatliches Niveau gerollt) als auch das Geld in den Reserven (ähnlich wie ein Bankkonto für Forderungen) zu erfassen. Sie möchten die monatlichen Beträge für Zahlungen sehen (kein Problem). Sie möchten jedoch den aktuellen Kontostand der Reserven sehen.

Ich werde ein bildliches Beispiel geben.

Angenommen, wir haben Reserven in Höhe von 1000 USD für einen Anspruch eingerichtet. Dies wird beiseite gelegt (in gewisser Hinsicht funktioniert es also wie ein Bankkonto).

Im Oktober 2014 zahlen wir noch nichts aus. Das Unternehmen möchte also die Zahlungen und den Reservesaldo Ende Oktober sehen.

-----------------------------------------------
-  MONTH_YEAR  -  PAYMENTS -  RESERVE_BALANCE -
-----------------------------------------------
-      102014  -      0.00 -          1000.00 -
-----------------------------------------------

Dann kommt der November. Wir leisten Zahlungen in Höhe von 100, 150 und 75 US-Dollar. Sie möchten, dass diese Beträge wie folgt aggregiert und die Reserve wie folgt ausgewiesen werden:

-----------------------------------------------
-  MONTH_YEAR  -  PAYMENTS -  RESERVE_BALANCE -
-----------------------------------------------
-      102014  -      0.00 -          1000.00 -
-----------------------------------------------
-      112014  -    325.00 -           675.00 -
-----------------------------------------------

Und dann sagen wir, wir haben im Dezember keine Zahlungen und im Januar nächsten Jahres 200 Dollar mehr.

-----------------------------------------------
-  MONTH_YEAR  -  PAYMENTS -  RESERVE_BALANCE -
-----------------------------------------------
-      102014  -      0.00 -          1000.00 -
-----------------------------------------------
-      112014  -    325.00 -           675.00 -
-----------------------------------------------
-      122014  -      0.00 -           675.00 -
-----------------------------------------------
-       12015  -    200.00 -           475.00 -
-----------------------------------------------

Hier kämpfe ich. Mein Verständnis ist, dass der Zahlungsteil korrekt ist. Sie werden alle monatlich in jedem Datensatz zusammengefasst. Sie können also ein weiteres Rollup durchführen, wenn Sie dies für das Jahr, das Quartal usw. wünschen.

Der Reservebetrag ist jedoch unterschiedlich. Es ist ein Gleichgewicht. Und das Unternehmen möchte sehen, wie viel sich jeden Monat in der Bilanz befindet. Sie können dieses Feld jedoch nicht aggregieren. Wenn Sie dies tun würden, würden Sie einige wackelige Ergebnisse erhalten.

Irgendwie kommt mir das falsch vor. Aber ich kann nicht ehrlich sagen, dass ich genug modelliert habe oder genug weiß. Ich kann nur sagen, was ich weiß. Und soweit ich weiß, sollten alle Werte in einem Fakt dieselbe Granularität haben.

Beide Zahlen haben die gleiche Granularität wie ein "Monat", aber sie sind nicht vom Standpunkt dessen, wofür sie stehen. Eine davon sind die Gesamtdollar innerhalb eines Monats. Der andere ist nur das Gleichgewicht.

Ist das richtig? Ich habe dieses Design zurückgedrängt. Bin ich falsch das zu tun? Ist es in Ordnung, dies in einer Tatsache zu tun? Oder ist mein Sinn für "Code-Geruch" eines schlechten Designs korrekt?

Jede Hilfe wäre dankbar. HINWEIS: Bitte sagen Sie nicht nur "Es sollte Weg X sein", sondern erklären Sie, warum es so sein sollte, damit ich daraus lernen kann.

EDIT : Nun, ich habe gelernt, dass mein anfängliches Verständnis der Tatsache falsch ist. Die Granularität ist NICHT monatlich. Die Granularität ist die Transaktionsebene. Das bedeutet, dass innerhalb des MONTH_YEAR (dh es handelt sich tatsächlich um den Berichtszeitraum) mehrere Zahlungs- und Wiederherstellungsvorgänge stattfinden. Diese werden nach Datum oder Transaktionsdatum gebucht. Aufgrund eines vorherigen Berichts, den das Unternehmen sieht, und auch aufgrund der Art und Weise, wie die Daten im Altsystem gespeichert sind, wollten sie sowohl die Transaktionsdaten (eine Zeile pro Zeile) als auch den monatlichen Reservesaldo (eine Zeile pro Monat) festlegen ).

Als ich das erfuhr, wurde mir klar, dass das Problem nicht so sehr additiv oder nicht additiv oder sogar halbadditiv war, sondern vielmehr Getreide, was ich von Anfang an vermutete. Unser DBA-Team hat dies mit dem Projektteam besprochen und berichtet, dass versucht wird, zwei verschiedene Körner in dieselbe Tatsache zu integrieren, was jedoch nicht korrekt war. Dass sie entweder die Transaktionen auf ein monatliches Niveau bringen sollten, damit sie dann die Zahlungen, Rückforderungen und den monatlichen Reservesaldo (dh eine halbadditive Tatsache) haben können, weil alles auf einem monatlichen Korn wäre. Oder sie müssen einen Weg finden, das Reservesaldo in Transaktionen aufzuteilen, um das Getreide auf Transaktionsebene zu erhalten. Oder sie müssen die Tatsache in zwei Tatsachen aufteilen. Man kann das monatliche Niveau für den Reservesaldo sein. Die andere kann auf Transaktionsebene für die Zahlungen und Rückforderungen sein. (Es gibt keinen Grund, warum sie die Zahlungen und Rückforderungen auch nicht auf monatlicher Ebene in die monatliche Ebene einbeziehen konnten. Hängt nur von den Geschäftsanforderungen ab.)

Angesichts dessen, was ich gelernt habe, werde ich die Antwort von Thomas als die richtige markieren. Ich bin jedoch der Meinung, dass die Diskussion, die ich mit der ursprünglichen Frage begonnen habe, immer noch eine gute ist, von der andere lernen können, sodass ich den ursprünglichen Teil meiner Frage intakt lassen werde. Ich beabsichtige auch, Nikadams Antwort eine Prämie zu gewähren, da dies mir viel über additive, nichtadditive und semi-additive Fakten beigebracht und viele Missverständnisse, die ich bezüglich der Dimensionsmodellierung hatte , korrigiert hat .

Ihre Intuition für Codegeruch ist gut geschliffen.

Es handelt sich reserves um das, was Kimball als "semi-additive Tatsache" bezeichnet. Es rollt nicht gut auf Viertel oder Jahr.

Die typische Lösung hierfür besteht darin, zwei Faktentabellen zu haben, eine für die additive Tatsache ( paymentsin Ihrem Fall) und eine für die nicht additive Tatsache. Die nicht-additive Tatsache muss eigentlich kein Getreide auf Monatsebene haben, man könnte sie bis zum Tag aufbewahren und die Dinge funktionieren immer noch.

Die nichtadditive Tatsache reservewird anders abgefragt als die andere Tatsache. Sie müssen eine Geschäftsentscheidung treffen: Was bedeutet reserveauf Jahresebene? Ist es der letzte Monat des Jahres oder vielleicht der Durchschnitt der Monate im Jahr? Unabhängig davon, welche Wahl Sie treffen, finden Sie die Lösung für die Modellierung in den Kimball-Büchern unter den Kapiteln über nichtadditive Fakten.

Beachten Sie, dass bei Verwendung eines Cube-Produkts wie Analysis Services die Aggregate möglicherweise "nur funktionieren", auch wenn Sie alles in einer Tabelle speichern. Ich ziehe es jedoch vor, die Dinge getrennt zu halten, damit relationale Abfragen leichter zu schreiben sind (und die Fakten auch leichter zu laden sind).

Sie haben Recht: " Verschiedene Körner dürfen nicht in derselben Faktentabelle gemischt werden ".

Der Reservesaldo am Monatsende und die Summe der Zahlungen am Monatsende sind jedoch gleich hoch. Es ist nur eine der Tatsachen, die halbadditiv sind . Die Art der Tatsache (additiv oder nicht) definiert nicht die Körnung der Tabelle.

Nach dem, was Sie beschreiben, sehe ich Ihr Korn als "monatlichen Anspruchsschnappschuss", wodurch Ihre Faktentabelle zur " periodischen Schnappschuss-Faktentabelle " wird.

In diesem Artikel hat Kimball ein Beispiel für additive und semi-additive Fakten in derselben Faktentabelle.

Hier ist ein Beispiel für einen periodischen Schnappschuss mit semi-additiven Fakten aus dem Data Warehouse Toolkit (Seite 116):

Es wird empfohlen, eine Transaktionsfaktentabelle zu erstellen, die jede Änderung der Reserve (Zahlungen und Anpassungen) auf der niedrigsten atomaren Ebene widerspiegelt. Wenn Sie sich mit Ansprüchen befassen, ist die atomare Ebene häufig kein Anspruch, sondern ein Unteranspruch (Ihre Versicherungsgesellschaft hat möglicherweise eine eigene Laufzeit dafür). Im Allgemeinen repräsentiert jeder Unteranspruch eine andere Partei des Anspruchs und Zahlungen / Rückstellungen für jede Partei. Beispielsweise gibt es möglicherweise keine Zahlungen an den Versicherten, sondern Zahlungen an nicht versicherte Personen, die von Ihrem Unternehmen verletzt wurden, sowie Zahlungen an das Krankenhaus und den Anwalt.

Abhängig von der Leistung Ihres BI-Tools können Sie die Transaktionsfaktentabelle direkt verwenden, um monatliche Zahlungen und Salden zu erhalten. Oder Sie aktualisieren die periodische Snapshot-Faktentabelle täglich oder am Monatsende.

Die Fähigkeit, mit semi-additiven Fakten umzugehen, hängt davon ab, welche BI-Schicht Sie verwenden. Einige Tools können problemlos mit semi-additiven Fakten umgehen, andere nicht.

Kimballs Hauptbuch ( The Data Warehouse Toolkit ) enthält das vollständige Kapitel (16) über Versicherungen.