Identifying und Non-Identifying Relationships

Installation und Anwendung von Datenbankschnittstellen wie SQLite, PostgreSQL, MariaDB/MySQL, der DB-API 2.0 und sonstigen Datenbanksystemen.
Antworten
Benutzeravatar
Sophus
User
Beiträge: 1109
Registriert: Freitag 25. April 2014, 12:46
Wohnort: Osnabrück

Hallo Leute,

zunächst einmal möchte ich anmerken, dass meine Frage keineswegs direkt mit Python und auch nicht direkt mit einem Datenbanksystem zutun hat. Daher möchte ich mich jetzt schon entschuldigen, wenn ich das Forum hier etwas "verfremdet" haben sollte.

Zu meinem Anliegen: ich bin über diese beiden Bezeichnungen der Beziehungen gestolpert. Zuvor habe ich mir darüber keine Gedanken gemacht. Mit SQLAlchemy kann man auch diese beiden Beziehungen definieren. Nun möchte ich wissen, ob meine Faustregeln in Ordnung sind. Im Internet schwirren viele Erklärungsversuche, jedoch befriedigen die mich nicht wirklich.

Kann ich also sagen, dass bei einer n:m-Beziehung auf jeden Fall Identifying Relationships verwenden soll? Denn meine waghalsige Vermutung bzw. Erklärung wäre, da bei einer n:m-Beziehung eine Zuordnungstabelle/Verknüpfungstabelle erstellt wird, und in dieser Tabelle aus den Fremdschlüsseln sozusagen ein Primärschlüssel entstehen. Hier entsteht zusagen eine Abhängigkeit. Denn ohne die beiden (zunächst) Fremdschlüssel kann kein neuer Primärschlüssel in der Zuordnungstabelle erstellt werden.

Während in einer 1:n-Beziehung könnte man getrost mit Non-Identifying Relationships arbeiten. Da beide Tabellen unabhängig voneinander existieren können. Zum Beispiel kann ich einen Film in die Datenbank speichern, ohne den Produzenten, ohne die Schauspieler und sonstige Personen zu "kennen".

Gruß
Sophus
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Du kannst dir über das Thema auch weiterhin keine Gedanken machen. Identifying ist wenn du eine Tabelle hast deren primary key gleichzeitig ein foreign key ist. Eine Zeile X kann in so einer Tabelle nicht auftauchen ohne dass in einer anderen Tabelle eine Zeile existiert auf die X zeigt. Das taucht wie du schon festgestellt hast bei n:m Beziehungen zwangsläufig auf. In allen anderen Situationen hab ich bisher noch nie gesehen dass jemand eine Beziehung Identifying macht.
Benutzeravatar
Sophus
User
Beiträge: 1109
Registriert: Freitag 25. April 2014, 12:46
Wohnort: Osnabrück

@DasIch: Ich bin nur daher verwirrt, weil einige Erklärungsansätze sehr verwirrend erscheinen - oder aber ich bin zu dämlich. In einem hat jemand versucht, diese beiden Beziehungstypen anhand eines Buches zu erklären. Da meinte jemand, ein Buch könne ohne einen Autor nicht existieren. Also wäre es demnach Identifying. Für mich aber war es aber verwirrend. Denn ich kann doch einen Buch abspeichern, ohne erst einmal was vom Autor des Buches zu wissen - vielleicht trage ich das später nach. Da dachte ich zuerst, dass man bestimmte Attribute in einer Relation bestimmte Beziehungstypen zuschreibt. Dies erschien mir dann aber sehr aufwendig. Also fragte ich mich, ob meine Faustregel eher passen würde. Und da einige von euch Anwendungen schreiben, die mit Datenbanken arbeiten, wollte ich mich nur vergewissern.
BlackJack

@Sophus: Ein Buch kann nur ohne Autor existieren wenn *Du* das so definierst. Man kann das halt auch anders definieren. Ein Verlag wird beispielsweise für ein Buch einen Autor haben. Und selbst einem in einer Datensammlung der Autor erst einmal egal ist, kann es Sinn machen, dass das System trotzdem auch schon beim Anlegen einen verlangt wenn das den Code einfacher macht weil man den Sonderfall von noch autorenlosen Büchern dann nicht bedenken muss.
Benutzeravatar
Sophus
User
Beiträge: 1109
Registriert: Freitag 25. April 2014, 12:46
Wohnort: Osnabrück

