Ist mein ER-Diagramm korrekt ?
- Ersteller kcb
- Erstellt am
Piktogramm
Admiral
- Registriert
- Okt. 2008
- Beiträge
- 8.859
Was du da machst ist die Chen-Notation. Ich mag sie nicht und würde gar behaupten, dass die Chen Notation unüblich ist. Chen ist schlicht unübersichtlich. Versuch es lieber gleich mit ERM nach UML zu machen, bringt mehr Übersicht und der Informationsgehalt ist besser.
Da Schüler verschiedene Zeugnisse bekommen (aller halben Jahre eines), ist eine 1 zu 1 Beziehung da fachlich schlicht falsch.
Da Schüler verschiedene Zeugnisse bekommen (aller halben Jahre eines), ist eine 1 zu 1 Beziehung da fachlich schlicht falsch.
- Registriert
- Mai 2011
- Beiträge
- 15.095
Falls bei den Schüler noch die Wohn-Adresse hinterlegt wird, könnte man noch PLZ und Ort in eine eigene Tabelle auslagern 
Update: Man könnte sogar die ganze Adresse sowie PLZ / Ort auslagern weil es können ja auch mehrere Schüler an 1 Adresse wohnen (Mehrfamilienhaus, Geschwister).
Update: Man könnte sogar die ganze Adresse sowie PLZ / Ort auslagern weil es können ja auch mehrere Schüler an 1 Adresse wohnen (Mehrfamilienhaus, Geschwister).
Zuletzt bearbeitet:
xSeppelx
Lt. Junior Grade
- Registriert
- Sep. 2009
- Beiträge
- 384
Lawnmower schrieb:Falls bei den Schüler noch die Wohn-Adresse hinterlegt wird, könnte man noch PLZ und Ort in eine eigene Tabelle auslagern
Update: Man könnte sogar die ganze Adresse sowie PLZ / Ort auslagern weil es können ja auch mehrere Schüler an 1 Adresse wohnen (Mehrfamilienhaus, Geschwister).
Finde ich persönlich nicht notwendig, hier würden dann mehrere Person eine Adresse zugewiesen bekommen? Hier muss man dann sämtliche Aspekte berücksichtigen, die bei einer Änderung der Entität in Frage kommen. In der Praxis würde ich das nicht sehen, wenn dann eher eine Adressen Historie (wobei man da auch einfach eine Schülerhistorie erstellen kann).
Die Beziehung sollte auf jeden Fall 1:n sein. Als nächstes würde ich dann auch die Primärschlüssel als solche kennzeichnen.
Piktogramm
Admiral
- Registriert
- Okt. 2008
- Beiträge
- 8.859
@Lawnmower
Naja, man kann viel, aber wenn es nicht gefordert ist, sollte man es weglassen
@kcb
Was auch so ne Sache ist, du hast Fach und Note einer Zeugnis_ID zugeordnet. Daher würde für n Fächer die Zeugnis_ID n-mal in der Tabelle stehen. Genauso müsste jedes Fach für jede Zeugnis_ID existieren. Daher hat die Tabelle Zeugnis 2 Spalten mit hoher Redundanz wo die Nutzdaten eigentlich die Spalte Note darstellt. Das ist weit weg von schön.
Naja, man kann viel, aber wenn es nicht gefordert ist, sollte man es weglassen
@kcb
Was auch so ne Sache ist, du hast Fach und Note einer Zeugnis_ID zugeordnet. Daher würde für n Fächer die Zeugnis_ID n-mal in der Tabelle stehen. Genauso müsste jedes Fach für jede Zeugnis_ID existieren. Daher hat die Tabelle Zeugnis 2 Spalten mit hoher Redundanz wo die Nutzdaten eigentlich die Spalte Note darstellt. Das ist weit weg von schön.
Ich habe soeben ein neues ER-Diagramm erzeugt, welches zwar leider immer noch auf Basis der Chen-Notation aufgebaut ist, jedoch m.E. wesentlich vollständiger als als das erste ERD ist.
Es wird sicherlich nicht 100% korrekt sein, ich hoffe jedoch, dass es besser als mein erstes sein wird.
Es wird sicherlich nicht 100% korrekt sein, ich hoffe jedoch, dass es besser als mein erstes sein wird.
Anhänge
Piktogramm
Admiral
- Registriert
- Okt. 2008
- Beiträge
- 8.859
Das ERM sagt: Ein Flugzeug kann mehrere Flüge bedienen und ein Flug kann von mehreren Flugzeugen bedient werden.
Real fliegt je Flug immer nur ein Flugzeug, wäre auch nicht gut für die Unfallstatistik, wenn 2 oder mehr Flieger gleichzeitig versuchen würden ein und den selben Ort einzunehmen um gemeinsam einen Flug zu bestreiten...
PS: Für was beschäftigst du dich eigentlich gerade mit ERM?
PPS: Tip: Wenn du etwas in einem ERM modelliert hast, formuliere die Darstellung revers in Text, also welche Aussage lässt sich ohne Vorwissen aus dem Modell ableiten. In etwa so wie ich das oben gemacht habe. Da es oft schwer ist zu vergessen was man vorher gedacht hat kann man anstatt des echten Vergessens auch einfach versuchen das dargestellte absichtlich misszuverstehen. Wenn die Darstellung so gut ist, dass absichtlich kein Missverständnis auftauchen kann, dann ist das Modell höchst wahrscheinlich von der Aussage her richtig. Ist ein Missverständnis leicht möglich, dann ist die Definition nicht ausreichend. Unzureichende Definition ist in der Informatik zwingend zu vermeiden!
Zusätzlich gilt:
*ERM Diagramme die die Schlüssel (-beziehungen) nicht abbilden sind Kacke. Ohne Schlüsselbeziehungen sehen viel ERM als falsch an.
*Symmetrie ist wichtig und meistens richtig! Die Spalten könntest du wunderbar als Baumansicht unter den Tabellennamen darstellen anstatt so ein unsortierte Wolke. Informatiker lieben leicht zu überschauende Ordnung!
Real fliegt je Flug immer nur ein Flugzeug, wäre auch nicht gut für die Unfallstatistik, wenn 2 oder mehr Flieger gleichzeitig versuchen würden ein und den selben Ort einzunehmen um gemeinsam einen Flug zu bestreiten...
PS: Für was beschäftigst du dich eigentlich gerade mit ERM?
PPS: Tip: Wenn du etwas in einem ERM modelliert hast, formuliere die Darstellung revers in Text, also welche Aussage lässt sich ohne Vorwissen aus dem Modell ableiten. In etwa so wie ich das oben gemacht habe. Da es oft schwer ist zu vergessen was man vorher gedacht hat kann man anstatt des echten Vergessens auch einfach versuchen das dargestellte absichtlich misszuverstehen. Wenn die Darstellung so gut ist, dass absichtlich kein Missverständnis auftauchen kann, dann ist das Modell höchst wahrscheinlich von der Aussage her richtig. Ist ein Missverständnis leicht möglich, dann ist die Definition nicht ausreichend. Unzureichende Definition ist in der Informatik zwingend zu vermeiden!
Zusätzlich gilt:
*ERM Diagramme die die Schlüssel (-beziehungen) nicht abbilden sind Kacke. Ohne Schlüsselbeziehungen sehen viel ERM als falsch an.
*Symmetrie ist wichtig und meistens richtig! Die Spalten könntest du wunderbar als Baumansicht unter den Tabellennamen darstellen anstatt so ein unsortierte Wolke. Informatiker lieben leicht zu überschauende Ordnung!
Zuletzt bearbeitet:
A
abulafia
Gast
Jeder Flug gehört nur zu einem Flugzeug. 1-n
Die ID (PS) schreibt man nicht ins Diagramm.
Die ID (PS) schreibt man nicht ins Diagramm.
A
abulafia
Gast
Genau. Flugzeug ist 1, Flüge ist n
Zuletzt bearbeitet von einem Moderator:
Piktogramm
Admiral
- Registriert
- Okt. 2008
- Beiträge
- 8.859
@abulafia
Wo hast du her, dass IDs bzw. Primärschlüssel nicht ins ERM gehören?
Wo hast du her, dass IDs bzw. Primärschlüssel nicht ins ERM gehören?
A
abulafia
Gast
In dieser Notation gehören die nicht ins Diagramm.
So wäre es richtig:
So wäre es richtig:
Zuletzt bearbeitet von einem Moderator:
Piktogramm
Admiral
- Registriert
- Okt. 2008
- Beiträge
- 8.859
Hast du dazu ne Quelle?
ERM ohne Schlüssel ist sinnlos, Wikipedia (en) gibt eindeutige PS an (https://en.wikipedia.org/wiki/Entity–relationship_model). Also klar, autoIDs kann man weglassen, wenn sie fürs Verständnis nicht gebraucht werden. Sind diese aber in Funktion als Schlüssel für das Verständnis notwendig wäre das sträflich (und autoIDs die man nicht als Schlüssel braucht kann man auch gleich in der Datenbank weglassen).
ERM ohne Schlüssel ist sinnlos, Wikipedia (en) gibt eindeutige PS an (https://en.wikipedia.org/wiki/Entity–relationship_model). Also klar, autoIDs kann man weglassen, wenn sie fürs Verständnis nicht gebraucht werden. Sind diese aber in Funktion als Schlüssel für das Verständnis notwendig wäre das sträflich (und autoIDs die man nicht als Schlüssel braucht kann man auch gleich in der Datenbank weglassen).
A
abulafia
Gast
Ist in dieser Darstellung auf jeden Fall optional. Dass ein PS gebraucht wird, sollte jedem klar sein.
Die Beispiele bei Wikipedia verzichten auch auf PS. Ergibt sich auch daraus, dass eine Festlegung, wie der PS zu kennzeichnen ist, fehlt.
Die Beispiele bei Wikipedia verzichten auch auf PS. Ergibt sich auch daraus, dass eine Festlegung, wie der PS zu kennzeichnen ist, fehlt.
Zuletzt bearbeitet von einem Moderator:
Piktogramm
Admiral
- Registriert
- Okt. 2008
- Beiträge
- 8.859
In allen ERMs ist das Dargestellte mehr oder weniger optional. Alles was für die gewollte Aussage nicht notwendig ist kann weggelassen werden. Da der TE jedoch die fachliche Richtigkeit wünscht würde ich davon abraten, jetzt schon Sachen wegzulassen. Ansonsten:
Das ist ein typisches Antipattern der Softwareentwicklung! In Relationalen Datenbanken sind die Relationen die über verknüpfte Schlüssel abgebildet werden die Basis. Gerade da muss alles kommuniziert und dokumentiert werden. Nur weil es dem Ersteller des ERM logisch erscheint muss Anderen noch lange nicht so erscheinen. Also bitte nicht diese Haltung übernehmen!
https://de.wikipedia.org/wiki/Anti-Pattern
Das ist ein typisches Antipattern der Softwareentwicklung! In Relationalen Datenbanken sind die Relationen die über verknüpfte Schlüssel abgebildet werden die Basis. Gerade da muss alles kommuniziert und dokumentiert werden. Nur weil es dem Ersteller des ERM logisch erscheint muss Anderen noch lange nicht so erscheinen. Also bitte nicht diese Haltung übernehmen!
https://de.wikipedia.org/wiki/Anti-Pattern
A
abulafia
Gast
PS werden in dieser Darstellung nicht dargestellt. Punkt. Weglassen ist richtig. Dafür fehlt, wie gesagt, auch die Konvention.
Wir reden ausschließlich von der Chen-Notation
https://de.wikipedia.org/wiki/Chen-Notation
Wir reden ausschließlich von der Chen-Notation
https://de.wikipedia.org/wiki/Chen-Notation
Zuletzt bearbeitet von einem Moderator:
