Geänderte Daten aus der ExpoDB

Christof Mainberger, 20.11.2024

Eine Grundidee der ExpoDB ist, dass die Museen für die Online-Publikation ihrer Daten nicht von ihren Webagenturen jeweils eine eigene zusätzliche Datenhaltung einrichten lassen müssen. Vielmehr sollte die ExpoDB die zentrale Infrastruktur bilden, die über passende Schnittstellen alle Datenbedarfe von Frontends der Digitalen Kataloge bedient. Dennoch sind inzwischen redundante Datenbanken entstanden, sei es dass Museen mit regionalen Portalen zusammenarbeiten müssen, sei es, dass ambitionierte Projekte eine weitere Aufbereitung der Datensätze erfordern. Oder man traut einfach der Recherche in der ExpoDB nicht. Jedenfalls möchte man solche sekundären Datenbestände nicht jede Nacht vollständig erneuern (wie die ExpoDB jede Nacht aktualisiert wird), sondern man erwartet einen Änderungsdienst, der es erlaubt, nur neue sowie geänderte Datensätze abzurufen. 

Um in der ExpoDB eine Abfrage anzubieten, die nur die seit einem bestimmten Datum geänderten Datensätze liefert, muss die ExpoDB zunächst selbst wissen, wann ein Datensatz zuletzt geändert wurde. Es wäre denkbar, die Daten beim Aktualisieren jeweils mit dem Stand vom Vorabend zu vergleichen. Ein solcher Vergleich Datensatz für Datensatz würde das Update stark ausbremsen, weshalb dieser Ansatz bislang noch nicht verfolgt wurde. Stattdessen ist die Feststellung des letzten Änderungsdatum auf die Daten angewiesen, die dazu in imdas pro zu ermitteln ist. 

In imdas pro ist jede Zeile in jeder Tabelle mit einem last-modified-Datum ausgestattet, das mit jeder Änderung des Datensatzes angepasst wird. Für die ExpoDB werden nun die Entitäten mit ihren Feldern, Komponenten, Thesauri und benutzerdefinierte Felder aus vielen imdas pro-Tabellen zusammengebaut. Immer wenn auf diesem Weg ein aus imdas pro stammendes Änderungsdatum jünger ist, als das bis dahin für die Entität ermittelte akkummulierte Änderungsdatum, wird das letztere durch das jüngere ersetzt. So ergibt sich schließlich für die Entität das jüngste Datum aller beteiligten imdas pro-Datensätze. Dieses wird für die Entität in einem speziellen Solr-Index "modified" indexiert. Das Datum wird dazu in eine invertierte Form geschrieben, so dass aus dem 20.11.2024 ein String 2024-11-20 wird, der in der korrekten zeitlichen Reihenfolge sortierbar ist. 

Wie jeder Index in der ExpoDB kann dieser Index über die Schnittstelle abgefragt werden: Der Abfrageparameter qry=modified gt "2024-11-19" ergäbe demnach alle Datensätze, die nach dem 19.11.2024 angelegt oder geändert worden sind. Die Treffer der Recherchen werden vor der Auslieferung noch durch ein Format aufbereitet. Unter anderem legen diese Formate fest, welche Datenelemente ins Resultat übernommen werden und welche ausgeschlossen werden. Dabei könnte z.B. eine Komponente wegfallen, die kürzlich geändert wurde und für das Änderungsdatum der Entität verantwortlich war. Dann unterscheidet sich das Resultat u.U. nicht von dem zum gleichen Datensatz vom Vortag und kommt trotzdem bei den geänderten. Dieser Effekt führt allerdings schlimmstenfalls zu mehr scheinbar geänderten Datensätzen. Es fallen jedenfalls keine wirklich geänderten unter den Tisch.

Über die Schnittstelle gibt es keine Möglichkeit, mitzuteilen, ob Datensätze gelöscht wurden oder ob Datensätze aus dem Teilbestand herausgefallen sind, der für eine bestimmte Datennutzung definiert ist. Es werden aus imdas pro lediglich vorhandene Daten übernommen , nicht Daten, die nicht mehr da sind. Ebensowenig wird bei der Auswertung der Einschränkung auf einen Teilbestand, z.B. für die Online-Publikation, untersucht, welche nicht enthaltenen Datensätze evtl. am Vortag noch den Kriterien entsprachen. Es kommt nun verhältnismäßig selten vor, dass Datensätze wegfallen. Um dennoch solche obsoleten Datensätze von Zeit zu Zeit auszusondern, muss auch bei diesen inkrementellen Updates mittels des modified-Index ab und an eine Gesamtaktualsisierung des redundanten Datenbestands vorgenommen werden.