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 .
