Home Up PDF Prof. Dr. Ingo Claßen
ER-Modelle 1 - DMDB

Entity-Relationship-Modellierung

  • Starker Bezug zum relationalen Datenmodell
    • Abstraktere Beschreibung von relationalen Strukturen
    • Transformation in das relationale Modell
  • Datenmodellierungstechnik, basierend auf
    • Klassifikation von Objekten
    • Klassifikation von Beziehungen zwischen Objekten
  • Wurde Mitte der 70er Jahre entwickelt
    • Verschiedene Variationen
    • Werkzeugunterstützung

Klassifikation von Objekten


    Datenbankobjekt mit der Bezeichnung "Lehrperson". Das Objekt ist in einem abgerundeten Rechteck dargestellt, welches blau umrandet ist. Innerhalb des Rechtecks befinden sich drei Attribute, die jeweils mit einem Symbol versehen sind: ein rotes Asterisk neben "LPID" und "Name" und ein blaues "O" neben "EMail". Das Asterisk deutet auf ein Schlüsselattribut hin, während das "O" ein optionales Attribut anzeigt.
  • Entitätstypen klassifizieren Objekte
  • Haben Identifikator
  • Beinhalten Attribute, die die Objekte beschreiben
    • Haben Datentypen
    • Können optional oder notwendig sein
  • Haben einen intensionalen und extensionalen Charakter
    • Intensional: Struktur, d.h.die intendierte Form der Informationen
    • Extensional: Menge der Objekte zu einem Zeitpunkt, Datenbankzustand

Entitätstyp und Extension


    Datenbankobjekt mit der Bezeichnung "Lehrperson". Das Objekt ist in einem abgerundeten Rechteck dargestellt, welches blau umrandet ist. Innerhalb des Rechtecks befinden sich drei Attribute, die jeweils mit einem Symbol versehen sind: ein rotes Asterisk neben "LPID" und "Name" und ein blaues "O" neben "EMail". Das Asterisk deutet auf ein Schlüsselattribut hin, während das "O" ein optionales Attribut anzeigt.
  • Entitätstyp
  • Objekttyp


    Die Abbildung zeigt drei elliptische Formen, die jeweils eine Nummer und einen Namen enthalten, wobei die ersten beiden auch eine E-Mail-Adresse beinhalten. Von oben nach unten sind die Inhalte wie folgt: 1. Claßen, ingo.classen@htw-berlin.de 2. Kempa, martin.kempa@htw-berlin.de 3. Burghardt
  • Entität
  • Objekt
  • Instanz

Klassifikation von Beziehungen


Die Abbildung zeigt ein einfaches Entity-Relationship-Diagramm (ER) mit zwei Entitäten, die durch eine Beziehung verbunden sind. Die linke Entität ist mit "Lehrperson" beschriftet und enthält drei Attribute: ein Primärschlüsselattribut "LPID", sowie die Attribute "Name" und "EMail". Die rechte Entität ist mit "Gebäude" beschriftet und enthält zwei Attribute: ein Primärschlüsselattribut "GID" und das Attribut "Bez". Zwischen den beiden Entitäten besteht eine Beziehung, die durch eine gestrichelte Linie dargestellt wird und mit "hat Büro in" beschriftet ist. Diese Beziehung deutet an, dass eine Lehrperson ein Büro in einem Gebäude hat.
  • Beziehungstypen klassifizieren Beziehungen
  • Graphische Darstellung von Kardinalitäten
    • Kardinalität 1: 0..1 oder 1
    • Kardinalität N: 0..* oder 1..*
  • Hinweis: Keine Fremdschlüsselspalte in Lehrperson
  • Wird bei der Übersetzung ins relationale Modell erzeugt

Beziehungstyp und Extension


    Die Abbildung zeigt ein einfaches Entity-Relationship-Diagramm (ER) mit zwei Entitäten, die durch eine Beziehung verbunden sind. Die linke Entität ist mit "Lehrperson" beschriftet und enthält drei Attribute: ein Primärschlüsselattribut "LPID", sowie die Attribute "Name" und "EMail". Die rechte Entität ist mit "Gebäude" beschriftet und enthält zwei Attribute: ein Primärschlüsselattribut "GID" und das Attribut "Bez". Zwischen den beiden Entitäten besteht eine Beziehung, die durch eine gestrichelte Linie dargestellt wird und mit "hat Büro in" beschriftet ist. Diese Beziehung deutet an, dass eine Lehrperson ein Büro in einem Gebäude hat.
  • Beziehungstyp


    Die Abbildung zeigt fünf elliptische Formen, von denen drei jeweils eine Nummer und einen Namen enthalten, und zwei nur eine Nummer und eine Gebäudebezeichnung ("TA A" und "TA C"). Von oben nach unten sind die Inhalte wie folgt: 1. Claßen, ingo.classen@htw-berlin.de 2. Kempa, martin.kempa@htw-berlin.de 3. Burghardt. Claßen und Kempa sind durch eine Beziehung mit dem Element "1, TA A" verbunden, was bedeutet, dass die beiden ein Büro im Gebäude "TA A" haben.
  • Beziehungen
  • Instanzen

Kardinalitäten - Bedeutung


Die Abbildung zeigt ein einfaches Entity-Relationship-Diagramm (ER) mit zwei Entitäten, die durch eine Beziehung verbunden sind. Die linke Entität ist mit "Lehrperson" beschriftet und enthält drei Attribute: ein Primärschlüsselattribut "LPID", sowie die Attribute "Name" und "EMail". Die rechte Entität ist mit "Gebäude" beschriftet und enthält zwei Attribute: ein Primärschlüsselattribut "GID" und das Attribut "Bez". Zwischen den beiden Entitäten besteht eine Beziehung, die durch eine gestrichelte Linie dargestellt wird und mit "hat Büro in" beschriftet ist. Diese Beziehung deutet an, dass eine Lehrperson ein Büro in einem Gebäude hat.

Min-Max-Notation

Entitätstyp Min..Max Beschreibung Bedeutung
Lehrperson 0..* Eine Lehrperson kann minimal mit 0 Gebäuden verbunden sein
Maximal N Lehrpersonen können mit einem Gebäude verbunden sein
Eine Lehrperson muss kein Büro in einem Gebäude haben
Viele Lehrpersonen können ein Büro im selben Gebäude haben
Lehrperson 1..* Eine Lehrperson muss minimal mit 1 Gebäuden verbunden sein
Maximal N Lehrpersonen können mit einem Gebäude verbunden sein
Eine Lehrperson muss ein Büro in einem Gebäude haben
Viele Lehrpersonen können ein Büro im selben Gebäude haben
Gebaeude 0..1 Ein Gebäude kann minimal mit 0 Lehrpersonen verbunden sein
Maximal 1 Gebäude kann mit einer Lehrpersonen verbunden sein
Ein Gebäude muss kein Büro für eine Lehrperson haben
Eine Lehrperson kann nicht Büros in mehreren Gebäuden haben
Gebaeude 1 Ein Gebäude muss minimal mit 1 Lehrpersonen verbunden sein
Maximal 1 Gebäude kann mit einer Lehrpersonen verbunden sein
Ein Gebäude muss ein Büro für mindestens eine Lehrperson haben
Eine Lehrperson kann nicht Büros in mehreren Gebäuden haben

Interaktiv diskutieren - Beispiel-Datei öffnen

Kardinalitäten - Beispiele

one-to-one one-to-many many-to-many
1---1 1---1..* 1..*---1..*
0..1---1 0..1---1..* 0..*---1..*
1---0..1 1---0..* 1..*---0..*
0..1---0..1 0..1---0..* 0..*---0..*

Diskussion Beispiele

  • Produkt / Lieferant
  • Bestellung / Bestellposition
  • Mietvertrag / Schlüssel
  • Kunde / Schliessfach
  • Student/in / Modul
  • Raum / Gebäude
  • Paket / Empfänger
  • Person / Geburtsurkunde
  • Arzt / Krankenhaus
  • Patient / Raum

ER nach Rel: optional many / optional one


    Die Abbildung zeigt ein einfaches Entity-Relationship-Diagramm (ER) mit zwei Entitäten, die durch eine Beziehung verbunden sind. Die linke Entität ist mit "Lehrperson" beschriftet und enthält drei Attribute: ein Primärschlüsselattribut "LPID", sowie die Attribute "Name" und "EMail". Die rechte Entität ist mit "Gebäude" beschriftet und enthält zwei Attribute: ein Primärschlüsselattribut "GID" und das Attribut "Bez". Zwischen den beiden Entitäten besteht eine Beziehung, die durch eine gestrichelte Linie dargestellt wird und mit "hat Büro in" beschriftet ist. Diese Beziehung deutet an, dass eine Lehrperson ein Büro in einem Gebäude hat.

Die Abbildung zeigt ein Relationsmodell mit zwei Entitäten: "Lehrperson" und "Gebaeude". Die Entität "Lehrperson" hat die Attribute "LPID" (Primärschlüssel), "Name", "Email" und den Fremdschlüssel "GID". Die Entität "Gebaeude" hat die Attribute "GID" (Primärschlüssel) und "Bez". Zwischen "Lehrperson" und "Gebäude" herrscht eine 1-zu-n Beziehung, bei der ein Gebäude mehrere Lehrpersonen haben kann, aber eine Person muss kein Gebäude haben.
CREATE TABLE Lehrperson (
  LPID INTEGER NOT NULL,
  Name VARCHAR(100) NOT NULL,
  EMail VARCHAR(100),
  GID INTEGER,
  PRIMARY KEY (LPID)
);
CREATE TABLE Gebaeude (
  GID INTEGER NOT NULL,
  Bez VARCHAR(50) NOT NULL,
  PRIMARY KEY (GID)
);
ALTER TABLE Lehrperson
  ADD CONSTRAINT fk_hat_buero_in FOREIGN KEY (GID) REFERENCES Gebaeude (GID);

ER nach Rel: many / optional one


    Die Abbildung zeigt ein einfaches Entity-Relationship-Diagramm (ER) mit zwei Entitäten, die durch eine Beziehung verbunden sind. Die linke Entität ist mit "Lehrperson" beschriftet und enthält drei Attribute: ein Primärschlüsselattribut "LPID", sowie die Attribute "Name" und "EMail". Die rechte Entität ist mit "Gebäude" beschriftet und enthält zwei Attribute: ein Primärschlüsselattribut "GID" und das Attribut "Bez". Zwischen den beiden Entitäten besteht eine Beziehung, die durch eine gestrichelte Linie dargestellt wird und mit "hat Büro in" beschriftet ist. Diese Beziehung deutet an, dass eine Lehrperson ein Büro in einem Gebäude hat.

Die Abbildung zeigt ein Relationsmodell mit zwei Entitäten: "Lehrperson" und "Gebaeude". Die Entität "Lehrperson" hat die Attribute "LPID" (Primärschlüssel), "Name", "Email" und den Fremdschlüssel "GID". Die Entität "Gebaeude" hat die Attribute "GID" (Primärschlüssel) und "Bez". Zwischen "Lehrperson" und "Gebäude" herrscht eine 1-zu-n Beziehung, bei der ein Gebäude mehrere Lehrpersonen haben kann, aber eine Person muss kein Gebäude haben.
CREATE TABLE Lehrperson (
  LPID INTEGER NOT NULL,
  Name VARCHAR(100) NOT NULL,
  EMail VARCHAR(100),
  GID INTEGER NOT NULL,
  PRIMARY KEY (LPID)
);
CREATE TABLE Gebaeude (
  GID INTEGER NOT NULL,
  Bez VARCHAR(50) NOT NULL,
  PRIMARY KEY (GID)
);
ALTER TABLE Lehrperson
  ADD CONSTRAINT fk_hat_buero_in FOREIGN KEY (GID) REFERENCES Gebaeude (GID);

ER nach Rel: optional many / optional many


    Die Abbildung zeigt ein einfaches Entity-Relationship-Diagramm (ER) mit zwei Entitäten, die durch eine Beziehung verbunden sind. Die linke Entität ist mit "Lehrperson" beschriftet und enthält drei Attribute: ein Primärschlüsselattribut "LPID", sowie die Attribute "Name" und "EMail". Die rechte Entität ist mit "Gebäude" beschriftet und enthält zwei Attribute: ein Primärschlüsselattribut "GID" und das Attribut "Bez". Zwischen den beiden Entitäten besteht eine Beziehung, die durch eine gestrichelte Linie dargestellt wird und mit "hat Büro in" beschriftet ist. Diese Beziehung deutet an, dass eine Lehrperson ein Büro in einem Gebäude hat.

Die Abbildung zeigt ein Relationsmodell mit zwei Entitäten: "Lehrperson" und "Gebaeude". Die Entität "Lehrperson" hat die Attribute "LPID" (Primärschlüssel), "Name", "Email" und den Fremdschlüssel "GID". Die Entität "Gebaeude" hat die Attribute "GID" (Primärschlüssel) und "Bez". Zwischen "Lehrperson" und "Gebäude" herrscht eine 1-zu-n Beziehung, bei der ein Gebäude mehrere Lehrpersonen haben kann, aber eine Person muss kein Gebäude haben.
CREATE TABLE Lehrperson (
  LPID INTEGER NOT NULL,
  Name VARCHAR(100) NOT NULL,
  EMail VARCHAR(100),
  PRIMARY KEY (LPID)
);
CREATE TABLE Gebaeude (
  GID INTEGER NOT NULL,
  Bez VARCHAR(50) NOT NULL,
  PRIMARY KEY (GID)
);
CREATE TABLE hat_buero_in (
  LPID INTEGER NOT NULL,
  GID INTEGER NOT NULL,
  PRIMARY KEY (LPID, GID)
);
ALTER TABLE hat_buero_in
  ADD CONSTRAINT fk_hat_buero_in_Lehrperson FOREIGN KEY (LPID) REFERENCES Lehrperson (LPID);
