ER-Modell m:n Beziehung?

[nfa1]

 

 

 

Ich befasse mich zurzeit mit Datenbanken, ER-Modellen usw.

Wie findet ihr das Beispiel hier für das m:n-Modell? Habt ihr Verbesserungsvorschläge?

 

Beispiel

Klasse und Lehrer: Eine Klasse kann mehrere Lehrer haben, und ein Lehrer kann mehrere Klassen unterrichten.

___

Jedes Objekt der ersten Entität mit beliebig vielen Objekten der zweiten Entität in Beziehung stehen kann.

Jedes Objekt der zweiten Entität kann mit beliebig vielen Objekten der ersten Entität in Beziehung stehen.

___

Darstellung

Entität „Klasse“ (Rechteck) mit einem „m“ (jede Klasse kann mehrere Lehrer haben)

Beziehung „unterrichtet“ oder „gehört zu“ (Raute) zwischen „Klasse“ und „Lehrer“

Entität „Lehrer“ (Rechteck) mit einem „m“ (jeder Lehrer kann mehrere Klassen unterrichten)

Zwei Rechtecke: Eins für „Klasse“ und eins für „Lehrer“.

Eine Linie verbindet sie mit einer Raute (z.B. „unterrichtet“).

Beide Entitäten haben das „m“, weil es sich um eine viele-zu-viele-Beziehung handelt.

 

 

[Schliepi]

Passt soweit, wenn es um das ER-Modell geht.

[FISI-Prüfer]

Würd ich auch so machen. Im Hinterkopf das Wissen, dass m-zu-n-Beziehungen in eine Hilfstabelle und damit 1-n|n-1 aufgelöst wird...

Viele Grüße 

[Crapz]

vor 4 Stunden schrieb FISI-Prüfer:

Würd ich auch so machen. Im Hinterkopf das Wissen, dass m-zu-n-Beziehungen in eine Hilfstabelle und damit 1-n|n-1 aufgelöst wird...

Viele Grüße 

Hey, 

das macht man erst dann, wenn man m-n Relation in einer relationalen Datenbank umsetzen will. Kann man zB in NoSQL Datenbanken, wie MongoDB aber auch anders machen. 

Beste Grüße 

[Whiz-zarD]

vor 8 Stunden schrieb Crapz:

Hey, 

das macht man erst dann, wenn man m-n Relation in einer relationalen Datenbank umsetzen will. Kann man zB in NoSQL Datenbanken, wie MongoDB aber auch anders machen. 

Beste Grüße 

In einer dokumentenbasierten Datenbank, wie MongoDB, würde man aber nicht unbedingt mit einem ER-Modell arbeiten wollen.

Im Allgemeinen halte ich ER-Modelle nicht wirklich für praktikabel. Ich finde, sie wirken so aus der Zeit gefallen, da durch modernere Software-Architekturen Datenbanken zu einem Implementierungsdetail werden und eine untergeordnete Rolle spielen. Meiner Meinung, wäre es erstmal viel wichtiger ein Datenmodell zu entwickeln, mit dem ich auch meine Business Logik abbilden kann. Ich verdiene nämlich mit der Business Logik Geld und nicht wie die Daten in einer relationalen Datenbank gespeichert werden.

