Themabewertung:
  • 1 Bewertung(en) - 5 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Zur Problematik eindeutiger Bezeichner bzw. UUIDs in Datenbanken und Portalen
#1
Die unter anderem vom Archivportal-D gestellte Forderung nach der Führung eindeutiger und unveränderlicher UUIDs (Universally Unique Identifier) in Archivprogrammen bzw. in den zugrundeliegenden Datenbanken stößt in der Praxis auf Konflikte grundsätzlicher Natur, die noch einer Klärung bedürfen. Mit diesem Forumsbeitrag möchten wir auf die Konflikte aufmerksam machen und eine entsprechende Diskussion anregen.

Prinzipiell lässt sich ein zufallsbasierter UUID für jedes Datenelement erzeugen. Soll dieser UUID aber mit Bezug auf das Datenelement eindeutig UND unveränderlich sein, ergeben sich Widersprüche:

- Wird das Datenelement (der Datensatz) kopiert, so ist der UUID doppelt vorhanden. Wird für die Kopie ein neuer UUID vergeben, so gibt es zwei Versionen des gleichen Datensatzes mit unterschiedlichen UUIDs (dabei ist das Eindeutigkeitskriterium des Originaldatensatzes, z.B. das Bestandskürzel, abgeändert).

- Wird der Datensatz exportiert und wieder importiert (im Sinne des AUGIAS-internen MDB-Austauschformats), so ergeben sich ebenfalls Widersprüche. Wird beim Import des betreffenden Datenelementes dessen Eindeutigkeitskriterium verändert, so ist der UUID doppelt vorhanden und nicht mehr eindeutig. Wird der Datensatz in eine andere Datenbank importiert, so können sogar zwei Versionen des Datensatzes mit identischem UUID und Eindeutigkeitskriterium vorliegen.

Fazit:
Im Gegensatz zu den ursprünglichen Überlegungen und Absichten kann ein UUID also entweder unveränderlich ODER eindeutig sein, aber nicht beides. Angesichts dieses Widerspruchs ist die Diskussion über eine abgestimmte und einheitliche Vorgehensweise notwendig.
Zitieren
#2
In einer Diskussion mit den Entwicklern der DNS Software für die Langzeitarchivierung (Projekt DA-NRW) hat sich gezeigt, dass auch dort das Thema eine Rolle spielt. Dazu ein Kommentar von Daniel Marreiros de Oliveira:
"Wir sehen uns einer ähnlichen Problematik gegenüber und gehen damit folgendermaßen um:
Die Maßgabe ist hier tatsächlich, dass unsere Identifier (wir nennen sie technische Identifier, dies sollte aber konzeptionell den UUIDs entsprechen) unveränderlich UND eindeutig sein sollen. Wir würden das Problem also folgendermaßen sehen: Eine Kopie eines Datensatzes bedeutet, dass alle Eigenschaften (Felder) mit kopiert werden, also auch das UUID Feld.
Ein Datensatz entspricht hier mutmaßlich einem „Object“ in unserem Modell. Sobald eine Kopie eines Objektes erzeugt wird, MUSS also auch ein neuer Identifier erzeugt werden. Eine Kopie heißt ja dann, dass es zwei gleichzeitig existierende Instanzen eines Objektes gibt. Jede davon hat als einzelne Instanz einen Identifier.

Vielleicht noch zwei Sätze zum Kontext:
Objekte haben bei uns noch physische Entsprechungen, die repliziert, also in verschiedenen physischen Kopien vorliegen können. Dies sind dann tatsächliche bitgleiche Kopien, die logisch als Object zusammengefasst sind
und damit einen eindeutigen Identifier haben.
Objekte können modifiziert und sogar ergänzt werden. Der Identifier für das Object als logisches Objekt bleibt erhalten. In diesem Fall würden wir nicht von einer Kopie sprechen."
Zitieren
#3
Vielen Dank für den Beitrag.

Die Problematik ist ähnlich, es gibt aber einen grundsätzlichen Unterschied:

