nicht angemeldet
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.