Das in der Lehrveranstaltung bearbeitete ER(Entity Relationship)-Diagramm ist ein Modell, welches mit Hilfe eines fiktiven Buchhandels den Aufbau einer relationalen Datenbank und die dafür benötigten Daten beschreibt.




In diesem Modell gibt es verschiedene Elemente die gegenseitig in Beziehung stehen. Zunächst benötigt man einmal Entitäten, die hier mit Hilfe von Rechtecken dargestellt sind. Die verwendeten Entitäten im Modell des Buchhandels sind Kunde, Auftrag, Buch und Verlag.

Jeder dieser vier Entitäten sind Attribute zugeordnet, die in einem Oval dargestellt werden. Die Attribute dienen dazu, die jeweiligen Entitäten besser zu beschreiben. Bei der Entität Kunde sind dies Dinge wie Vorname, Nachname, die Adresse und die Kundennummer. Würde man genauere Information des Kunden benötigen könnte man weitere Attribute hinzufügen. Ich denke in diesem Zusammenhang an Dinge wie das Geschlecht oder vielleicht das Geburtsdatum. Das Ganze würde ich für eine sehr sinnvolle Erweiterung halten. Solche Informationen könnten verwendet werden, wenn man mit einem Buch zum Beispiel eine gewisse Generation ansprechen möchte. Wäre die Entität Kunde um diese Attribute erweitert, könnte man beispielsweise auch alle Kundinnen herausfiltern, wenn man nur diese braucht. Weitere Attribute könnten auch Dinge wie Handy- oder Festnetznummer sein, um den Kunden auch telefonisch kontaktieren zu könne. Dies sind nur einige Beispiele die ich in diesem Zusammenhang nennen möchte, natürlich könnte man jede Entität x-beliebig erweitern. Eine Frage die sich hier stellt ist, wie gern die Kunden solche, teilweise eher persönliche Daten hergeben.

Die einzelnen zuvor beschriebenen Entitäten sind mit Hilfe von so genannten Beziehungen miteinander verbunden, welche als Rauten dargestellt werden. Unterschieden werden im Modell des Buchhandels die „erteilt“, „über“ bzw. die „verlegt“ Beziehung. Die 1:n Beziehung „verlegt“ zwischen den Entitäten Verlag und Buch sagt beispielsweise aus, dass jedem Verlag (1) beliebig viele Bücher (n) zugeordnet sein können. Umgekehrt ist dies logischerweise nicht möglich, denn wie sollte es funktionieren wenn jedes Buch verschiedenen Verlagen zugeordnet werden könnte. Es würde zu Problemen führen, denn für gewöhnlich kommt es nicht vor, dass zwei verschiedene Verlage ein und dasselbe Buch verlegen. Dasselbe ist es bei der Beziehung „erteilt“ zwischen den Entitäten Kunde und Auftrag. Es kann jeder Auftrag auch immer nur einem Kunden zugewiesen sein während es umgekehrt natürlich möglich ist, dass ein und derselbe Klient mehrer Aufträge tätigt.

Zwischen den Entitäten Auftrag und Buch herrscht überhaupt eine n:m Beziehung, welche bedeutet, dass sowohl mehrere Bücher in einem Auftrag enthalten sein können als auch umgekehrt mehrere Aufträge einem Buch zugeordnet sein können.


Um die Beziehungen zu prüfen habe ich im vorliegenden Fall auf SQL.IDV.EDU folgenden Befehl eingegeben:

Select a.Nr,count(b.titel)
from Auftrag a, Buch b, Auftragspos au where a.Nr=au.Auftragsnummer and au.Buchnummer=b.Nr
group by a.Nr

Das Ergebnis zeigt, dass beispielsweise dem Auftrag Nr. 1 nicht nur ein Titel sondern wie der n:m Beziehung entsprechend mehrere, genauer gesagt im betreffenden Fall 14 verschiedene Titel zugeordnet sind.

Um die angesprochene Beziehung auch umgekehrt zu prüfen verwendete ich folgende Abfrage

Select b.Nr,count(a.Nr)as "Anzahl der Aufträge"
from Auftrag a, Buch b, Auftragspos au
where a.Nr=au.Auftragsnummer
and au.Buchnummer=b.Nr group by b.Nr

Diese zeigt deutlich, dass auch jeder Buchnummer mehrere Aufträge zugeordnet sein können. Bei der Buchnummer 5 sind es beispielsweise 6 zugeordnete Aufträge. Die n:m Beziehung zwischen den Entitäten Auftrag und Buch hat also funktioniert.