Beispiel 2 EER Anregungen

  • So, hier jetzt mal mein Ansatz zu den Spieler-Match-Mannschafts-Beziehungen.
    Meinungen?


    Du meinst du würdest ein Flag in 'spielt' (zwischen Spieler und Match) setzen das angibt ob der Spieler Kap. war oder nicht.
    Wäre eine Lösung. Mir wären es zu viele Redundanzen da sich der Kapitän ja meist nicht so oft ändert. Genauso ist nicht sichergestellt dass es mehrere Kapitäne zu einem Zeitpunkt gibt.
    Falls der Kapitän eine Trikotnummer haben soll und aus der Mannschaft sein soll würde ich das Flag in 'spielt' zwischen Spieler und Mannschaft setzen. Es ist zwar nicht sichergestellt dass es nicht mehrere Kap. gibt aber das will man vl. ja auch garnicht.


    Anbei mal meine Ausarbeitung die ich auch bei der Abgabe heute korrekt war.


    Der Tutor meinte die Fälle Co-Trainer und Trainer, sowie Kapitän solle man nicht so genau nehmen, nachdem ich kurz mit Ihm über die Angabe gesprochen habe.

    Files

    • er-diagramm.pdf

      (166.59 kB, downloaded 280 times, last: )
    • relationen.pdf

      (118.17 kB, downloaded 219 times, last: )
    • create.txt

      (2.98 kB, downloaded 287 times, last: )
    • insert.txt

      (12.39 kB, downloaded 298 times, last: )
    • drop.txt

      (309 Byte, downloaded 206 times, last: )
  • Ja, die Geschichte mit dem Kapitän ist so eine Sache.
    Ist der nominierte Kapitän gemeint, oder der am Feld eingesetzte...man weiß es nicht... ;)


    Aber danke für dein Diagramm, das bestätigt auch meine Modellierung!

  • bei deiner relation "betreut" ... gehört da nicht sid referenziert auf fanclub.sid und nicht auf standort.sid?


    sonst ist ja der fanclub der betreut wird nicht eindeutig identifiziert!?
    oder täusch ich mich jetzt total?

  • habs auch so wie lidl.. mal sehen was morgen bei der abgabe rauskommt. das einzige was ich anders hab ist

    Code
    1. [Person] -> [Trainer]
    2. / \
    3. / \
    4. [ChefT] [CoT]

    und von Chef && Co jeweils 1,1 auf Mannschaft. aber ob das so zu 100% richtig ist ueberleg ich mir noch..wenns ist morgen 10min vor der abgabe:)

  • bei deiner relation "betreut" ... gehört da nicht sid referenziert auf fanclub.sid und nicht auf standort.sid?


    sonst ist ja der fanclub der betreut wird nicht eindeutig identifiziert!?
    oder täusch ich mich jetzt total?


    Richtig :) - hatte zum Glück niemand bemerkt.



    Attachments kann man wohl nich editieren?

  • Hallo,
    Im Diagramm von lidl sind die Nummer der Spieler innerhalb einer Mannschaft nicht eindeutig, oder habe ich da was falsch verstanden? Laut der Angabe sollen wir sicherstellen dass die Nummer in der Mannschaft eindeutig sind oder?


    lg

  • Hallo,
    Im Diagramm von lidl sind die Nummer der Spieler innerhalb einer Mannschaft nicht eindeutig, oder habe ich da was falsch verstanden? Laut der Angabe sollen wir sicherstellen dass die Nummer in der Mannschaft eindeutig sind oder?


    lg


    stimmt im diagramm nicht, aber im create.txt siehst du den Unique Constraint über nummer und mannschaft.


    im EER ist das nicht möglich zu modellieren.



    So, hier jetzt mal mein Ansatz zu den Spieler-Match-Mannschafts-Beziehungen.
    Meinungen?



    hmm wenn du
    spieler.persnr, trikot, mannschaft.bezeichnung als Primary Key definierst kann bspw. ein Spieler mehrfach bei ein und derselben mannschaft spielen.


    persnr trikot bezeichnung
    1 1 mannschaft1
    1 2 mannschaft1


    Du könntest trikot und mannschaft.bezeichnung als Primary Key definieren
    und mannschaft und spieler.persnr als unique definieren


  • Stimmt, danke! Das ist nachvollziehbar.
    Bloß wie kann ich das dann im ER-Diagramm so abbilden? Ich hab echt schon einen Knoten im Hirn... :shinner:

  • Ich geb mich jetzt dieser Annahme auch einfach mal hin, damit das endlich ein Ende hat! :D

    Hier meine Serviervorschläge zu ER-Diagramm und Relationenschema.




    hey was mir auf die schnelle aufgefallen ist... der Fanclub wird nicht mithilfe eines Angestellten oder eines Mitglieds identifiziert, weshalb hier eine übliche Relation (einfach umrandete, mir fallen die Namen der beiden nicht ein) reicht. Die doppelt umrandete Relation müsste zwischen Fanclub und Standort stehen.

    Trikot wird entweder mithilfe von Mannschaft oder Spielder identifiziert - beides ist nicht von Vorteil da dann alle 3 Attribute im Primary Key stehen.
    RS dazu:

    spieler_1 trikot_1 mannschaft_1
    spieler_1 trikot_2 mannschaft_1
    spieler_1 trikot_3 mannschaft_1
    spieler_2 trikot_1 mannschaft_1

    spieler_1 kann somit zig-mal in mannschaft_1 spielen oder spieler_2 mit demselben trikot in mannschaft_1 wie spieler_1. Es ist zwar ein eindeutiger schlüssel der aber mehr könnte. In deinem Fall benötigst du noch 2 unique constraints über (spieler & trikot) und (trikot & mannschaft)
    wenn du z.B nur spieler und mannschaft als Primary Key nimmst benötigst dur nur noch einen unique constraint z.B. über (trikot & mannschaft).

    zwei mal 1,1 von trainer auf mannschaft sagt aus dass er sowohl mind. 1 mal co-trainer und einmal trainer sein muss - wird aber nicht so tragend sein.

    zwischen Fanclub und Standort sind die Kardinaliäten vertauscht. laut dem EER kann ein Fanclub an mehreren Standorten sein aber ein Standort nur einen Fanclub haben.

    mitglied <--> fanclub, ein Mitglied muss nicht Obmann sein, ein Fanclub muss einen haben. Da sind wohl auch die Kardinalitäten vertauscht.

    sry :)

  • hey was mir auf die schnelle aufgefallen ist... der Fanclub wird nicht mithilfe eines Angestellten oder eines Mitglieds identifiziert, weshalb hier eine übliche Relation (einfach umrandete, mir fallen die Namen der beiden nicht ein) reicht. Die doppelt umrandete Relation müsste zwischen Fanclub und Standort stehen.


    Ja...klar! THX!


    Plausibel, das werd ich nochmal durchdenken! :D


    Also...wenn Du die Kardinalitäten in diese Richtung liest, dann wären ja ALLE meine Kardinalitäten falsch. Ich habe in deinem ERD gerade gesehen, daß
    deine Beschriftungen gegengleich zu meinen sind, was ich wiederum nicht für korrekt halte (wenn man sich z.B. die Diagramme im Kemper-Konvolut ansieht).
    Entweder steh ich auf dem Schlauch, oder...

    sry :)


    Wieso? Danke für den Input! :)

  • Quote

    Also...wenn Du die Kardinalitäten in diese Richtung liest, dann wären ja ALLE meine Kardinalitäten falsch. Ich habe in deinem ERD gerade gesehen, daß
    deine Beschriftungen gegengleich zu meinen sind, was ich wiederum nicht für korrekt halte (wenn man sich z.B. die Diagramme im Kemper-Konvolut ansieht).
    Entweder steh ich auf dem Schlauch, oder...



    Hmm, verwende das Buch kaum, aber...

    Du verwendest die Chen-Notation deren Leserichtung genau invers zur min, max ist.

    Dazu ein Aufschlussreicher Thread:
    http://www.informatik-forum.at/showthread.php?t=59320

  • hallo. bin gerade dabei das er-modell zu machen. also ich habe zwei auschnitte bei denen ich mir nicht ganz so klar bin ob dies so richtig ist,
    einmal bei trainer und co trainer und einmal beim obmann;
    ich habe noch keine kardinalitäten eingetragen, da ich dies zum schluss mache;
    was denkt ihr?

  • hallo. bin gerade dabei das er-modell zu machen. also ich habe zwei auschnitte bei denen ich mir nicht ganz so klar bin ob dies so richtig ist,
    einmal bei trainer und co trainer und einmal beim obmann;
    ich habe noch keine kardinalitäten eingetragen, da ich dies zum schluss mache;
    was denkt ihr?



    Ich verstehe nicht ganz warum du Obmann, Tainer und Co-Trainer ableitest. Keiner der 3 hat zusätzliche Attribute zu deren 'Eltern'. Mach die Beziehung doch direkt zwischen den Entities.

    In Fanclub ein Foreignkey der auf Mitglied zeigt
    und in Mannschaft zwei Foreignkeys die beide auf Trainer zeigen (1* Trainer, 1* Co-Trainer)