[KonzMod] - News | IT-Sicherheitsinfrastrukturen ... · TR75 27 UX-11 TR-78 EC-1 XVG VCR CAMC VIDEO...

27TR75

UXQ11

TRQ78

ECQ1

XVG

CA

MC

VC

R

VID

EO

531 539 652 683 867

Nord Süd

Gesamt

JanFeb

MarApr

MaiJun

product

location

time

sales

1HmQuartal

2HmQuartalHJ1

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 ER-Modell

Autoren:Richard LenzFelix Freiling

2. Auflage

Friedrich-Alexander-Universität Erlangen-Nürnberg

© 2015 Richard Lenz, Felix FreilingDepartment InformatikMartensstr. 391058 Erlangen

2. Auflage (3. Dezember 2015)

Didaktische und redaktionelle Bearbeitung:Philipp Klein

Das Werk einschließlich seiner Teile ist urheberrechtlich geschützt. Jede Ver-wendung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohneZustimmung der Verfasser unzulässig und strafbar. Das gilt insbesonderefür Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspei-cherung und Verarbeitung in elektronischen Systemen.

Um die Lesbarkeit zu vereinfachen, wird auf die zusätzliche Formulierungder weiblichen Form bei Personenbezeichnungen verzichtet. Wir weisen des-halb darauf hin, dass die Verwendung der männlichen Form explizit alsgeschlechtsunabhängig verstanden werden soll.

Das diesem Bericht zugrundeliegende Vorhaben wurde mit Mitteln des Bun-desministeriums für Bildung, und Forschung unter dem Förderkennzeichen160H11068 gefördert. Die Verantwortung für den Inhalt dieser Veröffentli-chung liegt beim Autor.

Inhaltsverzeichnis Seite 3

Inhaltsverzeichnis

Einleitung zu den Studienbriefen 4I. Abkürzungen der Randsymbole und Farbkodierungen . . . . . . . . . 4II. Zu den Autoren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5III. Modullehrziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

Studienbrief 1 Grundlagen der Modellierung und das ER-Modell 111.1 Lernergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2 Advance Organizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3 Einführung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.3.1 Daten und Informationen . . . . . . . . . . . . . . . . . . . . 121.3.2 Wann sind Datenbanksysteme sinnvoll? . . . . . . . . . . . . 121.3.3 Grundlegende Begriffe . . . . . . . . . . . . . . . . . . . . . 161.3.4 Die 3-Schema Architektur . . . . . . . . . . . . . . . . . . . . 181.3.5 Phasen des Datenbankentwurfs . . . . . . . . . . . . . . . . 191.3.6 Typen von Datenbanksystemen . . . . . . . . . . . . . . . . . 20

1.4 Das Entity-Relationship-Modell . . . . . . . . . . . . . . . . . . . . . . 211.4.1 Grundlagen des ER-Modells . . . . . . . . . . . . . . . . . . . 221.4.2 Die Symbole in ER-Diagrammen . . . . . . . . . . . . . . . . 251.4.3 Entities und ihre Attribute . . . . . . . . . . . . . . . . . . . . 291.4.4 Relationships (Beziehungen) . . . . . . . . . . . . . . . . . . 341.4.5 Schwache Entity-Typen . . . . . . . . . . . . . . . . . . . . . 43

1.5 Fragestellungen beim Entwurf . . . . . . . . . . . . . . . . . . . . . . 441.5.1 Wozu braucht man schwache Entity-Typen? . . . . . . . . . . 441.5.2 Wozu braucht man ternäre Beziehungstypen? . . . . . . . . . 45

1.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 491.7 Übungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Liste der Lösungen zu den Kontrollaufgaben 57

Verzeichnisse 61I. Abbildungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61II. Beispiele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61III. Definitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62IV. Exkurse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62V. Kontrollaufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62VI. Tabellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62VII. Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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) derFriedrich-Alexander-Universität Erlangen-Nürnberg.

Felix Freiling ist Inhaber des Lehrstuhls für Informatik 1 (IT-Sicherheitsinfrastrukturen) der Friedrich-Alexander-Universität Erlangen-Nürnberg.


III. Modullehrziele

Wenn Sie gute Informatiksysteme konstruieren wollen, dann müssen Sie modellieren können. Modellierungbedeutet, dass Sie den für die IT-Anwendung relevanten Teil derWirklichkeit im Informatiksystemnachbilden.Das Modell ist dann ein zweckgerichtetes vereinfachtes Abbild der Wirklichkeit. Um dies bewerkstelligenzu können, müssen Sie fundamentale Kenntnisse über sinnvolle Modellierungsmethoden besitzen. Diesewerden Ihnen imModul „Konzeptionelle Modellierung“ vermittelt. Gleichzeitig ist dieses Modul ein Einstiegin den Bereich der Datenbanken.

Neben typischen Modellierungssprachen lernen Sie in diesem Modul zur Definition von Datenstrukturenin relationalen Datenbanken die allgemein bekannte Datenbanksprache SQL (Structured Query Langua-ge). Ein besonderer Vorteil von SQL ist, dass die Sprache weitgehend standardisiert und im Bereich dermarktführenden relationalen Datenbanksysteme unangefochten ist.

Im ersten Studienbrief werden die Grundlagen der Modellierung und das Entity-Relationship-Modell (ER-Modell) vorgestellt. Sie lernen, wie Sie Objekte und Beziehungen der realen Welt in formale Konstrukte einerModellwelt übertragen. In diesem Zusammenhang wird auch auf die Strukturierung der Beschreibungsdaten(Schema-Architektur) einer Datenbank und die Phasen des Datenbankentwurfs eingegangen. Im zweitenStudienbrief wird das erweiterte ER-Modell (EER-Modell) vorgestellt. In diesen beiden Studienbriefen erler-nen Sie quasi eine neue Sprache, mit der Sie unabhängig von einer konkreten Implementierung formulierenkö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 Daten-banken übertragen. Dazu erhalten Sie Einblicke in die Welt der relationalen Datenmodellierung. WichtigeKonzepte 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 DatenbankspracheSQL 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 Lan-guage) kennen, die es Ihnen ermöglicht, zunächst unstrukturierte Textdateien mit zusätzlichen hierarchischstrukturierten Beschreibungsdaten anzureichern.