@BlackJack: Deine Überlegung bzw. deine Definition hat aber einen bitteren Nachgeschmack. Der wird Anwender stets gezwungen die Autoren mit anzugeben. Dieses Problem kann man auch auf Musik und Filne etc. ausweiten. Aber auch ich kenne es, dass ich erst einmal meine Filme oder Bücher abspeichern will, damit ich meinen Bestand im Überblick habe. Später setze ich mich hin und fülle die restlichen Daten aus. Ich frage mich also, ob man den Anwender nicht eher verärgert, wenn man ihm sagt "Entweder sagst du mir den Autor oder ich lege dir das Buch nicht an!"
BlackJack

@Sophus: Das hat überhaupt keinen bitteren Nachgeschmack wenn man den Anwender dazu ”zwingt” die Regeln einzuhalten, die die Anforderungen vorgeben. Wenn Du andere Anforderungen hast, dann kannst Du den Autor in Deiner Anwendung ja gerne optional machen. Aber es gibt halt auch Szenarien wo das nicht geht. Und das Beispiel aus dem Buch geht offensichtlich davon aus, dass ein Autor vorhanden sein muss. Bezogen auf den Verlag entspricht das ja auch den Geschäftsabläufen. Entweder kommen Autor und Buch zusammen, dann kann man auch die Reihenfolge beim eingeben der Daten einhalten, oder der Autor kommt erst (oder ist bereits da) und später kommt ein neues Buch hinzu.
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Du machst dir da zuviele Gedanken um dieses konkrete Beispiel. Beziehungen dieser Art tauchen in der Praxis halt auf und es ist auch öfter ein Requirement irgendwelche Identifying Relationships zu haben. Die kannst du dann tatsächlich auf Datenbankebene auch als solche modellieren oder du kümmerst dich höher im Stack um das Problem. Letzteres ist flexibler aber auch mit mehr Komplexität verbunden und eine Fehlerquelle die Daten beschädigen könnte.

Die meisten Nutzer sind mit Flexibilität ohnehin überfordert. Jede Entscheidung die du einem Nutzer abnimmst, jede Einstellung die du nicht anbietest, sogar Features die du nicht hast, machen deine Anwendung für die allermeisten Nutzer eher besser als schlechter.
Benutzeravatar
Sophus
User
Beiträge: 1109
Registriert: Freitag 25. April 2014, 12:46
Wohnort: Osnabrück

@DasIch: Was meinst du mit "höher im Stack"? Ich habe gerade keine Ahnung was du damit meinst. Die Datenbank bekommt der Anwender sowieso nicht zur Sicht.
Sirius3
User
Beiträge: 17710
Registriert: Sonntag 21. Oktober 2012, 17:20

@Sophus: Stack ist ein Stapel, ganz unten liegt die Datenhaltung, dann kommt die Verarbeitung und oben auf liegt die Darstellung der Daten. Auf Datenhaltungsebene kann man der Datenbank eben vorschreiben, dass bestimmte Felder zwingend sind, dann kann die Verarbeitungsebene gar keine Bücher ohne Autor in die Datenbank schreiben. Oder man prüft beim Verarbeiten der Daten, ob alle Angaben da sind. Oder man programmiert das Eingabeformular schon so, dass ein rotes Rechteck dargestellt wird, wenn der Autor fehlt. Oder nehmen wir besser den Titel als den Autor. Du sagst, man kann kein Buch eingeben ohne dass es einen Titel hat, ein Verlag kommt aber ganz gut damit zurecht, dass der Autor noch keinen Titel angegeben hat.
Benutzeravatar
Sophus
User
Beiträge: 1109
Registriert: Freitag 25. April 2014, 12:46
Wohnort: Osnabrück

@Siriu3: Titel ist in der Tat zwingend. Im View()-Bereich habe ich auch so programmiert, dass man unbedingt den Titel oder dergleichen eingeben muss. Denn wie solle man ein Buch, einen Film, Musik etc speichern, wenn man den Titel noch nicht einmal hat? Auf Autoren, Schauspieler, Regisseure oder Interpreter bzw. Bandname kann man erst einmal verzichten.
BlackJack

