Objekte und Identität.

Ein Objekttyp hat einen Namen, einen Primärschlüssel und typisierte Eigenschaften: Text, Zahl mit Einheit, Datum und Zeit, Aufzählung, Geometrie, Verweis. Pflichtfelder, Wertebereiche und Formate stehen am Typ und werden bei jedem Schreiben geprüft. Abgeleitete Eigenschaften rechnen aus anderen Eigenschaften und führen keine eigene Wahrheit.

Jede Eigenschaft trägt Markierungen, etwa personenbezogen oder vertraulich, die später die Rechteprüfung liest. Der Schutz hängt damit am Feld und nicht an der Ansicht, in der es gerade erscheint.

Ein Verknüpfungstyp verbindet zwei Objekttypen und trägt eine Kardinalität: eins zu eins, eins zu viele oder viele zu viele. Eins zu viele bildet FORGE über einen Verweis am Objekt der Seite mit vielen ab, viele zu viele über eine eigene Verknüpfung, die auch Eigenschaften der Beziehung tragen kann, etwa seit wann sie gilt.

Die Kardinalität ist eine Regel. Liefert eine Quelle zwei Verweise, wo einer erlaubt ist, überschreibt FORGE nicht still den älteren. Es entsteht ein Konflikt, der mit beiden Herkünften sichtbar bleibt, bis die Quelle ihn auflöst oder die zuständige Stelle entscheidet.

Eine Abbildung beschreibt je Quelle, welche Spalten welchen Eigenschaften entsprechen, wie Werte umgerechnet werden (Einheit, Zeitzone, Zeichenkodierung) und aus welchen Spalten sich der Schlüssel bildet. Abbildungen sind deklarativ und versioniert. Dieselbe Rohzeile ergibt mit derselben Version der Abbildung immer dasselbe Objekt; das macht jeden Lauf wiederholbar.

Mehrere Quellen dürfen dieselbe Eigenschaft liefern. Welcher Wert gilt, entscheidet eine Regel an der Eigenschaft: die führende Quelle, der jüngste Gültigkeitszeitpunkt oder ein Vorrang nach Güte. Die unterlegenen Werte bleiben mit ihrer Herkunft erhalten und lassen sich jederzeit abrufen.

Dasselbe Ding steht oft in mehreren Systemen, mit verschiedenen Schlüsseln. FORGE löst es zuerst über feste Schlüssel auf: Kennungen, die beide Systeme führen, oder eine gepflegte Zuordnungstabelle. Was so zusammenfällt, ist eindeutig.

Wo feste Schlüssel fehlen, vergleicht FORGE Kandidaten unscharf: Namen über Ähnlichkeitsmaße für Zeichenketten wie Jaro-Winkler oder die Levenshtein-Distanz, Anschriften nach Normalisierung, Datumsangaben mit Toleranz. Damit nicht jedes Paar mit jedem verglichen wird, bildet FORGE vorher Blöcke aus groben Merkmalen. Die Übereinstimmungen der Felder ergeben eine Gesamtbewertung, gewichtet nach dem Verfahren von Fellegi und Sunter.

Über einem oberen Schwellwert verknüpft FORGE selbst, unter einem unteren nie. Dazwischen legt es das Paar zur Bestätigung vor, mit den Feldern, die für und gegen die Verknüpfung sprechen. Jede Zusammenführung ist umkehrbar und steht im Verlauf, mit den Werten und dem Schwellwert, die zu ihr führten.

Die Ontologie selbst ändert sich. Jede Änderung an einem Typ ergibt eine neue Version. Verträglich ist etwa eine neue optionale Eigenschaft; unverträglich sind eine entfernte Eigenschaft, ein geänderter Typ oder eine neue Bedeutung für einen bestehenden Wert.

Unverträgliche Änderungen kommen mit einer Migration, die bestehende Objekte in die neue Form überführt. Die alte Version bleibt lesbar, solange Abnehmer sie brauchen; Abfragen, Handlungen und Rechte nennen die Version, gegen die sie geschrieben sind.

Jede Aussage trägt zwei Zeitachsen: die Gültigkeitszeit, also wann der Sachverhalt in der Welt galt, und die Erfassungszeit, also wann FORGE davon wusste. So lässt sich fragen, was zu einem Stichtag galt, und getrennt davon, was das System damals über diesen Stichtag wusste. SQL:2011 kennt beide Achsen als Anwendungszeit und Systemzeit; FORGE führt sie für jede Eigenschaft.

Eine Korrektur überschreibt nichts. Sie schließt die Erfassungszeit der alten Aussage und legt eine neue mit derselben Gültigkeitszeit an. Spät eintreffende Daten fügen sich so in die Vergangenheit ein, ohne frühere Auswertungen zu verfälschen: Wer eine alte Entscheidung prüft, sieht den Stand, auf dem sie getroffen wurde.