Nach dem erfolgreichen Abschluss dieses Moduls werden Sie in der Lage sein, einen Ausschnitt der realenWelt 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 DatenbankspracheSQL formulieren. Schließlich werden Sie die wesentlichen Konzepte der Daten- und Domänenmodellierungbeherrschen, 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 Lenzausgearbeitet und gehalten worden ist [Lenz, 2012]. Diese Vorlesung und somit auch dieses Modul basierenjedoch stark auf bekannter Standardliteratur im Bereich Datenbanksysteme, hauptsächlich Elmasri andNavathe [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 Wahlpflicht-modul gewählt werden, sondern ist ein Pflichtmodul.

Lehrveranstaltungen undLehrformen:

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 denFachgebieten des Curriculums:

Einordnung ins Fachsemester: Ab Studiensemester 1

Generelle Zielsetzung des Moduls: Zur Förderung und Verstärkung der Fachkompetenz


Arbeitsaufwand bzw.Gesamtworkload:

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 The-mengebiete 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 Entity-Relationship-Modell (ER-Modell). Darüber hinaus erwerben Siefundiertes Wissen über die Datenbanksprache SQL sowie die Aus-zeichnungssprache XML.

Methodenkompetenz: Die Studierenden haben die Fähigkeit zu be-urteilen, wann eine Datenbank sinnvoll ist und können zwischenverschiedenen Typen von Datenbanksystemen unterscheiden.

Sozialkompetenz: Die Konflikt- und Kommunikationsfähigkeit derStudierenden wird in den gemeinsamen Online-Tutorien und Dis-kussionsforen geschult.

Selbstkompetenz: Die Studierenden erlangen die Fähigkeit zur Bil-dung einer Meinung über die selbstentwickelten Datenmodellie-rungen und die Datenmodellierungen anderer. Darüber hinauserlangen sie die Fähigkeit, in herausfordernden Situationen zuhandeln und eine Lösung für komplexe Probleme zu finden.

Modullehrziele Seite 9

Häufigkeit des Angebots: Wintersemester

Anerkannte Module:

Anerkannte anderweitige Lerner-gebnisse /Lernleistungen:

Medienformen: Studienbriefe in schriftlicher und elektronischer Form, Onlinema-terial in Lernplattform, Übungen und Projekte über Lernplattform,Online-Konferenzen, Chat und Forum, Präsenzveranstaltungenmit Computer und Beamer.

Literatur: • Konzeptionelle Modellierung, Richard Lenz, 2012

• Datenbanksysteme: Eine Einführung, Alfons Kemper undAndre 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 Guen-zel

• Information Modeling and Relational Database, T. Halpinund T-Morgan

• Mehrrechner- Datenbanksysteme, E. Rahm

• Lehrbuch der Softwaretechnik, H. Bazert

• Datenbankmodelle, Datenbanksprachen und Datenbankma-nagementsysteme, G. Vossen

• Datenbanken – Konzepte und Sprachen, G. Saake, K. Sattlerund A. Heuer

• Duden 01. Die deutsche Rechtschreibung: Das umfassendeStandardwerk auf der Grundlage der aktuellen amtlichenRegeln, Dudenverlag

• Grundlagen der Informatik, Helmut Herold und BrunoLurz 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 dasER-Modell

1.1 Lernergebnisse

Sie können die Grundbegriffe der Modellierung und der Datenbanken definierenund entscheiden, wann der Einsatz von Datenbanken sinnvoll ist und wann nicht.Sie können die verschiedenen Phasen des Datenbankentwurfs beschreiben undverschiedene Typen von Datenbanksystemen unterscheiden.

Sie beherrschen das Vokabular des Entity-Relationship-Modells (Entity, Relati-onship, Extension, Intension, Attribute, Schlüssel etc.) und können einfache ER-Diagramme 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 Entity-Relationship-Modell. Abschließend werden einige im Kontext der Modellierungständig wiederkehrenden Fragen kurz behandelt.

1.3 Einführung

Das Wort „Modell“ stammt aus dem Lateinischen [Dudenredaktion, 2013]. Dortbezeichnete man mit modulus einen Maßstab, wie man ihn etwa in der Architekturoder der bildenden Kunst verwendete. Heute bezeichnet man mit dem Begriff„Modell“ die Nachbildung oder Darstellung eines Gegenstandes. Grundsätzlichwerden in einem Modell wesentliche Eigenschaften eines Gegenstandes hervorge-hoben und nebensächliche Aspekte außer Acht gelassen. Ein Modell ist also immerauch eine Abstraktion des dargestellten Gegenstandes (eines Realitätsausschnit-tes).

BBeispiel 1.1: Modelle in der Architektur

Architekten verwenden häufigModelle, um dieWirkung eines Gebäudes imKontext seiner Umgebung darzustellen. Dazu wird eine nach einem festenMaßstab verkleinerte Version des (geplanten) Hauses und seiner Umgebungaus Holz oder Pappe nachgebaut. Dieses Modell ist eine Nachbildung derWirklichkeit. Allerdings werden nicht alle Aspekte der Wirklichkeit darge-stellt. Unwesentlich für das Modell sind beispielsweise viele Aspekte desInnenausbaus (Möbel, Wasser- und Stromleitungen etc.). Diese werden be-wusst weggelassen. Wichtig sind hingegen die Proportionen des Hauses imVerhältnis zur Umgebung. Genau diese werden im Modell beibehalten.

Die Abstraktion eines Realitätsausschnitts sollte immer einen Zweck haben, derdurch das Modell erreicht wird. Modellierung ist also immer eine zweckgerichteteVereinfachung durch Weglassen von Details.

Modelle spielen in der Informatik eine zentrale Rolle bzw. erfüllen verschiedeneZwecke. In der Softwareentwicklung dienen Modelle dazu, Software-Systeme

Seite 12 Studienbrief 1 Grundlagen der Modellierung und das ER-Modell

zu spezifizieren, konstruieren, visualisieren und zu dokumentieren. Sie bildenBeschreibungen, an denen sich Entwickler und Anwender orientieren können.

M Merksatz 1.1

EinModell ist ein zweckgerichtetes, vereinfachtes Abbild derWirklichkeit.

1.3.1 Daten und Informationen

In der datenzentrierten Welt der Modellierung müssen wir zwei wichtige Begriffeunterscheiden, die umgangssprachlich häufig nicht trennscharf verwendet werden:Daten und Informationen.

Unter DatenDaten versteht man in der Informatik einfach nur Folgen von Bits [Heroldet al., 2012]. Eine Bitfolge wie „01000001“ hat an sich keine Bedeutung. Erst wennman weiß, wie die Bitfolge zu interpretieren ist, erschließt sich aus ihr (möglicher-weise) eine Information.

Interpretationsmöglichkeiten werden häufig durch sogenannte Kodierungen Kodie-rungen fixiert. Es muss beispielsweise fixiert werden, welche Bitfolge den Buchsta-ben „A“ repräsentiert. Wenn dies geschehen ist, kann man Daten (also eine Folgevon Bits) Informationen (also einer Interpretation) zuordnen. Wenn man Dateninterpretiert, spricht man ihnen eine Bedeutung zu.

K Kontrollaufgabe 1.1: ASCII-Codierung

Eine bekannte Kodierung für einzelne (alphanumerische) Zeichen ist dersogenannte ASCII-Standard. Durch welche Bitfolge wird in diesem Standardder Großbuchstabe „A“ kodiert?

Daten-und Informa-tionsverarbeitung

WennmanDaten in andereDaten transformiert, sprichtman von (sieheAbb. 1.1 un-ten). Wenn uns die Daten eigentlich nicht interessieren, sondern die Verarbeitungder Informationen im Vordergrund steht, spricht man von Informationsverarbei-tung (siehe Abb. 1.1 oben). Durch die Kodierung der Information in Daten kannman so die Informationsverarbeitung auf die Datenverarbeitung zurückführen.Letztendlich interessieren uns immer die Informationen.

Abb. 1.1: Datenund Informationen

Information Information

Daten Daten

Repräsentation Interpretation

Informationsverarbeitung

Datenverarbeitung

1.3.2 Wann sind Datenbanksysteme sinnvoll?

relevante Daten sindDaten, die für unseren

Zweck von Interesse sind

Nicht alle Daten, die weltweit durch Sensoren, Mess- und Aufnahmegeräte, Experi-mente oder Überwachungen erzeugt werden, müssen zwangsläufig aufgezeichnetund 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 Durch-schnittstemperatur des Tages oder die großen Temperaturschwankungen übermehrere Jahre. Daten, für die wir uns interessieren, nennt man relevant.

Das heute gespeicherte Datenvolumen steigt jedoch stetig. Um alle relevantenInformationen aufzuheben, benötigt man heute nach grober Schätzung ein Spei-chervolumen von wenigen tausend Petabytes. Ein Petabyte entspricht dabei 1015

Byte. Dies zu speichern, liegt heute bereits im Bereich des Möglichen. In wenigenJahrenwerdenwir jedoch in der Lage sein, alles aufzubewahren und abzuspeichern.Es ist klar, dass diese unvorstellbaren Datenmengen nur noch von Rechnern aufbe-wahrt, gesucht und aufbereitet werden. Der Mensch sieht weder die Daten, nochkennt er den Aufbewahrungsort und die genauen Ableitungsverfahren. Neben derreinen Speicherkapazität benötigt man aber auch zusätzliche Strukturen, um dieseDaten effizient zu verarbeiten. Genau dies bieten moderne Datenbanken.

BBeispiel 1.2: Library of Congress

Ein gutes Beispiel für eine große Datensammlung ist die größte Bibliothekder 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ügtwerden.

Nach aktuellen Schätzungen umfasst die Sammlung etwa

• 30 Millionen Bücher, darunter 124.000 Telefonbücher und 100.000Comics

• 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 3PB:

• Nur Text (ASCII): 29∗106 ∗1MB = 29TB

• Tonaufnahmen: 2,7∗106 ∗600MB = 1,6PB

• Fotos: 12,3∗106 ∗1MB = 12,3TB

• Landkarten: 4,8∗106 ∗50MB = 240TB

Die großen Datenmengen führen zu ganz praktischen Problemen: Betrachtenwir als Beispiel das Problem der effizienten Suche. Angenommen, wir hätteneine große Festplatte, auf der alle Daten der Library of Congress gespeichertwären. Würde man diese Festplatte „von vorne nach hinten“ (also sequentiell)nach einem gewünschten Buch, Manuskript oder Video durchsuchen, würde manziemlich lange suchen müssen. Zur Abschätzung des Zeitaufwandes folgt hiereine vereinfachte Rechnung.

Nehmen wir an, wir können die Daten mit dem Durchsatz einer normalen Fest-

1 http://www.loc.gov/ (Aufruf am 25.6.2013)

http://www.loc.gov/


platte durchsuchen (etwa 10 MB/s). Für die Durchsuchung von 3 PB würde manalso im Mittel

3PB10MB/s

· 12= 150.000.000s

benötigen. Dies entspricht etwa 4,76 Jahren. Neben der reinen Speicherkapazitätbenötigt man also auch Möglichkeiten, um effizient in den Datenbeständen suchenund auf diese zugreifen zu können.

Konsistenz Effizienter Zugriff allein reicht aber auch noch nicht aus. Ein anderes praktischesProblem besteht nämlich darin, die Daten konsistent zu halten, insbesondere, wennmehrere Benutzer gleichzeitig mit den Daten arbeiten (siehe Abb. 1.2).

Mehrbenutzerbetrieb Stellen Sie sich vor, was passieren würde, wenn täglich tausende Besucher un-kontrolliert auf die Sammlung der Library of Congress zugreifen würden. JederBenutzer möchte mit den Daten so umgehen, als wäre er allein. Der Einsatz einesDatenbanksystems gewährleistet, dass etwa zwei Benutzer nicht den gleichenEintrag gleichzeitig verändern können. Im Gegensatz zu Applikationen, die ihreDaten 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 1

Application 3

Database

User A

User B

Um Ihnen zu verdeutlichen, wann ein Datenbanksystem Sinn macht, betrachtenwir eine Firma, die verschiedene Abteilungen hat und in der die üblichen Ge-schä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 arbei-ten, 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 Verschwen-dung von Speicherplatz birgt dieses Vorgehen auch die Gefahr, dass die Daten„auseinanderlaufen“, d.h. ein und dasselbe Datum an unterschiedlichen Stellenmit unterschiedlichen Werten gespeichert wird. Redundant abgespeicherte Datenbergen 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 sindDaten, die irgendwo gespeichert sind, von denen aber andere Benutzer nichtswissen. Es können beispielsweise Abhängigkeiten zwischen verschiedenen Ap-plikationen bestehen, die undokumentiert sind und sich nicht in den abgelegtenDaten äußern. Zudem können Dateien in verschiedenen Formaten gespeichertwerden. Zu allem Überfluss sind die Datenformate dann meist auch nicht doku-mentiert, so dass es unterschiedliche Interpretationen der Daten gibt, je nachdem,wer sie liest. Diese Art der Datenverwaltung in Form von anwendungsspezifischenbzw. benutzerspezifischen Dateien hat also viele Nachteile.


ApplicationI1

DateiI1

A

ApplicationI2

DateiI2

<A>

ApplicationI3

DateiI3

ApplicationI4

DateiI4

VerschiedeneIFormate RedundatenIDaten

Abhängigkeiten

IsolierteDaten

Abb. 1.3: Benutzerspezifi-sche Datenhaltung

konzeptionelles Daten-bankschema

Ein Datenbanksystem ermöglicht einen zentralen Speicherort für alle Daten einesSoftwaresystems in einem einheitlichen Format für alle Benutzer. Der zentraleSpeicherort vermeidet Redundanz und dadurch Inkonsistenz (siehe Abb. 1.4).Wenn sich das Datum an dieser einen Stelle ändert, dann ist es für alle Benutzersichtbar, die darauf zugreifen dürfen. Der zentrale Speicherort erleichtert es auch,Zugriffsbeschränkungen und Zugriffskontrollen durchzuführen. Ebenso ist dieSynchronisation im Mehrbenutzerbetrieb möglich, denn das Datenbanksystemgarantiert die Integrität der Daten, auch wenn Fehler auftreten (z.B. in Benutzer-programmen oder bei Stromausfall). Wie wir noch sehen werden, ermöglicht einDatenbanksystem 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ürAnwendungsunabhängigkeit. Außerdem sorgt sie dafür, dass die Interpretati-onsmöglichkeiten der Daten durch die Angabe von Kodierungen größtenteilsfestgelegt werden. Es gibt also weniger Möglichkeiten, sich über die Bedeutungvon Daten zu streiten.

Application 2

Application 1

Application 3

Database

User A

User B

Abb. 1.4: Eine anwen-dungsunabhängigeDatenbank

Neben den vielen Vorteilen von Datenbanksystemen gibt es, wie wir noch sehenwerden, auch einige Nachteile bei ihrem Einsatz. So verursacht die erstmaligeEinführung eines Datenbanksystems in einem Softwaresystem hohe Kosten, auchwenn diese Kosten insgesamt (über die Projektlaufzeit) sinken mögen. Die Soft-ware zur Verwaltung von Datenbanksystemen nennt man Datenbankmanage-mentsysteme. Solche Datenbankmanagementsysteme werden auf den allgemeinenAnwendungsfall hin optimiert, sind also keine Spezialanwendungen. Dies ver-ursacht in der Regel einen hohen Rechenaufwand und erfordert entsprechendeRechenleistung. Ein Datenbanksystem macht also keinen Sinn, wenn es sich umeine kleine Datenbank mit einer komplizierten Struktur handelt, die nur von einereinzelnen spezialisierten Anwendung gebraucht wird. Ebenso macht es wenig


Sinn, ein Datenbanksystem einzuführen, wenn die Anwendung eine harte Echt-zeitanforderung hat. Beispiele für solche Anwendungen sind Steuerungssoftwarezur Kontrolle einer Ampelschaltung oder ein Patientenmonitoringsystem auf einerIntensivstation. Wenn kein Mehrbenutzerbetrieb benötigt wird, wie beispielsweisezur Ablage einer privaten CD-Sammlung, dann ist ein Datenbanksystem ebenfallskaum erforderlich.

Datenschutz Nicht zuletzt spielen auch viele Fragen der IT-Sicherheit im Bereich der Datenban-ken eine Rolle. So wurden viele Basiskonzepte der IT-Sicherheit, etwa Zugriffs-schutz und Informationsflusskontrolle, anfangs im Kontext von Datenbankfor-schung entwickelt. Heute muss man beim Entwurf und Betrieb von Datenbanksys-temen immer auch das Thema Datenschutz beachten. So unterliegt das Sammelnvon Daten beispielsweise einer Zweckbindung (Daten dürfen nur zu einem be-stimmten Zweck gesammelt werden) und das Sammeln von Daten muss sparsamerfolgen (es dürfen nicht mehr Daten gesammelt werden als notwendig ist, umden verfolgten Zweck zu erreichen) [Kühling et al., 2011].

1.3.3 Grundlegende Begriffe

Eine DatenbankDatenbank ist eine Sammlung von zusammenhängenden Daten [Elmasri andNavathe, 2000]. Datenbanken werden in der Regel verwendet, um einen Ausschnittder realen Welt zu modellieren. Sie repräsentieren also eine Art „Miniwelt“ [Sauer,2002].

Ein Datenbankmanagementsystem (DBMS)DBMS hingegen ist eine Sammlung von Pro-grammen zur Verwaltung einer Datenbank. Durch ein DBMS soll die Erzeugungeiner Datenbank, die Wartung einer Datenbank und der konsistente Zugriff aufeine Datenbank gewährleistet sein.

Abb. 1.5: Datenbank-managementsystem

(DBMS)

Datenbank

Benutzer

DBMS

Anwendungsprogramm

Datenbanksystem

Datenbankanwendung

Ein Datenbanksystem (DBS)DBS schließlich ist die Kombination einer Datenbankund eines Datenbankmanagementsystems. Dies ist in Abb. 1.5 schematisch darge-stellt.

Zudem gibt es noch den Begriff der DatenbankanwendungDatenbankanwendung . Dies ist die Kombi-


nation einer Datenbank, eines Datenbankmanagementsystems und eines odermehrerer Anwendungsprogramme (siehe Abb. 1.5).

MMerksatz 1.2

Den Zusammenhang zwischen Datenbank (DB), Datenbankmanagement-system (DBMS) und Datenbanksystem (DBS) drückt man häufig durchfolgende Pseudo-Formel aus:

DBS=DB+DBMS

NutzdatenUm die vielen oben beschriebenen Vorteile zu erreichen, muss eine Datenbankneben den eigentlichen Nutzdaten auch noch zusätzliche Daten speichern, die dieNutzdaten „beschreiben“. Dies sind die sogenannten Metadaten.

MetadatenMetadaten („Daten über Daten“) sind Beschreibungsdaten, etwa der Struktur derDatenbank oder zur Kodierung der Daten. Der Zusammenhang zwischen Nutzda-ten, Metadaten und Datenbank wird in Abb. 1.6 nochmals bildlich dargestellt.

Datenbank

Metadaten Nutzdaten

Abb. 1.6: Inhalt einerDatenbank

Schließlich müssen wir noch zwei wichtige Begriffe unterscheiden: Datenmodell(oder auch Datenbankmodell) und Datenbankschema.

a) Das Datenmodell Datenmodellist eine anwendungsunabhängige Strukturierungsvor-schrift für Daten. Es hat also gar nichts mit einer konkreten Anwendungzu tun. Es bestimmt, wie die Daten einer Datenbank allgemein strukturiertwerden. In diesemModul betrachtenwir ausschließlich das relationale Daten-modell. Das relationaleDatenmodell ist die Basis für relationale Datenbanken.Das relationale Datenmodell ist aber nicht die einzige Strukturierungsvor-schrift für Datenbanken. Am Ende des Moduls werden wir durch Verweisein die Literatur noch einen Ausblick etwa auf das Netzwerkmodell oder dashierarchische Datenmodell geben.

b) Ein Datenbankschema Datenbankschemaist die Beschreibung einer konkreten Datenbank.Das Datenbankschema einer relationalen Datenbank enthält beispielswei-se Informationen zu den verschiedenen Tabellen der Datenbank und denDatenformaten, die darin abgelegt sind. Der überwiegende Teil dieses Mo-duls beschäftigt sich mit der Frage, wie man gute Datenbankschemata imrelationalen Datenmodell entwirft.

KKontrollaufgabe 1.2: Grundbegriffe der Datenbanken

Grenzen Sie die Begriffe Datenbank (DB), Datenbankmanagementsystem(DBMS), Datenbanksystem (DBS) und Datenbankanwendung voneinanderab.


1.3.4 Die 3-Schema Architektur

konzeptionelles Schema In diesem Modul wird vorwiegend eine bestimmte Art von Datenbankschemabetrachtet, nämlich das konzeptionelle Schema. Entsprechend heißt das Modulauch „Konzeptionelle Modellierung“. In der Literatur [Rahm, 1994] unterscheidetman insgesamt drei Arten von Datenbankschemata. Diese werden üblicherweiseauf drei Ebenen aufgeteilt (siehe Abb. 1.7), wobei das konzeptionelle Schema inder Mitte angesiedelt ist.

externes Schema Für komplexe Anwendungen kann das Datenbankschema relativ groß werdenund tausende von Tabellen enthalten. Man kann die Datenbank dann durch „Sich-ten“ auf die Tabellen strukturieren, die bestimmen, welche Anwendung welcheTabellen sehen kann. Die Informationen über diese Sichten werden auch als Meta-daten 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 kon-zeptionellen Schema erreicht man, dass das konzeptionelle Schema unabhängigvon bestimmten Anwendungen formuliert werden kann. Diese Eigenschaft wirdals Anwendungsneutralität bezeichnet.

Abb. 1.7: 3-Schema-Architektur ei-

ner DatenbankExterne Schemata:- anwendungsspezifische Sichten

Interne Schemata:- Zugriffspfade- Speicherungsstrukturen

Konzeptionelles Schema:- Datenunabhängigkeit!

- Anwendungsneutralität!

Kern dieser Vorlesung:

internes Schema Es gibt noch weitere Metadaten einer Datenbank, von denen wir jedoch bei derRealisierung der Datenbank bewusst abstrahieren. Hierbei handelt es sich uminterne Realisierungsregeln der konkreten Datenbank, beispielsweise interne Spei-cherstrukturen, 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, oh-ne dass es die Funktionalität der Datenbankanwendung verändert (ein ähnlichesGeheimnisprinzip lernen Sie im Modul „Einführung in die Programmierung“kennen). Diese Speicherstrukturen sind ebenfalls Metadaten, die in der Datenbankabgelegt werden. Man nennt sie auch internes Schema.

Datenunabhängigkeit Durch die explizite Trennung der internen Schemata vom konzeptionellen Sche-ma erreicht man also, dass interne Speicherungsstrukturen vor dem Benutzerverborgen und unabhängig modifiziert werden können. Dies nennt man Daten-unabhängigkeit. Der Grad der Unabhängigkeit, der letztlich in einer konkretenAnwendung erreicht werden kann, hängt dabei vom verwendeten Datenmodellab.Da im relationalen Datenmodell alle Daten in Tabellen abgelegt werden undder Benutzer keinerlei physische Datenstrukturen (wie etwa physische Zeiger,die auf einen Speicherbereich verweisen) zu sehen bekommt, ist mit relationalenDatenbanken ein sehr hoher Grad an Datenunabhängigkeit erreichbar.

Wenn wir im Folgenden von Datenbankschema sprechen, meinen wir immer daskonzeptionelle Schema. Das konzeptionelle Schema ist der Kern jedes Datenban-


kentwurfs und beschreibt, welche Daten es gibt und wie sie zusammenhängen,und zwar unabhängig von der konkreten Umsetzung in einem Datenmodell.

KKontrollaufgabe 1.3: Vorteile mehrschichtiger Architektur

Warum ist eine mehrschichtige Architektur für den Entwurf von Datenban-ken empfehlenswert?

1.3.5 Phasen des Datenbankentwurfs

Wenn man ein konzeptionelles Datenbankschema entwerfen möchte, stellt sichdie Frage, wie man bei dessen Entwurf am besten vorgeht. Die Problemstellung istin Abb. 1.8 dargestellt: Auf der einen Seite existiert die Anwendungsdomäne. Derrelevante Ausschnitt dieser Anwendungsdomäne, der später durch die Datenbankrepräsentiert werden soll, wird „Miniwelt“ genannt. Auf der anderen Seite stehtdas relationale Datenmodell, mit dem wir die Domäne modellieren wollen. Zieldieses Modellierungsprozesses ist die Beschreibung einer Menge von Tabellen, diewir relationales Datenbankschema nennen.

Miniwelt

Anwendungsdomäne

Tabelle 3

Tabelle 1?

Abb. 1.8: Wie komme ichzum Schema?

So einfach diese Aufgabe erscheint, so schwer gestaltet sie sich in der Praxis. Be-trachten wir beispielsweise die Domäne „Gesundheitswesen“ und die Aufgabe,ein Patientenverwaltungssystem für ein Krankenhaus zu entwerfen. Das Problemhierbei liegt nun darin, dass die Domänenexperten (Ärzte, Pfleger etc.) keinenHintergrund in konzeptioneller Modellierung haben und nicht wissen, wie sie ihrDomänenwissen in ein Datenbankschema abbilden sollen. Datenbankexpertenhaben hingegen ein Verständnis von Tabellen und Relationen, aber es fehlt Ihnen anDomänenwissen. Man benötigt also eine Art „Zwischensprache“, um auf einfacheund doch präzise Art und Weise zu kommunizieren. Diese Zwischensprache sollmöglichst einfach zu verstehen undunabhängig von allen Implementierungsdetailssein, die erst relevant werden, wenn man die beschriebene Miniwelt in der konkre-ten Sprache eines DBMS formulieren möchte. In unserem Fall ist die Zielsprache,in der wir unsere Miniwelt formulieren wollen, das relationale Datenmodell. Wirgehen also davon aus, dass wir ein relationales DBMS verwenden wollen. Dadas konzeptionelle Schema aber erst mal unabhängig von der Implementierungdes DBMS sein soll, verwenden wir zunächst ein sogenanntes „semantisches Da-tenmodell“ als Zwischensprache. Eine solche Zwischensprache, das so genannteEntity-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.9dargestellt. Der Anfangspunkt ist jeweils die zu modellierende Miniwelt. In (unterUmständen) mehreren Schritten wird die Miniwelt in ein konzeptionelles Schemaabgebildet, das in der angesprochenen Zwischensprache formuliert ist. Da wirhier das ER-Modell als Zwischensprache verwenden, steht als Ergebnis ein ER-Diagramm.


konzeptioneller Entwurf Der Schritt von der Miniwelt in das konzeptionelle Schema gilt als der eigentlichschwierige Schritt bei der konzeptionellen Modellierung. Man spricht hier auchvom konzeptionellen Entwurf. Für einen guten konzeptionellen Entwurf brauchtman 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 kon-zeptionelles Schema in die konkrete Sprache einesDBMSüberführt. Im relationalenDatenmodell ist das Ergebnis dann ein relationales Datenbankschema.

Abb. 1.9: Datenmo-dellierung an Handeines Minimodells Miniwelt

ObjekteBegriffe

Objektbeziehungen

KonzeptionellerEntwurf

LogischerEntwurf

K Kontrollaufgabe 1.4: Eigenschaften eines konzeptionellen Schemas

Welche zwei Haupteigenschaften eines konzeptionellen Schemas werdendurch die explizite Trennung von externen und internen Schemata er-reicht?

Abb. 1.10 zeigt den konzeptionellen Entwurf im Zusammenhang weiterer Phasendes Datenbankentwurfs. In diesem Studienbrief geht es zunächst um die Erstellungdes konzeptionellen Entwurfs. Dieser Schritt ist unabhängig von einem konkretenDatenbankmanagementsystem. Alle weiteren Schritte, insbesondere der logischeEntwurf, sind DBMS-spezifisch. Im Rahmen dieses Moduls werden nur der kon-zeptionelle und der logische Entwurf betrachtet. Der physische Entwurf wird inanderen Datenbankvorlesungen behandelt. Der linke Zweig von Abb. 1.10 beziehtsich auf die Einbettung der Datenbank in die Anwendung und wird üblicherweisein Lehrveranstaltungen zum Thema Software Engineering behandelt.

1.3.6 Typen von Datenbanksystemen

Das Relationenmodell, mit dem wir uns in diesem Modul beschäftigen, ist dasweltweit verbreitetste Datenbankmodell. Es ist aber nicht das einzige. Zum Ab-schluss dieses Abschnittes erfolgt noch ein kurzer (teilweise) historischer Ausblickauf verschiedene Typen von Datenbanksystemen. Dieser Abschnitt ist als Exkurszu verstehen.

1.4 Das Entity-Relationship-Modell Seite 21

Miniwelt

Anforderungs-analyse

LogicalKDesign

PhysicalKDesign

Implementierung

Anwendungsprogramm-entwurf

Funktional-analyse

Datenbankanforderungen

LogischesKBKonzeptuellesäKSchema

InternesKSchema

Anwendungsprogramm

SpezifikationKvonTransaktionen

FunktionaleKAnforderungen

KonzeptuellerEntwurf

KonzeptuellesKSchema

VorlesungKonzeptionelleModellierung

AndereDatenbank-Vorlesungen

DB

MS

-spe

zifis

chD

BM

S-u

nabh

ängi

g

Abb. 1.10: Phasen desDatenbankenentwurfs(nach Elmasri and Nava-the [2000])

Das historisch älteste Datenmodell ist das hierarchische Datenmodell. hierarchisches Datenmo-dell

Hier werdenDatensätze, die hierarchisch zusammenhängen, „nahe beieinander“ gespeichert.Ein Beispiel für eine hierarchische Datenbeziehung ist die Abteilungshierarchieeiner Firma (Abteilungen mit Unterabteilungen). Suchanfragen entlang dieser Hie-rarchie werden sehr effizient unterstützt: Wenn man den Chef einer Abteilunggefunden hat, dann hat man auch seine Mitarbeiter. Wenn man hingegen andereDatenstrukturen modellieren will, die entgegen der Hierarchie stehen (beispiels-weise Mitarbeiter, die in mehreren Abteilungen arbeiten), muss man Redundanzeinbauen und wird insbesondere bei Änderungsoperationen ineffizient. Das hier-archische Datenmodell erlaubt nur einen geringen Grad an Datenunabhängigkeit,weil der semantische Bezug von zwei Datensätzen durch physische Nachbarschaftausgedrückt wird. Es ist also beispielsweise nicht ohne Weiteres möglich, denSpeicherort eines Datensatzes zu verändern ohne damit auch seine Bedeutung zuverändern.

Objektorientierte Datenbanksysteme verwenden ähnliche Konzepte zur Daten-modellierung wie objektorientierte Programmiersprachen (Objekte, Methoden,Vererbung, siehe Modul „Einführung in die Programmierung“), konnten sichaber am Markt nicht wirklich durchsetzen. Objektrelationale Datenbanksystemesind die Kombination aus relationalen und objektorientierten Konzepten. XML-Datenbanksysteme haben hingegen ihre Vorteile, wenn es um die Verarbeitung von„semistrukturierten Daten“ geht. Diese werden vor allem in Webanwendungeneingesetzt. Auf weitere Datenmodelle soll hier nicht eingegangen werden.

1.4 Das Entity-Relationship-Modell

Entity-Relationship-Modell

Datenbanken spielen eine zentrale Rolle in modernen Softwaresystemen. Im vo-rigen Abschnitt haben wir gesehen, welche Rolle das konzeptionelle Schema imKontext des Datenbankentwurfs und der konzeptionellen Modellierung spielt: Esist ein zentrales Ausdrucksmittel bei der Umsetzung eines Realitätsausschnittsin ein Modell. Um das konzeptionelle Schema auszudrücken, benötigt man eineNotation (eine „Sprache“). Entity-Relationship-Diagramme (ER-Diagramme) sindAusdrücke einer solchen Sprache. Den Formalismus hinter ER-Diagrammen nenntman das Entity-Relationship-Modell (abgekürzt ER-Modell).

In diesem Kapitel lernen Sie die Grundlagen des Entity-Relationship-Modells


kennen, insbesondere die verschiedenen Entity-Typen und Relationship-Typen.Einen Ausschnitt der Welt kann man in ganz verschiedener Weise mittels ER-Diagrammen ausdrücken. Sie lernen deshalb auch, wie man möglichst gute ER-Diagramme schreibt, also den Unterschied zwischen guten und schlechten ER-Diagrammen. Dieses Kapitel orientiert sich an der Begleitliteratur, insbesondereElmasri and Navathe [2000, Kapitel 3] .

1.4.1 Grundlagen des ER-Modells

Das ER-Modell ist eine formale Ausdrucksform, um Gegenstände (Entities) undihre Beziehungen (Relationships) untereinander darzustellen. Wir gehen nun aufdie einzelnen Begriffe des ER-Modells genauer ein. Da diese Begriffe zentral fürdas Verständnis dieses Moduls sind, haben wir sie im Rahmen von Definitionenhervorgehoben.

D Definition 1.1: Entity

Ein Entity ist ein zu beschreibendes Objekt.2

Ein Entity kann beispielsweise ein konkretes Haus, ein bestimmtes Auto oder einbenennbares Boot sein, im Prinzip alles, was in einer Datenbank repräsentiert unddurch sie verwaltet werden soll. Eine Menge gleichartiger Objekte nennt man auchEntity-Menge.

Entity-Typ Beim Datenbankentwurf möchte man aber nicht auf der Ebene konkreter Entitiesarbeiten, sondern auf der Ebene von Entity-Typen. Entity-Typen abstrahieren eineEntity-Menge durch die Angabe ihrer typischen Eigenschaften. Ein Entity-Typkönnte eine bestimmte Menge von Personen sein, etwa die Menge der Mitarbeitereiner Firma.

Attribut Grafisch stellt man einen Entity-Typ als Kasten dar. Jeder Entity-Typ hat einenNamen. Diesen Namen schreibt man üblicherweise mitten in den Kasten hinein.In Abb. 1.11 ist als Beispiel der Entity-Typ „Mitarbeiter“ grafisch dargestellt. UmEntities genauer zu beschreiben, verwendet man Attribute.

Abb. 1.11: Entity-Typ mit Attributen

Mitarbeiter

Vorname

Name

PNR

D Definition 1.2: Attribut

EinAttribut ist eine Eigenschaft bzw. einMerkmal von Objekten eines Entity-Typs.

2 Wir sagen eingedeutscht „das“ Entity, es übernimmt als das Geschlecht vom Objekt.


Beispiele für Attribute eines Mitarbeiters sind die Personalnummer (PNR, sieheAbb. 1.11), der Vorname oder Nachname.

SchlüsselattributUnter allen Attributen gibt es besondere Attribute, so genannte Schlüsselattribute.Dies sind Attribute, die genau ein Entity identifizieren. Bei Schlüsselattributen gibtes also jeden Attribut-Wert nur einmal. Schlüsselattribute werden in der grafischenDarstellung unterstrichen. In Abb. 1.11 ist das Attribut „PNR“ ein Schlüsselattribut,da jedem Mitarbeiter eine eindeutige Nummer zugewiesen wird.

Manchmal kann ein Entity-Typ auch mehrere Schlüsselattribute enthalten. Wennmehrere Attribute unterstrichen sind, bedeutet das in der hier vorgestellten Notati-on, dass es verschiedene Möglichkeiten gibt, die Entities dieses Typs zu identifizie-ren. Beispielsweise könnten Abteilungen entweder durch den Abteilungsnamenoder durch die Abteilungsnummer identifiziert werden. Manchmal braucht manauch eine Kombination von Merkmalen, um Entities zu identifizieren. Dann ver-wendet man zusammengesetzte Attribute. Unter der Annahme, dass es unter denMitarbeitern einer Firma keine Personen mit demselben Namen gibt (also derKombination aus Vornamen und Nachnamen), könnte man auch die beiden Attri-bute „Vorname“ und „Nachname“ als zusammengesetztes Attribut definieren unddieses Attribut als Schlüsselattribut auszeichnen. Wir werden später dazu nochBeispiele kennenlernen.

Neben Entities gibt es als zweites wesentliches Konzept im ER-Modell sogenannteRelationships.

DDefinition 1.3: Relationship

Eine Relationship ist eine Beziehung zwischen zwei oder mehr Objekten.3

Relationship-Menge undRelationship-Typ

Analog zur Entity-Menge bezeichnet man eine Menge gleichartiger Relationshipsals Relationship-Menge. Ein Relationship-Typ ist eine Beschreibung gleichartigerBeziehungen. Genauso wie bei den Entities verwenden wir zur Modellierung nichtkonkrete Relationships, sondern Relationship-Typen.

Arbeitet_in

Projekt

Mitarbeiter

Vorname

Name

PNR

Name

PNR

Position

Beginn

Ende

Abb. 1.12: Beispiel fürRelationship-Typ

3 Sprachlich übernimmt die Relationship das Geschlecht von der Beziehung. Wir sagen also einge-deutscht die Relationship.


Darstellung vonRelationship-Typen

Abb. 1.12 zeigt ein einfaches Beispiel mit zwei Entity-Typen (Mitarbeiter undProjekt) und einem Relationship-Typ „arbeitet in“. Eine Ausprägung dieses Typsbeschreibt die „Arbeitsbeziehung“ zwischen einem Mitarbeiter und einem Pro-jekt, in dem er oder sie arbeitet. Relationship-Typen werden typischerweise alsRaute dargestellt, die mit Linien die Entity-Typen verbinden, zwischen denen dieBeziehung besteht.

Relationship-Typen besitzen einen Namen und können Attribute haben. In demBeispiel aus Abb. 1.12 wird festgehalten, in welcher Position der Mitarbeiter imProjekt arbeitet, wann er seine Arbeit im Projekt begann und wann sie voraus-sichtlich endet. Relationship-Typen können keine Schlüsselattribute haben, dadie einzelnen konkreten Relationships (Beziehungen) immer durch die jeweilsbeteiligten Entities identifiziert werden.

K Kontrollaufgabe 1.5: Attribute

Stellen Sie sich vor, das Attribut „Position“ wäre nicht ein Attribut desRelationship-Typs „arbeitet in“, sondern des Entity-Typs „Mitarbeiter“. Wel-che 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-Modellskennengelernt. Um dieses Wissen zu vertiefen, betrachten wir ein Beispiel. Dabeisehen wir, dass ein ER-Diagramm schnell sehr komplex werden kann. Gerade fürAnfänger sind diese Diagramme schwer nachzuvollziehen. Wir werden deshalbden Formalismus ausgiebig in den Übungen dieses Studienbriefs behandeln.


Im folgenden Beispiel soll die Personalverwaltung einer Firma im ER-Modellmodelliert werden:

BBeispiel 1.3: Personalverwaltung

Die Beispielfirma ist nach Abteilungen organisiert. Jede Abteilung hat eineneindeutigen Namen sowie eine Abteilungsnummer. Weiter ist jeder Abtei-lung ein Manager zugeordnet. Zu jedem Manager wird das Startdatumseiner Managertätigkeit notiert.

Jede Abteilung kann auf mehrere Standorte aufgeteilt sein und mehrereProjekte organisieren. Jedes Projekt hat einen eindeutigen Projektnamen,eine Projektnummer, und ein Projekt findet immer nur an einem Standortstatt.

EinMitarbeiter kannmännlich oder weiblich sein, besitzt einen Namen, eineVersicherungsnummer, eine Adresse, ein Geburtsdatum und bezieht einbestimmtes Gehalt. In der Firmawird einMitarbeiter immer einer Abteilungzugeordnet, kann aber an mehreren Projekten beteiligt sein, auch an Projek-ten anderer Abteilungen. Es soll festgehalten werden, wie viele Stunden einMitarbeiter an einem Projekt arbeitet. Auch der direkte Vorgesetzte einesMitarbeiters muss immer festgelegt sein.

Um die Bezüge (Kindergeld, Freibeträge) eines Mitarbeiters korrekt be-rechnen zu können, sollen auch Daten der Angehörigen eines Mitarbeitersfestgehalten werden. Benötigt werden Angaben zu Name, Geschlecht, Ge-burtsdatum sowie zur Art der Beziehung zu dem Mitarbeiter.

Die Angaben aus dem vorgenannten Beispiel kann man nun mit dem bestehendenWissen über das ER-Modell in ein erstes ER-Diagramm überführen. Dies ist inAbb. 1.13 dargestellt. Wie wir gleich sehen werden, verwendet die Abbildungeinige „Tricks“, um ER-Diagramme leichter lesbarer zu machen. Diese Tricks sindauch Teil der offiziellen Notation. Wir erklären diese Tricks im Anschluss an diefolgende Kontrollaufgabe.

