"Daten-Historisierung in einem RDB(M)S"

[Lude]

Hi,

muss naechste Woche Mittwoch einen Vortrag ueber "Daten-Historisierung in einem RDB(M)S" halten. Und - *Angst*, *Bibber*, *Geldgier* - verfuege moeglicherweise nicht ueber "das Expertenwissen". - Zumindest habe ich die Hoffnung, dass der eine oder andere hier gerade zufaellig ein paar Buchstaben oder/und ein paar Verweise fuer Lude griffbereit hat.

Viele Gruesse,
Lude

[Matze]

Ein richtig umfangreiches Thema hast Du dir dabei raus gesucht.

1. Gilt festzuhalten, dass derartige historisierung in unterschiedlichem Umfang abläuft.

Zum einen begüngen sich die meisten lediglich Änderungen und druchgeführte aktionen zu merken.
Damit kann dann hinterher lediglich festgestellt werden, wer für eine missere veranwortlich war. Z.b. löschen eines kompletten Datenbestandes.

Zum anderen gitb es eine historie, welche änderungen in einem vorfall pflegt und merkt. Die funktionsweise ist denkbar einfach.
z.B. Bei einem Konto verweist z.B. der Kontostand auf eine Liste welche entpsrechend der historie gepflegt wird. dazu gibt es im Regelfall eine Buchungsnsummer.

-> Du benötigst immer einen historischen Bezug.

Diese Buchungsnummer dient hierbei als Grundlage für sämmtliche andere Sachen. z.B. was ist gebucht worden von wo nach wo welcher Betrag usw.

Das war nur mal ein kleiner sehr kleiner vorgeschmack zum thema.
Grundssätzlich wird hier keiner Deine Hausaufgaben machen. setz dich mit dm thema auseinander und mach Deine arbeit selbst.

Links zum thema habe ich leider nicht.
Aber eine Tip mach dir gedanken übr obiges Beispiel und Du wirst schon etwas dazu finden. PS Data Warehousing ist da noch ein Stichwort.

[Michael N.]

Hallo Lude, Hallo Matze,

Ein richtig umfangreiches Thema hast Du dir dabei raus gesucht.

dem kann ich nur beipflichten.

Zusätzlich sind unter Umständen noch die Themen Archiving und Data-Recovery wichtig, was dann aber auch in den Bereich Backup-Strategien zielt. Interessant ist auch, das speziell bei Großprojekten mit Großrechnerdatenbanken dann in den Tabellen Datensätze eine sogenannte "Duftmarke" und auch oft genug Effectiv- und Expierie-Spalten vorhanden sind, welche zum einen ein Tracking auf die letzte Änderung erlauben (Jede Änderung hinterläßt ihre Spur mittels Tag, Zeit und UserID), als auch erlauben, daß Inhalte zwar in der Jetztzeit invalide sind, in der Historie oder Zukunft aber durchaus eine Relevanz haben.

Mittels der Effectiv-/Expirie-Methodik kannst Du dann zum Beispiel sagen, daß ein Satz bis zur Änderung valide ist, nach einer Änderung wird der Satz kopiert, der alte Satz erhält den aktuellen Timestamp als Expirie und der neue denselben Stamp als Effectiv und gleichzeitig werden die Änderungen im neuen(!) Datensatz gemacht. Das eignet sich aber nur, wenn Du die Sätze nicht in alle Ewigkeit aufbewahren mußt oder genügend Kapazität hast um diese Mimik über die gesamte Laufzeit der DB zu halten (auch die Schwerstlaster unter den Datenbanken haben, wenn auch sehr hohe, Grenzen der Verarbeitungskapazität).

Das war nur mal ein kleiner sehr kleiner vorgeschmack zum thema.
Grundssätzlich wird hier keiner Deine Hausaufgaben machen. setz dich mit dm thema auseinander und mach Deine arbeit selbst.

Er bekommt ja auch nur Hilfe zur Selbsthilfe und mehr nicht.

Bis denndann

Michael N.

[Lude]

Hallo, Michael,

Ein richtig umfangreiches Thema hast Du dir dabei raus gesucht.

dem kann ich nur beipflichten.

es gibt im Web recht wenig Material dazu.

Interessant ist auch, das speziell bei Großprojekten mit Großrechnerdatenbanken dann in den Tabellen Datensätze eine sogenannte "Duftmarke" und auch oft genug Effectiv- und Expierie-Spalten vorhanden sind, welche zum einen ein Tracking auf die letzte Änderung erlauben (Jede Änderung hinterläßt ihre Spur mittels Tag, Zeit und UserID), als auch erlauben, daß Inhalte zwar in der Jetztzeit invalide sind, in der Historie oder Zukunft aber durchaus eine Relevanz haben.

Ja, richtig. - Allerdings sehe ich noch keinen Zusammenhang mit Daten-Historisierung. Da wurden doch einfach einer Tabelle zwei Dimensionen hinzugefuegt, die Bedingungen setzen, wenn der Datensatz gerade "gueltig" ist.

