Objekte über Anwendungsgrenzen hinweg verfolgen

Ein Objekt ist ein Ding in der Welt. Ein bestimmtes Gebäude ist eines, ein Unternehmen ein anderes. Es gibt viele Gebäude, und jedes System, das ein Gebäude erfasst, verwaltet es für sich: das Handelsregister, ein Statistikamt und jede Datenbank, die es führt. Objektidentität beantwortet zwei Fragen zu einem Datensatz: Was für ein Ding ist das, und welches Exemplar dieser Art? Beide Antworten sind eine Klassifikation des Objekts. Die ID, die eine Datenbank dem Objekt gibt, ist ein Handle für diese Klassifikation und bedeutet für sich allein nichts. Diese Seite beschreibt das Modell der Informationsplattform eines Kunden, das ich im Rahmen meines Forschungsschwerpunkts entwickle.

Typfelder sind ein Klassifikationssystem

Objekten sind oft ein oder mehrere Typen zugewiesen, und der Typ ist die erste Hälfte ihrer Klassifikation. Der Datensatz eines Gebäudes ist der Datensatz eines Gebäudes, gleich welche Organisation ihn geschrieben hat, und eine Zusammenführung ändert nie die Klasse eines Objekts.

Die zweite Hälfte ist die Frage, welches Gebäude der Datensatz beschreibt. Die Antwort geben die Registercodes und die Same-as-Links in den folgenden Abschnitten. Ein gemeinsamer Name allein genügt dafür nicht, denn zwei Gebäude können denselben Namen tragen.

Die ID ist eine Verbindung

Die ID beantwortet keine der beiden Fragen. Sie sorgt dafür, dass jede Tabelle, jede URL und jedes Suchdokument zu einem bestimmten Zeitpunkt, meist in der Vergangenheit, auf dasselbe Objekt zeigt.

Jedes Objekt hat eine ID, und diese ID gehört zu nichts anderem. Ein einziger Allokator zieht aus einer Sequenz und überspringt jede Nummer, die schon ein Objekt oder eine Aussage trägt. Eine Entität entsteht mit dem Objekt zuerst: Die Objektzeile und ihre Aussagen werden in einer Transaktion geschrieben.

Eine ID, die nur innerhalb ihrer Tabelle eindeutig ist, wird mehrdeutig, sobald eine zweite Tabelle IDs derselben Art enthält. Der Preis eines gemeinsamen ID-Raums ist ein zentraler Allokator, von dem jeder schreibende Prozess abhängt.

Versionen gehören zum Objekt

Eine Bearbeitung erzeugt eine Version des Objekts, und die Objektzeile bleibt dieselbe. Jede Relation, jede URL, jede Berechtigungsprüfung und jedes Suchdokument meint mit der Objekt-ID das Ding selbst.

Die Grenze einer Version ist die vollständige Änderung: Ein Absenden durch einen Nutzer oder ein Element eines Imports erzeugt höchstens eine Version. Auch ein Rollback ist eine neue Version, die Historie wächst also nur.

Auf Speicherebene besteht eine Änderung aus vielen Schreibvorgängen auf Zeilen, und eine Historie auf dieser Ebene kann die Person, die die Änderung gemacht hat, nicht lesen. Die Version ist über die Änderung definiert, die ein Nutzer sieht, und die Tests prüfen, wie viele Versionen sie erzeugt.

Beziehungen sind Objekte

Eine Beziehung wie die Rolle einer Person in einem Unternehmen ist oft eine Datenzeile, die einem ihrer Endpunkte gehört. Eine solche Zeile hat keine Identität und lässt sich weder für sich versionieren noch für sich stilllegen.

Jede Beziehungsfamilie ist ein eigener Objekttyp. Eine Beziehung hat ihre eigene ID und ihre eigenen Versionen, und ihre beiden Endpunkte sind Aussagen über sie. Ein Vertrag zwischen zwei Unternehmen kann enden, während beide weiterbestehen, und dieses Ende ist eine Version des Vertrags. Die Kosten sind mehr Objekte und ein zusätzlicher Join bei jeder Traversierung.

Registercodes sind ein gemeinsamer Schlüssel

Eine interne ID sagt einem Statistikamt nichts. Den Registercode kennen beide Seiten. Die Regel lautet: ein Datentyp pro Register und pro Verwaltungsebene. Der Code bleibt durchgehend ein String, denn eine führende Null gehört zu ihm.

Was ein Code beweist, hat zwei Grenzen. Register vergeben Codes neu, sodass ein Code, der in einer Ausgabe einen Ort bezeichnet, in der nächsten einen anderen bezeichnen kann. Und eine gemeinsame Kennung ist ein schwacher Beleg für eine Zusammenführung, denn Datensätze mit gleicher Kennung oder gleichem Weblink unterscheiden sich oft in einem grundlegenden Fakt. Sie erzeugt nur einen Kandidaten für die Prüfung auf Dubletten.

Same-as-Links

Ein Same-as-Link sagt aus, dass zwei Objekte dasselbe Ding in der Welt bezeichnen, im strengen Sinn von owl:sameAs. Beide Objekte behalten ihre IDs und ihre Historie, deshalb ist das Zurückziehen eines Links eine einzige Änderung. Nur akzeptierte, veröffentlichte Links gehen in die transitive Hülle der Identität ein.

Konfidenz ist ein Wert an einer einzelnen Aussage und nicht transitiv: Ein Score für A und B und ein Score für B und C ergeben keinen Score für A und C. Harte Vetos laufen vor der Annahme, und kein Score setzt sich über sie hinweg. Ein Veto ist ein Widerspruch zwischen den beiden Objekten, etwa ein aufgelöstes und ein aktives Unternehmen.

Fazit

Ein System, das datensatzbasierte Informationen verwaltet, braucht Software, die die Klassen dieser Objekte erkennt, die Fakten über sie prüft, die Quellen bewertet und die Daten aktuell hält. Der Bedarf ist derselbe zwischen Organisationen und Nutzern, wo mehrere Systeme Kopien eines Objekts halten, und dort, wo Register und Partner eigene Datensätze desselben Dings führen.

Die Systeme, die heute am Markt sind, decken diesen Bedarf nicht. Eine Datenbank gibt einem Objekt eine ID und überlässt das Gerüst der Klassifikation und die Aktualisierung ihren Nutzern. Deshalb veralten Systeme mit der Zeit, werden fehlerhaft oder beides. Das System, das ich entwerfe, hilft Nutzern, besser mit diesen Problemen umzugehen: veränderbare Definitionen seiner Struktur, einheitliche Klassifikation, Versionen, die zum Objekt gehören, verbundene Objekte als gemeinsamer Schlüssel und Regeln, die sperren oder freigeben.