KKontrollaufgabe 1.6: Überprüfung des Beispiels

Gehen Sie den Text aus Beispiel 1.3 durch und prüfen Sie, ob alle Entity-Typen und Relationship-Typen im Diagramm vorhanden sind und ob keinesvergessen wurde.

1.4.2 Die Symbole in ER-Diagrammen

Wir beschreiben im Folgenden die Darstellung und Bedeutung der Symbole in ER-Diagrammen imÜberblick. Diese Beschreibungwird in den folgenden Abschnittendann noch weiter vertieft.

Wir beginnen mit Entity-Typen und Relationship-Typen. Abb. 1.14 zeigt die Sym-bole in der Übersicht nach Elmasri and Navathe [2000]. Wie oben bereits erwähnt,werden Entity-Typen durch Rechtecke dargestellt, Relationship-Typen durch Rau-ten. Man unterscheidet zwischen „normalen“ Entity-Typen und schwachen Entity-Typen, die mit einem doppelten Rechteck bezeichnet werden und die wir späternoch genauer erklären.


Abb. 1.13: ER-Diagrammeiner Personalverwal-

tung (zur besserenLesbarkeit rotiert)

Mit

arb

eit

er

Ad

ress

eSS

N

Vorn

am

eM

itte

linit

iale

Nach

nam

e

Gesc

hle

cht

Nam

eG

eh

alt

Geb

Dat

Arb

eit

et

an

Hat_

Ag

eh

öri

ge

Vorg

ese

tzer

von

org

an

isie

rt

Nu

mm

er

Nam

e

Ort

e

Abte

ilung

Anza

hlM

itarb

eit

er

Arb

eit

et

für

leit

et

Sta

rtd

atu

m

Stu

nd

en

Pro

jekt

Nu

mm

er

Nam

eO

rt

Angehöri

ger

Nam

e Gesc

hle

cht

Geb

Dat

Bezi

ehu

ng

Vorg

ese

tzer

Un

terg

eb

en

er

1NN

NN

M

1

1

1

1

11


Bei Relationship-Typen unterscheidet man zwischen „normalen“ Relationship-Typen und identifizierenden Relationship-Typen. Identifizierende Beziehungstypenstehen im Zusammenhang zu schwachen Entity-Typen und werden im Folgendennoch genauer erläutert.

ENTITY

Ident.RELATION

SHIP

RELATIONSHIP

WEAKENTITY

EntitywTypw(Gegenstandstyp)

SchwacherwEntitywTyp

RelationshipwTypw(Beziehungstyp)

IdentifizierenderwRelationshipwTyp

Abb. 1.14: Entity- undRelationship-Typen

Die verschiedenen Möglichkeiten für Attribute sind in Abb. 1.15 dargestellt. Wiebereits beschrieben, werden Attribute als Kreise/Ellipsen dargestellt und habeneinen Namen. Der Name von Schlüsselattributen wird dabei unterstrichen.

UID

attribute

derived

multivalued

A.2

A.1

A

A.3

Attribut

Schlüsselattribut

Mehrwertiges Attribut

Zusammengesetztes Attribut

Abgeleitetes Attribut

Abb. 1.15: Attribute

Ein Attribut wie „Gehalt“ oder „Name“ hat üblicherweise genau einen Wert. Esgibt aber auch Attribute, bei denen mehrere Werte sinnvoll sind. Ein Beispielaus Abb. 1.13 ist das Attribut „Orte“ des Entity-Typs „Abteilung“, das mehrereWerte 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 dar-gestellt wird, ist in Abb. 1.15 zu sehen. Ein Beispiel aus der Personalverwaltungin Abb. 1.13 ist der Name des Mitarbeiters, der aus den drei Attributen Vorname,Mittelinitiale und Nachname zusammengesetzt ist.

abgeleitetes AttributSchließlich gibt es noch abgeleitete Attribute. Ein abgeleitetes Attribut enthält einenWert, der aus anderen im Modell bereits vorhandenen Informationen vollständigabgeleitet werden kann. Man muss dieses Attribut also eigentlich gar nicht explizitspeichern, da es immer wieder „ausgerechnet“ werden kann. Ein Beispiel für


ein abgeleitetes Attribut in Abb. 1.13 ist „AnzahlMitarbeiter“ des Entity-Typs„Abteilung“. Über die Zuordnung von Mitarbeitern zu Abteilungen kann mandieses Attribut ausrechnen. Abgeleitete Attribute werden mit einer gestricheltenLinie umkreist.

Abb. 1.16:Relationship-Typen

E1 R

Totale"Teilnahme"von"E2"in"R

E2

E1 R

Kardinalität"des"Beziehungstyps"R

E2

E1 R

Strukturelle"Bedingung"für"die"Teilnahmevon"E1"in"R",(min,"max)-Notation,

E2(min,"max)

1 N

In Abb. 1.16 werden verschiedene Möglichkeiten aufgezeigt, wie Einschränkungen(Constraints) für Beziehungstypen definiert werden können. Ein Beziehungstypwird, wie bereits erwähnt, als Raute dargestellt, die mit Linien zwei (oder mehrere)Entity-Typen verbindet. Diese Basis-Notationwird durch zusätzlicheMarkierungennoch erweitert. Diese Markierungen bezeichnen die Art der Beziehung noch etwasgenauer.

Kardinalität Betrachtenwir zunächst die Zahlen, die an denVerbindungslinien des Relationship-Typs zu den jeweiligen Entity-Typen stehen. Diese beziffern die sogenannte Kardi-nalität des Relationship-Typs, d.h. sie geben wieder, in welchem Zahlenverhältnisdie Beziehung gilt. Betrachten wir zur Verdeutlichung das Beispiel in Abb. 1.13:Hier besteht eine Beziehung „arbeitet für“ zwischen dem Entity-Typ „Mitarbei-ter“ und dem Entity-Typ „Abteilung“. Die Zahlen N (auf der Verbindung zumMitarbeiter) und 1 (auf der Verbindung zur Abteilung) bedeuten, dassmehrere (aus-gedrückt als N) Mitarbeiter in einer Abteilung arbeiten. Hier werden also mehrereMitarbeiter einer Abteilung zugeordnet.

funktionale Abhängigkeit Als Kontrast betrachten wir die darunterliegende Beziehung „leitet“. Die Angabendort besagen, dass ein Mitarbeiter höchstens einer Abteilung als Leiter zugeordnetist und umgekehrt. Ein und derselbe Mitarbeiter kann demnach nicht zwei Ab-teilungen leiten. Genauso kann ein und dieselbe Abteilung nicht von mehrerenMitarbeitern geleitet werden. Beachten Sie, dass durch jede 1 an einer Kante eineEinschränkung definiert wird. Die 1 in Abb. 1.16 besagt beispielsweise, dass es zujedem Entity vom Typ E2 höchstens ein Entity vom Typ E1 gibt.

Chen-Notation Etwas anders formuliert bedeutet das: Es wird eine funktionale Abhängigkeitdefiniert, so dass E1 funktional durch E2 bestimmt wird. Diese Form der Spezi-fikation von Beziehungskardinalitäten wird nach dem Erfinder des ER-ModellsPeter 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. TotaleTeilnahme wird mit einer doppelten Linie markiert. In Abb. 1.13 gibt es mehrereBeziehungen, die eine totale Teilnahme vorschreiben. Beispielsweise wird jedeAbteilung von mindestens einem Mitarbeiter geleitet. Außerdem arbeitet jeder


Mitarbeiter in mindestens einem Projekt, und jedem Projekt ist mindestens einMitarbeiter zugeordnet.

KKontrollaufgabe 1.7: totale Teilnahme

Prüfen Sie anhand Ihres Verständnisses von ER-Diagrammen, ob die folgen-den 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 geleitetwerden.

Alternativ zur Chen-Notation in Verbindung mit der Notation zur Formulierungeiner Totalen Teilnahme kann auch die sogenannte „(min,max)-Notation“ zurSpezifikation von Einschränkungen auf Beziehungstypen verwendet werden (sieheAbb. 1.16, unten). Eine Angabe von (x,y) an einer Kante eines Entity-Typs E1 zumRelationship-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 undhöchstens 100 Mitarbeiter haben darf.

Auf den ersten Blick scheint die (min,max)-Notation die zuvor genannten Dar-stellungen zu verallgemeinern. Wie wir später noch sehen werden, gibt es beimehrstelligen Beziehungstypen aber auch Einschränkungen, die nur mit der Chen-Notation formuliert werden können.

KKontrollaufgabe 1.8: totale Teilnahme und (min,max)-Notation

Wie würde man totale Teilnahme von E1 an R in der (min,max)-Notationausdrücken?

1.4.3 Entities und ihre Attribute

Wir betrachten die Begriffe Entity, Entity-Typ und Attribute von Entities nun ge-nauer.

Merkmale von EntitiesWas macht ein Entity genau aus? Ein wesentliches Merkmal eines Entity ist seineeigenständige Existenz. Entities müssen identifizierbar sein, man muss sie alsounterscheiden können. Diese Unterscheidung erfolgt mittels ihrer Attribute. Ins-besondere möchten wir gerne, dass Entities eindeutig identifizierbar sind. Diesgeschieht über die bereits oben beschriebenen Schlüsselattribute. Beispiel für einSchlüsselattribut bei Studierenden ist die Matrikelnummer (es gibt keine zweiStudierenden mit derselben Matrikelnummer).


Attributwert Attribute von (konkreten) Entities haben einen Wert (siehe Abb. 1.17). Der Unter-schied zwischen Attributen und Attributwerten ist wichtig, um den Unterschiedvon Entity-Typ und Entity-Menge zu verstehen. Entities werden durch ihre Attri-butwerte identifiziert. Wir fordern zusätzlich, dass Entities ausschließlich durchihre Attributwerte identifiziert werden. Entities müssen also vollständig durch ihreAttributwerte beschreibbar sein. Außer Attributwerten (und Beziehungen) gibt esnichts, was ein Entity im ER-Modell zusätzlich beschreiben könnte. Wir fordernzusätzlich, dass Entities relevant sind für den zumodellierendenWeltausschnitt.

Abb. 1.17: Entity, At-tribute, Attributwerte

Name:

Vorname:

PNR:

Meier

Hans

1236

Entity E1

Attribute Attributwerte

Intension und Extension

Die Unterscheidung zwischen Entity-Typ und Entity-Menge bringt uns auf einenGegensatz, den wir später auch in anderen Kontexten wiedersehen werden.

M Merksatz 1.3: Intension und Extension

Der Entity-Typ (Intension) ist eine abstrakte Typ-Beschreibung. Die Entity-Menge (Extension) ist die Menge von Entities, die der Typ-Beschreibungentsprechen.

Die IntensionIntension ist also das, was Sie modellieren (wollen): Der Entity-Typ mit sei-nen Attributen. Dies ist das konzeptionelle Schema, das sich üblicherweise zurLebenszeit der Datenbank nicht ändert. Die Entity-Menge umfasst hingegen allekonkreten Entities, die in ihrer Datenbank gespeichert werden. Diese Menge ist„flexibel“ und kann sich mit der Zeit ändern. Ein Entity-Typ hat also Attribute, einEntity hat Attributwerte.

Entity-Typen unterscheiden sich in ihren Attributen. Der Entity-Typ „Mitarbeiter“beinhaltet beispielsweise die Attribute „Name“, „Alter“ und „Gehalt“. Ein andererEntity-Typ „Firma“ enthält die Attribute „Name“, „Standort“ und „Chef“. DasEntity-Set für den Entity-Typ „Mitarbeiter“ könnte also zu einem bestimmtenZeitpunkt 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)


Die Kürzel m1, m2, m3, f1 und f2 sollen die eigentlichen Entities darstellen. InKlammern 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, m2und 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 Bei-spielen wurde jedem Entity für jedes Attribut jeweils ein Wert zugewiesen. Eskann aber auch sein, dass es Entities gibt, denen für ein bestimmtes Attribut keinWert zugewiesen werden kann. Dies ist beispielsweise der Fall, wenn ein Mitar-beiter kein Telefon hat. Dann kann im Attribut Telefonnummer auch kein Wertstehen. Für solche Fälle gibt es einen besonderen Attributwert, den wir NULLnennen. Der Attributwert NULL bedeutet nicht immer, dass der entsprechendeAttributwert nicht existiert. Der Wert NULL bedeutet einfach nur „dieser Wertfehlt“. 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). Isthingegen ein AttributwertNULL gespeichert, bedeutet dies, dass das Attribut nichtbefüllt ist. In diesem Fall darf man es nicht interpretieren.

Ein anderes Beispiel ist ein Attribut „Telefonnummer“ einer Person. Der WertNULL könnte in ganz verschiedener Weise interpretiert werden. Er kann bedeuten,dass die Person gar kein Telefon hat, allerdings auch, dass die Telefonnummereinfach 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 atomareAttribute. Diese haben wir oben bereits kennengelernt. Diese speichern einfacheinen Attributwert. Es gibt hingegen auch Attribute, die aus mehreren Teilattribu-ten bestehen. Dies sind zusammengesetzte Attribute. Oben hatten wir bereits einBeispiel für ein zusammengesetztes Attribut kennengelernt, das Attribut „Name“.Aber auch das Attribut „Adresse“ kann aus mehreren strukturierten Teilattributenbestehen wie etwa „PLZ“, „Ort“, „Straße“ oder „Hausnummer“. Um dieses Attri-but trotzdem als ganzes ansprechbar zu haben, wird es als zusammengesetztesAttribut definiert.

Mehrwertige Attribute

Eine weitere Spielart von Attributen sind mehrwertige Attribute. mehrwertiges AttributAtomare Attributesind einwertige Attribute. Sie können immer maximal einen Wert speichern, wiebeispielsweise „Alter“ oder „Geschlecht“. Mehrwertige Attribute können mehrereAttributwerte speichern. Ein Beispiel hatten wir bereits oben: Das Attribut „Or-te“ einer Abteilung kann mehrere Werte haben, da die Abteilung über mehrere


Liegenschaften verteilt sein kann. Durch eine Zusatznotation (die wir hier nichtbesprechen) kann man sogar Ober- und Untergrenzen angeben.

Abgeleitete Attribute

Weiterhin unterscheiden wir gespeicherte und abgeleitete Attribute.gespeicherte & ab-geleitete Attribute

Dieses Merkmalbezieht sich auf die interne Repräsentation. Der Normalfall sind gespeicherte At-tribute, die „ganz normal“ in der Datenbank abgelegt werden. Ein abgeleitetesAttribut hingegen kann vollständig aus anderen verfügbaren Informationen ab-geleitet werden. So kann beispielsweise das Alter aus dem aktuellen Datum unddem Geburtsdatum abgeleitet werden und muss deshalb nicht explizit gespeichertwerden.

Komplexe Attribute

komplexes Attribut Verschiedene Attributsmerkmale können kombiniert werden. Dies führt zu kom-plexen Attributen. Diese werden textuell in einer speziellen Notation angegeben.Wir betrachten hier die Kombination von zusammengesetzten und mehrwertigenAttributen. Zusammengesetzte Attribute schreiben wir in runden Klammern. EinAttribut „Telefonnummer“, das aus den Attributen „Vorwahl“ und „Teilnehmer-nummer“ zusammengesetzt ist, notieren wir wie folgt:

Telefonnummer (Vorwahl, Teilnehmernummer)

Allgemein wird das zusammengesetzte Attribut A, das aus den Attributen A1 bisAn zusammengesetzt ist, wie folgt aufgeschrieben:

A(A1, . . . ,An)

Mehrwertige Attribute werden in der Notation mit geschweiften Klammern ge-schrieben. Das mehrwertige Attribut „Standort“ würde man dann wie folgt schrei-ben:

{ Standort }

Man kann zusammengesetzte Attribute und mehrwertige Attribute zu komplexenAttributen kombinieren.

