Änderungsmanagement und Workflows

Die anderen Forschungsseiten beschreiben einen Datenspeicher im Ruhezustand. Im Tagesbetrieb ändert er sich: Importe legen neue Datensätze neben bestehende, Redakteure korrigieren Fakten, und das Schema bekommt ein Feld dazu oder verliert eines. Hier stehen die Regeln, die ich auf einer Informationsplattform für diese Änderungen aufstelle.

Gleiche Adresse, anderes Unternehmen

Zwei Unternehmen können unter derselben Adresse eingetragen sein, und zwei Produkte verschiedener Hersteller können denselben Namen tragen. Ein Matcher bewertet beide Paare hoch, und eine Zusammenführung, die dem Score vertraut, zerstört einen der beiden Datensätze.

Meine Regel ist ein Satz von Identitäts-Vetos, die jeder Scanner und jede Merge-Routine prüft, bevor sie schreibt. Ein Veto ist ein harter Widerspruch zwischen zwei Datensätzen. Der Lebenszyklusstatus ist einer: Ein aufgelöstes Unternehmen und ein später an derselben Adresse gegründetes sind zwei Entitäten. Ein Namenszusatz ist ein anderer: „Werk Nord“ und „Werk Süd“ sind Geschwister. Dasselbe gilt für ein gemessenes Attribut außerhalb einer festen Toleranz.

Ein hoher Match-Score setzt sich nie über ein Veto hinweg. Ein gemeinsamer Name, eine gemeinsame Adresse oder eine gemeinsame externe Kennung erzeugt einen Kandidaten und entscheidet nichts. Objekte über Anwendungsgrenzen hinweg verfolgen beschreibt das Identitätsmodell hinter dieser Regel.

Eine Zusammenführung ist ein Soft Delete. Der verbleibende Datensatz übernimmt die Kennungen des stillgelegten, und dessen Name wird zum Alias. So lässt sich eine falsche Zusammenführung zurücknehmen.

Was ein Dublettenscan messen muss

Ein Scan meldet die Paare, die er abgelehnt hat, ebenso wie die Zusammenführungen, die er vorgenommen hat: wie viele Kandidaten jedes Signal erzeugt hat, wie viele an einem Veto gescheitert sind und welche Paare unter der Schwelle für das automatische Zusammenführen geblieben sind.

Kandidaten dürfen nicht nur aus Namen kommen. Der englische und der französische Name eines Unternehmens haben kein Token gemeinsam, deshalb holt ein Scan Kandidaten auch über den Standort und über übereinstimmende Messwerte.

Eine geprüfte Stichprobe gehört in jeden Bericht. Findet eine manuelle Prüfung unter Paaren, die einen strengen Filter passiert haben, verschiedene Entitäten, dann ist das Signal für automatische Zusammenführungen zu schwach. Paare, die die Vetos nicht klären, gehen an KI-Agenten unter denselben Regeln wie Menschen, und „unsicher“ lässt beide Datensätze stehen.

Änderungen an Fakten

Jeder Fakt ist eine versionierte Zeile, wie es Woher ein Fakt stammt und wann er galt beschreibt. Die Zeile ist die Wahrheit, eine flache Spalte daneben ist eine Projektion. Scheitert das Schreiben der Zeile, ist das Speichern gescheitert. Wo Zeilen und Spalten in Altdaten voneinander abweichen, entscheide ich pro Feld, welche Seite stimmt, denn eine Pauschalregel schreibt falsche Werte in großer Menge.

Ein Rollback legt die Zeilen still, die ein Import geschrieben hat, und die früheren Zeilen werden wieder sichtbar. Er löscht nichts. Den alten Wert ein zweites Mal zu speichern, wäre eine neue Bearbeitung und ließe die fehlerhaften Zeilen in der Historie stehen.

Änderungen am Schema

Eine Schemaänderung beginnt mit einer Zählung. Bevor ein Flag aus dem Code verschwindet, zähle ich die Zeilen, die allein dieses Flag verbirgt, denn sie werden sichtbar, sobald es fehlt. Bevor eine Tabelle außer Gebrauch geht, belegt eine feste Folge von Prüfungen, dass nichts mehr aus ihr liest oder in sie schreibt. Die Tabelle bekommt dann ein Präfix als Markierung und bleibt in PostgreSQL. Nach der Änderung laufen dieselben Zählungen noch einmal und müssen die Vorhersage treffen.

Skripte und Obergrenzen für Schreibprozesse

Skripte schreiben über ein SDK, das auf der API aufsetzt, also auf demselben Weg, auf dem ein Redakteur speichert. Das SDK protokolliert jeden Aufruf ohne das Access Token. Jede Umgebung hat eine Obergrenze für gleichzeitige Schreibprozesse in PostgreSQL. Ändert ein Job die Zahl seiner Schreibprozesse, halten zuerst alle an, und die verbleibenden Zeilen werden in einen Shard pro neuem Schreibprozess aufgeteilt.

Offene Fragen

Die Vetos, die Zusammenführung ohne Löschen, Rollbacks, die Zeilen stilllegen, gezählte Schemaänderungen und die Obergrenze für Schreibprozesse sind auf der Informationsplattform eines Kunden im Produktiveinsatz. Zwei Fragen sind offen.

Die erste: Wo soll das automatische Zusammenführen aufhören? Unterhalb einer Schwelle kann der Matcher eine echte Dublette nicht von einem nahen Nachbarn unterscheiden, und diese Kandidaten brauchen einen Menschen oder bessere Belege.

Die zweite: Wie lassen sich gemeinsame Kennungen prüfen, bevor ein Datensatz entsteht, sodass eine Dublette schon am Eingang abgewiesen wird und nie später zusammengeführt werden muss?