Mittels der Effectiv-/Expirie-Methodik kannst Du dann zum Beispiel sagen, daß ein Satz bis zur Änderung valide ist, nach einer Änderung wird der Satz kopiert, der alte Satz erhält den aktuellen Timestamp als Expirie und der neue denselben Stamp als Effectiv und gleichzeitig werden die Änderungen im neuen(!) Datensatz gemacht.

Fragen:
Was genau bedeutet ein "effective"-DF und ein "expiry"-DF?
Was heisst hier kopieren?
Was wolltest Du mit dem letzten Teilsatz aussagen?

Das eignet sich aber nur, wenn Du die Sätze nicht in alle Ewigkeit aufbewahren mußt oder genügend Kapazität hast um diese Mimik über die gesamte Laufzeit der DB zu halten (auch die Schwerstlaster unter den Datenbanken haben, wenn auch sehr hohe, Grenzen der Verarbeitungskapazität).

Was ist Mimik?

---

Weitere Fragen waeren:

• Soll man Daten-Historisierung ueber Trigger realisieren, falls diese vom RDBMS als Objekt bereitgestellt werden?
• Soll man die Daten-Historisierung beim Datenzugriff platzieren, (also bei den SPs)?
• Soll man fuer historische Daten eine zweite DB mit dem gleichen Schema wie die Quell-DB halten?
• Welche Ueberlegungen bzw. der vorhandenen Ressourcen duerfen gestellt werden? - Wie "teuer" ist Daten-Historisierung?
• Was sind die Ziele, die mit Historisierung erreicht werden sollen?
• Gehen Daten-Historisierung und Sicherheit immer Hand in Hand?

Diese Fragen werden morgen in meinem Vortrag von mir alle kompetent beantwortet werden.   *huestel*

Gruss,
Lude

[Michael N.]

Hallo Lude,

Ein richtig umfangreiches Thema hast Du dir dabei raus gesucht.
dem kann ich nur beipflichten.
es gibt im Web recht wenig Material dazu.

Unter Umständen solltest Du mal versuchen Dich bei den großen Datenbankherstellern herumzutreiben (DB2 ist zum Beispiel von IBM, Oracle, wer war da noch mal der Hersteller???) und den dazugehörigen Foren.

Interessant ist auch, das speziell bei Großprojekten mit Großrechnerdatenbanken dann in den Tabellen Datensätze eine sogenannte "Duftmarke" und auch oft genug Effectiv- und Expierie-Spalten vorhanden sind, welche zum einen ein Tracking auf die letzte Änderung erlauben (Jede Änderung hinterläßt ihre Spur mittels Tag, Zeit und UserID), als auch erlauben, daß Inhalte zwar in der Jetztzeit invalide sind, in der Historie oder Zukunft aber durchaus eine Relevanz haben.
Ja, richtig. - Allerdings sehe ich noch keinen Zusammenhang mit Daten-Historisierung. Da wurden doch einfach einer Tabelle zwei Dimensionen hinzugefuegt, die Bedingungen setzen, wenn der Datensatz gerade "gueltig" ist.

Auf diese Weise hältst Du historische Daten in der Datenbank selbst vor. Die Zeit ist einfach auch eine Dimension, genau, wie Zeile und Spalte. Hast Du dann das Effectiv- und Expirie-Date im Index der Tabelle, vermeidest Du trotz der datenduplizierung einen Indexkonflikt.

Mittels der Effectiv-/Expirie-Methodik kannst Du dann zum Beispiel sagen, daß ein Satz bis zur Änderung valide ist, nach einer Änderung wird der Satz kopiert, der alte Satz erhält den aktuellen Timestamp als Expirie und der neue denselben Stamp als Effectiv und gleichzeitig werden die Änderungen im neuen(!) Datensatz gemacht.
Fragen:
Was genau bedeutet ein "effective"-DF und ein "expiry"-DF?

Effective heißt der Inhalt des Datensatzes ist gültig ab Zeitpunkt X, Expiry heißt, daß die Gültigkeit des Inhaltes zum Zeitpunkt Y ausläuft. Das ganze ist ein einfacher Eintrag in einem Feld des Datensatzes, den Du mittels Programmlogik auswerten kannst.

Was heisst hier kopieren?