B Beispiel 1.4: komplexe Attribute

Ein Beispiel für ein komplexes Attribut „Kontaktinfo“ könnte man beispiels-weise 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 mehre-ren Attributen zusammengesetzt ist, nämlich „Telefonnummer“ und „Adresse“.Das Attribut „Telefonnummer“ ist ein mehrwertiges, zusammengesetztes Attri-but. Adresse hingegen ist zusammengesetzt aus „Straße“, „PLZ“, „Hausnummer“,wobei „Straße“ wieder ein zusammengesetztes Attribut ist. Dieses Beispiel istnicht sonderlich elegant (es soll ja nur das Konzept eines komplexen Attributes


demonstrieren). Der Normalfall in der Praxis sind die einfachen (nicht-komplexen)Attribute.

KKontrollaufgabe 1.9: komplexe Attribute

Zeichnen Sie das komplexe Attribut aus Beispiel 1.4 in grafischer Notation.

Schlüsselattribute

Eine wichtige Art von Attributen sind Schlüsselattribute. SchlüsselattributSchlüsselattribute ermög-lichen es, ein Entity eindeutig zu identifizieren. Da diese Eigenschaft für Entitiesso wichtig ist, werden in der Praxis der Einfachheit halber spezifische Attribute alsSchlü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 Personeneindeutig zu identifizieren (aber das funktioniert in ganz seltenen Fällen eben auchnicht).

zusammengesetztesSchlüsselattribut

Wenn eine Gruppe von Attributen zusammengefasst wird, um eine Eindeutigkeiterreichen zu können, spricht man von zusammengesetzten Schlüsselattributen.Ein zusammengesetztes Schlüsselattribut sollte allerdings minimal sein, d.h. mansollte nicht mehr Attribute darin zusammenfassen als notwendig sind, um ein En-tity eindeutig zu identifizieren. Wenn beispielsweise angenommen wird, dass einzusammengesetztes Attribut „(Name, Vorname, Geburtsdatum)“ zur Identifikati-on einer Person ausreicht, dann ist das Attribut „(Name, Vorname, Geburtsdatum,Adresse)“ nicht minimal.

schwacher Entity-TypNicht jeder Entity-Typmuss zwingend ein Schlüsselattribut enthalten. Entity-Typen,die kein Schlüsselattribut enthalten, nennt man schwache Entity-Typen. SchwacheEntities werden mit Hilfe der Entities eines anderen Entity-Typs identifiziert.

EExkurs 1.1: Wertebereiche von Attributen

Man kann Attribute und ihre Wertebereiche auch noch formaler, also nochpräziser definieren. Grundsätzlich hat jedes einfache Attribut einenWertebe-reich bzw. eine Menge von zulässigen Attributswerten. So hat z.B. das Attri-but „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 WertebereichV als Abbildung

A : E 7→ P(V )

wobei P(V ) die Potenzmenge von V bezeichnet, also die Menge aller Teil-mengen von V .

Da A eine Abbildung ist, kann man für eine konkrete Entity e den Attribut-wert mit A(e) bezeichnen. Einwertige Attribute führen dann zu einelementi-gen Mengen, d.h. falls A ein einwertiges Attribut mit Wert a1 ist, ergibt dieAbfrage des Attributwertes die einelementige Menge {a1}, also:

A(e) = {a1}


Wäre A ein mehrwertiges Attribut (mit Werten a1, a2 und a3, ergäbe dieAbfrage 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 Instrumentdes Kreuzproduktes verwenden. Der Wertebereich eines Attributes, das ausn Attributen mit Wertebereichen V1 bis Vn zusammengesetzt ist, ist danndefiniert als:

V = P(V1)×P(V2)× . . .×P(Vn)

1.4.4 Relationships (Beziehungen)

Eine Relationship (Beziehung) besteht zwischen zwei odermehr 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 gutdie Beziehungen zwischen den verschiedenen Entities abgelesen werden.

Existenzabhängigkeit Auch Beziehungen haben Merkmale, die charakteristisch sind. Eine Beziehungkann zwischen zwei oder mehr Entities bestehen, aber andersherum kann eine„Relationship“ nicht ohne die beteiligten Entities existieren. So kann z.B. eineAnstellung zwischen einer Person und einer Firma nicht ohne eine Person oder eineFirma existieren. Beziehungen sind also existenzabhängig. Daher ist eine Beziehungnicht eigenständig und hat auch keine Schlüsselattribute. Die Beziehung wird überdie beteiligten Entities identifiziert.

Binäre und n-stellige Beziehungstypen

Wir betrachten Relationship-Typen etwas formaler. Bisher haben wir hauptsäch-lich binäre Beziehungstypen kennengelernt, also Beziehungstypen zwischen zweiEntity-Typen, wie etwa ein Mitarbeiter und einer Abteilung. Man kann aber mit Be-ziehungen beliebig viele Entities miteinander verknüpfen. Die folgende Definitionbeschreibt 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


Mengen. Bei n Mengen spricht man von n-Tupeln (ein paar ist also ein 2-Tupel,siehe Modul „Mathematik 1“).

BBeispiel 1.5: binäre Beziehungstypen als Tupel

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 eineZuordnung von Studierenden zu Lehrveranstaltungen. Formal wird das alsMenge von Paaren der Entity-Mengen Studierende undLehrveranstaltungenausgedrü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 „konz-Mod“.

Analog zur Unterscheidung zwischen Entity-Typen (Intension) und Entity-Mengen(Extension) unterscheiden wir sprachlich auch zwischen Beziehungstypen (In-tension) und Beziehungsmengen (Extension). Die Extension verändert sich überdie Zeit, die Intension aber nicht. Gegenstand der Modellierung ist daher immerdie intensionale Ebene. Besonders trennscharf ist diese Unterscheidung hier abernicht, weil wir zur Erläuterung der Bedeutung eines Beziehungstyps immer auchdie extensionale Ebene brauchen. So wird in Definition 1.4 ein Beziehungstyptatsächlich als Menge definiert, um zu verdeutlichen, wie die Ausprägungen diesesTyps aussehen.

Grundsätzlich kann ein Entity an einer Beziehung teilnehmen und ein Entity-Typkann an einem Beziehungstyp teilnehmen. Eine Instanz eines n-stelligen Bezie-hungstyps R, wie er in Definition 1.4 definiert ist, ist immer auch eine n-stelligeBeziehung, die genau n Entities zueinander in Beziehung setzt, nämlich von jedemder beteiligten Entity-Typen genau ein Entity.

BBeispiel 1.6: Beziehungsmenge

Im vorgenannten Beispiel der Studierenden, die an Lehrveranstaltungenteilnehmen, ist die Menge

{ (Sally, konzMod), (Sally, Programmierung 1), (Joe, konzMod) }

die Beziehungsmenge und die einzelnen Tupel sind die Instanzen. Jede In-stanz, z.B. (Sally, konzMod), schließt von jedem an der Beziehung beteiligtenEntity-Typ (Studierende, Lehrveranstaltung) genau ein Entity mit ein.

Was ein binärer Beziehungstyp auf extensionaler Ebene bedeutet wird grafisch inAbb. 1.18 dargestellt. Hier geht es um den Beziehungstyp „arbeitet in“ zwischen


den Entity-Typen „Mitarbeiter“ und „Abteilung“. In der Abbildung ist wieder dieIntension (oben) und die Extension (unten) getrennt dargestellt. Die Mitarbeiter-menge ist links unten dargestellt. Sie besteht abstrakt aus den Entities e1,e2, . . .,während die Menge der Abteilungen d1,d2, . . . rechts dargestellt ist. Die Beziehun-gen sind in der Mitte dargestellt. Sie verbinden jeweils einen Mitarbeiter mit einerAbteilung. Jede Beziehung (w1 bis w7) ist eine Instanz des Beziehungstyps. Sie setztjeweils genau zwei Entities in Beziehung. Beziehungsinstanzw1 setzt beispielsweisedas Mitarbeiter-Entity e1 mit dem Abteilungs-Entity d3 in Beziehung.

Abb. 1.18: Relationships:Intension und Extension

Mitarbeiter Abteilungarbeitet_in

Mitarbeiter arbeitet_in

Abteilunge1e2e3e4e5e6e7...

w1w2w3w4w5w6w7...

d1d2d3...

Darstellung als Tabelle

Eine Beziehungsmenge lässt sich auch als Tabelle darstellen. Für jeden beteiligtenEntity-Typ ist eine Spalte vorgesehen und für jede Beziehungsinstanz eine Zeile.Hierbei ist wichtig zu beachten, dass es nicht mehrere Beziehungsinstanzen einesBeziehungstyps mit denselben Entities geben kann. Tabelle 1.1 bezieht sich aufAbb. 1.18, in der die Beziehung vonMitarbeitern zur Abteilung dargestellt wird. Eskann nicht vorkommen, dass der Eintrag (Sally, konzMod) zweimal in der Tabellevorkommt.

Tabelle 1.1: Darstel-lung einer Beziehungs-

menge als Tabelle

Student VorlesungSally konzModSally Programmierung 1Joe Programmierung 1

Bisher haben wir immer Beispiele kennengelernt, in der die Modellierung mehroder weniger sinnvoll war. Man kann aber auch leicht Fehler bei der Modellierungmachen, also ER-Diagramme zeichnen, die ungenau oder ungenügend die Weltabbilden. Ein Beispiel ist in Abb.1.19 zu sehen. Dort ist die Beziehung von einemArzt zu seinen Patienten dargestellt. Mit dem Attribut „Datum“ der Beziehung„untersucht“ soll vermutlich modelliert werden, dass ein Arzt einen Patienten aneinem bestimmten Datum untersucht (hat). Allerdings ist die Darstellung nochnicht optimal, da ein Arzt einen Patienten mehrfach untersuchen kann. In derAbbildung wird hingegen folgendes beschrieben: Die Beziehung „untersucht“besteht zwischen Arzt und Patient oder sie besteht nicht; wenn sie besteht, dannhat sie ein Datum.

Abb. 1.19: Darstellungeiner falschen Beziehung

Arzt Patientuntersucht

Datum

FALSCH!


KKontrollaufgabe 1.10: Modellierungsalternativen beim Beziehungstyp

Wie kann man die Darstellung aus Abb. 1.19 verbessern, damit das Mo-dell auch ausdrücken kann, dass ein Arzt einen Patienten an mehrerenverschiedenen Terminen untersucht hat?

EExkurs 1.2: Sprachphilosophie

Zitat aus einer Mail von Prof. Wedekind (zitiert nach Lenz [2012]:

Flektieren und Passivbildung sind zur Formalisierung von Kon-zepten verboten, aus Gründen der Einfachheit und Sprachöko-nomie. Ockhams Rasiermesser lässt grüßen. Und man sollte sichvon natürlichen Sprachen nicht gängeln lassen. Die sind nämlichein unendlicher Ozean. [. . . ]

Unter Subjekt-Arten finden Sie den Begriff „logisches Subjekt“.Die Subjektart erklärt man über eine (logisch verbotene) Passiv-bildung. In „Kabine wird von Kunde gebucht“ ist „Kabine“ (imNominativ stehend) das grammatische Subjekt und „Kunde“das grammatische Objekt. Das logische Subjekt ist und bleibt„Kunde“, weil die Logik die Passivbildung nicht mitmacht. Daslogische Subjekt, oder, anders gesprochen, das Agens, ist undbleibt das Wort „Kunde“. Das haben rationale, logikbasierteSprachen so an sich. Sie haben ihren Sitz im Handeln.

Wenn ich „buchen“, wie die ER-Technik das tut, als simple Rela-tion 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, derKopula (ε)-Form:

Kunde, Kabine ε buchen

Das Agens ist semantischweg. Und das ist aus objekt-orientierterSicht unzulässig und auch für praktische Bedürfnisse falsch [. . . ].Der Kunde tut was und das ist zu programmieren, d.h. in diePraxis zu bringen.

„Kunde bucht Kabine“ wird als Fakt bezeichnet. Fakten konstitu-ieren ein Faktmodell [. . . ]. Das ist etwas anders als ein ER-Modellund steht als Kompression einer langseitigen Anforderungs-beschreibung (requirement definition) an zweiter Stelle einerGesamtmethodologie. Man sollte aber erst mal ein Faktenmo-dell aufstellen, ohne dabei schon an Klassen und Methoden zudenken. Denn bis dahin, das heißt, hin zum Vorhof der Program-mierung, ist noch ein weiter Weg. [. . . ]

PS: Platon sagt: Es gibt „actio“ und „res“. ER-Diagramme kennennur „res“. „actio“ wird unterdrückt. Das kann man machen. DieEinschränkung ist aber enorm.


Grade von Beziehungen

Der Grad eines BeziehungstypsGrad eines Be-ziehungstyps

beziffert die Menge der Entity-Typen, die die Bezie-hung verbindet. So hat z.B. der in Abb. 1.18 dargestellte Beziehungstyp „arbeitetin“ den Grad 2, da sie zu zwei Objekten eine Beziehung hat. Einen Beziehungstypvom Grad 2 nennt man „binären Beziehungstyp“ und einen Beziehungstyp vomGrad 3 nennt man „ternären Beziehungstyp“.

Einige Beispiele sind in Abb. 1.20 wiedergegeben. Teil a und b von Abb. 1.20stellen beides ternäre Beziehungstypen dar. Teil b ist dabei eine Verbesserung deroben als suboptimal klassifizierten Darstellung mit einem Attribut „Datum“ derBeziehung „untersucht“. Teil c der Abbildung stellt die Extension eines ternärenBeziehungstyps aus Teil a der Abbildung nochmal grafisch dar.Man sieht, dass jedeBeziehungsinstanz genau drei Entities der beteiligten Entity-Typen in Beziehungsetzt.

Abb. 1.20: Beziehungs-typen vom Grad 3

Lieferant Lieferung

Projekt

Teil

Arzt untersucht

Patient

Untersuchung

LieferantLieferung

r2r3

s1s2s3s4

s6s7...

Projekt

j222j333...

j111s5

...

r1

Teil

p22

p11

...

a) b)

c)

Beispiel:

Rekursive Bezieungstypen

In einem ER-Diagramm kann es auch rekursive Beziehungstypenrekursive Be-ziehungstypen

geben. Diesist der Fall, wenn ein Entity-Typ mit sich selbst in Beziehung steht. Ein Beispielfür einen solchen Beziehungstyp ist „ist Vorgesetzter von“, in dem der Entity-TypMitarbeiter doppelt vorkommt. Was damit modelliert wird ist die Tatsache, dassein Mitarbeiter der Vorgesetzte eines anderen Mitarbeiters sein kann.

Abb. 1.21: Rekursi-ver Beziehungstyp

Mitarbeiter

Chef_von

Mitarbeiter

e1e2e3e4e5e6e7...

Vorgesetzter Untergebener

Chef_von

s1s2s3s4s5s6...

1

1 1

11

1

2

2

2

2

22

Rollenname Um die Kardinalitäten bei rekursiven Beziehungstypen eindeutig definieren zukönnen, versieht man die verschiedenen Vorkommen eines Entity-Typs jeweils miteinem Rollennamen. In unserem Beispiel wird die eine ausgehende Kante desrekursiven Beziehungstyps mit dem Rollennamen „Vorgesetzter“ und die andereKante mit dem Rollennamen „Untergebener“ beschriftet (siehe Abb. 1.21 links).Wenn nun an der Kante „Vorgesetzter“ eine 1 steht, ist klar erkennbar, dass ein


Mitarbeiter höchstens einen Vorgesetzten haben kann. Ohne die Rollennamenwäre das nicht eindeutig.