@Sophus: Bei vielen GUIs kann man durch klicken auf eine Schaltfläche wo „Speichern“ drauf steht, speichern. Das geht auch ohne den Titel einzugeben wenn die UI das zulässt. =;o)
Benutzeravatar
Sophus
User
Beiträge: 1109
Registriert: Freitag 25. April 2014, 12:46
Wohnort: Osnabrück

@BlackJack: Deswegen baut man ja auch ein paar Mechanismen ein ;-)
BlackJack

@Sophus: Weswegen? Man kann ein Buch doch prima ohne Titel speichern. Deine Frage nach dem wie klang so als wäre das generell unmöglich. Das ist nur nicht möglich wenn das verboten würde, aber grundsätzlich wäre es kein Problem.
Benutzeravatar
Sophus
User
Beiträge: 1109
Registriert: Freitag 25. April 2014, 12:46
Wohnort: Osnabrück

@BlackJack: Ich bin neugierig geworden. Ein Titel eines Buches, Filmes oder gar eines Liedes gilt ja zum Teil auch als Identifizierung. Wenn man also die ISBN eingibt, wird als erstes ja der Titel des Buches ausgespuckt und dann weitere Daten. Machen wir es praktischer. Wie kann man über etwas sprechen, was keinen Namen hat? Wir gehen mal davon aus, dass wir keine Autoren oder Produzenten sind, sondern Ottonormalverbraucher. Wenn ich also mit dir über ein besonderes Buch reden möchte, brauche ich den Titel als Identifizierung, damit wir beide wissen wovon hier die Rede ist. Übertragen auf die Datenbank verstehe ich das ähnlich. Daher bin ich neugierig auf deinen Ansatz.
BlackJack

@Sophus: Das mag alles richtig sein, aber es begründet IMHO noch nicht, dass man die Eingabe des Titels erzwingen muss oder ansonsten das Speichern verbietet. Demgegenüber steht, das der Anwender speichern möchte, zum Beispiel weil der Akku fast alle ist, oder das Telefon klingelt, oder… und das nicht kann, weil ihm die UI das verbietet, obwohl er schon Daten eingetragen hat und die nun gerne Speichern möchte.
Dav1d
User
Beiträge: 1437
Registriert: Donnerstag 30. Juli 2009, 12:03
Kontaktdaten:

Der Autor hat nur ein Buch geschrieben das sehr bekannt ist, oder anders: Das Buch mit dem Jesus. Du kannst für alles ein Szenario konstruieren bei dem dein Ansatz fehlschlägt, weil du nur bestimmte Use-Cases betrachtest und das ist gut so. Du willst ja auch nicht, dass alle Autos rückwärts 150 fahren können, nur weil ein Stuntman das in einem Film braucht.

Wenn das speichern ohne Titel keinen Sinn macht (z.B. ein Programm in dem User anderen Usern Bücher empfehlen können), dann erlaube es nicht, ob du das in der Datenbank selbst verbietest (`nullable=False, primary_key=True`) oder nur in der UI sei dir überlassen.
the more they change the more they stay the same
BlackJack

@Dav1d: Die Anspielung auf Mohammed und den Koran verstehe ich jetzt nicht‽ ;-)
Benutzeravatar
pillmuncher
User
Beiträge: 1482
Registriert: Samstag 21. März 2009, 22:59
Wohnort: Pfaffenwinkel

@BlackJack: Achso, ich dachte, er meint das, wo Jesus Amerikaner wird: https://www.youtube.com/watch?v=OKkLV1zE8M0
In specifications, Murphy's Law supersedes Ohm's.
BlackJack

@pillmuncher: Das hatte ich ausgeschlossen, weil es dort genau wie bei der Bibel, nicht *den* Autor gibt und weil es ebenso aus mehreren Büchern besteht, was Dav1d's Aussage von „Der Autor hat genau ein Buch geschrieben“ widerspricht. Es sei denn man geht nach den Fehlgeleiteten, die Joseph Smith unterstellen, er hätte sich das alles selber ausgedacht. Womöglich noch im Suff oder unter Drogeneinfluss. Was ja nun wirklich jeder rationalen Grundlage entbehrt. :-D
Antworten