Oftmals werden ja objektorientierte Sprachen verwendet und diese Sprachen passen dann mit der Welt einer relationalen Datenbank oft nicht zusammen und dann braucht man wieder einen ominösen O/R-Mapper (Object/Relational), wie z.B. Nibernate (Java) oder Entity Framework (C#). Sowas, wie Hilfstabellen für n:m-Beziehungen benötigt man dann in der Objektorientierung nicht.

Eine dokumentenbasierte Datenbank entspräche den Ansatz der Objektorientierung. Dort gäbe es ein Dokument "Klasse" und ein Dokument "Lehrer" und in beiden gäbe es dann eine Liste mit den Referenzen zu den Klassen bzw. Lehrern.

 

[EdwardFangirlXxX]

vor 54 Minuten schrieb Whiz-zarD:

durch modernere Software-Architekturen Datenbanken zu einem Implementierungsdetail werden

Eh warum ist das wichtig. Natürlich ist wie wir die Daten speichern ein Implementationsdetail, aber das spricht sich doch nicht gegen die Modellierung davon aus. Da versteh ich gerad nicht warum du das so sagst.

vor 55 Minuten schrieb Whiz-zarD:

ein Datenmodell zu entwickeln, mit dem ich auch meine Business Logik abbilden kann

Aber: Warum Business Logik im Datenlayer darstellen. Da vermischst du doch Implementation und Logik. Sicher aus Performancegründen wird das manchmal gemacht, aber wenn wir pur an schöne, saubere Softwarearchitektur denken, warum würden wir diese beiden Sachen vermischen wollen. SOLID.

vor 58 Minuten schrieb Whiz-zarD:

Sowas, wie Hilfstabellen für n:m-Beziehungen benötigt man dann in der Objektorientierung nicht

Wir reden ja aber auch nicht darüber wie wirs im Arbeitsspeicher eines beliebigen Programms in kleinen Mengen speichern, da können wir ja sicher eine unoptimiertere Darstellung wählen. Aber wenn wir hunderte TB haben, da wollen wir dann doch ja irgendwie schon eine datensparsame Lösung, die in der Lage ist beliebig zusammengesetzte Daten hoch effizient abzurufen.

Die komplette Idee ist ja, Daten extrem performant, sehr datensparsam und einfach zugreifbar abzuspeichern. Und darin sind die ganzen Datenbanken schon verdammt gut find ich.

vor einer Stunde schrieb Whiz-zarD:

und in beiden gäbe es dann eine Liste mit den Referenzen zu den Klassen bzw. Lehrern

Was dafür sorgt, dass wir nicht einen single point of truth haben, und das kann echt einen beißen. Hatt ich schonmal war nicht toll

[Whiz-zarD]

vor 25 Minuten schrieb EdwardFangirlXxX:

Aber: Warum Business Logik im Datenlayer darstellen. Da vermischst du doch Implementation und Logik. Sicher aus Performancegründen wird das manchmal gemacht, aber wenn wir pur an schöne, saubere Softwarearchitektur denken, warum würden wir diese beiden Sachen vermischen wollen. SOLID.

In moderneren Architekturen, wie z.B. die Hexagonal- oder die Clean Architektur, gibt es kein Datenlayer, wie man es aus der n-Schicht-Architektur kennt und das ist genau der Knackpunkt: In der n-Schicht-Architektur steht die Datenhaltung im Vordergrund. D.h. die Business Logik ist abhängig von der Datenhaltung, da die Datenhaltung vorgibt, wie die Daten aussehen.

UI -> Business -> Data

Bei einer Hexagonal-Architektur steht die Business Logik im Vordergrund. Hier wird der Abhängigkeitsgraph umgedreht: Die Datenhaltung ist Abhängig von der Business Logik bzw. von der Application-Schicht, da die Business Logik nun vorgibt, wie die Daten auszusehen haben.

UI -> Application -> Business
          ^
          |
         Data

 

vor 33 Minuten schrieb EdwardFangirlXxX:

Wir reden ja aber auch nicht darüber wie wirs im Arbeitsspeicher eines beliebigen Programms in kleinen Mengen speichern, da können wir ja sicher eine unoptimiertere Darstellung wählen. Aber wenn wir hunderte TB haben, da wollen wir dann doch ja irgendwie schon eine datensparsame Lösung, die in der Lage ist beliebig zusammengesetzte Daten hoch effizient abzurufen.

Kannst du ja auch. Bei einer Hexagonal-Architektur sogar besser, als bei einer n-Schicht-Architektur, weil man bei der Hexagonal-Architektur von Fall zu Fall entscheiden könnte, welche Art von Datenhaltung, für den jeweiligen Use Case besser wäre. Bei einer n-Schicht-Architektur entscheidet man sich, aufgrund der Komplexität, für eine einzige Art der Datenhaltung.

[EdwardFangirlXxX]

vor 38 Minuten schrieb Whiz-zarD:

Bei einer Hexagonal-Architektur sogar besser, als bei einer n-Schicht-Architektur, weil man bei der Hexagonal-Architektur von Fall zu Fall entscheiden könnte, welche Art von Datenhaltung, für den jeweiligen Use Case besser wäre

I mean das kann ich doch ohne Probleme auch bei der Schichtenarchitektur, sind ja alles nur Interfaces die irgendwo implementiert werden, ich kann ja beliebige Implementationen haben, und diese auch on the fly auswechseln mithilfe meiner DI, ich seh da keine Schwäche drin.

Und es ist ja auch ganz normale Praxis zu Mappen zwischen den verschiedenen DOs mit denen wir gerade arbeiten, das heißt ich kann auch in der Logik ohne Probleme meine Daten so halten und formen wie ich will. Sicher kann eins jetzt detailpicken und sagen bei dem einen Architekturansatz muss ich aber hier einmal weniger mappen und dafür da einmal mehr, aber ich finde nicht, dass in irgendeiner Art und Weise eine Schichtenarchitektur mehr oder weniger mit relationalen Datenbanken verbunden ist als andere Architekturansätze. Sowohl hier als auch bei anderen kann ich wunderbar auch mit dokumentenbasierten DBs arbeiten und wenn ichs unbedingt mag auch diese mixen wie ich gerad will.

Aber zum eigentlichen Thema: Ich finde absolut beide Ansätze sowohl relational als auch dokumentorientiert für absolut rechtfertigbar, sicher manches in manchen Situationen besser als in anderen. Aber ich würd niemals relationale Datenbanken als veraltet bezeichnen oder die entsprechenden ER-Modelle. Für die Situation hier von der Fragesteller:in ist ein relationales Modell absolut angebracht und hat eben auch seine Vorteile, dadurch dass es einfach datensparsamer ist als dein Vorschlag und eben einen single point of truth hat anstatt darauf zu setzen dass die Daten durch Logik konsistent gehalten werden müssen. Und idk tbh warum du bei einer Frage zu Grundlagen des ER-Modells das dann postest die Fragesteller:in ist probably verwirrter als zuvor jetzt halt.

[Parser]

vor 22 Stunden schrieb nfa1:

Beispiel

Klasse und Lehrer: Eine Klasse kann mehrere Lehrer haben, und ein Lehrer kann mehrere Klassen unterrichten.

das Beispiel ist der Klassiker, der in so ziemlich jedem mir bekannten Lehrbuch zu Datenbanken und auch in der Berufsschule diskutiert wird. Insofern passt das.