In einem Digitalen Langzeitarchiv ist der Zweck einer Kopie (bzw. das Ziel eines Kopiervorgangs) von vorneherein eindeutig definiert, es ist also klar, ob eine Kopie wirklich nur ein Duplikat des Originals ist, oder ob hieraus ein neuer Datensatz entsteht.
Beides sind grundsätzlich verschiedene Vorgänge, die demzufolge eine unterschiedliche Behandlung der UUID erfordert.
Eine Kopie im Sinne einer Duplikaterstellung kann dieselbe UUID wie das Original haben, eine Kopie als Ausgangsbasis für einen neuen Datensatz erfordert eine neue UUID.
Diese Differenzierung kann in einem archivischen Verzeichnungsprogramm aber nicht eindeutig getroffen werden, da es letztlich im Ermessen bzw. der Verantwortung des Anwenders liegt, eine Kopie NACH ihrer Erstellung in einer der beiden genannten Weisen zu verwenden.
Neben der im alltäglichen Gebrauch zwangsläufig vorhandenen Gefahr einer unwillentlichen Fehlbenutzung muss auch bedacht werden, dass vielen Anwendern die hinterliegende Problematik entweder gar nicht oder nur zu gewissen Teilen oder für einen gewissen Zeitraum bewusst ist.
Zitieren
#4
Sehr geehrte Frau Karls,

der von Ihnen zitierte Kommentar enthält genau den Widerspruch, auf den wir aufmerksam machen möchten:

"[...] Eine Kopie eines Datensatzes bedeutet, dass alle Eigenschaften (Felder) mit kopiert werden, also auch das UUID Feld.
[...] Sobald eine Kopie eines Objektes erzeugt wird, MUSS also auch ein neuer Identifier erzeugt werden. [...]"

Der erste Satz spricht von einer Kopie der UUID (Verstoß gegen die Eindeutigkeit), der zweite Satz hingegen von einer Neuvergabe (Verstoß gegen die Unveränderlichkeit).

Soll eine UUID nun eindeutig oder unveränderbar sein? Beides ist nicht zu gewährleisten, es ist also grundsätzlich erforderlich, diesen Widerspruch aufzulösen. Wenn in der Praxis beides auftreten kann, dann wird eher früher als später die UUID nicht mehr den Zweck erfüllen, für den sie ursprünglich geschaffen wurde. Der zitierte Kommentar unterstreicht unsere Sorge, dass die Problematik nicht wirklich verstanden wird und daher kaum gelöst werden kann. Es bereitet uns großes Unbehagen, ein Konzept umsetzen zu müssen, dass von vorneherein widersprüchlich ist.
Zitieren
#5
Hallo allerseits,

Was ich lediglich aus meinem Verständnis feststellen konnte ist, wenn ein Objekt kopiert wird, ein neuer Identifier vergeben werden muss, da es sich dann nicht mehr um das gleiche Objekt handelt. Rein technisch gesprochen handelt es sich dann im Ursprungszustand um eine Kopie, nach der Vergabe des neuen Identifiers jedoch nicht mehr. Vielmehr wäre es als Derivat zu bezeichnen. Das ist wovon ich spreche. Der Identifier des Ursprungsobjektes wurde somit nicht verändert und das Objekt auch nicht, und jeder Identifier identifiziert eindeutig ein Objekt (entweder das neue oder das alte).

Ein anderer Fall wären rein technische Kopien der Objekte, die müssten insgesamt unveränderlich sein und alle Kopien teilen sich einen gemeinsamen Identifier.

Daniel M. de Oliveira
Zitieren
#6
Sehr geehrter Herr de Oliveira,

wir Entwickler können nicht vorhersehen, zu welchem Zweck der Anwender Kopien anfertigt. Vormals erstellte Exporte wieder zu importieren, ist z.B. sowohl für Vergleiche verschiedener Bearbeitungsstände desselben Objekts als auch zur Erfassung von neuen Objekten ähnlichen Inhaltes möglich.

Technische Kopien (Spiegelung von Festplatten, Kopie der Datenbank) gehen ohnehin an der Verzeichnungsssoftware vorbei und bieten erst keine Möglichkeit, Identifier neu zu vergeben. Wir sprechen nur von den Kopien, die mittels der Verzeichnungssoftware erzeugt werden können.

Genau die sind es, die uns Sorgen bereiten, denn:
Wie kann sichergestellt werden, dass
- beim Erstellen einer Kopie bereits klar ist, zu welchem Zweck sie erstellt wird?
- die Kopie später niemals zu dem gegenteiligen Zweck verwendet werden kann?

