Historische Daten

Historische Daten

Bevor wir später uns in der Praxis mit der historischen Datenhaltung und -verwendung beschäftigen, müssen wir uns über manche theoretische Punkte klar sein. Sonst besteht die Gefahr, dass wir gegen die Wand laufen.

Allgemein sehe ich die historischen Daten eines Objektes sind die Eigenschaften, die sich im Leben des Objektes zu bestimmten Zeitpunkten ändern. Logisch ist es so zu sehen, dass ein geborenes Objekt ab der Geburt vorhanden ist. Die Eigenschaften sind dann immer zu einer Stichzeit sichtbar. Diese Sicht hat dann so lange Gültigkeit bis sich eine der Eigenschaften ändert oder mit einem Gültig-ab eine neue dazu kommt. Ein Objekt wird in der historischen Datenhaltung nie beendet. Nur Eigenschaften können geleert werden.

Wenn wir es gut machen, dann gibt es hier eine verlustfreie Datenhaltung. Dieses bedeutet, dass wir jede Eingabe nachvollziehen können (wer, wann, wo eingegeben) und aber auch bei Bedarf auf frühere Werte zurückgehen können. Mal sehen, sind so meine Überlegungen.

Die historischen Daten unterteilen sich in verschiedene Bereiche:
  • Daten ohne Historie (es wird immer der aktuelle Wert sichtbar)
  • Standard Daten mit Historie (Normale Objekte mit Eigenschaften)
  • Berechnungsergebnisse (Daten zu Perioden / Zeiträumen) - mit differenzierten Periodensystem und Rückrechnung ohne Datenverlust.
Die ersten beiden Arten haben identische Datenstrukturen für Objekte
Die Berechnungsergebnisse haben eine eigene Datenstruktur im Periodensystem.

Grundlegende Strukturen im Standard

Die Datenhaltung kann in verschiedenen Formen erfolgen. Für die Verarbeitung und die laufenden Änderungen - Verwaltung der Daten - denken wir in der aktuellen Form der realtionalen Datenbanken, aber ohne Relationen. Einfach eine schnellen Datenzugriff und Speicherung. Bei den eigentlichen Daten und ggf. den ÄnderungsLogs denken wir in Dokumenten (JSON bzw. PythonWörterbuch)

Sehen wir es so, wenn ich heute zum Beispiel mit Django ein Objekt speichere bekomme ich einen Satz in der Datenbanktabelle mit der ID des Objektes. Wenn ich nun zu einer Objekt.ID aber historisch Daten in mehreren Sätzen ablegen möchte geht es so mit dem Standardvorgehen nicht mehr.

Logisch gesehen bilden das Gültig-ab mit der Objekt.ID die Id des Satzes. Zu einem Gültig-ab kann es bei einem Objekt immer nur einen Eintrag geben.

Bis hierher brauchen wir
  • ID // ID der Zeile
  • Gültig-ab // über die Form unterhalten wir uns später
  • OID // Id des Objektes
Wir wollen es so diskutieren, dass wir allgemein keine Sätze löschen, sondern nur als gelöscht kennzeichnen. Folglich kommt
  • isDeleted  // True = gelöscht
hinzu.

Dieses zentrale Struktur des Standards ist bei allen Objekten identisch, nur der eigentliche Datenbereich ist unterschiedlich. Da diese dann später auch verknüpft werden und es dann so was ähnliches wie Teilobjekte sind werde ich diese als Datengruppe bezeichnen.

Sichten und Stichtag / Stichzeit

Nun wenn wir unsere Daten in einer Datengruppe historisch ablegen und verwalten, müssen wir uns gleich am Anfang Gedanken machen, wie wir diese Eigneschaften wieder beschaffen um damit geordnet arbeiten zu können. Immer mit einer Liste Daten zu arbeiten macht hier keinen Sinn, da wir nicht wissen, welche Daten für die geade anstehende Aufgabe benötigt werden.

Bei einer historischen Datenverwaltung muss es immer eine Sicht auf die Daten zu einem Zeitpunkt (Stichtag / Stichzeit) geben. Dieses bedeutet, dass zu dem Stichtag einfach die nächsten Daten mit dem kleineren Gültig-ab relevant sind. Also am Stichtag Gültigkeit haben.

Sobald ich mit meinen technischen Muster weiter bin, wird dieses Thema weiter ausgeführt.

Änderungslog für Datensicherheit

Dieses ist an der Stelle einfach ein Merker. Wir benötigen eine gute Lösung, Änderungen in einem Log vorzuhalten, um diese ggf. auch zurücksetzen zu können.

Dieses ist auch abhängig davon ob das Gültig-ab ein Datum ist oder eine Zeitpunkt.

Historie bei Berechnungsergebnissen

Wir reden von Berechnungsergebnissen. Etwas berechnet werden kann nur, wenn dazu ein Objekt vorhanden ist. Das heißt die Standard Historie bildet die so genannten Stammdaten ab. Dazu wird was berechnet. Die Berechnung erfolgt immer zu einer Periode, Monat, 3 Wochen, 1 Woche, 1 Tag mehrere Tage. Dieses bedeutet, dass es für verschiedene Berechnungsergebnisse eigene Periodendefinitionen gibt.

Dieses sind zum Beispiel (kein Anspruch auf Vollständigkeit):
  • In der Buchhaltung sind es Buchungsperioden in einem Buchungszyklus
  • Bei einer Rechnung ist des der Rechnungstag
  • Bei Quartalsabrechnungen ist es das Quartal im Abrechnungszyklus
  • Bei Halbjahresabrechnung ist es das halbe Jahr im Abrechnungszyklus
  • Bei einer Jahresabrechnung ist es einfach das Jahr
  • In der Lohnabrechnung ist es in der Regel der Abrechnungsmonat im Abrechnungsjahr
  • Bei einer Reisekostenabrechnung ist die Dauer der Reise
Bei allen Perioden ist es so, dass es ggf. Teilperioden geben muss. Diese sind einfach kleiner Einheiten, die sich auf der Basis von geänderten Stammdaten oder per Definition ergeben.

Das ganze wird über ein Periodensystem geregelt, dass in einer Periodenebene n mal gerechnet werden kann bis diese gesperrt/jounalisiert wird. Auch bei Rückrechnungen (Berechnungen mit abweichenden Werten) die diese Ergebnisse nie überschrieben. Vielmehr wird diese Periode in einer neuen Ebene abgelegt und kann zur Berechnung der Differenzwerte herangezogen werden.

Wie dieses im Einzelnen aussieht werden wir noch erarbeiten.
Share by: