Semantische Datenmodellierung Teil 2: Extended Entity Relationship Modell. Hans-Georg Hopf



Ähnliche Dokumente
ER-Modell. Entity-Relationship-Model

1 Mathematische Grundlagen

Inhaltsverzeichnis. 1. Fragestellung

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken

Entity-Relationship-Modell. Ein Studierender kann (oder muss) mehrere Vorlesungen hören. Eine Vorlesung wird i.a. von mehrerer Studierenden gehört.

ER-Modellierung am Beispiel der Universitätsdatenbank aus der DBIS-Vorlesung

Vom Entity-Relationship-Modell (ERM) zum relationalen Datenmodell (RDM)

Fachdidaktik der Informatik Jörg Depner, Kathrin Gaißer

Lineargleichungssysteme: Additions-/ Subtraktionsverfahren

Stellen Sie bitte den Cursor in die Spalte B2 und rufen die Funktion Sverweis auf. Es öffnet sich folgendes Dialogfenster

Systemanalyse. - Folien zur Vorlesung für AI3 im Sommersemester Teil 4 -

Willkommen zum DBS I Praktikum!

How to do? Projekte - Zeiterfassung

1. Man schreibe die folgenden Aussagen jeweils in einen normalen Satz um. Zum Beispiel kann man die Aussage:

Grundbegriffe der Informatik

Kapitel 04 Strukturiertes Entity-Relationship-Modell. 4 Strukturiertes Entity-Relationship- Modell

3. Das Relationale Datenmodell

Lineare Gleichungssysteme

Bedienungsanleitung. Matthias Haasler. Version 0.4. für die Arbeit mit der Gemeinde-Homepage der Paulus-Kirchengemeinde Tempelhof

In diesem Thema lernen wir die Grundlagen der Datenbanken kennen und werden diese lernen einzusetzen. Access. Die Grundlagen der Datenbanken.

Das Entity-Relationship-Modell

Austausch- bzw. Übergangsprozesse und Gleichgewichtsverteilungen

4. BEZIEHUNGEN ZWISCHEN TABELLEN

2.5.2 Primärschlüssel

Professionelle Seminare im Bereich MS-Office

Kapitel DB:III. III. Konzeptueller Datenbankentwurf

1 topologisches Sortieren

Übungsblatt 4. Aufgabe 7: Datensicht Fachkonzept (Klausur SS 2002, 1. Termin)

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem

Mathematik. UND/ODER Verknüpfung. Ungleichungen. Betrag. Intervall. Umgebung

Primzahlen und RSA-Verschlüsselung

Datenbankmodelle 1. Das Entity-Relationship-Modell. Prof. Dr. Bernhard Schiefer 2-1

Einführung in Datenbanken

TYPO3 Super Admin Handbuch

EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0. EDV Kurs 13/2

Berechnungen in Access Teil I

Datenbankmodelle 1. Das Entity-Relationship-Modell

Hilfe zur Urlaubsplanung und Zeiterfassung

4 Grundlagen der Datenbankentwicklung

SharePoint Demonstration

Datenbanken I - Übung 1

Suche schlecht beschriftete Bilder mit Eigenen Abfragen

Kapitel 4 Die Datenbank Kuchenbestellung Seite 1

Import von Angeboten in die BildungsDatenbank mit Hilfe des Excel-Templates

Datenbanken Kapitel 2

4.4 AnonymeMärkteunddasGleichgewichtder"vollständigen Konkurrenz"

WS 2002/03. Prof. Dr. Rainer Manthey. Institut für Informatik III Universität Bonn. Informationssysteme. Kapitel 1. Informationssysteme

Basis und Dimension. Als nächstes wollen wir die wichtigen Begriffe Erzeugendensystem und Basis eines Vektorraums definieren.

Systemen im Wandel. Autor: Dr. Gerd Frenzen Coromell GmbH Seite 1 von 5

SWE5 Übungen zu Software-Engineering

Zeichen bei Zahlen entschlüsseln

Benutzeranleitung Superadmin Tool

IT-Kompaktkurs. Datenbanken Skript zur Folge 5. Prof. Dr. Georg Herde Fachhochschule Deggendorf

«Eine Person ist funktional gesund, wenn sie möglichst kompetent mit einem möglichst gesunden Körper an möglichst normalisierten Lebensbereichen

Jede Zahl muss dabei einzeln umgerechnet werden. Beginnen wir also ganz am Anfang mit der Zahl,192.

ARCO Software - Anleitung zur Umstellung der MWSt

Informationsblatt Induktionsbeweis

Datenbanken. Erstellen des Semantischen Modells. Manuel Friedrich. Schiller-Gymnasium Hof

Abamsoft Finos im Zusammenspiel mit shop to date von DATA BECKER

Data Mining: Einige Grundlagen aus der Stochastik

7. Übung - Datenbanken

geben. Die Wahrscheinlichkeit von 100% ist hier demnach nur der Gehen wir einmal davon aus, dass die von uns angenommenen

Auf der linken Seite wählen Sie nun den Punkt Personen bearbeiten.

Softwaretechnologie -Wintersemester 2013/ Dr. Günter Kniesel

Daten-Synchronisation zwischen dem ZDV-Webmailer und Outlook ( ) Zentrum für Datenverarbeitung der Universität Tübingen

Diese Ansicht erhalten Sie nach der erfolgreichen Anmeldung bei Wordpress.

Was ist Sozial-Raum-Orientierung?

Codex Newsletter. Allgemeines. Codex Newsletter

Was meinen die Leute eigentlich mit: Grexit?

my.ohm Content Services Autorenansicht Rechte

Objektorientierte Programmierung OOP

Erstellen einer digitalen Signatur für Adobe-Formulare

Software Engineering Klassendiagramme Assoziationen

3. GLIEDERUNG. Aufgabe:

AZK 1- Freistil. Der Dialog "Arbeitszeitkonten" Grundsätzliches zum Dialog "Arbeitszeitkonten"

5. Bildauflösung ICT-Komp 10

Ein Schlüssel ist eine Menge von Attributen (also eines oder mehrere), die eine Datenzeile (Tupel) einer Tabelle eindeutig identifiziert

impact ordering Info Produktkonfigurator

Anwendungshinweise zur Anwendung der Soziometrie

Kapiteltests zum Leitprogramm Binäre Suchbäume

3. Zusammenhang. 22 Andreas Gathmann

HANDBUCH PHOENIX II - DOKUMENTENVERWALTUNG

Vermeiden Sie es sich bei einer deutlich erfahreneren Person "dranzuhängen", Sie sind persönlich verantwortlich für Ihren Lernerfolg.

4. Jeder Knoten hat höchstens zwei Kinder, ein linkes und ein rechtes.

Um zusammenfassende Berichte zu erstellen, gehen Sie folgendermaßen vor:

Im Folgenden wird Ihnen an einem Beispiel erklärt, wie Sie Excel-Anlagen und Excel-Vorlagen erstellen können.

Binärdarstellung von Fliesskommazahlen

Konzepte der Informatik

SDD System Design Document

Darstellung von Assoziationen

Motivation. Formale Grundlagen der Informatik 1 Kapitel 5 Kontextfreie Sprachen. Informales Beispiel. Informales Beispiel.

Handbuch zur Anlage von Turnieren auf der NÖEV-Homepage

Fundamentals of Software Engineering 1

Übung 1. Ziel: Statisches Modell (Klassendiagramm) aus allgemeiner Beschreibung erstellen.

3.2 Spiegelungen an zwei Spiegeln

Zusatzmodul Lagerverwaltung

Übung Datenbanksysteme

Anwendungsbeispiele Buchhaltung

-Inhalte an cobra übergeben

Einleitung: Frontend Backend

Transkript:

Semantische Datenmodellierung Teil 2: Extended Entity Relationship Modell Hans-Georg Hopf 26. März 2004

Inhaltsverzeichnis 1 EER-Modell 2 1.1 Objektklassen............................ 3 1.2 Beziehungen............................ 4 1.2.1 Beziehungsobjektklassen................. 4 1.2.1.1 Grad einer Beziehung.............. 10 1.2.1.2 Rolle....................... 10 1.2.1.3 Kardinalität.................... 13 1.2.1.4 Objektbeteiligung................ 20 1.2.1.5 Kardinalitätskonzept............... 24 1.2.1.6 Namensgebung................. 25 1.2.2 Schwache Objektklasse.................. 25 1.2.3 Gerund........................... 27 1.3 Objekthierarchien.......................... 29 1.4 Darstellungshilfen......................... 33 1.4.1 Attribute........................... 33 1.4.2 Restriktionen........................ 33 1.4.3 Kategorisierung...................... 34 1.4.4 Gruppierung........................ 35 1.5 Übersicht.............................. 36 1.6 Übungen.............................. 39 Was Sie nach der Bearbeitung dieses Teils kennen und können sollten: Sie erfahren, welche Modellierungskonstrukte die Extended Entity Relationship Modellierungssprache zur Verfügung stellt. 1

Kapitel 1 Entity-Relationship-Modell Mit Hilfe von Relationen formulierte Datenmodelle haben einige gravierende Nachteile: Es stellt sich die Frage: Wann ist ein relationales Datenmodell (Relationenmodell) ein gutes Datenmodell? bzw. Was zeichnet ein gutes Datenmodell aus? Die einzelnen Relationen sind häufig in ihrer Struktur mit Mängeln behaftet. Diese Mängel machen sich, wie wir im Kapitel?? gesehen haben, allerdings oft erst im operationellen Umgang mit den Tabellen bemerkbar und drücken sich durch sogenannte Update-, Insert- und Delete-Anomalien aus. Ein vergleichsweise aufwendiges mathematisches Verfahren, die sog. Normalisierung, muss eingesetzt werden, um die in der Datenstruktur vorhandenen strukturellen Mängel aufzudecken und zu beseitigen. Die in einem Modell formulierten Relationen bzw. Tabellen sind üblicherweise nicht voneinander unabhängig. Über Fremdschlüssel sind Relationen untereinander verbunden. Fremdschlüssel vermittel jedoch Beziehungen verschiedenster Art und Ausprägung. Die Darstellung dieser relationsübergreifenden Beziehungen wird durch im Relationenmodell nur unzureichend unterstützt. Die Bedeutung der Beziehungen bleibt unberücksichtigt. Ein wesentlicher Teil der Aussagekraft eines Datenmodells wird gerade durch Beziehungen zwischen den Objektklassen bestimmt. Die unzureichende Darstellung dieser Objektbeziehungen ist damit ein echter Mangel des Relationenmodells. Ein semantisches Datenmodell soll die oben beschriebenen Nachteile beheben. Ein sehr erfolgreich eingesetztes semantisches Datenmodell ist das Entity- Relationship (ER) - Modell. Es gibt verschiedene Varianten dieses ursprünglich von Chen [CHE 76 ] eingeführten graphischen Modellierungsverfahrens. Sie unterscheiden sich nicht nur in der Ausgestaltung der verwendeten graphischen Symbole, sondern auch im ausdrückbaren Informationsgehalt. 2

1.1. OBJEKTKLASSEN KAPITEL 1. EER-MODELL Ein bezüglich der Repräsentation von Semantik besonders aussagekräftiges und in seiner graphischen Darstellung sehr übersichtliches Modell ist das Extended-Entity-Relationship (EER) - Modell von Teory, Yang und Fry (siehe [TEO 86, TEO 90 ]). Dieses Modell, erweitert um einige in der praktischen Modellierung sehr nützliche Konstrukte, soll hier vorgestellt werden. Grundelemente des EER-Modells, die im folgenden detailliert erläutert werden, sind: (eigenständige) Objektklassen (entity-sets) Beziehungsobjektklassen (relationship-sets) schwache Objektklassen (weak entity-sets) Gerund (view aggregation) Generalisation (generalization) Objektkategorien (category) 1.1 Objektklassen (entity-sets) Als erstes wenden wir uns der Beschreibung von sogenannten eigenständigen Objektklassen zu. Ein Datenmodellobjekt (entity) beschreibt eine eigenständige reale oder erdachte Einheit, der realen Welt oder abstrakten Gedankenwelt, über die Informationen zusammengetragen werden sollen. Eigenständige Objekte können ohne Rückgriff auf andere Objekte eindeutig identifiziert und näher beschrieben werden. Diese Identifikation und Beschreibung von Objekten geschieht durch Attribute und die ihnen zugeordneten Attributwerte. Objekte mit gleichen Attributen (aber üblicherweise verschiedenen Attributwerten) können zu Objektklassen (entity sets) zusammengefaßt werden. Relationen (Tabellen) sind z.b. Repräsentanten solcher Objektklassen. Jedes Tupel (Zeile) einer Relation (Tabelle) entspricht einem Objekt (entity). Für viele Überlegungen reicht es jedoch, die Struktur einer Objektklasse zu erfassen, ohne auf einzelne Objekte im Detail einzugehen. Das bedeutet, dass für eine Objektklasse die Attributstruktur erfaßt wird, die einzelnen Objekte mit ihren Attributwerten jedoch keine Rolle spielen. Dem trägt das EER- Modell Rechnung durch ein Konstrukt, das als Objektklasse oder Entity-Set bezeichnet wird (siehe Abbildung 1.1). In der Abbildung 1.1 ist eine mathematische Darstellung angegeben, wie wir sie zur Definition von Relationen benutzt haben. Daneben findet sich die EER- Darstellung einer Objektklasse. Beide Darstellungen beschränken sich auf die Angabe der Attributstruktur. Im Gegensatz dazu gibt die tabellarische Darstellung der Objektklasse die einzelnen Objekte (Entities) mit den zugehörigen Attributwerten an. Zusammenfassend läßt sich bezüglich der EER-Darstellung einer Objektklasse feststellen: Version 1.0 / 26. März 2004 3 c H.-G. Hopf

Alle Objekte (Entities) eines Typs sind als Menge zusammengefaßt in dieser Objektklasse (dem Entity-Set), zu finden. Das Datenmodell-Konstrukt beschreibt nur den Typ der Objekte einer Objektklasse, durch die Angabe der Attribute, nicht jedoch die Ausprägung einzelner, individueller Objekte mit ihren Attributwerten (Entities). In graphischer Notation benutzt man folgende Darstellungsformen: Die Objektklasse wird durch Angabe des Objektklassennamens und aller relevanten Attribute näher beschrieben. Der Objektklassennamen wird in ein Rechteck eingetragen. Die Attribute werden durch Verbindungslinien dem Rechteck zugeordnet. Attribute, die den Primärschlüssel bilden, werden im Unterschied zu den restlichen Attributen durch Unterstreichen besonders gekennzeichnet. Vergröbert man die Granularität in der Darstellung, kann auch noch auf die detaillierte Angabe der Objektstruktur verzichtet werden. Es genügt für viele Zwecke anzudeuten, dass die betrachteten Objekte gleichartig sind, ohne auf die Attributstruktur näher einzugehen. In diesem Fall reduziert sich die graphische Darstellung zu einem einfachen Rechteck, das den Objektklassennamen enthält. Es hat sich eingebürgert den Objektklassennamen als Substantiv anzugeben und jeweils im Singular zu verwenden. Werden, wie im Beispiel (siehe Abbildung 1.1), Angestellte durch die Objektklasse repräsentiert, ist der Objektklassenname Angestellter. 1.2 Beziehungen Wie eingangs erläutert ist der Verlust von Information über Beziehungen zwischen einzelnen Objektklassen ein großer Nachteil des traditionellen relationalen Modells. Dieser Abschnitt soll deutlich machen, wie im EER-Modell die Darstellung verschiedener Beziehungen zwischen Objektklassen gelöst ist. 1.2.1 Beziehungs - Objektklassen (relationship sets) Die erste Art einer Beziehung zwischen Objektklassen soll am Beispiel erläutert werden. Angestellte einer Firma arbeiten an verschiedenen Projekten. Der Prozentsatz der Mitarbeit eines Angestellten an einem Projekt ist jeweils festgelegt. Version 1.0 / 26. März 2004 4 c H.-G. Hopf

Abbildung 1.1: Verschiedene Darstellungen der Objektklasse Angestellter : mathematische Darstellung, Tabellendarstellung, EER-Darstellung Version 1.0 / 26. März 2004 5 c H.-G. Hopf

Diese einfache Situation soll in einem Datenmodell beschrieben werden. Als eigenständige Objektklassen erkennt man sofort die Objektklasse Angestellter und die Objektklasse Projekt. Die Attribute der Objektklasse Angestellter sind vom obigen Beispiel übernommen (siehe Abbildung 1.1). Für die Objektklasse Projekt wird neben der Projektnummer zur Identifikation des Projekts noch Projektname und Kostenstelle als Attribut angegeben. Eine beispielhafte Tabellendarstellung ist für die Objektklasse Angestellter in Tabelle 1.1 und für die Objektklasse Projekt in Tabelle 1.2 angegeben. Personal- Vorname Nachname Abteilung nummer 101 Fritz Meier 1 102 Hans Müller 1 103 Uli Adam 2 104 Susi Otto 2 105 Gaby Müller 2 Tabelle 1.1: Tabellendarstellung der Objektklasse Angestellter Projekt- Projektname Kostenstelle nummer 1 SST 6900 2 ASAB 7000 3 MTA 6900 Tabelle 1.2: Tabellendarstellung der Objektklasse Projekt In keiner der beiden Objektklassen jedoch gelingt es durch Ergänzung der vorhandenen Attribute die Projektmitarbeit ohne Schwierigkeiten unterzubringen. Besonders deutlich treten diese Schwierigkeiten zu Tage, wenn man sich die Situation mittels der Tabellendarstellung einer derart modifizierten Objektklassen (siehe Tabelle 1.3) veranschaulicht. Personal- Vorname Nachname Abteilung Projekt- Projektnummer nummer mitarbeit 101 Fritz Meier 1 3 100 102 Hans Müller 1 1, 2 50, 40 103 Uli Adam 2 2 100 104 Susi Otto 2 2, 3 10, 90 105 Gaby Müller 2 3 100 Tabelle 1.3: Tabelle für die modifizierte Objektklasse Angestellter Das Hinzunehmen der Projektinformation (Projektnummer, Prozentsatz der Projektmitarbeit) in der Objektklasse Angestellter bringt offenkundig Probleme mit sich: Wir betrachten auch in der modifizierten Objektklasse Objekte vom Typ Angestellter. Damit darf sich auch an der Identifikation von Objekten der Objektklasse durch die neu hinzugenommenen Attribute nichts Version 1.0 / 26. März 2004 6 c H.-G. Hopf

ändern. Behält man also den Schlüssel Personalnummer bei, treten nicht atomare Attributwerte auf: Für den Angestellten Hans Müller müssen unter dem Attribut Projektnummer zwei Projektnummern (1, 2) und für das Attribut Projektmitarbeit zwei Prozentsätze (50 %, 40 %) aufgeführt werden. Der Zusammenhang zwischen Projekt und Projektmitarbeit geht verloren. Für den Angestellten Hans Müller ist nicht mehr zu entscheiden, in welchem der beiden Projekte 1 oder 2 er mit 40 % bzw. 50 % seiner Arbeitszeit mitarbeitet. Eine andere Lösung ist, die Objektklassen Angestellter und Projekt in ihrer ursprünglichen Form zu belassen und Informationen über die Projektmitarbeit in einer eigenen Tabelle abzulegen (siehe Tabelle 1.4). Personal- Projekt- Prozentnummer nummer satz 101 3 100 102 1 40 102 2 50 103 2 100 104 2 10 104 3 90 105 3 100 Tabelle 1.4: Tabelle Projektmitarbeit Diese Aufteilung in verschiedene Tabellen kann man auch schon auf konzeptioneller Ebene ausdrücken: Der Aspekt Projektmitarbeit stellt eine Beziehung zwischen den Objektklassen Angestellter und Projekt her. Diese Beziehung drückt sich in einer eigenen Tabelle Projektmitarbeit aus. Nun könnte man Tabellen, die Beziehungen repräsentieren, auf konzeptioneller Ebene als Objektklasse ansehen. Im Unterschied zu den im Abschnitt 1.1 definierten Objekten sind Objekte dieser Objektklasse aber nicht eigenständig, sondern hängen von den Objekten der die Beziehung begründenden Objektklassen ab. Es ist dementsprechend nur folgerichtig, zur Darstellung auf konzeptioneller Ebene die Beziehungsinformation durch ein eigenes Symbol zwischen den in Beziehung gesetzten Objektklassen auszudrücken. Im Beispiel (siehe Abbildung 1.2) hängt die Beziehungsobjektklasse, der man den Namen arbeitet an geben kann, in ihrer Existenz von Objekten aus den Objektklassen Angestellter und Projekt ab. In der Tabellendarstellung zeigt sich diese Abhängigkeit durch den zusammengesetzten Tabellenschlüssel (Personalnummer, Projektnummer), der aus den Schlüsselattributen der Tabellen Angestellter und Projekt besteht. In der Abbildung 1.2 ist diese Beziehungsobjektklasse arbeitet an zwischen den Objektklassen Angestellter und Projekt als Raute ausgeführt. In der Abbildung 1.2 ist neben der EER- Darstellung und der tabellarischen Darstellung wieder eine mathematische Version 1.0 / 26. März 2004 7 c H.-G. Hopf

Darstellung aufgeführt, wie wir sie zur Definition von Relationen benutzt haben. An das Beziehungssymbol kann weitere Information (im Beispiel Prozentsatz ) in Form von beschreibenden Attributen angeheftet werden. Das explizite Ausweisen von identifizierenden Attributen (im Beispiel Personalnummer, Projektnummer ) erübrigt sich jedoch: Durch die Angabe der in Beziehung tretenden Objektklassen ergibt sich ein zusammengesetzter Identifikator aus den identifizierenden Attributen der Ausgangsobjektklassen (im Beispiel Angestellter, Projekt ). Version 1.0 / 26. März 2004 8 c H.-G. Hopf

Abbildung 1.2: Darstellungen für Beziehungsobjektklassen: mathematische Darstellung, Tabellendarstellung, EER-Darstellung (relationship) Version 1.0 / 26. März 2004 9 c H.-G. Hopf

Eine Beziehung zwischen Objektklassen kann noch sehr viel differenzierter ausformuliert werden. Beziehungen zwischen Objektklassen können näher beschrieben werden durch Angaben über: den Grad einer Beziehung (degree) die Rolle der beziehungsbeteiligten Objektklassen (role) den Typ der Beziehung (connectivity) die Art der Beteiligung von Objekten an der Beziehung (membership class) 1.2.1.1 Grad einer Beziehung (degree) Der Grad einer Beziehung (siehe Abbildung 1.3) legt fest, wie viele bzw. wie oft Objektklassen an einer Beziehungsobjektklasse (Entity-Relationship-Set) beteiligt sind. Man unterscheidet: zweifache Beziehungen (binary relationships): Die Beziehung wird zwischen Objekten von zwei Objektklassen definiert. dreifache Beziehungen (ternary relationships): Die Beziehung wird zwischen Objekten von drei Objektklassen definiert. n - fache Beziehungen (n - ary relationships): Die Beziehung wird zwischen Objekten von n Objektklassen definiert. Die Objektklassen, die eine Beziehung definieren, müssen nicht notwendigerweise verschieden sein 1. Eine binäre Beziehung mit gleichen Ausgangsentities wird in der Literatur auch als rekursive Beziehung (recursive relationship) bezeichnet. 1.2.1.2 Rolle (role) Die Rolle gibt die Funktion an, die eine Objektklasse in einer Beziehungsobjektklasse spielt. Diese Funktion ist oft schon den Objektklassennamen oder dem Beziehungsklassennamen zu entnehmen. Beispielsweise verbindet die Beziehung gehört zu die Objektklassen Angestellter und Abteilung (siehe Abbildung 1.4). Die Rolle, die die Objektklasse Angestellter in der Beziehung gehört zu spielt ist offenkundig, die Rollenbezeichnung ist aus den Objektklassennamen ableitbar und muss dementsprechend nicht gesondert vermerkt werden. 1 In der Literatur (z.b. [TEO 86, TEO 90 ]) findet man häufig den Begriff einfache Beziehung (unary relationship). Unter einer einfachen Beziehung wird verstanden, dass die Beziehung zwischen Objekten der gleichen Objektklasse definiert wird. Dies ist jedoch ein Spezialfall einer binären Beziehung mit nicht verschiedenen Ausgangsobjektklassen. Insofern ist der Begriff einfache Beziehung entbehrlich. Version 1.0 / 26. März 2004 10 c H.-G. Hopf

Abbildung 1.3: Grad einer Beziehung Abbildung 1.4: Beispiele für eine implizite bzw. explizite Rollenkennzeichnung Version 1.0 / 26. März 2004 11 c H.-G. Hopf

In anderen Fällen muss die Rolle jedoch explizit angegeben werden, um die Beziehung in ihrer Bedeutung zu charakterisieren. Insbesondere für mehrfach an einer Beziehung beteiligte Objektklassen muss die Bedeutung der einzelnen Beteiligungen durch die Rollenbezeichnung unterschieden werden. In der 2-fach-Beziehung ist verheiratet mit, die die Objektklasse Person mit sich selbst verbindet, ist die Rollenkennzeichnung Ehemann bzw. Ehefrau zum Verständnis wichtig. In der Beziehung ist Vorgesetzter von, die die Objektklasse Angestellter mit sich selbst verbindet, muss die Rolle Vorgesetzter deutlich gemacht werden, ein Rollenname Mitarbeiter ist in diesem Fall entbehrlich. In der 3-fach-Beziehung spielt zwischen den Objektklassen Mannschaft und Saison muss die Charakterisierung Heimmannschaft bzw. Gastmannschaft die Rolle der einzelnen Beteiligung von Mannschaft an der Beziehung spielt verdeutlichen. Die Rolle dient dazu größtmögliche Transparenz in der Beschreibung der Beziehungsobjektklasse zu erreichen. Insofern sollte sie stets explizit angegeben werden. Die Rolle wird auf der Verbindungslinie zwischen Objektklassensymbol und Beziehungsklassensymbol vermerkt. Version 1.0 / 26. März 2004 12 c H.-G. Hopf

1.2.1.3 Kardinalität (cardinality) und Beziehungstyp (connectivity) Die Art, in der Objekte einer Objektklasse sich an einer Beziehung beteiligen, kann unterschiedlich sein. Durch eine Klassifikation dieser Beteiligung sollen Beziehungstypen herausgearbeitet werden. Die Kardinalität (cardinality) gibt für jede Rolle an, wie viele Objekte der aktuell betrachteten Objektklasse oder Rolle in einer Beziehung mit jeweils einem Objekt aller anderen Objektklassen stehen können. Üblicherweise wird für die Kardinalität ein Intervall festgelegt. [minimale Kardinalität, maximale Kardinalität] Eine Beziehung mit Objekten anderer Objektklassen einzugehen erfolgt üblicherweise mit wenigstens einem Objekt; die minimale Kardinalität hat in diesem Fall den Wert 1. Für die obere Grenze der Kardinalität unterscheidet man die Fälle maximale Kardinalität = 1 oder maximale Kardinalität > 1. Ein Wert für die maximale Kardinalität kann im letzteren Fall explizit angegeben werden (z.b. 5) oder über einen Parameter (z.b. n) ganz allgemein formuliert werden. Oft erfolgt die Bezeichnung für die maximale Kardinalität durch die englischen Begriffe one für den Wert 1 oder many für Werte n > 1. Werte kleiner 1 machen für den Maximalwert der Kardinalität keinen Sinn. Die Kardinalität wird im Beziehungsklassensymbol für alle beteiligten Rollen durch ein eigenes Indikatorsymbol graphisch dargestellt. Die Tabelle 1.5 zeigt die verschiedenen, typischen Formulierungen der Kardinalität. Ausgehend von einer minimalen Kardinalität 1 orientiert sich die Darstellung des Indikatorsymbols an der maximalen Kardinalität: die maximale Kardinalität 1 wird durch ein weißes Dreieck dargestellt; die maximale Kardinalität n > 1 wird durch ein schwarzes Dreieck dargestellt. Zur Darstellung des Typs einer Beziehung (connectivity) werden die zuvor für jede Rolle ermittelten Kardinalitäten kombiniert: Im Beziehungsklassensymbol sind die Indikatorsymbole für die Kardinalitätsintervalle für alle Rollen gemäß dem Grad der Beziehung angegeben. Für Zweifach-Beziehungen entsteht durch Kombination der Indikatorsymbole eine Raute. Version 1.0 / 26. März 2004 13 c H.-G. Hopf

Abbildung 1.5: Indikatorsymbole für verschiedene Kardinalitätsintervalle Für n-fach-beziehungen wird die Beziehung durch ein Polygon mit n Ecken dargestellt. Jeder Ecke ist eine Objektklasse/Rolle zugeordnet. In jeder Ecke wird ein Dreieck als Indikatorsymbol genutzt. Wir wollen in den folgenden Abschnitten zunächst binäre und dann n-fache Beziehungen näher untersuchen und insbesondere auf die verschiedenen Beziehungstypen eingehen. Binäre Objektbeziehungen Für eine binäre Objektbeziehung kann man folgende Beziehungstypen unterscheiden: 1:1 Beziehung: ein Objekt der einen Objektklasse ist genau einem Objekt der anderen Objektklasse durch die Beziehungsobjektklasse zugeordnet. Ein Beispiel für eine 1:1-Beziehung ist die Beziehung leitet zwischen den Objektklassen Angestellter und Abteilung (siehe Abbildung 1.6). Die beiden (maximalen) Kardinalitäten können wie folgt festgelegt werden: ein Angestellter leitet genau eine Abteilung; die Kardinalität der Objektklasse Abteilung in der Beziehung leitet ist 1 (one); das zugeordnete Dreieckssymbol ist weiß eingefärbt; eine Abteilung hat genau einen Abteilungsleiter; die Kardinalität der Objektklasse Angestellter in der Beziehung leitet ist 1 (one); das zugeordnete Dreieckssymbol ist ebenfalls weiß eingefärbt. 1:n Beziehung: ein Objekt der einen Objektklasse kann mit mehr als einem Objekt der anderen Objektklasse durch die Beziehungsobjektklasse verbunden sein. Als Beispiel für eine 1:n-Beziehung soll die Beziehung gehört zu zwischen den Objektklassen Angestellter und Abteilung dienen (siehe Abbildung 1.7). Version 1.0 / 26. März 2004 14 c H.-G. Hopf

Abbildung 1.6: Ermittlung des Beziehungstyps für die Beziehungsobjektklasse leitet zwischen den Objektklassen Angestellter und Abteilung Die beiden (maximalen) Kardinalitäten können wie folgt festgelegt werden: ein Angestellter gehört genau einer Abteilung an; die Kardinalität der Objektklasse Abteilung in der Beziehung gehört zu ist 1 (one); das der Objektklasse Abteilung zugeordnete Dreieckssymbol ist weiß eingefärbt; ein Abteilung besteht in der Regel aus mehr als einem Angestellten; die Kardinalität der Objektklasse Angestellter in der Beziehung gehört zu ist n (many); das der Objektklasse Angestellter zugeordnete Dreieckssymbol ist schwarz eingefärbt. n:m Beziehung: mehrere Objekte beider Objektklassen können sich gegenseitig durch die Beziehungsobjektklasse zugeordnet sein. Als Beispiel für eine n:m-beziehung soll die Beziehung arbeitet an zwischen den Objektklassen Angestellter und Projekt dienen. Die beiden (maximalen) Kardinalitäten können wie folgt festgelegt werden: ein Angestellter arbeitet an mehreren Projekten; die Kardinalität der Objektklasse Projekt in der Beziehung arbeitet an ist n (many); das der Objektklasse Projekt zugeordnete Dreieckssymbol ist schwarz eingefärbt; Version 1.0 / 26. März 2004 15 c H.-G. Hopf

