ERD Frage

E

e9lii

Neuer Benutzer
Beiträge
3
Guten Tag

Falls ich meine Frage im falschen Forum poste entschuldigt bitte meine Unachtsamkeit.

Ich habe ein Problem. Ich habe die Tabelle "room" welche einen Raum darstellt, z.B. "Schlafzimmer Erdgeschoss". Nun habe ich eine zweite Tabelle "job" welche die zu erledigenden Punkte darstellt wie z.B. "Müll lehren", "Boden wischen" oder "Bettwäsche wechseln". In der Tabelle "job" habe ich als FK die ID des room. Nun meine Frage, ein room kann mehrere jobs beeinhalten, jobs aber auch mehrere rooms. Wie stelle ich dies dar, ohne die 3. Normalform zu verletzen?

Mit freundlichen Grüssen
Christian
 
Werbung:
AW: ERD Frage

Hallo e9lii,

mit einer Zuordnungstabelle.

Das würde dann so aussehen:

Tabelle 1 Room (RoomID PK)
Tabelle 2 Job (JobID PK)
Tabelle 3 Room_Job(RoomID FK, JobID FK)

RoomID und JobID aus Tabelle Room_Job verweisen auf die entsprechenden Splaten in den beiden anderen Tabellen

Um zu verhindern das es doppelte Einträge in der Tabelle Room_Job gibt erzeugt man einfach einen PK aus beiden FK-Spalten.

Gruß Charly
 
AW: ERD Frage

Hallo Charly

Danke für die schnelle Antwort. Dies würde dann so aussehen wie auf dem Bild unten oder?

erd.png


Grüsse,
Christian
 
AW: ERD Frage

Hallo e9lii,

So wie es jetzt ist kann man z.B. folgende 2 Insert-Anweisungen ohnen eine Fehler zu bekommen auf die jobPerRoom Tabelle anwenden

Code: 
insert into jobperroom (roomid, jobid)values (1,1)
insert into jobperroom (roomid, jobid)values (1,1)

Damit hat man dann einen doppelten Datensatz in der Zuordnungstabelle.

Du musst aus FK1(roomid) und FK2(jobid) einen Primärschlüssel machen.
Das ist dann ein Primärschlüssel der 2 Spalten enthält. Die JobPerRoomId wird nicht benötigt.

Wenn mann dann versucht das zweite insert auszuführen bekommt mann einen Fehler.

Gruß Charly
 
AW: ERD Frage

Hallo Christian,

ja das richtig. durch den PK in der Zuordnungstabelle kann es jetzt keine doppelten Beziehungen zwischen einem Datensatz in der room- und der job-Tabelle geben.

Nur um Missverständnisse zu vermeiden:

Das gilt für das relationale Datenmodell (Das was man in die Datenbank schreibt). In einem ER-Model (z.B. nach Chen, Backer oder Codd) gibt es N:M-Beziehungen zwischen 2 'Tabellen'. Diese Modelle haben allerdings eine andere Syntax um 'Beziehungen' darzustellen und müssen, wenn man mit dem Modell fertig ist, erst in das relationale Datenmodell übersetzt werden.

Gruß Charly
 
AW: ERD Frage

Charly schrieb:
Nur um Missverständnisse zu vermeiden:

Das gilt für das relationale Datenmodell (Das was man in die Datenbank schreibt). In einem ER-Model (z.B. nach Chen, Backer oder Codd) gibt es N:M-Beziehungen zwischen 2 'Tabellen'. Diese Modelle haben allerdings eine andere Syntax um 'Beziehungen' darzustellen und müssen, wenn man mit dem Modell fertig ist, erst in das relationale Datenmodell übersetzt werden.

Gruß Charly
Zum Vergrößern anklicken....

Hallo

Kleine Präzisierung : Das gilt für das relationale Datenmodell : Du meinst das logische und physische Modell, nehme ich an ?


Gruss
 
AW: ERD Frage

Hallo,

@db.wizard:

Richtig angenommen.

Logisches Modell = ER-Modell

Pysisches Modell = Relationales Datenmodell

@Christian:

Habe ich doch richtig verstanden? Du hast hier das physische Modell. Du bist ja schon am normalisieren und sowas macht man im logischen Modell noch nicht.

Gruß Charly
 
Werbung:
AW: ERD Frage

Hallo db.wizard,

du hast natürlich recht.

Ist schon lange her das ich in die Bücher geschaut habe.

und jetzt um alle unstimmigkeiten aus dem Weg zu schaffen:

Das Phasenmodell:

1. Wirklichkeit
2. Anforderungsanalyse
3. konzeptionelles Datenmodell = Entity-Relationship-Modell
4. logisches Datenmodell = Relationenmodell
5. physisches Modell = SQL-Implementierung

Gru? Charly
 
Zurück
Oben