2
Richtige ER und Tabellenumsetzung
Was ist hier richtig?
Hallo,
ich bin zur Zeit in Bezug auf ER-Modellierung und dessen Tabellentransformation etwas verwirrt.
Folgendes klassische Problem sei gegeben: Bücherrei.
Kunde leiht Buch aus:
Da natürlich mehrere Kunden das Buch ausleihen können, nur nicht zum selben Zeitpunkt, würde
ich die Attribute "von" und "bis" an die Beziehung "leiht aus" hängen. Die Tabellenumsätzung ist
durch m:n dann äquivalent:
Kunde(....)
LeihtAus(FK_KundenID, FK_BuchID, von, bis)
Buch(....)
Mir wurde nun von einer Lehrkraft gesagt, dass dies nicht geht, weil das im ER-Modell nicht
vorgesehen ist. Deshalb soll ich eine weitere Tabelle machen in der ausschließlich das Datum steht
und dann an die Relation hängen. Selbes gilt fpr die Tabellen. Stimmt das? Wenn ja, wieso?
Kunde(....)
LeihtAus(FK_KundenID, FK_BuchID, FK_von, FK_bis)
Datum(Datum)
Buch(....)
Ich finde leider auch keinerlei Literatur die das mir bestätigt oder wiederlegt. Ich selber arbeite seit
einigen Jahren mit Datenbanken und hatte diesbezüglich niemals probleme. Auch der Nutzen ist mir
vollkommen schleierhaft, da ich so nur noch mehr Tabellen miteinander Verknüpfen muss und dass
Integritätsbedingungen unnötig kompliziert sind.
Bin sehr gespannt auf eure Meinungen. Ich wäre auch sehr dankbar, wenn mir jemand auch noch einen
Literaturverweis o.ä. nennen könnte, der das erläutert.
Hallo,
ich bin zur Zeit in Bezug auf ER-Modellierung und dessen Tabellentransformation etwas verwirrt.
Folgendes klassische Problem sei gegeben: Bücherrei.
Kunde leiht Buch aus:
........................................... -------------
..+------------------+............../................\.............+------------------+
..|......Kunde........|-----------|..leiht aus..|----------|........Buch........|
..+------------------+..............\................/.............+------------------+
........................................... -------------ich die Attribute "von" und "bis" an die Beziehung "leiht aus" hängen. Die Tabellenumsätzung ist
durch m:n dann äquivalent:
Kunde(....)
LeihtAus(FK_KundenID, FK_BuchID, von, bis)
Buch(....)
Mir wurde nun von einer Lehrkraft gesagt, dass dies nicht geht, weil das im ER-Modell nicht
vorgesehen ist. Deshalb soll ich eine weitere Tabelle machen in der ausschließlich das Datum steht
und dann an die Relation hängen. Selbes gilt fpr die Tabellen. Stimmt das? Wenn ja, wieso?
........................................... -------------
..+------------------+............../................\.............+------------------+
..|......Kunde........|-----------|..leiht aus..|----------|........Buch........|
..+------------------+..............\................/.............+------------------+
........................................... -------------
..................................................|
........................................+------------------+
........................................|..... Datum........|
........................................+------------------+LeihtAus(FK_KundenID, FK_BuchID, FK_von, FK_bis)
Datum(Datum)
Buch(....)
Ich finde leider auch keinerlei Literatur die das mir bestätigt oder wiederlegt. Ich selber arbeite seit
einigen Jahren mit Datenbanken und hatte diesbezüglich niemals probleme. Auch der Nutzen ist mir
vollkommen schleierhaft, da ich so nur noch mehr Tabellen miteinander Verknüpfen muss und dass
Integritätsbedingungen unnötig kompliziert sind.
Bin sehr gespannt auf eure Meinungen. Ich wäre auch sehr dankbar, wenn mir jemand auch noch einen
Literaturverweis o.ä. nennen könnte, der das erläutert.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 90795
Url: https://administrator.de/contentid/90795
Ausgedruckt am: 25.11.2024 um 15:11 Uhr
2 Kommentare
Neuester Kommentar
Hallo utopia.
Die Lehrkraft hat Recht.
Was besagte Lehrkraft wohl meint ist das die Tabelle "LeihtAus" weiter in die 5. Normalform gebracht werden kann. Eben den Ausleihzeitraum in eine (oder ganz brutal gesehen in zwei) Tabellen auszulagern.
Dazu müsstest Du dann aber in "LeihtAus" einen (neuen) eindeutigen Schlüssel definieren um in den neuen Tabellen die Relation herzustellen. FK_KundenID, FK_BuchID bilden ja keinen eindeutigen Key mehr!
Du hast Recht.
Rein praktisch gesehen bringt es nichts weiter in die 5NF zu gehen. Es bringt keinerlei Vorteile; ganz im Gegenteil...
Genügen Links zur Materie findest Du z.B. in der Wikipedia unter Normalisierung.
BG, Felix -misterdemeanor-
PS: Biber wird sich sicher noch zu Wort melden und uns das genauer erläutern können *g
Die Lehrkraft hat Recht.
Was besagte Lehrkraft wohl meint ist das die Tabelle "LeihtAus" weiter in die 5. Normalform gebracht werden kann. Eben den Ausleihzeitraum in eine (oder ganz brutal gesehen in zwei) Tabellen auszulagern.
Dazu müsstest Du dann aber in "LeihtAus" einen (neuen) eindeutigen Schlüssel definieren um in den neuen Tabellen die Relation herzustellen. FK_KundenID, FK_BuchID bilden ja keinen eindeutigen Key mehr!
Du hast Recht.
Rein praktisch gesehen bringt es nichts weiter in die 5NF zu gehen. Es bringt keinerlei Vorteile; ganz im Gegenteil...
Genügen Links zur Materie findest Du z.B. in der Wikipedia unter Normalisierung.
BG, Felix -misterdemeanor-
PS: Biber wird sich sicher noch zu Wort melden und uns das genauer erläutern können *g
Moin utopia,
Felix hat auch Recht.
Bei der ER-Modellierung arbeitest du normalerweise mit einem Logischen Modell und einem Physischen Modell.
Im Physischen Modell und erst recht in der Realität hast Du m:n-Beziehungen.
Zum Teil weil es das Werkzeug (die Datenbankmöglichkeiten) nicht hergeben, zum Teil aber auch weil ja nun ein Modell immer nur ein vereinfachtes Abbild der Wirklichkeit sein kann.
Im physischen Modell wirst Du in der Tat auf eine Tabelle mehr verzichten und eine m:n-Beziehung (die keine DB-Engine effizient durch Constraints und Relationen absichern kann) eben unabgesichert lassen.
Muss dann halt Durch organisatorische Massnahmen/Plausi-Prüfungen der GUI oder den Programmfluss gehandelt werden.
Im Logischen Modell dagegen hast Du KEINE m:n-Beziehungen, sondern nur saubere Relationen zwischen allen Entitäten.
Also hast Du dort eine so genannte Intersection-Tabelle, auf/von deren eindeutigen PK jeweils n:1 /1:m - Relationen gehen.
Diese "logische Tabelle" und auch alle deren Relationen werden natürlich nicht mit angelegt.
"Intersection-Tabelle" sollte auch ein Stichwort sein, unter dem Suchmaschinen etwas wissen.
Grüße
Biber
P.S. Obwohl: das Beispiel oben würde auch in 90% aller handwerklich umgesetzten Datenbanken eine physisch vorhandene Tabelle mit Ein/Aus-Datum, Kunde, Buch, und Aktion beinhalten.
Felix hat auch Recht.
Bei der ER-Modellierung arbeitest du normalerweise mit einem Logischen Modell und einem Physischen Modell.
Im Physischen Modell und erst recht in der Realität hast Du m:n-Beziehungen.
Zum Teil weil es das Werkzeug (die Datenbankmöglichkeiten) nicht hergeben, zum Teil aber auch weil ja nun ein Modell immer nur ein vereinfachtes Abbild der Wirklichkeit sein kann.
Im physischen Modell wirst Du in der Tat auf eine Tabelle mehr verzichten und eine m:n-Beziehung (die keine DB-Engine effizient durch Constraints und Relationen absichern kann) eben unabgesichert lassen.
Muss dann halt Durch organisatorische Massnahmen/Plausi-Prüfungen der GUI oder den Programmfluss gehandelt werden.
Im Logischen Modell dagegen hast Du KEINE m:n-Beziehungen, sondern nur saubere Relationen zwischen allen Entitäten.
Also hast Du dort eine so genannte Intersection-Tabelle, auf/von deren eindeutigen PK jeweils n:1 /1:m - Relationen gehen.
Diese "logische Tabelle" und auch alle deren Relationen werden natürlich nicht mit angelegt.
"Intersection-Tabelle" sollte auch ein Stichwort sein, unter dem Suchmaschinen etwas wissen.
Grüße
Biber
P.S. Obwohl: das Beispiel oben würde auch in 90% aller handwerklich umgesetzten Datenbanken eine physisch vorhandene Tabelle mit Ein/Aus-Datum, Kunde, Buch, und Aktion beinhalten.