ALTER TABLE hat_buero_in
  ADD CONSTRAINT fk_hat_buero_in_Gebaeude FOREIGN KEY (GID) REFERENCES Gebaeude (GID);

Anforderungen ER-Modell Hochschule

  • Diese sind nicht vollständig
  • Sie sind auch nicht präzise
  • Sie dienen lediglich als Grundlage für die VL und Ü

Bereiche der Modellierung

  • Personen
  • Standorte
  • Akademische Struktur
  • Lehre
  • Prüfungen
  • Bibliothek

Personen

  • Unterschiedliche Personengruppen mit unterschiedlichen Aufgaben
  • Studendierende sind Studiengängen zugeordnet, studieren nach einer Studienordnung, nehmen an Lehrveranstaltungen teil, machen Prüfungen
  • Lehrpersonen halten Lehrveranstaltungen, führen Prüfungen durch
  • Lehrpersonen (Rollen): Professoren, akademische Mitarbeiter, Lehrbeauftragte
  • Rollen gelten für bestimmte Zeiträume

Standorte

  • Eine Hochschule umfasst mehrere Standorte
  • Ein Standort umfasst Gebäude
  • Ein Gebäude enthält Räume
  • Räume haben verschiedene Raumarten
  • Räume haben Ausstattungsmerkmale, z.B. Whiteboard, Beamer

Akademische Struktur

  • Eine Hochschule setzt sich aus Fachbereichen zusammen
  • Ein Fachbereich beinhaltet Studiengänge
  • Ein Studiengang hat mehrere Studienordnungen
  • Studienordnungen legen Module und deren Regelsemester fest
  • Module können Pflicht, Wahlpficht und Wahl sein
  • Module haben Bestandteile, z.B. Vorlesung, Übung
  • Bestandteile haben einen zeitlichen Umfang (SWS)

Lehre

  • Studierende belegen Module
  • Module werden semesterweise durchgeführt
  • Module können im Semester mehrfach angeboten werden (Züge, Gruppen)
  • Modulbestandteile finden zu bestimmten Zeiten in festgelegten Räumen statt
  • Z.B. wochenweise in bestimmten Zeitbereichen
  • Oder zweiwöchentlich, oder als Blockveranstaltung
  • Belegungen haben Prioritäten, z.B Studierende mit Kindern
  • Oder Belegung im Regelsemester

Prüfungen

  • Studierende melden sich zu Prüfungen an
  • Prüfungen beziehen sich auf Module
  • Haben einen Status, z.B. angemeldet, abgemeldet, durchgeführt
  • Haben einen Termin
  • Führen zu einer Note

Bibliothek

  • Die Bibliothek hat verschiedene Medien, z.B. Bücher, Zeitschriften, Abschlussarbeiten
  • Medien werden Schlagworte zugeordnet
  • Zu jedem Medium gibt es Exemplare, die an verschiedenen Standorten stehen können
  • Exemplare können zu unterschiedlichen Zeitpunkten beschafft worden sein
  • Es gibt mehrere Nutzerklassen, z.B. Studierende, ProfessorInnen
  • Für die Nutzerklassen gelten unterschiedliche Ausleihefristen
  • Ausleihen können verlängert werden
  • Medien können vorbestellt werden
  • Bei Fristüberschreitung erfolgt eine Mahnung

Beispieloberfläche

Diskussion Semester

  • Ist nicht nur Bezeichnung
  • Hat Attribute
  • Sollte daher Entitätstyp sein

    Entität mit dem Titel "Semester". Die Tabelle enthält sechs Attribute, wobei das erste Attribut mit einem Rautensymbol markiert ist, was auf einen Primärschlüssel hindeutet. Die Attribute sind in folgender Reihenfolge aufgelistet: "SID", "Bez", "Beginn", "Ende", "VLBeginn" und "VLEnde". Jedes Attribut ist als Schlüsselattribut markiert.

