durchaus realistisch, dass ich das korrekt verstanden habe
Ja, die Modellierung und was sie bewirken soll. Mit den Besonderheiten von workbench kann ich Dir nicht weiterhelfen, würde und werde ich nie benutzen, wenn ich nicht beruflich dazu gezwungen werde.
Zusammenfassung:
Workbench kann man nutzen, muss sich aber über nichts wundern, ebenso mySQL selbst.
Die folgende Beschreibung (der Kurs) hat spezifisch mit Workbench nichts zu tun (gut),
dass beide Entitäten unabhängig voneinander sind, eine durchgezogene Linie symbolisiert abhängige Entitäten.
ich halte sie an der Stelle für etwas unglücklich.
Eine Abhängigkeit gibt es bei einem Fremdschlüssel immer, sie manifestiert sich immer in der Foreign Key Clause* des Table Create Scripts und wird durch nur "Not NULL" modifiziert. Darüber Hinaus ist die Abhängigkeit gerichtet bzw. verschiedener Ausprägung. "beide Entitäten unabhängig voneinander .., .. abhängig" gibt das nicht wieder. Eine Hauptentität (Parent) kann gut ohne Child auskommen, umgekehrt eher nicht.
Unabhängige Entitäten würde ich nur so nennen, wenn sie in einem Diagramm gar nicht verbunden sind (auch nicht indirekt).
Disclaimer: Ich bin kein Dozent oder sowas, die Konventionen für offizielle Darstellungen nach Chen, UML, .. müsste ich selbst nachschlagen.
* Sie manifestiert sich natürlich noch viel mehr im Betrieb und das ist genau das, was man mit guter Modellierung erreichen will. Verletzte Abhängigkeiten werden mit Fehlern beim Einfügen, Löschen oder Ändern von Datensätzen quittiert, so soll es sein. Undefinierte Abhängigkeiten, also gleiche Datenstruktur, gleiche Daten, jedoch fehlende Foreign Key Angaben trotz logischem Zusammenhang führen zu Null Konsequenzen bei Missachtung dieser nun mehr nur gedachten Zusammenhänge.
Das ist sehr wesentlich und wird anfangs oft nicht verstanden oder manchmal absichtlich nicht umgesetzt (aus fragwürdigen Gründen). Die Folge sind nahezu unweigerlich:
1. inkonsistente Daten, 2. die fahrlässige Ignoranz eines Superpower Features, das man mit der Datenbankfunktionalität geschenkt bekommt.
3. aufwändige, teure und unzuverlässige Workaround-Programmierung, wenn man auf 1. nicht wirklich verzichten will.