Entity-Relationship-Modell

Mithilfe von Entity-Relationship-Modellen (kurz: ER-Modellen) kann man relationale Datenbanken planen:

Realität -> Anforderungsermittlung -> Entity-Relationship-Modell -> Relationales Datenmodell -> Datenbanksystem

Erklärvideos

• Entity-Relationship-Modellierung

Fachbegriffe

Entität, Entitätsmenge, Attibut, Relation (=Beziehung), 1:1-Beziehung, 1:n-Beziehung, n:m-Beziehung, Kardinalität

Entität, Entitätsmenge und Attribut

Entitätsmenge lehrer mit Attributen

• Entität: ein reales Objekt oder ein realer Vorgang.
  • z.B. die Lehrerin Brigitte Huber.
  • z.B. eine Überweisung von 300€ auf das Abikonto.
• Entitätsmenge: mehrere gleichartige Entitäten werden in einer Entitätsmenge zusammengefasst;
  • Entitätsmengen werden als Rechteck dargestellt.
  • z.B. die Entitätsmenge lehrer, in der alle Lehrer zusammengefasst werden; die Lehrerin Brigitte Huber gehört zur Entitätsmenge lehrer.
  • z.B. Alle Überweisungen werden in die Entitätsmenge ueberweisung zusammengefasst.
• Attribut: Eigenschaft einer Entitätsmenge; jede Entität der Entitätsmenge kann einen eigenen Wert für das Attribut haben.
  • Attribute werden als Ovale dargestellt. Sie werden durch eine Linie mit der Entitätsmenge verbunden, zu der sie gehören.
  • z.B. name ist ein Attribut der Entitätsmenge lehrer. Jeder einzelne Lehrer hat dann einen eigenen Wert für name, z.B. Huber, Zimmermann, ... Die Werte können doppelt vorkommen.
  • z.B. betrag ist ein Attribut der Entitätsmenge ueberweisung.

Entsprechungen zur Datenbank

Entität, Entitätsmenge und Attribut haben folgende Entsprechungen in der Datenbank:

Entity-Relationship-Modell	Datenbank	Darstellung in der Datenbank-Tabelle
Entitätsmenge	Datenbank-Tabelle	ganze Tabelle
Entität	Datensatz in einer Tabelle	eine Zeile der Tabelle
Attribut	Attribut	eine Spaltenüberschrift in der Tabelle
Wert	der Wert eines Attributes in einem Datensatz	eine Zelle in der Tabelle.

Relationen und Kardinalitäten

• Mithilfe von Relationen kann man die Beziehungen zwischen den Entitätsmengen im ER-Modell festhalten.
• Relationen haben einen Namen und werden als Raute dargestellt. Der Name der Relation sollte die inhaltliche Bedeutung der Beziehung widerspiegeln; so ist z.B. hat als Name einer Relation fast immer ungeeignet.
• Jede Relation hat 2 Kardinalitäten; die Kardinalitäten geben an, in welcher zahlenmäßigen Beziehung die zwei Entitätsmengen stehen.

Relationen und Kardinalitäten

Folgende Kardinalitäten sind denkbar:

• 1:1 z.B. trainer trainiert mannschaft:
  • Jeder Trainer trainiert eine Mannschaft.
  • Jede Mannschaft wird von einem Trainer trainiert.
• 1:n z.B. schueler gehoert zu klasse
  • Jeder Schüler gehört zu einer Klasse.
  • Zu jeder Klasse gehören mehrere Schüler.
• n:m z.B. schueler nimmt teil an kurs
  • Jeder Schüler nimmt an mehreren Kursen teil.
  • An jedem Kurs nehmen mehrere Schüler teil.

Begründung der Kardinalitäten

Wie oben gezeigt, werden die Kardinalitäten einer Beziehung durch 2 Sätze begründet.

Diese Sätze sollten jeweils mit Jeder anfangen; damit stellt man sicher, dass man die richtige Kardinalität erhält.

Beispielaufgabe

Die Entity-Relationship-Modellierung wird jetzt an einem Beispiel vorgestellt.

Anforderungsermittlung