Abb. 1.21 (rechts) verdeutlicht nochmal die Extension dieses Beziehungstyps. Inder Grafik kann man nochmal deutlich sehen, dass es sich um einen binärenBeziehungstyp handelt, denn jede Beziehungsinstanz verbindet genau zwei Entitiesmiteinander. Der Einfachheit halber wurden die beiden Rollen-Namen dabei mitden Ziffern 1 und 2 abgekürzt.

Kardinalitäten

Abhängig von der Menge der zugeordneten Entities unterscheidet man Bezie-hungstypen unterschiedlicher Kardinalitäten. Die wichtigsten dieser Typen sindin Abb. 1.22 dargestellt.

N:M N:1 1:1

Abb. 1.22: Kardinalitätvon Beziehungstypen

Die allgemeinste Form ist die N : M-Beziehung (Abb. 1.22, links). Eine solcheBeziehung modelliert, dass ein Entity des einen Entity-Typs mit beliebig vielenEntities des anderen Entity-Typs in Beziehung stehen kann und umgekehrt.

BBeispiel 1.7: N : M-Beziehung

Ein Beispiel für eine N : M-Beziehung ist die Beziehung „arbeitet in“ zwi-schen Mitarbeitern und Projekten (siehe Abb. 1.13): Ein Mitarbeiter kann invielen Projekten arbeiten, und in einem Projekt arbeiten viele Mitarbeiter.

Manchmal möchte man die Kardinalität der Beziehung einschränken. Zwei Spezi-alfälle sind die N : 1- und die 1 : 1-Beziehungen. In einer N : 1-Beziehung bestehtdann, wenn ein Entity des ersten Typs nur mit höchstens einem Entity des zweitenTyps in Beziehung stehen darf, ein Entity des zweiten Typs aber mit vielen Entitiesdes zweiten Typs (Abb. 1.22, mitte).

BBeispiel 1.8: N : 1-Beziehung

Ein Beispiel für eineN : 1-Beziehung ausAbb. 1.13 ist die Beziehung „arbeitetin“ zwischen Mitarbeitern und Abteilungen: Ein Mitarbeiter arbeitet inhöchstens einer Abteilung, allerdings sind einer Abteilung beliebig vieleMitarbeiter zugeordnet.

Eine 1 : 1-Beziehung liegt schließlich vor, wenn ein Entity des ersten Typs mithöchstens einem Entity des zweiten Typs in Beziehung steht und umgekehrt ge-


nauso ein Entity des zweiten Typs mit höchstens einem Entity des zweiten Typs inVerbindung steht.

B Beispiel 1.9: 1 : 1-Beziehung

Ein Beispiel für eine 1 : 1-Beziehung ist „leitet“ zwischen Mitarbeitern undAbteilungen: Ein Mitarbeiter kann höchstens eine Abteilung leiten, und eineAbteilung wird von höchstens einem Mitarbeiter geleitet.

funktionale Abhängigkeit Die Darstellung in Abb. 1.22 entspricht nicht unserer üblichen ER-Notation, weilsie verdeutlichen soll, dass durch die Spezifikation von Kardinalitäten in ersterLinie funktionale Abhängigkeiten spezifiziert werden. Ein Pfeil symbolisiert einefunktionale Abhängigkeit: Der erste Typ bestimmt dann vollständig den zweitenTyp. Bei N : M-Beziehungen gibt es keine Einschränkungen, also auch keine funk-tionalen Abhängigkeiten. Bei einer N : 1-Beziehung ist der zweite Typ funktionalabhängig vom ersten Typ. Bei 1 : 1-Beziehungen hat man die funktionale Abhän-gigkeit in beiden Richtungen: Wenn man ein Entity des ersten Typs hat, dann istdas Entity des zweiten Typs vollständig bestimmt; umgekehrt ist auch bei Angabedes Entities des zweiten Typs der Entity des ersten Typs genau bestimmt.

Abb. 1.23: Chen-Notationfür Kardinalitäten bei

binären Beziehungstypen

��

��

��

Chen-Notation In der von uns verwendeten Notation wird zur Darstellung der Kardinalitätenüblicherweise die sogenannteChen-Notation [Balzert, 2009] verwendet. Abb. 1.23zeigt die eben (mit Pfeilen) vorgestellten Beziehungstypen nochmal in andererForm. Eine „1“ bei einem Entity-Typ bedeutet, dass Entities dieses Typs funktionaldurch die Entities des anderen Beziehungstyps bestimmt werden, etwa so wie inAbb. 1.23. Die dort dargestellten drei Beziehungstypen enthalten folgende dreifunktionale Abhängigkeiten:

• Mann „bestimmt“ Frau (in der Beziehung „verheiratet mit“). Ein Mann istalso mit höchstens einer Frau verheiratet.

• Frau „bestimmt“ Mann (in der Beziehung „verheiratet mit“). Eine Frau istalso mit höchstens einem Mann verheiratet.

• Mitarbeiter „bestimmt“ Abteilung (in der Beziehung „arbeitet in“). EinMitarbeiter arbeitet also in höchstens einer Abteilung.

Integritätsbedingung Die Kardinalitätsangaben können natürlich auch bei Beziehungstypen höherenGrades gemacht werden. Ein Beispiel für eine ternäre Beziehung zeigt Abb. 1.24.


��

��

��

�

�

�

Abb. 1.24: Chen-Notationfür Kardinalitäten bei ter-nären Beziehungstypen

Dieser Beziehungstyp drückt aus, dass ein Lieferant verschiedene Teile für ver-schiedene Projekte liefern kann. Allerdings existiert auch hier eine funktionaleAbhängigkeit: Die Kardinalität 1 an der Kante zum Lieferanten bedeutet nämlich,dass das Projekt und das Bauteil den Lieferanten eindeutig bestimmen. Pro Projektund Bauteil gibt es höchstens einen Lieferanten. Das Paar Projekt und Bauteil„bestimmt“ den Lieferanten. Funktionale Abhängigkeiten beschreiben Integri-tätsbedingungen, also Bedingungen auf dem Modell, die durch die Datenbanküberprüft und eingehalten werden sollen.

KKontrollaufgabe 1.11: Kardinalitäten und funktionale Abhängigkeiten

Betrachten Sie die Entity-Typen „Mitarbeiter“, „Projekt“ und „Ort“ und denternären Beziehungstyp „arbeitet in“, der die drei Entity-Typen miteinanderin Beziehung setzt. Zeichnen Sie das ER-Diagramm für die „arbeitet in“-Beziehung und geben Sie jeweils die Kardinalitäten an, so dass die folgendenBedingungen modelliert werden:

• Ein Mitarbeiter arbeitet pro Projekt immer nur an höchstens einemOrt.

• Mitarbeiter können an verschiedenen Orten arbeiten.

• Ein Mitarbeiter darf an einem Ort nur in höchstens einem Projektarbeiten.

• 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 mindestenseiner Beziehungsinstanz dieses Typs teilnehmen muss. Dies nennt man totaleTeilnahme. Abb. 1.25 zeigt ein Beispiel für totale Teilnahme. Die doppelten Kantensind wie folgt zu lesen: Jeder Mitarbeiter arbeitet in mindestens einer Abteilung,und jede Abteilung hat mindestens einen Mitarbeiter. Zusammen mit der Kardi-nalität 1 an der Kante zur Abteilung bedeutet dies: Jeder Mitarbeiter arbeitet inmindestens und höchstens einer Abteilung; also arbeitet jeder Mitarbeiter in genaueiner Abteilung.


Abb. 1.25: Chen-Notationund (min, max)-Notation

Mitarbeiter AbteilungArbeitet_in

a)N 1


b)(1,1) (2,N)

(min,max)-Notation

Mit der bisherigen Notation kann man noch nicht ausdrücken, dass eine Abtei-lung 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 undhöchstens an y Beziehungsinstanzen teilnimmt.

Abb. 1.25 verdeutlicht dies nochmal anhand eines Beispiels. Hier wird folgen-des ausgedrückt: Jeder Mitarbeiter arbeitet in genau einer Abteilung, und jedeAbteilung 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 alsoRestriktionen ausdrücken, die in der Chen-Notation nicht darstellbar wären.

Die (min,max)-Notation kann auch für mehrstellige Beziehungstypen verwendetwerden. Abb. 1.26 (c) zeigt ein Beispiel. Die einzelnen Angaben an den Kantensind 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, kannjedoch in der (min,max)-Notation nicht dargestellt werden. Hier ist die Chen-Notation mächtiger. Beide Notationen haben also ihre Daseinsberechtigung. DieChen-Notation eignet sich besser zur Darstellung funktionaler Abhängigkeiten.

Abb. 1.26: (min,max)-Notation


a)N 1


b)(1,1) (2,N)

Lieferant

Projekt

Lieferung(0,N)

Teil

c) (0,N)

(0,N)


KKontrollaufgabe 1.12: (min, max)-Notation vs. Chen-Notation bei dreistelli-gen Beziehungstypen

Formulieren Sie die Kardinalitäten des in der unten stehenden Abbil-dung dargestellten dreistelligen Beziehungstyps „betreuen“ in (min,max)-Notation. Begründen Sie, inwiefern die Semantik beider Darstellungen äqui-valent ist!

Student

Seminarthema

UniversitätsangestellterbetreuenN 1

1

1.4.5 Schwache Entity-Typen

Bisher haben wir von Entities gefordert, dass sie eine eigenständige Existenz be-sitzen und identifizierbar sind. Schwache Entities sind zwar auch identifizierbar,hängen in ihrer Existenz aber von anderen (starken) Entities ab.

Arzt Patientuntersucht

Datum

Untersuchung

hat

Partieller Schlüssel

Angehörige

Mitarbeiter

Schlüssel

1

N

a)

b)

Abb. 1.27: SchwacheEntity-Typen und identifi-zierende Beziehungen

Betrachten wir ein Beispiel für einen schwachen Entity-Typ in Abb. 1.27 (a). EinMitarbeiter kann beliebig viele Angehörige haben, aber ein Angehöriger ist höchs-tens einemMitarbeiter zugeordnet. Der Entity-Typ „Angehörige“ ist ein schwacherEntity-Typ und wird deshalb durch einen Doppelrahmen gekennzeichnet. Intuitivbedeutet dies, dass ein Angehöriger ohne den zugeordneten Mitarbeiter uninter-essant ist und nicht gespeichert werden muss.

identifizierender Bezie-hungstyp

Schwache Entities besitzen keine Schlüsselattribute. Um sie zu identifizieren, ver-wenden wir so genannte identifizierende Beziehungstypen. Wir verbinden alsoeinen schwachen Entity-Typ mit einem starken Entity-Typ. Dies wird durch eineRaute mit doppelter Umrandung dargestellt (siehe Abb. 1.27, a). Schwache Entity-Typen müssen immer mit Kardinalität 1 an den starken Entity-Typ verbundenwerden, denn der starke Entity-Typ wird benutzt, um den schwachen Entity-Typzu identifizieren. Da im Beispiel jeder Angehörige genau genau einem Mitarbei-


ter zugeordnet ist, kann man den Schlüssel des Mitarbeiters verwenden, um dieAngehörigen zu identifizieren.

M Merksatz 1.4: Schwache Entity-Typen

Ein schwacher Entity-Typ hat immer eine totale Teilnahme an einem identi-fizierenden Beziehungstyp.

partielles Schlüs-selattribut

Nun kann ein Mitarbeiter im vorgenannten Beispiel mehrere Angehörige haben,die man auch unterscheiden (identifizieren) können muss. Hierfür verwendet manein partielles Schlüsselattribut im schwachen Entity-Typen.

Schwache Entity-Typen können auch durch mehrere starke Entity-Typen identifi-ziert 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, wennes den Arzt und den Patienten gibt. Die Kombination beider bestimmt den Entity-Typ „Untersuchung“. Das Attribut „Datum“ ist ein partieller Schlüssel, über denmehrere Untersuchungen eines Arztes an dem gleichen Patienten unterschiedenwerden können. Zur eindeutigen Identifikation einer Untersuchung braucht manalso einen Arzt, einen Patienten und ein Datum.

K Kontrollaufgabe 1.13: Zusammenfassung ER-Modell

Machen Sie sich nochmals selbständig mit den Modellierungselementendes ER-Modells vertraut: Mit Hilfe welcher Konstrukte können Objekte derMiniwelt und deren Beziehungen abgebildet werden? Gehen Sie hierbeiauch auf die Begriffe „Intension“, „Extension“, „Typ“ und „Instanz“ ein!

1.5 Fragestellungen beim Entwurf

Wir haben nun alle wesentlichen Modellierungsinstrumente kennen gelernt undauch gesehen, dass man ein und denselben Sachverhalt auf ganz unterschiedli-che Arten modellieren kann. Die Frage ist also, wie man unter den Alternativenmöglichst gute Modelle auswählt.

1.5.1 Wozu braucht man schwache Entity-Typen?

Eine Frage lautet: Wann braucht man überhaupt schwache Entity-Typen? Mankönnte schließlich auch einen schwachen Entity-Typ als komplexes Attribut dar-stellen. Dies geht allerdings nicht, wenn mehrere identifizierende Entity-Typenim Spiel sind und wenn der schwache Entity-Typ mit weiteren Entity-Typen inBeziehung steht. Dies ist in Abb. 1.28 dargestellt.

Abb. 1.28: Schwa-cher Entity-Typ stehtmit weiteren Entity-Typen in Beziehung

Gebäude

Gebäude-Nr

liegt_in Raum1 N

Raum-Nr

läuft_in

1

VeranstaltungN

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 alsschwache Entities modelliert, d.h. zur Identifizierung eines Raumes benötigen wirdie 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 Zuordnungnicht möglich gewesen, denn schließlich kann man mit dem Beziehungstyp „läuftin“ 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 Fossili-ensammlung in verschiedenen Artenmodelliert worden: Die Entity-Typen „Fossil“,„Spezies“ und „Entdecker“ sollen sinnvoll durch Beziehungen verknüpft werden.

Fossil Fund Spezies

Entdecker

Spezies Gehört_zu Fossil

von

Entdecker

a)

b)

Fossil Spezies Entdecker

Abb. 1.29:Entwurfsalternativen

Eine (erste) Möglichkeit ist in Abb. 1.29 (a) dargestellt. Dort ist ein ternärer Bezie-hungstyp „Fund“ eingeführt worden, der ein Fossil mit einer Spezies und einemEntdecker 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 unbe-kannt ist, kann man den Fund noch nicht richtig eintragen. Beachten Sie bitte, dasses hier keineNULL-Werte geben kann, dennNULL-Werte gibt es im ER-Modell nurfür Attribute. Eine ternäre Beziehung setzt also immer exakt genau drei Entitieszueinander in Beziehung.

Welche Alternativen gibt es? Man könnte beispielsweise zwei binäre Beziehungs-typen verwenden. Dieser Ansatz ist in Abb. 1.29 (b) dargestellt. Dort sind die dreiEntity-Typen mit zwei binären Beziehungstypen „gehört zu“ und „von“ verknüpft.Bei der binären Darstellung kann die Fossil/Entdecker-Beziehung eingetragenund die Fossil/Spezies-Beziehung später nachgetragen werden.


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 werdensollen, ist kein Beziehungstyp in der Darstellung nötig (siehe Abb. 1.30). Sobaldman aber die Spezies oder den Entdecker als eigenständige Objekte darstellenoder mit anderen Entity-Typen in Beziehung setzen will, ist die Darstellung ohneBeziehungstypen nicht sinnvoll, denn hier existiert eine Spezies nur, wenn es einFossil gibt.

Abb. 1.30: Modelllierungohne Beziehungstyp

FossilSpezies

Entdecker

Name

Braucht man ternäre Beziehungstypen überhaupt?

Nachdem wir oben gesehen haben, dass ternäre Beziehungstypen in manchenFällen ungünstig sind, kann man die Frage stellen, ob man nicht jeden ternärenBeziehungstyp in eine Menge von binären Beziehungstypen umwandeln kann.Wenn dies so wäre, dann bräuchte man im Prinzip gar keine Beziehungstypenmit Grad größer als 2 anzubieten. Manche Modellierungswerkzeuge erlaubenbeispielsweise nur binäre Beziehungstypen. Ist man in diesen Werkzeugen inirgend einer Weise eingeschränkt in dem, was man modellieren kann?

Betrachten wir dazu den ternären Beziehungstyp in Abb. 1.31 (links). Dort sinddie Entity-Typen „Projekt“, „Teil“ und „Lieferant“ durch den Beziehungstyp „Lie-ferung“ verknüpft. Auf der rechten Seite ist der Versuch abgebildet, den ternärenBeziehungstyp durch drei binäre Beziehungstypen nachzubilden. Sind beide Dar-stellungen äquivalent?

Abb. 1.31: Model-lierungstypen sind

nicht äquivalent

Lieferant Lieferung

Projekt

Teil

Lieferant braucht

Projekt

Teil

beliefert

hat

Wie wir bereits oben gesehen haben, können wir in dem rechten Modell mit aus-schließlich binären Beziehungstypen darstellen, dass ein Teil von einemLieferantenkommt auch wenn es gar nicht von einem Projekt bezogen wird. Das geht mitdem ternären Beziehungstyp nicht. Die Frage ist nun: Steckt im linken Modellmit dem ternären Beziehungstyp auch eine Information, die im rechten Modellnicht abgebildet werden kann? Tatsächlich ist das der Fall: Nehmen wir an, es gibtzwei Lieferanten L1 und L2 die beide die gleichen Teile A und B liefern. BeideLieferanten beliefern die zwei gleichen Projekte P und Q. Im rechten Modell istnicht darstellbar, welcher Lieferant welches Teil an ein bestimmtes Projekt liefert.Will man das also darstellen, braucht man den ternären Beziehungstyp. Will mannun gleichzeitig auch darstellen können, dass ein Teil prinzipiell von einem Liefe-ranten lieferbar ist, ohne ein Projekt angeben zu müssen, dann braucht man einenzusätzlichen binären Beziehungstyp. Ein weiterer Unterschied wird deutlich, wennKardinalitäten ins Spiel kommen.

1.5 Fragestellungen beim Entwurf Seite 47

Betrachten Sie Abb. 1.32. Dort sind im gleichen Szenario wie zuvor Kardinalitätenin der Chen-Notation eingetragen. Hier wird dermittlerweile bekannte Sachverhaltmodelliert, dass ein bestimmtes Teil in einem Projekt immer vom gleichen Liefe-ranten kommt. Es besteht also eine funktionale Abhängigkeit zwischen Projekt,Teil und Lieferanten, die von unserem Datenbanksystem überwacht werden soll.

Lieferant Lieferung

Projekt

Teil

1

M

N

Abb. 1.32: Ternärer Bezie-hungstyp mit funktiona-ler Abhängigkeit

Kann man diese Bedeutung noch nachmodellieren mit binären Beziehungstypenund ohne zusätzliche Entity-Typen? Die Antwort lautet nein, denn in der Model-lierung aus Abb. 1.31 (rechts) kann man diese funktionale Abhängigkeit nichtnachbilden, 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 Bezie-hungstypen zurückzuführen, keine zusätzlichen Entity-Typen verwendet. Mankönnte auch überlegen, einen schwachen Entity-Typ zu verwenden, um ternäreBeziehungstypen darzustellen. Abb. 1.33 zeigt das Beispiel von eben, bei dem derternäre Beziehungstyp „Lieferung“ durch einen schwachen Entity-Typ gleichenNamens ersetzt wurde, der über drei identifizierende Beziehungstypen mit denanderen Entity-Typen verbunden ist. Beachten Sie, dass alle Beziehungstypen indiesem Beispiel binär sind.

Lieferant Lieferung

Projekt

Teil

Lieferant

Teil

Lieferung Projekt

Abb. 1.33: Nachbildungternärer durch binäreBeziehungstypen

Abb. 1.33 modelliert folgenden Sachverhalt: Jede Lieferung ist mit einem Lieferan-ten, einem Projekt und einem Teil verbunden (totale Teilnahme). In diesem Beispiel


hat „Lieferung“ keinen partiellen Schlüssel. Eine Lieferung wird also vollständigdurch 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 ausAbb. 1.32 auszudrücken?

Ein Versuch, diese Aufgabe zu lösen, ist in Abb. 1.34 dargestellt. Beachten Sie, dassder Beziehungstyp zwischen Lieferung und Lieferant nicht mehr identifizierendist. Die Lieferung wird jetzt nur noch durch die Beziehungstypen zu Projekt undTeil bestimmt, nicht mehr durch den Lieferanten. Zusätzlich ist jede Lieferunggenau einem Lieferanten zugeordnet. Also haben wir die Aufgabe in diesem Falltatsächlich gelöst!

Abb. 1.34: Nachbil-dung ternärer duch

binäre Beziehungsty-pen: Erster Versuch

Geht das aber in jedem Fall? Betrachten Sie dazu Abb. 1.35. Dort ist ein leichtverändertes Szenario abgebildet, das nicht mehr dargestellt werden kann. Dortwurde der ternäre Beziehungstyp durch die Angabe einer zusätzlichenKardinalitätmodifiziert. Nun bestimmt nicht mehr nur das Projekt und die Lieferung eindeutigden Lieferanten, sondern der Lieferant in Verbindung mit einem Teil bestimmt dasProjekt. Ob dies eine sinnvolle Bedingung ist, sei dahingestellt, aber man kann siebeschreiben.

Abb. 1.35: Nachbil-dung ternärer duch

binäre Beziehungsty-pen: Zweiter Versuch

Möchte man diese Situation mit binären Beziehungstypen darstellen und versuchtman denselben Ansatz wie oben (also mit schwachen Entity-Typen), dann läuftman 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 zwi-schen Lieferung und Projekt noch identifizierend ist. Die Lieferung (und somitder Lieferant) wird wie oben beschrieben durch das Projekt und das Teil eindeu-tig bestimmt. Hingegen bestimmt die Kombination aus Lieferant und Teil nichteindeutig das Projekt. Dies ist aber im Diagramm oben gefordert. Die funktionaleAbhängigkeit hinsichtlich des Projekts geht also verloren.

Abb. 1.36: Nachbildungternärer duch binäreBeziehungstypen: DritterVersuch

Alternativ könnte man natürlich auf die Idee kommen, das Diagramm wie inAbb. 1.36 zu zeichnen. Hier ist der Beziehungstyp zwischen Lieferant und Liefe-rung wieder identifizierend, hingegen ist der Beziehungstyp zwischen Lieferungund Projekt nicht identifizierend. Man kann nun zwar die funktionale Abhän-gigkeit von Lieferant und Teil zu Projekt beschreiben, nicht aber die im oberenDiagramm geforderte Abhängigkeit von Projekt, Teil zu Lieferant. Aus diesemDilemma gibt es kein Entrinnen, weil man sich bei Angabe eines Beziehungstypsentscheiden muss, ob er identifizierend ist oder nicht.

Es gibt also Situationen, in denen ternäre Beziehungstypen mächtiger sind als eineMenge binärer Beziehungstypen.

1.6 Zusammenfassung

Im vorausgegangenenAbschnitt habenwir das Entity-Relationship-Modell kennen-gelernt (ER-Modell). Das ER-Modell ist das am weitesten verbreitete semantischeDatenmodell. Es wird dazu benötigt, um die „Miniwelt“, die wir in unserer Daten-bank beschreiben wollen, zu beschreiben, ohne gleich die Implementierung derDatenbank vorweg zu nehmen. Zielvorgabe des Modells war es, eine möglichsteinfache Sprache zu haben, die auch ein Anwender versteht, und es gleichzeitig er-laubt, die wichtigsten Dinge im Modell möglichst präzise und unmissverständlichzu beschreiben.

Als wesentliche Modellierungsprimitive hatten wir Entity-Typen und Relationship-Typen (Beziehungstypen) kennengelernt. Ein Entity ist irgendetwas, was Sie in derDatenbank ablegen wollen, und ein Entity-Typ ist eine Beschreibung gleichartigerEntities. Entity-Typen besitzen beschreibende Merkmale, genannt Attribute. Einebesondere Art von Attributen sind die sogenannten Schlüsselattribute, die eserlauben, ein Entity eines Entity-Typs eindeutig zu identifizieren.

Entities werden über Beziehungstypen verknüpft, die auch für sich noch Attributehaben können. Beziehungstypen kann man noch genauer präzisieren, in dem manan die Kanten Kardinalitäten schreibt. Hierfür haben wir verschiedene Notationen


und ihre jeweiligen Vor- und Nachteile kennengelernt. Mittels der Chen-Notationbeispielsweise kann man funktionale Abhängigkeiten festlegen (durch Angabeeiner 1 an der Zielkante). Andere Arten von Kanten in der Chen-Notation bezeich-nen die totale Teilnahme eines Entity-Typs, d.h. jedes Entity dieses Typs nimmt anmindestens einer Beziehung teil. In der (min,max)-Notation hingegen kann manfestlegen, an wie vielen Beziehungen dieses Typs ein Entity mindestens teilnimmtund an wie vielen Beziehungen es höchstens teilnimmt.

Ein wichtiger Unterschied bei der Modellierung ist der zwischen Intension undExtension. Intension ist die abstrakte Beschreibung des Modells, die sich seltenändert. Die Extension ist die Menge der konkreten Ausprägungen, die sich überdie Zeit ändern kann.

Wenn zwei Entity-Typen mit einer Beziehung verknüpft werden, spricht man voneinem binären Beziehungstyp. Man kann aber auch beliebig viele Entity-Typenverknüpfen. Die Anzahl der verknüpften Entity-Typen nennt man den Grad desBeziehungstyps. Ternäre Beziehungstypen haben den Grad 3. Auch bei Bezie-hungstypenmit Grad größer als 2 kannmanmittels der Chen-Notation funktionaleAbhängigkeiten modellieren.

Der Vergleich von Chen-Notation mit der (min,max)-Notation hat ergeben, dassbeide Notationen nicht ineinander überführt werden können, denn einerseits gibtes 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 Exis-tenz anderer Entity-Typen abhängig sind und nur über deren Schlüssel-Attributeidentifiziert werden können. Abschließend haben wir noch gesehen, dass ternäreBeziehungstypen nur zum Teil durch binäre Beziehungstypen ausgedrückt werdenkönnen.

1.7 Übungen Seite 51

1.7 Übungen

Fast alle Aufgaben des Moduls „Konzeptionelle Modellierung“ können mit Pa-pier und Bleistift gelöst werden. Darüber hinaus können Sie gerne die Modelleelektronisch erstellen. Zur ER-Modellierung gibt es viele kommerzielle Modellie-rungswerkzeuge, aber auch kostenlose oder Open-Source-Werkzeuge. „Dia“ istein Programm zum Zeichnen von Diagrammen, vergleichbar mit MS Visio undentstammt der Linux-Gemeinde. Mittlerweile gibt es Dia ebenfalls fürWindows be-quem zum Installieren unter http://dia-installer.de/. Es besteht jedoch keinePflicht zur Nutzung von Dia oder anderer Werkzeuge.

ÜÜbung 1.1: 3-Schema-Architektur

Die 3-Schema-Architektur (ANSI/SPARC, 1975) trennt 3 Arten von Metada-ten strikt: Internes, konzeptionelles und externes Schema. Beschreiben Siedie drei Schemata in Stichworten.

ÜÜbung 1.2: konzeptioneller vs. logischer Entwurf

Charakterisieren Sie den Begriff „konzeptioneller Entwurf“ und „logischerEntwurf“ der Datenmodellierung, indem Sie Ausgangsbasis und Ergebnisin Stichwörtern notieren.

ÜÜbung 1.3: erste Entwurfsaufgabe

Zur besseren Unterstützung diverser Dienste soll in Ihrem beruflichen Kon-text zentral ein DBS eingesetzt werden. Falls Sie keinen beruflichen Kontexthaben, wählen Sie als Kontext die Friedrich-Alexander-Universität (FAU)Erlangen-Nürnberg.

1. Überlegen Sie sich exemplarisch, welche Daten verwaltet werdenmüs-sen, welche unterschiedlichen Benutzergruppen es gibt, wie häufigdiese auf die Daten zugreifen und welche Anwendungsprogrammebenötigt werden. (Für den Kontext der FAU orientieren Sie sich bei-spielsweise an den Diensten EST, UnivIS undMeinCampus, falls Siediese kennen.)

2. Würden sich die von Ihnen identifizierten Funktionalitäten auch ohneein DBS umsetzen lassen? Welche Vor- und Nachteile ergäben sichaus dem Verzicht auf die Nutzung eines DBS?

Werden Sie nicht zu schnell zu technisch, denken Sie noch nicht in formalenNotationen sondern eher umgangssprachlich.

ÜÜbung 1.4: Krankenhaus-Szenario, Teil 1

In dieser Übung sollen Sie ein konkretes Szenario mittels eines ER-Diagramms in Chen-Notation modellieren.

Vorbemerkungen: In dieser Aufgabenstellung trennen wir Entities nochbewusst von Relationships, um Ihnen den Einstieg in die Modellierung zu

http://dia-installer.de/


erleichtern. Normalerweise vermischen sich diese in der Beschreibung. Dadie Beschreibung zu Entities oft Zustandsverben enthält, um bloße Attributezu beschreiben ist es bei Anforderungsspezifikationen aus der realen Weltnicht unbedingt so einfach, Entitäten, Beziehungen und Attribute auseinan-derzuhalten.

In der Formulierung der Beziehungen sind die Kardinalitätseinschränkun-gen genau zu beachten. Im Allgemeinen gilt: alles was nicht explizit einge-schränkt ist, muss im Modell auch uneingeschränkt bleiben (bitte also keineEinschränkungen einfach in eine Beschreibung hineininterpretieren). Alleswas explizit eingeschränkt ist, darf imModell nicht einfach uneingeschränktbleiben (alle formulierten Einschränkungen sind also zu erkennen).

Bitte verwenden Sie ab jetzt die Chen-Notation. Modellieren Sie die folgen-den 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 werdenweitere Daten wie Vorname, Nachname und Adresse gespeichert.


ÜÜbung 1.5: Krankenhaus-Szenario, Teil 2

Es folgt eine weitere narrative Beschreibung von Relationships desKrankenhaus-Szenarios. Modellieren Sie die folgenden Entities und Relati-onships 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ürjeden 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 Arztist stets ein Angestellter.

ÜÜbung 1.6: Erweiterung des Krankenhaus-Szenarios

Lernziel ist hier, Entity-Typen und Relationship-Typen zu modellieren, de-ren Beschreibungen sich vermischen und die teilweise unvollständig sind.Modellieren Sie die folgenden Entities und Relationships wieder in Chen-Notation.

1. Gebühren• Wir würden gerne Patienten Leistungen in Rechnung stellen.

Zu jeder Leistung speichern wir die Beschreibung der medizi-nischen Leistung und den jeweiligen Preis. Identifiziert werdensie durchDRG-Codeswie z.B. „B70A“ (einemEU Standard, derauf ICD-10 und OPS basiert). Rechnungen haben eine eindeu-tige Rechnungsnummer. Eine Rechnung geht an genau einenPatienten. 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 Angestell-ten.(Zusatzfrage: Woran erkennt man den obersten Boss?)(Gibt es nur einen obersten Boss oder kann man damit Unter-nehmen mit einer Art „Vorstand“ modellieren?)


ÜÜbung 1.7: weitere Fragen zum Krankenhaus-Szenario