Abbildung 1.7: Ermittlung des Beziehungstyps für die Beziehungsobjektklasse gehört zu zwischen den Objektklassen Angestellter und Abteilung ein Projekt wird von mehreren Angestellten abgewickelt; die Kardinalität der Objektklasse Angestellter in der Beziehung arbeitet an ist n (many); das der Objektklasse Angestellter zugeordnete Dreieckssymbol ist schwarz eingefärbt. Allgemeine n-fache Objektbeziehungen Für den allgemeinen Fall n-facher Beziehungsobjektklassen wird der Beziehungstyp wie folgt ermittelt: Man beantwortet für jede an der Beziehung beteiligte Objektklasse bzw. Rolle die Frage, mit wie vielen Objekten ein Beziehungstupel typischerweise angegeben werden kann, wenn von allen anderen Objektklassen/Rollen jeweils ein Objekt im Beziehungstupel festgelegt ist. Kann nur ein einziges Objekt mit den festgelegten (n-1) anderen Objekten ein gültiges Beziehungsobjekttupel bilden, so ist die maximale Kardinalität für diese Rolle 1. In der graphischen Darstellung wird im Relationssymbol das der betrachteten Objektklasse bzw. Rolle zugewandte Dreieck weiß dargestellt. Können mehrere Objekte mit den festgelegten anderen (n-1) Objekten zu gültigen Beziehungsobjekttupel kombiniert werden, ist der Maximalwert der Kardinalität für diese Rolle n (n > 1). In der graphischen Darstellung wird im Relationssymbol das der betrachteten Objektklasse/Rolle zugewandte Dreieck schwarz dargestellt. Version 1.0 / 26. März 2004 16 c H.-G. Hopf

Abbildung 1.8: Ermittlung des Beziehungstyps für die Beziehungsobjektklasse arbeitet an zwischen den Objektklassen Angestellter und Projekt Diese Überlegung wird für jede an der Objektklassenbeziehung beteiligte Objektklasse bzw. Rolle durchgeführt. Damit werden alle Dreiecke des Beziehungssymbols in ihrer Ausprägung (schwarz oder weiß) festgelegt, d.h. die maximalen Kardinalitäten aller Objektklassen/Rollen definiert. Die Abbildung 1.9 veranschaulicht das beschriebene Verfahren. Ein Beispiel soll zur Verdeutlichung dienen: Mannschaften spielen in der Bundesliga. Die Paarungen sollen für jede Saison abgespeichert werden. Betrachtet wird die 3-fach-Beziehung spielt zwischen den Objektklassen Mannschaft und Saison (siehe Abbildung 1.10). Die beiden Spiel-Mannschaften werden in der Beziehungsobjektklasse spielt durch die Rollen Heimmannschaft und Gastmannschaft unterschieden. Die maximalen Kardinalitäten der 3-fach-Beziehung können wie folgt festgelegt werden: Eine Paarung von Heimmannschaft und Gastmannschaft kann in mehr als einer Saison zustande kommen; die maximale Kardinalität der Objektklasse Saison in der Beziehung spielt ist n (many); das der Objektklasse Saison zugeordnete Dreieckssymbol ist schwarz eingefärbt. Eine Heimmannschaft spielt in einer Saison gegen mehrere Gastmannschaften; die maximale Kardinalität der Rolle Gastmannschaft der Objektklasse Mannschaft in der Beziehung spielt ist n (many); das der Objektklasse Mannschaft in der Rolle Gastmannschaft zugeordnete Dreieckssymbol ist schwarz eingefärbt. Version 1.0 / 26. März 2004 17 c H.-G. Hopf

Abbildung 1.9: Bestimmung der Kardinalität einer Objektklasse bzw. Rolle in einer n- fach Beziehung Version 1.0 / 26. März 2004 18 c H.-G. Hopf

Abbildung 1.10: Ermittlung des Beziehungstyps für die 3-fach- Beziehungsobjektklasse spielt zwischen den Objektklassen Mannschaft und Saison Völlig analog gilt: eine Gastmannschaft spielt in einer Saison gegen mehrere Heimmannschaften; die maximale Kardinalität der Rolle Heimmannschaft der Objektklasse Mannschaft in der Beziehung spielt ist n (many); das der Objektklasse Mannschaft in der Rolle Heimmannschaft zugeordnete Dreieckssymbol ist schwarz eingefärbt. Version 1.0 / 26. März 2004 19 c H.-G. Hopf