Tritt im Langzeitarchiv der erste Fall überhaupt auf? Möglicherweise stellt sich bei Ihnen diese Frage gar nicht erst, weil Kopien ohnehin immer nur auf technischer Ebene erzeugt werden?
Zitieren
#7
Sehr geehrter Herr Haps, sehr geehrter Herr Kochsiek

vielen Dank für den Start dieser Diskussion (und bitte entschuldigen Sie die späte Reaktion, da ich zwei Wochen auf Urlaub war), die für die DDB und das Archivportal-D von zentraler Bedeutung ist. Damit Identifier langfristig eindeutig und stabil bleiben, ist nämlich auch das Bewusstsein der Anwender für diese Thematik äußerst wichtig.

Identifier müssen aber beides sein, nämlich einerseits eindeutig und andererseits stabil, ist beides doch die Grundvoraussetzung dafür, dass Inhalte (in diesem Fall Verzeichnungseinheiten) langfristig eindeutig identifizierbar sind.

Ein stabiler Identifier soll im Netz die eindeutige Identifizierung eines Objekts gewährleisten und deshalb auch so bzw. noch sorgfältiger
als die Signatur behandelt werden. Gerade die Generierung des Identifiers bei jedweder Form eines Imports widerspricht dem allerdings. So soll dieser Identifier ja auch einen Software-Anbieter Wechsel überstehen und daher als eigenständiges Feld in der Datenbank (und nicht etwa bloß als primary-key einer Tabelle) definiert sein.

Falls ein Identifier nämlich nicht stabil zu sein braucht, könnte dieser erst beim speziellen Anwendungsfall, etwa beim Import in ein Portal generiert werden, allerdings würde dieser dann seine Bedeutung zur langfristigen Identifizierbarkeit verlieren.

Falls der Identifier aber nicht eindeutig ist, würde dies beim Import in das Archivportal-D dazu führen, dass sich Datensätze gegenseitig überschreiben, da anhand der ID kontrolliert wird, ob ein Objekt bereits existiert, was nicht erwünscht ist. Das Ziel muss daher auf jeden Fall sein, beides zu gewährleisten. Eine komplette Neuvergabe aller Identifier bei jedem Import oder Export der Datenbank würde allerdings den worst-case darstellen.

Vielleicht wäre daher noch eine kurze Erläuterung der Bedeutung des Import-/Kopiervorgangs bei Augias nützlich, was hier also die spezifischen Anwendungsfälle sind und ob hier nicht dem Nutzer die Möglichkeit zur Differenzierung der Anwendungsfälle gegeben werden muss. Ist doch davon abhängig, wie in den vorhergehenden Kommentaren bereits ausgeführt, ob ein Identifier neu vergeben werden sollte oder nicht.

Die Stabilität der Identifier muss sicherlich nicht nur vom technischen Prozess der Vergabe in der Archivsoftware her betrachtet werden, sondern erfordert natürlich auch das Bewusstsein der Nutzer dafür. Wie Sie aber schon ganz richtig erwähnt haben, sind diese Problematiken den Anwendern oftmals nicht bewusst, weshalb es hier sicherlich gewisse Regelungen durch die Software und die Unterscheidung der Prozesse, etwa hinsichtlich eines Gesamtexports/-imports der Datenbank und des Kopierens eines einzelnen Datensatzes, zentral sind.

Soweit meine Betrachtung des Themas unter dem Gesichtspunkt, dass für die Publizierung der Daten im Netz (man denke nur an das Semantic Web) und im speziellen in der DDB/ im Archivportal-D stabile und eindeutige Identifier eine wichtige Grundvoraussetzung sind. Ich bin gespannt auf die weitere Diskussion.
Zitieren
#8
Sehr geehrter Herr Reisacher,

vielen Dank für Ihren Beitrag.

Um die Diskussion kompakt und fokussiert zu halten, möchten wir den Argumentationsstrang noch einmal so wie wir ihn verstanden haben zusammenfassen und gleichzeitig kommentieren:

Der Identifier muss stabil und eindeutig sein
- Diese beiden Anforderungen wurden bereits geäußert und sind also bekannt, sie bilden ja die Grundmotivation für diese Diskussion