Nehme alle Inahlte aus Datensatz A und speichere sie als neuen Datensatz. (Hier stößt Du aber u.U. an Indizierungsprobleme, also nimmt man die Gültigkeitsdaten in den Schlüssel, setzt den "alten" Datensatz auf nicht mehr gültig ab Zeitpunkt X und den neuen Datensatz auf gültig ab Zeitpunkt X und nimmt als "Gültigkeitsende" erstmal den Wert, welcher intern als Ende der Zeit definiert wurde.

Was wolltest Du mit dem letzten Teilsatz aussagen?

Das eignet sich aber nur, wenn Du die Sätze nicht in alle Ewigkeit aufbewahren mußt oder genügend Kapazität hast um diese Mimik über die gesamte Laufzeit der DB zu halten (auch die Schwerstlaster unter den Datenbanken haben, wenn auch sehr hohe, Grenzen der Verarbeitungskapazität).
Was ist Mimik?

Diese Vorgehensweise. Da Du ja bei jeder Änderung von Daten einen neuen Satz hinzufügst, ist je nach Nutzung der Tabelle irgendwann der Punkt erreicht, wo u.U. die Kapazität der Datenbank (alle Datenbanken haben zwar im Prinzip unendlich große Tabellen, aber ab einer bestimmten Menge von Daten in einer Tabelle kommt es zu Problemen {Beispiel: generiere mal unter MS-Access zwei Tabelle mit 500.000 Datensätzen und einem gemeinsamen Schlüssel und mache dann einen Join dieser beiden Tabellen und laß Dir das ganze anzeigen [Aber Achtung: das kann u.U. Stunden dauern], machst Du dasselbe dann und MySQL auf einem UNIX/LINUX-System, wirst Du unter Umständen schon beobachten können, daß MySQL für die gleiche Operation weniger Zeit braucht, gehst Du dann mit einer Oracle DB, wirst Du einen weiteren zeitlichen Effekt sehen, DB2 auf dem Mainframe wird Dich am Schluß sogar verblüffen}. Diese Effekte entstehen zum einen durch Unterschiede in der Software-Architektur, zum anderen natürlich in der Hardware, aber Du kannst den Effekt auch schon bei vergleichbarer Hardware und unterschiedlichen Datenbanken feststellen.) Dir einen bösen Streich spielt.

Weitere Fragen waeren:

• Soll man Daten-Historisierung ueber Trigger realisieren, falls diese vom RDBMS als Objekt bereitgestellt werden?

Das hängt immer davon ab, ob man sich 1000%ig sicher ist, daß a. kein Wechsel des Systems (Oracle --> DB2 o.Ä.) in ferner Zukunft vorgenommen wird, ob b. die verwendete Methodik auch von späteren einzusetzenden Versionen unterstützt wird, ob c. die Steuerung über Trigger in Punkto Transparenz und Dokumentierbarkeit den Richtlinien des Projektes entspricht und ob d. es nicht eine performantere Lösung gibt.

• Soll man die Daten-Historisierung beim Datenzugriff platzieren, (also bei den SPs)?

IMHO sollte, wenn man sich änderbare Daten in der historischen Abfolge halten will, jedes Update sofort zur Protokollierung in der History führen, da ansonsten ein Absturz des Systems zwischen Update und History-Eintrag zu einer Inkonstistenz zwischen dem Protokoll und dem Datenstatus führt (Änderung vollzogen, Historyeintrag dazu fehlt).

• Soll man fuer historische Daten eine zweite DB mit dem gleichen Schema wie die Quell-DB halten?

Das kommt auf die projektinterne Datenstruktur an. Mache ich z.B. beim jeder Änderung einen Eintrag in eine spezielle History-Tabelle, erübrigt sich das, arbeite ich auf der selben Tabelle mit Effectiv/Expiry, erübrigt sich das ganze auch, pflege ich meine History nur via Copy der Altdaten, dann macht das u.U. Sinn.

• Welche Ueberlegungen bzw. der vorhandenen Ressourcen duerfen gestellt werden? - Wie "teuer" ist Daten-Historisierung?

Ein Spiegeln dupliziert mindestens die Menge der notwendigen Speicher- und Verwaltungsressourcen, ein Tracking in der selben Tabelle spart u.U. Ressourcen, eine gesonderte Tracking-Tabelle kann evtl. durch Beschränkung auf den Schlüssel plus ein Datum plus die änderbaren Felder sogar die "billigste" Variante sein.

• Was sind die Ziele, die mit Historisierung erreicht werden sollen?

Gerade in kritischen (Finanz-)Systemen ist es wichtig, daß Änderungen nachvollziehbar sind, damit prüfende Institutionen nachvollziehen können, wie bestimmte Eckwerte zustande kommen (siehe: Dein Kontoauszug {oder was würdest Du sagen, wenn Du lediglich die Mitteilung bekämst: "Ihr Kontostand beträgt: ###.###,## EUR" und nicht wüßtest, woher und wohin Dein Geld fließt}).

• Gehen Daten-Historisierung und Sicherheit immer Hand in Hand?

Daten-Historisierung ist eines von vielen Elementen im Bereich der IT-Sicherheit, weitere Elemente, wie Toolauswahl, Zugangsberechtigungen, Passwort-Managment, Backup-/Recovery-Strategien, Disaster-Recovery-Plänen, Notfalltests und Verschlüsselung gehören natürlich immer zur Sicherheit dazu.

Diese Fragen werden morgen in meinem Vortrag von mir alle kompetent beantwortet werden.   *huestel*

Na dann viel Spaß, ich hoffe, ich konnte Dir genügend Denkanstöße geben.

Bis denndann

Michael N.