1.2.1.4 Art der Objektbeteiligung (membership class) Die Art der Objektbeteiligung an einer Beziehung macht rollenspezifisch eine Aussage über die Existenz von Objekten der Ausgangsobjektklassen/-Rollen im Kontext der Beziehung. Eine Beziehung ist für eine Rolle: verbindlich (mandatory): wenn für jede Objektkombination aller anderen Rollen ein zuzuordnendes Objekt der aktuellen Rolle existiert. wahlfrei (optional): wenn nicht sichergestellt ist, dass bei Vorgabe von jeweils einem Objekt aller anderen Rollen ein Objekt der betrachteten Rolle zugeordnet werden kann. Damit wird eine Aussage über die Formulierbarkeit bzw. Existenz von Objekten der Beziehungsobjektklasse gemacht. Eine optionale Objektbeteiligung wird durch ein Kreissymbol auf der, der Objektklasse/Rolle zugewandten Seite des Relationssymbols vermerkt. Die Optionalität soll an einigen einfachen Beispielen erläutert werden. Zuerst werden Beispiele binärer Beziehungen betrachtet: Betrachtet wird die Beziehung hat zwischen den Objektklassen Person und Paß (siehe Abbildung 1.11). Die beiden maximalen Kardinalitäten der binären Beziehung können wie folgt festgelegt werden: eine Person kann mehrere Pässe besitzen; die Kardinalität der Objektklasse Paß in der Beziehung hat ist n (many); das der Objektklasse Paß zugeordnete Dreieckssymbol ist schwarz eingefärbt; ein Paß kann nur einer Person zugeordnet sein; die Kardinalität der Objektklasse Person in der Beziehung hat ist 1 (one); das der Objektklasse Person zugeordnete Dreieckssymbol ist weiß eingefärbt. Nun soll die Art der Objektbeteiligung festgelegt werden: eine Person muss keinen Paß besitzen; d.h. nicht zu jeder Person muss ein Objekt der Objektklasse Paß existieren; die Beziehung hat ist bezüglich der Objektklasse Paß optional; das der Objektklasse Paß zugeordnete Dreieckssymbol ist durch das Optionalitätensymbol gekennzeichnet; ein Paß kann nur einer existierenden Person zugeordnet sein; jedem Paß ist damit eine Person zugeordnet, d.h. zu jedem Paß muss ein Objekt der Objektklasse Person existieren; die Beziehung hat ist bezüglich der Objektklasse Person verbindlich; das der Objektklasse Person zugeordnete Dreieckssymbol wird nicht weiter gekennzeichnet. Version 1.0 / 26. März 2004 20 c H.-G. Hopf

Auch für n-fach Beziehungen kann die Optionalität auf prinzipiell gleiche Weise festgelegt werden. Mannschaften spielen in einem Fußball-Turnier nach dem Prinzip jeder gegen jeden in verschiedenen Stadien. Betrachtet wird die 3-fach-Beziehung spielt zwischen den Objektklassen Mannschaft und Stadion (siehe Abbildung 1.12). Die beiden Spiel- Mannschaften werden in der Beziehungsobjektklasse spielt durch die Rollen Mannschaft A und Mannschaft B unterschieden. Die maximalen Kardinalitäten der 3-fach-Beziehung können wie folgt festgelegt werden: eine A-Mannschaft und eine B-Mannschaft tragen ihr Spiel in genau einem Stadion aus. die maximale Kardinalität der Objektklasse Stadion in der Beziehung spielt ist 1 (one); das der Objektklasse Stadion zugeordnete Dreieckssymbol ist weiß eingefärbt; eine A-Mannschaft spielt in einem Stadion im Rahmen des Turniers gegen alle anderen Mannschaften (B-Mannschaften); die maximale Kardinalität der Rolle B-Mannschaft der Objektklasse Mannschaft in der Beziehung spielt ist n (many); das der Objektklasse Mannschaft in der Rolle B-Mannschaft zugeordnete Dreieckssymbol ist schwarz eingefärbt. völlig analog gilt: eine B-Mannschaft spielt in einem Stadion im Rahmen des Turniers gegen alle anderen Mannschaften (A-Mannschaften); die maximale Kardinalität der Rolle A-Mannschaft der Objektklasse Mannschaft in der Beziehung spielt ist n (many); das der Objektklasse Mannschaft in der Rolle A-Mannschaft zugeordnete Dreieckssymbol ist schwarz eingefärbt. Nun soll die Art der Objektbeteiligung festgelegt werden: eine A-Mannschaft und eine B-Mannschaft tragen ihr Spiel in genau einem Stadion aus. Die Zuordnung eines Spielstadions für die Spielpaarung steht außer Frage. Die Objektbeteiligung der Objektklasse Stadion ist verpflichtend. Das der Objektklasse Stadion zugeordnete Dreieckssymbol ist weiter nicht gekennzeichnet. eine A-Mannschaft spielt in einem Stadion im Rahmen des Turniers gegen mehrere B-Mannschaften; eine A-Mannschaft muss jedoch nicht in jedem Stadium gegen eine B-Mannschaft antreten. Die Existenz einer B-Mannschaft für ein Spiel gegen eine A- Mannschaft in einem beliebig gewählten Stadion ist nicht gewährleistet. So spielt beispielsweise Dynamo im Rahmen des Turniers im Waldstadion nie gegen eine andere Mannschaft. Die Objektbeteiligung der Objektklasse Mannschaft in der Rolle B-Mannschaft ist optional. Das der Rolle B-Mannschaft zugeordnete Dreieckssymbol ist mit einem Optionalitätsindikator gekennzeichnet. Version 1.0 / 26. März 2004 21 c H.-G. Hopf

völlig analog begründet kann festgestellt werden, dass die Objektbeteiligung der Objektklasse Mannschaft in der Rolle A-Mannschaft optional ist. Das der Rolle A-Mannschaft zugeordnete Dreieckssymbol ist mit einem Optionalitätsindikator gekennzeichnet. Version 1.0 / 26. März 2004 22 c H.-G. Hopf