Für die Einhaltung beider Anforderungen ist ein Bewusstsein der Anwender sehr wichtig
- Die Aussage ist nachvollziehbar, ist aber kritisch
o Letztlich entscheidend ist ja nicht ein Bewusstsein, sondern ein konkretes Verhalten
o Die Betonung der Wichtigkeit eines bestimmten Verhaltens drückt implizit aus, dass der Anwender Wahlmöglichkeiten hat, sich also sowohl richtig als auch falsch verhalten kann.
o Das Bestehen der Möglichkeit eines Fehlverhaltens beinhaltet auch, dass dieses Fehlverhalten früher oder später auftritt. Beeinflussbar ist hier also nicht das ob, sondern nur das 'wieviel/wie häufig'.
o Die grundsätzliche Einhaltung beider Anforderungen ist somit also dadurch schon per Definition ausgeschlossen.


Ein grundsätzliches Ändern der ID bei einem Import ist aufgrund der Verletzung der Unveränderlichkeit nicht tragbar.
- Ist soweit erstmal richtig

Der offensichtliche Konflikt zwischen beiden Anforderungen soll durch eine Differenzierung nach Anwendungsfällen innerhalb der Archivsoftware gelöst werden.
- Neben der oben erwähnten grundsätzlichen Unzuverlässigkeit einer Regelung, die den Anwendern Verantwortung für die strukturelle Datenintegrität auferlegt, ist es zweifelhaft, ob die Vielzahl möglicher Anwendungsfälle in einer für unsere (äußerst heterogene) Anwenderschaft nachvollziehbaren Form dargestellt bzw. kommuniziert werden kann.


Fehler durch mangelndes Bewusstsein der Anwender für die Problematik soll durch Regelungen innerhalb der Archivsoftware kompensiert werden
- Hier sehe ich einen gewissen logischen Widerspruch. Hat der Anwender Entscheidungsfreiheit, so kann er diese auch (unwillentlich) missbrauchen. Hat er sie nicht, so hat er auch nicht die Möglichkeit, den Konflikt zwischen beiden Anforderungen zu kompensieren.

Grundsätzlich stellen wir folgendes fest:

- Die Problematik zweier sich widersprechenden Anforderungen kann nicht dadurch entschärft werden, dass die Wichtigkeit der Einhaltung beider Anforderungen betont wird. Die Wichtigkeit ist uns bewusst, deshalb diese öffentliche Diskussion.
- Der vorgeschlagene Lösungsansatz ist, in der Archivsoftware fallbedingte Unterscheidungen zu schaffen, die vom Anwender verantwortungsvoll genutzt werden sollen. Dies ist aus folgenden Gründen kritisch:
o Es gibt schon ausgehend von einer Archivierungsphilosphie eine Vielzahl möglicher Anwendungen. Dadurch, dass unsere Anwender verschiedene Archivierungsphilosophien verfolgen, halten wir die Definition allgemeingültig sinnvoller Fallunterscheidungen für sehr schwierig. Zu bedenken ist hier auch, dass der daraus entstehende Workflow überschaubar und verständlich bleiben muss, auch für Anwender, für die die gesamte UUID-Thematik überhaupt nicht von Bedeutung ist.
o Eine Einbeziehung des Anwenders in die Verantwortung zur Einhaltung grundsätzlicher Datenintegrität kann grundsätzlich nicht funktionieren. Neben den im letzten Punkt erwähnten Problemen kann hier immer nur ein mehr oder weniger hoher Grad an richtigen Anwenderentscheidungen erreicht werden. Datenintegrität ist aber nicht durch ein graduelles Erreichen definiert, sondern durch grundsätzliche, eindeutige und zuverlässige Prinzipien.

Insofern kann eine grundsätzliche Vereinbarung beider Anforderungen nicht erreicht werden. Möglich ist selbst im Optimalfall nur ein gewisser Grad prinzipieller Übereinstimmung.
Der Sinn einer UUID soll aber – so wie wir es verstanden haben – sein, jene Sonderfälle abzufangen, in denen die herkömmliche Eindeutigkeitsdefinition durch die Signatur nicht greift. Es ist also durchaus wichtig, dass die UUID IMMER beiden Kriterien genügt, nicht nur manchmal oder in den meisten Fällen (ist die „Trefferquote“ der UUID-basierten Identifikation geringer als die einer Signatur-basierten Identifikation, verliert die UUID ihren Sinn).
Dies ist aber – wie oben ausgeführt – nicht möglich, insofern halten wir das Konzept für praktisch nicht durchführbar, auch wenn der idealistische Grundgedanke auf den ersten Blick sinnvoll erscheinen mag.
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 1 Gast/Gäste