Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03230.jsonl.gz/1853

Es geht wahnsinnig harzig voran – doch immerhin kommen wir vom Fleck. 🙂 Das Problem dabei ist, dass meist die Lösung eines Problems ein neues hervorruft oder andere Unklarheiten schafft. Zudem ergeben sich ungeant verschiedene Lösungsmöglichkeiten eines Problems, bei denen man nicht einfach eine davon Umsetzen kann, sondern alle Analysieren und evtl. auch implementieren sollte.
Hier ein kleines Beispiel: Wie sollte man eine logische 1:1 Relation zwischen zwei Entitätsmengen korrekt physikalsich relational auflösen?
Lösung 1: Man könnte einfach eine Tabelle A und eine Tabelle B erstellen. Tabelle B hätte dann den Primärschlüssel von Tabelle A als Fremdschlüssel. Easy.
Lösung 2: Man könnte dies aber auch gerade umgekehr implementieren. Tabelle A besässe dann den Fremdschlüssel. Dies ist eine Überlegung wert, weil sich daraus Performanceeinbussen vermeiden liessen. Hätte Tabelle B nähmlich tausende von Datensätzen und Tabelle A nur sehr wenige, wäre diese Lösung besser als die Lösung 1. Bei der Lösung 1 gäbe es ja sonst auch extrem viele NULL Werte beim Fremdschlüssel.
Lösung 3: Man könnte hier aber auch eine Zwischentabelle einfügen, wie es bei einer n:m Relation der brauch ist. Wichtig dabei ist, dass die jeweiligen Fremdschlüssel in der Zwischentabelle einzeln mit dem Unique-Index-Constraint versehen würden – ansonsten hätte man ja wirklich eine n:m Relation abgebildet. Mit dieser Lösung würde man definieren, dass eine Tabelle A zur Tabelle B gleichberechtigt ist. Dies wäre die Lösung des sog. Verheiratungsproblem mit den Entitätsmengen Mann und Frau. Hier muss logisch eine Zwischentabelle eingefügt werden, denn würde beim Verheiratungsproblem die Lösung 1 oder 2 implementiert, könnte es vorkommen, dass eine Frau mit mehreren Männern oder ein Mann mit mehreren Frauen verheiratet ist, was laut unserem Gesetzgebuch nicht wirklich erlaubt ist.
Dies sind nun die 3 Lösungen zu physikalisch relationaler Abbildung von einer 1:1 Beziehung. Hätte diese Beziehung nun noch zusätzlich ein Attribut, wäre eine weitere Entscheidung fällig. Kommt das Attribut auf der Beziehung, nun in Tabelle A oder B oder muss hier zwingend eine Zwischentabelle generiert werden.
Eine weitere Frage ist, wie sich dieses logische Modell nun auf physikalisch objektorientiert abbilden lässt… nun geht die Lösungssuche von neuem los. Und auch danach hat man erst die 1:1 Beziehung analysiert… 1:n, 1:m und is-a Beziehungen folgen dann… Und auch danach hat man ja noch keine Definitionen resp. Variantenabklärungen für Notationen, Domains, den Codegeneratoren… Zudem fehlen ja auch so Kleinigkeiten wie Softwarearchitekturen oder Testszenarien…
Hauptsache, mir wird nicht langweilig, denn programmieren sollten wir diese Software nach all unseren Analysen dann auch noch 😀