Die Firma Schooltech möchte ein Datenbanksystem entwickeln, das es Gymnasien ermöglicht, Schüler, Kurse und Noten in der Oberstufe zu verwalten, u.a. für den Zeugnisdruck. Aus Gesprächen mit mehreren Schulen ergeben sich folgende Anforderungen für die Datenspeicherung:

• Es gibt keine Schulklassen wie in der Unter- und Mittelstufe, sondern nur noch Kurse. In jedem Schulhalbjahr belegt jeder Schüler ca. 10-12 Kurse.
• Am Ende des Halbjahres bekommt jeder Schüler in jedem Kurs eine Note.
• Für jeden Schüler müssen Name, Vorname, Geburtsdatum, Geschlecht und Adresse gespeichert werden.
• Für die Kurse müssen Name, Kürzel und Schulhalbjahr (z.B. 201213/2) gespeichert werden.
• Jeder Kurs wird von einem Lehrer unterrichtet.
• Für Lehrer müssen Name, Vorname und Kürzel gespeichert werden.

Aufgabe

• Zeichnen Sie zu dieser Anforderungsermittlung ein Entity-Relationship-Modell.
• Begründen Sie die Kardinalitäten.

Entity-Relationship-Modell

ER-Modell Kurssystem

Anmerkung zum Attribut note:

• Die Note kann nicht Attribut von schueler sein, denn dann hätte jeder Schüler eine fächerübergreifende Pauschalnote.
• Die Note kann nicht Attribut von kurs sein, denn dann hätten alle Schüler eines Kurses die gleiche Note.
• Die Note gehört zur Relation belegt; damit kann jede Kursbelegung durch einen Schüler mit einer Note versehen werden.

Begründung für die Kardinalitäten

• schueler - kurs: n:m
  • Jeder Schüler nimmt an mehreren Kursen teil.
  • An jedem Kurs nehmen mehrere Schüler teil.
• kurs - lehrer: n:1
  • Jeder Kurs wird von einem Lehrer unterrichtet.
  • Jeder Lehrer unterrichtet mehrere Kurse.

Syntax

Damit man das ER-Modell problemlos in das relationale Datenmodell und in die Datenbank übertragen kann, sollten einige Konventionen zur Schreibweise beachtet werden.

• keine Umlaute, kein ß, keine Sonderzeichen (=dann streikt die Datenbank)
• keine Leerzeichen; stattdessen einen Unterstrich verwenden, z.B.: kurs_hat_teilnehmer
• alles klein schreiben (=erleichtert hinterher die SQL-Abfragen)

Primärschlüssel

Das Zentralabitur NRW verlangt, dass Primärschlüssel schon im Entity-Relationship-Modell eingetragen werden.

Primärschlüssel identifizieren eindeutig einen Datensatz (= eine Zeile) in einer Entitätsmenge.

• Wenn es ein Attribut gibt, das als "natürlicher" Primärschlüssel dienen kann, (z.B. eine Personalnummer), dann wird dieses unterstrichen.
  • In den Entitätsmengen Lehrer und Kurs kann das Attribut kuerzel als Primärschlüssel dienen, denn das Kürzel identifiziert einen Lehrer/ eine Kurs eindeutig.
  • Voraussetzung: Die Datenbank soll nur den momentanen Stand abbilden!
  • Wenn die Datenbank einen langen Zeitraum abbilden soll, dann ist das Kürzel als Primärschlüssel nicht geeignet.
    Denn jedes Jahr gibt es wieder Kurse, die dann genauso heißen können, wie die Kurse des Vorjahres.
    Und wenn ein Lehrer in Rente geht (aber weiterhin gespeichert bleiben soll), dann kann man sein Kürzel (z.B. ST) nicht an einen neuen Lehrer vergeben. Und das wird auf Dauer sehr umständlich.
• Wenn es keinen natürlichen Primärschlüssel gibt, dann ergänzt man ein Attribut "id", das als Primärschlüssel unterstrichen wird.
• id als Primärschlüssel ist in der Regel zuverlässig und bewährt sich auch in der Praxis.

Redundanzen vermeiden!