Module - erster Ansatz

  • In einem Semester können viele Module angeboten werden
  • Ein Modul kann in vielen Semestern angeboten werden
  • Ein Modul kann von vielen Studierenden belegt werden
  • Studierende können viele Module belegen

Die Abbildung zeigt ein Entity-Relationship-Diagramm mit drei Entitäten: Semester, Modul und StudentIn.Die Entität "Semester" enthält zwei Attribute: ein Primärschlüssel SID und eine Bez. "Semester" besitzt eine n-zu-m Beziehung zu "Modul". Die Entität "Modul" hat ebenfalls zwei Attribute: ein Primärschlüssel MID und eine Bez. "Modul" besitzt eine n-zu-m Beziehung zu "StudentIn". Die Entität "StudentIn" auf der rechten Seite hat zwei Attribute: ein Primärschlüssel SID und einen Namen.

Problem des Ansatzes

  • Nicht erkennbar, wer in welchem Semester welches Modul belegt hat
  • Verbundoperation würde immer Studierende in allen Semestern liefern

Die Grafik zeigt 3 Kreise "Semester" mit verschiedenen Semestern darin, "Modul" mit verschiedenen Modulen darin und "StudentIn" mit verschiedenen StudentInnen darin. Zwischen den Kreisgruppen verlaufen mehrere Verbindungslinien, die eine komplexe und unklare Zuordnung zwischen Semestern, Modulen und Studierenden darstellen. Es gibt keine direkte Zuordnung, die klar erkennen lässt, welcher Studierende welches Modul in welchem Semester belegt hat.

Auflösung des Problems

  • Unterscheidung zwischen Modul und Kurs
  • Kurs ist die konkrete Durchführung eines Moduls
  • Module haben Informationen unabhängig von der Durchführung
  • Differenzierung notwendig, um Redundanzen und Inkosistenzen zu vermeiden

Es sind vier Entitäten "Semester", "Modul", "StudentIn" und "Kurs" dargestellt. Links ist die Entität "Semester" mit den Attributen "SID" und "Bez". In der Mitte befindet sich die Entität "Modul" mit den Attributen "MID" und "Bez". Rechts ist die Entität "StudentIn" mit den Attributen "SID" und "Name". Unterhalb der drei Entitäten ist die Entität "Kurs" zentral positioniert, mit dem Attribut "KID". Die Entität "Kurs" ist mit gestrichelten Linien zu "Modul" als 1-zu-n Beziehung und "StudentIn" als n-zu-m Beziehung verbunden, und mit einer durchgezogenen Linie zu "Semester" als 1-zu-n Beziehung.

Semesterzuordnung von Kursen


Die Grafik zeigt 3 Kreise "Semester" mit verschiedenen Semestern darin, "Modul" mit verschiedenen Modulen darin und "StudentIn" mit verschiedenen StudentInnen darin. Zwischen den Kreisgruppen verlaufen mehrere Verbindungslinien, die eine komplexe und unklare Zuordnung zwischen Semestern, Modulen und Studierenden darstellen. Es gibt keine direkte Zuordnung, die klar erkennen lässt, welcher Studierende welches Modul in welchem Semester belegt hat. Grafik nun erweitert mit dem Kreis "Kurs", der jeden Kurs einem Semester klar zuordnet und das ursprüngliche Problem gelöst hat.

Modul- und Kursbestandteile


Die Abbildung zeigt ein Entity-Relationship-Modell (ERM) für ein universitäres Kursverwaltungssystem. Es besteht aus acht Entitäten, die durch Linien verbunden sind, welche die Beziehungen zwischen ihnen darstellen. Die Entitäten und ihre Attribute sind wie folgt: 
1. StudentIn: SID, Name 
2. Semester: SID, Bez 
3. Raum: RID, RaumNr 
4. Kurs: KID 
5. Modul: MID, Bez, CP, Regelsemester 
6. Lehrperson: LPID, Name 
7. KursBT: KBTID 
8. ModulBT: MBTID, SWS
Die Beziehungen zwischen den Entitäten werden durch Linien dargestellt, wobei die Beziehungsnamen teilweise über den Linien stehen. Die Beziehungen sind: "Belegung" zwischen StudentIn und Kurs, "führt durch" zwischen KursBT und Lehrperson, und "kann lehren" zwischen ModulBT und Lehrperson.
  • Modul PROG1: VL und Ü
  • VL 2 SWS und Ü 2 SWS
  • Regelsemester ist 1
  • Kurs pro Semester
  • Belegt wird der Kurs
  • Hat 2 VL und 2 Ü
  • VL/Ü hat Raum
  • Hat Lehrperson
  • "Kann lehren" für Planung