-
Notifications
You must be signed in to change notification settings - Fork 7
Framework 2
Das Framework muss für den Umstieg auf Laminas unabhängig von Zend-Db gemacht werden. Die existierende Implementation der Datenbankanbindung kann nicht einfach auf Laminas umgestellt werden. OPUS 4 nutzt Aspekte von Zend-Db im Zend Framework 1, die in späteren Version nicht mehr vorhanden sind.
Die Datenbankanbindung soll mit Doctrine neu umgesetzt werden. Dabei sollen die Erfahrungen der letzten 10 Jahr OPUS 4 Entwicklung einfließen, um die neue Implementation an vielen Stellen zu vereinfachen und an anderen flexibler zu gestalten. Laminas-Db wird nicht, verwendet, weil dort keine Weiterentwicklung mehr stattfindet und ein Umstieg auf Doctrine-DBAL empfohlen wird.
Die Daten im OPUS 4 Framework lassen aufteilen.
- Verwaltungsdaten (Account, UserRole, EnrichmentKey usw.)
- Dokumente (Document, Title, Identifier usw.)
- Referenzdaten (Licence, DnbInstitute, Collection usw.)
- Personen
- Übersetzungen
- XML-Cache
- Properties
Das sind die Datenmodelle, die der Verwaltung, dem Betrieb einer OPUS 4 Instanz dienen.
Das sind die Metadaten, die nur zu einem einzelnen Dokument gehören. Hier wird eine Vereinfachung angestrebt, die letztendlich mehr Flexibilität bringen soll. Erweiterungen sollen ohne Änderungen im Datenbankschema möglich sein. Das heißt die Metadaten sollen nicht mehr über viele Tabellen und Spalten verteilt, sondern als Block, vermutlich JSON, gespeichert werden.
Das sind die Datenobjekte, die mit mehreren Dokumenten verknüpft sind, z.B. Lizenzen oder Sammlungen. Diese Objekte sollen wie bisher in der Datenbank gespeichert werden. Die verschiedenen Objekttypen haben aber unterschiedliche Anforderungen und sollten einzeln betrachtet werden. Sammlungen werden zum Beispiel für Abteilungen und Projekte eines Instituts verwendet, lokale Informationen, aber auch für Klassifikationen, die externe Standards darstellen. Auch wenn in beiden Fällen Sammlungen für die Abbildung der Hierarchien verwendet werden, sollten Klassifikationen eine separate API bekommen, so dass dort auch alternative Implementationen, möglicherweise ohne Verwendung der Datenbank möglich sind. Eine Klassifikation könnte auch als XML oder JSON Datei gespeichert sein, insbesondere wenn alle Suchfunktionen über den Index ausgeführt werden und die ursprüngliche Speicherung der Klassifikationseinträge keine Rolle mehr spielt.
Personendaten sind ein Sonderfall, zum einen sollen sie wie Referenzdaten behandelt werden, so dass Dokumente mit bekannten Personen verknüpft sind, deren Daten zentral verwaltet werden können. Andererseits sind die Metadaten von Personen spezifisch zu einzelnen Dokumente, so sollen zum Beispiel unterschiedliche Schreibweisen berücksichtigt werden. Hier muss überdacht werden was sinnvoll und machbar ist.
Die lokalen Anpassungen an den Übersetzungen werden in der Datenbank gespeichert. Das sind im Prinzip Verwaltungsdaten. Die API und Implementation für die Speicherung von Übersetzungen sind aber völlig unabhängig und eine alternative Implementation, die nicht die Datenbank verwendet, ist vorstellbar.
Der XML-Cache speicher XML-Versionen von Dokumenten, um Export und Anzeigefunktionen zu beschleunigen. Das ist völlig unabhängig von den anderen Datenmodellen, die in der Datenbank gespeichert werden. Alternative Implementation, die unter Umständen, nicht mehr die Datenbank verwenden sind denkbar. Die Umsetzung des XML-Cache, wie bei den Übersetzungen, sollte also möglichst unabhängig sein.
Properties wurden eingeführt, um für verschiedene Objekt-Typen, insbesondere Personen, Dokumente und Dateien, zusätzliche, interne Informationen abspeichern zu können, die nicht im externen Datenmodell auftauchen sollen und nicht der Verwaltung durch die Nutzer unterliegen. Momentan werden solche Informationen immer noch als Enrichments gespeichert, was Nutzerdaten und interne Informationen vermischt und für Nutzer wie auch Entwickler mehr Aufwand bedeutet. Die existierenden Enrichments wurden noch nicht auf Properties umgestellt.
Für die Properties muss überlegt werden, wie sie am Besten in das Datenmodell und seine Implementation passen. Sollen sie mit der neuen Implementation in das "normale" Datenmodell integriert werden oder ist es sinnvoll sie weiterhin separat zu behandeln? Die regulären Metadaten eines Dokuments sollen in Zukunft als JSON-Block gespeichert werden. Für die internen Properties gibt es aber andere Anforderungen. Sie werden häufiger aktualisiert und unter Umständen in SQL-Queries verwendet. Daher macht eine separate Implementation direkt in der Datenbank vermutlich weiterhin Sinn.