Information ausblenden
Willkommen im Forum für alle Datenbanken! Registriere Dich kostenlos und diskutiere über DBs wie Mysql, MariaDB, Oracle, Sql-Server, Postgres, Access uvm

Schwache Entität und N zu M...

Dieses Thema im Forum "Datenmodellierung, Datenbank-Design" wurde erstellt von DBNewb, 23 August 2013.

  1. DBNewb

    DBNewb Benutzer

    Hallo zusammen,
    ich bin hier ganz neu und hoffe mal, dass ich das hier richtig poste!:)

    Ich habe mir für eine Uniarbeit eine Datenbank modelliert und das ER-Modell auch schon in ein relationales Modell übertragen und eine MS-SQL Datenbank daraus erstellt.

    Als ich anfing Datensätze einzutragen, fiel mir auf, dass ich schon im ER-Modell Redundanzen habe...

    Das Problem ist Folgendes:

    Menschen---N---haben===M===Gefühle

    Die Relation "Menschen" hat den Primärschlüssel MenschID.
    Die Relation "Gefühle" hat zunächst den Primärschlüssel GefühlID. Sie ist jedoch eine schwache Entität, da ein Gefühl nicht ohne Menschen existieren kann. Daher erhält es den zusammengesetzten Primärschlüssel aus beiden Relationen, also MenschID,GefühlID.

    Die Relation "haben" kann ich nicht auflösen, da es eine N-M-Beziehung ist und daher bestehen bleiben muss. Sie hat jedoch den gleichen Primärschlüssel, wie die Relation Menschen MenschID,GefühlID.


    Erfasse ich nun ein Gefühl, lässt sich ja schon über den zusammengesetzten Primärschlüssel von "Gefühl" erkennen, welcher Mensch dieses Gefühl hegt. Dadurch wird die Relation "hat" meiner Meinung nach total sinnfrei und ich provoziere durch Redundanzen Anomalien. Irgendwelche Ideen?;) (Vielleicht hinkt mein "Mensch, Gefühl"-Beispiel etwas, aber ich habe versucht mein komplexeres Modell zu abstrahieren:))




    Vielen Dank im Voraus!
     
  2. akretschmer

    akretschmer Datenbank-Guru

    Ich denke mal, das ist der Fehler. Lasse dort den Menschen raus, welcher Mensch welches Gefühl hat machst Du in einer dritten Tabelle.
     
  3. DBNewb

    DBNewb Benutzer

    Welcher Mensch welches Gefühl hat soll ja die Tabelle "haben" sein, aber dass die MenschID in der Gefühle Tabelle ist, ist erforderlich, weil es eine schwache Entität ist... Habe ich zumindest in der Uni so gelernt;)
     
  4. akretschmer

    akretschmer Datenbank-Guru

    Das ist doch wie Mensch und Automarke. Du machst wieder Tabelle Mensch, eine für Automarken (Opel, Fiat, ...) und eine, die beschreibt, wer welche Marke fährt.
     
  5. DBNewb

    DBNewb Benutzer

    Wie bilde ich dann die schwache Entität ab?
     
  6. akretschmer

    akretschmer Datenbank-Guru

    Ich kann mit diesem Begriff nix anfangen, sorry.
     
  7. DBNewb

    DBNewb Benutzer

    Das ist um darzustellen, dass ein Gefühl nicht ohne Mensch bestehen kann.

    Es kann kein Gefühl entstehen, ohne dass ein Mensch existiert, der dieses Gefühl entwickelt --> Ein Kind kann nicht ohne Vater/Mutter entstehen
     
  8. ukulele

    ukulele Datenbank-Guru

    Den Begriff Schwache Entität habe ich auch noch nie gehört, die Erklärung leuchtet ein. Auf Wiki steht auch das in Notationen und Diagrammen darauf eingegangen wird, dennoch den PK des Menschen in den PK des Gefühls einzubeziehen halte ich für blödsinnig. Natürlich kann man den ersten Menschen einbeziehen, der das Gefühl hatte, aber wozu brauchst du diese Information denn eigentlich? Wenn sie wirklich gewollt ist, kann man das so machen aber es entstünde nicht zwingend eine Redundanz.

    zu deiner hat-Tabelle: was ist wenn der Mensch das Gefühl mehrmals hat, also sagen wir jeden Montag zwischen 7 und 12 Kater, dann könntest du auf die Idee kommen mehrere Einträge in der Tabelle zu machen insofern ist aus praktischer Sicht auch hier ein "neutraler" künstlicher PK durchaus sinnvoll.
     
  9. DBNewb

    DBNewb Benutzer

    Hier in dem Beispiel ist es nicht gerade sinnig ja.

    Irgendwie treffe ich immer nur auf große Augen, wenn ich jemanden nach einer "schwachen Entität" frage.:)

    Die Begründung warum ich das mache ist, dass ich in meiner Datenbank 3 Objekte (A,B,C) habe, die voneinander abhängen..

    B kann erst entstehen wenn es A gibt, C erst, wenn es B gibt.

    In der Regel ist das bei mir kein Problem gewesen, aber da konnte ich auch immer die Zwischenrelationen auflösen, weil es keine N:M-Beziehungen waren
     
  10. akretschmer

    akretschmer Datenbank-Guru

    Code:
    test=# create table a (id int primary key);
    NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "a_pkey" for table "a"
    CREATE TABLE
    test=*# create table b(id int primary key, a_id int references a);
    NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "b_pkey" for table "b"
    CREATE TABLE
    test=*# create table c(id int primary key, b_id int references b);
    NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "c_pkey" for table "c"
    CREATE TABLE
    
     
  11. DBNewb

    DBNewb Benutzer

    Genau, das ist die Abbildung einer schwachen Entität!:)

    nur da diese Tabellen in N zu M Beziehungen stehen, brauche ich noch die Tabellen dazwischen, also wie oben 3 Tabellen.

    Da fängt es dann für mich an sinnlos zu werden, da ja in der Tabelle B schon die Infos von A als Schlüssel übergeben werden.

    Warum dann noch eine Tabelle, wo der Primärschlüssel von A und B drin ist....
     
  12. ukulele

    ukulele Datenbank-Guru

    Du kannst in der Tabelle Gefühle auch einen "normalen" PK verwenden und zusätzlich einen Fremdschlüssel erstellen der von Mensch abhängig ist. Sozusagen Patient 0 für das jeweilge Gefühl. Die FK Spalte machst du dann NOT NULL und schon kann kein Gefühl ohne Patient 0 eingetragen werden. Der einzige Unterschied zu einem zusammengesetzen PK wäre das der FK veränderbar ist.
     
  13. DBNewb

    DBNewb Benutzer



    Ich bin leider an die Uni-Restriktionen gebunden und muss das ER-Modell nach einem bestimmten Schema umwandeln.

    Habe da irgendwie den Sonderfall eines Sonderfalls konstruiert...

    Aber die Diskussion hat mich auf eine Idee gebracht, wie ich mein ER-Modell abändern kann, sodass die N:M-Beziehung zu einer 1:N-Beziehung wird. Dadurch kann ich dann die Tabellen wie oben abbilden.

    Vielen Dank für Eure Hilfe!:)

    Kann geschlossen werden;)
     
  14. ukulele

    ukulele Datenbank-Guru

    Eigentlich spricht auch nichts gegen deinen ursprünglichen Weg von einem zusammengesetzen PK, nur weil das selbe Schlüsselpaar in 2 Tabellen vorkommen kann heißt das ja nicht das es redundant ist. Jeder PK aus Gefühle wäre dann auch irgendwo in "hat" zu finden, nicht aber umgekehrt.
     
Die Seite wird geladen...

Diese Seite empfehlen

  1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden