Is there not a better Standardization possible?

Grüß Gott, @Alan E. Brown

Offensichtlich wurde unsere Diskussion über die 1NF aufgrund höherwertige Gründe abgeschnitten, nicht jedoch von mir. Schade dass ich den Urheber und den Grund nicht erkennen kann.
https://community.familysearch.org/en/discussion/188845/familysearch-and-the-1nf#latest
Das wichtigste mir bekannte Nicht-Relationale Datenbankmodell ist GEDCOM. GEDCOM ist jedoch nach der Definition der NoSQL-Datenbanken keine solche 'Not only SQL'-DB, da es offensichtlich starren Tabellen wie 'fam', 'indi' usw. beschreibt.
Nun hat es etwas gedauert bis ich meinen alten Vortrag zur alten Version 5.5. wieder gefunden habe
https://untin.de/Ahnen04/VSFF/GEDCOM01_Scheibl_o19.pdf
Wenn ich die Empfehlungen von GEDCOM betrachte (die Version 5.5. sollte sich in diesen Punkten nicht wirklich von der aktuellen Version unterscheiden), dann ist dieses Modell nichtrelational, weil zwischen 'family' und 'individual' eine Kreuzbeziehung besteht. Eine relationale Datenbank kann also die Daten nicht direkt einlesen, wenn es gleichzeitig referentielle Integrität für die Zeiger verlangt. Die Verknüpfung kann nicht gleichzeitig hergestellt werden (Seite 37). Auch können sich die Zeiger in den jeweiligen Entitäten widersprechen. Hier entspricht GEDCOM der noSQL Eigenschaft: "Nicht-relationale Datenbanken garantieren Verfügbarkeit, aber keine sofortige Konsistenz." Nun ist aber GEDCOM keine DB sondern ein Datenaustauschformat, so dass die Verfügbarkeit entfällt. Anders verhält es sich natürlich bei Datenbanken, die auf diesem Modell basieren.
GEDCOM erlaubt Wiederholfelder für die Alias-Vor- und Zunamen. Jedes dieser Felder enthält aber nur einen Namen, erfüllt also einen Teil der 1NF. Die Wiederholfelder entsprechen somit den 'multivalued fields', die intern für den Programmierer in RDBMS unsichtbar in einen m:m-Beziehungstyp umgewandelt werden.
Mir geht es aber nicht darum, dass verschiedene Schreibweisen eines Namens mit gleicher Bedeutung abgebildet werden, sondern dass mehrere Namen mit anderer logischer Bedeutung für den Benutzer klar erkennbar sind. So haben für mich Mädchenname (Geburtsname), Ehename, Witwenname(n), Scheidungsname(n), Genannt, Sterbename usw. jeweils eine deutlich unterscheidbare logische Bedeutung für einen Leser. Zwei oder gar drei, vier gleichartige Namen in einem Feld sind für mich aufgrund ihrer Stellung in der Reihenfolge nicht unterscheidbar. So gefällt mir zumindest der Trick von FindAGrave mit der Variation der Schriftart recht gut, während die Varianten ins MouseOver gehören.
Wie schon an anderer Stelle erwähnt, verstoßen nicht nur die Namen sondern vielmehr die Ortsbezeichnungen mit ihren Hausnummern gegen die 1NF. Das Problem kann man einfach und gleichzeitig viel besser lösen.
Also beenden wir die Diskussion nach dem Motte: "Ändere niemals eine funktionierende Datenbank"

===

Apparently, our discussion regarding 1NF was cut short for higher-level reasons—though certainly not by me. It is a pity that I cannot identify the person responsible or the specific reason behind it.

https://community.familysearch.org/en/discussion/188845/familysearch-and-the-1nf#latest

The most significant non-relational database model known to me is GEDCOM. However, according to the definition of NoSQL databases, GEDCOM does not qualify as such a "Not Only SQL" database, as it clearly describes rigid tables such as 'fam', 'indi', etc.
It took me some time to track down my old presentation on the legacy version 5.5 again:

https://untin.de/Ahnen04/VSFF/GEDCOM01_Scheibl_o19.pdf

When examining the recommendations set forth by GEDCOM (version 5.5 should not differ significantly from the current version in these specific respects), it becomes apparent that this model is non-relational because a cross-relationship exists between 'family' and 'individual' entities. Consequently, a relational database cannot directly import this data if it simultaneously requires referential integrity for the pointers. The links cannot be established simultaneously (see page 37). Furthermore, the pointers within the respective entities may contradict one another. In this regard, GEDCOM aligns with a key characteristic of NoSQL: "Non-relational databases guarantee availability, but not immediate consistency." However, since GEDCOM is not a database but rather a data exchange format, the concept of "availability" does not apply. The situation is, of course, different for actual databases built upon this model.
GEDCOM permits repeating fields for alias first names and surnames. Yet, each of these fields contains only a single name; thus, it satisfies one specific aspect of 1NF. These repeating fields therefore correspond to "multivalued fields"—constructs that, within a relational database management system (RDBMS), are internally and transparently converted into a many-to-many (m:m) relationship type, invisible to the programmer. My point, however, is not about displaying various spellings of a single name that share the same meaning, but rather ensuring that multiple names—each with a distinct logical significance—are clearly distinguishable to the user. To me, terms such as maiden name (birth name), married name, widow’s name(s), divorce name(s), Genannt (alias), death name, and so on, each carry a clearly distinct logical meaning for a reader. Having two, or even three or four, names lumped together in a single field makes them indistinguishable to me, simply due to their position within the sequence. In this regard, I quite like FindAGrave’s trick of using variations in font style—at least as a workaround—while I believe the alternative variants themselves belong in a mouseover tooltip.
As I have mentioned elsewhere, it is not merely the names—but rather the place names, specifically those including house numbers—that violate the First Normal Form (1NF). This problem can be solved quite simply, and indeed, much more effectively.
So, let us bring this discussion to a close with the motto: "Never change a working database—don't even think about it."

Herzliche Grüße vom Hans-Jürgen Scheibl