Redundanzen können zu Inkonsistenzen führen und müssen deswegen im Datenbankschema vermieden werden.
(In der Praxis lässt man Redundanzen an wichtigen Stellen absichtlich zu, um die Performanz der Datenbank zu erhöhen. Aber dafür braucht man sehr gute Gründe.)

Begriffserklärung: Redundanz, Inkonsistenz

• Redundanz:
  Daten sollten möglichst nicht mehrfach gespeichert werden. Ein gutes Schema organisiert Informationen so, dass jedes Faktum nur einmal vorkommt. Das spart Speicher und erleichtert Pflege. Außerdem können Redundanzen immer zu Inkonsistenzen führen.
• Inkonsistenz:
  Wenn redundante Daten vorhanden sind, kann es passieren, dass sie unterschiedlich aktualisiert werden. Je nachdem, wie man die Datenbank abfragt, erhält man dann unterschiedliche Informationen.
  Das ist für die Datenbank viel schlimmer als inkorrekte Daten: Die fallen sofort auf und können einfach korrigiert werden.

Ringbeziehungen untersuchen auf Redundanz

Redundanz: ER-Modell Kurssystem mit Ringbeziehung: Auf Redundanz prüfen!

Wenn das Entity-Relationship-Modell eine Ringbeziehung enthält, dann muss man prüfen, ob Informationen redundant gespeichert sind.
Häufig kann man eine Beziehung weglassen, weil sie sich aus den anderen Beziehungen im Ring ergibt.

Beispiel:

• Im Modell rechts gibt es eine Ringbeziehung.
• Die Ringbeziehung führt zu Redundanz, denn man kann auch über die Entitätsmenge Kurs feststellen, welche Schüler ein Lehrer unterrichtet.
  Das heißt, die Information, welche Schüler ein Lehrer unterrichtet, ist hier doppelt gespeichert.
• Das kann zu Inkonsistenz führen: Lehrer Müller könnte z.B. einen Kurs unterrichten, an dem der Schüler Max Meier teilnimmt. Es kann aber sein, dass in der direkten Beziehung "unterrichtet" für Lehrer Müller und Schüler Meier nichts eingetragen ist.
  Dann ergibt sich das Problem: Was gilt den jetzt?!
  Je nachdem, wie man die Datenbank abfragt, kann man dann unterschiedliche Informationen dazu erhalten, ob Lehrer Müller den Schüler Meier unterrichtet.

Lösung:

• Die Beziehung lehrer-unterrichtet-schueler kann verlustfrei gestrichen werden
  .Denn diese Beziehung ergibt sich aus lehrer-unterrichtet-kurs und schueler-nimmt_teil-kurs.
• Die Beziehung lehrer-unterrichtet-kurs kann nichtverlustfrei gestrichen werden.
  Denn über die Beziehung lehrer-unterrichtet-schueler und schueler-nimmt_teil-kurs kann nicht erschlossen werden, welche Kurse der Lehrer unterrichtet.
  Das liegt daran, dass diese beiden Beziehungen n:m sind.

Was häufig schiefgeht

Relation vs. Attribut

Man muss die Attribute daraufhin überprüfen, ob sie nicht die Beziehung zu einer anderen Entitätsmenge darstellen.

So ist z.B. empfaengerkonto kein Attribut der Entitätsmenge ueberweisung, sondern eine Relation zur Entitätsmenge konto.

Begründungen von Kardinalitäten

Folgende Begründung für die Beziehung kurs-lehrer ist ungeeignet:

Falsch:

• Viele Lehrer unterrichten viele Kurse
• Viele Kurse werden von vielen Lehrern unterrichtet.

Das ließe auf eine n:m-Beziehung schließen - es ist aber keine!

D.h. mit diesen Sätzen, die natürlich inhaltlich richtig sind, lassen sich Kardinalitäten nicht begründen.

Richtig:

• Jeder Lehrer unterrichtet viele Kurse
• Jeder Kurs wird von einem Lehrer unterrichtet.

Und schon erhält man die - korrekte - n:1-Beziehung.

Das Beispiel zeigt, dass die beiden Sätze am besten immer mit Jeder anfangen.