Schwache Entität und N zu M...

[DBNewb]

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!

 

[akretschmer]

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.

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

 

[DBNewb]

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

 

[akretschmer]

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

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.

 

[DBNewb]

Wie bilde ich dann die schwache Entität ab?

 

[akretschmer]

Wie bilde ich dann die schwache Entität ab?

Ich kann mit diesem Begriff nix anfangen, sorry.

 

[DBNewb]

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

 

[ukulele]

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.

 

[DBNewb]

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

 

[akretschmer]

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.

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

 

[DBNewb]

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....

 

[ukulele]

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.

 

[DBNewb]

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

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

 

[ukulele]

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.