Data Warehouse: Modellierung eines zukünftigen Zeitplans

Ich erstelle eine DW, die Daten zu Finanzwerten wie Anleihen und Darlehen enthalten wird. Diese Wertpapiere sind mit Zahlungsplänen verbunden. Zum Beispiel könnte eine Anleihe vierteljährlich gezahlt werden, während eine Hypothek in der Regel monatlich (manchmal alle zwei Wochen) gezahlt wird. Der Zahlungsplan wird erstellt, wenn das Wertpapier gehandelt wird und in den meisten Fällen unverändert bleibt. Das Design müsste jedoch den Fällen Rechnung tragen, in denen es sich ändert.Data Warehouse: Modellierung eines zukünftigen Zeitplans

Ich versuche gerade, diese Daten zu modellieren, und ich habe Schwierigkeiten, ein praktikables Design zu entwickeln. Eines der am häufigsten abgefragten Felder ist das "nächste Zahlungsdatum". Benutzer möchten oft wissen, wann ein Wertpapier als nächstes bezahlt wird. Daher möchte ich es so einfach wie möglich machen, dass sie das nächste Zahlungsdatum und den nächsten Betrag für jedes Wertpapier erhalten.

Außerdem führen Benutzer häufig historische Abfragen durch, in denen sie das nächste Zahlungsdatum und den nächsten Zahlungsbetrag zu einem bestimmten Zeitpunkt wünschen. Zum Beispiel könnten sie auf den 31. Januar 2009 zurückblicken und die nächsten Zahlungstermine (die normalerweise im Februar 2009 für Hypotheken wären) abfragen. Es ist auch üblich, dass sie den gesamten Zahlungsplan einer Sicherheit abfragen wollen, der 360 Datensätze umfassen kann (30 Jahre Hypothek x 12 Zahlungen/Jahr).

Da das nächste Zahlungsdatum und der Betrag jeden Monat oder sogar zweiwöchentlich geändert würden, würden diese Felder nicht sehr gut in eine sich langsam ändernde Dimension passen. Es wäre wahrscheinlich sinnvoller, eine Faktentabelle zu verwenden, aber ich bin nicht sicher, wie ich sie modellieren soll. Irgendwelche Ideen würden sehr geschätzt werden.

Quelle

2009-07-08 Anonymous

Warum wird das nächste Zahlungsdatum nicht als Anzahl der Tage ab dem Datum der aktuellen Zahlung gespeichert?

weitere Klarstellung:

Es würde eine Tatsache für jede Vergangenheit Zahlung bis zu einem gewissen Zeitpunkt Dimension verknüpft sein. Jeder dieser Fakten wird ein Feld next payment in haben, das eine Ganzzahl ist. Die Idee ist, dass das Datum der aktuellen Zahlung + next payment in das Datum der nächsten Zahlung Tatsache sein wird. Diese sollte in der Lage sein, für alles zu sorgen.

Quelle

2009-07-08 16:40:32

Das Problem wäre, dass Benutzer müssten die berechnen Nächstes Zahlungsdatum Ich bin mir auch nicht sicher, wie gut das für eine historische Abfrage funktionieren würde. Vielleicht könntest du etwas mehr auf diese Idee erweitern? –

Nein, du hast Recht. Es passt nicht zu diesem Modell. Ich würde mich wirklich dafür interessieren, wie das elegant gelöst werden könnte. Entschuldige, dass ich dich irreführe. –

Wie bestimmen Sie, wann das Zahlungsdatum jetzt ist? Ist es ein Teil der Daten, die Sie in das DW laden, oder handelt es sich um eine Geschäftsregel, die angewendet wird, wenn Sie Abfragen für die Daten ausführen? – nos

Das nächste Zahlungsdatum ist ein Beispiel für eine "Fakt-freie Faktentabelle". Es gibt kein Maß, nur FK zwischen mindestens zwei Dimensionen: die Sicherheit und die Zeit.

Sie können die Sicherheit denormalisieren, um eine Typ-1-SCD zu haben (mit jeder Ladung überschrieben), die ein paar wichtige "nächste Zahlungstermine" hat.

Ich denke, es ist wahrscheinlich besser, ein paar wichtige Zahlungstermine zusammen mit den Fakten zu tragen. Wenn Sie eine Fakturentabelle "aktueller Saldo" für Darlehen haben, haben Sie ein anwendbares Datum für dieses Saldo, und Sie können auch vorherige und nächste Zahlungstermine zusammen mit dem Saldo tragen.

Für den gesamten Zahlungsplan haben Sie eine spezielle Fakt-freie Faktentabelle, die nur das Datum und die Abfolge der Zahlungstermine in der Zukunft hat. Auf diese Weise können Sie, wenn sich der Zeitplan ändert, die Zahlungssequenz ab einem bestimmten Datum auswählen.

Quelle

2009-07-08 17:05:24

Ich habe erwogen, ein next_payment-Feld zu haben, das überschrieben wird, aber meine Sorge ist, dass es für historische Abfragen nicht funktionieren würde. Benutzer möchten oft auf ein vorheriges Datum zurückblicken und sehen, wie das nächste Zahlungsdatum zu diesem Zeitpunkt war. Also lehnte ich an einem Typ 1 SCD. –

Deshalb schlage ich vor, dass es eine Tatsache ist. Lade es einfach weiter. Datum, an dem die Information gilt und zukünftiges Zahlungsdatum Für jedes angegebene Datum haben Sie alle zukünftigen Zahlungstermine. Das min() ist das nächste Zahlungsdatum. Ja, es sind viele Fakten. –

Ich möchte einen Tisch verwenden (securityid, startdate, paymentevery, Zeitraum) es auch enddate umfassen könnte, paymentpershare

Periode 1 für Tag sein würde, 2 Wochen, 3 Monate, 4 seit Jahren.

So für die Sicherheit 1, die wöchentlich am 01.03.2009 zu zahlen begann, dann änderte sich das Datum alle 20 Tage auf 4/2, dann wöchentlich nach 1.5.2009, dann monatlich auf 1.7.2009 es würde enthalten:

1,'3/1/2009',1,2 
1,'4/2/2009',20,1 
1,'5/1/2009',1,2 
1,'7/1/2009',1,3

die tatsächlichen Daten zu erhalten, ich einen Algorithmus wie folgt verwenden würde:

um die Zahlungstermine auf Sicherheit 1 von 2009.03.05 bis 17.05 weiß/2008:

Find first entry before 3/5 = 3/1 
Loop: 
Get next date that's after 3/5 and before the next entry (4/2 - weekly) = 3/8 
Get next date that's before next the entry (4/2) = 3/15 
Get next date that's before next the entry (4/2) = 3/22 
Get next date that's before next the entry (4/2) = 3/29 
Next date >4/2 switch to next entry: 
Loop: 
Get next date that's after 4/2 and before the next entry (5/1 - every 20 days) = 4/22 
Next date 5/12 is AFTER next entry 5/1, switch to next entry 
Loop: 
Get next date that's after 5/1 and before the lastdate (5/17 - weekly) = 5/8 
Get next date that's before the lastdate = 5/15 
Next date > 5/17

Die Daten zwischen 3/5/2009 und 5/17/2008 wäre 3/8,3/15,3/22,3/29,4/22,5/8,5/15

Quelle

2009-07-18 20:55:21

Data Warehouse: Modellierung eines zukünftigen Zeitplans

Antwort

Verwandte Themen