Konzeptionelle Modellierung [KonzMod] - IT

sales
CAMC
TR75
27
UXQ11
TRQ78
VCR
VIDEO
p
r
o
d
u
c
t
Jun
Mai
Apr
Mar
Feb
Jan
ECQ1
XVG
531 539 652 683 867
Nord
2HmQuartal
HJ1
1HmQuartal
time
Süd
Gesamt
location
Bachelorstudiengang Informatik/IT-Sicherheit
Konzeptionelle Modellierung
[KonzMod]
Autoren:
Richard Lenz
Felix Freiling
Friedrich-Alexander-Universität Erlangen-Nürnberg
Konzeptionelle Modellierung
[KonzMod]
Studienbrief 1: Grundlagen der Modellierung und das ERModell
Autoren:
Richard Lenz
Felix Freiling
2. Auflage
Friedrich-Alexander-Universität Erlangen-Nürnberg
© 2015 Richard Lenz, Felix Freiling
Department Informatik
Martensstr. 3
91058 Erlangen
2. Auflage (3. Dezember 2015)
Didaktische und redaktionelle Bearbeitung:
Philipp Klein
Das Werk einschließlich seiner Teile ist urheberrechtlich geschützt. Jede Verwendung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne
Zustimmung der Verfasser unzulässig und strafbar. Das gilt insbesondere
für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.
Um die Lesbarkeit zu vereinfachen, wird auf die zusätzliche Formulierung
der weiblichen Form bei Personenbezeichnungen verzichtet. Wir weisen deshalb darauf hin, dass die Verwendung der männlichen Form explizit als
geschlechtsunabhängig verstanden werden soll.
Das diesem Bericht zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung, und Forschung unter dem Förderkennzeichen
160H11068 gefördert. Die Verantwortung für den Inhalt dieser Veröffentlichung liegt beim Autor.
Inhaltsverzeichnis
Seite 3
Inhaltsverzeichnis
Einleitung zu den Studienbriefen
I.
Abkürzungen der Randsymbole und Farbkodierungen . . . . . . . . .
II.
Zu den Autoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
III.
Modullehrziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Studienbrief 1 Grundlagen der Modellierung und das ER-Modell
1.1 Lernergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Advance Organizer . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1 Daten und Informationen . . . . . . . . . . . . . . . . .
1.3.2 Wann sind Datenbanksysteme sinnvoll? . . . . . . . . .
1.3.3 Grundlegende Begriffe . . . . . . . . . . . . . . . . . .
1.3.4 Die 3-Schema Architektur . . . . . . . . . . . . . . . . .
1.3.5 Phasen des Datenbankentwurfs . . . . . . . . . . . . .
1.3.6 Typen von Datenbanksystemen . . . . . . . . . . . . . .
1.4 Das Entity-Relationship-Modell . . . . . . . . . . . . . . . . . . .
1.4.1 Grundlagen des ER-Modells . . . . . . . . . . . . . . . .
1.4.2 Die Symbole in ER-Diagrammen . . . . . . . . . . . . .
1.4.3 Entities und ihre Attribute . . . . . . . . . . . . . . . . .
1.4.4 Relationships (Beziehungen) . . . . . . . . . . . . . . .
1.4.5 Schwache Entity-Typen . . . . . . . . . . . . . . . . . .
1.5 Fragestellungen beim Entwurf . . . . . . . . . . . . . . . . . . .
1.5.1 Wozu braucht man schwache Entity-Typen? . . . . . . .
1.5.2 Wozu braucht man ternäre Beziehungstypen? . . . . . .
1.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . .
1.7 Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
5
6
11
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Liste der Lösungen zu den Kontrollaufgaben
Verzeichnisse
I.
Abbildungen . .
II.
Beispiele . . . .
III.
Definitionen . . .
IV.
Exkurse . . . . .
V.
Kontrollaufgaben
VI.
Tabellen . . . . .
VII. Literatur . . . . .
4
11
11
11
12
12
16
18
19
20
21
22
25
29
34
43
44
44
45
49
51
57
61
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
61
61
62
62
62
62
62
Seite 4
Einleitung zu den Studienbriefen
Einleitung zu den Studienbriefen
I. Abkürzungen der Randsymbole und Farbkodierungen
Beispiel
B
Definition
D
Exkurs
E
Kontrollaufgabe
K
Merksatz
M
Übung
Ü
Zu den Autoren
Seite 5
II. Zu den Autoren
Richard Lenz ist Professor am Lehrstuhl für Informatik 6 (Datenmanagement) der
Friedrich-Alexander-Universität Erlangen-Nürnberg.
Felix Freiling ist Inhaber des Lehrstuhls für Informatik 1 (ITSicherheitsinfrastrukturen) der Friedrich-Alexander-Universität ErlangenNürnberg.
Seite 6
Einleitung zu den Studienbriefen
III. Modullehrziele
Wenn Sie gute Informatiksysteme konstruieren wollen, dann müssen Sie modellieren können. Modellierung
bedeutet, dass Sie den für die IT-Anwendung relevanten Teil der Wirklichkeit im Informatiksystem nachbilden.
Das Modell ist dann ein zweckgerichtetes vereinfachtes Abbild der Wirklichkeit. Um dies bewerkstelligen
zu können, müssen Sie fundamentale Kenntnisse über sinnvolle Modellierungsmethoden besitzen. Diese
werden Ihnen im Modul „Konzeptionelle Modellierung“ vermittelt. Gleichzeitig ist dieses Modul ein Einstieg
in den Bereich der Datenbanken.
Neben typischen Modellierungssprachen lernen Sie in diesem Modul zur Definition von Datenstrukturen
in relationalen Datenbanken die allgemein bekannte Datenbanksprache SQL (Structured Query Language). Ein besonderer Vorteil von SQL ist, dass die Sprache weitgehend standardisiert und im Bereich der
marktführenden relationalen Datenbanksysteme unangefochten ist.
Im ersten Studienbrief werden die Grundlagen der Modellierung und das Entity-Relationship-Modell (ERModell) vorgestellt. Sie lernen, wie Sie Objekte und Beziehungen der realen Welt in formale Konstrukte einer
Modellwelt übertragen. In diesem Zusammenhang wird auch auf die Strukturierung der Beschreibungsdaten
(Schema-Architektur) einer Datenbank und die Phasen des Datenbankentwurfs eingegangen. Im zweiten
Studienbrief wird das erweiterte ER-Modell (EER-Modell) vorgestellt. In diesen beiden Studienbriefen erlernen Sie quasi eine neue Sprache, mit der Sie unabhängig von einer konkreten Implementierung formulieren
können, welche Zusammenhänge aus der realen Welt in einer Datenbank abgebildet werden sollen.
Im dritten Studienbrief lernen Sie, wie Sie EER-Modelle in konkrete Datenstrukturen relationaler Datenbanken übertragen. Dazu erhalten Sie Einblicke in die Welt der relationalen Datenmodellierung. Wichtige
Konzepte sind hier die verschiedenen Normalformen, die es erlauben, ein Modell schrittweise zu zerlegen,
um Redundanzen zu vermeiden.
Im vierten Studienbrief lernen Sie (nach einer Einführung in die Relationenalgebra) die Datenbanksprache
SQL kennen. Sie können anschließend in SQL deskriptive Anfragen an die Datenbank formulieren.
Im fünften und letzten Studienbrief lernen Sie die Auszeichnungssprache XML (Extensible Markup Language) kennen, die es Ihnen ermöglicht, zunächst unstrukturierte Textdateien mit zusätzlichen hierarchisch
strukturierten Beschreibungsdaten anzureichern.
Nach dem erfolgreichen Abschluss dieses Moduls werden Sie in der Lage sein, einen Ausschnitt der realen
Welt in einer sinngemäßen Nachbildung in Form eines Modells nach festgelegten Kriterien möglichst „gut“
darzustellen. Sie können syntaktisch korrekte und semantisch sinnvolle Anfragen in der Datenbanksprache
SQL formulieren. Schließlich werden Sie die wesentlichen Konzepte der Daten- und Domänenmodellierung
beherrschen, so dass Sie einfache Beispiele selbst erstellen können.
Die Inhalte dieses Moduls basieren auf der gleichnamigen Vorlesung im Präsenzstudiengang Informatik
(Bachelor) der Friedrich-Alexander-Universität, die in den vergangenen Jahren von Prof. Dr. Richard Lenz
ausgearbeitet und gehalten worden ist [Lenz, 2012]. Diese Vorlesung und somit auch dieses Modul basieren
jedoch stark auf bekannter Standardliteratur im Bereich Datenbanksysteme, hauptsächlich Elmasri and
Navathe [2000], aber auch Hitz et al. [2005], Oestereich [2006], Date [2000] und Kemper and Eickler [2006].
Viel Spaß und viel Erfolg!
Modullehrziele
Seite 7
Modulbeschreibung
Modulbezeichnung:
Konzeptionelle Modellierung
Studiengang:
Bachelor IT-Sicherheit
Verwendbarkeit:
Dieses Modul ist verwendbar für
• Studierende der Informatik
• Studierende der Wirtschaftsinformatik
• Studierende der Mathematik und Informatik
auf Bachelorniveau. Dieses Modul kann nicht als Wahlpflichtmodul gewählt werden, sondern ist ein Pflichtmodul.
Lehrveranstaltungen und
Lehrformen:
Konzeptionelle Modellierung
Modulverantwortliche(r):
Prof. Dr. Richard Lenz
Lehrende:
Prof. Dr. Richard Lenz/Prof. Dr. Felix Freiling
Dauer:
1 Semester
Credits:
5 ECTS
Studien- und Prüfungsleistungen:
Schriftliche Prüfung: 90 min.
Berechnung der Modulnote:
Schriftliche Prüfung
Notwendige Voraussetzungen:
Keine
Empfohlene Voraussetzungen:
Keine
Unterrichts- und Prüfungssprache:
Deutsch
Zuordnung des Moduls zu den
Fachgebieten des Curriculums:
Einordnung ins Fachsemester:
Ab Studiensemester 1
Generelle Zielsetzung des Moduls:
Zur Förderung und Verstärkung der Fachkompetenz
Seite 8
Arbeitsaufwand bzw.
Gesamtworkload:
Einleitung zu den Studienbriefen
Präsenzzeit: 30 h
• Vorlesungsteil: 10 h
• Übungsteil: 5 h
• Praktischer Teil: 10 h
• Prüfungsvorbereitungsveranstaltung: 4 h
• Prüfung: 1 h
Eigenstudium: 120 h
• Durcharbeiten der Studienbriefe: 50 h
• Durcharbeiten des Online-Lernmaterials: 10 h
• Wahrnehmen der Online-Betreuung und Beratung: 10 h
• Ausarbeiten von Aufgaben: 30 h
• Individuelle Prüfungsvorbereitung der Studierenden: 20 h
Lerninhalt und Niveau:
Im Modul konzeptionelle Modellierung wird auf folgende Themengebiete eingegangen:
• Grundlagen der Modellierung
• Entity-Relationship Modell (ER-Modell)
• Metamodellierung und XML
• Datenmodellierung und Domänenmodellierung
Niveau der Lerninhalte liegt gemessen am DQR-Niveau bei 6
(Bachelor)
Angestrebte Lernergebnisse:
Fachkompetenz: Die Studierenden erwerben fundierte Kenntnisse
über die Grundlagen der Modellierung sowie über das EntityRelationship-Modell (ER-Modell). Darüber hinaus erwerben Sie
fundiertes Wissen über die Datenbanksprache SQL sowie die Auszeichnungssprache XML.
Methodenkompetenz: Die Studierenden haben die Fähigkeit zu beurteilen, wann eine Datenbank sinnvoll ist und können zwischen
verschiedenen Typen von Datenbanksystemen unterscheiden.
Sozialkompetenz: Die Konflikt- und Kommunikationsfähigkeit der
Studierenden wird in den gemeinsamen Online-Tutorien und Diskussionsforen geschult.
Selbstkompetenz: Die Studierenden erlangen die Fähigkeit zur Bildung einer Meinung über die selbstentwickelten Datenmodellierungen und die Datenmodellierungen anderer. Darüber hinaus
erlangen sie die Fähigkeit, in herausfordernden Situationen zu
handeln und eine Lösung für komplexe Probleme zu finden.
Modullehrziele
Häufigkeit des Angebots:
Seite 9
Wintersemester
Anerkannte Module:
Anerkannte anderweitige Lernergebnisse / Lernleistungen:
Medienformen:
Literatur:
Studienbriefe in schriftlicher und elektronischer Form, Onlinematerial in Lernplattform, Übungen und Projekte über Lernplattform,
Online-Konferenzen, Chat und Forum, Präsenzveranstaltungen
mit Computer und Beamer.
• Konzeptionelle Modellierung, Richard Lenz, 2012
• Datenbanksysteme: Eine Einführung, Alfons Kemper und
Andre Eickler
• An Introduction to Database Systems, C. J. Date
• Analyse und Design mit UML 2.1, B. Oestereich
• XML und Datenmodellierung, R. Eckstein und S. Eckstein
• XML und Datenbanken, H. Schoening
• XML Tutorial, Refsnes Data
• Extensible Markup Language (XML), Mario Jeckle
• Date Warehouse Systems, Andreas Bauer und Holger Guenzel
• Information Modeling and Relational Database, T. Halpin
und T-Morgan
• Mehrrechner- Datenbanksysteme, E. Rahm
• Lehrbuch der Softwaretechnik, H. Bazert
• Datenbankmodelle, Datenbanksprachen und Datenbankmanagementsysteme, G. Vossen
• Datenbanken – Konzepte und Sprachen, G. Saake, K. Sattler
und A. Heuer
• Duden 01. Die deutsche Rechtschreibung: Das umfassende
Standardwerk auf der Grundlage der aktuellen amtlichen
Regeln, Dudenverlag
• Grundlagen der Informatik, Helmut Herold und Bruno
Lurz und Jürgen Wohlrab
• Relationale Datenbanken, Hermann Sauer
Studienbrief 1 Grundlagen der Modellierung und das ER-Modell
Seite 11
Studienbrief 1 Grundlagen der Modellierung und das
ER-Modell
1.1 Lernergebnisse
Sie können die Grundbegriffe der Modellierung und der Datenbanken definieren
und entscheiden, wann der Einsatz von Datenbanken sinnvoll ist und wann nicht.
Sie können die verschiedenen Phasen des Datenbankentwurfs beschreiben und
verschiedene Typen von Datenbanksystemen unterscheiden.
Sie beherrschen das Vokabular des Entity-Relationship-Modells (Entity, Relationship, Extension, Intension, Attribute, Schlüssel etc.) und können einfache ERDiagramme aufstellen und erläutern.
1.2 Advance Organizer
Sie erhalten zunächst einen allgemeinen Einblick in das Thema „Modellierung“.
Anschließend folgt der Einstieg in eine einfache Modellierungstechnik, das EntityRelationship-Modell. Abschließend werden einige im Kontext der Modellierung
ständig wiederkehrenden Fragen kurz behandelt.
1.3 Einführung
Das Wort „Modell“ stammt aus dem Lateinischen [Dudenredaktion, 2013]. Dort
bezeichnete man mit modulus einen Maßstab, wie man ihn etwa in der Architektur
oder der bildenden Kunst verwendete. Heute bezeichnet man mit dem Begriff
„Modell“ die Nachbildung oder Darstellung eines Gegenstandes. Grundsätzlich
werden in einem Modell wesentliche Eigenschaften eines Gegenstandes hervorgehoben und nebensächliche Aspekte außer Acht gelassen. Ein Modell ist also immer
auch eine Abstraktion des dargestellten Gegenstandes (eines Realitätsausschnittes).
Beispiel 1.1: Modelle in der Architektur
Architekten verwenden häufig Modelle, um die Wirkung eines Gebäudes im
Kontext seiner Umgebung darzustellen. Dazu wird eine nach einem festen
Maßstab verkleinerte Version des (geplanten) Hauses und seiner Umgebung
aus Holz oder Pappe nachgebaut. Dieses Modell ist eine Nachbildung der
Wirklichkeit. Allerdings werden nicht alle Aspekte der Wirklichkeit dargestellt. Unwesentlich für das Modell sind beispielsweise viele Aspekte des
Innenausbaus (Möbel, Wasser- und Stromleitungen etc.). Diese werden bewusst weggelassen. Wichtig sind hingegen die Proportionen des Hauses im
Verhältnis zur Umgebung. Genau diese werden im Modell beibehalten.
Die Abstraktion eines Realitätsausschnitts sollte immer einen Zweck haben, der
durch das Modell erreicht wird. Modellierung ist also immer eine zweckgerichtete
Vereinfachung durch Weglassen von Details.
Modelle spielen in der Informatik eine zentrale Rolle bzw. erfüllen verschiedene
Zwecke. In der Softwareentwicklung dienen Modelle dazu, Software-Systeme
B
Seite 12
Studienbrief 1 Grundlagen der Modellierung und das ER-Modell
zu spezifizieren, konstruieren, visualisieren und zu dokumentieren. Sie bilden
Beschreibungen, an denen sich Entwickler und Anwender orientieren können.
Merksatz 1.1
M
Ein Modell ist ein zweckgerichtetes, vereinfachtes Abbild der Wirklichkeit.
1.3.1 Daten und Informationen
In der datenzentrierten Welt der Modellierung müssen wir zwei wichtige Begriffe
unterscheiden, die umgangssprachlich häufig nicht trennscharf verwendet werden:
Daten und Informationen.
Daten
Unter Daten versteht man in der Informatik einfach nur Folgen von Bits [Herold
et al., 2012]. Eine Bitfolge wie „01000001“ hat an sich keine Bedeutung. Erst wenn
man weiß, wie die Bitfolge zu interpretieren ist, erschließt sich aus ihr (möglicherweise) eine Information.
Interpretationsmöglichkeiten werden häufig durch sogenannte Kodierungen Kodierungen fixiert. Es muss beispielsweise fixiert werden, welche Bitfolge den Buchstaben „A“ repräsentiert. Wenn dies geschehen ist, kann man Daten (also eine Folge
von Bits) Informationen (also einer Interpretation) zuordnen. Wenn man Daten
interpretiert, spricht man ihnen eine Bedeutung zu.
Kontrollaufgabe 1.1: ASCII-Codierung
K
Eine bekannte Kodierung für einzelne (alphanumerische) Zeichen ist der
sogenannte ASCII-Standard. Durch welche Bitfolge wird in diesem Standard
der Großbuchstabe „A“ kodiert?
Daten-und Informationsverarbeitung
Wenn man Daten in andere Daten transformiert, spricht man von (siehe Abb. 1.1 unten). Wenn uns die Daten eigentlich nicht interessieren, sondern die Verarbeitung
der Informationen im Vordergrund steht, spricht man von Informationsverarbeitung (siehe Abb. 1.1 oben). Durch die Kodierung der Information in Daten kann
man so die Informationsverarbeitung auf die Datenverarbeitung zurückführen.
Letztendlich interessieren uns immer die Informationen.
Abb. 1.1: Daten
und Informationen
Information
Repräsentation
Informationsverarbeitung
Information
Interpretation
Daten
Datenverarbeitung
Daten
1.3.2 Wann sind Datenbanksysteme sinnvoll?
relevante Daten sind
Daten, die für unseren
Zweck von Interesse sind
Nicht alle Daten, die weltweit durch Sensoren, Mess- und Aufnahmegeräte, Experimente oder Überwachungen erzeugt werden, müssen zwangsläufig aufgezeichnet
und abgespeichert werden. Bei einer Temperaturaufzeichnung interessieren Sie
1.3 Einführung
Seite 13
sich vielleicht nicht für jedes einzelne Datum, sondern vielleicht nur für die Durchschnittstemperatur des Tages oder die großen Temperaturschwankungen über
mehrere Jahre. Daten, für die wir uns interessieren, nennt man relevant.
Das heute gespeicherte Datenvolumen steigt jedoch stetig. Um alle relevanten
Informationen aufzuheben, benötigt man heute nach grober Schätzung ein Speichervolumen von wenigen tausend Petabytes. Ein Petabyte entspricht dabei 1015
Byte. Dies zu speichern, liegt heute bereits im Bereich des Möglichen. In wenigen
Jahren werden wir jedoch in der Lage sein, alles aufzubewahren und abzuspeichern.
Es ist klar, dass diese unvorstellbaren Datenmengen nur noch von Rechnern aufbewahrt, gesucht und aufbereitet werden. Der Mensch sieht weder die Daten, noch
kennt er den Aufbewahrungsort und die genauen Ableitungsverfahren. Neben der
reinen Speicherkapazität benötigt man aber auch zusätzliche Strukturen, um diese
Daten effizient zu verarbeiten. Genau dies bieten moderne Datenbanken.
Beispiel 1.2: Library of Congress
Ein gutes Beispiel für eine große Datensammlung ist die größte Bibliothek
der Welt: die „Library of Congress“1 . Sie umfasst etwa 128 Millionen Bücher, Karten etc. Täglich erhält die Bibliothek 22.000 neue „Gegenstände“
zur Aufbewahrung, von denen etwa 10.000 der Sammlung hinzugefügt
werden.
Nach aktuellen Schätzungen umfasst die Sammlung etwa
• 30 Millionen Bücher, darunter 124.000 Telefonbücher und 100.000
Comics
• 2,7 Millionen Tonaufnahmen
• 0,9 Millionen Filmaufnahmen
• 12,3 Millionen Fotografien
• 4,8 Millionen Landkarten (die größte Sammlung der Welt)
• 57 Millionen handschriftliche Manuskripte
Umgerechnet in Speicheraufwand sind dies etwa 3 PB:
• Nur Text (ASCII): 29 ∗ 106 ∗ 1 MB = 29 TB
• Tonaufnahmen: 2, 7 ∗ 106 ∗ 600 MB = 1, 6 PB
• Fotos: 12, 3 ∗ 106 ∗ 1 MB = 12, 3 TB
• Landkarten: 4, 8 ∗ 106 ∗ 50 MB = 240 TB
Die großen Datenmengen führen zu ganz praktischen Problemen: Betrachten
wir als Beispiel das Problem der effizienten Suche. Angenommen, wir hätten
eine große Festplatte, auf der alle Daten der Library of Congress gespeichert
wären. Würde man diese Festplatte „von vorne nach hinten“ (also sequentiell)
nach einem gewünschten Buch, Manuskript oder Video durchsuchen, würde man
ziemlich lange suchen müssen. Zur Abschätzung des Zeitaufwandes folgt hier
eine vereinfachte Rechnung.
Nehmen wir an, wir können die Daten mit dem Durchsatz einer normalen Fest1 http://www.loc.gov/
(Aufruf am 25.6.2013)
B
Seite 14
Studienbrief 1 Grundlagen der Modellierung und das ER-Modell
platte durchsuchen (etwa 10 MB/s). Für die Durchsuchung von 3 PB würde man
also im Mittel
3 PB
1
· = 150.000.000 s
10 MB/s 2
benötigen. Dies entspricht etwa 4,76 Jahren. Neben der reinen Speicherkapazität
benötigt man also auch Möglichkeiten, um effizient in den Datenbeständen suchen
und auf diese zugreifen zu können.
Konsistenz
Effizienter Zugriff allein reicht aber auch noch nicht aus. Ein anderes praktisches
Problem besteht nämlich darin, die Daten konsistent zu halten, insbesondere, wenn
mehrere Benutzer gleichzeitig mit den Daten arbeiten (siehe Abb. 1.2).
Mehrbenutzerbetrieb
Stellen Sie sich vor, was passieren würde, wenn täglich tausende Besucher unkontrolliert auf die Sammlung der Library of Congress zugreifen würden. Jeder
Benutzer möchte mit den Daten so umgehen, als wäre er allein. Der Einsatz eines
Datenbanksystems gewährleistet, dass etwa zwei Benutzer nicht den gleichen
Eintrag gleichzeitig verändern können. Im Gegensatz zu Applikationen, die ihre
Daten im Hauptspeicher halten, bleiben die Daten in einem Datenbanksystem
über einen längeren Zeitraum (insbesondere nach Beendigung eines Programms)
verfügbar.
Abb. 1.2: Datenbank
Application 2
Application 3
User A
Application 1
User B
Database
Um Ihnen zu verdeutlichen, wann ein Datenbanksystem Sinn macht, betrachten
wir eine Firma, die verschiedene Abteilungen hat und in der die üblichen Geschäftsprozesse ablaufen (Bestellungen, Personalrekrutierung etc.). Jede Person,
die in der Firma arbeitet, hat einen lokalen Computer, auf dem sie die Daten,
die sie benötigt, selbst verwaltet und auf der eigenen Festplatte (im Dateisystem)
ablegt. Natürlich werden mehrere Personen teilweise mit denselben Daten arbeiten, die sie dann jeweils für sich lokal ablegen. Wenn Daten modifiziert werden,
müssen diese über das Netz hin- und hergeschoben werden. Neben der Verschwendung von Speicherplatz birgt dieses Vorgehen auch die Gefahr, dass die Daten
„auseinanderlaufen“, d.h. ein und dasselbe Datum an unterschiedlichen Stellen
mit unterschiedlichen Werten gespeichert wird. Redundant abgespeicherte Daten
bergen also immer die Gefahr von Inkonsistenz (siehe Abb. 1.3).
isolierte Daten
Diese Art der Datenspeicherung, die in der Praxis durchaus nicht unüblich ist,
führt zu weiteren Problemen, etwa zu so genannten isolierten Daten. Dies sind
Daten, die irgendwo gespeichert sind, von denen aber andere Benutzer nichts
wissen. Es können beispielsweise Abhängigkeiten zwischen verschiedenen Applikationen bestehen, die undokumentiert sind und sich nicht in den abgelegten
Daten äußern. Zudem können Dateien in verschiedenen Formaten gespeichert
werden. Zu allem Überfluss sind die Datenformate dann meist auch nicht dokumentiert, so dass es unterschiedliche Interpretationen der Daten gibt, je nachdem,
wer sie liest. Diese Art der Datenverwaltung in Form von anwendungsspezifischen
bzw. benutzerspezifischen Dateien hat also viele Nachteile.
1.3 Einführung
Seite 15
Abb. 1.3: Benutzerspezifische Datenhaltung
Abhängigkeiten
ApplicationI1
ApplicationI2
ApplicationI3
ApplicationI4
DateiI1
DateiI2
DateiI3
DateiI4
A
Isolierte
Daten
<A>
VerschiedeneIFormate
RedundatenIDaten
Ein Datenbanksystem ermöglicht einen zentralen Speicherort für alle Daten eines
Softwaresystems in einem einheitlichen Format für alle Benutzer. Der zentrale
Speicherort vermeidet Redundanz und dadurch Inkonsistenz (siehe Abb. 1.4).
Wenn sich das Datum an dieser einen Stelle ändert, dann ist es für alle Benutzer
sichtbar, die darauf zugreifen dürfen. Der zentrale Speicherort erleichtert es auch,
Zugriffsbeschränkungen und Zugriffskontrollen durchzuführen. Ebenso ist die
Synchronisation im Mehrbenutzerbetrieb möglich, denn das Datenbanksystem
garantiert die Integrität der Daten, auch wenn Fehler auftreten (z.B. in Benutzerprogrammen oder bei Stromausfall). Wie wir noch sehen werden, ermöglicht ein
Datenbanksystem auch eine abstraktere Sicht auf die dort gespeicherten Daten.
Dies wird durch ein sogenanntes konzeptionelles Datenbankschema erreicht,
das wir später noch erklären werden. Die gemeinsame, abstrakte Sicht sorgt für
Anwendungsunabhängigkeit. Außerdem sorgt sie dafür, dass die Interpretationsmöglichkeiten der Daten durch die Angabe von Kodierungen größtenteils
festgelegt werden. Es gibt also weniger Möglichkeiten, sich über die Bedeutung
von Daten zu streiten.
Application 2
konzeptionelles Datenbankschema
Abb. 1.4: Eine anwendungsunabhängige
Datenbank
Application 3
User A
Application 1
User B
Database
Neben den vielen Vorteilen von Datenbanksystemen gibt es, wie wir noch sehen
werden, auch einige Nachteile bei ihrem Einsatz. So verursacht die erstmalige
Einführung eines Datenbanksystems in einem Softwaresystem hohe Kosten, auch
wenn diese Kosten insgesamt (über die Projektlaufzeit) sinken mögen. Die Software zur Verwaltung von Datenbanksystemen nennt man Datenbankmanagementsysteme. Solche Datenbankmanagementsysteme werden auf den allgemeinen
Anwendungsfall hin optimiert, sind also keine Spezialanwendungen. Dies verursacht in der Regel einen hohen Rechenaufwand und erfordert entsprechende
Rechenleistung. Ein Datenbanksystem macht also keinen Sinn, wenn es sich um
eine kleine Datenbank mit einer komplizierten Struktur handelt, die nur von einer
einzelnen spezialisierten Anwendung gebraucht wird. Ebenso macht es wenig
Seite 16
Studienbrief 1 Grundlagen der Modellierung und das ER-Modell
Sinn, ein Datenbanksystem einzuführen, wenn die Anwendung eine harte Echtzeitanforderung hat. Beispiele für solche Anwendungen sind Steuerungssoftware
zur Kontrolle einer Ampelschaltung oder ein Patientenmonitoringsystem auf einer
Intensivstation. Wenn kein Mehrbenutzerbetrieb benötigt wird, wie beispielsweise
zur Ablage einer privaten CD-Sammlung, dann ist ein Datenbanksystem ebenfalls
kaum erforderlich.
Datenschutz
Nicht zuletzt spielen auch viele Fragen der IT-Sicherheit im Bereich der Datenbanken eine Rolle. So wurden viele Basiskonzepte der IT-Sicherheit, etwa Zugriffsschutz und Informationsflusskontrolle, anfangs im Kontext von Datenbankforschung entwickelt. Heute muss man beim Entwurf und Betrieb von Datenbanksystemen immer auch das Thema Datenschutz beachten. So unterliegt das Sammeln
von Daten beispielsweise einer Zweckbindung (Daten dürfen nur zu einem bestimmten Zweck gesammelt werden) und das Sammeln von Daten muss sparsam
erfolgen (es dürfen nicht mehr Daten gesammelt werden als notwendig ist, um
den verfolgten Zweck zu erreichen) [Kühling et al., 2011].
1.3.3 Grundlegende Begriffe
Datenbank
Eine Datenbank ist eine Sammlung von zusammenhängenden Daten [Elmasri and
Navathe, 2000]. Datenbanken werden in der Regel verwendet, um einen Ausschnitt
der realen Welt zu modellieren. Sie repräsentieren also eine Art „Miniwelt“ [Sauer,
2002].
DBMS
Ein Datenbankmanagementsystem (DBMS) hingegen ist eine Sammlung von Programmen zur Verwaltung einer Datenbank. Durch ein DBMS soll die Erzeugung
einer Datenbank, die Wartung einer Datenbank und der konsistente Zugriff auf
eine Datenbank gewährleistet sein.
Abb. 1.5: Datenbankmanagementsystem
(DBMS)
Benutzer
Datenbankanwendung
Anwendungsprogramm
Datenbanksystem
DBMS
Datenbank
DBS
Ein Datenbanksystem (DBS) schließlich ist die Kombination einer Datenbank
und eines Datenbankmanagementsystems. Dies ist in Abb. 1.5 schematisch dargestellt.
Datenbankanwendung
Zudem gibt es noch den Begriff der Datenbankanwendung. Dies ist die Kombi-
1.3 Einführung
Seite 17
nation einer Datenbank, eines Datenbankmanagementsystems und eines oder
mehrerer Anwendungsprogramme (siehe Abb. 1.5).
Merksatz 1.2
M
Den Zusammenhang zwischen Datenbank (DB), Datenbankmanagementsystem (DBMS) und Datenbanksystem (DBS) drückt man häufig durch
folgende Pseudo-Formel aus:
DBS = DB + DBMS
Um die vielen oben beschriebenen Vorteile zu erreichen, muss eine Datenbank
neben den eigentlichen Nutzdaten auch noch zusätzliche Daten speichern, die die
Nutzdaten „beschreiben“. Dies sind die sogenannten Metadaten.
Nutzdaten
Metadaten („Daten über Daten“) sind Beschreibungsdaten, etwa der Struktur der
Datenbank oder zur Kodierung der Daten. Der Zusammenhang zwischen Nutzdaten, Metadaten und Datenbank wird in Abb. 1.6 nochmals bildlich dargestellt.
Metadaten
Abb. 1.6: Inhalt einer
Datenbank
Datenbank
Metadaten
Nutzdaten
Schließlich müssen wir noch zwei wichtige Begriffe unterscheiden: Datenmodell
(oder auch Datenbankmodell) und Datenbankschema.
a) Das Datenmodell ist eine anwendungsunabhängige Strukturierungsvorschrift für Daten. Es hat also gar nichts mit einer konkreten Anwendung
zu tun. Es bestimmt, wie die Daten einer Datenbank allgemein strukturiert
werden. In diesem Modul betrachten wir ausschließlich das relationale Datenmodell. Das relationale Datenmodell ist die Basis für relationale Datenbanken.
Das relationale Datenmodell ist aber nicht die einzige Strukturierungsvorschrift für Datenbanken. Am Ende des Moduls werden wir durch Verweise
in die Literatur noch einen Ausblick etwa auf das Netzwerkmodell oder das
hierarchische Datenmodell geben.
Datenmodell
b) Ein Datenbankschema ist die Beschreibung einer konkreten Datenbank.
Das Datenbankschema einer relationalen Datenbank enthält beispielsweise Informationen zu den verschiedenen Tabellen der Datenbank und den
Datenformaten, die darin abgelegt sind. Der überwiegende Teil dieses Moduls beschäftigt sich mit der Frage, wie man gute Datenbankschemata im
relationalen Datenmodell entwirft.
Datenbankschema
Kontrollaufgabe 1.2: Grundbegriffe der Datenbanken
Grenzen Sie die Begriffe Datenbank (DB), Datenbankmanagementsystem
(DBMS), Datenbanksystem (DBS) und Datenbankanwendung voneinander
ab.
K
Seite 18
Studienbrief 1 Grundlagen der Modellierung und das ER-Modell
1.3.4 Die 3-Schema Architektur
konzeptionelles Schema
In diesem Modul wird vorwiegend eine bestimmte Art von Datenbankschema
betrachtet, nämlich das konzeptionelle Schema. Entsprechend heißt das Modul
auch „Konzeptionelle Modellierung“. In der Literatur [Rahm, 1994] unterscheidet
man insgesamt drei Arten von Datenbankschemata. Diese werden üblicherweise
auf drei Ebenen aufgeteilt (siehe Abb. 1.7), wobei das konzeptionelle Schema in
der Mitte angesiedelt ist.
externes Schema
Für komplexe Anwendungen kann das Datenbankschema relativ groß werden
und tausende von Tabellen enthalten. Man kann die Datenbank dann durch „Sichten“ auf die Tabellen strukturieren, die bestimmen, welche Anwendung welche
Tabellen sehen kann. Die Informationen über diese Sichten werden auch als Metadaten in der Datenbank gespeichert und gehören auch zum Datenbankschema.
Dieser Teil des Datenbankschemas wird auch als externes Schema bezeichnet
(siehe Abb. 1.7). Durch die explizite Trennung der externen Schemata vom konzeptionellen Schema erreicht man, dass das konzeptionelle Schema unabhängig
von bestimmten Anwendungen formuliert werden kann. Diese Eigenschaft wird
als Anwendungsneutralität bezeichnet.
Abb. 1.7: 3-SchemaArchitektur einer Datenbank
Externe Schemata:
- anwendungsspezifische Sichten
Kern dieser Vorlesung:
Konzeptionelles Schema:
- Datenunabhängigkeit!
- Anwendungsneutralität!
Interne Schemata:
- Zugriffspfade
- Speicherungsstrukturen
internes Schema
Es gibt noch weitere Metadaten einer Datenbank, von denen wir jedoch bei der
Realisierung der Datenbank bewusst abstrahieren. Hierbei handelt es sich um
interne Realisierungsregeln der konkreten Datenbank, beispielsweise interne Speicherstrukturen, die den schnellen Zugriff auf die Daten ermöglichen (Indizes).
Diese Informationen sollte man gegenüber dem Datenbankanwender verstecken,
da man die Speicherstrukturen dann auch nachträglich noch verändern kann, ohne dass es die Funktionalität der Datenbankanwendung verändert (ein ähnliches
Geheimnisprinzip lernen Sie im Modul „Einführung in die Programmierung“
kennen). Diese Speicherstrukturen sind ebenfalls Metadaten, die in der Datenbank
abgelegt werden. Man nennt sie auch internes Schema.
Datenunabhängigkeit
Durch die explizite Trennung der internen Schemata vom konzeptionellen Schema erreicht man also, dass interne Speicherungsstrukturen vor dem Benutzer
verborgen und unabhängig modifiziert werden können. Dies nennt man Datenunabhängigkeit. Der Grad der Unabhängigkeit, der letztlich in einer konkreten
Anwendung erreicht werden kann, hängt dabei vom verwendeten Datenmodell
ab.Da im relationalen Datenmodell alle Daten in Tabellen abgelegt werden und
der Benutzer keinerlei physische Datenstrukturen (wie etwa physische Zeiger,
die auf einen Speicherbereich verweisen) zu sehen bekommt, ist mit relationalen
Datenbanken ein sehr hoher Grad an Datenunabhängigkeit erreichbar.
Wenn wir im Folgenden von Datenbankschema sprechen, meinen wir immer das
konzeptionelle Schema. Das konzeptionelle Schema ist der Kern jedes Datenban-
1.3 Einführung
Seite 19
kentwurfs und beschreibt, welche Daten es gibt und wie sie zusammenhängen,
und zwar unabhängig von der konkreten Umsetzung in einem Datenmodell.
Kontrollaufgabe 1.3: Vorteile mehrschichtiger Architektur
K
Warum ist eine mehrschichtige Architektur für den Entwurf von Datenbanken empfehlenswert?
1.3.5 Phasen des Datenbankentwurfs
Wenn man ein konzeptionelles Datenbankschema entwerfen möchte, stellt sich
die Frage, wie man bei dessen Entwurf am besten vorgeht. Die Problemstellung ist
in Abb. 1.8 dargestellt: Auf der einen Seite existiert die Anwendungsdomäne. Der
relevante Ausschnitt dieser Anwendungsdomäne, der später durch die Datenbank
repräsentiert werden soll, wird „Miniwelt“ genannt. Auf der anderen Seite steht
das relationale Datenmodell, mit dem wir die Domäne modellieren wollen. Ziel
dieses Modellierungsprozesses ist die Beschreibung einer Menge von Tabellen, die
wir relationales Datenbankschema nennen.
Anwendungsdomäne
Miniwelt
Abb. 1.8: Wie komme ich
zum Schema?
?
Tabelle 1
Tabelle 3
So einfach diese Aufgabe erscheint, so schwer gestaltet sie sich in der Praxis. Betrachten wir beispielsweise die Domäne „Gesundheitswesen“ und die Aufgabe,
ein Patientenverwaltungssystem für ein Krankenhaus zu entwerfen. Das Problem
hierbei liegt nun darin, dass die Domänenexperten (Ärzte, Pfleger etc.) keinen
Hintergrund in konzeptioneller Modellierung haben und nicht wissen, wie sie ihr
Domänenwissen in ein Datenbankschema abbilden sollen. Datenbankexperten
haben hingegen ein Verständnis von Tabellen und Relationen, aber es fehlt Ihnen an
Domänenwissen. Man benötigt also eine Art „Zwischensprache“, um auf einfache
und doch präzise Art und Weise zu kommunizieren. Diese Zwischensprache soll
möglichst einfach zu verstehen und unabhängig von allen Implementierungsdetails
sein, die erst relevant werden, wenn man die beschriebene Miniwelt in der konkreten Sprache eines DBMS formulieren möchte. In unserem Fall ist die Zielsprache,
in der wir unsere Miniwelt formulieren wollen, das relationale Datenmodell. Wir
gehen also davon aus, dass wir ein relationales DBMS verwenden wollen. Da
das konzeptionelle Schema aber erst mal unabhängig von der Implementierung
des DBMS sein soll, verwenden wir zunächst ein sogenanntes „semantisches Datenmodell“ als Zwischensprache. Eine solche Zwischensprache, das so genannte
Entity-Relationship-Modell (ER-Modell), werden wir in Kürze kennenlernen.
Das ER-Modell ist die Grundlage vieler Modellierungssprachen, so auch von UML,
welche Sie in der Lehrveranstaltung Programmiersysteme kennenlernen werden.
Die Vorgehensweise der Datenmodellierung ist nochmals genauer in Abb. 1.9
dargestellt. Der Anfangspunkt ist jeweils die zu modellierende Miniwelt. In (unter
Umständen) mehreren Schritten wird die Miniwelt in ein konzeptionelles Schema
abgebildet, das in der angesprochenen Zwischensprache formuliert ist. Da wir
hier das ER-Modell als Zwischensprache verwenden, steht als Ergebnis ein ERDiagramm.
Seite 20
Studienbrief 1 Grundlagen der Modellierung und das ER-Modell
konzeptioneller Entwurf
Der Schritt von der Miniwelt in das konzeptionelle Schema gilt als der eigentlich
schwierige Schritt bei der konzeptionellen Modellierung. Man spricht hier auch
vom konzeptionellen Entwurf. Für einen guten konzeptionellen Entwurf braucht
man in der Regel viel Erfahrung.
logischer Entwurf
Während dieser erste Schritt eher als „Kunst“ betrachtet wird, ist der zweite Schritt,
nämlich die Übertragung des konzeptionellen Schemas in das logische Schema,
eher Handwerk. Dieser zweite Schritt wird auch als logischer Entwurf bezeichnet.
Im Rahmen des logischen Entwurfs wird ein implementierungsunabhängiges konzeptionelles Schema in die konkrete Sprache eines DBMS überführt. Im relationalen
Datenmodell ist das Ergebnis dann ein relationales Datenbankschema.
Abb. 1.9: Datenmodellierung an Hand
eines Minimodells
Miniwelt
Begriffe
Objekte
Objektbeziehungen
Konzeptioneller
Entwurf
Logischer
Entwurf
K
Kontrollaufgabe 1.4: Eigenschaften eines konzeptionellen Schemas
Welche zwei Haupteigenschaften eines konzeptionellen Schemas werden
durch die explizite Trennung von externen und internen Schemata erreicht?
Abb. 1.10 zeigt den konzeptionellen Entwurf im Zusammenhang weiterer Phasen
des Datenbankentwurfs. In diesem Studienbrief geht es zunächst um die Erstellung
des konzeptionellen Entwurfs. Dieser Schritt ist unabhängig von einem konkreten
Datenbankmanagementsystem. Alle weiteren Schritte, insbesondere der logische
Entwurf, sind DBMS-spezifisch. Im Rahmen dieses Moduls werden nur der konzeptionelle und der logische Entwurf betrachtet. Der physische Entwurf wird in
anderen Datenbankvorlesungen behandelt. Der linke Zweig von Abb. 1.10 bezieht
sich auf die Einbettung der Datenbank in die Anwendung und wird üblicherweise
in Lehrveranstaltungen zum Thema Software Engineering behandelt.
1.3.6 Typen von Datenbanksystemen
Das Relationenmodell, mit dem wir uns in diesem Modul beschäftigen, ist das
weltweit verbreitetste Datenbankmodell. Es ist aber nicht das einzige. Zum Abschluss dieses Abschnittes erfolgt noch ein kurzer (teilweise) historischer Ausblick
auf verschiedene Typen von Datenbanksystemen. Dieser Abschnitt ist als Exkurs
zu verstehen.
1.4 Das Entity-Relationship-Modell
Seite 21
Abb. 1.10: Phasen des
Datenbankenentwurfs
(nach Elmasri and Navathe [2000])
Miniwelt
DBMS-unabhängig
FunktionaleKAnforderungen
SpezifikationKvon
Transaktionen
KonzeptuellesKSchema
DBMS-spezifisch
Anforderungsanalyse
Anwendungsprogrammentwurf
LogischesKBKonzeptuellesäKSchema
Funktionalanalyse
Datenbankanforderungen
Konzeptueller
Entwurf
Vorlesung
Konzeptionelle
Modellierung
LogicalKDesign
PhysicalKDesign
Implementierung
InternesKSchema
Andere
DatenbankVorlesungen
Anwendungsprogramm
Das historisch älteste Datenmodell ist das hierarchische Datenmodell. Hier werden
Datensätze, die hierarchisch zusammenhängen, „nahe beieinander“ gespeichert.
Ein Beispiel für eine hierarchische Datenbeziehung ist die Abteilungshierarchie
einer Firma (Abteilungen mit Unterabteilungen). Suchanfragen entlang dieser Hierarchie werden sehr effizient unterstützt: Wenn man den Chef einer Abteilung
gefunden hat, dann hat man auch seine Mitarbeiter. Wenn man hingegen andere
Datenstrukturen modellieren will, die entgegen der Hierarchie stehen (beispielsweise Mitarbeiter, die in mehreren Abteilungen arbeiten), muss man Redundanz
einbauen und wird insbesondere bei Änderungsoperationen ineffizient. Das hierarchische Datenmodell erlaubt nur einen geringen Grad an Datenunabhängigkeit,
weil der semantische Bezug von zwei Datensätzen durch physische Nachbarschaft
ausgedrückt wird. Es ist also beispielsweise nicht ohne Weiteres möglich, den
Speicherort eines Datensatzes zu verändern ohne damit auch seine Bedeutung zu
verändern.
hierarchisches Datenmodell
Objektorientierte Datenbanksysteme verwenden ähnliche Konzepte zur Datenmodellierung wie objektorientierte Programmiersprachen (Objekte, Methoden,
Vererbung, siehe Modul „Einführung in die Programmierung“), konnten sich
aber am Markt nicht wirklich durchsetzen. Objektrelationale Datenbanksysteme
sind die Kombination aus relationalen und objektorientierten Konzepten. XMLDatenbanksysteme haben hingegen ihre Vorteile, wenn es um die Verarbeitung von
„semistrukturierten Daten“ geht. Diese werden vor allem in Webanwendungen
eingesetzt. Auf weitere Datenmodelle soll hier nicht eingegangen werden.
1.4 Das Entity-Relationship-Modell
Datenbanken spielen eine zentrale Rolle in modernen Softwaresystemen. Im vorigen Abschnitt haben wir gesehen, welche Rolle das konzeptionelle Schema im
Kontext des Datenbankentwurfs und der konzeptionellen Modellierung spielt: Es
ist ein zentrales Ausdrucksmittel bei der Umsetzung eines Realitätsausschnitts
in ein Modell. Um das konzeptionelle Schema auszudrücken, benötigt man eine
Notation (eine „Sprache“). Entity-Relationship-Diagramme (ER-Diagramme) sind
Ausdrücke einer solchen Sprache. Den Formalismus hinter ER-Diagrammen nennt
man das Entity-Relationship-Modell (abgekürzt ER-Modell).
In diesem Kapitel lernen Sie die Grundlagen des Entity-Relationship-Modells
Entity-RelationshipModell
Seite 22
Studienbrief 1 Grundlagen der Modellierung und das ER-Modell
kennen, insbesondere die verschiedenen Entity-Typen und Relationship-Typen.
Einen Ausschnitt der Welt kann man in ganz verschiedener Weise mittels ERDiagrammen ausdrücken. Sie lernen deshalb auch, wie man möglichst gute ERDiagramme schreibt, also den Unterschied zwischen guten und schlechten ERDiagrammen. Dieses Kapitel orientiert sich an der Begleitliteratur, insbesondere
Elmasri and Navathe [2000, Kapitel 3] .
1.4.1 Grundlagen des ER-Modells
Das ER-Modell ist eine formale Ausdrucksform, um Gegenstände (Entities) und
ihre Beziehungen (Relationships) untereinander darzustellen. Wir gehen nun auf
die einzelnen Begriffe des ER-Modells genauer ein. Da diese Begriffe zentral für
das Verständnis dieses Moduls sind, haben wir sie im Rahmen von Definitionen
hervorgehoben.
Definition 1.1: Entity
D
Ein Entity ist ein zu beschreibendes Objekt.2
Ein Entity kann beispielsweise ein konkretes Haus, ein bestimmtes Auto oder ein
benennbares Boot sein, im Prinzip alles, was in einer Datenbank repräsentiert und
durch sie verwaltet werden soll. Eine Menge gleichartiger Objekte nennt man auch
Entity-Menge.
Entity-Typ
Beim Datenbankentwurf möchte man aber nicht auf der Ebene konkreter Entities
arbeiten, sondern auf der Ebene von Entity-Typen. Entity-Typen abstrahieren eine
Entity-Menge durch die Angabe ihrer typischen Eigenschaften. Ein Entity-Typ
könnte eine bestimmte Menge von Personen sein, etwa die Menge der Mitarbeiter
einer Firma.
Attribut
Grafisch stellt man einen Entity-Typ als Kasten dar. Jeder Entity-Typ hat einen
Namen. Diesen Namen schreibt man üblicherweise mitten in den Kasten hinein.
In Abb. 1.11 ist als Beispiel der Entity-Typ „Mitarbeiter“ grafisch dargestellt. Um
Entities genauer zu beschreiben, verwendet man Attribute.
Abb. 1.11: EntityTyp mit Attributen
Vorname
Name
PNR
Mitarbeiter
Definition 1.2: Attribut
D
Ein Attribut ist eine Eigenschaft bzw. ein Merkmal von Objekten eines EntityTyps.
2
Wir sagen eingedeutscht „das“ Entity, es übernimmt als das Geschlecht vom Objekt.
1.4 Das Entity-Relationship-Modell
Seite 23
Beispiele für Attribute eines Mitarbeiters sind die Personalnummer (PNR, siehe
Abb. 1.11), der Vorname oder Nachname.
Unter allen Attributen gibt es besondere Attribute, so genannte Schlüsselattribute.
Dies sind Attribute, die genau ein Entity identifizieren. Bei Schlüsselattributen gibt
es also jeden Attribut-Wert nur einmal. Schlüsselattribute werden in der grafischen
Darstellung unterstrichen. In Abb. 1.11 ist das Attribut „PNR“ ein Schlüsselattribut,
da jedem Mitarbeiter eine eindeutige Nummer zugewiesen wird.
Schlüsselattribut
Manchmal kann ein Entity-Typ auch mehrere Schlüsselattribute enthalten. Wenn
mehrere Attribute unterstrichen sind, bedeutet das in der hier vorgestellten Notation, dass es verschiedene Möglichkeiten gibt, die Entities dieses Typs zu identifizieren. Beispielsweise könnten Abteilungen entweder durch den Abteilungsnamen
oder durch die Abteilungsnummer identifiziert werden. Manchmal braucht man
auch eine Kombination von Merkmalen, um Entities zu identifizieren. Dann verwendet man zusammengesetzte Attribute. Unter der Annahme, dass es unter den
Mitarbeitern einer Firma keine Personen mit demselben Namen gibt (also der
Kombination aus Vornamen und Nachnamen), könnte man auch die beiden Attribute „Vorname“ und „Nachname“ als zusammengesetztes Attribut definieren und
dieses Attribut als Schlüsselattribut auszeichnen. Wir werden später dazu noch
Beispiele kennenlernen.
Neben Entities gibt es als zweites wesentliches Konzept im ER-Modell sogenannte
Relationships.
Definition 1.3: Relationship
D
Eine Relationship ist eine Beziehung zwischen zwei oder mehr
Objekten.3
Analog zur Entity-Menge bezeichnet man eine Menge gleichartiger Relationships
als Relationship-Menge. Ein Relationship-Typ ist eine Beschreibung gleichartiger
Beziehungen. Genauso wie bei den Entities verwenden wir zur Modellierung nicht
konkrete Relationships, sondern Relationship-Typen.
Vorname
Name
PNR
Mitarbeiter
Position
Arbeitet_in
Beginn
Ende
Projekt
PNR
Name
3
Sprachlich übernimmt die Relationship das Geschlecht von der Beziehung. Wir sagen also eingedeutscht die Relationship.
Relationship-Menge und
Relationship-Typ
Abb. 1.12: Beispiel für
Relationship-Typ
Seite 24
Darstellung von
Relationship-Typen
Studienbrief 1 Grundlagen der Modellierung und das ER-Modell
Abb. 1.12 zeigt ein einfaches Beispiel mit zwei Entity-Typen (Mitarbeiter und
Projekt) und einem Relationship-Typ „arbeitet in“. Eine Ausprägung dieses Typs
beschreibt die „Arbeitsbeziehung“ zwischen einem Mitarbeiter und einem Projekt, in dem er oder sie arbeitet. Relationship-Typen werden typischerweise als
Raute dargestellt, die mit Linien die Entity-Typen verbinden, zwischen denen die
Beziehung besteht.
Relationship-Typen besitzen einen Namen und können Attribute haben. In dem
Beispiel aus Abb. 1.12 wird festgehalten, in welcher Position der Mitarbeiter im
Projekt arbeitet, wann er seine Arbeit im Projekt begann und wann sie voraussichtlich endet. Relationship-Typen können keine Schlüsselattribute haben, da
die einzelnen konkreten Relationships (Beziehungen) immer durch die jeweils
beteiligten Entities identifiziert werden.
K
Kontrollaufgabe 1.5: Attribute
Stellen Sie sich vor, das Attribut „Position“ wäre nicht ein Attribut des
Relationship-Typs „arbeitet in“, sondern des Entity-Typs „Mitarbeiter“. Welche Vor- und Nachteile hätte dies?
Was ist, wenn ein Mitarbeiter in mehreren Projekten arbeitet? Macht es Sinn,
das Attribut an den Entity-Typ „Projekt“ zu heften?
Im Prinzip haben Sie jetzt bereits die wichtigsten Grundlagen des ER-Modells
kennengelernt. Um dieses Wissen zu vertiefen, betrachten wir ein Beispiel. Dabei
sehen wir, dass ein ER-Diagramm schnell sehr komplex werden kann. Gerade für
Anfänger sind diese Diagramme schwer nachzuvollziehen. Wir werden deshalb
den Formalismus ausgiebig in den Übungen dieses Studienbriefs behandeln.
1.4 Das Entity-Relationship-Modell
Seite 25
Im folgenden Beispiel soll die Personalverwaltung einer Firma im ER-Modell
modelliert werden:
Beispiel 1.3: Personalverwaltung
B
Die Beispielfirma ist nach Abteilungen organisiert. Jede Abteilung hat einen
eindeutigen Namen sowie eine Abteilungsnummer. Weiter ist jeder Abteilung ein Manager zugeordnet. Zu jedem Manager wird das Startdatum
seiner Managertätigkeit notiert.
Jede Abteilung kann auf mehrere Standorte aufgeteilt sein und mehrere
Projekte organisieren. Jedes Projekt hat einen eindeutigen Projektnamen,
eine Projektnummer, und ein Projekt findet immer nur an einem Standort
statt.
Ein Mitarbeiter kann männlich oder weiblich sein, besitzt einen Namen, eine
Versicherungsnummer, eine Adresse, ein Geburtsdatum und bezieht ein
bestimmtes Gehalt. In der Firma wird ein Mitarbeiter immer einer Abteilung
zugeordnet, kann aber an mehreren Projekten beteiligt sein, auch an Projekten anderer Abteilungen. Es soll festgehalten werden, wie viele Stunden ein
Mitarbeiter an einem Projekt arbeitet. Auch der direkte Vorgesetzte eines
Mitarbeiters muss immer festgelegt sein.
Um die Bezüge (Kindergeld, Freibeträge) eines Mitarbeiters korrekt berechnen zu können, sollen auch Daten der Angehörigen eines Mitarbeiters
festgehalten werden. Benötigt werden Angaben zu Name, Geschlecht, Geburtsdatum sowie zur Art der Beziehung zu dem Mitarbeiter.
Die Angaben aus dem vorgenannten Beispiel kann man nun mit dem bestehenden
Wissen über das ER-Modell in ein erstes ER-Diagramm überführen. Dies ist in
Abb. 1.13 dargestellt. Wie wir gleich sehen werden, verwendet die Abbildung
einige „Tricks“, um ER-Diagramme leichter lesbarer zu machen. Diese Tricks sind
auch Teil der offiziellen Notation. Wir erklären diese Tricks im Anschluss an die
folgende Kontrollaufgabe.
Kontrollaufgabe 1.6: Überprüfung des Beispiels
Gehen Sie den Text aus Beispiel 1.3 durch und prüfen Sie, ob alle EntityTypen und Relationship-Typen im Diagramm vorhanden sind und ob keines
vergessen wurde.
1.4.2 Die Symbole in ER-Diagrammen
Wir beschreiben im Folgenden die Darstellung und Bedeutung der Symbole in ERDiagrammen im Überblick. Diese Beschreibung wird in den folgenden Abschnitten
dann noch weiter vertieft.
Wir beginnen mit Entity-Typen und Relationship-Typen. Abb. 1.14 zeigt die Symbole in der Übersicht nach Elmasri and Navathe [2000]. Wie oben bereits erwähnt,
werden Entity-Typen durch Rechtecke dargestellt, Relationship-Typen durch Rauten. Man unterscheidet zwischen „normalen“ Entity-Typen und schwachen EntityTypen, die mit einem doppelten Rechteck bezeichnet werden und die wir später
noch genauer erklären.
K
Geschlecht
1
Geschlecht
Name
Vorgesetzer von
GebDat
Untergebener
1
1
Gehalt
Nachname
Mitarbeiter
Name
Mittelinitiale
Beziehung
Angehöriger
N
leitet
Stunden
1
1
Arbeitet an
Startdatum
Arbeitet für
Hat_Agehörige
N
1
N
GebDat
M
Nummer
Nummer
Projekt
N
organisiert
1
Abteilung
Name
Name
Orte
Ort
AnzahlMitarbeiter
Abb. 1.13: ER-Diagramm
einer Personalverwaltung (zur besseren
Lesbarkeit rotiert)
Vorgesetzer
Adresse
SSN
Vorname
Seite 26
Studienbrief 1 Grundlagen der Modellierung und das ER-Modell
1.4 Das Entity-Relationship-Modell
Seite 27
Bei Relationship-Typen unterscheidet man zwischen „normalen“ RelationshipTypen und identifizierenden Relationship-Typen. Identifizierende Beziehungstypen
stehen im Zusammenhang zu schwachen Entity-Typen und werden im Folgenden
noch genauer erläutert.
Abb. 1.14: Entity- und
Relationship-Typen
ENTITY
EntitywTypw(Gegenstandstyp)
WEAK
ENTITY
SchwacherwEntitywTyp
RELATION
SHIP
RelationshipwTypw(Beziehungstyp)
Ident.
RELATION
SHIP
IdentifizierenderwRelationshipwTyp
Die verschiedenen Möglichkeiten für Attribute sind in Abb. 1.15 dargestellt. Wie
bereits beschrieben, werden Attribute als Kreise/Ellipsen dargestellt und haben
einen Namen. Der Name von Schlüsselattributen wird dabei unterstrichen.
Abb. 1.15: Attribute
Attribut
attribute
Schlüsselattribut
UID
Mehrwertiges Attribut
multivalued
A.2
A.3
A.1
Zusammengesetztes Attribut
A
derived
Abgeleitetes Attribut
Ein Attribut wie „Gehalt“ oder „Name“ hat üblicherweise genau einen Wert. Es
gibt aber auch Attribute, bei denen mehrere Werte sinnvoll sind. Ein Beispiel
aus Abb. 1.13 ist das Attribut „Orte“ des Entity-Typs „Abteilung“, das mehrere
Werte haben kann, da sich eine Abteilung an mehreren Standorten befinden kann.
Mehrwertige Attribute werden mit einer doppelten Linie eingerahmt.
Attribute können aus mehreren Attributen zusammengesetzt sein. Wie dies dargestellt wird, ist in Abb. 1.15 zu sehen. Ein Beispiel aus der Personalverwaltung
in Abb. 1.13 ist der Name des Mitarbeiters, der aus den drei Attributen Vorname,
Mittelinitiale und Nachname zusammengesetzt ist.
Schließlich gibt es noch abgeleitete Attribute. Ein abgeleitetes Attribut enthält einen
Wert, der aus anderen im Modell bereits vorhandenen Informationen vollständig
abgeleitet werden kann. Man muss dieses Attribut also eigentlich gar nicht explizit
speichern, da es immer wieder „ausgerechnet“ werden kann. Ein Beispiel für
abgeleitetes Attribut
Seite 28
Studienbrief 1 Grundlagen der Modellierung und das ER-Modell
ein abgeleitetes Attribut in Abb. 1.13 ist „AnzahlMitarbeiter“ des Entity-Typs
„Abteilung“. Über die Zuordnung von Mitarbeitern zu Abteilungen kann man
dieses Attribut ausrechnen. Abgeleitete Attribute werden mit einer gestrichelten
Linie umkreist.
Abb. 1.16:
Relationship-Typen
R
E1
E2
Totale"Teilnahme"von"E2"in"R
E1
1
R
N
E2
Kardinalität"des"Beziehungstyps"R
E1
(min,"max)
R
E2
Strukturelle"Bedingung"für"die"Teilnahme
von"E1"in"R",(min,"max)-Notation,
In Abb. 1.16 werden verschiedene Möglichkeiten aufgezeigt, wie Einschränkungen
(Constraints) für Beziehungstypen definiert werden können. Ein Beziehungstyp
wird, wie bereits erwähnt, als Raute dargestellt, die mit Linien zwei (oder mehrere)
Entity-Typen verbindet. Diese Basis-Notation wird durch zusätzliche Markierungen
noch erweitert. Diese Markierungen bezeichnen die Art der Beziehung noch etwas
genauer.
Kardinalität
Betrachten wir zunächst die Zahlen, die an den Verbindungslinien des RelationshipTyps zu den jeweiligen Entity-Typen stehen. Diese beziffern die sogenannte Kardinalität des Relationship-Typs, d.h. sie geben wieder, in welchem Zahlenverhältnis
die Beziehung gilt. Betrachten wir zur Verdeutlichung das Beispiel in Abb. 1.13:
Hier besteht eine Beziehung „arbeitet für“ zwischen dem Entity-Typ „Mitarbeiter“ und dem Entity-Typ „Abteilung“. Die Zahlen N (auf der Verbindung zum
Mitarbeiter) und 1 (auf der Verbindung zur Abteilung) bedeuten, dass mehrere (ausgedrückt als N) Mitarbeiter in einer Abteilung arbeiten. Hier werden also mehrere
Mitarbeiter einer Abteilung zugeordnet.
funktionale Abhängigkeit
Als Kontrast betrachten wir die darunterliegende Beziehung „leitet“. Die Angaben
dort besagen, dass ein Mitarbeiter höchstens einer Abteilung als Leiter zugeordnet
ist und umgekehrt. Ein und derselbe Mitarbeiter kann demnach nicht zwei Abteilungen leiten. Genauso kann ein und dieselbe Abteilung nicht von mehreren
Mitarbeitern geleitet werden. Beachten Sie, dass durch jede 1 an einer Kante eine
Einschränkung definiert wird. Die 1 in Abb. 1.16 besagt beispielsweise, dass es zu
jedem Entity vom Typ E2 höchstens ein Entity vom Typ E1 gibt.
Chen-Notation
Etwas anders formuliert bedeutet das: Es wird eine funktionale Abhängigkeit
definiert, so dass E1 funktional durch E2 bestimmt wird. Diese Form der Spezifikation von Beziehungskardinalitäten wird nach dem Erfinder des ER-Modells
Peter Chen auch als Chen-Notation bezeichnet.
totale Teilnahme
Wenn wir möchten, dass jeder Mitarbeiter in mindestens einer Abteilung arbeitet,
sprechen wir von totaler Teilnahme eines Entity-Typs an der Beziehung. Totale
Teilnahme wird mit einer doppelten Linie markiert. In Abb. 1.13 gibt es mehrere
Beziehungen, die eine totale Teilnahme vorschreiben. Beispielsweise wird jede
Abteilung von mindestens einem Mitarbeiter geleitet. Außerdem arbeitet jeder
1.4 Das Entity-Relationship-Modell
Seite 29
Mitarbeiter in mindestens einem Projekt, und jedem Projekt ist mindestens ein
Mitarbeiter zugeordnet.
Kontrollaufgabe 1.7: totale Teilnahme
K
Prüfen Sie anhand Ihres Verständnisses von ER-Diagrammen, ob die folgenden Aussagen für das Diagramm im Abb. 1.13 auf Seite 26 stimmen:
1. Jeder Mitarbeiter arbeitet in genau einer Abteilung.
2. Es kann Mitarbeiter geben, die in keiner Abteilung arbeiten.
3. Es kann Abteilungen geben, in denen keine Mitarbeiter arbeiten.
4. Jeder Mitarbeiter leitet eine Abteilung.
5. Jeder Mitarbeiter leitet mindestens eine Abteilung.
6. Es kann Abteilungen geben, die durch keinen Mitarbeitet geleitet
werden.
Alternativ zur Chen-Notation in Verbindung mit der Notation zur Formulierung
einer Totalen Teilnahme kann auch die sogenannte „(min,max)-Notation“ zur
Spezifikation von Einschränkungen auf Beziehungstypen verwendet werden (siehe
Abb. 1.16, unten). Eine Angabe von (x, y) an einer Kante eines Entity-Typs E1 zum
Relationship-Typen R bedeutet folgendes:
• E1 nimmt an mindestens x Beziehungen R teil.
• E1 nimmt an höchstens y Beziehungen R teil.
So kann man beispielsweise modellieren, dass eine Abteilung mindestens 2 und
höchstens 100 Mitarbeiter haben darf.
Auf den ersten Blick scheint die (min,max)-Notation die zuvor genannten Darstellungen zu verallgemeinern. Wie wir später noch sehen werden, gibt es bei
mehrstelligen Beziehungstypen aber auch Einschränkungen, die nur mit der ChenNotation formuliert werden können.
Kontrollaufgabe 1.8: totale Teilnahme und (min,max)-Notation
K
Wie würde man totale Teilnahme von E1 an R in der (min,max)-Notation
ausdrücken?
1.4.3 Entities und ihre Attribute
Wir betrachten die Begriffe Entity, Entity-Typ und Attribute von Entities nun genauer.
Was macht ein Entity genau aus? Ein wesentliches Merkmal eines Entity ist seine
eigenständige Existenz. Entities müssen identifizierbar sein, man muss sie also
unterscheiden können. Diese Unterscheidung erfolgt mittels ihrer Attribute. Insbesondere möchten wir gerne, dass Entities eindeutig identifizierbar sind. Dies
geschieht über die bereits oben beschriebenen Schlüsselattribute. Beispiel für ein
Schlüsselattribut bei Studierenden ist die Matrikelnummer (es gibt keine zwei
Studierenden mit derselben Matrikelnummer).
Merkmale von Entities
Seite 30
Studienbrief 1 Grundlagen der Modellierung und das ER-Modell
Attributwert
Attribute von (konkreten) Entities haben einen Wert (siehe Abb. 1.17). Der Unterschied zwischen Attributen und Attributwerten ist wichtig, um den Unterschied
von Entity-Typ und Entity-Menge zu verstehen. Entities werden durch ihre Attributwerte identifiziert. Wir fordern zusätzlich, dass Entities ausschließlich durch
ihre Attributwerte identifiziert werden. Entities müssen also vollständig durch ihre
Attributwerte beschreibbar sein. Außer Attributwerten (und Beziehungen) gibt es
nichts, was ein Entity im ER-Modell zusätzlich beschreiben könnte. Wir fordern
zusätzlich, dass Entities relevant sind für den zu modellierenden Weltausschnitt.
Abb. 1.17: Entity, Attribute, Attributwerte
Entity E1
Name:
Meier
Vorname:
Hans
PNR:
1236
Attribute
Attributwerte
Intension und Extension
Die Unterscheidung zwischen Entity-Typ und Entity-Menge bringt uns auf einen
Gegensatz, den wir später auch in anderen Kontexten wiedersehen werden.
Merksatz 1.3: Intension und Extension
M
Der Entity-Typ (Intension) ist eine abstrakte Typ-Beschreibung. Die EntityMenge (Extension) ist die Menge von Entities, die der Typ-Beschreibung
entsprechen.
Intension
Die Intension ist also das, was Sie modellieren (wollen): Der Entity-Typ mit seinen Attributen. Dies ist das konzeptionelle Schema, das sich üblicherweise zur
Lebenszeit der Datenbank nicht ändert. Die Entity-Menge umfasst hingegen alle
konkreten Entities, die in ihrer Datenbank gespeichert werden. Diese Menge ist
„flexibel“ und kann sich mit der Zeit ändern. Ein Entity-Typ hat also Attribute, ein
Entity hat Attributwerte.
Entity-Typen unterscheiden sich in ihren Attributen. Der Entity-Typ „Mitarbeiter“
beinhaltet beispielsweise die Attribute „Name“, „Alter“ und „Gehalt“. Ein anderer
Entity-Typ „Firma“ enthält die Attribute „Name“, „Standort“ und „Chef“. Das
Entity-Set für den Entity-Typ „Mitarbeiter“ könnte also zu einem bestimmten
Zeitpunkt so aussehen:
m1 (John Smith, 55, 80K)
m2 (Fred Brown, 40, 30K)
m3 (Judy Clark, 25, 20K)
Das Entity-Set für den Typ „Firma“ könnte wie folgt aussehen:
f1 (Sunco Oil, Houston, John Smith)
f2 (Fast Computer, Dallas, Bob King)
1.4 Das Entity-Relationship-Modell
Seite 31
Die Kürzel m1 , m2 , m3 , f1 und f2 sollen die eigentlichen Entities darstellen. In
Klammern dahinter folgen deren Attributwerte.
Im oberen Beispiel ist „Firma“ die Intension und f1 und f2 sind die Extension.
Analog dazu handelt es sich bei „Mitarbeiter“ um die Intension und bei m1 , m2
und m3 um die Extension.
Attribute und der NULL-Wert
Wir gehen nun genauer auf die Attribute von Entities ein. Wie bereits dargestellt,
beschreiben Attribute Eigenschaften eines Entity. In den bisher aufgeführten Beispielen wurde jedem Entity für jedes Attribut jeweils ein Wert zugewiesen. Es
kann aber auch sein, dass es Entities gibt, denen für ein bestimmtes Attribut kein
Wert zugewiesen werden kann. Dies ist beispielsweise der Fall, wenn ein Mitarbeiter kein Telefon hat. Dann kann im Attribut Telefonnummer auch kein Wert
stehen. Für solche Fälle gibt es einen besonderen Attributwert, den wir NULL
nennen. Der Attributwert NULL bedeutet nicht immer, dass der entsprechende
Attributwert nicht existiert. Der Wert NULL bedeutet einfach nur „dieser Wert
fehlt“. Verschiedene Gründe dafür könnten sein, dass
1. der Wert nicht existiert, oder
2. der Wert existiert, aber nicht bekannt ist, oder
3. es unbekannt ist, ob der Wert existiert.
Der Wert NULL ist vom Zahlenwert „0“ zu unterscheiden. Stellen Sie sich vor,
ein Attribut wie „Gehalt“ besitzt den Wert „0“. Das bedeutet, dass das Attribut
„befüllt“ und inhaltlich interpretiert werden kann (das Gehalt beträgt 0 Euro). Ist
hingegen ein Attributwert NULL gespeichert, bedeutet dies, dass das Attribut nicht
befüllt ist. In diesem Fall darf man es nicht interpretieren.
Ein anderes Beispiel ist ein Attribut „Telefonnummer“ einer Person. Der Wert
NULL könnte in ganz verschiedener Weise interpretiert werden. Er kann bedeuten,
dass die Person gar kein Telefon hat, allerdings auch, dass die Telefonnummer
einfach unbekannt ist. Um keine Fehlinterpretationen zu verursachen, fordern wir,
dass NULL-Attribute nicht interpretiert werden dürfen.
Zusammengesetzte Attribute
Attribute können verschieden aufgebaut sein. Der einfachste Fall sind atomare
Attribute. Diese haben wir oben bereits kennengelernt. Diese speichern einfach
einen Attributwert. Es gibt hingegen auch Attribute, die aus mehreren Teilattributen bestehen. Dies sind zusammengesetzte Attribute. Oben hatten wir bereits ein
Beispiel für ein zusammengesetztes Attribut kennengelernt, das Attribut „Name“.
Aber auch das Attribut „Adresse“ kann aus mehreren strukturierten Teilattributen
bestehen wie etwa „PLZ“, „Ort“, „Straße“ oder „Hausnummer“. Um dieses Attribut trotzdem als ganzes ansprechbar zu haben, wird es als zusammengesetztes
Attribut definiert.
Mehrwertige Attribute
Eine weitere Spielart von Attributen sind mehrwertige Attribute. Atomare Attribute
sind einwertige Attribute. Sie können immer maximal einen Wert speichern, wie
beispielsweise „Alter“ oder „Geschlecht“. Mehrwertige Attribute können mehrere
Attributwerte speichern. Ein Beispiel hatten wir bereits oben: Das Attribut „Orte“ einer Abteilung kann mehrere Werte haben, da die Abteilung über mehrere
mehrwertiges Attribut
Seite 32
Studienbrief 1 Grundlagen der Modellierung und das ER-Modell
Liegenschaften verteilt sein kann. Durch eine Zusatznotation (die wir hier nicht
besprechen) kann man sogar Ober- und Untergrenzen angeben.
Abgeleitete Attribute
gespeicherte & abgeleitete Attribute
Weiterhin unterscheiden wir gespeicherte und abgeleitete Attribute. Dieses Merkmal
bezieht sich auf die interne Repräsentation. Der Normalfall sind gespeicherte Attribute, die „ganz normal“ in der Datenbank abgelegt werden. Ein abgeleitetes
Attribut hingegen kann vollständig aus anderen verfügbaren Informationen abgeleitet werden. So kann beispielsweise das Alter aus dem aktuellen Datum und
dem Geburtsdatum abgeleitet werden und muss deshalb nicht explizit gespeichert
werden.
Komplexe Attribute
komplexes Attribut
Verschiedene Attributsmerkmale können kombiniert werden. Dies führt zu komplexen Attributen. Diese werden textuell in einer speziellen Notation angegeben.
Wir betrachten hier die Kombination von zusammengesetzten und mehrwertigen
Attributen. Zusammengesetzte Attribute schreiben wir in runden Klammern. Ein
Attribut „Telefonnummer“, das aus den Attributen „Vorwahl“ und „Teilnehmernummer“ zusammengesetzt ist, notieren wir wie folgt:
Telefonnummer (Vorwahl, Teilnehmernummer)
Allgemein wird das zusammengesetzte Attribut A, das aus den Attributen A1 bis
An zusammengesetzt ist, wie folgt aufgeschrieben:
A(A1 , . . . , An )
Mehrwertige Attribute werden in der Notation mit geschweiften Klammern geschrieben. Das mehrwertige Attribut „Standort“ würde man dann wie folgt schreiben:
{ Standort }
Man kann zusammengesetzte Attribute und mehrwertige Attribute zu komplexen
Attributen kombinieren.
B
Beispiel 1.4: komplexe Attribute
Ein Beispiel für ein komplexes Attribut „Kontaktinfo“ könnte man beispielsweise wie folgt textuell notieren:
{ Kontaktinfo (
{ Telefonnummer (Vorwahl, Teilnehmernummer) },
Adresse (Straße (Straßenname, Hausnummer),
PLZ, Ort) ) }
Das Attribut „Kontaktinfo“ ist also ein mehrwertiges Attribut, das aus mehreren Attributen zusammengesetzt ist, nämlich „Telefonnummer“ und „Adresse“.
Das Attribut „Telefonnummer“ ist ein mehrwertiges, zusammengesetztes Attribut. Adresse hingegen ist zusammengesetzt aus „Straße“, „PLZ“, „Hausnummer“,
wobei „Straße“ wieder ein zusammengesetztes Attribut ist. Dieses Beispiel ist
nicht sonderlich elegant (es soll ja nur das Konzept eines komplexen Attributes
1.4 Das Entity-Relationship-Modell
Seite 33
demonstrieren). Der Normalfall in der Praxis sind die einfachen (nicht-komplexen)
Attribute.
Kontrollaufgabe 1.9: komplexe Attribute
K
Zeichnen Sie das komplexe Attribut aus Beispiel 1.4 in grafischer Notation.
Schlüsselattribute
Eine wichtige Art von Attributen sind Schlüsselattribute. Schlüsselattribute ermöglichen es, ein Entity eindeutig zu identifizieren. Da diese Eigenschaft für Entities
so wichtig ist, werden in der Praxis der Einfachheit halber spezifische Attribute als
Schlüsselattribute eingeführt. So entstehen Attribute wie „Matrikelnummer“ oder
„Personalnummer“, obwohl man auch die Kombination anderer Attribute, etwa
„Vorname“, „Nachname“ und „Geburtsdatum“ verwenden könnte, um Personen
eindeutig zu identifizieren (aber das funktioniert in ganz seltenen Fällen eben auch
nicht).
Schlüsselattribut
Wenn eine Gruppe von Attributen zusammengefasst wird, um eine Eindeutigkeit
erreichen zu können, spricht man von zusammengesetzten Schlüsselattributen.
Ein zusammengesetztes Schlüsselattribut sollte allerdings minimal sein, d.h. man
sollte nicht mehr Attribute darin zusammenfassen als notwendig sind, um ein Entity eindeutig zu identifizieren. Wenn beispielsweise angenommen wird, dass ein
zusammengesetztes Attribut „(Name, Vorname, Geburtsdatum)“ zur Identifikation einer Person ausreicht, dann ist das Attribut „(Name, Vorname, Geburtsdatum,
Adresse)“ nicht minimal.
zusammengesetztes
Schlüsselattribut
Nicht jeder Entity-Typ muss zwingend ein Schlüsselattribut enthalten. Entity-Typen,
die kein Schlüsselattribut enthalten, nennt man schwache Entity-Typen. Schwache
Entities werden mit Hilfe der Entities eines anderen Entity-Typs identifiziert.
schwacher Entity-Typ
Exkurs 1.1: Wertebereiche von Attributen
Man kann Attribute und ihre Wertebereiche auch noch formaler, also noch
präziser definieren. Grundsätzlich hat jedes einfache Attribut einen Wertebereich bzw. eine Menge von zulässigen Attributswerten. So hat z.B. das Attribut „Alter“ des Entity-Typs „Mitarbeiter“ einen Wertebereich von „16–70“.
Die Wertebereiche werden im ER-Diagramm allerdings nicht angegeben.
Formaler definiert man ein Attribut A eines Entity-Typs E mit Wertebereich
V als Abbildung
A : E 7→ P(V )
wobei P(V ) die Potenzmenge von V bezeichnet, also die Menge aller Teilmengen von V .
Da A eine Abbildung ist, kann man für eine konkrete Entity e den Attributwert mit A(e) bezeichnen. Einwertige Attribute führen dann zu einelementigen Mengen, d.h. falls A ein einwertiges Attribut mit Wert a1 ist, ergibt die
Abfrage des Attributwertes die einelementige Menge {a1 }, also:
A(e) = {a1 }
E
Seite 34
Studienbrief 1 Grundlagen der Modellierung und das ER-Modell
Wäre A ein mehrwertiges Attribut (mit Werten a1 , a2 und a3 , ergäbe die
Abfrage eine dreielementige Menge:
A(e) = {a1 , a2 , a3 }
Der Attributwert NULL wird als leere Menge formalisiert:
A(e) = {}
Für zusammengesetzte Attribute kann man das mathematische Instrument
des Kreuzproduktes verwenden. Der Wertebereich eines Attributes, das aus
n Attributen mit Wertebereichen V1 bis Vn zusammengesetzt ist, ist dann
definiert als:
V = P(V1 ) × P(V2 ) × . . . × P(Vn )
1.4.4 Relationships (Beziehungen)
Eine Relationship (Beziehung) besteht zwischen zwei oder mehr Entities (Objekten).
Entsprechend besteht ein Relationship-Typ zwischen zwei oder mehr Entity-Typen.
Dies wurde bereits in Abb. 1.12 dargestellt. Aus dieser Abbildung können sehr gut
die Beziehungen zwischen den verschiedenen Entities abgelesen werden.
Existenzabhängigkeit
Auch Beziehungen haben Merkmale, die charakteristisch sind. Eine Beziehung
kann zwischen zwei oder mehr Entities bestehen, aber andersherum kann eine
„Relationship“ nicht ohne die beteiligten Entities existieren. So kann z.B. eine
Anstellung zwischen einer Person und einer Firma nicht ohne eine Person oder eine
Firma existieren. Beziehungen sind also existenzabhängig. Daher ist eine Beziehung
nicht eigenständig und hat auch keine Schlüsselattribute. Die Beziehung wird über
die beteiligten Entities identifiziert.
Binäre und n-stellige Beziehungstypen
Wir betrachten Relationship-Typen etwas formaler. Bisher haben wir hauptsächlich binäre Beziehungstypen kennengelernt, also Beziehungstypen zwischen zwei
Entity-Typen, wie etwa ein Mitarbeiter und einer Abteilung. Man kann aber mit Beziehungen beliebig viele Entities miteinander verknüpfen. Die folgende Definition
beschreibt also allgemein n-stellige Beziehungstypen.
D
Definition 1.4: Beziehungstyp (formal)
Ein Beziehungstyp R zwischen n Entity-Typen E1 , . . . , En ist eine Relation
über den Entities der beteiligten Entity-Typen. Formal:
R ⊆ E1 × E2 × . . . × En
Eine Relation über zwei Mengen ist eine Menge von Paaren aus diesen beiden
1.4 Das Entity-Relationship-Modell
Seite 35
Mengen. Bei n Mengen spricht man von n-Tupeln (ein paar ist also ein 2-Tupel,
siehe Modul „Mathematik 1“).
Beispiel 1.5: binäre Beziehungstypen als Tupel
B
Sei
{ Sally, Joe }
die Entity-Menge des Entity-Typs „Studierende“ und sei
{ konzMod, Programmierung 1 }
die Entity-Menge des Entity-Typs „Lehrveranstaltung“. Ein Beziehungstyp
„nimmt teil“ zwischen „Student“ und „Lehrveranstaltung“ beschreibt eine
Zuordnung von Studierenden zu Lehrveranstaltungen. Formal wird das als
Menge von Paaren der Entity-Mengen Studierende und Lehrveranstaltungen
ausgedrückt, also beispielsweise:
{ (Sally, konzMod), (Sally, Programmierung 1), (Joe, konzMod) }
Dies drückt aus, dass Sally an den Lehrveranstaltungen „konzMod“ und
„Programmierung 1“ teilnimmt und Joe an der Lehrveranstaltung „konzMod“.
Analog zur Unterscheidung zwischen Entity-Typen (Intension) und Entity-Mengen
(Extension) unterscheiden wir sprachlich auch zwischen Beziehungstypen (Intension) und Beziehungsmengen (Extension). Die Extension verändert sich über
die Zeit, die Intension aber nicht. Gegenstand der Modellierung ist daher immer
die intensionale Ebene. Besonders trennscharf ist diese Unterscheidung hier aber
nicht, weil wir zur Erläuterung der Bedeutung eines Beziehungstyps immer auch
die extensionale Ebene brauchen. So wird in Definition 1.4 ein Beziehungstyp
tatsächlich als Menge definiert, um zu verdeutlichen, wie die Ausprägungen dieses
Typs aussehen.
Grundsätzlich kann ein Entity an einer Beziehung teilnehmen und ein Entity-Typ
kann an einem Beziehungstyp teilnehmen. Eine Instanz eines n-stelligen Beziehungstyps R, wie er in Definition 1.4 definiert ist, ist immer auch eine n-stellige
Beziehung, die genau n Entities zueinander in Beziehung setzt, nämlich von jedem
der beteiligten Entity-Typen genau ein Entity.
Beispiel 1.6: Beziehungsmenge
Im vorgenannten Beispiel der Studierenden, die an Lehrveranstaltungen
teilnehmen, ist die Menge
{ (Sally, konzMod), (Sally, Programmierung 1), (Joe, konzMod) }
die Beziehungsmenge und die einzelnen Tupel sind die Instanzen. Jede Instanz, z.B. (Sally, konzMod), schließt von jedem an der Beziehung beteiligten
Entity-Typ (Studierende, Lehrveranstaltung) genau ein Entity mit ein.
Was ein binärer Beziehungstyp auf extensionaler Ebene bedeutet wird grafisch in
Abb. 1.18 dargestellt. Hier geht es um den Beziehungstyp „arbeitet in“ zwischen
B
Seite 36
Studienbrief 1 Grundlagen der Modellierung und das ER-Modell
den Entity-Typen „Mitarbeiter“ und „Abteilung“. In der Abbildung ist wieder die
Intension (oben) und die Extension (unten) getrennt dargestellt. Die Mitarbeitermenge ist links unten dargestellt. Sie besteht abstrakt aus den Entities e1 , e2 , . . .,
während die Menge der Abteilungen d1 , d2 , . . . rechts dargestellt ist. Die Beziehungen sind in der Mitte dargestellt. Sie verbinden jeweils einen Mitarbeiter mit einer
Abteilung. Jede Beziehung (w1 bis w7 ) ist eine Instanz des Beziehungstyps. Sie setzt
jeweils genau zwei Entities in Beziehung. Beziehungsinstanz w1 setzt beispielsweise
das Mitarbeiter-Entity e1 mit dem Abteilungs-Entity d3 in Beziehung.
Abb. 1.18: Relationships:
Intension und Extension
Mitarbeiter
arbeitet_in
Mitarbeiter
arbeitet_in
Abteilung
w1
w2
w3
w4
w5
w6
w7
...
e1
e2
e3
e4
e5
e6
e7
...
Abteilung
d1
d2
d3
...
Darstellung als Tabelle
Eine Beziehungsmenge lässt sich auch als Tabelle darstellen. Für jeden beteiligten
Entity-Typ ist eine Spalte vorgesehen und für jede Beziehungsinstanz eine Zeile.
Hierbei ist wichtig zu beachten, dass es nicht mehrere Beziehungsinstanzen eines
Beziehungstyps mit denselben Entities geben kann. Tabelle 1.1 bezieht sich auf
Abb. 1.18, in der die Beziehung von Mitarbeitern zur Abteilung dargestellt wird. Es
kann nicht vorkommen, dass der Eintrag (Sally, konzMod) zweimal in der Tabelle
vorkommt.
Tabelle 1.1: Darstellung einer Beziehungsmenge als Tabelle
Student
Sally
Sally
Joe
Vorlesung
konzMod
Programmierung 1
Programmierung 1
Bisher haben wir immer Beispiele kennengelernt, in der die Modellierung mehr
oder weniger sinnvoll war. Man kann aber auch leicht Fehler bei der Modellierung
machen, also ER-Diagramme zeichnen, die ungenau oder ungenügend die Welt
abbilden. Ein Beispiel ist in Abb.1.19 zu sehen. Dort ist die Beziehung von einem
Arzt zu seinen Patienten dargestellt. Mit dem Attribut „Datum“ der Beziehung
„untersucht“ soll vermutlich modelliert werden, dass ein Arzt einen Patienten an
einem bestimmten Datum untersucht (hat). Allerdings ist die Darstellung noch
nicht optimal, da ein Arzt einen Patienten mehrfach untersuchen kann. In der
Abbildung wird hingegen folgendes beschrieben: Die Beziehung „untersucht“
besteht zwischen Arzt und Patient oder sie besteht nicht; wenn sie besteht, dann
hat sie ein Datum.
Abb. 1.19: Darstellung
einer falschen Beziehung
Arzt
untersucht
CH!
FALS
Datum
Patient
1.4 Das Entity-Relationship-Modell
Kontrollaufgabe 1.10: Modellierungsalternativen beim Beziehungstyp
Seite 37
K
Wie kann man die Darstellung aus Abb. 1.19 verbessern, damit das Modell auch ausdrücken kann, dass ein Arzt einen Patienten an mehreren
verschiedenen Terminen untersucht hat?
Exkurs 1.2: Sprachphilosophie
Zitat aus einer Mail von Prof. Wedekind (zitiert nach Lenz [2012]:
Flektieren und Passivbildung sind zur Formalisierung von Konzepten verboten, aus Gründen der Einfachheit und Sprachökonomie. Ockhams Rasiermesser lässt grüßen. Und man sollte sich
von natürlichen Sprachen nicht gängeln lassen. Die sind nämlich
ein unendlicher Ozean. [. . . ]
Unter Subjekt-Arten finden Sie den Begriff „logisches Subjekt“.
Die Subjektart erklärt man über eine (logisch verbotene) Passivbildung. In „Kabine wird von Kunde gebucht“ ist „Kabine“ (im
Nominativ stehend) das grammatische Subjekt und „Kunde“
das grammatische Objekt. Das logische Subjekt ist und bleibt
„Kunde“, weil die Logik die Passivbildung nicht mitmacht. Das
logische Subjekt, oder, anders gesprochen, das Agens, ist und
bleibt das Wort „Kunde“. Das haben rationale, logikbasierte
Sprachen so an sich. Sie haben ihren Sitz im Handeln.
Wenn ich „buchen“, wie die ER-Technik das tut, als simple Relation in einer reinen Dingwelt als „Relationship“ rekonstruiere,
dann geht das logische Subjekt, das Agens, verloren.
Als Satz schreibt man logisch auch in einer anderen Form, der
Kopula (ε)-Form:
Kunde, Kabine ε buchen
Das Agens ist semantisch weg. Und das ist aus objekt-orientierter
Sicht unzulässig und auch für praktische Bedürfnisse falsch [. . . ].
Der Kunde tut was und das ist zu programmieren, d.h. in die
Praxis zu bringen.
„Kunde bucht Kabine“ wird als Fakt bezeichnet. Fakten konstituieren ein Faktmodell [. . . ]. Das ist etwas anders als ein ER-Modell
und steht als Kompression einer langseitigen Anforderungsbeschreibung (requirement definition) an zweiter Stelle einer
Gesamtmethodologie. Man sollte aber erst mal ein Faktenmodell aufstellen, ohne dabei schon an Klassen und Methoden zu
denken. Denn bis dahin, das heißt, hin zum Vorhof der Programmierung, ist noch ein weiter Weg. [. . . ]
PS: Platon sagt: Es gibt „actio“ und „res“. ER-Diagramme kennen
nur „res“. „actio“ wird unterdrückt. Das kann man machen. Die
Einschränkung ist aber enorm.
E
Seite 38
Studienbrief 1 Grundlagen der Modellierung und das ER-Modell
Grade von Beziehungen
Grad eines Beziehungstyps
Der Grad eines Beziehungstyps beziffert die Menge der Entity-Typen, die die Beziehung verbindet. So hat z.B. der in Abb. 1.18 dargestellte Beziehungstyp „arbeitet
in“ den Grad 2, da sie zu zwei Objekten eine Beziehung hat. Einen Beziehungstyp
vom Grad 2 nennt man „binären Beziehungstyp“ und einen Beziehungstyp vom
Grad 3 nennt man „ternären Beziehungstyp“.
Einige Beispiele sind in Abb. 1.20 wiedergegeben. Teil a und b von Abb. 1.20
stellen beides ternäre Beziehungstypen dar. Teil b ist dabei eine Verbesserung der
oben als suboptimal klassifizierten Darstellung mit einem Attribut „Datum“ der
Beziehung „untersucht“. Teil c der Abbildung stellt die Extension eines ternären
Beziehungstyps aus Teil a der Abbildung nochmal grafisch dar. Man sieht, dass jede
Beziehungsinstanz genau drei Entities der beteiligten Entity-Typen in Beziehung
setzt.
Abb. 1.20: Beziehungstypen vom Grad 3
Beispiel:
a)
b)
Projekt
Lieferant
Patient
Lieferung
Arzt
untersucht
Teil
Untersuchung
c)
Lieferant
Lieferung
s1
s2
s3
s4
s5
s6
s7
...
r1
r2
r3
...
Teil
p11
p22
...
Projekt
j111
j222
j333
...
Rekursive Bezieungstypen
rekursive Beziehungstypen
In einem ER-Diagramm kann es auch rekursive Beziehungstypen geben. Dies
ist der Fall, wenn ein Entity-Typ mit sich selbst in Beziehung steht. Ein Beispiel
für einen solchen Beziehungstyp ist „ist Vorgesetzter von“, in dem der Entity-Typ
Mitarbeiter doppelt vorkommt. Was damit modelliert wird ist die Tatsache, dass
ein Mitarbeiter der Vorgesetzte eines anderen Mitarbeiters sein kann.
Abb. 1.21: Rekursiver Beziehungstyp
Mitarbeiter
Chef_von
Mitarbeiter
Vorgesetzter
Untergebener
Chef_von
Rollenname
e1
e2
e3
e4
e5
e6
e7
...
2
1
2
1
2
2
1
1
2
2
1
1
s1
s2
s3
s4
s5
s6
...
Um die Kardinalitäten bei rekursiven Beziehungstypen eindeutig definieren zu
können, versieht man die verschiedenen Vorkommen eines Entity-Typs jeweils mit
einem Rollennamen. In unserem Beispiel wird die eine ausgehende Kante des
rekursiven Beziehungstyps mit dem Rollennamen „Vorgesetzter“ und die andere
Kante mit dem Rollennamen „Untergebener“ beschriftet (siehe Abb. 1.21 links).
Wenn nun an der Kante „Vorgesetzter“ eine 1 steht, ist klar erkennbar, dass ein
1.4 Das Entity-Relationship-Modell
Seite 39
Mitarbeiter höchstens einen Vorgesetzten haben kann. Ohne die Rollennamen
wäre das nicht eindeutig.
Abb. 1.21 (rechts) verdeutlicht nochmal die Extension dieses Beziehungstyps. In
der Grafik kann man nochmal deutlich sehen, dass es sich um einen binären
Beziehungstyp handelt, denn jede Beziehungsinstanz verbindet genau zwei Entities
miteinander. Der Einfachheit halber wurden die beiden Rollen-Namen dabei mit
den Ziffern 1 und 2 abgekürzt.
Kardinalitäten
Abhängig von der Menge der zugeordneten Entities unterscheidet man Beziehungstypen unterschiedlicher Kardinalitäten. Die wichtigsten dieser Typen sind
in Abb. 1.22 dargestellt.
Abb. 1.22: Kardinalität
von Beziehungstypen
N:M
N:1
1:1
Die allgemeinste Form ist die N : M-Beziehung (Abb. 1.22, links). Eine solche
Beziehung modelliert, dass ein Entity des einen Entity-Typs mit beliebig vielen
Entities des anderen Entity-Typs in Beziehung stehen kann und umgekehrt.
Beispiel 1.7: N : M-Beziehung
B
Ein Beispiel für eine N : M-Beziehung ist die Beziehung „arbeitet in“ zwischen Mitarbeitern und Projekten (siehe Abb. 1.13): Ein Mitarbeiter kann in
vielen Projekten arbeiten, und in einem Projekt arbeiten viele Mitarbeiter.
Manchmal möchte man die Kardinalität der Beziehung einschränken. Zwei Spezialfälle sind die N : 1- und die 1 : 1-Beziehungen. In einer N : 1-Beziehung besteht
dann, wenn ein Entity des ersten Typs nur mit höchstens einem Entity des zweiten
Typs in Beziehung stehen darf, ein Entity des zweiten Typs aber mit vielen Entities
des zweiten Typs (Abb. 1.22, mitte).
Beispiel 1.8: N : 1-Beziehung
Ein Beispiel für eine N : 1-Beziehung aus Abb. 1.13 ist die Beziehung „arbeitet
in“ zwischen Mitarbeitern und Abteilungen: Ein Mitarbeiter arbeitet in
höchstens einer Abteilung, allerdings sind einer Abteilung beliebig viele
Mitarbeiter zugeordnet.
Eine 1 : 1-Beziehung liegt schließlich vor, wenn ein Entity des ersten Typs mit
höchstens einem Entity des zweiten Typs in Beziehung steht und umgekehrt ge-
B
Seite 40
Studienbrief 1 Grundlagen der Modellierung und das ER-Modell
nauso ein Entity des zweiten Typs mit höchstens einem Entity des zweiten Typs in
Verbindung steht.
Beispiel 1.9: 1 : 1-Beziehung
B
Ein Beispiel für eine 1 : 1-Beziehung ist „leitet“ zwischen Mitarbeitern und
Abteilungen: Ein Mitarbeiter kann höchstens eine Abteilung leiten, und eine
Abteilung wird von höchstens einem Mitarbeiter geleitet.
funktionale Abhängigkeit
Die Darstellung in Abb. 1.22 entspricht nicht unserer üblichen ER-Notation, weil
sie verdeutlichen soll, dass durch die Spezifikation von Kardinalitäten in erster
Linie funktionale Abhängigkeiten spezifiziert werden. Ein Pfeil symbolisiert eine
funktionale Abhängigkeit: Der erste Typ bestimmt dann vollständig den zweiten
Typ. Bei N : M-Beziehungen gibt es keine Einschränkungen, also auch keine funktionalen Abhängigkeiten. Bei einer N : 1-Beziehung ist der zweite Typ funktional
abhängig vom ersten Typ. Bei 1 : 1-Beziehungen hat man die funktionale Abhängigkeit in beiden Richtungen: Wenn man ein Entity des ersten Typs hat, dann ist
das Entity des zweiten Typs vollständig bestimmt; umgekehrt ist auch bei Angabe
des Entities des zweiten Typs der Entity des ersten Typs genau bestimmt.
Abb. 1.23: Chen-Notation
für Kardinalitäten bei
binären Beziehungstypen
0122
345647518489
78 0781547845 8428
Chen-Notation
547848972 51
8472
442 46545128182
In der von uns verwendeten Notation wird zur Darstellung der Kardinalitäten
üblicherweise die sogenannte Chen-Notation [Balzert, 2009] verwendet. Abb. 1.23
zeigt die eben (mit Pfeilen) vorgestellten Beziehungstypen nochmal in anderer
Form. Eine „1“ bei einem Entity-Typ bedeutet, dass Entities dieses Typs funktional
durch die Entities des anderen Beziehungstyps bestimmt werden, etwa so wie in
Abb. 1.23. Die dort dargestellten drei Beziehungstypen enthalten folgende drei
funktionale Abhängigkeiten:
• Mann „bestimmt“ Frau (in der Beziehung „verheiratet mit“). Ein Mann ist
also mit höchstens einer Frau verheiratet.
• Frau „bestimmt“ Mann (in der Beziehung „verheiratet mit“). Eine Frau ist
also mit höchstens einem Mann verheiratet.
• Mitarbeiter „bestimmt“ Abteilung (in der Beziehung „arbeitet in“). Ein
Mitarbeiter arbeitet also in höchstens einer Abteilung.
Integritätsbedingung
Die Kardinalitätsangaben können natürlich auch bei Beziehungstypen höheren
Grades gemacht werden. Ein Beispiel für eine ternäre Beziehung zeigt Abb. 1.24.
1.4 Das Entity-Relationship-Modell
Seite 41
Abb. 1.24: Chen-Notation
für Kardinalitäten bei ternären Beziehungstypen
012324567
427
21
012324869
Dieser Beziehungstyp drückt aus, dass ein Lieferant verschiedene Teile für verschiedene Projekte liefern kann. Allerdings existiert auch hier eine funktionale
Abhängigkeit: Die Kardinalität 1 an der Kante zum Lieferanten bedeutet nämlich,
dass das Projekt und das Bauteil den Lieferanten eindeutig bestimmen. Pro Projekt
und Bauteil gibt es höchstens einen Lieferanten. Das Paar Projekt und Bauteil
„bestimmt“ den Lieferanten. Funktionale Abhängigkeiten beschreiben Integritätsbedingungen, also Bedingungen auf dem Modell, die durch die Datenbank
überprüft und eingehalten werden sollen.
Kontrollaufgabe 1.11: Kardinalitäten und funktionale Abhängigkeiten
Betrachten Sie die Entity-Typen „Mitarbeiter“, „Projekt“ und „Ort“ und den
ternären Beziehungstyp „arbeitet in“, der die drei Entity-Typen miteinander
in Beziehung setzt. Zeichnen Sie das ER-Diagramm für die „arbeitet in“Beziehung und geben Sie jeweils die Kardinalitäten an, so dass die folgenden
Bedingungen modelliert werden:
• Ein Mitarbeiter arbeitet pro Projekt immer nur an höchstens einem
Ort.
• Mitarbeiter können an verschiedenen Orten arbeiten.
• Ein Mitarbeiter darf an einem Ort nur in höchstens einem Projekt
arbeiten.
• Mitarbeiter können in verschiedenen Projekten arbeiten.
Welche funktionalen Abhängigkeiten haben Sie hierdurch festgelegt?
Totale Teilnahme
Bei der Chen-Notation ist darauf zu achten, dass jedes Entity eines Entity-Typs,
das über eine doppelte Linie an den Beziehungstyp geknüpft ist, an mindestens
einer Beziehungsinstanz dieses Typs teilnehmen muss. Dies nennt man totale
Teilnahme. Abb. 1.25 zeigt ein Beispiel für totale Teilnahme. Die doppelten Kanten
sind wie folgt zu lesen: Jeder Mitarbeiter arbeitet in mindestens einer Abteilung,
und jede Abteilung hat mindestens einen Mitarbeiter. Zusammen mit der Kardinalität 1 an der Kante zur Abteilung bedeutet dies: Jeder Mitarbeiter arbeitet in
mindestens und höchstens einer Abteilung; also arbeitet jeder Mitarbeiter in genau
einer Abteilung.
K
Seite 42
Studienbrief 1 Grundlagen der Modellierung und das ER-Modell
Abb. 1.25: Chen-Notation
und (min, max)-Notation
a)
Mitarbeiter
N
Arbeitet_in
1
Abteilung
b)
Mitarbeiter
(1,1)
Arbeitet_in
(2,N)
Abteilung
(min,max)-Notation
Mit der bisherigen Notation kann man noch nicht ausdrücken, dass eine Abteilung mindestens zwei Mitarbeiter haben muss. Dies kann durch die sogenannte
(min,max)-Notation dargestellt werden. Die Beschriftung mit zwei Werten (x, y)
an einer Kante gibt an, dass jedes Entity dieses Entity-Typs an mindestens x und
höchstens an y Beziehungsinstanzen teilnimmt.
Abb. 1.25 verdeutlicht dies nochmal anhand eines Beispiels. Hier wird folgendes ausgedrückt: Jeder Mitarbeiter arbeitet in genau einer Abteilung, und jede
Abteilung hat mindestens zwei Mitarbeiter. Hier sehen wir, dass die (min,max)Notation in diesem Fall mächtiger ist als die Chen-Notation. Man kann mit ihr also
Restriktionen ausdrücken, die in der Chen-Notation nicht darstellbar wären.
Die (min,max)-Notation kann auch für mehrstellige Beziehungstypen verwendet
werden. Abb. 1.26 (c) zeigt ein Beispiel. Die einzelnen Angaben an den Kanten
sind wie folgt zu lesen:
• Ein Lieferant liefert 0 bis beliebig viele Lieferungen.
• Ein Projekt erhält 0 bis beliebig viele Lieferungen.
• Ein Teil wird 0 bis beliebig oft geliefert.
Dass ein Teil je Projekt immer vom gleichen Lieferanten kommen muss, kann
jedoch in der (min,max)-Notation nicht dargestellt werden. Hier ist die ChenNotation mächtiger. Beide Notationen haben also ihre Daseinsberechtigung. Die
Chen-Notation eignet sich besser zur Darstellung funktionaler Abhängigkeiten.
Abb. 1.26: (min,
max)-Notation
a)
Mitarbeiter
N
Arbeitet_in
1
Abteilung
b)
Mitarbeiter
(1,1)
Arbeitet_in
c)
(2,N)
(0,N)
Lieferant
(0,N)
Abteilung
Projekt
Lieferung
(0,N)
Teil
1.4 Das Entity-Relationship-Modell
Seite 43
Kontrollaufgabe 1.12: (min, max)-Notation vs. Chen-Notation bei dreistelligen Beziehungstypen
K
Formulieren Sie die Kardinalitäten des in der unten stehenden Abbildung dargestellten dreistelligen Beziehungstyps „betreuen“ in (min,max)Notation. Begründen Sie, inwiefern die Semantik beider Darstellungen äquivalent ist!
Seminarthema
1
Student
N
betreuen
1
Universitätsangestellter
1.4.5 Schwache Entity-Typen
Bisher haben wir von Entities gefordert, dass sie eine eigenständige Existenz besitzen und identifizierbar sind. Schwache Entities sind zwar auch identifizierbar,
hängen in ihrer Existenz aber von anderen (starken) Entities ab.
Abb. 1.27: Schwache
Entity-Typen und identifizierende Beziehungen
a)
Schlüssel
Mitarbeiter
b)
1
hat
Arzt
untersucht
Patient
N
Angehörige
Untersuchung
Partieller Schlüssel
Datum
Betrachten wir ein Beispiel für einen schwachen Entity-Typ in Abb. 1.27 (a). Ein
Mitarbeiter kann beliebig viele Angehörige haben, aber ein Angehöriger ist höchstens einem Mitarbeiter zugeordnet. Der Entity-Typ „Angehörige“ ist ein schwacher
Entity-Typ und wird deshalb durch einen Doppelrahmen gekennzeichnet. Intuitiv
bedeutet dies, dass ein Angehöriger ohne den zugeordneten Mitarbeiter uninteressant ist und nicht gespeichert werden muss.
Schwache Entities besitzen keine Schlüsselattribute. Um sie zu identifizieren, verwenden wir so genannte identifizierende Beziehungstypen. Wir verbinden also
einen schwachen Entity-Typ mit einem starken Entity-Typ. Dies wird durch eine
Raute mit doppelter Umrandung dargestellt (siehe Abb. 1.27, a). Schwache EntityTypen müssen immer mit Kardinalität 1 an den starken Entity-Typ verbunden
werden, denn der starke Entity-Typ wird benutzt, um den schwachen Entity-Typ
zu identifizieren. Da im Beispiel jeder Angehörige genau genau einem Mitarbei-
identifizierender Beziehungstyp
Seite 44
Studienbrief 1 Grundlagen der Modellierung und das ER-Modell
ter zugeordnet ist, kann man den Schlüssel des Mitarbeiters verwenden, um die
Angehörigen zu identifizieren.
Merksatz 1.4: Schwache Entity-Typen
M
Ein schwacher Entity-Typ hat immer eine totale Teilnahme an einem identifizierenden Beziehungstyp.
partielles Schlüsselattribut
Nun kann ein Mitarbeiter im vorgenannten Beispiel mehrere Angehörige haben,
die man auch unterscheiden (identifizieren) können muss. Hierfür verwendet man
ein partielles Schlüsselattribut im schwachen Entity-Typen.
Schwache Entity-Typen können auch durch mehrere starke Entity-Typen identifiziert werden. Ein Beispiel ist in Abb. 1.27 (b) zu sehen. Dort ist die „Untersuchung“
als schwacher Entity-Typ modelliert. Eine Untersuchung kann es nur geben, wenn
es den Arzt und den Patienten gibt. Die Kombination beider bestimmt den EntityTyp „Untersuchung“. Das Attribut „Datum“ ist ein partieller Schlüssel, über den
mehrere Untersuchungen eines Arztes an dem gleichen Patienten unterschieden
werden können. Zur eindeutigen Identifikation einer Untersuchung braucht man
also einen Arzt, einen Patienten und ein Datum.
K
Kontrollaufgabe 1.13: Zusammenfassung ER-Modell
Machen Sie sich nochmals selbständig mit den Modellierungselementen
des ER-Modells vertraut: Mit Hilfe welcher Konstrukte können Objekte der
Miniwelt und deren Beziehungen abgebildet werden? Gehen Sie hierbei
auch auf die Begriffe „Intension“, „Extension“, „Typ“ und „Instanz“ ein!
1.5 Fragestellungen beim Entwurf
Wir haben nun alle wesentlichen Modellierungsinstrumente kennen gelernt und
auch gesehen, dass man ein und denselben Sachverhalt auf ganz unterschiedliche Arten modellieren kann. Die Frage ist also, wie man unter den Alternativen
möglichst gute Modelle auswählt.
1.5.1 Wozu braucht man schwache Entity-Typen?
Eine Frage lautet: Wann braucht man überhaupt schwache Entity-Typen? Man
könnte schließlich auch einen schwachen Entity-Typ als komplexes Attribut darstellen. Dies geht allerdings nicht, wenn mehrere identifizierende Entity-Typen
im Spiel sind und wenn der schwache Entity-Typ mit weiteren Entity-Typen in
Beziehung steht. Dies ist in Abb. 1.28 dargestellt.
Abb. 1.28: Schwacher Entity-Typ steht
mit weiteren EntityTypen in Beziehung
Gebäude-Nr
Gebäude
Raum-Nr
1
liegt_in
N
Raum
1
Veranstaltung
N
läuft_in
1.5 Fragestellungen beim Entwurf
Seite 45
In dem Beispiel sind die Entity-Typen „Gebäude“, „Raum“ und „Veranstaltung“
mit den Beziehungen „liegt in“ und „läuft in“ verknüpft. Die Räume sind als
schwache Entities modelliert, d.h. zur Identifizierung eines Raumes benötigen wir
die Gebäudenummer (Schlüssel-Attribut des zugeordneten starken Entity-Typen)
und die Raumnummer (partielles Schlüssel-Attribut des schwachen Entity-Typen).
Zusätzlich werden Veranstaltungen verwaltet, die Räumen zugeordnet wären.
Hätte man den Raum als komplexes Attribut modelliert, wäre diese Zuordnung
nicht möglich gewesen, denn schließlich kann man mit dem Beziehungstyp „läuft
in“ nur Entity-Typen verknüpfen.
1.5.2 Wozu braucht man ternäre Beziehungstypen?
Eine andere Frage lautet: Wann verwendet man Beziehungstypen mit Grad größer 2, also beispielsweise ternäre Beziehungstypen? Um diese Frage zu erörtern,
betrachten wir die ER-Diagramme in Abb. 1.29. Dort ist die Miniwelt einer Fossiliensammlung in verschiedenen Arten modelliert worden: Die Entity-Typen „Fossil“,
„Spezies“ und „Entdecker“ sollen sinnvoll durch Beziehungen verknüpft werden.
Abb. 1.29:
Entwurfsalternativen
a)
Fossil
Fund
Spezies
Fossil Spezies Entdecker
Entdecker
b)
Spezies
Gehört_zu
Fossil
von
Entdecker
Eine (erste) Möglichkeit ist in Abb. 1.29 (a) dargestellt. Dort ist ein ternärer Beziehungstyp „Fund“ eingeführt worden, der ein Fossil mit einer Spezies und einem
Entdecker verbindet. Wenn wir das so modellieren, haben wir jedoch das Problem,
dass man jede Instanz mit einem Entity der drei Entity-Typen verbinden muss.
Wenn beispielsweise ein Entdecker ein Fossil findet, dessen Spezies noch unbekannt ist, kann man den Fund noch nicht richtig eintragen. Beachten Sie bitte, dass
es hier keine NULL-Werte geben kann, denn NULL-Werte gibt es im ER-Modell nur
für Attribute. Eine ternäre Beziehung setzt also immer exakt genau drei Entities
zueinander in Beziehung.
Welche Alternativen gibt es? Man könnte beispielsweise zwei binäre Beziehungstypen verwenden. Dieser Ansatz ist in Abb. 1.29 (b) dargestellt. Dort sind die drei
Entity-Typen mit zwei binären Beziehungstypen „gehört zu“ und „von“ verknüpft.
Bei der binären Darstellung kann die Fossil/Entdecker-Beziehung eingetragen
und die Fossil/Spezies-Beziehung später nachgetragen werden.
Seite 46
Studienbrief 1 Grundlagen der Modellierung und das ER-Modell
Es gibt auch noch den Fall der Darstellung, in dem gar kein Beziehungstyp nötig ist.
Für den Fall, dass z.B „Spezies“ und „Entdecker“ nicht weiter detailliert werden
sollen, ist kein Beziehungstyp in der Darstellung nötig (siehe Abb. 1.30). Sobald
man aber die Spezies oder den Entdecker als eigenständige Objekte darstellen
oder mit anderen Entity-Typen in Beziehung setzen will, ist die Darstellung ohne
Beziehungstypen nicht sinnvoll, denn hier existiert eine Spezies nur, wenn es ein
Fossil gibt.
Abb. 1.30: Modelllierung
ohne Beziehungstyp
Name
Spezies
Fossil
Entdecker
Braucht man ternäre Beziehungstypen überhaupt?
Nachdem wir oben gesehen haben, dass ternäre Beziehungstypen in manchen
Fällen ungünstig sind, kann man die Frage stellen, ob man nicht jeden ternären
Beziehungstyp in eine Menge von binären Beziehungstypen umwandeln kann.
Wenn dies so wäre, dann bräuchte man im Prinzip gar keine Beziehungstypen
mit Grad größer als 2 anzubieten. Manche Modellierungswerkzeuge erlauben
beispielsweise nur binäre Beziehungstypen. Ist man in diesen Werkzeugen in
irgend einer Weise eingeschränkt in dem, was man modellieren kann?
Betrachten wir dazu den ternären Beziehungstyp in Abb. 1.31 (links). Dort sind
die Entity-Typen „Projekt“, „Teil“ und „Lieferant“ durch den Beziehungstyp „Lieferung“ verknüpft. Auf der rechten Seite ist der Versuch abgebildet, den ternären
Beziehungstyp durch drei binäre Beziehungstypen nachzubilden. Sind beide Darstellungen äquivalent?
Abb. 1.31: Modellierungstypen sind
nicht äquivalent
Lieferant
Projekt
beliefert
Projekt
Lieferung
Lieferant
braucht
Teil
hat
Teil
Wie wir bereits oben gesehen haben, können wir in dem rechten Modell mit ausschließlich binären Beziehungstypen darstellen, dass ein Teil von einem Lieferanten
kommt auch wenn es gar nicht von einem Projekt bezogen wird. Das geht mit
dem ternären Beziehungstyp nicht. Die Frage ist nun: Steckt im linken Modell
mit dem ternären Beziehungstyp auch eine Information, die im rechten Modell
nicht abgebildet werden kann? Tatsächlich ist das der Fall: Nehmen wir an, es gibt
zwei Lieferanten L1 und L2 die beide die gleichen Teile A und B liefern. Beide
Lieferanten beliefern die zwei gleichen Projekte P und Q. Im rechten Modell ist
nicht darstellbar, welcher Lieferant welches Teil an ein bestimmtes Projekt liefert.
Will man das also darstellen, braucht man den ternären Beziehungstyp. Will man
nun gleichzeitig auch darstellen können, dass ein Teil prinzipiell von einem Lieferanten lieferbar ist, ohne ein Projekt angeben zu müssen, dann braucht man einen
zusätzlichen binären Beziehungstyp. Ein weiterer Unterschied wird deutlich, wenn
Kardinalitäten ins Spiel kommen.
1.5 Fragestellungen beim Entwurf
Seite 47
Betrachten Sie Abb. 1.32. Dort sind im gleichen Szenario wie zuvor Kardinalitäten
in der Chen-Notation eingetragen. Hier wird der mittlerweile bekannte Sachverhalt
modelliert, dass ein bestimmtes Teil in einem Projekt immer vom gleichen Lieferanten kommt. Es besteht also eine funktionale Abhängigkeit zwischen Projekt,
Teil und Lieferanten, die von unserem Datenbanksystem überwacht werden soll.
Abb. 1.32: Ternärer Beziehungstyp mit funktionaler Abhängigkeit
Projekt
M
Lieferant
1
Lieferung
N
Teil
Kann man diese Bedeutung noch nachmodellieren mit binären Beziehungstypen
und ohne zusätzliche Entity-Typen? Die Antwort lautet nein, denn in der Modellierung aus Abb. 1.31 (rechts) kann man diese funktionale Abhängigkeit nicht
nachbilden, egal wo man mittels der Chen-Notation die Einsen setzt.
Helfen schwache Entity-Typen weiter?
Bisher haben wir in unseren Bemühungen, alle Beziehungen auf binäre Beziehungstypen zurückzuführen, keine zusätzlichen Entity-Typen verwendet. Man
könnte auch überlegen, einen schwachen Entity-Typ zu verwenden, um ternäre
Beziehungstypen darzustellen. Abb. 1.33 zeigt das Beispiel von eben, bei dem der
ternäre Beziehungstyp „Lieferung“ durch einen schwachen Entity-Typ gleichen
Namens ersetzt wurde, der über drei identifizierende Beziehungstypen mit den
anderen Entity-Typen verbunden ist. Beachten Sie, dass alle Beziehungstypen in
diesem Beispiel binär sind.
Projekt
Lieferant
Lieferung
Teil
Lieferant
Lieferung
Projekt
Teil
Abb. 1.33 modelliert folgenden Sachverhalt: Jede Lieferung ist mit einem Lieferanten, einem Projekt und einem Teil verbunden (totale Teilnahme). In diesem Beispiel
Abb. 1.33: Nachbildung
ternärer durch binäre
Beziehungstypen
Seite 48
Studienbrief 1 Grundlagen der Modellierung und das ER-Modell
hat „Lieferung“ keinen partiellen Schlüssel. Eine Lieferung wird also vollständig
durch einen Lieferanten, ein Projekt und ein Teil identifiziert. Die Frage ist nun,
wie man die Kardinalitäten an die Kanten schreiben muss, um die Situation aus
Abb. 1.32 auszudrücken?
Ein Versuch, diese Aufgabe zu lösen, ist in Abb. 1.34 dargestellt. Beachten Sie, dass
der Beziehungstyp zwischen Lieferung und Lieferant nicht mehr identifizierend
ist. Die Lieferung wird jetzt nur noch durch die Beziehungstypen zu Projekt und
Teil bestimmt, nicht mehr durch den Lieferanten. Zusätzlich ist jede Lieferung
genau einem Lieferanten zugeordnet. Also haben wir die Aufgabe in diesem Fall
tatsächlich gelöst!
Abb. 1.34: Nachbildung ternärer duch
binäre Beziehungstypen: Erster Versuch
Geht das aber in jedem Fall? Betrachten Sie dazu Abb. 1.35. Dort ist ein leicht
verändertes Szenario abgebildet, das nicht mehr dargestellt werden kann. Dort
wurde der ternäre Beziehungstyp durch die Angabe einer zusätzlichen Kardinalität
modifiziert. Nun bestimmt nicht mehr nur das Projekt und die Lieferung eindeutig
den Lieferanten, sondern der Lieferant in Verbindung mit einem Teil bestimmt das
Projekt. Ob dies eine sinnvolle Bedingung ist, sei dahingestellt, aber man kann sie
beschreiben.
Abb. 1.35: Nachbildung ternärer duch
binäre Beziehungstypen: Zweiter Versuch
Möchte man diese Situation mit binären Beziehungstypen darstellen und versucht
man denselben Ansatz wie oben (also mit schwachen Entity-Typen), dann läuft
man in ein Dilemma. Betrachten Sie dazu nochmal Abb. 1.35: Die Darstellung
1.6 Zusammenfassung
Seite 49
unten entspricht leider nicht der Darstellung oben, weil der Beziehungstyp zwischen Lieferung und Projekt noch identifizierend ist. Die Lieferung (und somit
der Lieferant) wird wie oben beschrieben durch das Projekt und das Teil eindeutig bestimmt. Hingegen bestimmt die Kombination aus Lieferant und Teil nicht
eindeutig das Projekt. Dies ist aber im Diagramm oben gefordert. Die funktionale
Abhängigkeit hinsichtlich des Projekts geht also verloren.
Abb. 1.36: Nachbildung
ternärer duch binäre
Beziehungstypen: Dritter
Versuch
Alternativ könnte man natürlich auf die Idee kommen, das Diagramm wie in
Abb. 1.36 zu zeichnen. Hier ist der Beziehungstyp zwischen Lieferant und Lieferung wieder identifizierend, hingegen ist der Beziehungstyp zwischen Lieferung
und Projekt nicht identifizierend. Man kann nun zwar die funktionale Abhängigkeit von Lieferant und Teil zu Projekt beschreiben, nicht aber die im oberen
Diagramm geforderte Abhängigkeit von Projekt, Teil zu Lieferant. Aus diesem
Dilemma gibt es kein Entrinnen, weil man sich bei Angabe eines Beziehungstyps
entscheiden muss, ob er identifizierend ist oder nicht.
Es gibt also Situationen, in denen ternäre Beziehungstypen mächtiger sind als eine
Menge binärer Beziehungstypen.
1.6 Zusammenfassung
Im vorausgegangenen Abschnitt haben wir das Entity-Relationship-Modell kennengelernt (ER-Modell). Das ER-Modell ist das am weitesten verbreitete semantische
Datenmodell. Es wird dazu benötigt, um die „Miniwelt“, die wir in unserer Datenbank beschreiben wollen, zu beschreiben, ohne gleich die Implementierung der
Datenbank vorweg zu nehmen. Zielvorgabe des Modells war es, eine möglichst
einfache Sprache zu haben, die auch ein Anwender versteht, und es gleichzeitig erlaubt, die wichtigsten Dinge im Modell möglichst präzise und unmissverständlich
zu beschreiben.
Als wesentliche Modellierungsprimitive hatten wir Entity-Typen und RelationshipTypen (Beziehungstypen) kennengelernt. Ein Entity ist irgendetwas, was Sie in der
Datenbank ablegen wollen, und ein Entity-Typ ist eine Beschreibung gleichartiger
Entities. Entity-Typen besitzen beschreibende Merkmale, genannt Attribute. Eine
besondere Art von Attributen sind die sogenannten Schlüsselattribute, die es
erlauben, ein Entity eines Entity-Typs eindeutig zu identifizieren.
Entities werden über Beziehungstypen verknüpft, die auch für sich noch Attribute
haben können. Beziehungstypen kann man noch genauer präzisieren, in dem man
an die Kanten Kardinalitäten schreibt. Hierfür haben wir verschiedene Notationen
Seite 50
Studienbrief 1 Grundlagen der Modellierung und das ER-Modell
und ihre jeweiligen Vor- und Nachteile kennengelernt. Mittels der Chen-Notation
beispielsweise kann man funktionale Abhängigkeiten festlegen (durch Angabe
einer 1 an der Zielkante). Andere Arten von Kanten in der Chen-Notation bezeichnen die totale Teilnahme eines Entity-Typs, d.h. jedes Entity dieses Typs nimmt an
mindestens einer Beziehung teil. In der (min,max)-Notation hingegen kann man
festlegen, an wie vielen Beziehungen dieses Typs ein Entity mindestens teilnimmt
und an wie vielen Beziehungen es höchstens teilnimmt.
Ein wichtiger Unterschied bei der Modellierung ist der zwischen Intension und
Extension. Intension ist die abstrakte Beschreibung des Modells, die sich selten
ändert. Die Extension ist die Menge der konkreten Ausprägungen, die sich über
die Zeit ändern kann.
Wenn zwei Entity-Typen mit einer Beziehung verknüpft werden, spricht man von
einem binären Beziehungstyp. Man kann aber auch beliebig viele Entity-Typen
verknüpfen. Die Anzahl der verknüpften Entity-Typen nennt man den Grad des
Beziehungstyps. Ternäre Beziehungstypen haben den Grad 3. Auch bei Beziehungstypen mit Grad größer als 2 kann man mittels der Chen-Notation funktionale
Abhängigkeiten modellieren.
Der Vergleich von Chen-Notation mit der (min,max)-Notation hat ergeben, dass
beide Notationen nicht ineinander überführt werden können, denn einerseits gibt
es Szenarien, die man mit der Chen-Notation beschreiben kann, nicht aber mit der
(min,max)-Notation. Andererseits gibt es aber auch Sachverhalte, die man in der
(min,max)-Notation beschreiben kann, nicht aber mit der Chen-Notation.
Schließlich haben wir noch schwache Entity-Typen kennengelernt, die von der Existenz anderer Entity-Typen abhängig sind und nur über deren Schlüssel-Attribute
identifiziert werden können. Abschließend haben wir noch gesehen, dass ternäre
Beziehungstypen nur zum Teil durch binäre Beziehungstypen ausgedrückt werden
können.
1.7 Übungen
Seite 51
1.7 Übungen
Fast alle Aufgaben des Moduls „Konzeptionelle Modellierung“ können mit Papier und Bleistift gelöst werden. Darüber hinaus können Sie gerne die Modelle
elektronisch erstellen. Zur ER-Modellierung gibt es viele kommerzielle Modellierungswerkzeuge, aber auch kostenlose oder Open-Source-Werkzeuge. „Dia“ ist
ein Programm zum Zeichnen von Diagrammen, vergleichbar mit MS Visio und
entstammt der Linux-Gemeinde. Mittlerweile gibt es Dia ebenfalls für Windows bequem zum Installieren unter http://dia-installer.de/. Es besteht jedoch keine
Pflicht zur Nutzung von Dia oder anderer Werkzeuge.
Übung 1.1: 3-Schema-Architektur
Ü
Die 3-Schema-Architektur (ANSI/SPARC, 1975) trennt 3 Arten von Metadaten strikt: Internes, konzeptionelles und externes Schema. Beschreiben Sie
die drei Schemata in Stichworten.
Übung 1.2: konzeptioneller vs. logischer Entwurf
Ü
Charakterisieren Sie den Begriff „konzeptioneller Entwurf“ und „logischer
Entwurf“ der Datenmodellierung, indem Sie Ausgangsbasis und Ergebnis
in Stichwörtern notieren.
Übung 1.3: erste Entwurfsaufgabe
Ü
Zur besseren Unterstützung diverser Dienste soll in Ihrem beruflichen Kontext zentral ein DBS eingesetzt werden. Falls Sie keinen beruflichen Kontext
haben, wählen Sie als Kontext die Friedrich-Alexander-Universität (FAU)
Erlangen-Nürnberg.
1. Überlegen Sie sich exemplarisch, welche Daten verwaltet werden müssen, welche unterschiedlichen Benutzergruppen es gibt, wie häufig
diese auf die Daten zugreifen und welche Anwendungsprogramme
benötigt werden. (Für den Kontext der FAU orientieren Sie sich beispielsweise an den Diensten EST, UnivIS und MeinCampus, falls Sie
diese kennen.)
2. Würden sich die von Ihnen identifizierten Funktionalitäten auch ohne
ein DBS umsetzen lassen? Welche Vor- und Nachteile ergäben sich
aus dem Verzicht auf die Nutzung eines DBS?
Werden Sie nicht zu schnell zu technisch, denken Sie noch nicht in formalen
Notationen sondern eher umgangssprachlich.
Übung 1.4: Krankenhaus-Szenario, Teil 1
In dieser Übung sollen Sie ein konkretes Szenario mittels eines ERDiagramms in Chen-Notation modellieren.
Vorbemerkungen: In dieser Aufgabenstellung trennen wir Entities noch
bewusst von Relationships, um Ihnen den Einstieg in die Modellierung zu
Ü
Seite 52
Studienbrief 1 Grundlagen der Modellierung und das ER-Modell
erleichtern. Normalerweise vermischen sich diese in der Beschreibung. Da
die Beschreibung zu Entities oft Zustandsverben enthält, um bloße Attribute
zu beschreiben ist es bei Anforderungsspezifikationen aus der realen Welt
nicht unbedingt so einfach, Entitäten, Beziehungen und Attribute auseinanderzuhalten.
In der Formulierung der Beziehungen sind die Kardinalitätseinschränkungen genau zu beachten. Im Allgemeinen gilt: alles was nicht explizit eingeschränkt ist, muss im Modell auch uneingeschränkt bleiben (bitte also keine
Einschränkungen einfach in eine Beschreibung hineininterpretieren). Alles
was explizit eingeschränkt ist, darf im Modell nicht einfach uneingeschränkt
bleiben (alle formulierten Einschränkungen sind also zu erkennen).
Bitte verwenden Sie ab jetzt die Chen-Notation. Modellieren Sie die folgenden Entities und Relationships.
1. Es gibt Krankenhäuser.
Diese sind an einer Adresse ansässig.
Und sie besitzen einen Namen.
Ein Krankenhaus ist offiziell unter einer eindeutigen ID registriert.
2. Es gibt Ärzte.
Sie besitzen eine eindeutige Lizenznummer.
In der Regel haben Ärzte ein Spezialisierungsfach.
Darüber hinaus können sie einen wissenschaftlichen Titel besitzen.
3. Das Krankenhaus ist in Abteilungen organisiert.
Eine Abteilung hat einen Namen und eine Spezialisierung
(z.B. „HNO“, „Labor“ etc.).
Vorläufig soll eine Abteilung durch einen künstlichen Schlüssel (ID)
eindeutig identifiziert sein.
4. Es gibt Angestellte, die über ihre Sozialversicherungsnummer (SVN)
eindeutig identifiziert sind.
Angestellte haben einen Vor- und einen Nachnamen.
Außerdem sind sie irgendwann geboren und haben ein Geschlecht.
Darüber hinaus ist ihnen ein Gehalt sehr wichtig.
5. Kein Krankenhaus ohne Patienten:
Sie werden durch die Personalausweis-ID identifiziert und es werden
weitere Daten wie Vorname, Nachname und Adresse gespeichert.
1.7 Übungen
Seite 53
Übung 1.5: Krankenhaus-Szenario, Teil 2
Ü
Es folgt eine weitere narrative Beschreibung von Relationships des
Krankenhaus-Szenarios. Modellieren Sie die folgenden Entities und Relationships weiter in Chen-Notation.
1. Jeder Arzt ist in genau einem Krankenhaus tätig.
Ein Krankenhaus kann mehrere Ärzte beschäftigen.
2. Ein Arzt kann für mehrere Patienten verantwortlich sein.
Wegen steigendem Kostendruck im Gesundheitswesen soll es für
jeden Patienten höchstens einen verantwortlichen Arzt geben.
3. Ein Krankenhaus muss mindestens eine Abteilung haben.
Jede Abteilung gehört zu genau einem Krankenhaus.
4. Eine Abteilung beschäftigt beliebig viele Angestellte.
Ein Angestellter kann in einer oder mehreren Abteilungen arbeiten.
5. Ärzte sind Angestellte: Ein Angestellter kann ein Arzt sein; ein Arzt
ist stets ein Angestellter.
Übung 1.6: Erweiterung des Krankenhaus-Szenarios
Lernziel ist hier, Entity-Typen und Relationship-Typen zu modellieren, deren Beschreibungen sich vermischen und die teilweise unvollständig sind.
Modellieren Sie die folgenden Entities und Relationships wieder in ChenNotation.
1. Gebühren
• Wir würden gerne Patienten Leistungen in Rechnung stellen.
Zu jeder Leistung speichern wir die Beschreibung der medizinischen Leistung und den jeweiligen Preis. Identifiziert werden
sie durch DRG-Codes wie z.B. „B70A“ (einem EU Standard, der
auf ICD-10 und OPS basiert). Rechnungen haben eine eindeutige Rechnungsnummer. Eine Rechnung geht an genau einen
Patienten. Jede Rechnung umfasst mindestens eine Leistung.
2. Angestellte leiten andere Angestellte
• Einem Chef können andere Angestellte untergeben sein.
• Jeder Angestellte ist Untergebener von genau einem Angestellten.
(Zusatzfrage: Woran erkennt man den obersten Boss?)
(Gibt es nur einen obersten Boss oder kann man damit Unternehmen mit einer Art „Vorstand“ modellieren?)
Ü
Seite 54
Ü
Studienbrief 1 Grundlagen der Modellierung und das ER-Modell
Übung 1.7: weitere Fragen zum Krankenhaus-Szenario
1. Welcher Beziehungstyp ergibt sich, wenn wir die Aussage „Wegen
steigendem Kostendruck im Gesundheitswesen soll es für jeden Patienten höchstens einen verantwortlichen Arzt geben“ zu „Ein Patient
hat mindestens einen verantwortlichen Arzt“ umformulieren?
2. Können wir „Abteilung“ als komplexes (zusammengesetzt/mehrwertig) Attribut modellieren? Ist das grundsätzlich möglich und wenn ja,
in welchem Fall? Wie?
3. Könnten wir den künstlichen Schlüssel von „Abteilung“ vermeiden?
4. Wie kann „Abteilung“ als schwache Entität modelliert werden?
5. Gibt es Vorteile oder Nachteile „Abteilung“ als starke Entität zu modellieren?
Ü
Übung 1.8: Szenario Universität
Zeichnen Sie entsprechend der nachfolgenden Angaben ein ER-Diagramm.
Verwenden Sie für die Kardinalitäten der Beziehungstypen die ChenNotation.
• An der Universität werden verschiedene Kurse angeboten. Jeder Kurs
wird über ein eindeutiges Kürzel identifiziert. Darüber hinaus besitzen alle Kurse einen Namen und eine Beschreibung.
• Universitätsangestellte können zudem für ihre Kurse Voraussetzungen zur Teilnahme angeben.
• Ein Semester ist definiert durch einen Namen, der zusammengesetzt
ist aus dem Jahr und einem Semesterkürzel (WS/SS für Wintersemester und Sommersemester).
• Universitätsangestellte werden über eine Personalnummer identifiziert und besitzen darüber hinaus einen Namen und weitere Kontaktinformationen.
• Eine Studienrichtung ist eindeutig identifiziert durch den Namen des
Abschlusses und die Spezialisierung. Diese besteht aus Schwerpunktfächern und Hauptfächern. Die Studienrichtung hat eine Fachprüfungsordnung und eine Studienordnung.
• Studenten können beliebig viele Kurse besuchen. Dabei gibt es keine
Beschränkung der Teilnehmerzahl pro Kurs.
• Alle Studenten besitzen eine Matrikelnummer sowie einen Namen.
Jeder Student studiert mindestens eine Studienrichtung. Für jede Studienrichtung eines Studenten wird die aktuelle Zahl der Fachsemester
vermerkt.
• Studenten können sich über Kurse prüfen lassen. Ein Student kann
von einem Universitätsangestellen in beliebig vielen Kursen geprüft
werden. Eine Prüfung über einen bestimmten Kurs kann jedoch von
einem Studenten nur bei genau einem Universitätsangestellten abgelegt werden. Ein Universitätsangesteller kann in einem Kurs mehrere
Studenten prüfen.
• Ein Kurs, der von einem Universitätsangestellen in einem Semester un-
1.7 Übungen
terrichtet wird, kann für beliebig viele Studienrichtungen angeboten
werden. Findet ein Kurs in einem Semester für eine Studienrichtung
statt, kann dieser von mehreren Universitätsangestellen gehalten werden. Ein Kurs, der von einem Universitätsangestellen für eine Studienrichtung angeboten wird, kann in mehreren Semestern stattfinden.
In einem Semester kann ein Angestellter für eine Studienrichtung
mehrere Kurse halten. In jedem Semester wird unterrichtet. Für jede
Studienrichtung gibt es Unterrichtsangebote. Wenn ein Kurs stattfindet, werden zusätzliche Informationen benötigt: Der Veranstaltungsort, die Veranstaltungstermine (jeweils mit Wochentag, Beginnzeit
und Endzeit), sowie die Anzahl der Semesterwochenstunden.
Seite 55
Liste der Lösungen zu den Kontrollaufgaben
Liste der Lösungen zu den Kontrollaufgaben
Lösung zu Kontrollaufgabe 1.1 auf Seite 12
Im ASCII-Standard wird der Großbuchstabe „A“ durch die Bitfolge „01000001“ kodiert.
Lösung zu Kontrollaufgabe 1.2 auf Seite 17
Zur Unterscheidung der Begriffe DB, DBMS und DBS sagt in der Regel ein Bild mehr
als tausend Worte (siehe Abb. 1.5 auf Seite 16). Wesentliche Punkte sind:
• Datenbank: Sammlung logisch zusammenhängender Daten.
• Datenbank-Managementsystem: Software zur Verwaltung (Definition, Manipulation) von Daten einer Datenbank.
• Datenbanksystem: DB + DBMS
• Datenbankanwendung: Eine Anwendung, die mit einem DBS kommuniziert.
Lösung zu Kontrollaufgabe 1.3 auf Seite 19
Die Vorteile einer mehrschichtigen Architektur beim Entwurf von Datenbanken liegt
in der Entkopplung funktionaler Einheiten: Wir wollen z. B. unsere Speicherungsstrukturen optimieren, ohne im SQL-Code etwas zu verändern. Auch die Anwendung
soll es nicht groß tangieren, wenn wir etwa auf ein anderes DBMS umsteigen.
Lösung zu Kontrollaufgabe 1.4 auf Seite 20
Die zwei Haupteigenschaften eines konzeptionellen Schemas sind Anwendungsneutralität und Datenunabhängigkeit.
Anwendungsneutralität bezieht sich auf die Trennung vom konzeptionellen Schema zum externen Schema (zur Anwendung hin, also nach „oben“ in Abb. 1.7).
Datenunabhängigkeit bezieht sich auf die Trennung vom konzeptionellen Schema
zum internen Schema (zu konkreten Speicherstrukturen hin, also nach „unten“ in
Abb. 1.7).
Lösung zu Kontrollaufgabe 1.5 auf Seite 24
Betrachten Sie nochmals Abb. 1.12 auf Seite 23. Stellen Sie sich vor, das Attribut
„Position“ wäre nicht ein Attribut des Relationship-Typs „arbeitet in“, sondern des
Entity-Typs „Mitarbeiter“.
Dieser Fall modelliert die „Position“ als Konzept unabhängig vom Projekt. Ein Mitarbeiter hätte dann möglicherweise eine Position, auch wenn er in keinem Projekt
arbeitet. Dies wäre durchaus sinnvoll, wenn „Position“ wie ein „Rang“ verstanden
würde (wie „Partner“ vs. „Berater“ bei Unternehmensberatungen oder in der Art
eines militärischen Ranges).
Was ist, wenn ein Mitarbeiter in mehreren Projekten arbeitet? Macht es Sinn, das
Attribut „Position“ an den Entity-Typ „Projekt“ zu heften?
Dies macht keinen Sinn, denn eine Position ist immer nur in einer Verbindung von
Projekt und einem Mitarbeiter sinnvoll. Wenn ein Mitarbeiter in mehreren Projekten
Seite 57
Seite 58
Liste der Lösungen zu den Kontrollaufgaben
arbeitet, gibt es zudem mehrere Instanzen der Relationship „arbeitet in“, die jede
einen eigenen Attributwert „Position“ besitzt.
Lösung zu Kontrollaufgabe 1.6 auf Seite 25
Sind alle Entity- und Relationship-Typen in Abb. 1.13 auf Seite 26 vorhanden?
Ja.
Lösung zu Kontrollaufgabe 1.7 auf Seite 29
Betrachten Sie wieder das Diagramm im Abb. 1.13 auf Seite 26. Die Antworten
lauten:
1. Jeder Mitarbeiter arbeitet in genau einer Abteilung: Ja, da totale Teilnahme
und Kardinalität 1.
2. Es kann Mitarbeiter geben, die in keiner Abteilung arbeiten: Nein, da totale
Teilnahme der Mitarbeiter.
3. Es kann Abteilungen geben, in denen keine Mitarbeiter arbeiten: Nein, da
totale Teilnahme auf beiden Seiten.
4. Jeder Mitarbeiter leitet eine Abteilung: Nein, da keine totale Teilnahme auf
Seiten der Mitarbeiter.
5. Jeder Mitarbeiter leitet mindestens eine Abteilung: Nein, da keine totale
Teilnahme auf Seiten der Mitarbeiter.
6. Es kann Abteilungen geben, die durch keinen Mitarbeiter geleitet werden:
Nein, da totale Teilnahme der Abteilung.
Lösung zu Kontrollaufgabe 1.8 auf Seite 29
Totale Teilnahme von E1 an R würde man in der (min,max)-Notation durch eine
Mindestangabe von 1 auf der Kante von E1 zu R ausdrücken.
Lösung zu Kontrollaufgabe 1.9 auf Seite 33
Das komplexe Attribut aus Beispiel 1.4 auf Seite 32 könnte in grafischer Notation
etwa so aussehen:
Vorwahl
Nummer
Name
Hausnummer
Strasse
PLZ
Telefon
Ort
Adresse
Kontaktinfo
Lösung zu Kontrollaufgabe 1.10 auf Seite 37
Wie kann man die Darstellung aus Abb. 1.19 auf Seite 36 verbessern, damit das
Modell auch ausdrücken kann, dass ein Arzt einen Patienten an mehreren verschiedenen Terminen untersucht hat?
Liste der Lösungen zu den Kontrollaufgaben
Seite 59
Man könnte das Attribut „Datum“ als mehrwertiges Attribut definieren. So hat die
Beziehung zwischen Arzt und Patient einfach mehrere Termine angeheftet.
Besser wäre hingegen, die Untersuchung als eigene Entity zu definieren, und so
über eine dreistellige Beziehung Arzt, Patient und Untersuchung in Verbindung zu
bringen. Datum wäre dann ein Attribut von „Untersuchung“.
Lösung zu Kontrollaufgabe 1.11 auf Seite 41
Die folgenden beiden Bedingungen schließen sich aus:
• Ein Mitarbeiter arbeitet pro Projekt immer nur an höchstens einem Ort.
• Mitarbeiter können an verschiedenen Orten arbeiten.
Bei der ersten Bedingung hat die Kardinalität der Kante zum Entity-Typ „Ort“ den
Wert 1, bei der zweiten Bedingung N . Im ersten Fall wird eine funktionale Abhängigkeit definiert: Mitarbeiter und Projekt zusammen bestimmen eindeutig den Ort.
Dieser Sachverhalt gilt analog für die letzten beiden Bedingungen.
Lösung zu Kontrollaufgabe 1.12 auf Seite 43
Aus der Angabe im Bild ergeben sich folgende funktionale Abhängigkeiten:
1. Universitätsangesteller × Student 7→ Seminarthema
2. Seminarthema × Student 7→ Universitätsangestellter
Studenten dürfen bei jedem Universitätsangestellten also nur ein Seminarthema
bearbeiten und dasselbe Seminarthema nicht bei unterschiedlichen Universitätsangestellten.
Es ist jedoch weiterhin möglich, ein Seminarthema an verschiedene Studenten zu
vergeben. Jeder Student, jeder Universitätsangestellte und jedes Seminarthema
können also in mehr als einem Tupel vorkommen. Die Kardinalitäten in der (min,max)Notation lauten somit in allen drei Fällen (0, N) (siehe Abbildung).
Mit diesen Kardinalitäten ist es aber nun beispielsweise ohne Weiteres möglich, dass
ein Student dasselbe Seminarthema mehr als einmal bearbeitet. Die ursprünglichen
Konsistenzbedingungen werden hiermit verletzt, die Semantik der beiden Notationen
ist also nicht äquivalent.
Seminarthema
Student
(0,N)
N
1 (0,N)
betreuen
1
(0,N)
Universitätsangestellter
Lösung zu Kontrollaufgabe 1.13 auf Seite 44
In dieser Aufgabe geht es um die allgemeine Rekapitulation der Modellierungselemente des ER-Modells. Hier ein stichpunktartiger Überblick:
Seite 60
Liste der Lösungen zu den Kontrollaufgaben
Begriff
Entity
Relationship
Instanz
Typ
Extension
Erklärung
Objekt der Miniwelt
Beziehung zwischen Entities
Ausprägung, Exemplar
Schablone, Prägeform
Menge von Instanzen
Memento
4 Eigenschaften: Bier
Identifiziert durch Teilnehmer
Verwechslungsgefahr: Entity ist kein Typ.
Entspricht Intension.
Damit hantiert später das DBS!
Es folgen einige Erläuterungen:
• Mit „Bier“ sind die 4 Eigenschaften einer Entity gemeint: Beschreibbarkeit,
Identifizierbarkeit, Eigenständige Existenz und Relevanz.
• Relationship-Instanzen sind durch ihre Teilnehmer identifiziert, aber niemals
durch ihre Attribute! Das bedeutet für unser Beispiel „Arzt untersucht Patient
an einem Datum“: Wenn „Datum“ ein Attribut ist, kann eine Untersuchung
nur über Arzt und Patient identifiziert werden. Dann kann ein Arzt einen
Patienten nur einmal untersuchen, weil ein Datum nicht zur Identifikation der
Relationship-Instanz verwendet werden kann!
• Oftmals wird man auf ein ER-Diagramm deuten und etwas wie „Dieses Entity
da“ sagen. Dabei meint man selbstverständlich „Entity-Typ“, obwohl „Entity“
eigentlich „Entity-Instanz“ bedeutet. Machen Sie sich stets den Unterschied
zwischen Typ und Instanz klar!
• Zu Instanzen, Typen/Intension und Extensionen: Angestellter 127-FM ist eine
Instanz des Typs „Angestellter“. Die Tabelle, in der alle Angestellten dieser Firma stehen, enthält die Extension, also die Menge aller (relevanten)
Angestellten.
Verzeichnisse
Seite 61
Verzeichnisse
I. Abbildungen
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
Abb.
1.1:
1.2:
1.3:
1.4:
1.5:
1.6:
1.7:
1.8:
1.9:
1.10:
1.11:
1.12:
1.13:
1.14:
1.15:
1.16:
1.17:
1.18:
1.19:
1.20:
1.21:
1.22:
1.23:
1.24:
1.25:
1.26:
1.27:
1.28:
1.29:
1.30:
1.31:
1.32:
1.33:
1.34:
1.35:
1.36:
Daten und Informationen . . . . . . . . . . . . . . . . . . . . . . . . . .
Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Benutzerspezifische Datenhaltung . . . . . . . . . . . . . . . . . . . . .
Eine anwendungsunabhängige Datenbank . . . . . . . . . . . . . . . . .
Datenbankmanagementsystem (DBMS) . . . . . . . . . . . . . . . . . .
Inhalt einer Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . .
3-Schema-Architektur einer Datenbank . . . . . . . . . . . . . . . . . .
Wie komme ich zum Schema? . . . . . . . . . . . . . . . . . . . . . . . .
Datenmodellierung an Hand eines Minimodells . . . . . . . . . . . . . .
Phasen des Datenbankenentwurfs (nach Elmasri and Navathe [2000]) .
Entity-Typ mit Attributen . . . . . . . . . . . . . . . . . . . . . . . . . . .
Beispiel für Relationship-Typ . . . . . . . . . . . . . . . . . . . . . . . . .
ER-Diagramm einer Personalverwaltung (zur besseren Lesbarkeit rotiert)
Entity- und Relationship-Typen . . . . . . . . . . . . . . . . . . . . . . .
Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Relationship-Typen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Entity, Attribute, Attributwerte . . . . . . . . . . . . . . . . . . . . . . .
Relationships: Intension und Extension . . . . . . . . . . . . . . . . . . .
Darstellung einer falschen Beziehung . . . . . . . . . . . . . . . . . . .
Beziehungstypen vom Grad 3 . . . . . . . . . . . . . . . . . . . . . . . .
Rekursiver Beziehungstyp . . . . . . . . . . . . . . . . . . . . . . . . . .
Kardinalität von Beziehungstypen . . . . . . . . . . . . . . . . . . . . . .
Chen-Notation für Kardinalitäten bei binären Beziehungstypen . . . . . .
Chen-Notation für Kardinalitäten bei ternären Beziehungstypen . . . . .
Chen-Notation und (min, max)-Notation . . . . . . . . . . . . . . . . . .
(min, max)-Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Schwache Entity-Typen und identifizierende Beziehungen . . . . . . . .
Schwacher Entity-Typ steht mit weiteren Entity-Typen in Beziehung . . .
Entwurfsalternativen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modelllierung ohne Beziehungstyp . . . . . . . . . . . . . . . . . . . . .
Modellierungstypen sind nicht äquivalent . . . . . . . . . . . . . . . . .
Ternärer Beziehungstyp mit funktionaler Abhängigkeit . . . . . . . . . .
Nachbildung ternärer durch binäre Beziehungstypen . . . . . . . . . . .
Nachbildung ternärer duch binäre Beziehungstypen: Erster Versuch . . .
Nachbildung ternärer duch binäre Beziehungstypen: Zweiter Versuch . .
Nachbildung ternärer duch binäre Beziehungstypen: Dritter Versuch . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
14
15
15
16
17
18
19
20
21
22
23
26
27
27
28
30
36
36
38
38
39
40
41
42
42
43
44
45
46
46
47
47
48
48
49
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
13
25
32
35
35
39
39
40
II. Beispiele
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
Beispiel
1.1:
1.2:
1.3:
1.4:
1.5:
1.6:
1.7:
1.8:
1.9:
Modelle in der Architektur .
Library of Congress . . . .
Personalverwaltung . . . .
komplexe Attribute . . . . .
binäre Beziehungstypen als
Beziehungsmenge . . . . .
N : M -Beziehung . . . . . .
N : 1-Beziehung . . . . . .
1 : 1-Beziehung . . . . . . .
. . . .
. . . .
. . . .
. . . .
Tupel
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Seite 62
Verzeichnisse
III. Definitionen
Definition
Definition
Definition
Definition
1.1:
1.2:
1.3:
1.4:
Entity . . . . . . . . . .
Attribut . . . . . . . . .
Relationship . . . . . .
Beziehungstyp (formal)
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
22
23
34
Exkurs 1.1: Wertebereiche von Attributen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exkurs 1.2: Sprachphilosophie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
37
IV. Exkurse
V. Kontrollaufgaben
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
Kontrollaufgabe
1.1:
1.2:
1.3:
1.4:
1.5:
1.6:
1.7:
1.8:
1.9:
1.10:
1.11:
1.12:
1.13:
ASCII-Codierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Grundbegriffe der Datenbanken . . . . . . . . . . . . . . . . . . . . . . .
Vorteile mehrschichtiger Architektur . . . . . . . . . . . . . . . . . . . . .
Eigenschaften eines konzeptionellen Schemas . . . . . . . . . . . . . . .
Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Überprüfung des Beispiels . . . . . . . . . . . . . . . . . . . . . . . . . .
totale Teilnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
totale Teilnahme und (min,max)-Notation . . . . . . . . . . . . . . . . . .
komplexe Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modellierungsalternativen beim Beziehungstyp . . . . . . . . . . . . . . .
Kardinalitäten und funktionale Abhängigkeiten . . . . . . . . . . . . . . .
(min, max)-Notation vs. Chen-Notation bei dreistelligen Beziehungstypen
Zusammenfassung ER-Modell . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
12
17
19
20
24
25
29
29
33
37
41
43
44
Tabelle 1.1: Darstellung einer Beziehungsmenge als Tabelle . . . . . . . . . . . . . . . . . . . . . . . .
36
VI. Tabellen
VII. Literatur
Helmut Balzert. Lehrbuch der Softwaretechnik. Springer Verlag, 2009.
C. J. Date. An Introduction to Database Systems. Addison-Wesley Verlag, New York, 2000.
Dudenredaktion. Duden 01. Die deutsche Rechtschreibung. Dudenverlag, 26. auflage edition, 2013.
R. Elmasri and S.B. Navathe. Fundamentals of Database Systems. Addison-Wesley Verlag, 2000.
Helmut Herold, Bruno Lurz, and Jürgen Wohlrab. Grundlagen der Informatik. Pearson Verlag, 2012.
Martin Hitz, Gerti Kappel, Elisabeth Kapsammer, and Werner Retschitzegger. UML@Work. dpunkt Verlag, 2005.
Alfons Kemper and Andre Eickler. Datenbanksysteme: Eine Einführung. Oldenbourg Verlag, 2006.
Jürgen Kühling, Christian Seidel, and Anastasios Sivridis. Datenschutzrecht (Start ins Rechtsgebiet). Verlag C.F.
Müller, 2. edition, 2011.
Richard Lenz. Konzeptionelle Modellierung (Vorlesung). Friedrich-Alexander-Universität Erlangen-Nürnberg,
2012.
Bernd Oestereich. Analyse und Design mit UML 2.1. Oldenbourg Verlag, 2006.
Literatur
Erhard Rahm. Mehrrechner-Datenbanksysteme. Oldenbourg-Verlag, 1994.
Hermann Sauer. Relationale Datenbanken. Addison-Wesley Verlag, 2002.
Seite 63