Woher ein Fakt stammt und wann er galt
Die meisten Datenbanken in Unternehmen halten pro Feld einen Wert. Ändert er sich, wird der alte überschrieben. Das geht gut, bis jemand nach der Vergangenheit fragt. Was wussten wir über diesen Lieferanten, als wir den Vertrag unterschrieben haben? Wer hat diese Zahl eingetragen, und woher stammt sie? War die Adresse damals falsch, oder ist die Firma später umgezogen?
Schwieriger wird es, wenn Quellen sich widersprechen. Das Handelsregister führt einen Lieferanten unter einer Rechtsform, seine Website nennt eine andere, und ein Jahr später korrigiert das Register den Eintrag. Eine Datenbank mit einem Feld für die Rechtsform kann nur eine dieser Antworten halten. Sie kann nicht sagen, welche Quelle was behauptet hat und seit wann. Dasselbe gilt für Preise, Produktgewichte, Ansprechpartner und Eigentümer. Seit immer mehr Quellen KI-generierte Texte enthalten, taugt eine Angabe unbekannter Herkunft noch weniger.
Der zweite Teil meiner Forschungsfrage ist, wie Wissen über ein Objekt zusammen mit seiner Zeit und seiner Quelle gespeichert werden kann.
Jede Angabe behalten, nichts überschreiben
Mein Ansatz: Jeder Fakt wird als eigene Angabe gespeichert, die nie überschrieben wird. Eine Angabe hält den Wert fest, wer ihn eingetragen hat, welche Quelle er nennt und wie vertrauenswürdig diese Quelle ist. Eine Korrektur fügt eine neue Angabe hinzu und blendet die alte aus, ohne sie zu löschen. So zeigt die Datenbank weiterhin, was sie vorher gesagt hat und wer es gesagt hat. Wer einen Wert entfernt, muss das schriftlich begründen.
Der Preis ist das Volumen, denn der Speicher wächst mit jeder Angabe und jeder Korrektur. Das nehme ich in Kauf. Ein überschriebener Wert ist verloren, ein ausgeblendeter lässt sich zurückholen.
Zwei Daten für jeden Fakt
Jede Angabe trägt zwei Daten. Das erste sagt, wann der Fakt galt, etwa der Tag, an dem ein Vertrag begann. Oft kennt eine Quelle nur das Jahr, deshalb darf dieses Datum unvollständig sein. Das zweite sagt, wann die Datenbank von dem Fakt erfahren hat. Ein Registereintrag, den jemand heute liest, kann eine Änderung beschreiben, die vor Jahren wirksam wurde. Mit beiden Daten beantwortet der Speicher zwei verschiedene Fragen: Was galt an einem bestimmten Tag, und was hielten wir an diesem Tag für wahr? Der Fachbegriff dafür ist bitemporale Modellierung.
Vertrauen in Quellen
Quellen sind unterschiedlich verlässlich. Ein amtliches Register zählt mehr als ein Forenbeitrag, ein erfahrener Redakteur mehr als ein neues Konto. Jede Angabe speichert deshalb einen Vertrauensrang, und zwar den niedrigeren aus dem Rang der Quelle und dem Rang des Autors. Der Rang ist ein Beleg für eine spätere Prüfung. Welcher Wert angezeigt wird, entscheidet die letzte redaktionelle Änderung. Sonst würde eine alte, hoch eingestufte Angabe, die niemand mehr sieht, jede Korrektur blockieren. Eine nachlässige Änderung kann dann einen gut belegten Wert verdrängen. Die alte Angabe bleibt aber erhalten, und die Änderung lässt sich rückgängig machen.
Schnelle Kopien bleiben Kopien
Anwendungen lesen aus vereinfachten Kopien, weil das schnell geht: eine flache Spalte pro Wert oder ein Suchindex. Eine solche Kopie verliert Details. Eine Shopseite zeigt dann vielleicht das Bruttogewicht eines Produkts, wo das Nettogewicht hingehört, und die Spalte verrät nicht, welches sie enthält. In meinem Ansatz sind die Angaben die einzige Quelle der Wahrheit. Jede Kopie lässt sich aus ihnen neu aufbauen und schreibt nie zurück. Eine Lücke in den Angaben kann gewollt sein, weil ein Redakteur einen falschen Wert entfernt hat. Wer sie aus einer alten Kopie wieder füllt, setzt sich über diese Entscheidung hinweg.
Was im Einsatz ist und was offen ist
Die Angaben, die zwei Daten und der Vertrauensrang sind auf der Informationsplattform eines Kunden im Produktiveinsatz. Die Änderungen einer Bearbeitung zu einer Version zusammenzufassen, ist ein Entwurf, an dem ich noch arbeite.
Zwei Fragen sind offen. Welchen Wert soll ein Leser sehen, wenn die letzte Änderung und der Vertrauensrang auf verschiedene Angaben zeigen? Und wie folgen die Angaben einem Objekt, wenn sich zwei Datensätze als dasselbe Objekt herausstellen oder ein Datensatz als zwei? Die zweite Frage gehört zu meiner Arbeit an der Objektidentität.
W3C PROV-O und die ISO-Norm zur Datenherkunft nutze ich als Referenzen. Ich bezeichne den Speicher nicht als konform zu einer der beiden.
Suchanfragen zu diesem Thema
- Bitemporale Daten
- Bitemporale Datenbank
- Temporale Datenbank
- Temporale Datenhaltung
- Temporale Daten
- Historisierung Daten
- Historisierung Datenbank
- Versionierung Datenbank
- Versionierung Daten
- Provenienz Daten
- Provenienz Datenbank
- Daten Nachvollziehbarkeit
- Data Lineage
- Data Lineage Bedeutung
- Audit Trail
- Audit Trail Bedeutung
- Audit Log
- Audit Logging
- Änderungshistorie
- Revisionssicherheit
- Revisionssicherheit Software
- Event Sourcing
- Event Sourcing Deutsch
- Event Sourcing Pattern
- Append Only Database
- Append Only Ledger
- Datenquellen
- Metadatenmanagement
- Datenqualität Kriterien