1. Welcher Beziehungstyp ergibt sich, wenn wir die Aussage „Wegensteigendem Kostendruck im Gesundheitswesen soll es für jeden Pati-enten höchstens einen verantwortlichen Arzt geben“ zu „Ein Patienthat mindestens einen verantwortlichen Arzt“ umformulieren?

2. Können wir „Abteilung“ als komplexes (zusammengesetzt/mehrwer-tig) 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 mo-dellieren?

ÜÜ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 Chen-Notation.

• An der Universität werden verschiedene Kurse angeboten. Jeder Kurswird über ein eindeutiges Kürzel identifiziert. Darüber hinaus besit-zen alle Kurse einen Namen und eine Beschreibung.

• Universitätsangestellte können zudem für ihre Kurse Voraussetzun-gen zur Teilnahme angeben.

• Ein Semester ist definiert durch einen Namen, der zusammengesetztist aus dem Jahr und einem Semesterkürzel (WS/SS für Wintersemes-ter und Sommersemester).

• Universitätsangestellte werden über eine Personalnummer identifi-ziert und besitzen darüber hinaus einen Namen und weitere Kontakt-informationen.

• Eine Studienrichtung ist eindeutig identifiziert durch den Namen desAbschlusses und die Spezialisierung. Diese besteht aus Schwerpunkt-fächern und Hauptfächern. Die Studienrichtung hat eine Fachprü-fungsordnung und eine Studienordnung.

• Studenten können beliebig viele Kurse besuchen. Dabei gibt es keineBeschränkung der Teilnehmerzahl pro Kurs.

• Alle Studenten besitzen eine Matrikelnummer sowie einen Namen.Jeder Student studiert mindestens eine Studienrichtung. Für jede Stu-dienrichtung eines Studentenwird die aktuelle Zahl der Fachsemestervermerkt.

• Studenten können sich über Kurse prüfen lassen. Ein Student kannvon einem Universitätsangestellen in beliebig vielen Kursen geprüftwerden. Eine Prüfung über einen bestimmten Kurs kann jedoch voneinem Studenten nur bei genau einem Universitätsangestellten abge-legt werden. Ein Universitätsangesteller kann in einem Kurs mehrereStudenten prüfen.

• EinKurs, der von einemUniversitätsangestellen in einemSemester un-


terrichtet wird, kann für beliebig viele Studienrichtungen angebotenwerden. Findet ein Kurs in einem Semester für eine Studienrichtungstatt, kann dieser von mehreren Universitätsangestellen gehalten wer-den. Ein Kurs, der von einem Universitätsangestellen für eine Studi-enrichtung angeboten wird, kann in mehreren Semestern stattfinden.In einem Semester kann ein Angestellter für eine Studienrichtungmehrere Kurse halten. In jedem Semester wird unterrichtet. Für jedeStudienrichtung gibt es Unterrichtsangebote. Wenn ein Kurs stattfin-det, werden zusätzliche Informationen benötigt: Der Veranstaltungs-ort, die Veranstaltungstermine (jeweils mit Wochentag, Beginnzeitund Endzeit), sowie die Anzahl der Semesterwochenstunden.

Liste der Lösungen zu den Kontrollaufgaben Seite 57

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“ ko-diert.


Zur Unterscheidung der Begriffe DB, DBMS und DBS sagt in der Regel ein Bild mehrals tausend Worte (siehe Abb. 1.5 auf Seite 16). Wesentliche Punkte sind:

• Datenbank: Sammlung logisch zusammenhängender Daten.

• Datenbank-Managementsystem: Software zur Verwaltung (Definition, Mani-pulation) von Daten einer Datenbank.

• Datenbanksystem: DB + DBMS

• Datenbankanwendung: Eine Anwendung, die mit einem DBS kommuniziert.


Die Vorteile einer mehrschichtigen Architektur beim Entwurf von Datenbanken liegtin der Entkopplung funktionaler Einheiten: Wir wollen z. B. unsere Speicherungs-strukturen optimieren, ohne im SQL-Code etwas zu verändern. Auch die Anwendungsoll es nicht groß tangieren, wenn wir etwa auf ein anderes DBMS umsteigen.


Die zwei Haupteigenschaften eines konzeptionellen Schemas sind Anwendungsneu-tralität und Datenunabhängigkeit.

Anwendungsneutralität bezieht sich auf die Trennung vom konzeptionellen Sche-ma zum externen Schema (zur Anwendung hin, also nach „oben“ in Abb. 1.7).Datenunabhängigkeit bezieht sich auf die Trennung vom konzeptionellen Schemazum internen Schema (zu konkreten Speicherstrukturen hin, also nach „unten“ inAbb. 1.7).


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 desEntity-Typs „Mitarbeiter“.

Dieser Fall modelliert die „Position“ als Konzept unabhängig vom Projekt. Ein Mit-arbeiter hätte dann möglicherweise eine Position, auch wenn er in keinem Projektarbeitet. Dies wäre durchaus sinnvoll, wenn „Position“ wie ein „Rang“ verstandenwürde (wie „Partner“ vs. „Berater“ bei Unternehmensberatungen oder in der Arteines militärischen Ranges).

Was ist, wenn ein Mitarbeiter in mehreren Projekten arbeitet? Macht es Sinn, dasAttribut „Position“ an den Entity-Typ „Projekt“ zu heften?

Dies macht keinen Sinn, denn eine Position ist immer nur in einer Verbindung vonProjekt und einem Mitarbeiter sinnvoll. Wenn ein Mitarbeiter in mehreren Projekten

Seite 58 Liste der Lösungen zu den Kontrollaufgaben

arbeitet, gibt es zudem mehrere Instanzen der Relationship „arbeitet in“, die jedeeinen eigenen Attributwert „Position“ besitzt.


Sind alle Entity- und Relationship-Typen in Abb. 1.13 auf Seite 26 vorhanden?

Ja.


Betrachten Sie wieder das Diagramm im Abb. 1.13 auf Seite 26. Die Antwortenlauten:

1. Jeder Mitarbeiter arbeitet in genau einer Abteilung: Ja, da totale Teilnahmeund Kardinalität 1.

2. Es kann Mitarbeiter geben, die in keiner Abteilung arbeiten: Nein, da totaleTeilnahme der Mitarbeiter.

3. Es kann Abteilungen geben, in denen keine Mitarbeiter arbeiten: Nein, datotale Teilnahme auf beiden Seiten.

4. Jeder Mitarbeiter leitet eine Abteilung: Nein, da keine totale Teilnahme aufSeiten der Mitarbeiter.

5. Jeder Mitarbeiter leitet mindestens eine Abteilung: Nein, da keine totaleTeilnahme auf Seiten der Mitarbeiter.

6. Es kann Abteilungen geben, die durch keinen Mitarbeiter geleitet werden:Nein, da totale Teilnahme der Abteilung.


Totale Teilnahme von E1 an R würde man in der (min,max)-Notation durch eineMindestangabe von 1 auf der Kante von E1 zu R ausdrücken.


Das komplexe Attribut aus Beispiel 1.4 auf Seite 32 könnte in grafischer Notationetwa so aussehen:

Kontaktinfo

Telefon

Vorwahl Nummer

Adresse

OrtPLZStrasse

HausnummerName


Wie kann man die Darstellung aus Abb. 1.19 auf Seite 36 verbessern, damit dasModell auch ausdrücken kann, dass ein Arzt einen Patienten an mehreren verschie-denen Terminen untersucht hat?

Liste der Lösungen zu den Kontrollaufgaben Seite 59

Man könnte das Attribut „Datum“ als mehrwertiges Attribut definieren. So hat dieBeziehung 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 zubringen. Datum wäre dann ein Attribut von „Untersuchung“.


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“ denWert 1, bei der zweiten Bedingung N. Im ersten Fall wird eine funktionale Abhängig-keit definiert: Mitarbeiter und Projekt zusammen bestimmen eindeutig den Ort.

Dieser Sachverhalt gilt analog für die letzten beiden Bedingungen.


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 Seminarthemabearbeiten und dasselbe Seminarthema nicht bei unterschiedlichen Universitätsan-gestellten.

Es ist jedoch weiterhin möglich, ein Seminarthema an verschiedene Studenten zuvergeben. Jeder Student, jeder Universitätsangestellte und jedes Seminarthemakö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, dassein Student dasselbe Seminarthema mehr als einmal bearbeitet. Die ursprünglichenKonsistenzbedingungen werden hiermit verletzt, die Semantik der beiden Notationenist also nicht äquivalent.

Student

Seminarthema

UniversitätsangestellterbetreuenN 1

1(0,N)

(0,N)

(0,N)


In dieser Aufgabe geht es um die allgemeine Rekapitulation der Modellierungsele-mente des ER-Modells. Hier ein stichpunktartiger Überblick:

Seite 60 Liste der Lösungen zu den Kontrollaufgaben

Begriff Erklärung MementoEntity Objekt der Miniwelt 4 Eigenschaften: Bier

Relationship Beziehung zwischen Entities Identifiziert durch TeilnehmerInstanz Ausprägung, Exemplar Verwechslungsgefahr: Entity ist kein Typ.

Typ Schablone, Prägeform Entspricht Intension.Extension Menge von Instanzen 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 niemalsdurch ihre Attribute! Das bedeutet für unser Beispiel „Arzt untersucht Patientan einem Datum“: Wenn „Datum“ ein Attribut ist, kann eine Untersuchungnur über Arzt und Patient identifiziert werden. Dann kann ein Arzt einenPatienten nur einmal untersuchen, weil ein Datum nicht zur Identifikation derRelationship-Instanz verwendet werden kann!

• Oftmals wird man auf ein ER-Diagramm deuten und etwas wie „Dieses Entityda“ sagen. Dabei meint man selbstverständlich „Entity-Typ“, obwohl „Entity“eigentlich „Entity-Instanz“ bedeutet. Machen Sie sich stets den Unterschiedzwischen Typ und Instanz klar!

• Zu Instanzen, Typen/Intension und Extensionen: Angestellter 127-FM ist eineInstanz des Typs „Angestellter“. Die Tabelle, in der alle Angestellten die-ser Firma stehen, enthält die Extension, also die Menge aller (relevanten)Angestellten.

Verzeichnisse Seite 61

Verzeichnisse

I. Abbildungen

Abb. 1.1: Daten und Informationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Abb. 1.2: Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Abb. 1.3: Benutzerspezifische Datenhaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Abb. 1.4: Eine anwendungsunabhängige Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Abb. 1.5: Datenbankmanagementsystem (DBMS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Abb. 1.6: Inhalt einer Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Abb. 1.7: 3-Schema-Architektur einer Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Abb. 1.8: Wie komme ich zum Schema? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Abb. 1.9: Datenmodellierung an Hand eines Minimodells . . . . . . . . . . . . . . . . . . . . . . . . . 20Abb. 1.10: Phasen des Datenbankenentwurfs (nach Elmasri and Navathe [2000]) . . . . . . . . . . . . 21Abb. 1.11: Entity-Typ mit Attributen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Abb. 1.12: Beispiel für Relationship-Typ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Abb. 1.13: ER-Diagramm einer Personalverwaltung (zur besseren Lesbarkeit rotiert) . . . . . . . . . . . 26Abb. 1.14: Entity- und Relationship-Typen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Abb. 1.15: Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Abb. 1.16: Relationship-Typen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Abb. 1.17: Entity, Attribute, Attributwerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30Abb. 1.18: Relationships: Intension und Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Abb. 1.19: Darstellung einer falschen Beziehung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Abb. 1.20: Beziehungstypen vom Grad 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Abb. 1.21: Rekursiver Beziehungstyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Abb. 1.22: Kardinalität von Beziehungstypen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Abb. 1.23: Chen-Notation für Kardinalitäten bei binären Beziehungstypen . . . . . . . . . . . . . . . . . 40Abb. 1.24: Chen-Notation für Kardinalitäten bei ternären Beziehungstypen . . . . . . . . . . . . . . . . 41Abb. 1.25: Chen-Notation und (min, max)-Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Abb. 1.26: (min, max)-Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Abb. 1.27: Schwache Entity-Typen und identifizierende Beziehungen . . . . . . . . . . . . . . . . . . . 43Abb. 1.28: Schwacher Entity-Typ steht mit weiteren Entity-Typen in Beziehung . . . . . . . . . . . . . . 44Abb. 1.29: Entwurfsalternativen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Abb. 1.30: Modelllierung ohne Beziehungstyp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Abb. 1.31: Modellierungstypen sind nicht äquivalent . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46Abb. 1.32: Ternärer Beziehungstyp mit funktionaler Abhängigkeit . . . . . . . . . . . . . . . . . . . . . 47Abb. 1.33: Nachbildung ternärer durch binäre Beziehungstypen . . . . . . . . . . . . . . . . . . . . . . 47Abb. 1.34: Nachbildung ternärer duch binäre Beziehungstypen: Erster Versuch . . . . . . . . . . . . . . 48Abb. 1.35: Nachbildung ternärer duch binäre Beziehungstypen: Zweiter Versuch . . . . . . . . . . . . . 48Abb. 1.36: Nachbildung ternärer duch binäre Beziehungstypen: Dritter Versuch . . . . . . . . . . . . . 49

II. Beispiele

Beispiel 1.1: Modelle in der Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Beispiel 1.2: Library of Congress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Beispiel 1.3: Personalverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Beispiel 1.4: komplexe Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Beispiel 1.5: binäre Beziehungstypen als Tupel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Beispiel 1.6: Beziehungsmenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Beispiel 1.7: N : M-Beziehung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Beispiel 1.8: N : 1-Beziehung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Beispiel 1.9: 1 : 1-Beziehung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Seite 62 Verzeichnisse

III. Definitionen

Definition 1.1: Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Definition 1.2: Attribut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Definition 1.3: Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Definition 1.4: Beziehungstyp (formal) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

IV. Exkurse

Exkurs 1.1: Wertebereiche von Attributen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Exkurs 1.2: Sprachphilosophie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

V. Kontrollaufgaben

Kontrollaufgabe 1.1: ASCII-Codierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Kontrollaufgabe 1.2: Grundbegriffe der Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Kontrollaufgabe 1.3: Vorteile mehrschichtiger Architektur . . . . . . . . . . . . . . . . . . . . . . . . . 19Kontrollaufgabe 1.4: Eigenschaften eines konzeptionellen Schemas . . . . . . . . . . . . . . . . . . . 20Kontrollaufgabe 1.5: Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Kontrollaufgabe 1.6: Überprüfung des Beispiels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Kontrollaufgabe 1.7: totale Teilnahme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Kontrollaufgabe 1.8: totale Teilnahme und (min,max)-Notation . . . . . . . . . . . . . . . . . . . . . . 29Kontrollaufgabe 1.9: komplexe Attribute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Kontrollaufgabe 1.10: Modellierungsalternativen beim Beziehungstyp . . . . . . . . . . . . . . . . . . . 37Kontrollaufgabe 1.11: Kardinalitäten und funktionale Abhängigkeiten . . . . . . . . . . . . . . . . . . . 41Kontrollaufgabe 1.12: (min, max)-Notation vs. Chen-Notation bei dreistelligen Beziehungstypen . . . . 43Kontrollaufgabe 1.13: Zusammenfassung ER-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

VI. Tabellen

Tabelle 1.1: Darstellung einer Beziehungsmenge als Tabelle . . . . . . . . . . . . . . . . . . . . . . . . 36

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 Seite 63

Erhard Rahm. Mehrrechner-Datenbanksysteme. Oldenbourg-Verlag, 1994.

Hermann Sauer. Relationale Datenbanken. Addison-Wesley Verlag, 2002.

[KonzMod] - News | IT-Sicherheitsinfrastrukturen ... · TR75 27 UX-11 TR-78 EC-1 XVG VCR CAMC VIDEO...

Documents

Transcript of [KonzMod] - News | IT-Sicherheitsinfrastrukturen ... · TR75 27 UX-11 TR-78 EC-1 XVG VCR CAMC VIDEO...