Datenmodellierung und Datenbankentwurf: Ein Vergleich aktueller Methoden

Datenmodellierung und Datenbankentwurf

Josef L. Staud

Datenmodellierung und Datenbankentwurf Ein Vergleich aktueller Methoden

Mit 167 Abbildungen

^

Springer

Professor Dr. Josef L. Staud Fachhochschule Ravensburg-Weingarten Doggenriedstraße 88250 Weingarten [email protected]

Bibliografische Information Der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.ddb.de abrufbar.

ISBN 3-540-20577-2 Springer Berlin Heidelberg New York Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte, insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen, bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik Deutschland vom 9. September 1965 in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des Urheberrechtsgesetzes. Springer ist ein Unternehmen von Springer Science+Business Media springer.de © Springer Berlin Heidelberg 2005 Printed in Germany Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Umschlaggestaltung: Erich Kirchner Herstellung: Helmut Petri Druck: betz-druck SPIN 10973158

Gedruckt auf säurefreiem Papier - 42/3130 - 5 4 3 2 1 0

Vorwort

Noch nie hatten Datenbanken eine so groBe Bedeutung wie in unserer Zeit. Nicht nur, dass unternehmensintem die Geschaftstatigkeit in der Regel digital unterstiitzt wird (mit entsprechenden Datenbestanden) und dass die geschaftUchen Interaktionen zwischen Untemehmen und von Untemehmen zu ihren Kunden in immer groBerem Umfang auf digitaler Basis und damit auf der Basis digitaler Datenbestande abgewickelt werden (im Rahmen des E-Business), es werden auch immer mehr groBe Datenbestande in Wirtschaft und Gesellschaft in digitaler Form - und das heiBt im Regelfall in Datenbanken - zur Verfugung gestellt. Und diese Entwicklung geht weiter. Es gibt emstzunehmende Schatzungen, die davon ausgehen, dass die nahe Zukunft einen groBen Anteil der Geschaftstatigkeit im E-Business sehen wird. Und das bedeutet dann eben Datenbestande fiir die angebotenen Produkte oder Leistungen und immense Datenbestande fiir die Geschaftstatigkeit. Und wie soil das prognostizierte „Evemet", das „Intemet der Dinge", bei dem sich die Waschmaschine mit dem zu waschenden Pullover dartiber „unterhalt", ob 30 Grad oder vielleicht doch besser nur 20 Grad die richtige Temperatur ist, fimktionieren ohne Datenbestande auf alien Ebenen. Datenbanken sind also von groBer Bedeutung und damit ist es ihr korrekter Aufl^au genauso. Datenmodellierung und Datenbankentwurf sind eine Schliisselkompetenz fiir heutige und fiir die zuktinftigen informations verwaltenden und -verarbeitenden Systeme. Ziel dieses Buches ist eine umfassende Darstellung der aktuellen Ansatze zu Datenmodellierung und Datenbankentwurf Deshalb werden hier nicht nur der relationale Datenbankentwurf und die objektorientierte und die Entity-Relationship - Modellierung (ERM) betrachtet, sondem auch die strukturierte ERM (SERM) und die SAP-SERM, die in der Praxis groBe Bedeutung erlangt haben. Dies allein adelt sie schon und verlangt nach Beschaftigung, dariiber hinaus geben sie aber auch noch der ubrigen Datenmodellierung wichtige Hinweise auf Schwachstellen und Verbesserungsmoglichkeiten. Das Buch wendet sich an alle, die Datenbanken entwerfen und einrichten diirfen(!). Die folgende Abbildung zeigt es auf: Die groBen Kapitel 3, 4 und 7 konnen unabhangig von den anderen gelesen werden. Mit einer einzigen Ausnahme: Kapitel 2 sollte vor alien anderen gelesen werden. Hier sind Konzepte und Begriffe zusammengefasst, die fiir alle Varianten heutiger

Immer mehr Datenbanken

Ziel des Buches

Lesehinweis

VI

Vorwort

Datenmodellierung wichtig sind. Fur das Kapitel zur SERM gilt, dass zuerst ein Verstandnis er ER-Modellierung gewonnen werden muss, fur SAP-SERM sollte zuvor SERM verstanden worden sein. Lesehinweis

Kapitel 2 Grundkonzepte

Datenmodellierung und Datenbankentwurf Stichwortverzeichnis Uberblick durch Typographie

Kapitel 3 Modellierung relationaler Datenbanken Kapitel 4 Entity Relationship - Modellierung (ERM) Kapitel 5 ^Strukturierte ERM (SERM) Kapitel 6 SAP-SERM Kapitel 7 ObjektorientierterDatenbankentwurf

v^

Das Buch beschreibt damit alle wesentlichen Theorieansatze zur Datenmodellierung. Es beschreibt aber auch recht fundiert, wie diese Datenmodelle dann mit Hilfe der relationalen Datenbanktheorie (bzw. bei der Anwendungsentwicklung mit Hilfe der objektorientierten Theorie) fiir den konkreten Datenbankentwurf gQimtzt werden. Das Stichwortverzeichnis wurde bewusst ausfiihrlich gehalten, um die gezielte Suche zu erleichtem. An einige Stellen wird im Text auch ausdriicklich mit Hilfe eines Pfeils darauf verwiesen (z.B. so: ->entity). Es gibt in der Datenmodellierung grob gesagt einen Ausgangspunkt und drei Modellebenen. Der Ausgangspunkt ist der zu modellierende Weltausschnitt / Anwendungsbereich. Die Modellebenen sind die Ebene der Attribute, die Ebene der „kleinsten" Elemente im jeweiligen Ansatz (Relationen, Entitatstypen, Klassen) und die Ebene des Datenmodells. Um hier im Text die Ubersichtlichkeit zu erhohen wird folgende typographische Festlegung getroffen: • •

Weltausschnitte / Anwendungsbereiche werden fett, etwas vergroBert und in Arial gesetzt: VORLESUNGSBETRIEB. Datenmodelle sind ebenfalls in Arial und in Kapitalchen gesetzt: MARKT FUR DATENBANKSYSTEME

• • Bezeichnung der aggregierten Ebene

Relationen, Entitatstypen, Beziehungstypen, Klassen sind in Arial und in GroBbuchstaben gesetzt: ANGESTELLTE Attribute sind in Arial gesetzt: Personalnummer

Fur die erste aggregierte Ebene (Relationen, Entitatstypen, Klassen) wird bei der Bezeichnung immer die Mehrzahl genommen. Also RECHNUNGSKOPFE statt RECHNUNGSKOPF, VORLESUNGEN statt VORLESUNG, DATENBANKSYSTEME statt DATENBANKSYSTEM. FUr die in den Beispielen ofl benutzten Personal Computer gilt: als Klassenbezeichnung wird PC verwendet, ansonsten (im Text) fur die Mehrzahl „PCs".

Vorwort

VII

Letztendlich stellt Datenmodellierung eines der Gebiete dar, das man nur durch LFbung lemt. Viele Jahre Lehrtatigkeit in diesem Bereich an Universitaten, Fachhochschulen, Bemfsakademien und in Untemehmen erweckten in mir sogar den Eindmck, dass es hier Wissensbereiche und Methoden gibt, die man textlich und verbal gar nicht vermitteln kann, sondem die im Kopf des Lernenden im Rahmen der Ubungen erworben werden miissen. Deshalb werden hier zahlreiche Ubungsaufgaben angegeben, noch mehr plane ich, auf meinen Web-Seiten zu platzieren (www. stand, info).

Nur Ubung machtden Meister

Abkurzungsverzeichnis

BPR DBS DV EPK ER ERM ERP

fA FA-Diagramm Host IRS KI OODBS OODM PC RDBS SAP-SERM SERM UML

Business Process Reengineering Datenbanksysteme Datenverarbeitung Ereignisgesteuerte Prozesskette Entity Relationship Entity Relationship - Modell bzw. Entity Relationship - Modellierung Enterprise Resource Planning. Als ERP-Software Bezeichnung fiir integrierte prozessorientierte Software (vgl. [Stand 2001]) Funktionale Abhangigkeit Diagramm der ftmktionalen Abhangigkeiten Anbieter von Online-Datenbanken Information Retrieval System KUnstliche Intelligenz - Forschung Obj ektorientiertes Datenbanksystem Obj ektorientierte Datenmodellierung Personal Computer Relationales Datenbanksystem SAP Strukturiertes Entity Relationship - Modell bzw. SAP Strukturierte Entity Relationship - Modellierung Strukturiertes Entity Relationship - Modell bzw. Strukturierte Entity Relationship - Modellierung Unified Modeling Language

Inhaltsverzeichnis

Einleitung

1

1.1 Datenbanken und Datenbanksysteme 1.2 Realitat und Modell 1.3 Syntax und Semantik

1 3 3

Grundbegriffe und -konzepte

7

2.1 2.2 2.3 2.4 2.5

Attribute Objekte und Beziehungen Mit Attributen zu Klassen Objekte erkennen durch Attribute Datenmodelle

7 12 14 16 18

Modellierung Relationaler Datenbanken

21

3.1 Einfuhrung 3.2 Relationen 3.3 Beziehungen zwischen Objektklassen bzw. Relationen 3.4 Relationale Verknupfung - Schlussel und Fremdschliissel 3.5 Verkniipfen von Relationen - konkret 3.6 Integritaten 3.7 Nicht-Attribute 3.8 Warum eigentlich flache Tabellen? 3.9 Zusammenfassung - erste Schritte 3.10 Optimierung durch Normalisierung 3.11 Die erste Normalform(INF) 3.12 Darstellung Relationaler Datenmodelle 3.13 Redundanzen in INF-Relationen 3.14Funktionale Abhangigkeiten 3.15 Die zweiteNormalform(2NF) 3.16 Normalisierung, Zerlegung, Zusammengehorigkeit 3.17 Die dritteNormalform(3NF)

21 22 25 35 42 44 44 45 47 48 49 55 56 58 70 78 79

Inhaltsverzeichnis

3.18 Die Boyce-Codd - Normalform (BCNF) 3.19 Die vierteNormaiform(4NF) 3.20 Relationale Operatoren bzw. Operationen 3.21 Die funfle Normalform (5NF) 3.22 Die theoretische Fundierung des Relationenbegriffs 3.23 Beispiel Rechnungsstellung 3.24 Die Zeitachse in Datenmodellen und Datenbanken

92 98 104 107 112 118 126

Entity Relationship - Modellierung

129

4.1 Einfuhrung 129 4.2 Entitaten, Beziehungen, Attribute 129 4.3 Zuordnung der Attribute - Entstehung neuer Entitatstypen... 13 7 4.4 Beteiligungen - Kardinalitaten und Min-/Max-Angaben 142 4.5 Ahnlichkeit und Enthaltensein 149 4.6 Beziehungen - vertieft 152 4.7 Beispiel „Sportverein" 155 4.8 Die Zeit in Datenmodellen 165 4.9 Gleichzeitig Entitat und Beziehung 166 4.10HinweisezurFehlervermeidung 168 4.11 Schlussbemerkung 172 4.12 Beispiel PC-Beschaffung 173 4.13 Ubertragung von ERM nach RM 181 SERM - Strukturierte Entity-Relationship-Modelle

193

5.1 Grundkonzepte 5.2 Existenzabhangigkeit

193 195

Der SAP-Ansatz fiir die Datenmodellierung

203

6.1 6.2 6.3 6.4

203 206 220 228

Das Grundkonzept SAP-SERM Konkrete Beispiele mit Erlauterungen Business Objekte

Objektorientierte Modellierung

233

7.1 Einfuhrung 7.2 Statische Aspekte I - Objekte und Objektklassen 7.2.1 Objekte - Attribute - Methoden 7.2.2 Objekte fmden

233 235 235 238

Inhaltsverzeichnis

7.3

7.4 7.5

7.6

7.2.3 l:l-Abbildung 7.2.4 Klassen bilden 7.2.5 Klassifikation und Instantiierung 7.2.6 Methoden vertieft 7.2.7 Identitat 7.2.8 Alles nur Objekte? Statische Aspekte II - Objekte in Beziehung setzen 7.3.1 Assoziation - Semantische Verkntipfung 7.3.2 Generalisierung / Spezialisierung 7.3.3 Vererbung 7.3.4 Aggregation und Komposition 7.3.5 Kapselung und Information Hidding 7.3.6 Uberladen und Uberschreiben Dynamische Aspekte -Nachrichten Verhaltensmodellierung 7.5.1 Um was geht's? 7.5.2 Anwendungsfalle (use cases) 7.5.3 Sequenzen 7.5.4 Kollaborationen 7.5.5 Zustandsubergange 7.5.6 Aktivitatsfolgen Einschatzung

XI

241 242 245 246 250 251 251 251 261 263 267 272 273 273 276 276 277 280 281 283 285 286

8

Index

289

9

Literaturverzeichnis

295

1

EiNLEITUNG

1.1

"The real world is not a formal system - or at least, if it is, then it is one of immense complexity, beyond our ability to formalize at the time of writing, and likely to remain so for the foreseeable future" [Date 1986].

Datenbanken und Datenbanksysteme

Datenbanksysteme sind Softwareprodukte wieviele andere auch, zum Beispiel Compiler ftir Programmiersprachen, Tabellenkalkulationsprogramme, Grafikpakete, Textverarbeitungsprogramme, usw. Wie alle anderen erftillen sie einen besonderen Zweck. Der Zweck ist hier die Verwaltung von Daten tiber einen bestimmten Anwendungsbereich, "Datenbanker" sprechen hier von Weltausschnitt, in einer Datenbank. Sinn und Zweck einer Datenbank ist es, zielgerichtet Inft)rmationen tiber einen Weltausschnitt zu verwalten. Nimmt man Bezug auf das aktuelle Thema Geschdftsprozesse und auf die Tatsache, dass Datenbanken letztendlich nichts anderes tun, als Geschaftsprozesse zu unterstiitzen, konnen damit drei Aufgaben von Datenbanken ft)rmuliert werden. Datenbanken ... • • •

erlauben die Inft)rmationsspeicherung an sich ermoglichen (einfache) Auswertungen auf den abgespeicherten Informationen und unterstiitzen die Geschaftsprozesse des jeweiligen Weltausschnitts

Datenbanksysteme

Datenbanken

Warum Datenbanken?

Durch die fortschreitende Informatisierung von Wirtschaft und Gesellschaft spielen Datenbanken eine immer wichtigere Rolle. Sie werden iiberall dort benotigt, wo - im Rahmen der Informatisierung - Informationen „erhalten bleiben sollen". Da dies ftir so gut wie alle Anwendungsbereiche gilt, ergibt sich eine entsprechende Verbreitung von Datenbanken und ein entsprechender Bedarf an Wissen tiber Datenbanktechniken. Einige Beispiele ftir Datenbanken, die den Einsatzbereich allerdings auch nur andeuten konnen: • •

•

Datenbank liber das Personal eines Untemehmens mit der Auswertung "monatliche Gehaltszahlung". Datenbank tiber den Produktionsbereich eines Untemehmens mit dem Ziel, Daten fur ein Produktionsplanungssystem zur Verftigung zu stellen. Datenbank zu alien Aspekten eines Untemehmens mit dem Ziel, dem Leitungspersonal standig zentrale Kennziffem des Untemehmens zur Verftigung zu stellen.

Beispiele fiir Datenbanken

1 Einleitung

•

• • •

Attribute iiberall

Persistenz

Eigenschaften von Datenbanksystemen

Datenbank zu den Buchungen in einer internationalen Hotelkette mit dem Ziel, moglichst in Realzeit einen Uberblick iiber die Reservierungen zu haben. Datenbank iiber Datenbanksysteme mit dem Ziel, das richtige Datenbanksystem fur einen bestimmten Zweck fmden zu helfen. Datenbank iiber Online-Datenbanken mit dem Ziel, jahrlich ein Verzeichnis von Online-Datenbanken zu veroffentlichen. Untemehmensweite Datenbank als Grundlage einer umfassenden Standardsoftware (wie SAP R/3), d.h. als Grundlage einer umfassenden Modellierung der Geschaftsprozesse.

Man kann heutige Datenbankansatze nur dann richtig begreifen, wenn man sich klar macht, dass sie voU und ganz auf dem Attributkonzept basieren. Attribute und ihre Auspragungen werden festgelegt, die Auspragungen fiir die ausgewahlten Informationstrager bestimmt, die Informationstrager in Klassen so zusammengefasst, dass die in einer Klasse sind, die durch dieselben Attribute beschrieben werden, usw. Diese Attributorientierung gilt fiir die Datenmodellierung genauso wie fiir die physische Speicherung. Die relationale Normalisierungstheorie ist z.B. fast ganzlich motiviert durch das Ziel, Attributsauspragungen so in Dateien (sequentielle mit ihren verschiedenen Weiterungen) zu bringen, dass moglichst wenig Redundanz entsteht. Wesentlich fiir Datenbanken ist ebenso, dass die Datenverwaltung iiber lange Zeitraume stattfmden soil, dass die Daten langfristig gespeichert werden sollen. Hierflir wird in der Fachdiskussion auch der Begriff/>ersistente Datenhaltung verwendet. Zu den Eigenschaften, die von Datenbanksystemen gefordert werden, gehorenu.a.: • •

• • • •

Unterstiitzung eines Datenmodells, d.h. eines Modells fiir die zu verwaltenden Daten (diesem Thema ist dieses Buch gewidmet). Unterstiitzung einer formalen Sprache, mit der die Nutzer die Datenstruktur defmieren, auf die Daten zugreifen und die Daten verarbeiten konnen. Bei relationalen Datenbanksystemen ist dies heute so gut wie immer SQL (Standardabfrage- und -auswertungssprache fiir Relationale Datenbanken). Transaktionsmanagement, d.h. die Fahigkeit vielen Nutzem auf einmal den Zugriff auf die Daten zu erlauben. Zugangskontrolle, d.h. die Fahigkeit, den Zugriff auf die Daten zu kontrollieren. Priifimgen der semantischen Integritat. Fahigkeit, Systemabstiirze ohne Datenverlust zu reparieren.

Fur relationale Datenbanksysteme gilt zusatzlich, dass sie auf effiziente Weise die Verkniipfiing von Daten aus verschiedenen Dateien (Schlussel / Fremdschliissel (vgl. Abschnitte 3.3 und 3.4)) ermoglichen.

1.2 Realitat und Modell

1.2

Realitat und Modell

Datenbanken stellen immer ein abstrahiertes Abbild der Realitat dar. Irgendeiner Realitat. Da es sich dabei immer nur um Teilbereiche handelt, sind dafiir Begriffe wie Weltausschnitt (slice of reality), Miniwelt (bei Autoren mit KI-Kontakt) oder auch Anwendungsbereich (der Software, der die Datenbank „dient") in Gebrauch. Weltausschnitte konnen Abteilungen von Untemehmen ("Datenbank fiir den Vertrieb") oder auch (fast^) ganze Unternehmen sein (z.B. bei ERP-Software). Weltausschnitte konnen aber auch durch eine einzelne Aufgabe defmiert sein, z.B. „Daten fiir die Absatzprognose" oder „Daten fur die neue Web-Prasentation des Untemehmens". Es soil hier nicht verschwiegen werden, dass es auch auBerhalb des attributbasierten Bereichs Weltausschnitte mit faszinierenden anderen Informationsarten gibt, z.B. in der Chemie mit chemischen Strukturformeln, in der Physik (vgl. die Online-Datenbanken hierzu) oder auch Okonometrie (vgl. die Zeitreihendatenbanken der entsprechenden Anbieter). Das „Abbild der Realitat" wird mit Hilfe eines Datenmodells (vgl. unten) gewonnen. D.h. der Ersteller der Datenbank analysiert den Weltausschnitt und erstellt - mit Hilfe eines theoretischen Instrumentariums - ein Datenmodell. In diesem sollte die Semantik des Anwendungsbereichs (die (benotigten) Strukturen, Regeln, Fakten, usw.) erfasst sein.

1.3

Weltausschnitt

Syntax und Semantik

Diese Semantik eines Weltausschnitts ist nicht leicht zu verstehen, deshalb hier einige Beispiele. Zuerst ein sehr einfaches, Datumsangaben. Datumsangaben haben eine schlichte Struktur. Sie bestehen aus einer Tages-, einer Monats- und einer Jahresangabe. Z.B. so: 4. Mai 2004 oder auch 2004/05/04, usw. Den korrekten Aufbau legt die sog. Syntax fest, die genau dafiir die Regeln vorgibt. Die Syntax wiirde aber auch den 31. April 2004 zulassen. Dies verhindert die Semantik, die festlegt, welche der Datumsangaben inhaltlich korrekt sind. Sie legt fest: • • •

Tagesangaben liegen nur zwischen 1 und 31 Monatsangaben liegen nur zwischen 1 und 12 Die Monate April, Juni, September, November haben maximal 30 Tage • Der Monat Februar hat maximal 28 Tage mit Ausnahme der Schaltjahre • Das Jahr 2004 ist ein Schaltjahr, der Februar hat also 29 Tage

„Ganz" sind Unternehmen nie modelliert. Zumindest die Trennlinie zwischen kaufmannischen und technischen Anwendungen halt meist immer noch.

Datumsangaben

1 Einleitung

Das Jahr 2000 war ebenfalls ein Schaltjahr USW.

Lehrbetrieb an einer Hochschule

Solche Festlegungen stellen also die Semantik der Datumsangaben dar. Genauer formuliert ist es so, dass die Realwelt (Datumsangaben) eine Semantik hat, die durch die Datumsangaben moglichst genau erfasst werden soil. Dieses Beispiel betrifft nur eine einzelne Information, so dass wir sie in einem Datenmodell mithilfe eines Attributs erfassen wurden (vgl. unten). Ein Beispiel flir Semantik „im groBeren" bringt das folgende Beispiel. Betrachten wir den Lehrbetrieb an einer Hochschule. Hier konnte bzgl. der Vorlesungen folgendes gelten: • • • • • • • •

Der nebenamtliche Dozent XYZ kann seinen Kurs nur Montag Vormittag Oder Freitag Nachmittag abhalten. An einem Tag sollten nicht mehr als 8 Unterrichtseinheiten Vorlesungen und Ubungen abgehalten werden. Der Vorlesungsbetrieb sollte nach Moglichkeit nicht vor 8.30 Uhr beginnen. Nach Moglichkeit sollte der Vorlesungsbetrieb spatestens um 18.00 Uhr beendet sein. Von einem Kurs sollten an einem Tag nicht mehr als 4 Vorlesungsstunden gegeben werden. Der hauptamtliche^ Dozent XYZ halt den Dienstag Vormittag fiir seine Vorlesung frei. Die EDV-Veranstaltungen fmden normalerweise in den Raumen K002 und K002A statt. Die Veranstaltung „C" im 1. Semester findet in Raum 123 an den dort lokalisierten HP-Workstations unter UNIX statt. Im 2. Semester wird C unter Windows in Raum 214 abgehalten.

Naturlich gehoren alle Festlegungen der Prufungsordnung, die den Stundenplan mitbestimmen, auch zur Semantik. Zum Beispiel (fiktiv): • •

Nachklausuren mlissen friihestens 4 Wochen und spatestens 3 Monate nach der ersten Klausur stattfinden. Eine miindliche Priifung kann einmal wiederholt werden. Die Wiederholung muss innerhalb von drei Monaten erfolgen.

Ebenso gehoren ganz allgemeine Grundsatze unserer Daseins dazu: • • ^ ^

In einem Raum kann in einer Zeitspanne nur eine Veranstaltung stattfinden. Ein Dozent kann in einer Zeitspanne nur einen Kurs abhalten. Die Schaltjahrregelungen sind recht kompliziert, so gibt es Schaltjahre, die nur in groBem Abstand auftreten. „Hauptamtlich:" an der Hochschule beschaftigt.

1.3 Syntax und Semantik

• •

Bin Dozent sollte pro Tag nicht mehr als 10 Stunden Vorlesungen und tjbungen geben. Veranstaltungen, die das lokale PC-Netz zum Absturz bringen konnten (z.B. Programmierkurse) sollten nicht am Freitag Nachmittag stattfinden, da ab 13.00 Uhr die Rechenzentrumsmitarbeiter nicht mehr da sind, um einen evtl. Netzzusammenbruch „zu reparieren".

usw. Wenigstens ein kleiner Teil solcher Semantikaspekte kann in Dateimiodellen erfasst werden. Allerdings wirklich nur ein kleiner, wie im folgenden zu sehen sein wird, weshalb die diesbeziiglichen Anstrengungen weitergehen. Woher kommt der Wunsch, moglichst viel Semantik des jeweiligen Weltausschnitts in einem Datenmodell und dann in der Datenbank zu erfassen? Nun, die Semantik"^ gehort zur Anwendung. Sie muss auf jeden Fall berticksichtigt werden, soil die Anwendung leistungsstark sein^. Entweder wird sie in der Datenbank hinterlegt oder in den Programmen softwaretechnisch realisiert (dann ist sie Gegenstand der Systemanalyse). Die Hinterlegung in der Datenbank, aufbauend auf der vorangehenden Beriicksichtigung beim Datenbankentwurf, hat aber Vorteile: Sie ist sehr iibersichtlich (z.B. als Semantische Integritatsbedingungen (constraints) auf den Relationen) und leicht anderbar. Man kann es auch so formulieren: Alle (zu berticksichtigende) Semantik, die nicht in der Datenbank hinterlegt wird, muss bei der Systemanalyse fur die Anwendungsprogramme beriicksichtigt werden.

Mehr Semantik in das Datenmodell

Die Aufgabe der Datenmodellierung ist es somit, einen Weltausschnitt - Oder, wie heute im Bereich der ERP-Software formuliert wird, einen Betriebswirtschaftlichen Anwendungsbereich mit den Mittein des jeweiligen theoretischen Ansatzes so zu modellieren, dass die gestellten Aufgaben gelost werden konnen. Das Ergebnis ist ein Datenmodell, das mit einem konkreten Datenbanksystem in eine Datenbank uberfiihrt wird.

Aufgabe der Datenmodellierung

Es geht nattirlich nur um den Teil der Semantik, der fiir die jeweilige Anwendung bzw. fiir die Geschaftsprozesse, denen die Datenbank "dient", Bedeutung hat. Zur Illustration stelle man sich nur eine Software fiir den oben skizzierten Lehrbetrieb

2

GRUNDBEGRIFFE UND -KONZEPTE

2.1

Attribute

Im Mittelpunkt aller derzeitigen datenbanktheoretischen Ansatze steht ein wichtiges Konzept: Attribute. Mit Hilfe von Attributen wird die Information erfasst, die in der Datenbank gespeichert wird. Bezogen auf die heutige Datenbanktechnologie heiBt das, dass durch sie die zu erfassenden Objekte und Beziehungen (vgl. Abschnitt 2.2) identifiziert und beschrieben werden. AuBerdem erfolgt mit ihrer Hilfe dann auch die Abfrage der Datenbestande: SQL, die Abfrage-, Auswertungs- und Verwaltungssprache fur relationale Datenbanken baut vollkommen auf Attributen auf Das Attributkonzept ist daher von zentraler Bedeutung fiir die Datenmodellierung und das Datenbankdesign. Attribute gehen auf den umgangssprachlichen Eigenschaftsbegriff zuriick. Eigenschaften wie die folgenden: • • • • • •

Maier als Name einer Angestellten in einem Unternehmen Silber als Farbe eines Autos, Mdnnlich als Geschlecht einer Katze, 5000 Euro als Gehalt eines Menschen, 11111 als Personalnummer eines Angestellten oder 2,7 als Note einer Klausur.

Alle unterstrichenen Worter: Name, Farbe, Geschlecht, Gehalt, Personalnummer und Note, sind Beispiele fur Eigenschaften, die im Zusammenhang der Datenorganisation Attribute genannt werden. Alle kursiv gesetzten Worter und Zahlen: Maier, Silber, Mannlich, 5000 Euro, 11111 ,2,7 sind Beispiele fur (AttYibutS')Ausprdgungen von Attributen. Alle fett gesetzten Worter: Angestellte, Autos, Katzen, Menschen, Angestellte, Klausuren bezeichnen Objekte (im allgemeinsten Sinn). Diese werden beschrieben. Der Zusammenhang ist grundlegend und wie folgt: • •

Eigenschaften und Objekte

Attribute haben eine bestimmte Menge von (Attributs-)Auspragungen. Attribute werden mit Objekten in Zusammenhang gebracht, indem eine Auspragung als gliltig fur das Objekt erkannt wird, oder auch mehrere.

Eigenschaften und Attribute Attributsauspragungen Objekte

2 Grundbegriffe und -konzepte

Die folgende Abbildung veranschaulicht diesen Zusammenhang. Auf der linken Seite sind die drei Attributsauspragungen angefiihrt, rechts die Menge der Objekte. Die Pfeillinien zeigen dann z.B., dass ANGl die Programmiersprachen PSl und PS2 beherrscht und ANG4 nur PS4.

Attributsauspragungen und Objekte Objekte: Angestellte (ANGx) Attribut: beherrschte Programmiersprachen (PSx) ANG1 ANG2 ANG3 ANG4 Objekte

I Attribut Abbildung 2.1-1:

Das Attributkonzept - Zuordnungen

Wenn man also, ganz am Anfang der Datenmodellierung und bei der Analyse des Weltausschnitts, etwas^ erfassen mochte, muss man zuerst entscheiden, ob es ein Attribut, eine Attributsauspragung oder ein Objekt bezeichnet. Die folgende Tabelle zeigt einige weitere Beispiele flir Attribute, ihre Auspragungen und die zugehorigen Objekte. 1 Attribute Farbe Geschlecint Gehalt Personalnummer Note

Attributsauspragungen blau, rot, gelb, schwarz, ...

Objekte 1 z.B. Automobile, Blumen mannlich z.B. Menschen, Tiere positive Dezimalzahlen Mensciien z.B. eindeutige 5-stellige z.B. Angestellte eines Zahlenkombinationen, jede Unternehmens eindeutig z.B. eine Zaiii zwisciien z.B. Studierende 1,0 und 6,0 (mit einer Dezimalstelle)

Ausgehend von dem, was wir wahmehmen, ist folgendes zu leisten:

Dieses „etwas" wird auch als Realweltphdnomen bezeichnet: Alles was wir mit unserer korperlichen und geistigen Ausstattung als Menschen wahrnehmen. Hier stoBen wir an biologische und erkenntnistheoretische Fragen, die, was letztere angeht, z.B. in der sog. Konzeptionellen Datenmodellierung oder „davor" in der Erkenntnistheorie, Psychologic, usw. behandelt werden.

2.1 Attribute

• • •

Wird „etwas" als Attribut erkannt, mussen die Auspragungen gesucht Oder auch festgelegt werden. Wird es als Attributsauspragung erkannt, muss man den Namen des Attributs und die ubrigen Auspragungen suchen oder festlegen. Wird es als Objekt erkannt, miissen die einschlagigen Attribute und ihre Auspragungen gesucht bzw. festgelegt werden.

Damit stellt sich zu Beginn jeder Datenmodellierung, bei der Betrachtung des Weltausschnitts oder Anwendungsbereichs, immer die Frage: Was beschreibt, was wird beschrieben? In modemer Sprache: Welches sind im Anwendungsbereich die Objekte^, welche Attribute haben diese, welche Auspragungen haben die Attribute. In der angelsachsischen Literatur wird die Menge der Attributsauspragungen eines Attributs mit domain bezeichnet, weshalb sich in der deutschsprachigen Literatur auch die Bezeichnung Domdne fmdet. Wie sieht nun der Zusammenhang zwischen Eigenschaften und Attributen konkret aus? So wie zu einer Eigenschaft ihre Benennung gehort, so gehoren auch zu Attributen entsprechende Namen, Attributsnamen, wie GroBe, Farbe, Gehalt, Alter, Abteilungszugehorigkeit, usw. Den konkreten Eigenschaftsauspragungen (z.B. gelb, rot, blau, usw. bei einer Eigenschaft Farbe) entsprechen Attributsausprdgungen, wie oben gesehen. Bei Gehalt und Alter die entsprechenden Zahlenangaben, bei einem Attribut Abteilungszugehorigkeit z.B. Datenverarbeitung, Personalwesen, Marketing, usw. Die Attributsauspragungen sind somit eine Menge von Begriffen, die zur Zuordnung der jeweiligen Eigenschaft dienen, deshalb der oben eingeflihrte Begriff Wertebereich eines Attributs, Weiter gehort zu einem Attribut die Angabe der Objekte bzw. Beziehungen, auf die es sich bezieht. Dies ist wichtig, well z.B. ein Attribut Grofie nattirlich bezuglich unterschiedlicher Objekte jeweils eine unterschiedliche Bedeutung hat. Es kann die GroBe von Menschen oder von Tieren bezeichnen oder auch ein materielles Gut. Attribute konnen nach verschiedenen Kriterien unterschieden werden. Eines davon hat auch im Zusammenhang mit Datenbanken Bedeutung und soil deshalb hier betrachtet werden. Es betrifft die Art und Weise, wie das jeweilige Attribut beschreibt. Unterschieden werden dabei: • • •

domain und entity Attributsnamen

Attributsauspragungen

Bezug auf Objekte

Eigenschaft von Attributen

Benennungen qualitative Attribute quantitative Attribute

Benennungen sind eindeutige Bezeichnungen der Objekte bzw. Beziehungen. Oft z.B. Namen (z.B. von Datenbanksystemen, von Untemehmen) oder eindeutige Nummem (z.B. Personalnummem). Ihr KennzeiIm allgemeinsten Sinne, nicht also unbedingt genauso wie Objekte im objektorientierten Ansatz defmiert sind, vgl. Kapitel 7.

Benennungen

10

Qualitative Attribute

chen ist die Eindeutigkeit, d.h. jedes Objekt bzw. jede Beziehung wird durch eine andere Attributsauspragung benannt. Personennamen gehoren hier im tibrigen meist nicht dazu, auch nicht Postleitzahlen, wenn es um Orte geht. Attribute dieses Typs dienen im Datenmodell - in Bezug auf ihre^ Objekte - als Schlussel, d.h. als identifizierende Information. Bei der Datenbankabfrage dienen diese Attribute zur Identifizierung einzelner Objekte und Beziehungen. Wahrend obiger Attributstyp identifizierenden Charakter hat, dienen die folgenden zwei der weitergehenden Beschreibung der Objekte bzw. Beziehungen. Sie beruhen auf dem Gegensatz qualitativ/quantitativ, wie er aus der statistischen Messtheorie bekannt ist. Qualitative Attribute beschreiben die Objekte nicht-numerisch. Sie dienen der Differenzierung zwischen Objekten und nicht dem „in Beziehung setzen", weshalb auch in der Kegel mehrere Objekte dieselbe Attributsauspragung aufweisen. Einige Beispiele hierzu: • • • •

Quantitative Attribute

2 Grundbegriffe und -konzepte

Geschlecht fur MENSCHEN. Datenbanksystemtyp, Hardware-Plattformen, Produzent des Datenbanksystems fur DATENBANKSYSTEME. Abteilung(szugehorigkeit), beherrschte Programmiersprachen fur die ANGESTELLTEN eines Untemehmens Anbieter, Produzent, Typ, Sprache (der Eintrage) flir ONLINEDATENBANKEN.

Bei der Datenbankabfrage dienen qualitative Attribute der inhaltlichen Festlegung der Suchmenge. Z.B. indem nach alien Datenbanksystemen gefragt wird, die vom Typ „Objektorientiertes Datenbanksystem" sind und die auf der Hardware-Plattform „Intel-PC" laufen. Oder indem nach alien Angestellten gesucht wird, die mehr verdienen als ihr Abteilungsleiter. In Beziehung gesetzt werden konnen diese Attribute nur durch den Gleich/ungleich-Operator. Quantitative Attribute beschreiben die Objekte und Beziehungen numerisch und zwar so, dass die Auspragungen verglichen werden konnen Oder dass man mit ihnen rechnen kann. Einige Beispiele: • • •

Preise, maximale Anzahl Datensatze flir DATENBANKSYSTEME Alter, Gehalt flir die ANGESTELLTEN eines Untemehmens Zahl der Datensatze fur ONLINE-DATENBANKEN

Diese Attributsart dient bei der Abfrage ebenfalls der inhaltlichen Festlegung der Suchmenge, z.B., wenn Datenbanksysteme mit einem Preis kleiner 3000,-- Euro gesucht werden. Die Auspragungen quantitativer Attribute konnen - zusatzlich zum GleichAJngleich-Operator" auch mit Dasselbe Attribut kann fiir die einen Objekte Benennung sein und fur die anderen nicht. Nehmen wir als Beispiel die Namen von Programmiersprachen (C, COBOL, FORTRAN, usw.). Fur PROGRAMMIERSPRACHEN waren dies Benennungen, fur ANGESTELLTE, wo jedem Angestellten die Programmiersprachen zugeordnet werden, die er Oder sie beherrscht, sicher nicht.

2.1 Attribute

11

dem Kleiner-ZGroBer-Operator in Beziehung gesetzt werden. Wichtiger ist, dass man mit den Auspragungen quantitativer Attribute rechnen kann. In der Grundausstattung von SQL sind dann auch gleich Funktionen flir die Aufsummierung, die Mittelung, das Finden des kleinsten/groBten Werts, usw. enthalten. Niclit alles, was quantitativ erscheint, ist auch so. Z.B. Personalnummem. Das Kjriterium der Unterscheidung qualitativer und quantitativer Attribute ist einfach: Dient die Information - alphanumerisch oder numerisch - nur zur Unterscheidung der Objekte, ist sie qualitativ. Dient sie auch zu Berechnungen, ist sie quantitativ^. Attribute als solche haben mit den konkreten Datenbanksystemen noch nichts zu tun. Dort stehen dann fiir die Attribute die Datentypen zur Verfiigung (wie Integer, Real, Date, usw.). Gleiches gilt fiir moderne Informationstypen wie Audio, Video, usw., die in Datenbanksystemen meist durch Binary Large Objects (BLOBs) realisiert werden. Der Begriff ^^^ ribut ist auf der Modellebene angesiedelt (auf der wir uns hier befinden), der ^Qgnff Datentypen auf der Ebene der physischen Datenorganisation. Die folgende Abbildung fasst die Ausftihrungen zu Attributen zusammen.

Auf die weitergeliende Unterscheidung rangskalierter Attribute (in der Statistik: Merkmale) wird hier verzichtet, weil diese im Datenbankbereich keine groBe Bedeutung hat.

Quantitativ?

Attribute vs. Datentypen

2 Grundbegriffe und -konzepte

12

Zusammengefasst: Attribute Eln Attribut halt eine Eigenschaft von Objekten bzw. Beziehungen fest. Zu einem Attribut gehoren der Attributsnamen und die Attributsauspr^gungen. Die Attributsauspragungen sind eine Menge von Begriffen, die zur Zuordnung der jeweiligen Eigenschaftdienen. HiersollendreiAttributsartenunterschiedenwerden: -Benennungen -qualitative Attribute - quantitative Attribute Benennungen sind eindeutige Bezeichnungen der Objekte bzw. Beziehungen. Z. B. Personalnummern bei den Angestellten eines Unternehmens, Bezeichnungen von Datenbanksystemen, Oder Firmennamen. Ihr Kennzeichen ist die Eindeutigkeit, d.h. jedes Objekt bzw. jede Bezlehung wird durch eine andere Attributsauspragungbenannt. Qualitative Attribute beschreiben die Objekte qualitativ (nichtnumerisch). Dabei haben in der Regel mehrere Objekte dieselbe Attributsauspragung. Beispiele sind bzgl. der Angestellten eines Unternehmens >AWe//i/nfif(szugehorigkeit) und beherrschte Programmiersprachen. Quantitative Attribute beschreiben die Objekte und Beziehun-gen numerisch und zwar so, dass die Auspragungen verglichen werden konnen Oder dass man mit ihnen rechnen kann. Bei ANGESTELLTEN zum Beispiele yA/ferund Gehalt '

Abbildung 2.1-2:

2.2 Schrittl: Wahrnehmung mit Hilfe von Objekten und Beziehungen

m6|

Das Attributkonzept

Objekte und Beziehungen

Eine wichtige Grundlage heutiger Datenmodellierung ist die Festlegung, dass die reale Welt aus Objekten (entity^^) besteht und dass diese Objekte durch semantisch tragfahige Beziehungen verkntipft sind. M.a.W.: Heutige Datenmodellierung nimmt die Weltausschnitte uber das Erkennen von Objekten und semantisch bedeutsamen^^ Beziehungen wahr. In der US-amerikanischen Fachliteratur wird in dieser Situation nicht der Begnff object sondern entity benutzt. Insofern meint Objekt hier einen sehr allgemeinen Objektbegriff, besser ware Informationstrdger im Sinne von: Alles was durch Informationen (hier im wesentlichen Attribute) beschrieben werden kann. Einige deutschsprachige Autoren verwenden fiir entity die direkte Ubersetzung Entitat.

2.2 Objekte und Beziehungen

13

Und dies in vollem Umfang. Es werden also keine weitergehenden Strukturen, z.B. formelle oder informelle Beziehungsgeflechte, keine Informationsfliisse, keine Regeln (im Sinne der KI), usw. erfasst bzw. modelliert. Es wird auch nur „Struktur" modelliert, d.h. ein statisches informationelles Abbild des Weltausschnitts erstellt, und nicht „Dynamik", also die mogliche Informationsverarbeitung. Exkurs: Informationstrager Ftir Objekte im hier gebrauchten Sinn wird in der angelsachsischen Literatur nicht der Begriff object, sondern der Begriff entity verwendet. Dieser bedeutet, betrachtet man den Sprachgebrauch - soviel wie Informationstrager im Sinne von: Alles was durch Informationen (hier im wesentlichen Attribute) beschrieben werden kann. Einige deutschsprachige Autoren verwenden flir entity die direkte Ubersetzung Entitdt. Die groBe Ausnahme steUt der objektorientierte Ansatz dar (vgl. Kapitel 7). Hier wird ein Schritt dahin getan, auch die (einfachen) Verarbeitungsschritte gleich im Datenmodell mit zu modellieren. Im folgenden nun einige Beispiele fur den ersten Schritt, das Erkennen von Objekten und Beziehungen in Weltausschnitten. Es handelt sich dabei durchweg um Weltausschnitte, die in den folgenden Kapiteln wieder thematisiert werden. Im Studienbetrieb einer Hochschule sind unschwer die "Objekte" STUDIERENDE, DOZENTEN, VORLESUNGEN und VERANSTALTUNGSRAUME zu erkennen. Eine wichtige Beziehung ist hier: Studierende besuchen Vorlesung. Eine andere: Dozenten halten Vorlesung. Eine, die drei Gruppen von Objekten in Beziehung setzt, ist: Studierende besuchen Vorlesung bei Dozenten. Auch der Markt fur Datenbanksysteme stellt einen Weltausschnitt dar. Hier sind auf Anhieb folgende Objekte erkennbar: die DATENBANKSYSTEME selbst, z.B. Oracle, ACCESS, Visual dBase, Paradox, LARS, AskSAm, Folio Views; die Firmen, die diese Software programmieren lassen und auf den Markt bringen (PRODUZENTEN): Borland, Microsoft, usw.; die HANDLER, die diese Software dem Endkunden verkaufen. Ebenfalls sofort erkennbar sind die Beziehungen produziert und verkauft. Erstere stellt die Datenbanksysteme mit den Produzenten in Beziehung, zweitere die Systeme mit den Handlem. In einem Weltausschnitt zu den Angestellten eines Untemehmens sind sicherlich sofort die Angestellten selbst (Herr Meier, Frau Miiller, usw.) als Objekte erkennbar, erganzt durch die Abteilungen (Organisation, EDV, Finanzbuchhaltung, Bibliothek, usw.). Auch eine Beziehung zwischen diesen Objekten bietet sich gleich an: ist beschdftigt in. Soweit der erste Schritt, das Erkennen von Objekten und Beziehungen. Er fiihrt in der Regel zu einer Vielzahl von Informationen, die weiter strukturiert werden. Bei dieser Strukturierung kann es auch ohne weiteres Fiir die zu unterstiitzenden Geschaftsprozesse

Beispiel HOCHSCHULE

Beispiel MARKT FUR DATENBANK SYSTEME

Beispiel ANGESTELLTE

14

Schrittweises Verfeinern

Vermeidbare Fehler

geschehen, dass Objekte als solche wieder verschwinden oder dass neue entstehen. Obwohl dieses Zusammenstellen von Objekten und Beziehungen nur den Einstieg darstellt, ist es der erste und wichtige Schritt bei der Erstellung eines Datenmodells. Am besten fiihrt man ihn so durch, dass alle Beteiligten ihre Ideen und Vorschlage zusammentragen. Zu den Beteiligten gehoren neben den Datenbankspezialisten auch die zukiinftigen Nutzer der Datenbank, z.B. Mitarbeiter des Lagers, wenn es um eine Datenbank fUr das Lagerwesen geht oder Mitarbeiter der Beschaffung, wenn das Beschaffungswesen in einer Datenbankanwendung erfasst werden soil. Oftmals fallen die beiden Gruppen allerdings zusammen oder die Nutzergruppe steht erst mal nicht zur Verfiigung. Bin haufig gemachter Fehler bei dieser "Objekt- und Beziehungsfindung" besteht darin, dass auch dynamische Aspekte der Anwendung mitberucksichtigt werden. Dies ist aber nicht richtig. In einem Datenmodell werden nicht Vorgange bzw. Prozesse modelliert, sondem die statischen Aspekte, die Beschreibung der Objekte und Beziehungen, mit denen danach dann z.B. Prozesse ("Rechnungsstellung", "Lohnabrechnung") abgebildet werden konnen. Mit anderen Worten: Die aus dem Datenmodell hervorgehende Datenbank stellt Informationen fiir die Geschaftsprozesse zur Verfiigung, sie modelliert nicht Aspekte derselbigen (auf die Ausnahme in der objektorientierten Datenmodellierung wurde schon hingewiesen)

2.3 Schritt 2: Attribute festlegen

2 Grundbegriffe und -konzepte

Mit Attributen zu Klassen

Doch nun zuruck zu den Attributen. Was waren alle diese identifizierten Objekte und Beziehungen ohne beschreibende Information. Zumindest datenbanktechnisch waren sie ohne Bedeutung. Deshalb besteht der zweite Schritt nun darin, den Objekten und Beziehungen Attribute zuzuordnen. Dies ist ein wichtiger Schritt und einer der wohlbedacht sein muss: Es werden genau die Attribute den Objekten bzw. Beziehungen zugeordnet, die fur die Abwicklung der Geschaftsprozesse im zugehorigen Anwendungsbereich benotigt werden. Friiher sprach man statt von den Geschaflsprozessen, die durch die Datenbank unterstiitzt werden, vom Zweck der Datenbank. In einfachen Fallen ist auch heute noch diese Formulierung sinnvoll. Nehmen wir als Beispiel eine Datenbank, die eine einzelne Aufgabe untersttitzen soil, z.B. die Absatzprognoserechnung fur die Produkte eines Untemehmens. Hier werden die Attribute von dieser einzelnen Aufgabe abgeleitet. Die konkrete Ausgestaltung eines Datenmodells wird zum einen durch den jeweiligen datenbanktheoretischen Ansatz gepragt, zum anderen aber auch durch einen weiteren Faktor: durch den Zweck der Datenbank bzw. durch die mit der Datenbank geplante Geschaftsprozesse. Ein Beispiel: Im Falle eines Datenmodells DATENBANKSYSTEME konnte der Schwer-

2.3 Mit Attributen zu Klassen

15

punkt eher auf den kommerziellen Aspekten liegen. Dann ergibt sich ein anderes Datenmodell (mit mehr Angaben zu Preisen, Rabatten, Verfugbarkeit, usw.), als wenn der Schwerpunkt auf technischen Aspekten liegt. Im letzteren Fall wlirden eher die zur Verfugung stehende Datentypen, Performance-Kennziffem, Leistungsfahigkeit der Masken- und ReportGeneratoren, usw. im Vordergrund stehen. Bevor wir uns dieser „Attributfmdung" naher zuwenden, noch der nachste Schritt, der eine weitere Klarung der Objekt- und Beziehungsstruktur bringt. Er besteht in einem Abstraktionsschritt, der Zusammenfassung gleich strukturierter Objekte und Beziehungen. „Gleich strukturiert" bedeutet hier „dieselben Attribute haben". Daraus entstehen dann Gruppen gleichartiger Objekte und Beziehungen, die Klassen genannt werden:

SchrittS: Klassen bilden

Die Objekte und Beziehungen, die dieselben Attribute besitzen, werden zu Objektklassen bzw. Beziehungsklassen zusammengefasst. Dies erfolgt oft schon automatisch beim ersten Schritt, beim Erkennen der Objekte und Beziehungen, wo wir unbewusst schon gleich an alle Studierende, an alle Angestellten, usw. denken, wenn wir die entsprechenden Objekte wahrnehmen. Diese Klassenbildung ist aber nicht immer so einfach und muss auf jeden Fall liber die Attribute iiberpriift werden. Dies soil an einem der oben eingefuhrten Beispiele verdeutlicht werden. Erinnerung: Um im Text die Ubersichtlichkeit zu erhohen, wird folgende typographische Festlegung getroffen: • Weltausschnitte / Anwendungsbereiche werden fett, etwas vergroBert und in Arial gesetzt: VORLESUNGSBETRIEB. •

Typographische Festlegung

Datenmodelle sind ebenfalls in Arial sowie in Kapitalchen gesetzt: MARKT FUR DATENBANKSYSTEME

• •

Relationen, Entitatstypen, Beziehungstypen, Klassen sind in Arial und in GroBbuchstaben gesetzt: ANGESTELLTE Attribute sind in Arial gesetzt: Personalnummer

In unserem Weltausschnitt M A R K T FUR DATENBANKSYSTEME fmden wir im ersten Schritt fiir die Systeme selbst die Attribute Name, Typ, Plattform und Produzent. Entsprechend bilden wir eine Objektklasse DATENBANKSYSTEME. Fur die PRODUZENTEN legen wir fest, dass wir die Attribute Name, Ort, Strafie, Land und Telefon erfassen. Fur die HANDLER erganzen wir diese Attribute noch, well uns auch deren Fax-Nummer und Rabatte interessieren. Entsprechend obiger Kegel fassen wir somit PRODUZENTEN und HANDLER zu je einer Objektklasse zusammen. Bezuglich der Beziehung Handler bietet ein Datenbanksystem auf dem Markt an (wir nennen es ANGEBOT) fallt uns erst mal nur ein, dass wir

Markt flir Datenbanksyste me

16

2 Grundbegriffe und-konzepte

den Preis festhalten konnten, zu dem dies geschieht, da wir aus Erfahrung wissen, dass die Preise der Handler sich bei ein und demselben System durchaus unterscheiden. Nur um die Bedeutung der obigen Kegel nochmals zu verdeutlichen: Wurden wir uns entschlieBen, fur die einzelnen Typen von Datenbanksystemen spezifische Attribute zu erfassen, z.B. Invertierungstechnik bei Information Retrieval Systemen oder die Art der Vererbungstechnik bei Objektorientierten Systemen, konnten diese nicht einer einzigen Objektklasse zusammengepackt werden, sondem sie mussten auf verschiedene verteilt werden. Die folgende Tabelle fasst die jetzt festgelegten Objekt- und Beziehungsklassen mit ihren Attributen zusammen. Weltausschnitt M A R K T FUR D A T E N B A N K S Y S T E M E

1 1 Objekt- / Beziehungsklasse Attribute DATENBANKSYSTEME Name, Typ, Plattform, LPreis, Pro- 1 duzent PRODUZENTEN Name, Ort, StrafJe, Land, WWW Name, Ort, StraUe, Tel, Fax, RaHANDLER batte, AnsprP

IANGEBOT 2.4

J^reis

1

Objekte erkennen durch Attribute

Das Erkennen von Objekten und Beziehungen ist im Regelfall - zumindest bei den ersten Schritten - einfach. Trotzdem lohnt es sich, auch hierfur ein sicheres tiberprufbares Verfahren zu haben und sich nicht nur auf seine Intuition zu verlassen. Das Verfahren besteht darin, die fiir irgendein Realweltphanomen gefundenen Attribute naher zu betrachten. Dabei gilt folgende Kegel: Werden irgendwelche Realweltphanomene durch ein Attribut identifiziert, dann ist dieses erst mal eine einfache Benennung, ein Attribut, das andere Objekte beschreibt. Zum Beispiel AbteilungsbezeichnungQn. Diese konnen den Angestellten zugewiesen werden, um festzuhalten, in welcher Abteilung sie arbeiten: • • •

Attribut: Abteilungsbezeichnung Objekte: ANGESTELLTE Die Auspragungen von Abteilungsbezeichnung werden den Angestellten zugewiesen und halten fest, in welcher Abteilung sie arbeiten.

Oder die Personalnummem von Angestellten, durch die festgehalten wird, in welchen Projekten sie mitarbeiten: • •

Attribut: Personalnummer Objekte: PROJEKTE

2.4 Objekte erkennen durch Attribute

•

17

Die Auspragungen von Personalnummer werden den Projekten zugewiesen und halten fest, wer in welchem Projekt mitarbeitet.

Noch ein Beispiel: • • •

Attribut: Programmiersprachenfham^; Objekte: ANGESTELLTE Die Auspragungen von Programmiersprachen werden den Angestellten zugewiesen und halten fest, welche Programmiersprache er oder sie (hauptsachHch) benutzt.

Kommt nun aber bei der Beschreibung des Realweltphanomens zu der Benennung nur ein einziges beschreibendes Attribut dazu, erfolgt ein qualitativer Sprung: Die Beschreibung etabliert nun fur die Datenmodellierung Objekte bzw. Beziehungen. In den obigen Beispielen: •

Das Attribut Abteilungsbezeichnung wird erganzt durch das Attribut Abteilungsleiter (undspdter noch viele mehr): • Attribut 1: Abteilungsbezeichnung • Attribut 2: Abteilungsleiter • Objekte: Jetzt geht es um ABTEILUNGEN (sie werden identifiziert und zusatzlich beschreiben).

•

Das Attribut Personalnummer wird erganzt durch das Attribut Name (undspdter noch viele mehr): • Attribut 1: Personalnummer • Attribut 2: Name • Objekte: Jetzt geht es um ANGESTELLTE (sie werden identifiziert und zusatzlich beschrieben).

•

Das Attribut Programmiersprachen(bezeichnung) wird erganzt um das Attribut (verwendeter) Compiler: • Attribut 1: Programmiersprachen • Attribut 2: Compiler • Objekte: Jetzt geht es um PROGRAMMIERSPRACHEN (sie werden identifiziert und zusatzlich beschrieben).

Jewells ein weiteres Attribut gentigt also fur die Etablierung der Objektoder Beziehungsbeschreibung und im weiteren fur die Einrichtung der Objekt- bzw. Beziehungsklassen. In der realen Modellierung kommen aber natiirlich viele weitere dazu. Mit dieser Regel ist es relativ einfach, Objekte und Beziehungen im datenbanktechnischen Sinn zu erkennen. Zusammengefasst kann diese Regel auch so formuliert werden: Wird ein Realweltphanomen durch ein Attribut identifiziert und durch mindestens ein weiteres beschrieben, handelt es sich datenbanktechnisch um eine Objekt- oder Beziehungsklasse.

identifizierung + Beschreibung "^ Objekte

18

2.5

2 Grundbegriffe und -konzepte

Datenmodelle

Wie oben schon angeftihrt, ist die Gmndlage jeder Datenbank ein sog. Datenmodell. Was sind aber nun Datenmodelle? Abstrahiertes Abbild der Realitat

Modellierungsinstrumente

•

Datenmodelle stellen ein abstrahiertes Abbild eines Anwendungsbereichs oder Weltausschnittes dar. „Abstrahiert" deshalb, weil von der vielschichtigen Realitat nur die Strukturen aufgenommen werden, die fiir die Anwendung benotigt werden. • Datenmodelle sind theoriespezifisch. D.h., sie werden mit Hilfe eines Instrumentariums erstellt, das eine Datenbanktheorie zur Verfugung stellt. Z.B. die relationale Datenbanktheorie, die objektorientierte oder die fur die semantische Modellierung. Diese werden in den Kapiteln dieses Buches vorgestellt. • Nach Fertigstellung werden Datenmodelle mit Hilfe eines Datenbanksystems in eine Datenbank umgesetzt. Diese drei Punkte versucht die folgende Abbildung zu veranschaulichen.

Anwendungsbereich/Weltausschnitt ..wird mit Hilfe einer Modellierungstheorie umgesetzt in ein...

Datenmodell ..wird mit Hilfe eines Datenbanksystems umgesetzt in eine...

Datenban Abbildung 2.5-1:

Vom Weltausschnitt zur Datenbank

Datenmodelle sind also ein Werkzeug, um zu Datenbanken zu kommen. Ein Datenmodell ist ein Abbild des jeweiligen Weltausschnitts, das mit den Mittein und gemafJ den Regein des jeweiligen datenbanktheoretischen Ansatzes realisiert wurde und das mit Hilfe eines Datenbanksystems in eine Datenbank umgesetzt wird.

2.5 Datenmodelle

19

Die Nutzung eines Instruments bedeutet immer auch eine Einschrankung der Moglichkeiten. Hier gilt, dass der jeweilige datenbanktheoretische Ansatz festlegt, was wir erfassen konnen und mit welchen Mitteln wir dies tun. Hier nur einige sehr allgemeine Festlegungen, die spezifischen werden in den einzelnen Kapiteln diskutiert: •

•

Festlegungen

Alle heutigen Datenmodelle sind attributbasiert, d.h. sie erfassen den Anwendungsbereich durch die Zuweisung von Attributsauspragungen zu Objekten und Beziehungen zwischen Objekten. Alle heutigen Datenmodelle gehen - wie oben gezeigt - im Kern von Objekten und Beziehungen aus, die im Anwendungsbereich gesucht und beschrieben werden.

Weiter legt das Datenmodell als Methode fest, was wir von den sonstigen Strukturen und Regeln des Anwendungsbereichs, der Semantik, erfassen konnen. Diese Semantischen Integritatsbedingungen (constraints) schranken die Operationen ein, die auf den Daten erlaubt sind. Bis zum Aufkommen der objektorientierten Modellierung gait auBerdem, dass ein Datenmodell nur Strukturen (statische Aspekte) erfasst, nicht „Verhalten" (dynamische Aspekte). In der historischen Entwicklung gab es i.w. die nachfolgend angeftihrten Datenmodelle. Hierarchische Datenmodelle waren die ersten und erlaubten im wesentlichen die Modellierung hierarchischer Beziehungen (Baumstrukturen) in den Datenbestanden. Diese mussten bei der Erstellung der Datenbank fest angegeben werden. Hierfur gab es spezifische Datenbanksysteme (die ganze erste Generation der Datenbanksysteme erlaubte nur solche Datenbanken bzw. Datenmodelle). Datenmodelle fur Netzwerkdatenbanken. Sie erlaubten die Uberwindung der nur hierarchischen Strukturen, indem sie netzwerkartige Beziehungen zwischen den Datenbestanden ermoglichten. Auch hier mussten die Beziehungen bei der Erstellung der Datenbank fest angegeben werden. Hierfiir gab es spezifische Datenbanksysteme. Relationale Datenmodelle. Diese bestehen im Kern aus (spezifisch geformten „flachen") Tabellen, die beliebig miteinander in Beziehung gesetzt werden konnen (vgl. unten). Die Beziehungen (hier: die Beziehungen zwischen den Relationen) werden liber die Inhalte einzelner Felder, den Werten von Attributen, hergestellt. Hierfur gibt es spezifische Datenbanksysteme (so gut wie alle heute in der Praxis eingesetzten Datenbanksysteme sind relationale Datenbanksysteme). Objektorientierte Datenmodelle entstanden aus dem ganz allgemeinen objektorientierten Ansatz. Aus Datenbanksicht ist das wesentliche Neue, dass hier zum ersten Mai in der Geschichte der Datenbanksysteme und der Datenmodellierung Struktur und Verhalten zusammen modelliert werden. Echte objektorientierte Datenbanksysteme wiirden, gabe es sie, objektorientierte Datenmodelle untersttitzen. Das was heute allerdings als ob-

Hierarchische Datenmodelle

Datenmodelle fiir Netzwerkdatenbanken

Relationale Datenmodelle

Objektorientierte Datenmodelle

20

Semantische Datenmodelle.

2 Grundbegriffe und -konzepte

jektorientierte Datenbanksysteme angeboten wird, sind nur Werkzeuge, um (z.B. den C++-Programmierem) die persistente Datenhaltung zu erleichtern (wie z.B. POET). Semantische Datenmodelle erlauben die Erstellung von Datenmodellen mit denen etwas mehr von der Semantik des Weltausschnitts erfasst werden kann als z.B. in relationalen Datenmodellen. Das bekannteste Beispiel sind ER-Modelle. Sie werden unten beschrieben. Hierfur gibt es keine Datenbanksysteme. Die semantische Modellierung ist grundsatzlich (datenbank)systemunabhangig, ER-Modelle konnen in alle anderen iiberfuhrt werden.

3

3.1

MODELLIERUNG RELATIONALER D A T E N B A N K E N

Einfuhrung

Wie in Kapitel 2 ausgefuhrt wurde, ist die Grundlage einer jeden Datenbank ein Datenmodell. Dieses ist ein Abbild des jeweiligen Weltaussclinitts, das mit den Mitteln und gemaB den Regeln des jeweiligen datenbanktheoretischen Ansatzes realisiert wurde. In diesem Kapitel wird nun betrachtet, welche "Mittel und Regeln" der relationale Ansatz fiir die Erstellung von Datenmodellen zur Verfugung stellt. Im ersten Schritt auf dem Weg zum relationalen Datenmodell werden wie in Abschnitt 2.2 beschrieben - Objekte und Beziehungen gesucht. Auch die relationale Datenbanktheorie beruht auf der Festlegung, dass die reale Welt aus Objekten (Informationstragem, vgl. ->entity) besteht und dass diese Objekte durch Beziehungen (relationships) verkntipfl sind (vgl. Kapitel 2). Was waren alle diese identifizierten Objekte und Beziehungen ohne beschreibende Information? Zumindest datenbanktechnisch waren Sie ohne Bedeutung, nicht existent. Deshalb besteht der zweite Schritt darin, den Objekten und Beziehungen Attribute zuzuordnen. Oftmals werden auch liber die Attribute die Objekte und Beziehungen entdeckt, z.B. wenn Geschaftsobjekte (business objects) der Datenmodellierung zugrundeliegen, z.B. Rechnungen, Lieferscheine, usw. Dann entfallt der im obigen Absatz beschriebene erste Schritt. Die Zuordnung der Attribute zu den Objekten und Beziehungen ist also ein wichtiger Schritt. Findet man neben einem identifizierenden Attribut, einer Benennung also, noch mindestens ein weiteres, dann wird das Objekt erst wirklich zum Objekt, die Beziehung erst wirklich zur Beziehung (vgl. Kapitel 2) und die Benennung wird zum Schliissel. Dies ist ein wichtiger Schritt und einer der wohlbedacht sein muss: Es werden genau die Attribute den Objekten bzw. Beziehungen zugeordnet, die fur die Abwicklung der Geschaftsprozesse im zugehorigen Weltausschnitt benotigt werden. Nach dieser Zuordnung der Attribute werden die Objekte und Beziehungen zusammengefasst, die durch dieselben Attribute beschrieben werden. Diese zusammengefassten Objekte bzw. Beziehungen werden dann Objektklassen bzw. Beziehungsklassen genannt (vgl. Kapitel 2).

Objekte und Beziehungen suchen

Attribute festlegen

Finden durch Attribute

Existenz durch Attribute

Klassen bilden

3 Modellierung Relationaler Datenbanken

22

Soweit die Bildung der Klassen. Sie stellt einen wichtigen Strukturierungsschritt im Rahmen der Datenmodellierung dar und fuhrt direkt zur Bildung von Relationen. Typographische Festlegung

Erinnerung: Um im Text die Ubersichtlichkeit zu erhohen, wird folgende typographische Festlegung getroffen: • Weltausschnitte / Anwendungsbereiche werden fett, etwas vergroBert und in Arial gesetzt: VORLESUNGSBETRIEB. •

Datenmodelle sind ebenfalls in Arial sowie in Kapitalchen gesetzt: MARKT FUR DATENBANKSYSTEME

3.2

•

Relationen, Entitatstypen, Beziehungstypen, Klassen sind in Arial und in GroBbuchstaben gesetzt: ANGESTELLTE

•

Attribute sind in Arial gesetzt: Personalnummer

Relationen

Im nachsten Schritt wird nun jede der oben eingefuhrten Objekt- und Beziehungsklassen in einer Tabelle erfasst. Die Attributsnamen stehen im Kopf der Spalten, darunter die Auspragungen, in einer Zeile befinden sich jeweils die Attributsauspragungen, die ein Objekt bzw. eine Beziehung beschreiben. Genau diese Tabellen werden, wenn sie bestimmte Eigenschaften haVon Tabellen zu Relationen ben, Relationen genannt. Relationen sind also - auf dieser Ebene der Modellierung - nichts anderes als nach bestimmten Regeln gestaltete Tabellen, mit denen jeweils eine Objekt- oder Beziehungsklasse beschrieben wird. Somit besteht der nachste Schritt im Modellierungsprozess darin, fur jede Objekt- und Beziehungsklasse eine Relation anzulegen. Betrachten wir das Beispiel der Objektklasse DATENBANKSYSTEObjektklasse DATENBANKME. Die Tabelle kann (in einfacher Form) so aussehen, wie unten geSYSTEME zeigt. Die Datenbanksysteme werden durch ihren Namen, ihren Typ^^, ihre Plattform (die, auf der sie zur Verfugung stehen) ^^ und den Produzenten beschrieben. Eines der Attribute muss identifizierenden Charakter haben. Es wird Schliissel (der Relation) genannt und durch eine Raute gekennzeichnet (mehr dazu weiter unten). Von Klassen zu Tabellen

'^ Relationales Datenbanksystem, Information Retrieval System, Netzwerk-Datenbanksystem und Personal Information Manager. ^^ Gruppe der „Intel-PC's", Apple-Rechner, Rechner, die mit UNIX betrieben werden.

3.2 Relationen

23

DATENBANKSYSTEME

1 #Name Typ DBS1 DBS2 DBS3 DBS4 DBS5

RDBS RDBS IRS NDBS PIM

Plattformen PCs UNIX-Rechner PCs PCs Apple Macintosh

Produzent 1 P3 P1 P3 P2 P1

Der Einfachheit halber wurden fiir die Namen von Systemen und Produzenten inhaltslose Kurzbezeichnungen gewahlt. Auch wenn diese Tabelle aussieht wie die meisten anderen, gelten fur sie im Rahmen der relationalen Datenbanktheorie doch einige Besonderheiten. Die wichtigsten: •

•

• • •

Jede Zeile (auch "Reihe" oder "Tupel") beschreibt ein Objekt (bzw. eine Beziehung), die Tabelle als Ganzes beschreibt die Objektklasse oder Beziehungsklasse). In jeder Spalte steht als Kopf der Name eines Attributs, darunter stehen die Attributsauspragungen, die das jeweilige Objekt (die Beziehung) beschreiben. Eine Relation hat mindestens zwei Attribute, wovon mindestens eines Schlusselattribut ist. Es gibt keine zwei identischen Tupel, d.h. jedes Tupel beschreibt ein anderes Objekt. Im Schnittpunkt jeder Zeile und Spalte wird genau eine Attributsauspragung festgehalten, nicht mehr. Dies macht die Tabelle zm flachen Tabelle.

Eigenschaften von Relationen

Letztgenannte Eigenschaft ist besonders wichtig im relationalen Ansatz und bereitet beim Aufbau einer Datenbank (bei der Erstellung des Datenmodells) auch die meisten Schwierigkeiten. Sie bedeutet konkret, dass eine Tabelle umorganisiert werden muss (mehr dazu im folgenden), wenn einem Objekt mehr als eine Ausprdgung eines Attributs zugeordnet werden kann (man spricht dann von Mehrfacheintragen oder auch Wiederholungsgruppen^"^).

Flachheit

Diese Datentabellen mit den genannten Eigenschaften werden Relationen genannt. Auf ihnen und nur auf ihnen beruht der relationale Ansatz und auf diesem wiederum die Relationalen Datenbanksysteme (RDBS). Alle Objekt- und Beziehungsklassen werden durch Relationen erfasst und nur durch diese.

Im Mittelpunkt: Flache Tabellen

Die Auswertungssoftware (Abfi*agesprachen, Berichtsgeneratoren, ...) Relationaler Datenbanksysteme ist ebenfalls voU auf diesen Informationstyp zugeschnitten. Die folgende Abbildung 3.2-1 zeigt, wie Relationen als Tabellen dargestellt werden konnen und wie sie aufgebaut sind. Vom angelsachsischen „repeating groups"

24

3 Modellierung Relationaler Datenbanken

Zusammengefasst: Relationen Attribut, das als Schlussel benutzt wird (durch#markiert)

Attribut, das als Fremdschlussel dient (markiert durch Unterstreichung)

Namen der Attribute

Name der Relation (Tabelle)

DATENBANKSYSTEME Ein Tupel (eine Zeile) der Relation

Keine Mehrfacheintrage: Jedem Objekt/ jeder Beziehung darfje Attribut nur EINE Auspragung zugewiesen werden.

Abbildung 3.2-1: Schreibweisen

#Nanne

Typ

DBMS1 RDBMS DBMS2 RDBMS DBMS OODBS DBMS4 IRS DBMS5 OODBS

Attributs auspragungen desjeweiligen Attributs

Spalte der Relation (Tabelle)

Grad der Relation (Anzahl der Attribute) Aufbau von Relationen

Neben der grafischen Notation in Form einer Tabelle wird fur Relationen auch die folgende textliche Schreibweise benutzt: RELATIONENNAME (#Ai, A2, A3, ...) Dabei stehen Ai A2 usw. ftir die Attribute der Relation. Die Raute kennzeichnet das Schltisselattribut. Vgl. zu den verwendeten Abkurzungen das Abkiirzungsverzeichnis.

3.3 Beziehungen zwischen Objektklassen bzw. Relationen

25

Soil ein Attributsnamen um die Angabe seiner Relation erganzt werden (z.B. in SQL, wo es unabdingbar ist), wird folgende Notation benutzt: RELATIONENNAME.Attributname, also z.B. DATENBANKSYSTEME.Name, PRODUZENTEN.Ort Oder DATENTYPEN.NameDBS.

Weitere Erlauterungen zu Notationen fur Relationen folgen weiter unten. Die grafische Notation fiir Relation ist wie in der folgenden Abbildung angegeben. In einem Rechteck wird in der oberen Halfte der Relationenname angegeben, darunter die Schltissel und Fremdschlussel^^ (und nur diese). DATENBANKSYSTEME #Name, Produzent

Abbildung 3.2-2:

Grafische Darstellung von Relationen

Die Objektklassen, die im vorigen Schritt gefunden wurden, konnen nun ohne Schwierigkeiten in solche Relationen ubemommen werden. Die Beziehungsklassen dagegen bedurfen einer Erganzung, die im nachsten Abschnitt vorgestellt wird. Die folgende Tabelle fasst die Grundbegriffe zu Relationen zusammen. Dabei sind die Begriffe der datenbanktheoretischen Diskussion um die informellen Begriffe erganzt, soweit solche existieren:

Grundbegriffe

Relationale Begrifflichkeit 1 Informell 1 Tabelle Zeile Eigenschaft - Bezeichnung Eigenschaft - Auspragung

3.3

Formell Relation Tupel Attribut(sname) Attributsauspragungen, Wertebereich

Englisch 1 table row, tuple attribute domain

Beziehungen zwischen Objektklassen bzw. Relationen

Oben wurden schon Beziehungen zwischen Objekten bzw. Objektklassen eingefiihrt. Sie mussen beim Datenbankentwurf beachtet werden. Einige werden schon in den ersten Schritten entdeckt und dann gleich als Beziehungsklassen angelegt. Andere werden erst entdeckt, wenn die Relationen

Fremdschltissel dienen der Verkntipfting, vgl. Absclinitte 3.3 und 3.4.

Beziehungen entdecken

3 Modellierung Relationaler Datenbanken

26

Kardinalitat

angelegt wurden und wenn diese mit den Bediirfhissen der zu untersttitzenden Geschaftsprozesse abgeglichen werden. Diese Beziehungen miissen nun ftir das Datenmodell genauer bestimmt werden und zwar so, dass geklart wird, wieviele Objekte an der Beziehung teilnehmen. Bei zweistelligen Beziehungen (den haufigsten), d.h. Beziehungen zwischen zwei Objektklassen (oder, falls sie bereits in Relationen eingefiillt wurden, zwei Relationen) also, wieviele Objekte (Tupel) der einen Objektklasse (Relation) mit Objekten (Tupeln) der anderen semantisch verknUpft sind. Ftir die Datenbank und damit das Datenmodell ist dabei jeweils nur wichtig, ob maximal ein Objekt oder ob mehrere an der Beziehung teilhaben. Diese Eigenschaft wird auch Kardinalitat der Beziehung genannt. Einige Beispiele mogen diese Eigenschaft von Beziehungen erlautem: •

•

•

1:1 Einer hier, einer dort

Ftir die Beziehung zwischen Studierenden und Vorlesungen in unserem Weltausschnitt VORLESUNGSBETRIEB gilt: ein Studierender kann mehrere Vorlesungen besuchen, eine Vorlesung wird von mehr als einem Studierenden besucht. Fur die Beziehung zwischen Softwareproduzenten und Datenbanksystemen im Weltausschnitt D A T E N B A N K S Y S T E M E gilt: ein Softwareproduzent kann mehrere Datenbanksysteme auf dem Markt anbieten, ein Datenbanksystem kommt aber von einem Softwareproduzenten. Fur die Beziehung zwischen Angestellten und Abteilungen im Weltausschnitt A N G E S T E L L T E gilt: ein Angestellter gehort zu genau einer Abteilung, eine Abteilung hat i.d.R. mehrere Angestellte.

Datenbanktechnisch notwendig ist die Unterscheidung von drei Fallen, die im folgenden vorgestellt werden (vgl. auch die folgende Abbildung). Nehmen wir an, dass in der Datenbank eines Unternehmens die Relationen MITARBEITER und PC (Personal Computer) existieren und dass die PC-Nutzung so geregelt ist, dass einem Mitarbeiter genau ein PC zugeordnet ist und dieser ihm alleine zur Verftigung steht. Eine solche semantische Beziehung verknupft also je ein Tupel aus den beiden Relationen (je ein Objekt aus den beiden Objektklassen) und wird 1:1 - Beziehung genannt. Hier also je einen Mitarbeiter mit einem PC. In einem relationalen Datenmodell wird eine solche Beziehung verankert, indem entweder der Schliissel von MITARBEITER zu den Attributen von PC oder der von PC den Attributen von MITARBEITER hinzugeftigt wird. Wenn MITARBEITER (#PersonalNr, Name, Vorname, ...) und PC (#lnventarNr, Typbezeichnung, ...)

3.3 Beziehungen zwischen Objektklassen bzw. Relationen

27

die beiden Relationen sind, dann wird die 1:1 - Beziehung also z.B. dadurch festgehalten, dass das Attribut InventarNrPC (dies muss hier jetzt unterstrichen sein, dazu spater mehr) in die Relation MITARBEITER eingefugt wird: MITARBEITER (#PersonalNr, Name, Vorname, ..., InventarNrPC) In Tabellendarstellung wird dies noch deutlicher. Zuerst die beiden Ausgangsrelationen: MITARBEITER |#PersonalNr 100 200 1150

1 Name 1 Sulger Muller 1 Radetzky

Vorname Paul Ulrike Siegfried

PC #lnventarNr InvOOl InvOOS 1 InvOOS

Typbezeichnung Server Laptop 1Desktop

Nach der Ubemahme des Schltissels von PC in die Relation MITARBEITER ergibt sich dann z.B.: MITARBEITER |#PersonalNr Name Sulger 100 Muller 200 Radetzky |l50

Vorname Paul Ulrike Siegfried

InventarNrPC A200 B999 A111

1

Das tibemommene Attribut, das also in der anderen Relation Schliissel ist, wird hier Fremdschlussel genannt (vgl. auch Abschnitt 3.4). Es wird durch Unterstreichung gekennzeichnet. Mit Schlusseln/FremdschlUsseln wird somit die relationale Verkntipfung realisiert. Damit ist im iibrigen ein kleines Datenmodell entstanden. In der korrekten grafischen Notation fur relationale Datenmodelle miissen die beiden Relationen angegeben werden. AuBerdem wird durch eine Pfeillinie auf die Beziehung verwiesen:

Fremdschlussel

28

3 Modellierung Relationaler Datenbanken

MITARBEITER

PCs

#PersonalNr, InventarNrPC

#lnventarNr

m3

Abbildung 3.3-1:

Min- / MaxAngaben

0,1
Relationales Datenmodell PC-NUTZUNG in grafischer Notation

Vertiefung: Min-/Max-Angaben Obige Ausfuhrungen zu den 1:1- Beziehungen sind zwar richtig, aber fiir die konkrete Arbeit nicht genau genug. Flir die Prazisierung erganzen wir bei jeder Relation die Angabe, wieviele Tupel hochstens an der Beziehung teilhaben um eine zweite, wieviele mindestens daran teilhaben. Damit entstehen sog. Min-/MaxAngaben, die iiberall in der Modellierung benotigt werden. Mit ihnen kann dann fiir jede Relation die Beziehung wesentlich genauer angegeben werden. Im obigen Fall: • Jeder Angestellte muss einen PC haben. Min-/Max-Angabe: 1,1 (mindestens ein Tupel, hochstens ein Tupel = genau ein Tupel) • Ein Angestellter kann, muss aber nicht einen PC haben. Min-/Max-Angabe: 0,1 (evtl. kein Tupel, hochstens ein Tupel) • Jeder PC muss einem Angestellten zugeordnet sein. Min-/Max-Angabe: 1,1 • Ein PC kann, muss aber nicht einem Angestellten zugeordnet sein. Min-/Max-Angabe: 0,1 Der oben bei der Diskussion der Kardinalitat vorgestellte Fall betrifft die Situation, wenn auf beiden Seiten 1,1 als Min-/Max-Angabe vorliegt: MITARBEITER ^ - > PC mit 1,1 ^ - > 1,1 Dann ist die Situation wie oben beschrieben. Es besteht freie Wahl, welcher Schlussel in die andere Relation als Fremdschlussel Ubernommen wird. Was ist aber, wenn auf einer Seite die Min-/Max-Angabe 0,1 vorliegt? Dann kann in diese Relation nicht der Schliissel der anderen Relation aufgenommen werden, denn es gabe dann Tupel, flir die es einen Attributseintrag nicht geben kann. Im folgenden die moglichen Falle. Hat die Beziehung MITARBEITER
3.3 Beziehungen zwischen Objektklassen bzw. Relationen

29

MITARBEITER 1 #PersonalNr 100 200 150 199 244

Name Sulger Muller Radetzky Stanis Stoll

Vorname Paul Ulrike Siegfried Rolf Eva

InventarNrPC 1 A200 ????? A111

????? ?????

1 1

Hat die Beziehung MITARBEITER 0,1, dann muss der Schlussel von PC nach MITARBEITER iibernommen werden:

1,1 ^^

0,1

MITARBEITER (#PersonalNr, Name, Vorname, ..., InventarNrPC) Die andere Richtung geht nicht. Hat die Beziehung MITARBEITER
0,1 ^-> 0,1

PC-Nutzung (#PersonalNr, #lnventarNrPC) In tabellarischer Darstellung: PC-NUTZUNG 1 #PersonalNr 100 150

#lnventarNrPC A200

1

A111

1

Durch diese neue Relation werden nur die wirklich existierenden Beziehungen erfasst. Eine Besonderheit dieser Relation ist, dass beide Attribute alleine SchlUssel sein konnen, da aufgrund der Zahl eins an der zweiten Stelle der Min-/MaxAngaben jede PersonalNr und jede InventarNrPC nur einmal vorkommen kann. Doch nun weiter mit der Betrachtung der Kardinalitaten. Nach der 1:1Beziehung folgt nun die 1 :n - Beziehung. Bei l:n - Beziehungen nimmt auf der einen Seite jeweils nur ein Tupel und auf der anderen mehrere an der Beziehung teil. In der Abbildung unten wurde dafur die Beziehung ABTEILUNGSZUGEHORIGKEIT zwischen MITARBEITER und ABTEILUNG angefuhrt: Ein Mitarbeiter gehort zu einer Abteilung, eine Abteilung hat aber^^ natlirlich in der Kegel mehr als einen Mitarbeiter. Eine seiche Kardinalitat wird mit 1 :n bezeichnet. Wie kommt nun eine seiche 1 :n - Beziehung in das Datenmedell und damit (spater) in die Datenbank? Ganz einfach wiederum durch Uber-

Grundsatzlich gilt: allein die Moglichkeit, dass mehr als ein Objekt (mehr als ein Tupel) an einer Beziehung teilhaben kann, erhoht bereits ihre Stelligkeit auf der jeweiligen Seite liber 1 hinaus, da dieser Fall dann ja in der Datenbank erfasst werden muss und die hohere Stelligkeit die niedrigere umfasst, aber nicht umgekehrt.

l:n Einer hier, viele dort

30

3 Modellierung Relationaler Datenbanken

nahme des Schlussels der einen in die andere. Allerdings ist hier, im Gegensatz zur 1:1 - Beziehung nur eine "Richtung" moglich. Die Relation, von der mehr als ein Objekt an der Beziehung teilnimmt, nimmt den Schliissel der anderen auf. Die umgekehrte Losung wurde zu Mehrfacheintragen fiihren und damit gegen eine der Defmitionen von Relationen verstoBen. Hier das Beispiel. Zuerst die Ausgangsrelationen, textlich und tabellarisch: MITARBEITER (#PersonalNr, Name, Vorname, ...) MITARBEITER |#PersonalNr Name Sulger 100 200 Mijller Radetzky 150 102 Meindl Friedrich 300

Vorname Paul Ulrike Siegfried Karl Eugenie

und ABTEILUNGEN (#Abteilungsname, Abteilungsleiter, ...) ABTEILUNGEN |#Abteilungsname 1 Organisation Personalwesen 1 Lager

Abteilungsleiter Muller Paulsen Meiners

Die 1 :n - Beziehung wird nun dadurch in der Datenbank verankert, dass in MITARBEITER der Schlussel von ABTEILUNGEN festgehalten wird: MITARBEITER (#PersonalNr, Name, Vorname, me) MITARBEITER |#PersonalNr Name Sulger 100 Muller 200 Radetzky 150 Meindl 102 Friedrich 300

Vorname Paul Ulrike Siegfried Karl Eugenie

Abteilungsna-

Abteilunqsname 1 Organisation 1 Organisation Personalwesen Lager Personalwesen |

Das neu hinzugekommene Attribut wurde wiedemm unterstrichen. An der tabellarischen Darstellung ist auch leicht erkennbar, dass der umgekehrte

3.3 Beziehungen zwischen Objektklassen bzw. Relationen

31

Weg nicht moglich ist. Das Hinzufugen der PersonalNr in die Relation ABTEILUNGEN hatte zu Mehrfacheintragen gefuhrt. Auch hier entsteht ein kleines Datenmodell, das am besten in der grafischen Notation erkennbar ist:

MITARBEITER

ABTEILUNGEN

#PersonalNr, Abteilunasname

#Abteilungsname

Abbildung 3.3-2:

Relationales Datenmodell ABTEILUNGSZUGEHORIGKEIT in grafischer Notation.

Vertiefung: Min-/Max-Angaben Auch hier kann wieder durch die Erganzung um die mindestens vorliegende Teilnahme die Modellierung prazisiert werden. Insgesamt sind fiir die Abteilungszugehorigkeit (MITARBEITER
3. 0,l^->0,n 4. l , l < - ^ 0 , n zu unterscheiden. Da hier in der Grundkonstellation der Schlussel von ABTEILUNGEN bei MITARBEITER eingefugt wird, machen die Falle 2 und 4 keine Schwierigkeiten. Die Falle 1 und 3 dagegen schon. Wenn es tatsachlich Mitarbeiter gibt, die aus irgendeinem Grund keine Abteilungszugehorigkeit haben, kann der Schlussel von ABTEILUNGEN nicht dorthin als Fremdschlussel wandern. Deshalb muss hier in den Fallen 1 und 3 eine eigene Relation eingerichtet werden. Zuerst die Ausgangsrelationen: MITARBEITER 1 #PersonalNr 100 200 150 102 300

Name Sulger Mulier Radetzky Meindl Friedrich

Vorname Paul Ulrike Siegfried Karl Eugenie

ABTEILUNGEN 1 #Abteilungsname Organisation Personalwesen Lager

Abteilungsleiter Mulier Paulsen Meiners

Angenommen, Sulger und Mulier seien keiner Abteilung zugeordnet, dann ent-

32

3 Modellierung Relationaler Datenbanken

steht folgende Relation: ABTEILUNGSZUGEHORIGKEIT #PersonalNr Abteilungsname Personalwesen 150 102 Lager Personalwesen 300 In textlicher Notation: ABTEILUNGSZUGEHORIGKEIT(#PersonalNr, Abteilungsname) Beide Attribute sind dann Fremdschlussel. n:m Viele hier, viele dort.

Sehr viele Beziehungen sind so strukturiert, dass mehrere Tupel der einen Relation mit mehreren der anderen in Beziehung stehen (in beiden Richtungen). So bei einer Beziehung PROJEKTMITARBEIT: Ein Mitarbeiter kann in mehreren Projekten mitarbeiten, ein Projekt kann mehrere Mitarbeiter haben (vgl. auch die folgende Abbildung). Eine solche Beziehung wird n:m - Beziehung genannt. Beziehungen mit einer solchen Kardinalitat werden in relationalen Datenbanken dadurch festgehalten, dass eine zusdtzliche Relation eingerichtet wird, in der die Schlussel der beteiligten Relationen nebeneinander stehen. Im folgenden Beispiel sollen als Ausgangsrelationen MITARBEITER und PROJEKTE vorliegen: MITARBEITER (#PersonalNr, Name, Vorname, ...) MITARBEITER |#PersonalNr Name Sulger 100 MiJiJer 200 Radetzky 150 Meindl 102 Friedrich 300 Paulsen 350 Meiners 390

Vorname Paul Ulrike Siegfried Karl Eugenie Heinrich Lars

PROJEKTE (#ProjektBez, Leiter, Budget, ...)

3.3 Beziehungen zwischen Objektklassen bzw. Relationen

33

PROJEKTE #ProiektBez BPR^' Change Management IT2010

Leiter Muller Paulsen Meiners

Budget 10000 50000 1500000

Die n:m - Beziehung wird durch eine zusatzliche Relation, PROJEKTMITARBEIT, festgehalten: PROJEKTMITARBEIT (#(PersonalNr. Proiektname)) PROJEKTMITARBEIT ProiektBez BPR BPR Change Management

PersonalNr Muller Radetzky Radetzky

#(Pro]ektBez, PersonalNr) Diese angegebenen Tupel genugen, um die n:m - Beziehung deutlich zu machen: Ein Projekt hat mehrere Mitarbeiter, ein Mitarbeiter ist in mehreren Projekten. Eine solche Relation wird auch Verb indungsrelation genannt, weil sie die anderen beiden semantisch (und dann spater auch fur Abfragen und Auswertungen) verkntipft. Auch sie benotigt nattirlich einen Schltissel. Dieser besteht aus den beiden von den Ausgangsrelationen iibemommenen Attributen und ist unten an der Tabelle angegeben. Er ist das erste Beispiel fur einen zusammengesetzten Schltissel. Dazu spater mehr. Die folgende Abbildung zeigt die grafische Darstellung des Datenmodells.

Business Process Reengineering (Geschaftsprozessoptimierung)

Verbindungsrelation

34

3 Modellierung Relationaler Datenbanken

MITARBEITER

PROJEKTE

#PersonalNr

#ProjektBez

PROJEKTMITARBEIT #(PersonalNr. ProiektBez)

Abbildung 3.3-3:

Relationales Datenmodell PROJEKTMITARBEIT in grafischer Notation.

Vertiefung: Min-/Max-Angaben Auch hier konnen die Beziehungen durch die Angabe der Mindestbeteiligung prazisiert werden: • l,n<-^l,m • 0,n ^-> l,m • 0,n ^ ^ 0,m • l,n
Beziehungen in relationalen Datenmodellen und damit in relationalen Datenbanken konnen nur auf die oben beschriebene Weise erfasst werden, also nur durch Attribute, die von der einen Relation kommen (meist als Schlussel) und bei der anderen eingeftigt werden (meist als Fremdschlussel). Nach der Ubernahme eines Attributs als Fremdschlussel gibt jedes Tupel eine der Beziehungen an. Die folgende Abbildung fasst die moglichen Beziehungen in Relationalen Datenbanken zusammen.

3.4 Relationale Verknupfung - Schlussel und Fremdschlussel

35

Zusammengefasst: Beziehungswertigkeiten

Kardinalitat

Beispiel

1:1 (eins zu eins)

Mitarbeiter •

PCs •

Jedem Mitarbeiter ist genau ein PC zugewiesen, der ihm allein zur Verfugung steht.

1:n (eins zu viele)

Abteilung

Mitarbeiter

In einer Abteilung sind mehrere Mitarbeiter, ein Mitarbeiter gehort zu genau einer Abteilung

n:m (viele zu viele)

Projekte

Mitarbeiter

Zu einem Projekt konnen mehrere Mitarbeiter gehoren, ein Mitarbeiter kann in mehreren Projekten tatig seln.

Abbildung 3.3-4:

3.4

Beziehungen in Relationalen Datenbanken.

Relationale Verknupfung - Schlussel und Fremdschlussel

Jetzt wird es Zeit, den schon mehrfach benutzten Begriff Schlussel etwas naher zu betrachten.

36

Schlussel

Zusammengesetzte Schlussel

Textliche Notation

3 Modellierung Relationalen Datenbanken

Definition 3.4-1: Schlussel Als Schlussel wird ein Attribut bezeichnet, das fur jedes Tupel eine andere Auspragung hat. Ein Schlussel weist somit jedem Objekt^^ oder jeder Beziehung eine andere Auspragung zu. Ein Schlussel kann auch aus einer Kombination von Attributen bestehen. Dann gilt obiges entsprechend. In der Definition wurde schon darauf hingewiesen: Oft kann nicht ein einzelnes Attribut als Schltissel dienen, aber mehrere. In dem hier diskutierten und oben grafisch angegebenen Datenmodell MARKT FUR DATENBANKSYSTEME sind zwei solche Relationen angegeben. In ANGEBOT stellen nur Name DBS und NameHae zusammen eine eindeutige Identifizierung jeder Beziehung (jedes Tupels/jeder Zeile) dar. In DATENTYPEN konnen ebenfalls nur NameDBS und NameDT zusammen als Schltissel dienen. Das Gesamtdatenmodell zeigt, dass in einem solchen Fall bei der grafischen tabellarischen Notation - der Einfachheit der Darstellung wegen - der Schlussel unter die Relation geschrieben wird. In der textlichen Notation werden zusammengesetzte Schlussel wie folgt angegeben: ANGEBOT (#(NameDBS, NameHae), Preis) DATENTYPEN (#(NameDBS, NameDT))

Konkurrierende Schlussel

Von dieser Situation, dass ein Schlussel aus mehreren Attributen besteht, ist zu unterscheiden, wenn eine Relation mehrere, voneinander unabhangige Schlussel hat {konkurrierende Schlussel). Nehmen wir als Beispiel eine Relation zu ONLINE-DATENBANKEN, in der ftir jede OnlineDatenbank eine eindeutige Nummer (Nr), der (naturlich eindeutige) Name (der bis zu 100 Zeichen lang sein kann) und eine ebenfalls eindeutige Kurzbezeichnung (KurzBez) erfasst wird: ONLINE-DATENBANKEN (#Nr, #Name, #KurzBez, Sprache, Umfang, ...)

Primarschltissel

Diese Schltissel existieren dann nebeneinander und erfullen unterschiedliche Aufgaben. Hier dient z.B. #Nr der relationalen Verkniipfung, der #Name der Kennzeichnung bei der Erstellung von Verzeichnissen und #KurzBez der Erfassung der Kurzbezeichnung (und Ausgabe bei Verzeichnissen), die bei den Nutzem von Online-Datenbanken meist besser bekannt ist als die Langbezeichnung. Liegen mehrere solche Schlussel vor, macht es auch Sinn, von Sekunddrschlusseln und Primdrschlusseln zu reden. Einer der Schltissel, meist

'^

Zum Objektbegriff: Hier wird der Einfachheit halber weiterhin davon ausgegangen, dass jedes Tupel (jede Zeile) einer Relation ein Objekt beschreibt und die Relation als Ganzes die Objektklasse. Mehr dazu weiter unten.

3.4 Relationale Verknupfung - Schlussel und Fremdschlussei

37

der fur die interne Verknupfung verwendete, wird zum Primarschltissel, die anderen sind dann die Sekundarschlussel. Der von einigen Autoren verwendete BQgriff Schlusselkandidat ist eine direkte Ubersetzung des amerikanischen Begriffs „candidate key" fur Sekundarschliissel. Insgesamt ergeben sich damit folgende Festlegungen fur die textlichen Notationen von Relationen: Grundform: RELATIONENNAME (#Ai, A2, A3, ... An)^° Beispiel: ANGESTELLTE (#PersonalNr, Name, Vorname, ...) Mit zusammengesetztem Schlussel: RELATIONENNAME (#(A1, A2), A3, A4, ... A n f Beispiel: PROJEKTMITARBEIT(#(PersNr, ProjektName), AntArbzeit) Mit konkurrierenden Schlussein: RELATIONENNAME (#A1, #A2, A3, A4, ... Anf^ Beispiel: ONLINE-DATENBANKEN (#Nr, #Name, #KurzBez, Sprache, Umfang,...) Beg riffe: Schlusselattribut (SA):

Attribut, das Teil eines Schlussels ist

Nichtschlusselattribut (NSA): Attribut, das nicht Teil eines Schlussels ist Primarschltissel:

Ein ausgewahlter Schlussel

Sekundarschlussel:

Die ubrigen Schlussel

Fremdschlussel wurden oben, bei den drei Beziehungstypen, schon angesprochen. Hier soil nun das Konzept des Fremdschlussels am Beispiel des Datenmodells MARKT FUR DATENBANKSYSTEME erlautert werden (vgl.

zum Datenmodell auch Kapitel 2). Hier die oben gefimdenen Objekt- und Beziehungsklassen, die wir - bis auf ANGEBOT - problemlos in Relationen tiberfUhren konnen:

20

Ai usw. sind Attribute. Der Schlussel kann naturlich aus beliebig vielen Attributen bestehen. Es konnen naturlich beliebig viele konkurrierende Schlussel sein,

Fremdschlussel

38

3 Modellierung Relationaler Datenbanken

Datenmodell

MARKT FUR DATENBANKSYSTEME

Objekt- / Beziehungsklassen Attribute DATENBANKSYSTEME Name, Typ, Plattform, LPreis, Pro- 1 duzent PRODUZENTEN Name, Ort, StralSe, Land, WWW NameDBS, NameDt DBS DT HANDLER Name, Ort, Stralie, Tel, Fax, Rabatte, AnsprP ANGEBOT Preis, weitere siehe unten | Beispiel MARKT FUR DATENBANKSYSTEME

Die mm - Beziehung ANGEBOT erfasst, welcher Handler welches Datenbanksystem anbietet. Da ein Handler in der Regel mehrere Systeme anbietet und ein Datenbanksystem von mehreren Handlem angeboten wird, liegt eine solche Kardinalitat vor. In die Relation ANGEBOT werden deshalb die beiden Schlussel aus DATENBANKSYSTEME und HANDLER aufgenommen, z.B. als NameDBS und NameHae. Diese beiden die Beziehung somit etablierenden Attribute werden in ihrer neuen Relation Fremdschlussel genannt: ANGEBOT (#(NameDBS, NameHae^^). Preis) Erfassen wir zusatzlich, welche Datentypen ein Datenbanksystem hat, ergibt sich die Relation DBS_DT: DBS_DT (#(NameDT^^ NameDBS)) NameDT ist nur deshalb nicht Fremdschliissel, well es keine Relation zu den Datentypen gibt. Die l:n - Beziehung zwischen DATENBANKSYSTEME und PRODUZENTEN wird durch Einfligen des Produzentenschliissels in DATENBANKSYSTEME erfasst. Dieses Attribut Produzent wird dadurch wiederum zu einem Fremdschliissel: DATENBANKSYSTEME (#Name, Typ, Plattform, LPreis, Produzent) Bleiben noch die beiden Relationen, die keinen Fremdschlussel erhalten: PRODUZENTEN (#Name, Ort. StrafJe, Land, WWW) HANDLER (#Name, Ort, StrafSe, Tel, Fax, Rabatte, AnsprP) Die folgende Abbildung zeigt das Datenmodell in einer vereinfachten grafischen Notation. Dabei sind die Relationen in Tabellenform angegeben und mit Pseudodaten aufgeftillt. Die Beziehungen sind durch Pfeillinien angedeutet.

Firmenname des Handlers. Name des Datentyps, also z.B. char, float, date, time.

3.4 Relationale Verknupfung - Schlussel und Fremdschlussel

39

PRODUZENTEN 1 #Name Ort StraBe Land WWW P1 P2

1 PS^^J^ DATENBANKSYSTEME 1 #Name Typ Plattform LPreis Produzent | P3 P1 P3 P2 PI

1DBMS1 DBMS2 DBMS3 DBMS4 DBMSS

M

DBS DT [NameDBS NameDT|

/

LDBMSI DBMS1 DBMSS DBMSS DBMSS

"DTI DT2 DT2 DT1 DT3

#(NarneDBS, NameDT)

vANGEBOT ^^ameDBSl NameHae DBMS1 DBMS1 DBMS2 DBMSS DBMSS DBMS4 DBMS4 DBMSS DBMSS DBMSS

HA1 HAS HAS HA2

Preis 5.000,4.000,9.000,1.000,1.S00,2.000,3.S00,4.000,6.000,S.OOO,-

HA1 HA1

HAS HA1 HA2

.HAS

#(NameDBS< NameHae^

HANDL ER |#Name Ort StraSe Tel Fax Rabatte AnsprP HA1

mA2 IHAS m4

Abbildung 3.4-1:

Relationales Datenmodell M A R K T FUR DATENBANKSYSTEME (vereinfacht) in Tabellendarstellung.

40

Beispiel Vorlesungsbetrieb

3 Modellierung Relationaler Datenbanken

Das Beispiel macht die auBerordentHche Bedeutung der Fremdschltissel und der Schltissel / Fremdschltisselbeziehungen deutlich. Auf ihnen beruhen die Verkntipflingen der Relationen, weshalb sie hier auch relationale Verknilpfung genannt werden. Ein Weltausschnitt, in dem sich leicht viele Fremdschltissel fmden lassen, ist der zum VORLESUNGSBETRIEB einer Hochschule. Hier fmdet sich sicher eine Relation, die Veranstaltungen beschreibt. Wir setzen den Begriff Veranstaltung als Oberbegriff fiir Vorlesungen, Ubungen, Praktika, usw. Es gilt folgende Semantik: •

• • • • • •

Eine Veranstaltung wird nach Vorgabe des Studienplanes fiir ein bestimmtes Semester und fiir einen bestimmten Studiengang geplant. Z.B. fiir einen Studiengang Wirtschaftsinformatik im 5. Semester (WI5) Eine Veranstaltung wird durch einen bestimmten Dozenten^^ gehalten. Dieser halt in der Regel mehrere Veranstaltungen. Eine Veranstaltung fmdet in einem bestimmten Raum statt. Studierende konnen mehr als eine Veranstaltung besuchen. Eine Veranstaltung wird in einem Semester nur von einem Dozenten gegeben. Eine Veranstaltung wird in unterschiedlichen Semestern u.U. von verschiedenen Dozenten gehalten. Dieselbe Veranstaltung kann in verschiedenen Semestern von verschiedenen Dozenten gehalten werden.

Wie sieht nun eine Relation aus, mit der die Abwicklung der durch den Studienplan vorgegebenen Vorlesungen in den einzelnen Semestern erfasst wird (der konkreten wochentlichen Veranstaltungen). Erfasst werden mtissten folgende Attribute: • • • • • •

Bezeichnung der Veranstaltung (VThema), z.B. Datenbanksysteme Studiengang, fiir den die Veranstaltung geplant wird (Studiengang), z.B. WI Semester, in dem die Veranstaltung in der Studien- und Prufungsordnung geplant ist (Semester), z.B. 5 Semester, in dem die Veranstaltung von einem bestimmten Dozenten gehalten wird (Zeitpunkt), z.B. SS2005 oder WS2005/06 Identifikation des Dozenten (DozNr) Raum, in dem die Veranstaltung stattfmdet (Raum), z.B. K002

Damit ergibt sich folgende Relation: VORLESUNGEN (VThema, Studiengang, Zeitpunkt, DozNr, Semester, Raum)

Wir verzichten an dieser Stelle auf die Variante, dass auch mehrere Dozenten zusammen eine Veranstaltung durchfuhren.

3.4 Relationale Verknupfung - Schlussel und Fremdschlussel

41

Was ist der Schlussel dieser Relation? Wie unschwer zu erkennen ist, reichen dafur DozNr und VThema nicht aus, da ein Dozent dieselbe Veranstaltung in verschiedenen Semestem halten kann. Es muss also noch das Attribut Zeitpunkt dazu genommen werden. DozNr und Zeitpunkt alleine reichen nicht, da ein Dozent in einem Semester mehrere Veranstaltungen gibt. VERANSTALTUNGEN (#(DozNr, VThema, Zeitpunkt), Studiengang, Semester, Raum) Die folgende Relation zeigt einige Beispielsdaten fiir die SchlUsselattribute. Es soil an dieser Stelle nicht verschwiegen werden, dass statt eines solchen zusammengesetzten Schltissels auch ein kunstlich generierter, z.B. VorlesungsNr, verwendet werden kann, mit dem einfach alle solchen Veranstaltungen durchnummeriert werden. VERANSTALTUNGEN (nur Schlusselattribute) 1 DozNr VThema EinfGhrung in die Wl 008 Einfuhrung in die Wl 007 EinfQIirung in dieWI 008 Gesciiaftsprozesse 008 008 Geschaftsprozesse 001 E-Business - Anwendungen Datenbanl<systenne 007 001 Iteratives Prozessprototyping

Zeitpunkt WS2005/06 SS05 SS06 SS05 SS06 WS2005/06 SS05 WS2005/06

1

1

In der Relation Veranstaltungen fmden sich nun drei FremdschlUssel,^^//^ die entsprechenden Relationen zu S T U D I E N G A N G E N , D O Z E N T E N und VERANSTALTUNGEN vorliegen. Damit ergabe sich: VERANSTALTUNGEN (#(DozNr, VThema. Zeitpunkt), Studiengang. Semester, Raum) DOZENTEN (#DozNr, Sprechstunde, ...) STUDIENGANGE

(#Name, Anzahl, ...)

VERANSTALTUNGEN (#VThema, Veranstaltungstyp, Leistung, ...) AbschlieBend noch eine Definition ftir FremdschlUssel:

3 Modellierung Relationaler Datenbanken

42

Definition 3.4-2: Fremdschliissel Gegeben seien zwei Relationen Ri und R2. Ein Fremdschlussel in Ri ist ein Attribut, das nicht Schlussel ist^^, denselben Wertebereich hat wie ein Schltissel in einer anderen Relation R2 und das mit Hilfe des Schlussels von R2 der relationalen Verknupfung von Ri und R2 dient. Exkurs: Zweck der Datenbank Wie oben schon angemerkt, wird ein Datenmodell neben den schon erwahnten Mitteln und Regeln des jeweiligen datenbanktheoretischen Ansatzes durch einen weiteren Faktor wesenthch gepragt: dem Zweck der Datenbank, d.h. durch die Geschaftsprozesse, die mit den Daten reahsiert werden sollen. Nehmen wir das Beispiel MARKT FUR DATE N BAN KSYSTEME. Liegt hier der Schwerpunkt eher auf den kommerziellen Aspekten ergibt sich ein anderes Datenmodell (mit mehr Angaben zu Preisen, Rabatten, Verfugbarkeit, usw.), als wenn der Schwerpunkt auf technischen Aspekten liegt. Im letzteren Fall wtirden die zur Verfugung stehende Datentypen genauer beschrieben, mehr auf Kompatibilitat, Performance-Kennziffern, Leistungsfahigkeit der Masken- und ReportGeneratoren, usw. eingegangen.

3.5

Verkniipfling vertieft

Verknupfen von Relationen - konkret

Es wurde oben schon deutlich: Relationen stehen nicht isoliert im Datenmodell, sondem sind miteinander verknupfl. Dies ist sogar ein grundsatzliches Wesensmerkmal relationaler Datenmodelle: alle Relationen eines relationalen Datenmodells mtissen untereinander in Beziehung stehen^^, wobei mit Beziehung die oben eingefuhrte Verknupfung durch Attribute gemeint ist. Was bedeuten nun solche Verkntipfungen konkret? Die folgende Abbildung soil hierauf ein Antwort geben. Im oberen Teil sind die beiden Relationen PRODUZENTEN und DATEN BAN KSYSTEME angegeben. Die Verkniipfixng geschieht hier tiber das Attribut

DATENBANKSYSTEME.Produzent auf der einen und PRODUZENTEN.Name auf der anderen Seite (groBgeschrieben: Relationenname). Die Verkntipfung hat hier als sog. 1 :n-Verknupfung, die Aufgabe, jedem Datenbanksystem das Tupel des zugehorigen Produzenten zuzuordnen.

Fine wichtige Ausnahme, bei 1:1-Beziehungen, wird unten diskutiert. Fine Ausnahme von dieser Kegel ergibt sich manchmal und zwar dann, wenn man Tabellen zum "Nachschlagen" mit in das Datenmodell integriert. Z.B. mit Kalenderdaten, wenn es um ein Datenmodell geht, bei dem Kalenderdaten eine groBe Rolle spielen. Fine solche "Nachschlagetabelle" ist aber nicht auf die iibliche "relationale" Weise mit den ubrigen Relationen des Datenmodells verknupfl (wie es in diesem Abschnitt erlautert wird), hat aber trotzdem Bedeutung fur das Datenmodell.

3.5 Verknupfen von Relationen - i
43

1. Die Ausgangssituation PRODUZENTEN Die Relation P R O D U Z E N T E N erfaBt Informationen zu den Produzenten der Datenbanksysteme. Hier wird angenommen, daB ein Produzent u.U. mehrere Datenbanksysteme hersteilt, daS ein System aber immer von einem Produzenten stammt.

Ort

#Name

StraSe

Land

P1

Ort1

Str1

D

P2

Ort2

Str2

USA

P3

Ort1

Str3

D

DATENBANKSYSTEME

r^

Typ

Plattform

Produzent

DBMS1 RDBMS

PC's

P3

DBMS2 RDBMS

Apple

P1

DBMS3 O O D B S

UNIX

P3 A/H

DBMS4 IRS

UNIX

P2

DBMS5 O O D B S

PC's

P1

#Name

Die Relation DATENBANKSYSTEME beschreibt (in einfacher Form) die entsprechenden Softwareprodukte. Das Attribut Produzent ist hier Femdschlussel, weil mit ihm die Verknijpfung mit der Relation PRODUZENTEN erfolgt.

J

Darstellung der Verknupfung auf Tupel-Ebene DATENBANKSYSTEME #Name

Typ

PRODUZENTEN

Plattform Produzent

DBMS1 RDBMS

PC's

DBMS2 RDBMS

Apple

P1^<

DBMS3 OODBS

UNIX

P3^k,^^^^

DBMS4 IRS

UNIX

DBMS5 O O D B S

PC's

#Name

Ort

StraUe

t P1 ^ P2 >^P3

Ort1 Ort2 Ort1

Str1 Str2 Str3

P3^^

1 Zf

PU

>-o ^

Land D USA D

/

3. Die neue Relation nach vollzogener Verknupfung DBMS PROD #Name

Typ

Plattform

DBMS1 RDBMS PC's DBMS2 RDBMS Apple DBMS3 OODBS UNIX DBMS4 IRS

UNIX

DBMS5 OODBS PC's

Produzent

P3 P1 P3 P2 P1

Ort

StraRe

Land

D 4] D 4

Ort1

Str3

Ort1 Ort1

Str1 Str3

Ort2

Str2

D ^ USA

Ort1

Str1

D ••I

Doppeleintrage (Redundanz)

Es entsteht eine i.d. Regel temporare Relation (die nun doppelt vorhandene Produzentenangabe wird einmal unterdruckt), Diese Relation weist Redundanzen auf: Ort, StraBe und Land eines Produzenten sind hier nicht nur einmal, sondern fiir jedes Datenbanksystem des Produzenten angegeben. Hier in diesem Beispiel ist dies sicher nicht sehr gewichtig, man stelle sich aber mehrere Hunderttausend Datensatze vor und Wiederholungsraten von mehreren Hundert. Solche Redundanzen sind naturlich bei den Relationen eines Datenmodells unerwiinscht und werden im Rahmen der Optimierung des Datenmodells (Normalisierung) beseitigt.

Abbildung 3.5-1:

Relationale Verkntipfungen - konkret

44

Tupelebene

temporare Verschmelzung

Der zweite Teil der Abbildung zeigt die daraus folgende Verknupfung auf Tupelebene. Die Pfeile deuten jetzt an, dass ein Tupel der Relation PRODUZENTEN mit mehreren Tupeln der Relation DATENBANKSYSTEME verbunden sein kann, entsprechend der 1 :n-Verknupfung. Der dritte Teil zeigt eine eventuelle konkrete Verknupfung der beiden Relationen auf der Basis von DATENBANKSYSTEME.Produzent und PRODUZENTEN.Name. Dabei werden die Tupel aneinandergehangt, die in den beiden Attributen dieselbe Auspragung haben. Eine solche Relation kann tatsachlich entstehen, z.B. durch einen entsprechenden SQL-Befehl. Sie wird aber i.d.R. nur voriibergehend gebraucht, weil hier ja zwei Objektklassen zusammengebracht werden. Dies fuhrt zu Redundanzen, wie ja auch schon das einfache Beispiel zeigt und diese sind im relationalen Ansatz unerwunscht (dazu unten mehr).

3.6

Objektintegritat

Referentielle Integritat

Integritaten

Dies ist nun die Stelle, um zwei grundsatzliche Forderungen an Relationen bzw. Datenmodelle anzufuhren: Objektintegritat und referentielle Integritat. Objektintegritat wird die Forderung genannt, dass kein Tupel mit unvollstandigem Schliissel in eine Relation eingetragen werden darf D.h., es kommt natiirlich vor, dass unvollstandige Tupel in eine Relation eingetragen werden, z.B. weil eine Information noch fehlt, aber der Schliissel muss vollstandig vorhanden sein. Die Forderung der referentiellen Integritat bezieht sich auf die Verknupfung von Relationen durch Schlussel und Fremdschlussel. Sie besagt, dass in den jeweiligen Fremdschliissel eine Auspragung nur eingetragen werden darf, wenn sie als Auspragung des SchlUssels in der anderen Relation vorhanden ist. Damit soil verhindert werden, dass Fremdschliisseleintrage erfolgen, die nicht verknupfl werden konnen. Betrachten wir als Beispiel wieder die beiden Relationen DATENBANKSYSTEME (mit dem Fremdschlussel Produzent) und PRODUZENTEN (mit dem Schlussel Name). Die Forderung der referentiellen Integritat verbietet es, einen Produzenten in DATENBANKSYSTEME.Produzent einzutragen, der nicht in PRODUZENTEN.Name bereits eingetragen wurde.

3.7

BLOBs etc.

3 Modellierung Relationaler Datenbanken

Nicht-Attribute

Der in diesem Abschnitt beschriebene relationale Ansatz ist ganz und gar auf Attribute zugeschnitten. Inzwischen sind aber vollig andere Informationsarten in Datenbanksystemen heimisch geworden, v. a. Texte in der einen oder anderen Form und die sog. Binary Large Objects (BLOBs). Mit diesen konnen alle Informationen abgespeichert werden, die binar verkodet werden konnen. also z.B. Grafiken, Photographien, Sprache, Musik, Video-Sequenzen, usw. Diese nicht-konventionellen Datentypen

3.8 Warum eigentlich flache Tabellen?

45

sind im originaren relationalen Ansatz nicht vorgesehen (es gab sie damals, als der Ansatz begrundet wurde, auch noch nicht), konnen aber ohne Schwierigkeit integriert werden. Nehmen wir z.B. texthche Information, die ja inzwischen in den meisten Datenbanksystemen zur tieferen Beschreibung der Objekte und Beziehungen verwendet wird. Nehmen wir weiter an, wir wollen - bezogen auf das diskutierte Datenmodell zum "Markt fur Datenbanksysteme" - die Datenbanksysteme auch textlich beschreiben, z.B. in einem Anmerkungsfeld^^. Dann wird natiirlich dieses Textfeld an die Relation DATENBANKSYSTEME angefiigt, denn da gehort es hin. Allgemein gesagt gilt, dass die Nicht-Attribute einfach an die Relation angefugt werden, deren Objekte sie beschreiben. In den weiteren Optimierungsschritten (Normalisierung) werden sie dann einfach entsprechend mitgefiihrt.

3.8

Warum eigentlich flache Tabellen?

Warum stehen solche flachen Tabellen im Mittelpunkt eines datenbanktheoretischen Ansatzes? Wieso lasst man nicht Mehrfacheintrage zu^^, die sich ja standig ergeben (vgl. unten). Die Grtinde sind i.w. folgende: •

• • •

•

Mit den beschriebenen flachen Tabellen ist eine umfassende Modellierung moglich, d.h. die im konventionellen Bereich^^ vorkommenden Datenstrukturen konnen dadurch reprasentiert werden. Flache Tabellen konnen weitgehend redundanzfrei organisiert werden. Eine Modellierung mit flachen Tabellen ist insgesamt Ubersichtlich. Flache Tabellen konnen ohne Schwierigkeit verkniipft werden, um entsprechende Datenstrukturen abzubilden (z.B. solche, die sich als 1 :n - Oder n:m - Beziehungen auBem). Flache Tabellen konnen problemlos als Dateien gefiihrt und dann leicht abgefragt und verwaltet werden.

Das folgende Beispiel der Relationen PERS__UN (Tabelle zu Personen mit Mehrfacheintragen^^ und PERS_1NF (Relation zu Personen als flache Tabelle^^) moge dies veranschaulichen. In beiden wird fur irgendEine Erganzung der Beschreibung bzw. Modellierung ist aucli bei fast alien Datenbanken notig, da sich i.d.R. nur ein Teil der zu erfassenden Information in die Form von Attributen pressen laCt. Es gibt in der Tat Datenbanksysteme, die ausdrucklich solche nicht-flachen Strukturen zulassen, dominierend sind aber derzeit Relationale Datenbanksysteme. Mit „konventioneH" ist hier v.a. der kaufmannische Bereich gemeint. Zusatzlich aber auch alle anderen, deren Informationen sich durch Attribute erfassen lassen. Nichtkonventionell in diesem Sinn sind z.B. die Datenbanken der Chemie, Physik, der Technik (teilweise), usw. Hier liegen neben den Attributen ganz andere Informationsarten vor (Strukturformeln, Spektren, technische Zeichnungen, usw.). Wer hier mehr wissen mochte, moge sich die Datenbanken der groBen Anbieter von Online-Datenbanken anschauen. lJN=in unnormalisierter Form. Eine solche Relation wird als Relation in erster Normalform (INF) bezeichnet (vgl. unten), was einfach bedeutet, dass sie flach ist.

46

3 Modellierung Relationaler Datenbanken

welche Personen festgehalten, welche Programmiersprachen sie beherrschen (PS) und wieviel Jahre Erfahrung sie damit haben (ERFAHRUNG). PERS UN |#PersNr 123 |456

Flach durch Tupelvermehrung

rps

Erfahrung 1,4,2,3 2,10,5

C, COBOL, Fortran, Prolog C++, Smalltalk, C

1 1

PERS__UN enthalt als Auspragungen des Attributs PS eine Liste der Programmiersprachen, die von der jeweiligen Person beherrscht werden. Das Attribut Erfahrung gibt die Zahl der Jahre an, die mit der Sprache gearbeitet wurden. Die Beziehung zwischen den Attributsauspragungen von PS und Erfahrung wird nur durch die Position in der Liste festgehalten. Die nachfolgende Tabelle zeigt dieselben Daten als flache Tabelle. Dabei wurde einfach fur jeden der Mehrfacheintrage ein eigenes Tupel angelegt. Diese Methode wird Tupelvermehrung genannt. PERS 1NF 1 PersNr PS 123 C COBOL 123 Fortran 123 Prolog 123 456 C++ Smalltalk 456 456 C #(PersNr, PS)

Erfahrung 1 4 2 3 2 10 5

1

Auch wenn diese Relation auf den ersten Blick redundant anmutet, ist sie es im relationalen Sinn nicht und stellt eine effiziente und „wartungsfreundliche" Informationsstmktur dar. Wenn die INF so wie hier erreicht ist, •

•

•

... kann jedes Feld leichter abgefragt werden. In PERS_UN kann die Suche nach alien, die Fortran beherrschen, nicht einfach durch Abgleich erfolgen, sondem durch das Absuchen der Zeichenkette nach dem Auftreten der Zeichenfolge "Fortran". ... kann jedes Feld flir die Verknupfung mit anderen Relationen genutzt werden. Hier z.B. zu einer Relation, die zu den jeweiligen Programmiersprachen nahere Angaben enthalt. ... ist die Beschreibung der Objekte eindeutig, denn sonst kann bereits bei zwei Feldem mit Mehrfacheintragen die Eindeutigkeit verloren gehen. Beispiel: In der Tabelle PERS_UN ist die Zuordnung zwischen Programmiersprache und Programmiererfahrung sicherlich schwerer korrekt zu halten, als in der Relation PERS__1 NF.

3.9 Zusammenfassung - erste Schritte

• •

47

... ist ohne Schwierigkeit in die heute gangigen Dateitypen abzubilden (z.B. als indexsequentielle Datei). ... ist leichter zu korrigieren, wenn z.B. die Schreibweise einer Auspragung an alien Stellen geandert werden soil. In PERS_UN erfordert dies lange Suchprozesse und nicht ganz einfache Anderungen, in PERS_1NF konnte durch einen Befehl in alien Datensatzen z.B. "Fortran" durch "Fortran 2000" ersetzt werden.

Die Bedeutung der flachen Tabelle ist also sehr groB und kann so zusammengefasst werden:

Die Gmndlagen

Relationale Datenbanken bauen in all ihren Aspekten (Datenstruktur, Datenabfrage, Datenverwaltung, usw.) voll auf flachen Tabellen mit den beschriebenen Eigenschaften auf (Relationen). Diese sind daher beim Entwurf des Datenmodells zu realisieren. Ausnahmen stellen Felder dar, die ausdrlicklich nur zur Ausgabe dienen, die also weder Schliisselattribut sind, noch Determinante (vgl. unten), noch in Abfragen fur die Festlegung der auszugebenen Menge dienen, noch die Verknupfung mit anderen Relationen leisten.

3-9

Zusammenfassung - erste Schritte

Die bisherigen Ausfuhrungen zum Entwurf eines relationalen Datenmodells lassen sich wie folgt zusammenfassen: •

Im ersten Schritt wird die Komplexitat des betrachteten Weltausschnitts dadurch reduziert, dass bedeutsame^^ Objekte und Beziehungen identifiziert/festgelegt werden. • Dann werden bedeutsame^"^ Attribute von Objekten und Beziehungen erfasst. Die Reihenfolge der ersten beiden Schritte ist unterschiedlich. Manchmal werden zuerst die Informationstrager (Objekte und Beziehungen) und dann die beschreibende Information (Attribute) entdeckt, manchmal umgekehrt. • Im dritten Schritt werden die Objekte bzw. Beziehungen zusammengefasst, die durch dieselben Attribute beschrieben werden. Die sich dabei ergebenden Mengen werden Klassen genannt, Objektklassen bzw. Beziehungsklassen. • Im nachsten Schritt wird fur Objekt- bzw. Beziehungsklassen je eine Relation angelegt. Treten dabei Mehrfacheintrage auf, werden diese mit den nachfolgend beschriebenen Techniken beseitigt. Eine der da-

Von Bedeutung fiir die Anwendung, fiir die Gesciiaftsprozesse die dort eine Rolle spielen. Wie oben ja angemerkt, hat eine Datenbank sozusagen eine „dienende Funktion" bzgl. der Geschaftsprozesse des Anwendungsbereichs. Auch bei den Attributen gilt, dass nur solche genommen werden, die „Bedeutung" im Sinn der vorigen FuBnote haben.

Erste Schritte

48

3 Modellierung Relationaler Datenbanken

bei verwendeten Methoden, die Tupelvermehrung, wurde oben schon kurz vorgestellt. Die so entstehenden Relationen sind relational verkniipft. Ergab sich die VerknUpfiing nicht direkt aus dem Designprozess, muss sie jetzt erganzt werden. Dabei gilt, wie oben schon angefUhrt: Fiir l:n - Beziehungen wird normalerweise eine Schlussel- / Fremdschliisselbeziehung etabliert, fur n:m - Beziehungen eine eigene Relation (Verbindungsrelation).

3.10 Optimierung durch Normalisierung Der so entstandene Entwurf muss nun lediglich noch optimiert werden. Optimierung bedeutet hier verschiedenes, z.B. auch die Beseitigung eventueller Mehrfacheintrage, v.a. aber die Beseitigung von Redundanz in den Daten einer Relation. Redundanz

Oberste Kegel flir Datenbanken

Redundanz bedeutet an dieser Stelle, dass ein und dieselbe Information in einer Relation mehrfach erfasst wird. Z.B. die Tatsache, dass Person X die Programmiersprache C++ beherrscht. In den folgenden Abschnitten sind viele Beispiele flir Redundanzen in Relationen angefuhrt. Letztendlich ist eine Regel fiir die im folgenden dargestellten Bemuhungen verantwortlich, die wegen ihrer Bedeutung getrost zur obersten Regel des Datenbankentwurfs emannt werden kann:

Jede Information darf in einer Datenbanknureinmalvorkommen. Information im „Attributsinne". Also z.B. die Information, dass Lisa Widmer in der Abteilung Controlling arbeitet, dass Heiner Milller Abteilungsleiter der Abteilung Personalwesen ist, dass Angelika Widmer die Programmiersprache C++ beherrscht, usw. Als Werkzeug fiir diese Optimierung stellt die relational Datenbanktheorie die Normalformen zur Verfiigung. Insgesamt gibt es sechs, die • • • • • • Aufbauend

Erste Normalform (INF), Zweite Normalform (2NF) Dritte Normalform (3NF) Boyce-Codd - Normalform (BCNF) Vierte Normalform (4NF) und die Funfte Normalform (5NF).

Die einzelnen Normalformen bauen aufeinander auf Ist die n-te erfiillt, sind auch alle „darunterliegenden" erfuUt. Jede Normalform hat das Ziel, das Datenmodell - aufbauend auf der vorangehenden - weiter zu „opti435 mieren Was dies jeweils im einzelnen bedeutet, wird bei den Normalisierungsschritten betrachtet.

3.11 Die erste Normalform (INF)

49

Die Normalformen kommen zum Zug, wenn die Objekt- und Beziehungsklassen des ersten Entwurfs in Relationen „gegossen" wurden. 0ftmals endet dieser erste Entwurf auch in einer einzigen groBen Universalrelation, in die alle gewiinschten Attribute geschrieben wurden. Auf die Relationen dieses ersten Datenmodells werden dann die Normalformen angewandt.

Universalrelation

3.11 Die erste Normalform (INF) Oben wurde bereits beschrieben, dass Relationen in INF ganz einfach flache Tabellen mit den angefuhrten Eigenschaften sind. Solange sie diese Eigenschaften nicht voll erfullen werden sie, sprachlich nicht ganz korrekt, als unnormalisierte Relationen bezeichnet. Wenn hier ausschlieBlich von einzelnen Relationen ausgegangen wird, bedeutet dies nicht, dass dies immer so ist. Im realen Datenbankentwurf hat man meist mehrere Relationen, die man im Zusammenhang und koordiniert normalisiert. „Unnormalisierte Relationen" kommen sehr oft vor, teilweise schon beim ersten Anlegen einer Relation, vor allem aber bei der Weiterentwicklung im Rahmen der Normalisierung. Ein Beispiel wurde oben schon angegeben, die Relationen PERS__UN, die dann in die INF gebracht wurde (PERS_1 NF). Wie kommt man nun zu den flachen Tabellen? Eine erste Losung wurde oben bereits gezeigt, beim Weg von der PERS_UN zur PERS_1NF. Dabei werden die Mehrfacheintrage so aufgelost, dass fiir jeden Eintrag ein eigenes Tupel angelegt wird. So entstanden in PERS_1NF fiir die Person mit der Personalnummer 123 insgesamt vier Tupel, ftir jede Programmiersprache eines. Diese Losung erscheint naheliegend, man stelle sich aber vor, es wtirden zahlreiche weitere Attribute in der Relation noch ft)lgen. Dann wtirde diese Losung eine gewaltige Vervielfachung von Inft)rmationen bedeuten. Auf der anderen Seite erlaubt diese Losung problemlos die spatere Abfi-age der Daten. Sie passt insofern hervorragend in den relationalen Ansatz. Die Relation PROD__UN erfasst Hersteller von Datenbanksystemen, mit den Systemen und Adressangaben.

Wege zur INF: Losung 1: Tupelvermehrung

Ein zweites Beispiel

50

3 Modellierung Relationaler Datenbanken

PROD UN 36 1 #NameProd 1 Microsoft Borland CA Oracle

NameDBS FoxPro, ACCESS Visual dBase, Paradox INGRES Oracle

Ort AAA BBB CCC DDD

StrafSe

Land

1

Die Tupelvermehrung fuhrt zu folgender Losung: PROD 1NF 1 NameProd Microsoft Microsoft Borland Borland CA Oracle

1NameDBS FoxPro ACCESS Visual dBase Paradox INGRES Oracle

^Ort AAA AAA BBB BBB CCC XXX

StrafSe

Land

1

Schlussel: #NameDBS Hier wird die Erhohung der Redundanz offensichtlich. Die Adressangaben werden fur jedes Datenbanksystem wiederholt. Das AusmaB der Redundanz wird noch deutlicher, wenn man sich vorstellt, die Adressangaben wiirden aus den tiblichen 10 bis 20 Attributen bestehen. Trotzdem ist obiger Losungsweg fiir die Herbeifuhrung der INF sinnvoU, da die dabei evtl entstehende Redundanz schon beim nachsten Optimierungsschritt, der Realisierung der 2NF, beseitigt wird.

Losung 2: Zerlegung entlang einer 1 :n - Beziehung

Vertiefung: Der schnelle Weg zum Erfolg Ftihrt man das obige Verfahren durch, entstehen erstmals Redundanzen, die dann im folgenden beseitigt werden. Will man dies nicht, muss man eines der Verfahren wahlen, die in dieser Vertiefung angegeben werden. Diese erfordern allerdings ein vertieftes Verstandnis. Die zweite Losungsvariante besteht darin, die Ausgangsrelation zu zerlegen in zwei miteinander verknupfte Relationen. Diese Losung ist aber nur dann die richtige, wenn die Mehrfacheintrage eine 1 :n - Beziehung ausdrucken. Betrachten wir dazu nochmals die Relation PROD_UN. Wir legen die Semantik so fest^^, dass wir annehmen, ein Datenbanksystem wird auch nur von einem Produzenten hergesteUt (fur die Zwecke unserer Datenbank). Dann handelt es sich

NameProd = Name des Herstellers eines Datenbanksystems. NameDBS = Name des Datenbanksystems. Ort, Strafie, Land = Adressangaben zum Produzenten. Das „Festlegen der Semantik" ist ein durchaus notwendiges Verfahren beim Datenbankdesign. Es ist nattirlich nur moglich, wenn die Festlegung nicht die Erfullung des Zwecks der Datenbank behindert.

3.11 Die erste Normalform (INF)

51

um eine eindeutige 1 :n - Beziehung zwischen Produzenten und Datenbanksystemen^^ Die Zerlegung fiihrt zu folgenden Relationen:

PRODUZENT 1 #NameProd 1 Microsoft Borland CA

DBS_PROD |#NameDBS [FoxPro ACCESS Visual dBase Paradox INGRES

Ort

StralJe

Land

1

NameProd 1 Microsoft 1 Microsoft Borland Borland CA

Fremdschlussel: INameProd Die Regel ist einfach: Das Attribut mit Mehrfacheintragen wird zusammen mit dem Schlussel der alten Relation zum Schliissel einer neuen, hier DBS__PROD. Der Schliissel der Ausgangsrelation wird in die neue Relation als Fremdschlussel aufgenommen. Mit ihm konnen die beiden Relationen bei Bedarf wieder verkniipft werden. Diese Moglichkeit, auch nach einem durch die Normalisierung erzwungenen Zerlegungsschritt die „alten" Attribute wieder zusammenzufugen, ist von groBer Bedeutung. Sie stellt eine der Grundregeln der Normalisierung dar: Die Zerlegungen im Rahmen der Normalisierung durfen zu keinem Informationsverlust fuhren. Der Grund ist einfach: In der unnormalisierten Relation wurden die Attribute ja nicht willktirlich zusammengestellt, sondern weil sie „irgendwie"^^ zusammengehoren. Dieser Zusammenhang kann bei Auswertungen oder Abfragen wieder Bedeutung gewinnen. Doch zuruck zu den beiden Relationen. Sie machen deutlich, dass die Ursprungsrelation zwei verschiedene Aspekte der Realwelt erfasst hat: zum einen die Beschreibung der Produzenten, zum anderen die Beziehung „wer produziert welches System?". Eine solche Vermengung zweier Aspekte in einer Relation fuhrt immer zu Schwierigkeiten. Die Zerlegung in die zwei Relationen fiihrt zu einer sauberen Trennung. Wem das obige Beispiel zu wenig aussagekraftig ist, der moge sich eine Erganzung der nun entstehenden Relationen vorstellen. Die eine beschreibt ja die Pro-

^^ Denn dann steht ein Datenbanksystem mit einem Produzenten und ein Produzent mit mehreren Datenbanksystemen in der genannten Beziehung. ^'^ Dies wird weiter unten naher betrachtet.

„Vermengung" schafft Redundanz

3 Modellierung Relationaler Datenbanken

52

duzenten, die andere die Datenbanksysteme. Beides konnte im Rahmen der Modellierung leicht erganzt werden, z.B. so:

Losung 3: Zerlegung entlang einer n:m - Beziehung

PRODUZENT (#NameProd, Ort, Strafle, Postfach, Land, Telefon, Telefax) DBS (# NameDBS, TypDBS, PlattformDBS, NameProd) Oftmals gehen Mehrfacheintrage auch darauf zurtick, dass in den Daten eine n:m Beziehung verborgen ist. Dann muss eine Zerlegung in drei Relationen erfolgen. Betrachten wir als Beispiel eine leicht veranderte Version der Relation PERS_UN. Nehmen wir an, dass wir beim Attribut P S nicht einen spezifischen Compiler, sondern nur den Namen der Programmiersprache erfassen. Dann handelt es sich um eine n:m - Beziehung zwischen Angestellten und Programmiersprachen: eine Person kann mehrere Programmiersprachen beherrschen und eine Programmiersprache wird u.U. von mehreren Personen beherrscht.

PERS_UN 1 #PersNr Name PS Stellenwert 1 Maier C, COBOL, Fortran, Prolog 1,4,2,3 123 Muller C, C++ 456 1,10 Stellenwert beschreibt die Bedeutung, den die Programmiersprache flir das Unternehmen hat. Zu erkennen ist das Vorliegen einer n:m - Beziehung in den Mehrfacheintragen entweder aus der Semantik des Weltausschnitts heraus, wenn es sich in Wirklichkeit um zwei Objektklassen A und B handelt, die zusammen in einer Relation beschrieben werden, oder durch die einfache Analyse der Daten. Hier machen z.B. die drei folgenden Beziehungen bereits den n:m-Charakter deutlich: Maier Muller Miiller

-

C C C++

In einem solchen Fall wird in drei Relationen zerlegt: eine flir die eine Objektklasse, eine fur die andere und eine fur die Beziehung zwischen ihnen. Die Relationen, die die Objektklassen reprasentieren, erhalten als Schliissel jeweils eines der Attribute mit Mehrfacheintragen und alle Attribute, die dieselbe Objektklasse beschreiben. Die Relation fiir die Beziehungsklasse, die Verbindungsrelation, enthalt die beiden Schliissel, die in ihr zusammen Schliissel und allein Fremdschliissel sind. Im obigen Beispiel entstehen dann folgende Relationen. PERS beschreibt die Objektklasse der Personen, PS die der Programmiersprachen und KOMPETENZ ist die Verbindungsrelation die festhalt, welche Person welche Programmiersprache beherrscht. PERS

1 #PersNr 123 456

Name Maier Muller

1 1

3.11 Dieerste Normalform (1NF)

53

PS |#PS

Stellenwert 1 1 c COBOL 4 Fortran 2 Prolog 3 10 C++

KOMPET ENZ 1 PersNr PS 123 c COBOL 123 Fortran 123 Prolog 123 C 456 C++ 456

1

#(PersNr, PS) Im realen Datenbankentwurf ist es meist so, dass sich die m:n - Beziehung bereits bei der ersten Beschreibung des Weltausschnittes herausstellt und dann gleich entsprechend berucksichtigt werden kann. Der Vorteil der Zerlegung einer n:m - Beziehung in mehrere Relationen ist fundamental. Erst dadurch werden die Informationen zugangig und konnen fur Abfragen und Verkniipfungen sinnvoU genutzt werden. Der einzige Nachteil ist unumganglich und liegt in der Zerlegung selbst, da bei Abfragen mit mehreren Relationen gearbeitet werden muss. Ein oft genutzter Losungsweg fur die Beseitigung von Mehrfacheintragen besteht darin, aus dem Attribut mit Mehrfacheintragen mehrere Attribute zu machen und zwar so, dass jedes der neu entstandenen Attribute „flach" ist. Dabei hangt die Zahl der entstehenden Attribute von der maximalen Zahl von Auspragungen ab, die sich bei den Mehrfacheintragen finden. Betrachten wir folgende Variante der Relation PERS_UN. PERS_UN |#PersNr 123 234 345 456 1567

PS C, COBOL, Fortran, Prolog Fortran, C Prolog " C++, Smalltalk

Name 1 Muller Maier Schweizer Fricksen ^avensburger |

Die maximale Zahl von Mehrfacheintragen ist vier. Die auf diese Weise in die INF gebrachte Relation sieht dann so aus:

Losung 4: Attributvermehruna

54

3 Modellierung Relationaler Datenbanken

PERS 1NF 1 PersNr 123 234 345 456 567

PS-1 C Fortran Prolog C++

PS-2 COBOL C Smalltalk

PS-3 Fortran -

PS-4 Prolog -

Name 1 Muller Maier Schweizer Fricksen Ravensburger |

Es ist wohl sofort ersichtlich, dass diese Losung zwar zu einer flachen Tabelle fuhrt, in der Praxis aber kaum bestehen kann. Einige der Nachteile: •

• •

Die Abfrage der Programmiersprachen wird komplizierter (man stelle sich eine Abfrage des Typs „Wer beherrscht Fortran?" vor, von komplizierteren Abfragen ganz zu schweigen). Relational Verknupfringen liber ein solches Feld sind praktisch unmoglich. Da die Zahl der Mehrfacheintrage in der Regel stark schwankt, entstehen viele Felder mit Leereintragen.

Diese Losung ist nicht mit dem relationalen Ansatz vereinbar. Dasselbe gilt flir die Losung, die in der folgenden Tabelle angedeutet ist. Hier wurden die Attributsauspragungen zu Attributsnamen gemacht. Leider ist so etwas in den real existierenden Datenbanken sehr oft zu sehen. Losung 5: Auspragungen zu Attributsnamen

Losung 6: Neue Auspragungen

PERS 1NF 1 PersNr C 123 ja 234 ja 345 456 567

Fortran ja ja

Prolog ja

C++ Cobol ja

ja ja

Name 1 Mailer 1 Maier Schweizer Fricksen Ravensburger |

Eine solche Losung hat alle oben beschriebenen Schwachen. Zusatzlich ist es ohne Kontaktierung des Data Dictionary"^^ nicht mehr moglich abzufragen, welche Programmiersprachen im Unternehmen vorhanden sind. Auch die letzte hier angefuhrte Losung ist nicht tauglich. Dabei wird das Attribut einfach umdefmiert, z.B. von „Beherrschte Programmiersprachen" zu „Liste der beherrschten Programmiersprachen" bzw. von „Telefonnummer" zu „Liste der Telefonnummem". Natlirlich bedeutet auch dies den ganzlichen Verzicht auf alle Operationen, die liber die reine Informierung durch die Auspragungen hinausgehen.

Ein Verzeichnis der Relationen, der Schlussel, der Fremdschlussel, der sonstigen Attribute, der semantischen Integritatsbedingungen, usw., welches vom Datenbanksystem bei der Anlage der Datenbank automatisch erstellt wird.

3.12 Darstellung Relationaler Datenmodelle

55

3.12 Darstellung Relationaler Datenmodelle Spatestens nach der Herbeiftihrung der INF sind meist erste Datenmodelle entstanden, mit mehreren Relationen, Verkniipfungen, usw. Dabei wird dann auch deutlich, welche Bedeutung die beiden Notationen haben. •

•

Die grafische Notation zeigt den Gesamtzusammenhang auf, die Verkniipfung der einzelnen Relationen durch Schliissel und Fremdschltissel. Deshalb werden in dieser Notation auch nur Fremdschliissel und Schliissel angegeben (vgl. die folgende Abbildung). Die Beziehungen zwischen den Relationen werden durch Linien zwischen den beteiligten Attributen ausgedriickt (meist Schliissel in der einen und Fremdschliissel in der anderen Relation). Die textliche Notation gibt dagegen die Gesamtheit aller Attribute an. Schliissel und Fremdschlussel werden dabei auch gekennzeichnet.

Die folgende Abbildung zeigt beide Notationen"^^ flir das Datenmodell MARKT FUR DATENBANKSYSTEME. Grafische Notation DATENBANKSYSTEME #Name, Produzent ANGEBOT #(NameHae. NameDBS)

K

PRODUZENTEN #Name

HANDLER . #Name

DBS DT #(NameDBS. NameDT)

Textliche Notation "^^^ PRODUZENTEN (#Name, Ort, StraSe, Land, WWW) DATENBANKSYSTEME (#Name, Typ, Plattform, LPreis, Produzent^ ANGEBOT (#(NameDBS. NameHae), Preis) HANDLER (#Name, Ort, StraBe, Tel, Fax, Rabatte, AnsprP) DBS_DT (#(NameDBS, NameDT)

Abbildung 3.12-1:

Relationales Datenmodell MARKT FUR DATENBANKSYSTEME (vereinfacht) in

grafischer und textlicher Notation. ^^ Die grafische Darstellung eines Relationalen Datenmodelles in Tabellenform wie in den obigen Abschnitten erfolgt nur ausnahmsweise, aus Grunden der erhohten Anschaulichkeit. Ublich ist dagegen die hier vorgestellte Notation.

56

3 Modellierung Relationaler Datenbanken

3.13 Redundanzen in 1NF-Relationen Relationen in INF sind zwar gegenuber unnormalisierten Tabellen optimiert, weisen aber trotzdem noch zahlreiche „Mangel" auf. Diese Mangel sind immer solche, die zu Redundanzen in den Daten fuhren, wenn die Relation bei der Einrichtung der Datenbank angelegt und die dann entstehende Datei mit Daten gefullt wird. Um dies naher betrachten zu konnen, muss der Begriff der Anomalien in Relationen eingefuhrt werden. Betrachten wir dazu die folgende Relation. Diese ist aus Platzgriinden in zwei Tabellen zerlegt. AUFTRAGE._1NF 1 AuftragsNr 0001 0001 0001 0010 0010 0011 0011 0011 0011 0012

PosNr 1 2 3 1 2 1 2 3 4 1

ProduktNr 9901 9910 9905 9905 9910 9901 9911 9905 9906 9998

ProduktBez Laser Drucker xyz Toner xyz Papier abc Papier abc Toner xyz Laser Drucker xyz Tintenpatronen x Papier abc InkJet-Drucker yz xyz-Bildschirm

Menge 1 3 5.000 30.000 1 1 20 5.000 2 1

1

Schlussel: #( AuftragsNIr, PosNr) 1 AuftragsDatum 30.06.03 30.06.03 30.06.03 01.07.04 01.07.04 02.07.02 02.07.02 02.07.02 02.07.02 04.07.02

KundenNr 1700 1700 1700 1201 1201 1600 1600 1600 1600 1900

KundenName 1 l\/luller 1 IVIuller Muller Sammer Sammer Stanzl KG Stanzl KG Stanzl KG Stanzl KG Max OHG

Diese Relation halt Informationen zu Auftragen fest. Die AuftragsNr identifiziert den Auftrag, die PosNr die einzelnen Positionen eines Auftrags. Jede Position bezieht sich auf ein Produkt, das durch ProduktBez(eichnung) benannt und zusatzlich durch die ProduktNr identifiziert wird. Menge gibt an, wieviele Produkte in der Position aufgefuhrt sind. Das Attribut KundenNr identifiziert den Kunden, auf den sich der Auftrag bezieht. KundenName ist nicht eindeutig.

3.13 Redundanzen in 1NF-Relationen

57

Es ist unschwer zu erkennen, dass die beiden Attribute AuftragsNr und PosNr den Schlussel der Relation darstellen, weil mit den Auspragungen dieser Attribute jedes Tupel (jede Zeile) eindeutig identifiziert werden kann. Diese Relation ist in INF, da sie keine Mehrfacheintrage aufweist. Trotzdem hat sie „Schwachstellen". Betrachten wir als erstes Schwierigkeiten, die sich beim Aktualisieren von Datensatzen ergeben konnen. Eine sogenannte Aktualisierungs-Anomalie (auch: Update-Anomalie) liegt vor, wenn die Anderung einer Information dazu fuhrt, dass in mehreren Tupeln die Auspragung des entsprechenden Attributs verandert werden muss. Dies ist grundsatzlich unerwiinscht. Es hat bei der Aktualisierung des Werts die Konsequenz, dass die Zahl der zu andemden Tupel im Vomehinein unbekannt ist. Unter Umstanden muss die gesamte Relation durchsucht werden. Ursache fur eine solche Struktur ist, dass eine bestimmte Information mehrfach in der Datenbank abgespeichert ist. Im obigen Beispiel: Werden die ProduktBez(eichnungen) geandert, indem z.B. der ProduktNr 9901 statt „Laser Drucker xyz" jetzt „HP Laser Drucker Serie 5" zugeordnet wird, dann muss die ProduktBez nicht nur an einer Stelle, sondem an verschiedenen geandert werden: in jedem Datensatz, in dem sie auftaucht. Dies ftihrt leicht dazu, dass die eine oder andere Stelle vergessen wird. Besser ware es, wenn die ProduktBez fur jede ProduktNr nur an einer Stelle festgehalten wurde. Gleiches gilt fur das AuftragsDatum. Mtissen wir dieses aus irgendwelchen Griinden andem, muss dies mehrfach geschehen. Auch die Kundennamen weisen diese Eigenschaft auf Andert sich der KundenName von KundenNr 1700 von „Muller" nach „Mtiller & Paul", sind bei der Aktualisierung wieder mehrfache Anderungen notig. Es ist klar, wodurch diese Anomalie verursacht ist, durch einen VerstoB gegen die oberste Regel des Datenbankentwurfs, wonach die Datenbank so zu gestalten ist, dass jede Information nur an einer Stelle gespeichert wird. Eine EinfUge-Anomalie liegt vor, wenn ein neues (noch) unvoUstandiges Tupel nicht in die Relation eingetragen werden kann, z.B. weil unter den fehlenden Attributen ein Schlusselattribut ist. Diese Anomalie beruht also auf der oben dargelegten Festlegung, dass ein Tupel in die Relation nur eingetragen werden darf, wenn die Auspragungen fur die Schltisselattribute (die Attribute, die den Schlussel ausmachen) vorhanden sind (vgl. Objektintegritat). Im obigen Beispiel: Nehmen wir neue Produkte mit ProduktNr und ProduktBez auf, so konnen wir sie in der Relation erst erfassen, wenn wir zumindest einen Auftrag mit Positionsnummer haben, in dem sie erscheinen. Sonst ware eine Erfassung nicht moglich, da ja kein Schllisselattribut vorliegen wiirde. Ahnlich gilt fur das AuftragsDatum. Es kann erst erfasst werden, wenn die erste Position des Auftrags bekannt ist. Gleiches gilt fur KundenNr und KundenName.

Schlussel der Relation

AktualisierungsAnomalie

„Oberste Direktive"

EinfugeAnomalie

58

LoscheAnomalie

Ziel bei der Erkennung und Beseitigung der Anomalien

3 Modellierung Relationaler Datenbanken

Die Ursache fur diese Anomalie liegt darin, dass in obiger Relation mehrere verschiedene "Dinge" zusammen beschrieben werden: die Objektklassen Auflrage, Produkte und Kunden, sowie die Beziehungsklasse A U F T R A G E - K U N D E N . Diese Strukturschwache wird mit Hilfe des Konzepts der funktionalen Abhangigkeit gelost (vgl. nachsten Abschnitt). Von einer Losche-Anomalie wird gesprochen, wenn beim Loschen einer Information, die nur einen Teil des Tupels betrifft, auch die ubrigen Attributswerte verloren gehen. Im obigen Beispiel: Loscht man den Auftrag 0012, der nur eine Position hat, geht auch die Information verloren, dass XYZ-Bildschirme die Produktnummer 9998 haben. Wiederum liegt die Ursache in der Vermischung mehrerer Objekt- und Beziehungsklassen in einer Relation. Selbst diese sehr einfachen Beispiele machen deutlich, wohin die drei Anomalien zielen: sie dienen zur Klarung, welche Attribute am besten zusammen erfasst werden und welche besser getrennt werden. Sie bringen also Ordnung in den zu Beginn jeder Modellierung entstehenden "Attributs- und Merkmalshaufen", der sog. Universalrelation. Wahrend die INF dazu fuhrte, dass die Attribute zusammen bleiben, deren Auspragungen so den Objekten zugeordnet werden konnen, dass je eine Auspragung mit den anderen kombiniert wird, liegt hier eine andere Situation vor. Hier geht es darum, die Attribute zusammenfassen, die zusammen mit einem Schliissel einen „homogenen" Block bilden, die von ihm funktional abhangig sind. Dies wird erreicht durch Beseitigung der Redundanz, die in solchen Relationen angelegt ist. Deren Beseitigung klart auch die Anordnung der Attribute in der Relation. Bin sehr hilfreiches Mittel fiir die Klarung der inneren Struktur von Relationen sind die sog. funktionalen Abhangigkeiten, die im nachsten Abschnitt betrachtet werden.

3.14 Funktionale Abhangigkeiten

Vereint durch gemeinsame Modellierung

In diesem Abschnitt geht es um die Beziehungen zwischen den Attributen einer einzelnen Relation. Es geht also insbesondere nicht um die Beziehungen zwischen verschiedenen Relationen. Die wichtigste Beziehung zwischen den Attributen einer einzelnen Relation ist die, dass sie zusammen die Objekte der jeweiligen Objekt- oder Beziehungsklasse modellieren. So wie in der oben schon eingefuhrten Relation Auftrage modelliert werden. Daher ruhrt ja auch die Bezeichnung Relation fiir eine Tabelle, die diese Zusammengehorigkeit ausdruckt. Neben dieser fundamentalen Beziehung gibt es aber noch weitere, die bei der Optimierung der Relationen helfen.

3.14 Funktionale Abhangigkeiten

59

Betrachten wir obige Relation AUFTRAGE 1NF etwas genauer, konnen wir feststellen, dass von bestimmten Attributen auf andere geschlossen werden kann^^. D.h., ist die Auspragung des einen Attributs bekannt, kann die Auspragung des anderen angegeben werden. Im obigen Beispiel ist dies in folgenden Fallen moglich: •

• • •

SchlieBen vom Einen auf das Andere

Von der ProduktNr kann auf die ProduktBez geschlossen werden, und umgekehrt, wenn wir von der naheliegenden Tatsache ausgehen, dass beide - Produktnummem und Produktbezeichnungen - eindeutig sind. Von der AuftragsNr kann auf das AuftragsDatum geschlossen werden, weil ein Auftrag ein Datum hat. Von der KundenNr kann auf den KundenName(n) geschlossen werden. Von AuftragsNr und PosNr zusammen(!) auf die ProduktNr, die ProduktBez(eichnung) und die Menge, da an einer Position eines Auftrags nur ein Produkt mit einer Mengenangabe aufgefuhrt wird.

Solche Beziehungen miissen nicht existieren. So kann z.B. weder von der AuftragsNr auf die PosNr, noch von der ProduktBez(eichnung) auf den KundenName(n), usw. geschlossen werden. Sind nun aber zwischen Attributen oder Attributkombinationen solche Funktionale „SchlUsse" moglich, wird von voller funktionaler Abhdngigkeit (f A.) Abhangigkeit gesprochen. Die Wortwahl ist folgende: Kann vom Attribut A auf das Attribut B „geschlossen" werden, ist B funktional abhangig von A. In der textlichen Notation wird die voile funktionale Abhangigkeit mit => dem grafischen Symbol => dargestellt, also z.B. so: B oder AuftragsNr => KundenNr Alle bisher betrachteten funktionalen Abhangigkeiten sind sogenannte „volle". Auf die Unterscheidung von „voller" und „einfacher" f A. wird weiter unten eingegangen. Eine andere - gleichwertige - Interpretation der funktionalen Abhangigkeit ist es, die Attributsauspragungen zu betrachten: Gibt es fur eine Auspragung eines Attributs A fiir alle Tupel immer genau dieselbe fiir ein Attribut B, dann ist B funktional abhangig von A. Im obigen Beispiel: •

Jedesmal, wenn in einem Tupel eine bestimmte Produktnummer auftritt, kommt dieselbe Produktbezeichnung vor. Dies gilt auch umgekehrt.

Grundlage dafiir ist die Kenntnis der Semantik des jeweiligen Weltausschnitts.

Zweite Interpretation

60

• • •

•

Basis der funktionalen Abhangigkeit

Grundkonzept

3 Modellierung Relationaler Datenbanken

Jedesmal, wenn in einem Tupel eine bestimmte Auftragsnummer vorkommt, kommt dasselbe Auftragsdatum vor. Jedesmal, wenn in einem Tupel eine bestimmte Kundennummer vorkommt, kommt derselbe Kundenname vor. Fur eine bestimmte Kombination aus Auftragsnummer + Positionsnummer gibt es genau eine Angabe zu Produktnummer, Produktbezeichnung und zur Menge. Jedesmal wenn in einem Tupel eine bestimmte Auftragsnummer vorkommt, kommt dieselbe Kundennummer vor.

So kann ftmktionale Abhangigkeit also auch gesehen werden und manchen leuchtet diese Interpretation leichter ein als die obige. Beide Interpretationen („schlieBen auf bzw. „genau eines") sind aber gleichwertig. Einmal hilft bei der praktischen Modellierungsarbeit die eine besser, manchmal die andere. Das obige Beispiel macht auch deutlich, was die Voraussetzung ftir das Erkennen ftinktionaler Abhangigkeiten ist: das Wissen, das der Nutzer tiber den Weltausschnitt (den Anwendungsbereich) und seine konkreten Objekte hat. Ohne dieses Wissen konnen die Relationen und dann das gesamte Datenmodell nicht konstruiert werden und dieses Wissen legt auch die ftinktionalen Abhangigkeiten fest. Funktionale Abhangigkeit drlickt Zusammengehorigkeit aus. Sie geht davon aus, dass es eine identifizierende Information gibt (bestehend aus einem Attribut oder mehreren), die jedes Tupel (d.h. Objekt oder Beziehung) identifiziert und weitere Attribute, die genau dieses Objekt oder diese Beziehung naher beschreiben. Im relationalen Ansatz wird dann noch zusatzlich verlangt, dass von den beschreibenden Attributen jeweils genau eine Auspragung Gtiltigkeit hat. Funktionale Abhangigkeiten einer Relation konnen auch grafisch ausgedriickt werden, durch ein sog. Diagramm der funktionalen Abhangigkeiten (FA-Diagramm). In ihm werden die Attribute durch Rechtecke reprasentiert und die ftinktionalen Abhangigkeiten durch Pfeile. Das ft)lgende FA-Diagramm"^^ zeigt die ftinktionalen Abhangigkeiten der obigen Relation A U F T R A G E

1NF.

In der US-amerikanischen Literatur FD-Diagram (wegen: functional dependency).

3.14 Funktionale Abhangigkeiten

AuftragsDatum

KundenNr

61

WKundenName

AuftragsNr PosNr ProduktBez Abbildung 3.14-1:

FA-Diagramm der Relation A U F T R A G E Anmerkung: Jeder Pfeil reprasentiert eine voile funktionale Abhangigkeit.

Besteht ein Schltissel aus zwei oder mehr Attributen, wird um diese ein weiteres Rechteck gezeichnet, so wie in der obigen Abbildung. Besteht der SchlUssel nur aus einem Attribut, wird er wie in den ubrigen Notationen durch eine Raute gekennzeichnet (vgl. unten). Die Bedeutung der funktionalen Abhangigkeiten liegt nun darin, dass sie angeben, wie optimale Relationen strukturiert sein sollen. Folgende Attribute sollten in einer Relation erfasst werden: Ein Schlussel'^'^ und die von ihm voll funktional abhangigen Attribute. Dann gibt es keine Redundanzen und keine Anomalien mehr. Die folgenden Abbildungen zeigen solche - abstrahierten - Idealstrukturen am Beispiel von vier Attributen"^^ mit einem bzw. zwei Schliisselattributen. B #A

H c D

Abbildung 3.14-2:

Idealstruktur 1 - Relation ohne Redundanz und Anomalien

Es stort auch nicht, wenn es mehrere konkurrierende SchlUssel gibt. Die Anzahl der Attribute und SchlUssel ist ohne Bedeutung. Wichtig ist nur das Strukturmerkmal.

Strukturierungshinweis durch funktionale Abhangigkeiten

62

3 Modellierung Relationaler Datenbanken

B

^sr Abbildung 3.14-3:

Determinante

Idealstruktur 2 - Relation ohne Redundanz und Anomalien Anmerkung: Das Rechteck um die beiden Schliisselattribute kennzeichnet diese als Schlussel.

Im Rahmen der Normalisierung geht es nun darum, fiir jede Relation ohne Informationsverlust - eine solche Idealstruktur zu erreichen. Bevor wir dies vertiefen, soil noch ein weiterer Begriff eingeflihrt werden: Determinante. Jedes Attribut, von dem andere fiinktional abhangig sind, wird Determinante genannt. Determinanten konnen auch aus mehreren Attributen bestehen, wie im obigen Beispiel: Hier sind AuftragsNr und PosNr zusammen Determinante fur ProduktNr und weitere Attribute. Nattirlich sind alle Schltissel auch Determinanten. Der Weg zur oben angedeuteten „Idealstruktur" kann dann auch so beschrieben werden, dass durch sie jeweils eine Determinante und die von ihr fiinktional abhangigen Attribute zu einer Relation werden, wobei die Determinante dann Schltissel wird. Zur Veranschaulichung hier eine Abbildung, die im FA-Diagramm der Relation A U F T R A G E _ 1 N F die Determinanten (D), die Schliisselattribute (SA) und die Nichtschlusselattribute (NSA) markiert. AuftragsDatum I >

MO A J

I KundenNr [ Ln

9

KundenName

MQA —I

•NSA-*

rDAuftragsNr SA

PositionsNr ProduktBez •-D

Abbildung 3.14-4:

NSA-J

Schlusselattribute (SA), Nichtschlusselattribute (NSA) und Determinanten (D) in A U F T R A GE 1NF

3.14 Funktionale Abhangigkeiten

63

Spatestens hier wird deutlich, dass die oben angesprochenen Strukturdefizite zwei Ursachen haben: •

•

Die Tatsache, dass einzelne Schliisselattribute Determinanten sind (die Beseitigung dieses Defizits wird zur 2NF fuhren), dies fuhrt immer zu Redundanz. Der Grund ist folgender: Die Auspragungen eines einzelnen Schltisselattributs kommen in der Kegel jeweils mehrfach vor. Damit kommen auch die Auspragungen des funktional abhangigen Attributs mehrfach vor. Im obigen Beispiel: AuftragsNr hat Auspragungen, die gleich sind (die eines Auftrags). Ftir alle diese gleichen Auspragungen wird die KundenNr erfasst. Damit sind die erfassten Daten redundant. Die Tatsache, dass es Determinanten gibt, die NichtschlUsselattribute sind (die Beseitigung dieses Defizits fuhrt zur 3NF), auch dies erzeugt immer Redundanz. Der Grund: Die Auspragungen von Nichtschliisselattributen kommen natiirlich mehrfach vor und damit auch die Auspragungen der funktional abhangigen Attribute. Im obigen Beispiel: KundenNr hat natiirlich gleiche Auspragungen (fiir die Auftrage von einem Kunden). Damit wird auch der KundenName mehrfach erfasst.

Vertiefung: Schneller Weg zum Erfolg Ein schneller Weg zum Erreichen der Idealstruktur (der hochsten Normalform), der allerdings erst nach einiger Ubung leicht fallt, besteht darin, aus jeder Determinante und den von ihr abhangigen Attributen eine eigene Relation zu machen und diese dann noch durch Fremdschllissel zu verkntipfen. Nimmt man die in diesem Beispiel vorliegenden vier Determinanten AuftragsNr KundenNr ProduktNr bzw. ProduktBez und

(AuftragsNr, PosNr) kann man, sozusagen auf direktem Weg, durch Bildung von vier Relationen zur „Idealstruktur" kommen. Beachtet werden muss lediglich, dass bei der notwendigen Zerlegung die Verkntipfbarkeit erhalten bleibt. Im folgenden sind die dabei entstehenden Relationen in Tabellenform angegeben. Um die Redundanzminderung deutlich zu machen, wurden die in den neuen Relationen wegfallenden Tupel durchgestrichen stehen gelassen.

Beispiel AUFTRAGE

64

3 Modellierung Relationaler Datenbanken

AUFTRAGSKOPFE

#AuftragsNr 0001 000400040010 004-0

AuftragsDatum

KundenNr

30.06.03 30.06.03 30.06.03

•J7QQ ^70Q

01.07.04 01.07.0^

1700 1201 4201-

KUNDEN #KundenNr 1700

KundenName Muller

^7QQ ^7QQ

Mi'illpr r/l filler

1201 4204-

Sammer Sammer

PRODUKTE #ProduktNr 9901 9910 9905 99Q5 99^1 Q

#ProduktBez Laser Drucker xyz Toner xyz Papier abc Papier abo Toner xyz

AUFTRAGSPOSITIONEN 1 AuftraqsNr~ PosNr 1 0001 0001 2 0001 3 0010 1 0010 2

ProduktNr 9901 9910 9905 9905 9910

Menge | 1 3 5.000 30.000 1

Schlussel: #(AuftragsNr. PosNr)

Die fiir die relational Verkntipfling notwendigen FremdschlUssel sind entsprechend markiert. Somit zeigt sich, dass in der Ausgangsrelation Auftrage_1 NF vier verschiedene Aspekte der Realwelt modelliert waren: die Beziehung zwischen Auftragen und Kunden, die Kunden, Produkte und Auftragspositionen. Bei jeder solchen Neuordnung muss dann noch geprtift werden, ob die Zerlegung nicht zu einem Informationsverlust gefiihrt hat. Dazu muss lediglich iiberprtift werden, ob die neuen Relationen durch Attribute wieder verkntipft werden konnen Oder ob vielleicht das eine oder andere Attribut als Fremdschliissel erganzt werden muss, bzw. ob eine Verbindungsrelation notig ist. Hier ergaben sich die FremdschlUssel von selbst, dies ist aber nicht immer so. Die grafische Notation des Datenmodells Auftrage_1NF gibt den Zusammenhang zwischen den Relationen an:

3.14 Funktionale Abhangigkeiten

65

AUFTRAGE *AuflragsNr, KundenNr

y^n*'

KUNDEN #KundenNr

AUFTRAGSPOSITIONEN #(AuftragsNr, PositionsNr), ProduktNr PRODUKTE

m28

#ProduktNr #ProduktBez Abbildung 3.14-5: Datenmodell AUFTRAGE AbschlieBend noch die textliche Notation dieses Datenmodells: Auftrage(#AuftragsNr, AuftrDatum, KundenNr) Auftragspositionen(#(AuftragsNr, PosNr), ProduktNr. Menge) Kunden(#KundenNr, KundenNanne) Produkte(#ProduktNr, #ProduktBez) Im Rahmen der Datenbanktheorie wird diese „Idealform" durch zwei Normalisierungsschritte (2NF und 3NF) erreicht, die im folgenden dargestellt werden.

Bevor wir uns den in der relationalen Datenbanktheorie iiblichen Schritten auf dem Weg zum optimalen Datenmodell zuwenden, muss noch die Unterscheidung von einfachen und vollen funktionalen Abhangigkeiten eingefiihrt werden. Alle bisherigen funktionalen Abhangigkeiten waren sogenannte voile. Zur Einfuhrung der einfachen betrachten wir nochmals die urspningliche Relation A U F T R A G E _ 1 N F , die den Schlussel #(AuftragsNr, PosNr) hat. Von diesem Schliissel kann - sonst ware es kein Schlussel - auf alle iibrigen Attribute geschlossen werden, wenn auch auf unterschiedliche Weise. Die folgende Liste gibt all diese Abhangigkeiten an, die vollen f A. sind mit => gekennzeichnet: AuftragsNr, AuftragsNr, AuftragsNr, AuftragsNr, AuftragsNr, AuftragsNr,

PosNr => ProduktNr PosNr => ProduktBez PosNr ^ Menge PosNr->AuftragsDatum PosNr ^ KundenNr PosNr ^ KundenName

(voile f A.) (voile f A.) (voile f A.) (einfache f A.) (einfache f A.) (einfache f A.)

Einfache funktionale Abliangigkeit

66

3 Modellierung Relationaler Datenbanken

Wie zu sehen ist, liegen nun Abhangigkeiten vor, die nicht voile f.A. sind. Dies sind einfache funktionale Abhangigkeiten, die mit dem einfachen Pfeil -> gekennzeichnet werden. Bei diesen ist die Situation so, dass die Determinante „uberausgestattet" ist, d.h., dass die Determinante mehr Attribute aufweist, als fur die voile funktionale Abhangigkeit notig ware. In den obigen drei Fallen einfacher funktionaler Abhangigkeit wtirde z.B. das Attribut AuftragsNr alleine fur eine voile funktionale Abhangigkeit ausreichen. Somit gilt: Definition 3.14-1: Voile und einfache funktionale Abhangigkeit Eine funktionale Abhangigkeit heiBt voll, wenn von der Determinante kein Attribut weggenommen werden kann, ohne dass die funktionale Abhangigkeit verloren geht. Sie heiBt einfach, wenn die Determinante mehr Attribute enthalt, als fur die funktionale Abhangigkeit notig sind. Im obigen Beispiel gelten daruberhinaus auch noch die sozusagen trivialen einfachen funktionalen Abhangigkeiten von der Determinante auf ihre Telle: AuftragsNr, PosNr -^ AuftragsNr AuftragsNr, PosNr-> PosNr Formale Definition: einfach und voll

Diese sollen allerdings im weiteren nicht betrachtet werden. Nun zu einer formalen Definition der funktionalen Abhangigkeiten. Diese bezieht sich darauf, dass das Vorkommen eines Werts eines Attributs (bzw. einer Attributkombination"*^) AKi iiber alle Tupel hinweg mit dem Vorkommen eines bestimmten Werts eines Attributs (oder einer Attributkombination) AK2 verbunden sein kann. Die erste Definition beschreibt funktionale Abhangigkeit als solche, noch ohne die Unterscheidung in „volle" oder „einfache". Definition 3.14-2: Funktionale Abhangigkeit (f.A.) Seien T die Menge der Attribute einer Relation und AKi, AK2 e T, d.h. A K i = {All, A21, A31, ..., Ami}, AK2 = {A12, A22, A32, ..., An2}.

AK2 ist funkfional abhangig von AKi (in der jeweiligen Relation), in Zeichen: AKi -> AK2, falls gilt: alle Tupel, die in den AKi-Auspragungen ubereinstimmen, tun dies auch in den AK2-Auspragungen. Die nachfolgende Definition der vollen funktionalen Abhangigkeit erfasst nun den Tatbestand, dass die Determinante nur die Minimalausstattung an Attributen haben sollte.

Eine Attributkombination (AK) besteht aus einem oder mehreren Attributen von T, der Menge der Attribute einer Relation.

3.14 Funktionale Abhangigkeiten

67

Definition 3.14-3: Voile funktionale Abhangigkeit (voile f.A.) Seien AKi, AK2 e T. AK2 heiBt voll funktional abhangig von AKi, in Zeichen: AKi =:> AK2, falls gilt: 1) AKi -> AK2 und 2) Es gibt keine echte Untermenge AKi* von AKi, so dass gilt: AKi*^AKi 1st AKi ein einziges Attribut, dann ist AKi -> AK2 gleichbedeutend mit AKi => AK2 Als „einfache f A." soil hier weiterhin eine funktionale Abhangigkeit bezeichnet werden, die keine voile ist. Betrachten wir einige weitere Beispiele. In der Relation ANGEBOT^INF (#(NameHost, NameODB), RetrSpr, DBTyp, Vertrag, Umfang)'^'', die erfasst, welche Online-Datenbanken von welchen Hosts angeboten werden, konnen u.a. folgende Beziehungen zwischen den Attributen festgestellt werden: •

•

Ist NameODB bekannt, kann der DBTyp angegeben werden. Der DBTyp ist funktional abhangig von NameODB (oder auch: NameODB determiniert DBTyp), in Zeichen: NameODB => DBTyp. Beriicksichtigt man, dass ein Host durchaus mehrere Retrievalsprachen haben kann (z.B. flir spezielle Datenbanken) gilt nicht NameHost => RetrSpr. Nattirlich gilt auch nicht NameODB =^ RetrSpr, well dieselbe Datenbank bei verschiedenen Hosts nattirlich mit verschiedenen Retrievalsprachen abgefragt werden muss. Es gilt aber (NameHost, NameODB) => RetrSpr, da man, wenn man den Host und die Datenbank kennt, die Retrievalsprache angeben kann. Insgesamt gelten folgende funktionalen Abhangigkeiten:

NameHost, NameODB ^ RetrSpr NameHost, NameODB -^ DBTyp NameHost, NameODB => Vertrag^^ NameHost, NameODB -^ Umfang NameODB => DBTyp NameODB => Umfang

Die Attribute bedeuten: Name des Datenbankanbieters; Name der Online-Datenbank; Retrievalsprache mit der die Datenbank bei diesem Host abgefragt werden kann (ein Host kann flir verschiedene Online-Datenbanken verschiedene Abfragesprachen haben); Information, ob mit diesem Host beziiglich dieser Datenbank ein Vertrag besteht; Zahl der Datensatze in der Online-Datenbank. Da die Informationssuchenden bei einem Host auch nur fiir bestimmte Online-Datenbanken einen Vertrag abschlieBen konnen.

Weitere Beispiele

68

3 Modellierung Relationaler Datenbanken

Das folgende FA-Diagramm mit den vollen funktionalen Abhangigkeiten"^^ druckt den Sachverhalt grafisch aus. Umfang

DBTyp

RetrSpr NameODB NameHost

Abbildung 3.14-6: Beispiel ANGESTELLTE

Vertrag

FA-Diagramm der Relation ANGEB0T_1 NF

In einer Relation .:\50 Angestellte (#(PersonalNr, NameProj), PS, AnteilProj)''

gelten folgende funktionale Abhangigkeiten: PersonalNr, NameProj -^ PS PersonalNr, NameProj => AnteilProj PersonalNr => PS Das FA-Diagramm ergibt sich dann wie folgt: PersonalNRi1 NameProj tra Abbildung 3.14-7:

Beispiel ONLINEDATEN BANKEN

1 1

—^ h

W

PS AnteilProj

FA-Diagramm der Relation ANGESTELLTE

Dabei gilt, dass ein Beschaftigter in mehreren Projekten mitarbeiten kann. In einer weiteren Relation zu Online-Datenbanken 0NLINEDB_1NF(#Name, #NameKurz, Sprache, Typ, Region, Produzent, ProdLand) gilt, mit der txblichen Bedeutung^^: ^'^ In FA-Diagrammen werden grundsatzlich nur die vollen funktionalen Abhangigkeiten angegeben. ^" Die Attribute bedeuten Personalnummer; Projekt, in dem der/die Angestellte mitarbeitet; Programmiersprachen, die ein Angestellter beherrscht; Anteil der Arbeitszeit, die ein Angestellter fur ein Projekt tatig ist.

3.14 Funktionale Abhangigkeiten

69

Name => Namekurz Name => Sprache Name ^ Typ Name => Region Name =^ Produzent Name => ProdLand NameKurz => Name NameKurz => Sprache NameKurz => Typ NameKurz => Region NameKurz => Produzent NameKurz => ProdLand Produzent => ProdLand Entsprechend ergibt sich das FA-Diagramm:

#Name

k

W#NameKurz Sprache

Typ

Region

Produzent

ProdLand Abbildung 3.14-8:

FA-Diagramm der Relation OnlineDBlNF

Wie oben zu sehen war, konnen die Attribute einer Relation nicht nur in Abhangigkeit stehen, sondem auch voneinander unabhangig sein. Zwei Attribute sind gegenseitig unabhangig , falls keines vom anderen funktio-

Die Attribute bedeuten: (eindeutiger) Name der Datenbank; (eindeutiger) Kurzname der Datenbank; Sprache(n) der Datenbankeintrage und der beschreibenden Informationen; Typ der Online-Datenbank; Region(en) auf die sich die Datenbank bezieht; Produzent der Datenbank (Namen); Land des Produzenten.

Unabhangigkeit

70

Schlussel

3 Modellierung Relationaler Datenbanken

nal abhangig ist. Dies bedeutet u.a., dass die Aktualisierung eines jeden unabhangig vom anderen erfolgen kann. Weiter oben wurde ein Schltissel kurz als ein Attribut definiert, das fur jedes Objekt (fiir jedes Tupel) eine andere Auspragung hat, dessen Auspragungen, m.a.W., paarweise verschieden sind. Damit gleichbedeutend ist, dass ein Schltissel die eindeutige Identifikation aller Objekte (Datensatze) erlaubt. Dies kann nun praziser gefasst werden: Definition 3.14-4 : Schlussel Sei AK c T, d.h. AK = {Ai, A2, ..., An} AK heiBt Schltissel , falls fiir alle Am (An, ct T) aus der Relation R gilt: Ai, A2,..., An => Am 1 und keine echte Untermenge von AK diese Eigenschaft hat. Damit gilt^^ (mit AKi und AK2 als Attributskombinationen^^ einer Relation): AKi Schlussel = > AKi => AK2 D.h., falls AKi ein Schlussel ist, sind alle anderen Attributskombinationen davon voU funktional abhangig. AKi, AK2 Schlussel ===> AKi => AK2 und AK2 => AKi. Liegen zwei Schltissel vor, sind diese natiirlich gegenseitig voneinander funktional abhangig. Wie oben schon angeflihrt, werden Attribute, die Teil eines Schliissels sind, Schliisselattribute (SA) genannt; die anderen Nichtschlusselattribute (NSA).

3.15 Die zweite Normalform (2NF) Die zweite Normalform besteht nun darin, eines der oben angesprochenen Defizite zu beseitigen. Nach dessen Beseitigung ist die Relation in 2NF. Definition 3.15-1: Zweite Normalform (2NF) Eine Relation ist in zweiter Normalform (2NF), falls jedes Nichtschlusselattribut voll funktional abhangig ist vom (gesamten) Schltissel. Alternativ: ... falls kein (echtes) Schllisselattribut Determinante fiir Nichtschliisselattribute ist. Somit mussen in einer Relation mit INF und ohne 2NF einfache funktionale Abhangigkeiten bestehen. Werden diese beseitigt, beschreibt jedes Attribut dann das Objekt, das durch den Primarschliissel identifiziert wird und nicht ein anderes, das durch einen Teil des Schliissels identifiziert

'A ==> B' bedeutet "aus A folgt B", meint also die logische Implikation. Zur Erinnerung: eine Attributskombination besteht aus einem oder mehreren Attributen.

3.15 Die zweite Normalform (2NF)

71

wird. Ist diese Bedingung erfullt, konnen die oben angefuhrten Anomalien nicht auflreten. Relationen in INF, die nicht in 2NF sind, konnen in diese uberflihrt werden. Dies erreicht man dadurch, dass die Attribute der Relation so in verschiedenen Relationen neu angeordnet werden, dass a) obige 2NFBedingung erfullt ist und b) keine Information verloren geht. Betrachten wir nun nochmals obige Relation A U F T R A G E _ 1 N F . Sie soil nun schrittweise in die hoheren Normalformen gebracht werden. Sie ist tatsachlich in INF und nicht in 2NF, da von dem Schlilsselattribut AuftragsNr funktionale Abhangigkeiten ausgehen, dieses also Determinante ist: AuftragsNr => AuftragsDatum AuftragsNr => KundenNr AuftragsNr => KundenName Damit bestehen auch einfache funktionale Abhangigkeiten, deren Existenz immer ein Hinweis auf einen VerstoB gegen die 2NF ist: AuftragsNr, PosNr -^ AuftragsDatum AuftragsNr, PosNr-» KundenNr AuftragsNr, PosNr-^ KundenName Ein solches Defizit ist in den FA-Diagrammen besonders leicht erkennbar. Diese Relation wird nun schrittweise normalisiert (und nicht, wie oben in der Vertiefung, auf einmal). Zuerst nochmals die ursprtingliche Relation: (#(AuftragsNr. PosNr), ProduktNr, ProduktBez, Menge, AuftragsDatum, KundenNr, KundenName),

AUFTRAGE_1NF

Um die 2NF zu erreichen, mussen die funktionalen Abhangigkeiten von Schliisselteilen beseitigt werden. Dazu wird das Attribut (und Determinante) AuftragsNr mit alien von ihm funktional abhangigen Attributen in eine neue Relation KUNDENAUFTRAGE gestellt. Diese ist dann auf jeden Fall in 2NF, eine evtl. hohere Normalform wird spater geprtift. KUNDENAUFTRAGE 2NF 1 #AuftragsNr 0001 0010 0011 0012

AuftragsDatum 30.06.03 01.07.04 02.07.02 04.07.02

KundenNr 1700 1201 1600 1900

KundenName Mailer Sammer Stanzl KG Marx OHG

Fiir diese Relation gilt: Schltissel: NSA:

AuftragsNr AuftragsDatum, KundenNr, KundenName

1

Relation AUFTRAGE

72

3 Modellierung Relationaler Datenbanken

Funktionale Abhangigkeiten: AuftrNr => AuftragsDatum AuftrNri^KundenNr AuftrNr =:> KundenName KundenNr^ KundenName Die fiinktionalen Abhangigkeiten zeigen, dass die voile Abhangigkeit aller Nichtschliisselattribute vom Schlussel gegeben ist. Die restlichen Attribute von A U F T R A G E _ 1 N F bilden dann eine Relation AUFTRAGSPOSITIONEN, in der die einzelnen Auftragspositionen festgelegt sind. Die AuftragsNr verbleibt hier ebenfalls und ist nun einfaches Schlusselattribut. AUFTRAGSPOSITIONEN 2NF 1 AuftragsNr 0001 0001 0001 0010 0010 0011 0011 0011 0011 0012

PosNr 1 2 3 1 2 1 2 3 4 1

ProduktNr 9901 9910 9905 9905 9910 9901 9911 9905 9906 9998

ProduktBez Laser Drucker xyz Toner xyz Papier abc Papier abc Toner xyz Laser Drucker xyz Tintenpatronen x Papier abc InkJet-Drucker yz xyz-Bildscliirnn

Menge 1 3 5.000 30.000 1 1 20 5.000 2 1

Fur diese Relation gilt: Schlussel: Schlusselattribute (SA): Funktionale Abhangigkeiten:

#(AuftragsNr, PosNr) AuftragsNr, PosNr AuftragsNr, PosNr ^ ProduktNr AuftragsNr, PosNr ^ Menge AuftragsNr, PosNr => ProduktBez ProduktNr => ProduktBez

Die Verkniipfung der beiden nun entstandenen Relationen und damit die eventuelle Wiederherstellung der alten „Zusammenhange" erfolgt Uber das Attribut AuftragsNr, das ja in beiden Relationen vorkommt (^SQLNotation): KUNDENAUFTRAGE.AuftragsNr ^ AUFTRAGSPOSITIONEN.AuftragsNr Damit ergibt sich auch der in AUFTRAGSPOSITONEN angegebene Fremdschlussel. Die folgende Abbildung zeigt das sich daraus ergebende kleine Datenmodell.

1

3.15 Die zweite Normalform (2NF)

73

KUNDENAUFTRAGE #AuftragsNr -

Abbildung 3.15-1:

Relationales Datenmodell

AUFTRAGE_2NF

Obige Relation ANGEBOT^INF (#(NameHost, NameODB), RetrSpr, DBTyp, Vertrag, Umfang), muss in die zwei Relationen 0DB_2NF und ANGEB0T__2NF umgewandelt werden: ANGEB0T_2NF (#(NameHost, NameODB). RetrSpr, Vertrag) 0DB_2NF (#NameODB, DBTyp, Umfang) Wie bei alien Zerlegungen ist darauf zu achten ist, dass durch die Zerlegung keine Information verloren geht. In der Relation ANGEBOT sind jetzt die Attribute, die das Angebotsverhaltnis ("Host bietet Datenbank an") modellieren. Die Attribute von Relation ODB, die naturlich sehr schnell an Zahl zunehmen, beschreiben die Online-Datenbanken an sich. Hier nochmals die Ausgangsrelation, danach die beiden in 2NF befmdlichen Relationen.

Beispiel ANGEBOT

74

3 Modellierung Relationaler Datenbanken

DBTyp

Umfang

RetrSpr NameODB NameHost

Vertrag

Abbildung 3.15-2:

Relation ANGEB0T_1 NF

Abbildung 3.15-3:

Relation 0NLINE-DATENBANKEN_2NF

Abbildung 3.15-4:

Relation ANGEB0T__2NF

Beide sind tatsachlich bereits in einer hoheren Normalform. Da diese hier aber noch nicht besprochen ist, wurde die Endung „_2NF" angehangt. Die beiden neuen Relationen stellen ein kleines Datenmodell dar, das ONLINE-DATENBANKEN genannt werden soil:

3.15 Die zweite Normalfornn (2NF)

75

ANGEBOT 2NF

ONLINE-DATENBANKEN 2NF

#(NameODB. NameHost)

#NameODB

Abbildung 3.15-5:

Datenmodell

ONLINE-DATENBANKEN

Die 2NF ist immer dann von vomeherein erfullt, falls jeder SchlUssel aus einem einzigen Attribut besteht, denn in diesem Fall ist die funktionale Abhangigkeit immer die voile funktionale Abhangigkeit und da das Attribut Schlussel ist, sind alle NSA voll von ihm abhangig (nicht aber die anderen Schltisselattribute). Eine Zerlegung einer Relation wie oben gezeigt wird Projektion genannt. Grundsatzlich gilt, dass jede Relation, die in INF ist und nicht in 2NF, durch Projektionen immer in 2NF-Relationen zerlegt werden kann. Die Originalrelation kann durch einen sog. Verbund^"^ wiederhergestellt werden. Ein weiteres Beispiel: Die Relation PR0JEKTMITARBEIT_1NF erfasst Informationen zu Angestellten und ihrer Mitwirkung in Projekten:

Faustregel

Beispiel

PROJEKTMITARBEIT

PROJEKTMITARBEIT_ I N F 1 Name Perso- Funktion nalNr Stein Maier Muller Bach Bach

12345 12346 23456 54321 54321

Leiter DV Leiter InfMan DV

FunktionsSpez

Name- ProjProj Dauer

ProjZugeh

Proj1 Budget

Finanzen Gesamt Gesamt

LCD LCD

24 18 18 10 24

10 10 30 30 10

Bpp55

786ZZ 786ZZ

Vernetzung

LCD

24 24 18 18 24

Schluss el: #(Pe rsonalNr ', NameProje kt)

Es bedeuten: Funktion: FunktionsSpez: NameProj: ProjDauer: ProjZugeh: ProjBudget:

Funktion der Person im Projekt Beschreibung der Funktion (Spezifikation) Eindeutiger Name des Projekts Dauer des Projekts in Monaten Anzahl Monate, die die jeweilige Person dem Projekt angehort Budget des Projekts in Millionen Euro

Ein Verbund zweier Relationen entspricht der oben eingefuhrten relationalen Verknupfung zweier Relationen. Business Process Reengineering

76

3 Modellierung Relationaler Datenbanken

Das folgende FA-Diagramm gibt die vollen funktionalen Abhangigkeiten an. Name

Funktion

FunktionsSpez

PersonalNr NameProj

ProjBudget Abbildung 3.15-6:

ProjZugeh

ProjDauer FA-Diagramm der Relation PROJEKTMITARBEIT 1NF

Daneben existieren die folgenden einfachen funktionalen Abhangigkeiten: PersonalNr, NameProj -^ Name PersonalNr, NameProj -> ProjBudget PersonalNr, NameProj -> ProjDauer In welcher Normalform ist diese Relation? Die INF ist erfullt. Ein VerstoB gegen sie ware im FA-Diagramm nicht erkennbar, weshalb FADiagramme nur bei Relationen eingesetzt werden, die in INF sind. Die 2NF ist nicht erfullt, well die NSA Name, ProjBudget und ProjDauer nicht voll f.a. sind vom Schltissel. Exkurs: Anomalien in diesem Beispiel: Einfiige-Anomalie Wird ein neues Projekt gestartet, so kann es erst eingetragen werden, wenn die erste Person, die im Projekt mitarbeitet, ebenfalls bekannt ist. Losche-Anomalie Angenommen, ein Projekt ist vorlibergehend ohne Personal, z.B. weil die Mitarbeiter aus dem Projekt gekiindigt haben, neue aber noch nicht bestimmt sind. Dann verschwindet, wenn die Projektzugehorigkeit der letzten Person geloscht wird, auch die Information iiber das Projekt. Aktualisierungsanomalien Falls die ProjDauer eines Projekts verandert wird, muss diese Information nicht nur an einer Stelle geandert werden, sondern an mehreren. Gleiches gilt fiir das Projektbudget. Falls ein Mitarbeiter seinen Namen verandert, z.B. durch Heirat, gilt dasselbe.

3.15 Die zweite Normalform (2NF)

77

Diese Relation wird normalisiert in die drei Relationen PROJEKTMITARBEIT_2NF, PR0JEKTE__2NF und PERS0NAL_2NF. Zuerst die tabellarische Darstellung der sich ergebenden Relationen: PROJEKTMITARBEIT 2NF 1 PersonalNr 12345 12346 23456 54321 54321

Funktion FunktionsSpez Finanzen Leiter Gesamt DV Gesamt Leiter BPR InfMan Vernetzung DV

NameProj LCD LCD 486zz 486ZZ

LCD

ProjZugeh 1 24 18 18 10 24

Schlijssel: #(PersonalNr. NameProj) PROJEKTE 2NF #NameProj LCD tGD 486ZZ

486ZZ 4=GB

ProjDauer 24 24 18 4« 24

ProjBudget 10 •W

30 30 4©

PERSONAL 2NF #PersonalNr 12345 12346 23456 5^1321 54321

Name Stein Maier Mijller BaGh Bach

Die durchgestrichenen Zeilen sind jetzt - gegeniiber der Ausgangsrelation, (iberfltlssig. Hier die FA-Diagramme der neuen Relationen:

78

3 Modellierung Relationaler Datenbanken

PersonalNr

v^

NameProj

Funktion

FunktionsSpez

ProjZugeh

PROJEKTMITARBEIT 2NF

#NameProj

ProjBudget

ProjDauer

>ROJEKTE 2N Abbildung 3.15-7:

PERSONAL 2NF

FA-Diagramme der Relationen PROJEKTMITARBEIT_2NF, PR0JEKTE_2NF, PERSONAL_2NF

Zuletzt das Datenmodell:

PERSONAL 2NF

PROJEKTE 2NF

#PersonalNr

#NameProj

Abbildung 3.15-8:

Relationales Datenmodell PROJEKTMITARBEIT

3.16 Normalisierung, Zerlegung, Zusammengehorigkeit Der Normalisierungsschritt von der INF zur 2NF ist immer mit einer Zerlegung der Relation verbunden. Immer wird die „st6rende" Determi-

3.17 Die dritte Normalform (3NF)

79

nante, die Teil des Schliissels ist, mit den von ihr abhangigen Attributen herausgenommen und zu einer neuen Relation gemacht. Auch die weiteren Normalisiemngsschritte fuhren meist zu Zerlegungen. Fiir alle diese Zerlegungen sind nun zwei Regeln zu beachten: • •

Die Zerlegung darf zu keinem Informationsverlust fiihren. Dies wird i.d.R. durch entsprechende Schlussel/Fremdschltissel realisiert. Kommt es vor, dass eine neu entstehende Relation eine Objekt- oder Beziehungsklasse beschreibt, die bereits in einer anderen Relation angelegt ist, dann werden die beiden Relationen zusammengefiihrt. Denn es gilt: nur eine Relation fur eine Objekt- oder Beziehungsklasse!

Identisch sind zwei Relationen in diesem Sinne, wenn sie denselben Schliissel haben.

3.17 Die dritte Normalform (3NF) Auch eine Relation, die in 2NF ist, kann noch Redundanzen und Anomalien aufweisen. Betrachten wir z.B. K U N D E N A U F T R A G E _ 2 N F aus dem Datenmodell AUFTRAGE. KUNDENAUFTRAGE

1 #AuftragsNr 0001 0100 0010 0011 0012 0014

2NF

AuftragsDatum 30.06.03 18.03.04 01.07.04 02.07.02 04.07.02 04.08.03

KundenNr 1700 1700 1201 1600 1900 1900

KundenName Mijller Mijller Sammer Stanzl KG Marx OHG Marx OHG

1 1

Hier gelten folgende ftinktionalen Abhangigkeiten: AuftrNr ^ AuftragsDatum AuftrNr=> KundenNr AuftrNr => KundenName KundenNr => KundenName Die Relation ist ohne Zweifel in 2NF. Die trotzdem noch vorliegende Redundanz liegt darin, dass dieselbe Kundennummer nattirlich sehr oft vorkommen kann und fiir jedes Vorkommen der Kundennamen erfasst wird. Als besonderes Strukturmerkmal halten wir fest, dass ein Nichtschltisselattribut (NSA), KundenNr, Determinante ist und dass eine „fortgesetzte" funktionale Abhangigkeit besteht: AuftrNr => KundenNr => KundenName

Redundanz

80

Transitive Abhangigkeit

3 Modellierung Relationaler Datenbanken

Eine solche „fortgesetzte" funktionale Abhangigkeit wird transitive Abhdngigkeit zwischen AuftrNr und KundenName genannt (in Anlehnung an den entsprechenden Begriff der Mathematik^^) und so dargestellt: AuftrNr-

Beispiel ANGESTELLTE

KundenName

Das nachste Beispiel betrifft eine Relation mit Informationen zu Angestellten. Im Rahmen eines Modellierungsvorhabens habe sich folgende Relation ergeben: ANGESTELLTE (#PersNr, Abteilung, AbtLeiter, Name, Vorname, Alter, Wohnort, StrafJe) Mit der Festlegung, dass hier nur der Hauptwohnsitz erfasst wird, dass also jede/r nur eine Adresse hat, gelten folgende funktionalen Abhangigkeiten: PersNr=> Name PersNr=> Vorname PersNr=> Abteilung PersNr^ AbtLeiter PersNr=^ Alter PersNr=> Wohnort PersNr=:> StrafJe Somit gilt: PersNr => Abteilung =:^ AbtLeiter und damit die folgende transitive Abhangigkeit: PersNr -^:\^ AbtLeiter Die Redundanz liegt hier in der Mehrfacherfassung des Zusammenhangs Abteilung => AbtLeiter Bei jedem Eintrag einer Abteilung wird auch der Abteilungsleiter eingetragen. Das folgende FA-Diagramm mit den vollen funktionalen Abhangigkeiten macht dieses Strukturmerkmal deutlich:

^^' Zur Erinnerung (an die Schulalgebra): transitiv bedeutet eine Beziehung uber ein anderes Element hinweg. A und B sind in (irgendeiner) transitiven Beziehung (bez), wenn fur diese gilt. A bez C bez B.

3.17 Die dritte Normalform (3NF)

Name

81

Vorname

Wohnort

#PersNr

StraBe

Abteilung L

Abbildung 3.17-1:

AbtLeiter

FA-Diagramm der Relation ANGESTELLTE_2NF

Die Grafik visualisiert auch sehr deutlich den VerstoB gegen die oben schon dargestellte Idealstruktur. Die entsprechende „storende" funktionale Abhangigkeit wurde durch einen „Blitz" markiert. Auch hier ist also wieder ein Nichtschlusselattribut (NSA) Determinante. Das folgende Beispiel betrifft wieder die Relation zu Online-Datenbanken: 0NLINE-DATENBANKEN_2NF(#Name, #NameKurz, Sprache, Typ, Region, Produzent, ProdLand) Auch diese Relation ist in 2NF, da - wie auch aus dem FA-Diagramm ersichtlich - alle Nichtschliisselattribute voll funktional abhangig sind vom PrimarschlUssel^^. Trotzdem weist sie Strukturmangel auf, wie auch die folgende tabellarische Darstellung deutlich macht (einige Attribute wurden aus Platzgriinden weggelassen)^^:

Bitte nicht irritieren lassen von den zwei Schiusseln. Diese stellen keinen VerstoB gegen die 2NF dar, denn es sind zwei konkurrierende Schlussel. VerstoBe gegen die 2NF basieren immer auf einem (aus mehreren Attributen) zusammengesetzten Schlussel. Vgl. das FA-Diagramm zu dieser Losung weiter unten, bei der Uberfiihrung in die 3NF.

Beispiel OnlineDatenbanken

3 Modellierung Relationaler Datenbanken

82

ODB 2NF 1 Name CRONOS-FRIC CRONOS-BISE Predicasts Overview of Markets and Technology Predicasts U.S.Time Series

NameKurz FRIC BISE PTS Promt

Produzent EUROSTAT EUROSTAT Predicasts

ProdLand 1 Luxemburg 1 Luxemburg USA

PTS USTS

Predicasts

USA

Anmerkung: die angegebenen Attributsauspragungen sind fiktiv Die Strukturmangel bestehen darin, dass Nichtschliisselattribute voneinander funktional abhangig sind, so wie hier Produzent :=> ProdLand und dass dadurch eine transitive Abhangigkeit entsteht: Name - > : : ^ ProdLand Anomalien-

In einem solchen Fall treten wieder die oben besprochenen Anomalien

Beispiel

auf:

•

•

•

Ein neuer Produzent mit seinem Land kann - wegen der Forderung der Objektintegritat - nicht eingetragen werden, ohne dass nicht zumindest eine seiner Datenbanken bekannt ist (Einfiige-Anomalie) Verlegt ein Produzent seinen Hauptsitz in ein anderes Land, muss das neue Land nicht nur an einer Stelle, sondem an mehreren geandert werden (Aktualisierungs-Anomalie) Miissen wir die letzte uns bekannte Online-Datenbank eines Produzenten loschen, verlieren wir auch die Information iiber seine Existenz und das Land, in dem er ansassig ist (Losche-Anomalie).

Die Ursache dafur ist wieder die Redundanz, die sich aus einem solchen Strukturmerkmal ergibt: Wie auch die obige tabellarische Darstellung zeigt, wird ProdLand fur jede Datenbank des Produzenten erfasst. Die Schwierigkeiten entstehen wiederum dadurch, dass NameProd zwar Determinante, aber nicht Schliisselattribut ist. Dadurch wird mit NameProd und ProdLand die Beschreibung einer zweiten Objektklasse aufgenommen, die z.B. mit weiteren Adressangaben fortgesetzt werden kann. Formal erfasst wird dieses Strukturdefizit iiber den oben schon eingefiihrten Begriff der transitiven Abhangigkeit. Es gelten ja die funktionalen Abhangigkeiten (mit der Annahme, dass jede Online-Datenbank nur einen Produzenten hat): Name => Produzent Produzent => ProdLand

3.17 Die dritte Normalform (3NF)

83

Ebenso gilt natiirlich, dass von der Online-Datenbank auf das Land des Produzenten geschlossen werden kann: Name => ProdLand Insgesamt lasst sich damit wieder eine „Kette" aufstellen:

N a m e =^ Produzent => ProdLand Die transitive Abhangigkeit ist formal wie folgt defmiert: Definition 3.17-1: Transitive Abhangigkeit A und C seien Attribute einer Relation R. C heiBt transitiv abhangig von A, in Zeichen: A -^::-^ C, falls es ein Attribut B aus R gibt mit dem gilt: A ^ B => C (A o B <> C) Entsprechendes gilt fur Attributkombinationen, wenn also fur A, B oder C mehrere Attribute stehen. Auch im folgenden Beispiel (einer Version der Relation ANGEBOT) liegt eine transitive Abhangigkeit vor: 0DB-H0ST__2NF (#(NameODB, NameHost), RetrSpr, TypRetrSpr) Folgende Annahmen sollen gelten: • •

Ein Host verwendet u.U. fur verschiedene Online-Datenbanken unterschiedliche Retrievalsprachen^^. Retrievalsprachen werden eindeutig typisiert (z.B.: "geeignet flir Zeitreihen", "geeignet fur datensatzorientierte Datenbanken", „geeignet fur Textdatenbanken", usw.)

Dann gelten die folgenden funktionalen Abhangigkeiten: #(NameODB, NameHost) => RetrSpr #(NameODB, NameHost) => TypRetrSpr RetrSpr => TypRetrSpr und damit #(NameODB, NameHost) ^ : : ^ TypRetrSpr Das FA-Diagramm:

Abfragesprachen flir Online-Datenbanken

Noch ein Beispiel: ODB-HOST

84

3 Modellierung Relationaler Datenbanken

Abbildung 3.17-2:

3NF

Relation 0DB-H0ST__2NF

Das FA-Diagramm visualisiert sehr deutlich den VerstoB gegen die 3NF durch die funktionale Abhangigkeit, die von einem NSA ausgeht. Die Beispiele machen deutlich, wodurch die transitiven Abhangigkeiten Schwierigkeiten bereiten: durch sie wird die Beschreibung einer weiteren Objekt- oder Beziehungsklasse eroffnet (hier z.B. durch RetrSpr =^ TypRetrSpr die der Retrievalsprachen), zusatzlich zu der eigentlich in der Relation beschriebenen (hier die der Beziehung zwischen OnlineDatenbanken und ihren Anbietem. Dies flihrt dann zu der oben beschriebenen Redundanz in den Daten. Liegen solche Strukturen nicht vor oder wurden sie beseitigt, ist eine Relation in dritter Normalform: Definition 3.17-2: Dritte Normalform (3NF) Eine Relation ist in dritter Normalform (3NF), falls sie in 2NF ist und falls keine transitiven Abhangigkeiten zwischen dem Schliissel und Nichtschltisselattributen (NSA) bestehen (altemativ: ... falls kein NSA Determinante ist). Somit gilt: •

• •

Regel: Von der 2NF zur 3NF

in einer 3NF-Relation ist kein Nichtschlusselattribut (NSA) transitiv von einem Schlussel abhangig, d.h. jedes NSA beinhaltet eine Eigenschaft, die dem zugrundeliegenden Objekt als Ganzes zukommt. Eine Relation ist in 3NF genau dann wenn alle NSA gegenseitig unabhangig und voll abhangig sind vom Schliissel. "A relation R is in third normal form (3NF) if and only if, for all time, each tuple of R consists of a primary key value that identifies some entity, together with a set of zero or more mutually independent attribute values that describe the entity in some way" [Date 1986, S. 367].

Damit ist dann der Bezug auf ein Objekt im relationalen Sinn voll hergestellt. Im FA-Diagramm auBert sich dies so, dass Pfeile nur vom Primarschlussel ausgehen, so wie in Abschnitt 3.14 als Idealstrukturen gezeigt. Eine Relation mit einer transitiven Abhangigkeit wird wie folgt normalisiert: Die Determinante, die nicht Schliisselattribut ist, bildet zusammen mit dem von ihr abhangigen Attribut eine neue Relation. In der Ur-

3.17 Die dritte Normalform (3NF)

85

sprungsrelation muss diese Determinante (die nach der Normalisierung keine mehr ist) ebenfalls stehen bleiben. Betrachten wir dies anhand der obigen drei Beispiele. Die Relation zu den Kundenauftragen hatte folgenden Aufbau: KUNDENAUFTRAGE_2NF (#AuftragsNr, AuftragsDatum, KundenNr, KundenName)

Von 2NF nach 3NF: Beispiel KUNDEN-

Das Nichtschliisselattribut als Determinante war KundenNr:

AUFTRAGE

KundenNr=^ KundenName Die transitive Abhangigkeit: AuftragsNr->::^ KundenName Damit muss die Relation in folgende zwei zerlegt werden: AUFTRAGE__3NF (#AuftragsNr, AuftragsDatum, KundenNr) KUNDEN_3NF (#KundenNr, KundenName) Das Attribut KundenNr wird zu einem Fremdschltissel. Die Relation zu den Angestellten hat das Attribut Abteilung, das gleichzeitig NSA und Determinante ist, und damit eine transitive Abhangigkeit zwischen PersNr und AbtLeiter (vgl. auch das FA-Diagramm oben): ANGESTELLTE_2NF (#PersNr, Abteilung, AbtLeiter, Name, Vorname. Alter, Wohnort, StrafJe) Abteilung => AbtLeiter PersNr ->::-> AbtLeiter Die Relation muss in die folgenden zwei Relationen zerlegt werden: ANGESTELLTE_3NF (#PersNr, Abteilung, Name, Vorname, Alter, Wohnort, StrafJe) ABTEJLUNG^SNF (#Abteilung, AbtLeiter) Hier die FA-Diagramme der neuen Relationen:

Von 2NF nach 3NF: Beispiel ANGESTELLTE

86

3 Modellierung Relationaler Datenbanken

Name

Vorname Alter

Wohnort

#PersNr

StraBe Abteilung Abbildung 3.17-3:

FA-Diagramm zur Relation ANGESTELLTE_3NF

#Abteilung Abbildung 3.17-4: Von der 2NF zur 3NF: Beispiel ONLINEDATENBANKEN

AbtLeiter

FA-Diagramm zur Relation ABTEILUNG_3NF

In der oben vorgestellten Relation ONLINE-DATENBANKEN ist Procluzent(enname) die „storende" Determinante: 0NLINE-DATENBANKEN__2NF(#Name, #NameKurz, Sprache, Typ, Region, Produzent, ProdLand) #NameKurz

#Name Sprache

Typ

Region

Produzent

ProdLand

Abbildung 3.17-5:

Relation 0NLINE-DATENBANKEN_2NF

3.17 Die dritte Normalform (3NF)

87

Fur die LFberfiihrung in die 3NF wird diese Relation in die folgenden zwei Relationen zerlegt: 0NLINE-DATENBANKEN_3NF (#Name, #NameKurz, Sprache, Typ, Region, Produzent) PRODUZENTEN_3NF(#Produzent, ProdLand) Etwaige hinzukommende Adressangaben waren dann an die Relation PR0DUZENT_3NF anzuhangen. Damit ergeben sich folgende FADiagramme:

#Name K

•H#NameKurz Sprache

Typ

Region

Produzent m2A

Abbildung 3.17-6:

FA-Diagramm der Relation ONLINEDATENBANKEN 3NF

# Produzent Abbildung 3.17-7:

ProdLand

FA-Diagramm der Relation PRODUZENTEN 3NF

Das obige Beispiel

Von der 2NF

0DB-H0ST_2NF (#(NameODB, NameHost), RetrSpr, TypRetrSpr)

Bdspiei'

zur 3NF' . ,

,

.

wird zerlegt m 0DB-H0ST_3NF (#(NameODB, NameHost), RetrSpr) und RETRSPR_3NF (#RetrSpr, TypRetrSpr)

ODB-HOST

88

3 Modellierung Relationaler Datenbanken

NameODB NameHost Abbildung 3.17-8:

r^^

Beispiel: PERSONAL

RetrSpr m18A

FA-Diagramm der Relation 0DB-H0ST__3NF

#RetrSpr Abbildung 3.17-9:

^ w

TypRetrSpr

FA-Diagramm der Relation RETRSPR_3NF

Zum Abschluss dieses Abschnitts nun noch ein groBeres Beispiel fur den Weg von der INF zur 3NF - mit ungewohnlichem Schlussel. Im Rahmen eines Modellierungsvorhabens habe sich folgende Relation ergeben: PERSONAL (PersonalNr, Name, Wohnort, AbtNr, AbtName, NameProj, Projektraum) Bedeutung der Attribute: PersonalNr Name Wohnort AbtN r AbtName NameProj ProjRaum

Personalnummer Namensangaben der Beschaftigten Wohnort der Beschaftigten (Erster Wohnsitz) Abteilungsnummer Namen der Abteilungen Namen von Projekten Raum, in dem die Projektleitung angesiedelt ist

Zur Semantik: • • •

Ein Mitarbeiter kann in mehreren Projekten sein Ein Mitarbeiter ist nur genau einer Abteilung zugeordnet Die Projektleitung ist in genau einem Raum angesiedelt.

Damit gelten folgende einfachen (->) und vollen (=>) funktionalen Abhangigkeiten: PersonalNr => Name PersonalNr => Wohnort PersonalNr => AbtNr PersonalNr => AbtName AbtNr => AbtName AbtName ^ AbtNr NameProj ^ Projektraum PersonalNr, NameProj -> Name

3.17 Die dritte Normalform (3NF)

PersonalNr, PersonalNr, PersonalNr, PersonalNr,

NameProj NameProj NameProj NameProj

-^ -> -> ->

89

Wohnort AbtNr AbtName Projektraum

Ein Schliissel ist so defmiert, dass durch ihn jedes Tupel eindeutig identifiziert wird. Also miissen in ihm die Determinanten zusammengefugt werden, von denen alle iibrigen Attribute funktionell abhangig sind. Somit wird hier die Attributkombination (PersonalNr, NameProj) Schlussel. Von diesem Schlussel ist allerdings kein Attribut voll funktional abhangig, wie auch das folgende FA-Diagramm zeigt: Name

Wohnort

AbtName PersonalNr NameProj

AbtNr

p

Projektraum Abbildung 3.17-10: FA-Diagramm der Relation PERSONAL Eine solche Relation ist - die INF mal vorausgesetzt - nicht in 2NF. Ihre tjberfiihrung in 2NF fiihrt - ausgedriickt in FA-Diagrammen - zu folgendem Ergebnis:

Schlusselbestimmung

90

3 Modellierung Relationaler Datenbanken

Name

Wohnort

AbtName #PersonalNr AbtNr

P

Abbildung 3.17-11: FA-Diagramm der Relation PERS-ABT_2NF

#NameProj

Projektraum

m20A

Abbildung 3.17-12: FA-Diagramm der Relation PR0JEKTE_2NF

PersonalNr

NameProj

Abbildung 3.17-13: FA-Diagramm der Relation PERS-PR0J_2NF Die Relation PERS-PR0J___2NF, die sozusagen die Projektmitarbeit festhalt, dient als Verbindungsrelation zwischen den anderen beiden Relationen. PERS-PR0J_2NF und PR0JEKTE_2NF befmden sich auch gleich in 3NF, wahrend PERS_ABT_2NF nochmals zerlegt werden muss (diesmal in textlicher Notation): PERS_3NF(#PersonalNr, Name, Wohnort, AbtNr) und ABT_3NF(#AbtNr, #AbtName) Bei ABT___3NF sind beide Attribute Schltisselattribute. Eines davon wird als Primarschliissel festgelegt. Insgesamt ergibt sich damit das folgende relationale Datenmodell:

3.17 Die dritte Normalform (3NF)

91

PERS-PROJ 3NF #(PersonalNr. ProiName)

PROJEKTE 3NF PERS 3NF

#ProjName

#PersonalNr, AbtNr ABT 3NF #AbtNr, #AbtName Abbildung 3.17-14: Relationales Datenmodell

PERS_ABT___PR0J

Vertiefung: „RelationaIe" Objekt- und Beziehungsklasse Ganz zu Beginn des Kapitels, bei der Einfuhrung des Relationenbegriffs, wurde als ein Modellierungsschritt genannt, dass jede Objektklasse und jede Beziehungsklasse in eine Relation „eingefullt" wird. 1st dies geschehen, entsprechen sich (Objekt-/Beziehungs-)Klasse und Relation noch sehr genau. Wird dann die INF herbeigeflihrt, sind u.U. Attribute mit Mehrfacheintragen weggenommen und in eigene Relationen getan worden. Die Ubereinstimmung von (Objekt-/Beziehungs-)Klasse und Relation ist nicht mehr voll gegeben. Die Klasse wird durch zwei oder drei Relationen beschrieben. Genauso bei der Herbeifuhrung der 2NF und 3NF. Die Attribute der (Objekt/Beziehungs-)Klasse werden falls notig auf verschiedene Relationen verteilt, diesmal aber, well in der Ausgangsrelation verschiedene Objekt-ZBeziehungsklassen beschrieben wurden. Insgesamt gilt, dass die urspriingliche Beschreibung der (Objekt-ZBeziehungs-)Klasse sich nach den Normalisierungsschritten nicht mehr in einer Relation, sondern in mehreren (u.U: zahlreichen) befindet. Soweit die Betrachtung der ersten drei Normalformen. Dies sind gleichzeitig auch die wichtigsten, zumindest fiir die Praxis der Datenhaltung. Wie zu erkennen ist bedeutet Normalisierung, dass Relationen in eine hohere Normalform gebracht werden und dass dies meist durch Zerlegung geschieht. Diese Zerlegung sollte aber gewissen Regeln geniigen. Die wichtigsten seien hier nochmals zusammengefasst:

Normalisierung durch Zerlegung

92

•

• •

3 Modellierung Relationaler Datenbanken

Es darf keine Information verloren gehen. D.h., es muss durch entsprechende Schlussel/Fremdschliissel-Anordnung erreicht werden, dass die zerlegten Relationen gegebenenfalls wieder verkniipft werden konnen. Es darf durch die Zerlegung in keinem Bereich des Datenmodells ein Ruckschritt bezuglich der Normalformen erfolgen. Nach jeder Zerlegung ist zu prufen, ob die neu entstandenen Relationen nicht mit anderen, schon bestehenden, verschmolzen werden konnen. Grundsatzlich gilt, dass fur eine relational Objekt- oder Beziehungsklasse immer nur eine Relation vorhanden sein darf

3.18 Die Boyce-Codd - Normalform (BCNF) Auch die Boyce-Codd - Normalform (benannt nach ihren Entdeckern) dient ebenfalls allein dem Zweck der Optimierung der relationalen Struktur, d.h., der optimierten Anordnung der Attribute in flachen Tabellen. Mit ihr werden Defizite beseitigt, die in Bezug auf die Coddsche dritte Normalform im Laufe der Jahre entdeckt wurden. Konkret waren dies Schwierigkeiten die auftreten, falls eine Relation mehrere zusammengesetzte (aus mehreren Attributen bestehende) und sich iiberlappende Schlussel hat und zwischen einzelnen Schlusselattributen fimktionale Abhangigkeiten bestehen. Denn die 3NF verlangt nicht die voile funktionale Abhangigkeit eines Attributs vom Primarschliissel, falls es selbst Attribut eines Schlussels ist. Betrachten wir als Beispiel die folgende Relation PROJEKTMITARBEIT. In der unteren Zeile ist angegeben, welche RoUe das jeweilige Attribut in der Relation wahrnimmt. PROJEKTMITARBEIT lAngName Stein, Anton Maier, Paul Muller, Erwin M. Bach, Susanne Bach, Susanne Bach, Susanne

PersonalNr 12345 12346 23456 54321 54321 54321

Funktion Leiter DV Leiter InfMan DV InfMan

ProjName LCD LCD 787ZZ 787ZZ LCD GPO

ProjZugeh 1 24 18 18 10 24 6

SA SA NSA SA NSA Schlussel: #(AngName, ProjName) oder#(PersonalNr, ProjName) Primarschlussel sei #(AngName, ProjName) Es gelte folgende Semantik: • •

Das Attribut AngName sei eindeutig(!) Die Funktion beschreibt die Stellung der Angestellten (Leiter: Projektleiter, InfMan: Informationsmanager, DV: DV-Spezialist). Eine

3.18 Die Boyce-Codd - Normalform (BCNF)

•

•

93

Angestellte kann in verschiedenen Projekten unterschiedliche Funktionen haben. ProjName ist der (eindeutige) Name des Projekts (LCD: Entwicklung eines neuen LCD-Displays, 787zz: Entwicklung eines neuen Prozessors, GPO: Geschaftsprozessoptimierung) ProjZugeh erfasst die Dauer der Projektzugehorigkeit in Monaten.

Damit gelten folgende vollen funktionalen Abhangigkeiten: (AngName, ProjName) => Funktion (AngName, ProjName) =:> ProjZugeh (PersonalNr, ProjName) => Funktion (PersonalNr, ProjName) ^ ProjZugeh AngName ^ PersonalNr PersonalNr => AngName

PersonalNr Funktion ProjName ProjZugeh AngName

Abbildung 3.18-1:

FA-Diagramm der Relation PROJEKTMITARBEIT

Die Relation ist in der 3NF, well die NichtschlUsselattribute voll funktional abhangig sind vom Schliissel und well es zwischen den NSA's keine weiteren vollen funktionalen Abhangigkeiten gibt. Trotzdem weist diese Relation Redundanzen auf und vermischt Konzepte zweier relationaler Objektklassen, was wiederum zu den schon diskutierten Anomalien fuhrt: Zum einen erfasst sie die Funktion und Projektzugehorigkeit der Personen, zum anderen erfasst sie, welche Personalnummer die Personen haben. Das Problem liegt hier also darin, dass die 1:1 - Beziehung zwischen den beiden Schlusselattributen AngName und PersonalNr mehrfach erfasst wird. D.h., die Tatsache, dass z.B. Bach die Personalnummer 54321 hat, wird mehrfach erfasst, usw. (vgl. auch obige tabellarische Darstellung). Diese Redundanz wird von der 3NF nicht beseitigt, da diese funktionale Abhangigkeiten zwischen Schlusselattributen nicht betrachtet. Die Anomalien hier im einzelnen:

Vermischung

94

EinfilgeAnomalie

LoscheAnomalie

AktualisierungsAnomalie

L5sung durch Zerlegung

3 Modellierung Relationaler Datenbanken

Dorrer wird neu eingestellt und erhalt eine Personalnummer. Sie ist allerdings noch keinem Projekt zugeordnet. Ihre Daten konnen nicht erfasst werden (wegen der Forderung der Objektintegritat), da zum Schliissel ja auch ein Projekt gehort. Stein verlasst das Projekt „LCD", sein Datensatz wird geloscht. Damit verschwindet auch die Information, welche Personalnummer er hat. Die Ursache hierfur kann darin gesehen werden, dass hier zwei verschiedene Aspekte der Realwelt beschrieben werden. Bach erhalt eine neue Personalnummer. Um diese Information in die Datenbank einzutragen, muss fur jeden Eintrag „Bach/5432r' die Anderung vorgenommen werden. Es wird also gegen die Kegel verstoBen, dass jede in der Datenbank gespeicherte Information nur an einer Stelle stehen sollte. Wieder besteht die Losung in der Zerlegung der Relation. Zum einen in eine Relation PROJEKTMITARBEIT, zum anderen in eine Relation PERSONAL, die nattirlich mit einer entsprechenden evtl. schon existierenden verschmelzen wtirde. Relationen, die in der 3NF sind und ein derartiges Strukturdefizit nicht aufweisen, befmden sich in der Boyce-Codd-Normalform (BCNF). Definition 3.18-1: Boyce/Codd-Normalform (BCNF) Eine Relation ist in BCNF, falls jede Determinante Schliissel ist (Primar- oder Sekundarschliissel). Diese Definition umfasst dann nattirlich auch die 2NF und die 3NF (vgl. hierzu auch oben). Sie geht weiter, als die der 3NF, wo ja nur verhindert wird, dass ein NSA zur Determinante wird. Hier wird auch verhindert, dass ein SA, das nicht selbst Schlussel ist, Determinante wird. In obigem Beispiel ergeben sich dann die zwei Relationen PERSONAL__BCNF (#AngName, #PersonalNr) PROJEKTMITARBEIT^BCNF (#(AnqName. ProjName), Funktion, ProjZugeh) Hier die FA-Diagramme: PersonalNr ProjName

1

b

r"

Funktion

^ ProjZugeh w

m3T

Abbildung 3.18-2:

FA-Diagramm der Relation PROJEKTMITARBEIT BCNF

3.18 Die Boyce-Codd - Normalform (BCNF)

95

PersonalNr AngName

Abbildung 3.18-3:

FA-Diagramm der Relation PERSONAL_BCNF

Damit entsteht ein kleines Datenmodell: PROJEKTMITARBEIT BCNF

PERSONAL BCNF

#(PersonalNr. ProjName)

#PersonalNr, #AngNAme

Abbildung 3.18-4:

Relationales Datenmodell PROJEKTMITARBEIT

Die tabellarische Darstellung macht den wesentlich effizienteren Aufbau der neuen Relationen deutlich. Die jetzt iiberflUssigen Tupel wurden durchgestrichen. PROJEKTMITARBEIT_BCN 1 PersonalNr ProjName LCD 12345 LCD 12346 787ZZ 23456 787ZZ 54321 LCD 54321 54321 GPO

ProjZugeh 24 18 18 10 24 6

SA SA NSA Schlussel: #(PersonalNr, ProjName)

Funktion Leiter DV Leiter InfMan DV InfMan NSA

| 1

3 Modellierung Relationaler Datenbanken

96

PERSONAL BCNF

Nochein Beispiel

#AngName Stein, Anton Maier, Paul Muller, Erwin M. Bach, Susanne Bach, Susanne Bach, Susanne

#PersonalNr 12345 12346 23456 §4324 §4324§4324

SA

SA

Im folgenden Beispiel (nach einem Beispiel aus [Date 1990, S. 546]) gilt folgende Semantik: • •

Bin bestimmtes Fach hort jeder Student nur bei einem Dozenten Jeder Dozent an dieser Hochschule lehrt nur ein Fach, aber jedes Fach wird von mehreren Dozenten gegeben.

VORLESUNGEN 1 Studierende Fach Schmidt Datenbanksysteme Burokommunikation Schmidt iVIuller Datenbanksysteme Burokommunikation Muller 1 Johnson Netzwerkdatenbanken SA SA Schlussel: #(Studierende, Fach)

Dozent Steiner Grauer Steiner Grauer Wagner SA

1

Aus der ersten obigen Semantikfestlegung ergibt sich (Studierende, Fach) => Dozent Aus der zweiten Semantikfestlegung folgt Dozent => Fach Damit gibt es einen zweiten SchlUssel: #(Dozent, Studierende). All dies ^hrt zu folgendem FA-Diagramm:

Abbildung 3.18-5: FA-Diagramm der Relation VORLESUNGEN

3.18 Die Boyce-Codd - Normalform (BCNF)

97

Beide (zusammengesetzten) Schliissel sind durch entsprechende Rechtecke gekennzeichnet. Die beiden Schliissel uberlappen sich. In welcher Normalform befmdet sich diese Relation? Die 2NF ist erfiillt, da es keine Nichtschltisselattribute gibt, ebenso die 3NF. Uberprtifen wir die BCNF. Diese verlangt, dass jede Determinante Schlussel ist, was hier offensichtlich nicht der Fall ist. Bevor wir diese Relation normalisieren, suchen wir die Anomalien. Diese sind darin begrtindet, dass der Zusammenhang Dozent - Fach (Jeder Dozent lehrt nur ein Fach") mehrfach erfasst wird, was bereits bei den wenigen Tupeln der obigen Tabelle sichtbar wird. Im einzelnen: Andert der Dozent Sterner den Namen seines Fachgebietes zu Computergestutzte Informationssysteme ist diese Anderung mehrfach zu vollziehen, so oft, wie die Anzahl der Studierenden ist, die das Fach belegt haben. Ein neuer Dozent gibt das Fach Geschdftsprozessoptimierung. Er kann erst eingetragen werden, wenn sich der erste Studierende fiir sein Fach entschieden hat, da erst dann ein Eintrag moglich ist, bei dem der Schliissel vollstandig ist (Forderung nach Objektintegritat) Verlasst der Studierende Miiller den Kurs Netzwerkdatenbanken des Dozenten Wagner, geht auch die Information verloren, dass Wagner dieses Fach lehrt. Wie immer deutet die Loscheanomalie damit an, dass „verschiedene Dinge" in eine Relation gepackt wurden. Hier ist es zum einen der Vorlesungsbesuch der Studierenden, zum andem die Dozententatigkeit. Die Normalisierung - gemaB den Forderungen der BCNF - flihrt zu folgendem Ergebnis:

Studierende

Abbildung 3.18-6:

Dozent

FA-Diagramm der Relation STUDIERENDE-DOZENTEN BCNF

Fach

#Dozent

T^AT

Abbildung 3.18-7:

FA-Diagramm der Relation DOZENTENTATIGKEIT BCNF

Die Relation STUDIERENDE-DOZENTEN halt fest, welcher Studierende bei welchem Dozent einen Kurs besucht. Die untere, welches Fach ein Dozent lehrt. Ware in der ersten Relation statt „Dozent" das Attribut Fach genommen worden, ware die Relation zwar korrekt, was den Zusammenhang Studierende - Fach angeht, es ware aber keine Verkniipfung

AktualisierungsAnomalie

EinfiigeAnomalie

LoscheAnomalie

98

3 Modellierung Relationaler Datenbanken

mit der anderen Relation moglich gewesen. Insofem ware gegen die Regel, dass eine Zerlegung ohne Informationsverlust zu erfolgen hat, verstoBen worden und die Losung ware falsch. Die folgende Abbildung zeigt das Datenmodell, es soil STUD-DOZ genannt werden. Relationales Datenmodell STUD-DOZ

STUDIERENDE-DOZENT BCNF

DOZENTENTATIGKEIT BCNF

#(Dozent, Studierende)

#Dozent

Abbildung 3.18-8:

Relationales Datenmodell

STUD-DOZ

3-19 Die vierte Normalform (4NF)

Mehrfache Mehrfacheintrage

Beispiel

Obwohl die BCNF bereits recht „ordentliche" Relationen schafft, fanden sich im Laufe der Zeit doch Konstellationen, die von ihr nicht erfasst werden. Eine solche driickt sich in der 4NF aus. Ich hore oft, dass diese Normalform keine Bedeutung in der Praxis hatte. Dies ist nicht ganz richtig. Sie gibt uns zumindest einen Hinweis auf eine mogliche Fehlerquelle gleich zu Beginn der Normalisierungsschritte, bei der Behandlung der unnormalisierten Relation. Deshalb soil sie hier auch betrachtet werden. Der Hintergrund der vierten Normalform kann wie folgt beschrieben werden: Angenommen, es liegt eine unnormalisierte Relation vor, in der drei Oder mehr Attribute Mehrfacheintrage aufweisen^^. In einem solchen Fall konnte man auf die Idee kommen, diese Mehrfacheintrage einfach durch Tupelvermehrung gegeneinander aufzulosen. Dabei entsteht aber eine Relation mit Strukturdefiziten, die von den bisherigen Normalformen nicht erfasst werden. Dazu ein Beispiel. Gegeben sei die folgende unnormaliserte Relation, mit der die Beziehungen zwischen Online-Datenbanken, ihren Anbietern und ihren Produzenten in einer Tabelle erfasst werden. Es gilt folgende Semantik: Eine Online-Datenbank kann bei mehreren Hosts aufliegen (von diesen der Offentlichkeit angeboten werden) und sie kann von mehreren Produzenten gemeinsam erstellt worden sein.

D.h., sie sind nicht flach (vgl. oben). Einige Autoren verwenden auch den Begriff Wiederholungsgruppen, vom angelsachsischen repeating groups.

3.19 Die vierte Nornnalform (4NF)

99

ODB UN 1 NameODB D1 D2 D3 • • •

NameHost H1,H2 H1 H1,H3

NameProd 1 P1,P2 P2 P3

Bedeutung der ersten Zeile: Online-Datenbank Dl wird von den Hosts HI und H2 angeboten und von den Produzenten PI und P2 hergestellt. Bedeutung der zweiten Zeile: Online-Datenbank D2 wird von HI angeboten und von P2 hergestellt. Bedeutung der dritten Zeile: Online-Datenbank D3 wird von HI und H3 angeboten und von P3 hergestellt.

Wird diese unnormalisierte Tabelle nun mittels Tupelvermehrung in die INF gebracht, mussen die Mehrfacheintrage miteinander kombiniert werden^ \ nur dann bleibt die Information der unnormalisierten Relation erhalten. Dann entsteht folgende Relation: ODB BCNF 1NameODB D1 D1 D1 D1 D2 D3

NameProd 1 NameHost P1 H1 P2 H1 P1 H2 P2 H2 P2 H1 P3 H1 P3 1 H3 |D3 Schlussel: #(N ameODB, NanneHost, Namel In dieser haben die Tupel folgende Bedeutung: • • • •

Tupel 1: Dl Tupel 2: Dl Tupel 3: Dl Tupel 4: Dl

wird von HI angeboten und PI produziert wird von HI angeboten und von P2 produziert wird von H2 angeboten und von PI produziert wird von H2 angeboten und von P2 produziert.

usw. Diese vier Tupel werden benotigt, um den Informationsgehalt des ersten Tupels der ODB-UN zu erfassen (1 * 2 * 2 = 4). Es ist leicht zu sehen, dass eine solche Relation nur Schwierigkeiten bereitet. Trotzdem ist sie in BCNF, da alle Attribute Schlusselattribute sind („all key") und die Regeln der BCNF gegeniiber einer solchen Situation nicht greifen. Die Redundanz ist offensichtlich: dass Dl von HI angeboten wird, ist nicht nur einmal erfasst, sondem mehrmals (fur jeden Produzenten). Ebenso wird die Tatsache, dass Dl von PI produziert wird, mehrfach erfasst (Zahl der Anbieter). Mittels des kartesischen Produkts.

Redundanz

100

3 Modellierung Relationaler Datenbanken

Die Komplexitat entsteht durch die Bildung der Relation aus dem kartesischen Produkt der Auspragungen mit Mehrfacheintragen. Dadurch "lastet" auf ihr eine komplexe Kegel: Falls (Dl, HI, PI) und (Dl, H2, P2) beide da sind, mlissen auch (Dl, HI, P2) und (Dl, H2, PI) vorkommen. Dies resultiert aus der Entstehung der Relation durch Tupelvermehrung. Aus dem ersten Teil der Regel folgt, dass in der unnormalisierten Ursprungsrelation die nachfolgend aufgefuhrte Zeile vorhanden war: 1 NameODB |DI

NameHost H1,H2

1 NameProd 1 |P1,P2 1

Deirn diese fiihrt zu folgenden Kombinationen:

'PI H,<; Dl

'PI H2<: .p2

War diese aber vorhanden, mussen (wegen der Bildung des kartesischen Produkts aus (HI, H2) x (PI, P2) auch die Tupel (Dl, HI, P2) und (Dl, H2, PI) vorhanden sein. Es ist leicht vorstellbar, dass eine solch komplexe Regel (eine semantische Integritatsbedingung) im Zeitverlauf kaum aufrechterhalten werden kann. Bei jedem neuen Eintrag, der entweder mehrere Hosts oder mehrere Produzenten aufweist muss ja nicht nur ein Tupel, sondem es miissen mehrere eingetragen werden. Wird zum Beispiel Dl zusatzlich von einem Produzenten P3 hergestellt, miissen die Tupel (Dl, HI, P3) und (Dl, H2, P3) zusatzlich eingetragen werden. Auch hier besteht die Losung wiederum in einer Zerlegung der Relation. Mit den obigen Abkurzungen wird ODB-BCNF in die zwei Relationen 0DB-H0ST_4NF (#(NameODB, NameHost)) und 0DB-PR0D_4NF (#(NarneODB, NameProd)) zerlegt. 0DB-H0ST_4NF erfasst nun die Beziehung zwischen OnlineDatenbanken und ihren Anbietem („welcher Anbieter hat welche OnlineDatenbank im Angebot). 0DB-PR0D_4NF erfasst die Beziehung zwischen Online-Datenbanken und ihren Produzenten („welcher Produzent stellt welche Online-Datenbank her").

3.19 Die vierte Normalform (4NF)

101

ODB-Host 4NF 1 NameODB~NameHost] H1 D1 D4m H2 D1 H2 D4H1 D2 H1 D3 H3 1 |D3 NameODB, f SchlQssel: #( ODB Prod 4NF 1 NameODB"NameProd 1 P1 D1 P2 D1 D4P4P2 m P2 D2 D3 P3 P3 ea Schlussel: #{ NameODB, t Die durchgestrichenen Zeilen zeigen wiederum die Redundanz der ursprunglichen Relation ODB-BCNF. Die Kennzeichnung von NameODB als FremdschlUssel (durch Unterstreichung) hat nicht genau dieselbe Bedeutung wie sonst, da (hier) ja die Relation fehlt, die Online-Datenbanken beschreibt und in der NameODB SchlUssel ware. Sie wurde trotzdem gewahlt, well die beiden Attribute Fremdschliisselcharakter haben. Allerdings ware eine direkt Verkniipfung problematisch, weshalb im folgenden Datenmodeil eine Relation ODB erganzt wurde. Diese konnte, vgl. die in den obigen Abschnitten vorgestellten Beispiele zu diesem Weltausschnitt, Attribute wie GroBe, Sprache, usw. haben.

102

3 Modellierung Relationaler Datenbanken

ODB HOST 4NF

ODB PROD 4NF

#(NameODB, NameHost)

#(NarneODB, NameProd)

ODB

V

••#NameODBAbbildung 3.19-1: Regel

Mehrwertige Abhangigkeit

Relationales Datenmodell

ONLINE-DATENBANKEN

Wegen der hier diskutierten Probleme mit mehrfachen Wiederholungsgruppen weist Date darauf bin, dass bei der Normalisierung einer unnormalisierten Relation auf jeden Fall zuerst die voneinander unabhangigen Wiederholungsgruppen getrennt werden sollten [Date 1986, S. 383]. Ftir die Definition der vierten Normalform (4NF), in der eine solche Konstellation beseitigt ist, muss nun eine weitere Form der Abhangigkeit zwischen den Attributen einer Relation eingefuhrt werden, die sog. mehrwertige Abhangigkeit (MWA) (multi-valued-dependency (MVD)). Manche Attribute A und B einer Relation stehen in folgender Beziehung zueinander: Kennt man eine Auspragung von A, kann man zwar nicht genau eine (einzige) von B "vorhersagen" (dies ware eine funktionale Abhangigkeit), aber eine genau defmierte Menge von Auspragungen von B. Beispiele hierfur sind leicht zu fmden: •

•

•

in einer Relation zu Online-Datenbanken: a) kennt man den Namen eines Hosts, kann man zwar nicht genau eine Online-Datenbank nennen, die er anbietet, aber eine genau defmierte Menge, namlich sein aktuelles Angebot. b) kennt man den Namen einer Online-Datenbank kann man zwar nicht in alien Fallen einen Produzenten nennen, aber eine Liste von Produzenten, die diese Datenbank herstellen (wir gehen davon aus, dass eine Online-Datenbank von mehreren Produzenten hergestellt werden kann). Beide Falle liegen dem obigen Beispiel zugrunde. in einer Relation zu den Angestellten einer entsprechenden Firma: Vom Namen eines Angestellten kann nicht eine einzelne von ihm beherrschte Programmiersprache genannt werden, aber eine Liste, namlich genau die der von ihm beherrschten. in einer Relation zu Datenbanksystemen: Da ein DBS mehrere Datentypen hat, gilt auch hier eine solche Beziehung, da vom Namen eines Datenbanksystems zwar nicht auf einen Datentyp, aber auf eine wohldefmierte Menge von Datentypen geschlossen werden kann.

3.19 Die vierte Normalform (4NF)

103

Es geht also im ersten Schritt schlicht darum, dass zwei Mengen so in Beziehung stehen, dass mehrere Elemente der einen Menge mit jeweils einem der anderen in Beziehung stehen. Aus der Sicht der Abhangigkeiten zwischen Attributen bedeutet dies, dass nicht eine Auspragung genannt werden kann, aber eine genau definierte Menge. Eine solche Form der Abhangigkeit zwischen Attributen wird mehrwertige Abhangigkeit (MWA) genannt.

Mehrwertige Abhangigkeit

Exkurs: Abhangigkeiten zwischen den Attributen einer Relation Attribute einer Relation stehen miteinander in Beziehung. Mit der obigen mehrwertigen Abhangigkeit sind folgende Beziehungen moglich: Unabhangigkeit (die Auspragungen der beiden Attribute sind unabhangig voneinander. Jede Auspragung beschreibt eine eigenstandige Eigenschaft). - voile und einfache funktionale Abhangigkeit transitive Abhangigkeit - mehrwertige Abhangigkeit In einer Relation schlagt sich dies in der Form von Mehrfacheintragen bei einem der Attribute nieder. Diese Form der Abhangigkeit zwischen zwei Attributen einer Relation ist somit etwas weiter als die der funktionalen Abhangigkeit, aber deutlich enger als die der Unabhangigkeit zweier Attribute (dann ist uberhaupt keine "Vorhersage" moglich ist). Schwierigkeiten bereitet diese Art der Abhangigkeit nur, falls sie doppelt in einer unnormalisierten Relation vorkommt. Dann miissen mindestens drei Attribute A, B und C im Spiel sein und zwei davon stehen in der beschriebenen Abhangigkeit vom dritten (wie im obigen Beispiel). Dennition 3.19-1: Mehrwertige Abhangigkeit (MWA) Seien A, B, C Attribute einer Relation R. B heiBt mehrwertig abhangig von A, in Zeichen: Ac =>=> B falls fur jede Kombination von Attributsauspragungen von A, C eine wohldefmierte Menge von Auspragungen von B existiert, die von A, aber nicht von C abhangt. Es gilt dann auch: AB = ^ ^ C Am leichtesten veranschaulicht man sich die Definition anhand des obigen Beispiels. Hier gih NameODBNameProduzent =>=^ NameHost NameODBNameHost =>=> NameProd

Das tiefgestellte Attribut wird mit angegeben, um deutlich zu machen, dass die MWA nur dann gegeben ist, wenn drei Attribute im Spiel sind, denn nur dann treten die beschriebenen Schwierigkeiten auf Jede funktionale Abhangigkeit ist auch eine Mehrwertige Abhangigkeit (eine, bei der nur ein "Treffer" vorliegt). Wir wollen im folgenden mehrwertige Abhangigkeiten, die keine funktionalen Abhangigkeiten sind, als echte Mehrwertige Abhangigkeiten bezeichnen.

EchteMWA

104

3 Modellierung Relationaler Datenbanken

Eine Relation mit einer echten Mehrwertigen Abhangigkeit hat die beschriebenen Strukturdefizite, die durch einen weiteren Normalisierungsschritt beseitigt werden, der zur vierten Normalform (4NF) fiihrt. Dies geschieht so, dass aus jedem Attribut mit Mehrfacheintragen zusammen mit dem Schliissel eine neue Relation gebildet wird: Waren A, B und C die Attribute mit Ac =>=^ B und AB =>=> C, dann kann die Relation in die zwei Relationen Ri(A,B) und R2(A,C) zerlegt werden. Die so entstehenden Relationen befinden sich dann in vierter Normalform. Definition 3.19-2: Vierte Normalform (4NF) Eine Relation R ist in 4NF, falls sie in BCNF ist und falls sie keine echten mehrwertigen Abhangigkeiten aufweist. Gleichwertig ist die folgende Definition nach [Date 1990, S. 558]: Definition 3.19-3: Vierte Normalform (4NF) Eine Relation R ist in 4NF, falls alle Mehrwertigen Abhangigkeiten in R auf den Schliisseln von R basieren. Wie oben ausgefuhrt, treten die Probleme nur auf, wenn zwei Attribute mit Mehrfacheintragen auftreten. Liegt nur ein solches vor, wird die Tabelle einfach flach gemacht, z.B. durch Tupelvermehrung (vgl. oben). Probleme mit der 4NF konnen also nur auftreten, wenn eine echte Mehrwertige Abhangigkeit durch Tupelvermehrung aufgelost wurde. Umgekehrt: Liegt keine echte MWA vor, konnen die Strukturdefizite, die zu Problemen mit der 4NF flihren, nicht vorliegen.

3.20 Relationale Operatoren bzw. Operationen

Verbund (Join)

Beispiel

Bevor die abschlieBende fiinfte Normalform (5NF) besprochen werden kann, werden die beiden Begriffe Verbund und Projektion benotigt. Diese beschreiben zwei sog. Relationale Operatoren (oder Operationen). Ein Verbund zwQiQY Relationen ist die relationale Verkntipfimg auf der Basis der Auspragungen zweier Attribute (meist Schliissel / Fremdschliissel, vgl. auch Abbildung 3.5-1). Dabei werden die Tupel einer Relation A mit denen einer Relation B zu neuen Tupeln zusammengefiigt, falls sie in einer bestimmten Attributsauspragung tibereinstimmen. Im folgenden Beispiel gehe es in ANG-PS um Programmiersprachenkompetenz, in ANG_PROJEKTE um die Mitarbeit in Projekten.

3.20 Relationale Operatoren bzw. Operationen

105

ANG-PS JName 1 Kunze Kunze Bauer Muller Mtiller Muller Muller

TS

1

COBOL C FORTRAN PASCAL C C++ FORTRAN

SchlQssel: #(Name, PS) ANG-PROJEKTE 1 Name Projekt 1 1 Bauer A Bauer B Muller B Muller C 1 Muller D Schlussel: #(Name, Projekt) Ein Verbund dieser zwei Relationen tiber das Attribut Name fiihrt dazu, dass alle Tupel aus ANG-PS nacheinander abgeglichen werden mit den Tupehi der Relation ANG-PROJEKTE. Tritt in ANG-PROJEKTE derselbe Name auf, wird ein neues zusammengesetztes Tupel aus alien Attributen beider Relationen gebildet. Findet sich ein Name in der zweiten Relation nicht, entsteht kein neues Tupel. Die neuen Tupel werden zu einer Ergebnisrelation ANG-PS-PROJEKTE zusammengefasst:

3 Modellierung Relationaler Datenbanken

106

ANG-PS-PROJEKTE Name iPS 1 FORTRAN Bauer FORTRAN Bauer PASCAL Mijller PASCAL Mijller PASCAL MiJller C MUller Muller c Muller c Muller C++ B Muller C C++ Muller C++ Muller FORTRAN B MUller FORTRAN C Muller FORTRAN 1 D Schlussel: #(PersNr, PS) Projekt A B B C D B C

p

p Verbinden, was (temporar) zusammengehort.

Kunze taucht hier nicht mehr auf, weil er in keinem Projekt mitwirkt. Genau diese Operation wird in SQL standig benotigt^^, da sie temporar Relationen wieder zusammenfugt, die vielleicht vorher im Rahmen der Normalisierung getrennt wurden. Hier die Definition des Verbundes. Es handelt sich hier um den sog. naturlichen Verbund. Dennition 3.20-1: (natiirlicher) Verbund (natural join) Seien A 1 , A 1 , . . . , A 1 Attribute einer Relation Rl und A2 , A2 , l'

2'

'

n

l'

2'

...,A2 .die Attribute einer Relation R2. n

Ein natiirlicher Verbund von Rl und R2: Rl VERBUND R2 ist eine Relation, die aus der relationalen Verknupfung von Rl und R2 iiber eine Attributkombination AKx entsteht (AKx e {Al , Al , ...,AlJ,AKxe{A2^,A2^,...,A2^.}). Projektion

Wesentlich einfacher ist die relational Operation, die Projektion genannt wird. Sie besteht lediglich darin, bestimmte Attribute (Spalten) einer Relation zu streichen, so dass als Ergebnis eine „schlankere" Relation entsteht. Sollten dabei gleiche Tupel entstehen, werden diese gestrichen. Beispiel: Eine Projektion der obigen Relation ANG-PS-PROJEKTE auf die Attribute Name und Projekt fuhrt zu folgender Relation ANGPROJEKTE REDUNDANT:

Sie wird dort mit Hilfe der WHERE-Klausel in den verschiedenen entsprechenden Befehlen reaiisiert.

3.21 Die funfte Normalform (5NF)

107

ANG-PROJEKT-REDUNDANT Projekt A B B C D B G B 8 G B B G B

Name Bauer Bauer Muller Muller Muller Muller Mu4teF Muller Muller MtWIer AMtef Muller Muller Muller

Werden die identischen Tupel geloscht (identische Tupel gibt es in Relationen nicht!) entsteht ANG-PROJEKTE: ANG-PROJEKTE 1 Projekt Name 1 A Bauer 1 Bauer B Muller B Muller 0 Muller 1 D Schlussel: #(Projekt, Name)

Definition 3.20-2: Projektion Seien A , A , ...,A Attribute einer Relation R. Bin Projektion von R auf Ai, A2, ..., Am (m
3.21 Die funfte Normalform (5NF) Bis jetzt fuhrten die Normalisierungen meist zu einer Zerlegung einer Relation in zwei andere. In bestimmten Fallen kann es geschehen, dass eine Relation ohne Informationsverlust nicht in zwei, aber in drei oder mehr Relationen zerlegt werden kann. Diese Eigenschaft wird n-Zerlegbarkeit genannt:

108

3 Modellierung Relationaler Datenbanken

Definition 3.21-1: n-Zerlegbarbarkeit Eine Relation heii3t n-zerlegbar, falls sie ohne Informationsverlust in n Relationen zerlegt werden kann, nicht aber in m (m < n). Das Phanomen der n-Zerlegbarkeit bezieht sich auf Beziehungen, die uber mehr als zwei Attribute greifen. Beispiel

Das folgende Beispiel moge dies verdeutlichen. Relation H_0_U erfasst die Beziehungen zwischen Hosts (Anbietern von Online-Datenbanken), Online-Datenbanken und Untemehmen (Nutzern von Online-Datenbanken). In diesem Weltausschnitt ist es so, dass ein Untemehmen, das auf eine Online-Datenbank zugreifen mochte, dariiber einen Vertrag mit einem Host abschlieBen muss. Da viele Online-Datenbanken bei mehreren Hosts aufliegen, hat ein Untemehmen durchaus die Wahl, Uber welchen Host es auf eine bestimmte Datenbank zugreift. Relation H_0_U 1 HostName Host1 Host2 Host2 Host2 Hosts

ODBName 0DB1 0DB1 0DB2 0DB3 0DB2

UntName 1 U1 U1 U2 U2

U2

1

Das erste Tupel bedeutet somit: Untemehmen Ul greift auf die OnlineDatenbank ODBl Uber den Datenbankanbieter Hostl zu. Das zweite Tupel gibt an, dass Ul zusatzlich noch bei Host2 auf ODBl zugreift (z.B. um bestimmte zeit- oder mengenabhangige Tarife zu nutzen). Zusatzlich zu den gmndlegenden Regeln dieses Weltausschnitts soil auch noch gelten: Kegel

Falls Host X die Online-Datenbank y anbietet UND Host X einen Vertrag mit dem Untemehmen z hat UND Untemehmen z die Online-Datenbank y im Zugriff hat dann hat Untemehmen z Zugriff auf die Online-Datenbank y Uber Host x. Diese Bedingung kann, muss aber nicht unbedingt erfiillt sein (wovon man sich leicht Uberzeugt) und sie hat Konsequenzen: Sollte Ul zusatzlich auf 0DB3 zugreifen, dann erst mal Uber Host2, da Host2 diese Datenbank anbietet und Ul einen Vertrag mit Host2 hat, usw. Nicht zulassig als einzelner weiterer Eintrag ware dann HostS, 0DB3, Ul! Diese komplexe Semantikfestlegung setzt also nicht nur die Auspragungen eines Tupels miteinander in Beziehung, sondem auch mehrere Tupel untereinander. So etwas war in den bisher betrachteten Normalformen nicht betrachtet worden.

3.21 Die funfte Normalform (5NF)

109

Es ist leicht vorstellbar, dass eine solche Relation nur schwer konsistent gehalten werden kann, obwohl sie alle bisher besprochenen Normalformen erfuUt: Sie befindet sich in 4NF. Die Losung liegt wiederum in einer Zerlegung. Jetzt jedoch nicht in zwei sondem in drei bzw. im allgemeinen Fall in n Relationen. Wann kommt es zu einer solchen - zugegeben etwas konstruierten - Situation? Sie liegt genau dann vor, wenn die Relation dem Verbund von einigen ihrer Projektionen entspricht bzw. wenn ihre Entstehung so gedacht werden kann. Dies soil an obigem Beispiel gezeigt werden. Die folgenden Relationen HO, HU und OU sind Projektionen dieser Relation H__0_U. Relation HO 1 HostName ODBName1 0DB1 Host1 0DB1 Host2 0DB2 Host2 Host2 0DB3 0DB2 Hosts #(HostName, ODBName) Relation HO druckt das Verhaltnis zwischen Hosts und Online-Datenbanken aus: Welcher Host bietet welche Online-Datenbank an? Relation HU 1 HostName UntName 1 U1 Host1 U1 Host2 U2 Host2 U2 1 Hosts #(HostName , UntName) Relation HU driickt das Verhaltnis zwischen Hosts und Untemehmen aus: Welche Vertragsverhaltnisse (iiber die Nutzung von Online-Datenbanken) zwischen Hosts und Untemehmen gibt es? Relation OU

1 ODBName UntName 1 0DB1 U1 0DB2 U2 ODBS U2 #(ODBName, UntName) Relation OU driickt das Verhaltnis zwischen Online-Datenbanken und Untemehmen aus: Welche Online-Datenbanken nutzen die einzelnen Untemehmen?

110

3 Modellierung Relationaler Datenbanken

Diese drei Projektionen driicken nun Einzelaspekte der Information aus, die in H__0_U gespeichert ist. Ein Verbund von Relation HO und Relation HU uber HostName fiihrt zu Relation HO HU: Relation HO._HU 1 HostName ODBName 0DB1 Host1 0DB1 Host2 0DB1 Host2 0DB2 Host2 0DB2 Host2 0DB3 Host2 0DB3 Host2 0DB2 Hosts #(HostName, ODBName,

UntName 1 U1 U1 U2 U1 U2 U1 U2 U2 UntName)

Dieser Verbund fasst also die Aussagen von Relation HO und HU durch die Tupelverkntipfung zusammen: auf welche Online-Datenbanken greifen die Untemehmen iiber welchen Host zu. Ein weiterer Verbund von Relation HO_HU mit Relation OU iiber (ODBName, UntName) fuhrt zur Relation HO_HU_OU: Relation HO._HU_OU 1 HostName ODBName 0DB1 Host1 0DB1 Host2 0DB2 Host2 ODBS Host2 0DB2 Hosts #(HostName, ODBName,

UntName 1 U1 U1 U2 U2 U2 UntName)

Dieser letzte Verbund wahlt konkret die Tupel aus HO_HU aus, die eines der Tupel(!) von OU enthalten. Diese stimmt mit Relation H_0__U uberein. Genau dann also, wenn die Relation so entstanden ist oder so entstanden gedacht werden kann, liegt eine Beziehung des beschriebenen Typs vor. Umgangssprachlich konnte diese semantische Integritatsbedingung so wie oben formuliert werden: Hat ein Host eine Datenbank im Angebot, auf die das Untemehmen zugreift und hat dieses Untemehmen einen Vertrag mit diesem Host, dann greift es auch iiber ihn auf diese Datenbank zu. Eine zwar naheliegende, in der Realitat aber nicht immer erftillte Bedingung, die immer dann entsteht, wenn eine Relation gleich dem Verbund einiger ihrer Projektionen ist. Mit den beiden Begriffen Verbund und Projektion kann nun die Definition der Verbund-Abhangigkeit angegeben werden:

3.21 Die funfte Normalform (5NF)

111

Definition 3.21-2: Verbund-Abhangigl^eit (VA) Seien T die Menge der Attribute einer Relation R und AKi, AK2 c T, d.h. AKi = {An, A21, A31, ..., A^i}, AK2 = {A12, A22, A32, ..., An2}.

R ist verbund-abhdngig, in Zeichen * (AKi, AK2, ..., AKn) falls R gleich dem Verbund seiner Projektionen auf AKi, AK2, ..., AKn ist. Werden diese Verbund-Abhangigkeiten (zwischen Nichtschltisseln) beseitigt, entstehen Relationen in der fiinften Normalform: Definition 3.21-3: Fiinfte Normalform (5NF) Sei R eine Relation. R ist in der 5NF, falls jede VERBUND-Abhangigkeit in R durch SchlUssel von R verursacht wird. D.h., durch Schliissel werden natiirlich Verbund-Abhangigkeiten definiert, die aber keine Probleme aufwerfen. Hierzu ein Beispiel. Die Relation ANGESTELLTe beschreibt Mitarbeiter eines Untemehmens:

Beispiel

ANGESTELLTE (#PersNr, Abteilung, Name, Vorname, Alter) Sie konnte durch folgenden Verbund entstanden sein: *((#PersNr, Abteilung), (#PersNr, Name, Vorname, Alter)) Oder durch: *((#PersNr, Abteilung), (#PersNr, Name), (#PersNr, Vorname), (#PersNr, Alter)) Ein Verbund mit Hilfe von Schltisselattributen ist aber problemlos, da jedem Schliisselwert der einen ein Schlusselwert der anderen entspricht. In die Ergebnisrelation kommen auf diese Weise auch nur die Tupel der verschiedenen Relationen, die einen gemeinsamen Schlussel haben. Das Beispiel macht auch deutlich, dass die Verbund-Abhangigkeit die ganz normale funktionale Abhangigkeit mitumfasst. Denn wenn der jeweilige Schliissel ein solcher ist, liegen funktionale Abhangigkeiten zwischen ihm und den NSA vor. Erfolgt der Verbund uber Schlussel, werden demzufolge Attribute zusammengefiihrt, die von demselben Schliissel funktional abhangig sind. Wie leicht gezeigt werden kann gilt damit: Jede Relation in 5NF ist auch in 4NF. Denn wenn die Relation aus einem Verbund mit Hilfe von Schliisseln entstanden ist, konnen keine mehrwertigen Abhangigkeiten vorliegen. Normalformen sind beziiglich einer Operation (bzw. beziiglich zweier in Beziehung stehender Operationen) defmiert. Die hier betrachteten bezogen sich auf die oben vorgestellten Verbund/Projektion - Operatoren.

Letzte denkbare Normalform

112

Normalisierung - wie weit

3 Modellierung Relationaler Datenbanken

Date weist darauf hin, dass die 5NF die letzte denkbare Normalform bezuglich der Verbund/Projektion-Operation ist [Date 1986, S. 390]. In der Praxis spielt die 5NF so gut wie keine Rolle. Eine VerbundAbhangigkeit ist auch nicht ohne weiteres zu erkennen, denn selbst wenn alle Eintrage einer Relation angegeben sind, und die vorliegenden Daten die oben angegebene Regel einhalten, muss sie ja nicht gelten. Wenngleich es nicht immer sinnvoll ist, alle Normalisierungsschritte tatsachlich durchzufuhren, verhilfl die Kenntniss der Normalisierungstheorie doch zu einem besseren Datenmodell und zu einem tieferen Verstandnis der attributbasierten Modellierung, die hier mit den Normalisierungsstufen einen ihrer Hohepunkte erlebt. Auf jeden Fall ist die Realisierung der BCNF und die Verhinderung einer Mehrwertigen Abhangigkeit zu empfehlen, so dass die 4NF immer sichergestellt ist. Hier noch etwas zum Nachdenken: In [Date 1990, S. 558] finden sich folgende elegante Definitionen der drei hoheren Normalformen:^^ • • •

A relation R is in BCNF if and only if every FD in R is a consequence of the candidate keys of R A relation R is in 4NF if and only if every MVD in R is a consequence of the candidate keys in R A relation R is in 5NF if and only if every JD in R is a consequence of the candidate keys of R.

3.22 Die theoretische Fundierung des Relationenbegriffs Formale Definition

Formal beruht das relationale Datenmodell auf dem mathematischen Relationenbegriff, der Mengenlehre und dem Pradikatenkalkiil. Ein relationales Modell besteht dabei aus einer (nicht-hierarchischen) Sammlung von n-stelligen Relationen. Alle Objekte und Beziehungen werden durch n-stellige Relationen reprasentiert. Eine Datenbank ist (aus dieser Sicht) wie folgt definiert: Definition 3.22-1: Relationale Datenbank Eine Relationale Datenbank ist eine endliche Menge von inhaltlich zusammenhangenden^'* endlichen Relationen. Mit endlicher Relation ist gemeint, dass die Zahl aller Tupel (die Extension der Relation) endlich ist.

FD = functional dependency =funktionale Abhangigkeit = FA; MVD = multi-valued dependency =mehrwertige Abhangigkeit =MWA; JD= join dependency = VerbundAbhangigkeit = VA; candidate key = Schlussel. ^'^ D.h., sie beschreiben denselben Weltausschnitt.

3.22 Die theoretische Fundierung des Relationenbegriffs

113

Der Begriff der "Relation" kommt aus der Mengenlehre. Seine Verwendung in der Datenbanktheorie und -praxis zur Modellierung von Realitat fur die maschinelle Informationsverarbeitung mutet oft uberraschend an. Deshalb soil er hier, ausgehend von der mathematischen Definition bis zu seiner Auspragung in der Datenbanktheorie, dargestellt werden. Vorab einige Definitionen, die in dieser formalen Fassung am Beginn dieses Kapitels nicht angegeben wurden: Definition 3.22-2: Wertebereich Ein Wertebereich (domain^^) D ist (im Datenbankkontext) eine endliche Menge von Begriffen, die zur Erfassung von Eigenschaften bzw. zur Benennung von Objekten dienen.

Wertebereich

Einige einfache Beispiele: {Relationales Datenbanksystem, Objektorientiertes Datenbanksystem, Hierarchisches Datenbanksystem, Netzwerkdatenbanksystem, Information Retrieval System} zur Erfassung verschiedener Typen von Datenbanksystemen. {10.000,- DM, 1.500,- DM, 2.800,- Euro} zur Erfassung der konkreten Preise von Datenbanksystemen. {COBOL, FORTRAN, C, PASCAL, SMALLTALK, PROLOG} zur Erfassung von Programmiersprachen. {INGRES, INFORMIX, Visual dBase, Paradox, FoxPro, Access} zur Benennung von Datenbanksystemen. Die zweite Definition klart das kartesische Produkt zweier Wertebereiche. Definition 3.22-3: Kartesisches Produkt von Wertebereichen Das kartesische Produkt der Wertebereiche D,, ..., D wird mit D^*D:'2

1'

^

'

n

* D bezeichnet und besteht aus der Menge aller Tupel

(Xp X2,..., x^), so dass fur jedes i (i=l, ...,n) gilt:

(X.GD.)

Ein einfaches Beispiel: Seien D ={a,b,c}, D ={x,y}. Dann besteht das kartesische Produkt aus den Tupeln {(a,x), (a,y), (b,x), (b,y), (c,x), (c,y)}. Dieses kartesische Produkt zweier solcher Mengen lasst sich auch tabellarisch darstellen:

^^

Von diesem englischen Begriff kommt die Bezeichnung Domane fiir Wertebereich bei einigen deutschsprachigen Autoren.

Kartesisches Produkt

3 Modellierung Relationaler Datenbanken

114

Spaltel a a b b c c

Spalte 2 X

y X

y X

y

In einem (beliebigen) mathematischen Begriffsworterbuch findet sich die folgende Definition einer Relation: Relation mathematisch

Definition 3.22-4: Relation - mathematisch Es seien D , D ,...., D beliebige nichtleere Mengen und D * D^ *....* D deren kartesisches Produkt. Dann heiBt jede Unter1

2

-^

n

menge R desselben eine nstellige Relation. Gilt (x , x ,..., x ) G R mit X G D (t=l,..., n), dann stehen x . x^,..., x in der Relation R zueinant

t

1

2

n

der.

Beispiel

Besonders haufig tritt der Fall auf, dass es sich um genau zwei Mengen A und B handelt. In diesem Fall schreibt man xRy (x G A, y G B), wenn (x, y) G R c A X B, also xRy <^ (x, y) G R c A x B. Die Wertebereiche D. mussen nicht unbedingt verschieden sein. Auf diese Weise werden also aus Wertebereichen Relationen. Bevor wir dies voll in den Datenbankbereich ubertragen hier einige Beispiele. Das erste betrifft Datenbanksysteme und deren Produzenten. Es ist nattirlich gegeniiber der Realitat stark vereinfacht. Seien D^={Microsoft, Borland} und D2={Visual dBase, Paradox, Access, FoxPro}. Dann besteht das kartesische Produkt aus der Menge der Tupel: {(Microsoft, Visual dBase), (Microsoft, Paradox), (Microsoft, Access), (Microsoft, FoxPro), (Borland, Visual dBase), (Borland, Paradox), (Borland, Access), (Borland, FoxPro)}. In der Tabellendarstellung lassen sich diese Tupel wie folgt anordnen:

3.22 Die theoretische Fundierung des Relationenbegriffs 1 Spalte 1 1 Microsoft Microsoft Microsoft Microsoft Borland Borland Borland Borland

115

Spalte 2 1 Visual dBase 1 Paradox Access FoxPro Visual dBase Paradox Access Foxpro 1

Relationen im mathematischen Sinn bestehen nun aus Teilmengen dieser „Tupelmenge". Im weniger abstrakten Datenbankkonzept fragen wir uns nun, welche Teilmengen (=Relationen) dieser Tupel einen Sinn ergeben. Welche erfasst z.B. die Relation Firma besitzt und verkauft Datenbanksystem (Zeitpunkt Fruhjahr 2004). Welche Teilmenge konnte die Relation erfassen Firma wiirde gerne besitzenl Eine andere Relation konnte lauten: datenkompatible Datenbanksysteme. In dieser wurden die Tupel erfasst, bei denen die beiden Datenbanksysteme datenkompatibel sind. Damit diirfle klar sein, wohin der mathematische Relationenbegriff zielt und woher seine Tauglichkeit fur die Datenbanktheorie kommt. Bestimmte Teilmengen - Relationen - ergeben semantisch einen Sinn und genau die sind es, die zur Datenmodellierung benutzt werden. Ein weiteres Beispiel soil Datenbanksysteme und deren Datentypen betreffen: Seien

Semantisch sinnvoUe Teilmengen

Sinn

Beispiel

Di={BLOBS, MEMO, TEXT} und D2={INGRES, Visual dBase, INFORMIX}. D gibt also ausgewahlte Datentypen an, D Datenbanksysteme. Das kartesische Produkt ist: {(BLOBS, INGRES), (BLOBS, Visual dBase), (BLOBS, INFORMIX), (MEMO, INGRES), (MEMO, Visual dBase), (MEMO, INFORMIX), (TEXT, INGRES), (TEXT, Visual dBase), (TEXT, INFORMIX)} Einen Sinn ergibt natiirlich nur die Teilmenge, die tatsachlich festhalt, welches Datenbanksystem welche Datentypen hat. Eine Relation ist hier somit einfach defmiert als Teilmenge des kartesischen Produkts von Mengen. Wie kommt man hiervon zur iiblichen Tabellendarstellung einer Relation, zum Attributsbegriff, usw. Dies soil am folgenden, wiedemm fiktiven Beispiel erlautert werden. Gegeben seien zwei Mengen. Die erste besteht aus Anbietem von Online-Datenbanken: {DIALOG, WEFA, STN},

Beispiel

116

3 Modellierung Relationaler Datenbanken

die zweite aus Online-Datenbanken {COMPENDEX, CRONOS-FRIC, CRONOS-ICG, CAS}. Beides ist naturiich wiederum stark vereinfacht. Folgende Beziehung sei gegeben: DIALOG bietet nur COMPENDEX und CAS an, WEFA nur CRONOS-FRJC und CRONOS-ICG, STN nur CAS. Dann gilt also: D^ = {Menge der Hosts} = (DIALOG, WEFA, STN) D^ = {Menge der Online-Datenbanken) = (COMPENDEX, CRONOS-FRIC, CRONOS-ICG, CAS} Das kartesische Produkt ergibt sich mit (D^ * D^):

(DIALOG, COMPENDEX), (DIALOG, CRONOS-FRIC), (DIALOG, CRONOS-ICG), (DIALOG, CAS), (WEFA, COMPENDEX), (WEFA, CRONOS-FRIC), (WEFA, CRONOS-ICG), (WEFA, CAS), (STN, COMPENDEX), (STN, CRONOS-FRIC), (STN, CRONOS-FRIC), (STN, CAS). Eine Untermenge davon ist: R = {(DIALOG, COMPENDEX), (DIALOG, CAS), (WEFA, CRONOS-FRIC), (WEFA, CRONOS-ICG), (STN, CAS)}. Diese Untermenge hat die Bedeutung Host A bietet Datenbank B an, weil sie mit der Semantik des fiktiven Weltausschnitts ubereinstimmt. Andere Untermengen konnten die Tupel herausgreifen mit der Beziehung Host wiirde gerne anbieten oder besteht Vertrag bzgl Datenbank bei Host. Nicht alle Teilmengen besitzen Bedeutung fiir die Modellierung. Aber alle sinnvollen sind Untermengen des kartesischen Produkts und somit Relationen. Relationen drticken somit Beziehungen zwischen Begrijfen aus. Hinter den Begriffen stehen Objekte, Eigenschaflen, usw. Verandem wir nun etwas den Blickwinkel, indem wir die Tupel spaltenweise untereinander anordnen und tiber die Spalten Benennungen der Begriffe schreiben, ergibt sich folgende Darstellung: Datenbank 1 [Host COMPENDEX DIALOG CAS DIALOG CRONOS-FRIC WEFA CRONOS-ICG WEFA CAS STN Die Objekte von D^ sind jetzt Auspragungen des Attributs Host, die von D^ Auspragungen des Attributs Datenbanken. Diese Darstellung einer Relation ist der Grund dafur, dass in der popularen Literatur und in den Handbiichern der Datenbanksysteme meist von Tabellen die Rede ist, wenn Relationen gemeint sind. Dies ist nicht sehr

3.22 Die theoretische Fundierung des Relationenbegriffs

117

glUcklich, weil hinter einer Tabelle im relationentheoretischen Sinne mehr steht, als nur eine tabellarische Anordnung von Werten. Die zu Beginn des Kapitels angefuhrten Eigenschaften einer Relation sind nun unschwer nachvollziehbar: •

• •

• • •

In einer Spalte stehen nur die Objekte einer Menge, bzw. die Auspragungen eines Attributs. Im Spaltenkopf steht die Benennung der Menge bzw. der Attributsname. Im Kreuzungspunkt einer Spalte und Zeile kann nur jeweils ein Objekt, bzw. eine Merkmalsauspragung stehen. Jeder Begriff einer Spalte bezeichnet ein bestimmtes Objekt (und nur dieses), bzw. ist Auspragung eines Attributs (mit alien Konsequenzen). Alle Zeilen der Tabelle sind paarweise verschieden Jede Zeile (Tupel) beschreibt ein Objekt^^. Die Reihenfolge der Zeilen ist ohne Bedeutung

Die Identifizierung der Zeilen der Tabelle mit den Tupeln ist Ursache von Defmitionen, die Relationen als eine Menge von Tupeln beschreiben. Mit obigem konnen dann Attribute wie folgt definiert werden: Definition 3.22-5: Attribute Die Spalten einer Relation enthalten Attribute. Im Spaltenkopf steht der Attributsname, darunter die Attributsauspragungen. Die Attribute einer Relation sind normalerweise verschieden (nicht aber die Wertebereiche). Aus obigen Defmitionen ergibt sich: Die Auspragungen des Attributs der Spalte i einer Relation stammen aus dem Wertebereich D.. 1

Jetzt konnen auch die Begriffe Objekt- und Beziehungsklasse (entity type, relationship type) genauer gefasst werden. Aus den einzelnen Objekten bzw. Beziehungen bilden wir zum Zwecke der Datenmodellierung Objektklassen. Dabei werden genau die Objekte zu einer Klasse zusammengefasst, die als Tupel in einer Relation stehen (oben wurde formuliert: die durch dieselben Attribute beschrieben werden). Genau dasselbe gilt fur Beziehungen und Beziehungsklassen. Das einzelne Tupel einer Relation beschreibt (mit Einschrankungen) ein Objekt oder eine Beziehung. Die Menge der Tupel einer Relation beschreibt die zugehorige Objektklasse bzw. Beziehungsklasse. Durch die Verwendung des Relationenbegriffs konnen die in der Relationentheorie entwickelten Instrumente fur die Entwicklung von und die Arbeit mit Datenbanken Verwendung fmden. Dies betrifft vor allem die Standardabfrage- und -auswertungssprache fur Relationale Datenbanken SQL. Dies ist nur teilweise richtig, wie oben gezeigt wurde. Nach der Normalisierung ist es oft so, dass ein Tupel einer Relation nur Telle eines Objekts beschreibt.

Klasse (type)

118

3 Modellierung Relationaler Datenbanken

Relationen im oben beschriebenen Sinn sind das einzige im relationalen Datenmodell zur Modellierung des Realitatsausschnitts zur Verfiigung stehende Werkzeug. AbschlieBend nun noch die datenbanktheoretische Formulierung der Relationendefinition. Diese ist mehr oder weniger stark am mathematischen Relationenbegriff orientiert. Der Ausgangspunkt der Formulierung sind aber die auf den Objekten defmierten Attribute und Merkmale: Definition 3.22-6: Relation (datenbanktheoretisch) Seien A , A , ...,A Attribute mit den Wertebereichen W , W , ... , W . 1'

2'

'

n

r

2'

'

n

Eine Teilmenge R c W x W x . . . x W heifit n-stellige Relation Uber den Bereichen W , W ,..., W . Die Elemente r e R werden wie folgt bezeichnet: r = (a , a , ...,a ) mit (a. e W., i=l,...,n) n ist der Grad der Relation; r heiBt n-Tupel aus R.

3.23 Beispiel Rechnungsstellung Weltausschnitt Rechnungsstellung

Mit diesem Beispiel wird der Aufbau einer Datenbank fur den Zweck der Rechnungsstellung gezeigt. Ausgangspunkt ist dabei die in der folgenden Abbildung angegebene Rechnung^^, also ein Geschdftsobjekt (business object), was in der Datenmodellierung durchaus oft der Fall ist. Es gelten - neben der iiblichen kauftnannischen Semantik von Rechnungen - die folgenden Bedingungen und semantischen Festlegungen: • • • • • •

• •

Es gibt noch keine Kunden-Relation. Diese soil bei dieser Gelegenheit angelegt werden. In der Datenbank wird auch festgehalten, wer die Kundschaft bedient hat (Verkaufer). Dies wird auf der Rechnung ausgegeben. TOUR bezeichnet das Auslieferungsteam. KVDAT gibt den Tag an, an dem die Kundschaft im Mobelhaus war und die Ware bestellt hat. Eine Rechnung bezieht sich auf genau einen Auftrag Fiir jeden Kunden kann, muss aber nicht, zwischen einer Rechnungsund einer Lieferanschrift unterschieden werden. Eine Rechnungsanschrift hat jeder Kunde. Die angegebene Telefonnummer ist die der Rechnungsanschrift Die Abkurzungen bei Position 1 bedeuten: o 889999 Artikelnummer (Nr_Artikel) o B/OO/EG Standort der Ware im Lager (STAND) o COUCHTISCH 1906 EICHE NATUR - MIT LIFT 125x71 cm Beschreibung der Ware Urspriinglich eine reale, die fur diesen Zweck aber anonymisiert wurde.

3.23 Beispiel Rechnungsstellung

119

Hans Lebom GmbH + CO. KG |\/J/^Kz:i| Marienplalz 2

'VIUUt?l 1 ^ i ^ L-^ > 1 r - ^ l j ( ^ V * < ^ K«y \

88212 Ravensburg Telefon (0751) 99999 Telefax (0751) 88888

Herr Jose f Staud Am k a l t e n B a c h

Lieferanschrift Herr Josef Staud S u B w a s s e r 99

8888 B W a l d h a u s e n

99999

Dm

Sonnenbiichel

Telefon: TOUR: KVDAT:

07777/9999 16 18.01.04

RECHNUNG 1 Pos.

Anzahl

ES B E D I E N T E 1

2

3

SIE

HERR

889999 COUCHTISCH 1 9 0 6 E I C H E NATUR - M I T 1 2 5 X 7 1 CM

1

999888 SESSEL

2

999999 1

MWST-BETRAG

EZ-Preis

B/OO/EG

1

998.00

420.00

840.00

1212

A/02/EG

1220.00

2424

16.00

% :

489,28

Rechnungsbetrag

TAGEN M I T

Gescmlprels

LIFT

Zdhlunga/ereinbcfung

10

1

BLUME

A/Ol/EG ROBUSTA

999887 COUCH ROBUSTA

1

INNERHALB

26.02.04

1 Bezeichnung, Art Modell, AusfCihrung. Grcfie

Achlung: Bei Zohlung immer Rechnungsnummer angebeni

Rechnungsnummer

LieferVRechnungsdokim

3058.00

3 % SKONTO

l/tm/fechnung

Abbildung 3.23-1: Eine Rechnung (Typ Mobelhaus) Grundsatzlich und auch bei dieser Aufgabe ist zu beobachten, dass Modellierer versuchen, auch dynamische Aspekte (Verarbeitung der Daten) mit ins Datenmodell zu integrieren. Insbesondere solche Modellierer, die gerade Systemanalyse gehort haben. Dies ist falsch und geht auch nicht (vgl. zur grundsatzlichen Problematik statischer und dynamischer Aspekte auch Kapitel 7). Deshalb folgender Hinweis:

Nur Statik, keine Dynamik!

120

3 Modellierung Relationaler Datenbanken

Datenbanken liefern „nur" das informationelle Gerust fur die „auf ihr" ablaufenden Geschaftsprozesse. Es mussen also nicht Vorgange, Handlungen, usw. (dynamische Aspekte des Weltausschnitts) modeiliert werden, dies leistet die Systemanalyse, sondern „Strukturen" (statische Aspekte). Diese Aufgabe wird mit unterschiedlichem Komplexitatsgrad in drei Stufen gelost: •

•

•

Aufgabe Stufe 1

Aufgabe Stufe 1 - Grundstruktur: o Fiir jeden Kunden wird nur eine Anschrift, die Rechnungsanschrift, erfasst. o Es wird keine historische Komponente beriicksichtigt, d.h. alte Rechnungen mtissen nicht reproduzierbar sein. Aufgabe Stufe 2 - Adressen o Fiir jeden Kunden werden beliebig viele Adressen erfasst. Jede davon kann Rechnungs- oder Lieferanschrift sein. Bei jeder Rechnung kann eine beliebige Anschrift Liefer- bzw. Rechnungsanschrift sein. Aufgabe Stufe 3 - Zeitachse o Die Rechnungen sollen tiber die Zeit gerettet werden, d.h. es soil moglich sein, beliebige Rechnungen der Vergangenheit zu reproduzieren. Also z.B. eine Rechnung vom 20. November 1997 mit den damaligen Preisen, der damaligen Mehrwertsteuer, usw.

Fiir die Stufe 1 sammeln wir zuerst die Attribute ein und bestimmen die Determinanten und funktionalen Abhangigkeiten (ein bei Geschaftsobjekten sinnvolles Vorgehen): Name: des Kunden Vorname PLZ: der Rechnungsanschrift Ort StrafJe Telefon: die Angabe auf der Rechnung KNr: Kundennummer. Diese erganzen wir gleich, da die Erfassung der Kunden ohne eine Kundennummer nicht sinnvoll ist. RechnNr: Rechnungsnummer RechnDatum: Rechnungsdatum Verkaufer: die Angabe des Verkaufers erfolgt auf der Rechnung KVDAT: Hierbei handelt es sich um das Kaufvertragsdatum. TOUR: Dabei handelt es sich um die Angabe des Teams, das mit seinem Fahrzeug die Mobel ausliefert. Eine tiefere Semantik liegt nicht vor. PosNr: Rechnungspositionsnummer ArtikelNr: wird bei den Rechnungspositionen angegeben. Anzahl der Artikel pro Position

3.23 Beispiel Rechnungsstellung

• • • •

121

Stand: Standort der Ware im Lager. Wird bei den Rechnungspositionen angegeben. Beschreibung: der Ware, je Position ZV: Zahlungsvereinbarung Preis: Einzelpreis. Der Preis flir die gesamte Position wird berechnet aus Anzahl und Preis.

Der Mehrwertsteuersatz wird im Programm hinterlegt, der Mehrwertsteuerbetrag wird dann daraus und aus der Rechnungssumme berechnet. Was konnen wir nun, auch unter Berticksichtigung der ja immer vorliegenden Objekt-ZBeziehungsstruktur von den Attributen ableiten? Problemlos zu erkennen sind die Kunden, als Objekte, Objektklasse und als Relation. Identifiziert werden sie durch die KNr. Diese ist hier also erstmals Determinante. Voll funktional abhangig von dieser sind die folgenden Attribute: KNR => Name KNR=> Vorname KNR=>PLZ KNR => Ort KNR ^ StralJe KNRz^Telefon FUr die Adressangaben gilt dies nur, weil wir uns in Stufe 1 mit der Rechnungsanschrift begntigen. Damit ergibt sich die erste Relation: KUNDEN (#KNr, Name, Vorname, PLZ, Ort, Stralie, Telefon) Diese ist bereits in 5NF. Ahnlich einfach ist das Erkennen der Rechnung als Modellelement. Bei genauerem Hinsehen erkennt man aber, dass es eine Unterscheidung geben muss zwischen Rechnungskopf (identifiziert durch die RechnNr) und den Rechnungspositionen, denn es gibt pro Rechnung mehrere Positionen. Folgende fiinktionalen Abhangigkeiten bestehen von der Determinante RechnNr: •

• • • •

RechnNr ^^ RechnDatum: Es gibt genau ein Rechnungsdatum pro Rechnung bzw. von der Rechnungsnummer kann auf das Rechnungsdatum geschlossen werden. RechnNr ^ Verkaufer: Da immer nur einer fiir einen Kaufvertrag zustandig ist und nur einer auf der Rechnung erscheint. RechnNr =^ Tour: Es gibt ein Team je Rechnung. RechnNr ^ KVDAT: Es gibt hier genau ein Kaufvertragsdatum je Rechnung. RechnNr ^ ZV: Die Zahlungsvereinbarung ist je Rechnung eindeutig. Trotz Nachfragen konnte auch keine weitere Semantik (z.B. Abhangigkeit vom gekauften Produkt) festgestellt werden.

objekteund Beziehungen ^^"^^"

122

3 Modellierung Relationaler Datenbanken

Damit ergibt sich eine Relation RECHNUNGSKOPFE: RECHNUNGSKOPFE

(#RechnNr, RechnDatum, Verkaufer, Tour,

KVDAT) Auch diese ist in 5NF. Die letzten leicht erkennbaren Objekte sind die Artikel. Auch sie werden identifiziert (ArtikelNr) und beschrieben. ArtikelNr ist also Determinante mit folgenden funktional abhangigen Attributen: • • •

ArtikelNr => Beschreibung: Wir wollen die Beschreibungstexte als Attributsauspragungen auffassen. ArtikelNr => Preis: Da es sich um den Einzelpreis der Artikel handelt. ArtikelNr ^ Stand: Standort der Ware im Lager. Fur einen Artikel immer derselbe.

Dies fuhrt zu folgender Relation: ARTIKEL (#ArtikelNr, Beschreibung, Preis, Stand) Rechnungspositionen kaufmannische Semantik

Auch hier gibt es keinen VerstoB gegen die 5NF. Bleiben noch die ubrigen Attribute. Sie bewegen sich alle um die Rechnungspositionen herum. Ihre Verarbeitung macht bei ungeiibten Modellierem regelmaBig Schwierigkeiten. Hier muss erkannt werden, dass das zu modellierende Realweltphanomen (der Informationstrager) das kaufmannische Konstrukt der Rechnungspositionen ist. Wird dies erkannt, ist der Rest einfach. Rechnungspositionen werden durch eine Attributskombination identifiziert: (RechnNr, PosNr). Folgende funktionalen Abhangigkeiten bestehen: • •

(RechnNr, PosNr) => ArtikelNr: Da es (kaufmannische „Tiefensemantik"!) pro Rechnungsposition nur einen Artikel gibt. (RechnNr, PosNr) ^ Anzahl: Anzahl der Artikel je Position.

Damit ergibt sich folgende Relation, ebenfalls in 5NF: RECHNUNGSPOSITIONEN (#(RechnNr, PosNr), ArtikelNr, Anzahl) Alternativer Weg

Oftmals wird in Ubungen obige Relation tiber den Zusammenhang von Rechnung und Artikeln erkannt. Da es typischerweise pro Rechnung mehrere Artikel gibt und die Artikel auch auf mehreren Rechnungen auftauchen (ein bestimmtes Sofa, das hundert mal verkauft wurde) wird dabei dann zuerst eine Verbindungsrelation mit dem Schlussel (RechnNr, ArtikelNr) eingerichtet. Wenn dann die Modellierer die Bedeutung der Rechnungspositionen erkennen, wird dieser Ansatz schnell zur obigen Losung weiterentwickelt. Zuruck zur Aufgabe. Wir haben nun vier Relationen erkannt, die wesentliche Merkmale der Rechnung beschreiben. Zu priifen sind aber noch die Schlussel und Fremdschlussel, d.h. die relationalen Verknupfungen:

3.23 Beispiel Rechnungsstellung

•

•

•

• •

123

Zwischen KUNDEN und RECHNUNGSKOPFE: Hier liegt sicherlich eine Beziehung vor. Ein Kunde hat hoffentlich viele Rechnungen mit „unserem" Untemehmen, aber eine Rechnung bezieht sich immer nur auf einen Kunden (kaufmannische Semantik). Diese Im - Beziehung soil auf beiden Seiten die Min-/Max-Angabe 1,1 haben, weshalb sie einfach durch die Ubemahme der Kundennummer (KNr) in die Relation RECHNUNGSKOPFE festgehalten wird. Damit ware auch der erste Fremdschliissel geklart: RECHNUNGSKOPFE (#RechnNr, RechnDatum, Verkaufer, Tour, KVDAT, KNr) Zwischen KUNDEN und ARTIKEL: Hier gibt es auf der Ebene der Relationen keine direkte Beziehung. Die Beziehung manifestiert sich ja gerade durch die Rechnung und ihre Positionen. Zwischen KUNDEN und RECHNUNGSPOSITIONEN: Auch hier gibt es auf der Ebene der Relationen keine Beziehung. Die Verkntipflmg erfolgt liber die Rechnung. Zwischen RECHNUNGSKOPFE und ARTIKEL: Dieser Zusammenhang wird uber die RECHNUNGSPOSITIONEN hergestellt. Zwischen RECHNUNGSKOPFE und RECHNUNGSPOSITIONEN: Diese Beziehung ist nattirlich fundamental. Es ist eine l:n - Beziehung, denn eine Rechnung kann mehrere Positionen haben, eine Rechnungsposition gehort aber immer zu einer bestimmten Rechnung. Diese Beziehung wurde aber schon bei der Festlegung des Schliissels von RECHNUNGSPOSITIONEN festgelegt. Es muss lediglich noch die RechnNr als Fremdschliissel gekennzeichnet werden : RECHNUNGSPOSITIONEN (#(RechnNr, PosNr), ArtikelNr. Anzahl)

•

Zwischen ARTIKEL und RECHNUNGSPOSITIONEN: Hier liegt wiederum eine l:n - Beziehung vor. Ein Artikel kommt hoffentlich auf vielen Rechnungspositionen vor und eine Rechnungsposition erfasst genau einen Artikel. Die Min-/Max-Angabe von 1,1 auf der Seite der Rechnungspositionen ist hier besonders sinnvoll, denn es hat keinen Sinn, Rechnungspositionen ohne Artikel zu erfassen. Damit kann die Verknupfung durch Ubemahme der ArtikelNr in die Relation RECHNUNGSPOSITIONEN eingerichtet werden. Da dies oben schon geschehen ist (falls nicht, wiirde das Defizit spatestens hier erkannt), muss lediglich noch die Kennzeichnung von ArtikelNr als Fremdschliissel erfolgen: RECHNUNGSPOSITIONEN (#(RechnNr, PosNr), ArtikelNr. Anzahl)

Die funktionalen Abhangigkeiten in alien Relationen sind bereits geklart, da ja die Attribute so zu Relationen gruppiert wurden, dass jeweils ein Schltissel und die von ihm voll funktional abhangigen Attribute zusam-

idealstruktur

124

3 Modellierung Relationaler Datenbanken

men kamen. Da keine iiberlappenden Schlussel auftreten, ist die BCNF auch gesichert. Da daruber hinaus die in der vierten und funften Normalform angesprochenen Probleme nicht auftreten, befmden sich alle Relationen in 5NF. Die folgende Abbildung zeigt die grafische Darstellung des Datenmodells. RECHNUNGSPOSITIONEN

ARTIKEL

#fRechnNr. PosNr), ArtikelNr

#ArtikelNr

KUNDEN RECHNUNGSKOPFE

#KNr

r#RechnNr, KNr 7rr Abbildung 3.23-2:

Datenmodell

RECHNUNGSSTELLUNG

Hier noch die textlichen Notationen - im Zusammenhang: KUNDEN (#KNr, Name, Vorname, PLZ, Ort, StraBe, Telefon) RECHNUNGSPOSITIONEN (#(RechnNr. PosNr), ArtikelNr Anzahl) RECHNUNGSKOPFE (#RechnNr, RechnDatum, Verkaufer, Tour, KVDAT, KNr) ARTIKEL (#ArtikelNr, Beschreibung, Preis, Stand) Aufgabe Stufe 2 -Adressen

In Stufe 2 wird zwischen Liefer- und Rechnungsadresse unterschieden. Bin Kunde kann beliebig viele Adressen haben. Jede kann bei einer Rechnung Liefer- oder Rechnungsadresse sein. Die alte Relation KUNDEN fallt dann weg, da es mehr als eine Adresse pro Kunde gibt. Sie wird in die Relationen KUNDEN_STUFE2 und ADRESSEN aufgeteilt. Einmalig pro Kunde ist weiterhin KNr, Name, Vorname, so dass daraus die neue Kundenrelation entsteht: KUNDEN__STUFE2 (#KNr, Name, Vorname Adressen werden zu einer eigenen Relation. Wir erganzen einen Schlussel Adressnummer (AdressNr), denn einen Schltissel braucht jede Relation: ADRESSEN (#AdressNr, PLZ, Ort, Stralie, Telefon)

3.23 Beispiel Rechnungsstellung

125

Fehlt die Verknupfung. Diese ist n:m, denn ein Kunde hat ja mehrere Adressen und unter einer Adresse wohnen u.U. mehrere Kunden (Mehrfamilienhauser). Wir benotigen also eine Verbindungsrelation: KUNDEN-ADRESSEN_STUFE2 (#(KNr, AdressNr)) Beide Attribute wurden gleich als Frerndschliissel gekennzeichnet. Damit ist im Datenmodell die Beziehung zwischen Kunden und Adressen festgehalten. Bleibt noch zu klaren, wie beim Rechnungskopf festgehalten wird, welche Adresse Liefer- und welche Rechnungsadresse ist. Bisher war einfach die KNr als Fremdschliissel hinterlegt. Folgende Vorschlage werden an dieser Stelle in Modellierungsprojekten gemacht: •

Vorschlag 1: Zwei Attributskombinationen (KNr, LieferadressNr) und (KNr, RechnungsadressNr) in die Relation RECHNUNGSK O P F E . Beide waren dann Fremdschliissel. Da sie die KNr gemeinsam haben, konnte auch ein ilberlappender Frerndschliissel gewahlt werden: RECHNUNGSKOPFE (#RechnNr, RechnDatum, Verkaufer, Tour, KVDAT, (LieferadressNr. (KNr). RechnungsadressNr)

•

Dieser ist nicht sinnvoll, da dann in alien Fallen, in denen nur eine Adresse vorliegt, semantisch bedingte Leereintrage vorkommen^^. Vorschlag 2: Zwei Verbindungsrelationen zwischen RECHNUNGSKOPFE und KUNDEN. Eine fiir die Erfassung der Lieferadressen, eine fur die Erfassung der Rechnungsadressen: LIEFERADRESSEN (#(RechnNr. KNr)) RECHNUNGSADRESSEN (#(RechnNr. KNr))

•

Auch diese Losung ist nicht sinnvoll, da hier bei der Erstellung der konkreten Rechnung zwei Relationen flir die Feststellung der beiden Anschriften abgefragt werden miissen. AuBerdem wird die Information, dass eine bestimmte Rechnung Liefer- oder Rechnungsanschrift ist, in die Meta-Ebene, die Relationenbezeichnung verlegt. Vorschlag 3: Eine einzige Verbindungsrelation, die gleichzeitig die Liefer- und Rechnungsanschrift festhalt: LR-ADRESSEN (#(RechnNr, (KNr. AdressNr)). Adresstyp)

Leereintrage, die nicht durcli fehlende Daten, sondern durch fehlerhafte Erfassung der Semantik zustande kommen. Diese sind nicht erwunscht. Nach der Regel, dass genau die Attribute zusammengefasst werden, die dieselben Objekte beschreiben, ist dies auch von der Theorie aus nicht zulassig.

126

3 Modellierung Relationaler Datenbanken

Diese Losung ist sinnvoll, da eben in vielen Rechnungen nur eine einzige Anschrift angegeben ist (die dann gleichzeitig Liefer- und Rechnungsadresse ist), manchmal aber zwei. KNr und AdressNr sind zusammen(!) FremdschlUssel. Das Attribut Adresstyp hat die Auspragungen L(ieferadresse) und R(echnungsadresse). R gibt es immer, L nur, falls es eine extra Lieferanschrift gibt. Ansonsten ist die Rechnungsanschrift gleich der Lieferanschrift. Die folgende Tabelle zeigt zur Verdeutlichung einige Beispielsdaten: LR-ADRESSEN 1 RechnNr KNr 1001 1001 2002 9999

007 007 007 010

AdressNr

AdressTyp 1

2 5 1 1

L R R R

Hier noch das Gesamtmodell nach Stufe 2 in textlicher Notation: RECHNUNGSPOSITIONEN (#(RechnNr, PosNr), ArtikelNr. Anzahl) R E C H N U N G S K O P F E (#RechnNr, RechnDatum, Verkaufer, Tour, KVDAT) ARTIKEL (#ArtikelNr, Beschreibung, Preis, Stand) neu: KUNDEN_STUFE2 (#KNr, Name, Vorname) neu: ADRESSEN (#AdressNr, PLZ, Ort, StraUe, Telefon) neu: KUNDEN-ADRESSEN_STUFE2 (#(KNr, AdressNr)) neu: LR-ADRESSEN (#(RechnNr, (KNr AdressNr)). Adresstyp) Die Losung von Stufe 3 dieser Aufgabe wird im nachsten Abschnitt diskutiert.

3.24 Die Zeitachse in Datenmodellen und Datenbanken Grundsatzlich gilt, dass Datenmodelle, die mit dem in diesem Kapitel beschriebenen Instrumentarium erstellt werden, immer nur den aktuellen Stand der Daten berticksichtigen. Wenn es sich nicht um Daten handelt, die in der Transaktion entstehen und die damit automatisch zeitlich fixiert sind, dann konnen sie sich verandem und dann wird bei Erfassung der Anderung die alte Attributsauspragung uberschrieben. Dies gilt auch fiir das Beispiel des vorigen Abschnitts. Andert sich dort z.B. der Preis eines Artikels, wird der alte uberschrieben und steht (in der Datenbank) nicht mehr zur Verfugung. Dies kann bei der Rekonstruktion einer alteren Rechnung ein Problem darstellen.

3.24 Die Zeitachse in Datenmodellen und Datenbanken

127

Es gibt also Griinde, daruber nachzudenken, wie die zeitliche Dimension der Daten mitberticksichtigt werden kann. Dazu muss erst mal iiberlegt werden, welche Daten sich nach ihrer Entstehung verandem konnen und welche nicht. Verandem konnen sich alle die, die nicht unmittelbar im Prozess entstehen (z.B. die verwendeten Stammdaten). Diese sind uber langere Zeit stabil, konnen sich aber natiirlich auch verandem. Beispiele sind Kundendaten, Artikeldaten, usw. Dagegen verandem sich die Daten, die im Geschaftsprozess entstehen, nicht mehr (Rechnungsdatum, Attribute von Rechnungspositionen, usw.). Doch nun zuriick zu unserem Datenmodell. Betrachten wir zuerst die Artikel. Sie konnen aus dem Angebot verschwinden, ihre Beschreibung und/oder ihren Preis verandem. Drei Alternativen fur die Erfassung der zeitlichen Dimension sind hier denkbar: Die Eintrage in ARTIKEL werden nicht geandert, sondem fortgeschrieben. Wenn sich die Beschreibung andert, erhalt der Artikel eine neue Versionsnummer, ebenso wenn sich der Preis andert, usw. Ein konkreter Artikel wird dann iiber die kombinierte Artikel- und Versionsnummer identifiziert:

Losung 1 Stammdaten fortschreiben

ARTIKEL (#(ArtikelNr, VersionsNr), Beschreibung, Preis, Stand) Fur die Rechnungspositionen ergibt sich dann: RECHNUNGSPOSITIONEN (#(RechnNr, PosNr), (ArtikelNr. VersionsNr). Beschreibung, Preis, Stand, Anzahl) Diese Losung ist akzeptabel, fiihrt aber zu Redundanzen, nicht auf der Ebene der einzelnen Relationen, aber uber die Relationen hinweg. So wird die Beschreibung wiederholt, wenn sich der Preis andert. Hat sich nur der Preis geandert, z.B. zehn mal, wird in 10 Tupeln dieselbe Beschreibung und derselbe Standort festgehalten. Dies ist die Stelle, an der oft radikale Umstrukturiemngen der Relationen vorgeschlagen werden im Sinne binarer Relationen. Das bedeutet, dass alle Attribute einer Relation, die sich im Zeitablauf verandem konnen, zusammen mit dem Schltissel in eine eigene Relation getan werden. Im obigen Beispiel: ARTIKEL-BESCHREIBUNG (#(ArtikelNr, VersionsNr), Beschreibung) ARTIKEL-PREIS (#(ArtikelNr, VersionsNr), Preis) ARTIKEL-STAND (#(ArtikelNr, VersionsNr), Stand) Die Relation zu den Rechnungspositionen wtirde sich bei dieser Losung wie folgt verandem: RECHNUNGSPOSITIONEN (#(RechnNr, PosNr), ((ArtikelNr. VersionsNr). Beschreibung), ((ArtikelNr VersionsNr). Preis), ((ArtikelNr, VersionsNr). Anzahl))

Losung 2 binare Relationen

128

Losung 3 Duplizieren zum Rechnungszeitpunkt

3 Modellierung Relationaler Datenbanken

Bei dieser Losung sind die oben angesprochenen Redundanzen beseitigt, allerdings werden die Abfragen komplizierter. Nicht nur mussen mehr Relationen verkniipft werden, was die Abfragen und Auswertungen verlangert, es muss auch immer noch bei jeder Relation die hochste Versionsnummer (bzw. bei Rekonstruktionen die „richtige") bestimmt werden. In der dritten Losung werden nicht die Stammdaten fortgeschrieben, sondem bei den Transaktionsdaten (hier die der Rechnungspositionen) die Daten dupliziert, die zum Zeitpunkt der Rechnungsstellung die richtigen sind. So wird aus dem Attribut ArtikelNr das Attribut RZ-ArtikelNr, d.h. Artikelnummer zum Zeitpunkt der Rechnungsstellung (RZ = Rechnungszeitpunkt). Insgesamt ergibt sich: RECHNUNGSPOSITIONEN (#(RechnNr, PosNr), RZ-ArtikelNr. RZ-Beschreibung, RZ-Preis, RZ-Stand, Anzahl) Die Relation Artikel bleibt unverandert: ARTIKEL (#ArtikelNr, Beschreibung, Preis, Stand) Diese Losung hat zur Folge, dass bei der Rechnungsstellung immer eine Kopie der Stammdaten erstellt wird, auch wenn sich diese vielleicht nie verandem. Insgesamt ergibt sich bei dieser Losung folgendes Datenmodell: RECHNUNGSPOSITIONEN (#(RechnNr, PosNr), RZ-ArtikelNn RZ-Beschreibung, RZ-Preis, RZ-Stand, Anzahl). ARTIKEL (#ArtikelNr, Beschreibung, Preis, Stand) RECHNUNGSKOPFE (#RechnNr, RechnDatum, Verkaufer, Tour, KVDAT) KUNDEN_STUFE2 (#KNr, Name, Vorname) ADRESSEN (#AdressNr, PLZ, Ort, StraBe, Telefon) KUNDEN-ADRESSEN_STUFE2 (#(KNr, AdressNr)) LR-ADRESSEN (#(RechnNr, (KNn AdressNr)). Adresstyp, RZName, RZ-Vorname, RZ-PLZ, RZ-Ort, RZ-StraBe, RZTelefon) Dupliziert wird in die Relationen RECHNUNGSPOSITIONEN und LRADRESSEN. In diesen spiegelt sich die Transaktion wider, hier werden die zum Zeitpunkt der Transaktion aktuellen Attributsauspragungen hinterlegt.

4

ENTITY RELATIONSHIP - MODELLIERUNG

4.1

Einfuhrung

Entity Relationship - Modelle (ER-Modelle) sind Semantische Datenmodelle. Das Hauptziel bei deren Entwicklung war, mehr von der Semantik eines Anwendungsbereichs zu erfassen als in alteren oder naher an den Dateistrukturen befindlichen Modellierungsansatzen, weshalb die ganze Gruppe dieser datenbanktheoretischen Ansatze Semantische Datenmodelle genannt wurde. Semantische Datenmodelle wurden vor allem in den 70er Jahren diskutiert. Dies fuhrte zu einer groBen Zahl von Vorschlagen, von denen nur einer Bedeutung fiir die Datenbankpraxis erlangt hat, die Entity Relationship Modellierung. Die Standardvorgehensweise beim Datenbankdesign ist, zuerst ein ERModell zu erstellen und dieses dann entweder in ein relationales oder in ein objektorientiertes Modell „runterzubrechen".

Mehr Semantik ins Datenmodell

Erinnerung: Urn im Text die Ubersichtlichkeit zu erhohen, wird folgende typographische Festlegung getroffen: • Weltausschnitte / Anwendungsbereiche werden fett, etwas vergroBert

Typographische Festlegung

und in Arial gesetzt: VORLESUNGSBETRIEB.

•

Datenmodelle sind ebenfalls in Arial sowie in Kapitalchen gesetzt: MARKT FUR DATENBANKSYSTEME

• •

4.2

Relationen, Entitatstypen, Beziehungstypen, Klassen sind in Arial und in GroBbuchstaben gesetzt: ANGESTELLTE Attribute sind in Arial gesetzt: PersOPialnummer

Entitaten, Beziehungen, Attribute

Im folgenden werden nun die verschiedenen Elemente des ER-Ansatzes^^ vorgestellt. Dabei wird jeweils besonders geprtift, wie hoch die semantische Potenz dieser Modellierungstechnik tatsachlich ist. AuBerdem wird Der ER-Ansatz wurde von Peter Chen Mitte der 70er-Jahre entwickelt und wird seitdem intensiv, auch auf zahlreichen Konferenzen, diskutiert, vertieft und weiterentwickelt.

130

Entitaten und Beziehungen

4 Entity Relationship - Modellierung

jeweils auf die grafische Notation fiir die dabei entstehenden Datenmodelle (ER-Modelle^^) eingegangen. In der ER-Modellierung werden ausdriicklich Objekte/Objektklassen und Beziehungen/Beziehungsklassen unterschieden. In der deutschsprachigen Literatur haben sich dafiir die Begriffe Entitdten/Entitdtstypen (vom englischen entities^ Ventity types) und Beziehungen/Beziehungstypen (von relationships/relationship types) eingebtirgert, die auch hier verwendet werden: 1 ER-Modellierung Entitat Entitatstyp Beziehung Beziehungstyp Typ

Konzeptionelle Modellierung Objekt Objektklasse Beziehung Beziehungsklasse Klasse

Englische Begriffe entity entity type relationship relationship type type

1

Die Unterscheidung von Objekten und Beziehungen geschieht im Gegensatz zum relationalen Modell, wo beide - Entitats- und Beziehungstypen durch Relationen dargestellt werden. Das Ziel dieser Trennung ist es, leichter die Abhangigkeiten zwischen den Daten zu erkennen. In der grafischen Notation werden Entitatstypen durch Rechtecke dargestellt. Hier z.B. die Entitatstypen DATEN BAN KSYSTEME und HANDLER: Entitatstypen grafisch

Datenbanksysteme

Handler Sie stellen - datenbanktechnisch - die Entitaten „Datenbanksysteme" bzw. „Handler von Datenbanksystemen" dar, die jeweils zu Klassen (hier Typen genannt) zusammengefasst wurden. Das zweite Grundelement dieses Ansatzes sind Beziehungen: Ein ERModell beschreibt einen Weltausschnitt als eine Menge von Entitaten/Entitatstypen, die durch Beziehungen/Beziehungstypen verknupft sind. Die Beziehungstypen werden durch Rauten dargestellt. In unserem Beispiel konnte der Beziehungstyp DB_H (nach den Anfangsbuchstaben Es gibt zahlreiche Variationen des ER-Modells, die alle aus dem Bemuhen entstanden, noch mehr von der Semantik des Weltausschnitts zu erfassen. Der Begriff „Entity" wird, nach seinem Gebrauch besser mit „Ding" ubersetzt, da die angelsachsischen Autoren ihn als allgemeinen Begriff fur alles, was wahrgenommen wird, benutzen. Geeignet ware auch - aus dem Modellierungsblickwinkel - Informationstrdger. Denn alles, was wir wahrnehmen, nehmen wir durch Informationen wahr.

4.2 Entitaten, Beziehungen, Attribute

131

der Entitatstypen) erfasst werden, mit der festgehalten wird, welcher Handler welches Datenbanksystem zu verkaufen bereit ist: Beziehungstypen grafisch

Grundsatzlich konnen Beziehungstypen auch mit Verben benannt werden, hier z.B. mit "bietet an". Die einzelnen Beziehungen sind die zwischen einzelnen Datenbanksystemen und einzelnen Handlem, z.B. Handler X bietet INGRES an. Alle solchen Beziehungen zusammen bilden den Beziehungstyp. In unserem Beispiel konnte damit das erste kleine Datenmodell angelegt werden: Datenbanksysteme er^T-

Abbildung 4.2-1:

Ein erstes kleines Datenmodell DATENBANKSYSTEME-HANDLER

Es erfasst, wie gesagt, welcher Handler welches Datenbanksystem auf dem Markt anbietet. Halten wir fest, dass bisher nur die Entitaten und Entitatstypen als solche, ohne jegliche Identifikation und Beschreibung, erfasst worden sind. Hierzu gleich mehr. Wie in den anderen Ansatzen zur Datenmodellierung werden auch hier die Beziehungen genauer festgelegt. Im ersten Schritt sollen hier 1:1-, 1 :n- und n:m - Beziehungen unterschieden werden. Diese werden einfach bei den beiden beteiligten Entitatstypen vermerkt. Da es sich beim obigen Beispiel um eine n:m - Beziehung handelt, konnte diese so angegeben werden: KardinalitBten: Ein Datenbanksystem kann von mehreren Handlern angeboten werden.

Ein Handler kann melirere Datenbanksysteme anbieten

Datenbanksysteme

Handler

t^ Abbildung 4.2-2:

n:m - Beziehung

132

4 Entity Relationship - Modellierung

Die Bedeutung ist dieselbe wie in der relationalen Theorie: Ein Datenbanksystem kann, muss aber nicht, von mehreren Handlem angeboten werden, ein Handler kann, muss aber nicht, mehrere Datenbanksysteme anbieten. Ein Beispiel fur eine l:n - Beziehung ist Angestellte/Abteilung. Ein Angestellter ist einer Abteilung zugeordnet, eine Abteilung hat in der Kegel mehrere Angestellte: Kardinalif^ten: Angestellte sind einer Abteilung zugeordnet

Eine Abteilung hat mehrere Angestellte.

Angestellte

Tsr Abbildung 4.2-3:

Rekursive Beziehungen

1 :n - Beziehung

Beispiele fur 1:1 - Beziehungen folgen unten. Der ER-Ansatz sieht auch Beziehungen eines Entitatstyps mit sich selber vor. Zwei Beispiele mogen dies verdeutlichen. Erstens das einer Stuckliste, die einfach wie folgt modelliert wird: Telle

Abbildung 4.2-4:

Stticklisten

Zweitens eine Beziehung wie „IST VORGESETZT" auf einem Entitatstyp ANGESTELLTE:

Abbildung 4.2-5:

Angestellte und Vorgesetzte

4.2 Entitaten, Beziehungen, Attribute

133

Die Art der grafischen Anordnung (nach unten oder seitlich) hat dabei keine Bedeutung. Die Aussagekraft dieser Modellfragmente ist noch sehr beschrankt. Sie erhoht sich erst, wenn im folgenden Abschnitt Attribute eingefuhrt werden. Es gibt eine Gruppe von Entitaten, deren Existenz im jeweiligen Datenmodell davon abhangt, dass in einem anderen Entitatstyp eine bestimmte Entitat vorliegt. Das in der Literatur meistgenannte Beispiel ist ein Entitatstyp KINDER in einem Datenmodell zu den Beschaftigten eines Unternehmens, zu dem auch ein Entitatstyp der Angestellten gehort. Hier gibt es in KINDER nur dann einen Eintrag, wenn Vater oder Mutter im Betrieb beschaftigt sind. Jeder Eintrag in KINDER ist also existentiell abhangig von den Eintragen in ANGESTELLTE. Verlassen die Eltem das Untemehmen, wird der Eintrag in KINDER geloscht. Ein zweites sehr typisches Beispiel sind die Auftragspositionen in einem Datenmodell AUFTRAGE (vgl. die folgende Abbildung). Die Auftragspositionen hangen existentiell vom Auftragskopf ab. Wird ein bestimmter Auftragskopf geloscht, mlissen auch seine Auftragspositionen geloscht werden. Dies ist nicht die normale Situation, bei der in einer Beziehung die Entitaten der beiden Entitatstypen unabhangig voneinander existieren. Solche „abhangigen" Entitatstypen werden singulare Entitatstypen und die zugehorigen Beziehungen singulare Beziehungstypen genannt. In der grafischen Notation werden sie mit einer Doppellinie versehen:

Auftragskopf

Abbildung 4.2-6:

Auftragsposition

Existenzabhangigkeit - erfasst durch singulare Entitatstypen.

Existenzabhangigkeiten dieser Art sind wichtig, insbesondere wenn das Datenmodell zur Datenbank geworden ist und seine AUtagstauglichkeit beweisen muss. Deshalb spielen sie in einem anderen Modellierungsansatz eine prominente Rolle, der SERM (vgl. Kapitel 5). Wie auch im relationalen Modell werden die Entitaten und Beziehungen in ER-Modellen durch Attribute beschrieben. Dabei werden aber verschiedene Arten von Attributen mit unterschiedlicher grafischer Notation unterschieden: • • • • •

Singulare Entitatstypen

„Normale" deskriptive Attribute, qualitativ oder quantitativ Schltisselattribute Mehrwertige Attribute Abgeleitete Attribute Zusammengesetzte Attribute

Attribute

134

4 Entity Relationship - Modellierung

Deskriptive Attribute

Abbildung 4.2-7:

Deskriptive Attribute

Deskriptive Attribute dienen „nur" der Beschreibung der Entitaten bzw. Beziehungen. Quantitative deskriptive Attribute haben die zusatzliche Eigenschaft, dass mit ihren Auspragungen gerechnet werden kann. Im Beispiel der Abbildung sind Alter und Gehalt quantitativ, Geschlecht ist qualitativ, Firmeneintritt ist eine Datumsangabe. Auf die Unterscheidung von rangskalierten Attributen (wie bei Merkmalen in der Statistischen Messtheorie) wird in der Datenbanktheorie verzichtet. SchlUssel

Abbildung 4.2-8: Konkurrierende Schlussel Konkurrenz unter Schlusseln

Schltisselattribute dienen - wie im Datenbankgeschehen tiblich - zur Identifikation der Entitaten oder Beziehungen. Im Beispiel sind - fiir Datenbanksysteme - der Name und eine (natiirlich eindeutige) Nummer angegeben. Letztere miisste vom System oder vom Nutzer vergeben werden. Somit liegen hier zwei voneinander unabhangige Schltissel vor. Bei einer solchen Situation kann auch von konkurrierenden Schliisseln gesprochen werden. Bezeichnung. Semester ester^

Vorlesungen er74a

Abbildung 4.2-9: Zusammengesetzter Schltissel

4.2 Entitaten, Beziehungen, Attribute

135

Im Gegensatz dazu sprechen wir von einem zusammengesetzten Schlussel, wenn mehrere Attribute zusammen den Schliissel bilden. In der obigen Abbildung genugt u.U. nicht die Angabe der Bezeichnung einer Vorlesung (z.B. Datenbanksysteme), sondem es muss auch noch das Semester angegeben werden {Datenbanksysteme / SS05), z.B. wenn es eben darum geht festzuhalten, wer in welchem Semester welche Veranstaltung gehalten hat. Mehrwertige Attribute

er75

Abbildung 4.2-10: Mehrwertige Attribute Oft gibt es bei einem Attribut mehrere Auspragungen in Bezug auf eine Entitat. In der obigen Grafik z.B. mehrere (beherrschte) Programmiersprachen fiir einen Angestellten oder mehrere Projekte, in denen er oder sie mitarbeitet. Bin solches Attribut wird mehrwertig genannt. In der ER-Modellierung wird es durch eine Doppellinie gekennzeichnet. Abgeleitete Attribute

Alter

Abbildung 4.2-11:

Abgeleitete Attribute

Abgeleitete Attribute werden nicht direkt erfasst, sondem aus anderen Attributen bestimmt. Z.B. konnte in einem Entitatstyp zu den Angestellten eines Untemehmens das Alter aus dem abgespeicherten Geburtsdatum (GebDat) und dem vom System gelieferten Tagesdatum bestimmt werden.

136

4 Entity Relationship - Modellierung

Zusammengesetzte Attribute

Abbildung 4.2-12:

Zusammengesetzte Attribute

Bei zusammengesetzten Attributen handelt es sich um solche, die zum Zweck der Erfassung in andere Attribute zerlegt werden konnen. Nehmen wir als Beispiel eine Namensangabe. Das Attribut Name kann zerlegt werden in die Attribute VorN und NachN. Dies ist beliebig ausbaubar (akademische Grade, usw.). Eine solche „Verschachtelung" kann auch mehrstufig sein, wie das Beispiel einer Adressangabe zeigt.

Abbildung 4.2-13:

Das erste ER-Modell

Zusammengesetzte Attribute - verschachtelt

Zu beachten ist, dass bei zusammengesetzten Attributen nur die unterste Ebene tatsachlich aus Attributen besteht. Die tibergeordneten (hier „Name" und „Adresse") sind lediglich Benennungen fiir inhaltlich zusammengehorige Gruppen von Attributen. Nattirlich werden Attribute nicht isoliert, sondem mit ihrem zugehorigen Entitats- bzw. Beziehungstyp erfasst, wie in den obigen Abbildungen ja schon angedeutet. Fur ein Datenmodell entsteht dann eine Grafik wie in der folgenden Abbildung gezeigt. Dort werden die DATENBANKSYSTEME durch ihren Namen identifiziert (Name), sowie durch die Angabe ihres Typs (Typ), der Liste ihrer Datentypen, der Liste ihrer Komponenten und ihren Llstenpreis beschrieben. Die Handler werden durch den Firmennamen identifiziert (Firmenname) und durch ihre Adressangaben sowie

4.3 Zuordnung der Attribute - Entstehung neuer Entitatstypen

137

durch ihre telekommunikativen Angaben beschrieben. Der Beziehung wurde ebenfalls ein Attribut (Konditionen) zugewiesen. In ihm soil festgehalten werden, welche prozentualen Nachlasse der Handler bei den einzelnen Datenbanksystemen zu geben bereit ist. Da die Prozentsatze je nach Datenbanksystem verschieden sein konnen, kann dieses Attribut nicht beim Handler, sondem nur bei der Beziehung (Kombination Datenbanksystem/Handler) platziert werden.

Abbildung 4.2-14:

4.3

ER-Modell MARKT FUR DATENBANKSYSTEME

Zuordnung der Attribute - Entstehung neuer Entitatstypen

Im Regelfall ist die Zuordnung der Attribute zu Entitats- und Beziehungstypen problemlos. So wird das obige Attribut Konditionen dem Beziehungstyp DB_H („bietet an") zugeordnet, weil es das Angebot spezifiziert und weil es nach Datenbanksystemen verschieden sein kann (nach Handlem sowieso). Was tun wir nun aber, wenn wir die Datentypen der Datenbanksysteme naher beschreiben wollen, z.B. durch Erfassung der konkreten Auspra-

Vom Attribut zum Entitatstyp

138

4 Entity Relationship - Modellierung

gung: Dass bei einem bestimmten Datenbanksystem FLOAT4 den Wertebereich von xxx bis yyy hat, dass TEXT die Erfassung von Texten bis 30MByte erlaubt, dass MONEY auf einem Datentyp REAL mit zwei Stellen rechts vom Komma und vorgestelltem Wahrungszeichen beruht, usw. Nennen wir dieses Attribut DTSpez fur „Spezifikation des Datentyps". Wo gehort es hin in obigem kleinen Datenmodell? Hatte jedes Datenbanksystem nur einen Datentyp, ware dies problemlos. DTSpez ware einfach ein weiteres Attribut, das den Entitatstyp DATE N BAN KSYSTE ME beschreibt. DATTYP ist nun aber ein mehrwertiges Attribut, das eine Menge von Datentypen angibt, die vom jeweiligen Datenbanksystem zur Verfugung gestellt werden. DATTYP selbst hat zudem Schltisselcharakter in Bezug auf Datentypen. Damit ist nun genau die Situation gegeben, bei der das neue Attribut DTSpez dazu fiihrt, dass ein neuer Entitatstyp DATENTYPEN eingefuhrt werden muss. Diesem wird dann a) das alte identifizierende Attribut zugeordnet, b) das neue und c) eventuelle weitere mit denen die Datentypen weiter beschrieben werden, z.B. GRUPPE, wenn jeder Datentyp einer der Gruppen „numerische", „alphanumerische", „textliche", „multimediale Datentypen" zugeordnet werden soil. Damit konnte sich das folgende Modellfragment ergeben: Name

DTSpez

Datentypen

Abbildung 4.3-1:

Name

DT/DB)

Datenbanksysteme

Zuordnung Attribute - Entitatstypen

Die Punkte deuten jeweils die Erganzungen des Datenmodells an (vgl. oben). Grundsatzlich ist folgende Zuordnungsregel wichtig: Attribute werden dem Entitats- Oder Beziehungstyp zugeordnet, dessen Entitaten oder Beziehungen sie beschreiben. Und zwar umfassend. Wie sich ja schon aus der Definition der Entitatsund Beziehungstypen ergibt ("zusammengefasst in einer Klasse/Typ werden die, die durch dieselben Attribute beschrieben werden") muss jedes Attribut flir alle Entitaten bzw. Beziehungen Gultigkeit haben, d.h., auf alle anwendbar sein^^.

^^

Diese Kegel wird in der relationalen Modellierung durch die zweite und dritte Normalform erreicht.

4.3 Zuordnung der Attribute - Entstehung neuer Entitatstypen

139

Im obigen Beispiel war es so, dass DTSpez (die Spezifikation des Datentyps) nicht die Datenbanksysteme beschreibt, sondem die Datentypen. Genauso Gruppe (der Datentypen). Es muss also sehr genau darauf geachtet werden, dass jedes Attribut genau die Entitaten des jeweiligen Entitatstyps beschreibt^^ Passiert es im Rahmen eines Modellierungsprozesses, dass diese Kegel nicht mehr zutrifft (z.B. weil neue Entitaten zum Entitatstyp hinzugenommen wurden, die diese Kegel verletzen), muss der Entitats- oder Beziehungstyp aufgeteilt werden. Ein Beispiel moge dies erlautem. In der folgenden Abbildung ist in Teil A ein Entitatstyp ANGESTELLTE angegeben. Seine Entitaten werden durch das Attribut PersNr (Personalnummer) identifiziert und durch Name, Vorname und viele weitere (dies sollen die Punkte in der Attributsellipse andeuten) beschrieben. Die Linie an dem Entitatstyp soil andeuten, dass ein solcher Entitatstyp nattirlich Teil eines groBeren Datenmodells sein muss.

C N ^

C^pme)

Angestellte

Abbildung 4.3-2:

EK-Modell ANGESTELLTE

Diese Modellierung ist korrekt, solange keine Angestellten dazukommen, die spezifische Attribute benotigen. Geschieht dies, hier wurden zwei Attribute aufgenommen, die nur ftir die Programmierer unter den Angestellten Bedeutung haben (Programmiersprachenkompetenz (PSn) und Programmiererfahrung (ProgErf)), ergibt sich die in Teil B skizzierte Situation. Jetzt sind zwei Attribute vorhanden, die nur auf einen Teil der Entitaten anwendbar sind (die nur ftir einen Teil der Entitaten Gtiltigkeit haben).

Hat man in der konzeptionellen Modellierung sauber gearbeitet („es werden die Objekte zusammengefasst, die durch dieselben Attribute beschrieben werden), taucht dieses Problem an dieser Stelle nicht auf.

Aufspaltung durch neue Attribute

140

4 Entity Relationship - Modeilierung

Abbildung 4.3-3:

ER-Modell ANGESTELLTE mit falscher Attributzuordnung

Genau eine solche Situation soil die oben angefuhrte Kegel verhindem. Der Grund ist einfach. Eine solche Attributanordnung fuhrt schlussendlich zu Datenbestanden die - in der tiblichen Grundform der sequentiellen Datei - luckenhafl sind. Ltickenhaft nicht durch "noch" fehlende Daten, sondem durch falsche Attribut/Entitatszuordnung^"^. Korrigiert wird dies mittels einer Aufteilung des Entitatstypen in zwei verschiedene, die der Zuordnungsregel entsprechen. Hier somit (vgl. die folgende Abbildung) in die zwei Entitatstypen PROGRAMMIERER und SONSTIGE Angestellte. Wer bei diesem Beispiel an die Generalisierung/Spezialisierung denkt, liegt genau richtig. Vgl. hierzu den nachsten Abschnitt.

In der relationalen Datenmodellierung verhindert die 3NF eine solche Attributanordnung (bezogen auf Relationen).

4.3 Zuordnung der Attribute - Entstehung neuer Entitatstypen

141

(jsiame^

Abbildung 4.3-4:

ER-Modell ANGESTELLTE - korrigiert

Auch das folgende Modellfragment ist falsch. Hier wird TRAINING als Entitatstyp beschrieben und durch Angabe des Tages sowie der Anfangsund Endzeit erfasst. So weit so gut. Die Beschreibung durch die Adresse ist aber falsch, da die Adresse zum Trainingsor^ gehort und nicht zum Training als solches.

Falsch!

Abbildung 4.3-5:

Fehlerhafte Attributzuordnung

Richtig ware also eine Aufteilung, wie in der folgenden Abbildung. Dadurch werden Training und Trainingsort getrennt.

Einweiteres Beispiel

142

4 Entity Relationship - Modellierung

Training

Trainingsort ;?5s-

Abbildung 4.3-6:

Training und Trainingsort getrennt

Die Zuordnung der Attribute macht oft auch im Zusammenhang mit zusammengesetzten Attributen Schwierigkeiten. Zusammengesetzte Attribute werden oft mit einer unzulassigen Attributskombination verwechselt, namlich damit, dass an ein Attribut weitere Attribute zur Fortsetzung der Beschreibung „gehangt" werden.

4.4

Totale Beteiligung

Beteiligungen - Kardinalitaten und Min-/MaxAngaben

Oben wurden schon Kardinalitaten eingeftihrt als erstes Werkzeug ftir die Festlegung, wieviele Entitaten jeweils an einer Beziehung teilhaben. Die dartiber hinaus zur Verftigung stehenden Werkzeuge werden hier vorgestellt. Z.B. kann festgelegt werden, dass alle Entitaten eines Entitdtstyps an einer Beziehung teilhaben mussen. Dies wird Jotale Beteiligung von ... an" genannt und bezieht sich immer auf eine Entitats- und Beziehungstyp. Nehmen wir das Datenmodell der ft)lgenden Abbildung. Hier konnte verlangt werden, dass nur Handler erfasst werden, die tatsachlich (in unserer Datenbank) zumindest ein Datenbanksystem anbieten. Mit anderen Worten wird damit verlangt, dass jede Entitat von HANDLER in die Beziehung BIETET__AN verwickelt ist. In der grafischen Notation wird dies durch einen Doppelstrich festgelegt, wie der ft)lgende Auszug aus dem Datenmodell zeigt.

4.4 Beteiligungen - Kardinalitaten und Min-/Max-Angaben

143

Datenbanksysteme

Handler

Abbildung 4.4-1:

Totale Beteiligung von Entitaten an Beziehungen

Fiir die Datenbanksysteme wird dies im Datenmodell nicht verlangt. Dadurch ist es dann moglich, Datenbanksysteme zu erfassen, von denen noch kein Handler bekannt ist. Wie oben (Abschnitt 4.3) schon ausgefuhrt, kann auch hier gleich wie bei Relationalen Datenmodellen die Kardinalitat einer Beziehung festgehalten werden. Damit ist gemeint, wieviele Entitaten des einen und des anderen Entitatstyps maximal in die entsprechende Beziehung einbezogen sind. Im Beispiel der folgenden Abbildung wurde z.B. die technische Beschreibung der Datenbanksysteme (OATENBANKSYSTEME/TECHNISCHE INFORMATION) getrennt von den Preisangaben (DATENBANKSYSTEME / PREISINFORMATION), z.B. well die technische Information grundsatzlich fur jedes erfasste Datenbanksystem erhoben wird, die preisliche aber nur flir einige, die diesbezuglich besonders interessieren. AuBerdem wurden die PRODUZENTEN der Systeme und die DATENTYPEN aufgenommen. Es wird angenommen, dass jedes Datenbanksystem von genau einem Produzenten stammt. Dann gelten die in der folgenden Abbildung angegebenen Kardinalitaten. Die Bedeutung dieser Kardinalitaten im einzelnen: •

1:1 zwischen DATENBANKSYSTEME / TECHNISCHE INFORMATION und DATENBANKSYSTEME / PREISINFORMATION, well es flir eine technische eine preisliche und fiir eine preisliche eine technische Beschreibung geben kann. Dieses Beispiel zeigt allerdings auch die Schwache der Kardinalitaten. Die Tatsache, dass es zwar fiir jede preisliche Information eine technische gibt, aber nicht umgekehrt, wird durch die Kardinalitaten nicht erfasst. Dies leisten dann aber die Min-/Max-Angaben (vgl. unten sowie die entsprechenden Anmerkungen in Kapitel 3). Hier waren sie 0,1 auf der Seite DATENBANKSYSTEME / TECHNISCHE INFORMATION und 1,1 auf der Seite DATENBANKSYSTEME / PREISINFORMATION.

Kardinalitat

144

4 Entity Relationship - Modellierung

ProdNr

Name

Produzenten

Datentypen

Datenbanksysteme / technische Information

Datenbanksysteme l\ Preisinformation KostenWartung Abbildung 4.4-2: •

•

Kardinalitaten in Entity Relationship-Modellen

nil zwischen PRODUZENT und DATENBANKSYSTEME/TECHNISCHE INFORMATION, weil ein Datenbanksystem von einem Produzent stammt, dieser aber mehrere Systeme auf dem Markt anbieten kann. n:m zwischen DATENTYPEN und DATENBANKSYSTEME/ TECHNISCHE INFORMATION, weil ein Datenbanksystem in der Regel mehrere Datentypen hat und ein Datentyp meist in verschiedenen Datenbanksystemen anzufmden ist.

Die Kardinalitaten sind eine nicht sehr prazise Angabe. So ist zum einen nicht ersichtlich, ob eine Entitat eines Entitdtstyps iiberhaupt an der Beziehung teilhaben muss (vgl. auch die Anmerkung oben), zum anderen wird damit auch nicht angegeben, mit wieviel anderen Entitaten die Beziehung maximal erfolgt.

4.4 Beteiligungen - Kardinalitaten und Min-/Max-Angaben

145

Dieses Defizit losen die sog. Min-/Max-Angaben'^ (Minimum/Maximum - Angaben). Mit ihnen wird festgehalten, wieviele Entitaten mindestens und wieviele hochstens an einer Beziehung teilhaben. Eine Min-/Max-Angabe besteht immer aus zwei durch ein Komma (bei einigen Autoren auch durch Punkte) getrennten Zahlen. Jede Beziehung hat zwei solche Angaben, die bei jeweils einer der beteiligten Entitdtstypen stehen. Die zwei Werte halten dann fest, mit wievielen Entitaten minimal (erster Wert) und maximal (zweiter Wert) die Entitatstypen an der Beziehung teilnehmen. Liegt bei Min-/Max-Angaben eine feste Unter- oder Obergrenze vor, werden diese angegeben, also z.B. 11,14 (vgl. unten). Liegt keine feste Obergrenze vor, wird n oder m genommen als ganzzahlige positive Werte groBer 1. In der folgenden Grafik, bei der Beziehung DT_DB, bedeutet z.B. 0,m beim Entitatstyp DATENTYPEN, dass Datentypen auch erfasst werden, wenn noch kein Datenbanksystem bekannt ist, das einen solchen hat (z.B. fiir neue Datentypen). Der Wert m dagegen bedeutet, dass ein Datentyp in zahlreichen Datenbanksystemen vorhanden sein kann. Die Min-/MaxAngabe l,m auf der anderen Seite der Beziehung bedeutet, dass gilt: Ein Datenbanksystem hat mindestens einen Datentyp, kann aber auch mehrere haben (was normalerweise der Fall ist). Zu beachten ist, dass der jeweils erste Wert einer Min-/Max-Angabe auch festlegt, ob eine Entitat an einer Beziehung teilhaben muss oder nicht. Die oben eingefiihrte totale Beteiligung wird also, zumindest was die Beziehungen angeht, bei der Verwendung von Min-/Max-Angaben tiberfliissig. Die Festlegung des ersten Werts der Min-/Max-Angaben ist nicht so sehr Ausdruck der realen Semantik, sondem Ausdruck des Wollens der Modellierer. Der Wert 0 in der 0,m-Angabe der folgenden Abbildung sagt, dass in diese Datenbank eben auch Datentypen eingetragen werden diirfen, fur die noch kein Datenbanksystem bekannt ist. Genauso gut konnte man mit l,m festlegen, dass nur Datentypen in die Datenbank kommen, zu denen in der Datenbank auch ein Datenbanksystem erfasst ist.

Vgl. auch die Ausflihrungen hierzu in Abschnitt 3.5

Min-/MaxAngaben

146

4 Entity Relationship - Modellierung

Min-/Max-Angaben: Ein (in derDatenbank erfaRter) Datentyp kann in keinem Oder mehreren Datenbanksystemen vorkommen.

Datenbanksysteme Abbildung 4.4-3:

Ein Datenbanksystem fiat mindestens einen Datentyp.

Min-/Max-Angaben

Die folgenden weiteren Beispiel zu Min-/Max-Angaben beziehen sich auf die (vereinfachte) Situation in einem Sportverein. Bei der Beziehung 1 zwischen MAN NSC HAPTEN und MITGLIEDERn wird hier durch das Datenmodell festgelegt, dass eine Mannschafl; aus mindestens 11 und maximal 14 Spielem besteht (evtl. mit Ersatzspielem) und dass ein Mitglied in mindestens einer und maximal zwei Mannschaften spielt.

Mannschaften

1.2

11.14

Mitglieder

n:m Abbildung 4.4-4:

Min-/Max-Angaben 1: Pflichtbeteiligung / mehrwertig

Die Beziehung 2 zwischen MANNSCHAPTEN und ABTEILUNGEN ist hier so angenommen, dass eine Mannschaft genau einer Abteilung zugeordnet sein muss („mindestens in einer, hochstens in einer"). Die Zahlen bei ABTEILUNGEN bedeuten, dass eine Abteilung mindestens eine Mannschaft hat (eine Abteilung existiert also in der Datenbank (modelltechnisch) erst, wenn auch die erste Mannschaft eingerichtet wurde), dass sie aber auch mehrere haben kann.

4.4 Beteiligungen - Kardinalitaten und Min-/Max-Angaben

Mannschaflen

Abbildung 4.4-5:

147

Abteilungen

Min-ZMax-Angaben 2: Pflichtbeteiligung / einer Oder mehr

Natiirlich gibt es auch Beziehungen, die auf jeder Seite den maximalen Wert 1 haben. Nehmen wir fiir dieses Beispiel an, es gabe einen eigenen Entitatstyp TRAINER und es ware weiterhin so, dass zu einem Zeitpunkt eine Mannschaft von einem Trainer trainiert wird und dass jeder Trainer auch nur eine Mannschafl betreut. Dann ergibt sich die Situation von Beispiel 3. Der Nullwert auf der linken Seite kann bedeuten, dass eine Mannschafl auch mal ohne Trainer sein kann, der Nullwert auf der rechten Seite, dass ein Trainer auch Trainer sein kann, ohne dass ihm eine Mannschaft zugewiesen ist.

Abbildung 4.4-6:

Min-/Max-Angaben 3: Optionale Beteiligungen / maximal 1

Somit gehen die Min-/Max-Angaben immer von dem Entitatstyp aus, bei dem sie stehen und geben an, mit wieviel Entitaten des anderen Entitatstyps eine Entitat in Beziehung steht. Aus den Min-/Max-Angaben konnen die Kardinalitaten direkt abgelesen werden. Im Falle der Beziehung zwischen Mannschaften und Mitgliedem handelt es sich um eine n:m - Beziehung, bei Mannschaflen und Abteilungen um eine 1 :n - Beziehung und bei Mannschaflen und Trainem um die Kardinalitat 1:1. Es gibt in ER-Modellen nicht nur zweistellige Beziehungen. Grundsatzlich sind beliebigstellige moglich. AUerdings ist dann die Bestimmung der Min-/Max-Angaben nicht mehr so einfach wie im zweistelligen Fall. Die Min-/Max-Angaben eines Entitatstyps konnen nun nicht mehr mit einem konkreten anderen, sondem nur mit dem Beziehungstyp in Verbindung gesetzt werden: Fur jeden Entitatstyp wird ausgedruckt, mit wieviel Entitaten er minimal und maximal am Beziehungstyp teilnimmt. Die folgende Abbildung zeigt ein Beispiel.

Min-ZMaxAngaben bei mehrstelligen Beziehungen

148

4 Entity Relationship - Modellierung

(jvlame^

Trainer

er86

Abbildung 4.4-7:

Dreistelliger Beziehungtyp - Variante 1

Hier bedeuten die Min-/Max-Angaben: • • •

Am Training nimmt genau eine Mannschaft teil Das Training fmdet an einem Ort statt Es wird durch einen Trainer durchgefuhrt

Die folgende Abbildung zeigt etwas andere Werte. MMame^

Trainer

Abbildung 4.4-8:

Dreistelliger Beziehungstyp - Variante 2

Jetzt ist die Bedeutung der Min-/Max-Angaben wie folgt:

4.5 Ahnlichkeit und Enthaltensein

• • •

149

Am Training nimmt mindestens eine, maximal zwei Mannschaft/en teil Das Training fmdet an einem Ort statt Es wird nicht immer von einem Trainer durchgefiihrt. Falls doch, sind hochstens zwei beteiligt.

Diese Beispiele miissten geniigen um klarzumachen, dass mit der Festlegung der Min-/Max-Angaben ein weiteres wichtiges Stuck Semantik im Datenmodell festgehalten wird. Gleichzeitig helfen diese Angaben, sich iiber die Beziehung klar zu werden.

4.5

Ahnlichkeit und Enthaltensein

Ein Instrument zur Erhohung der Modellierungspotenz in Semantischen Datenmodellen war die Einfuhrung der Generalisierung/Spezialisierung als Modellierungswerkzeug. Mit ihr kann die Tatsache im Datenmodell ausgedriickt werden, dass Entitatstypen zwar nicht gleich sind (d.h., dieselben Attribute haben), aber eine groBe Ahnlichkeit aufweisen (d.h. viele Attribute gemeinsam haben und einige, die nicht gemeinsam sind). Betrachten wir das Beispiel eines Entitatstyps "datenverwaltende Systeme" (DVS). Damit sollen alle die Soflwareprodukte gemeint sein, deren Hauptaufgabe darin besteht, Daten zu verwalten. Beispiele sind Dateisysteme, Datenbanksysteme, Information Retrieval Systeme''^, usw. und dass Datenbanksysteme wiederum unterteilt^^ werden konnen in Entwicklungssysteme^^, Client/Server-Datenbanksysteme^^ und Verteilte Systeme^^. Will man solche Systeme in einer Datenbank verwalten, sie also durch Attribute beschreiben, wird man feststellen, dass sie viele Attribute gemeinsam haben, jeder Typ aber auch spezifische nur ftir ihn gultige Attribute aufweist. In der folgenden Abbildung ist hierzu ein Beispiel und die grafische Notation angegeben. Bedeutung gewinnt dies, weil dadurch im Datenmodell Ahnlichkeit zwischen Entitaten bzw. Entitatstypen erfasst werden kann. Im Rahmen von Datenmodellen werden dann z.B. allgemeine Attribute fur den allgemeinsten Entitatstyp defmiert. Dies sind Attribute, die auf alle Entitatstypen und Entitaten anwendbar sind. Die etwas spezifischeren Entitatstypen konnten dann Attribute aufweisen, die nur fiir sie sinnvoll und giiltig sind. Diese Technik tritt in zwei Varianten auf, die beide in der folgenden Abbildung integriert sind. Die erste Spezialisierung von DATENVERWALTENDE SYSTEME in DATEISYSTEME, DATENBANKSYSDies sind Programme zur professionellen Verwaltung von (auch und vor allem langen) Texten. Es handelt sich jeweils nattirlich nur um eine Auswahl. Datenbanksysteme mit einer Entwicklungsumgebung zur Realisierung komplexer Anwendungen. Datenbanksysteme, die Client/Server-Architekturen untersttitzen. Datenbanksysteme, die ihre Daten „verteilt" auf unterschiedlichen geographischen Standorten halten und trotzdem integriert anbieten konnen.

Ahnlichkeit zwischen Entitaten

150

4 Entity Relationship - Modellierung

TEME, usw. hat ausschliefienden Charakter: ein System ist Dateisystem ODER Datenbanksystem ODER Information Retrieval System im Sinne des ausschlieBenden ODER. Deshalb wird hier in der grafischen Notation ein „d" (fur disjunkt) angegeben. Dagegen hat die Einteilung von Datenbanksystemen in ENTWICKLUNGSSYSTEME, CLIENT/SERVER-DATENBANKSYSTEME und VERTEILTE DATENBANKSYSTEME keineswegs ausschlieBenden Charakter. So sind heute - zumindest auf der Ebene der Mittleren Datentechnik - so gut wie alle Datenbankentwicklungssysteme auch Systeme, die Client/Server-Architekturen unterstutzen. Deshalb wird hier in der grafischen Notation ein „ti" fiir „iiberlappend" angegeben^ \ Beide Generalisierungs-ZSpezialisierungs-Varianten kommen haufig vor und bedtirfen entsprechender datenbanktechnischer Berlicksichtigung. Datenverwaltende Systeme

Information Retrieval Systeme

Dateisysteme

XI fepezifische AttributgJ stepezifische AttributgJ)

Entwicklungssysteme

ClienVServer-Datenbanksysteme

Verteilte Datenbanksysteme

T" (igpezifische Attributgy (ispezifische Attribute^) (^pezifische Attributg!)

Abbildung 4.5-1:

Generalisierung / Spezialisierung

In der englischsprachigen Literatur „o" fur „overlapping"

4.5 Ahnlichkeit und Enthaltensein

151

Auch das im vorigen Abschnitt diskutierte Beispiel der Aufspaltung eines Entitatstyps Angestellte in PROGRAMMIERER und SONSTIGE Angestellte konnte mit der Generalisierung/Spezialisierung besser gelost werden. Betrachtet man die „Richtung" von den spezielleren Systemen zu den allgemeineren spricht man von Generalisierung, umgekehrt von Spezialisierung. Insgesamt wird hier auch von Abstraktion gesprochen. Die DoppellHnie bedeutet, wie oben eingefiihrt, totale Beteiligung. Im obigen Beispiel ist es also so, dass alle erfassten datenverwaltenden Systeme in eine der Spezialisierungen fallen mussen. Eine weitere Modellierungstechnik betrifft die Tatsache, dass sich Entitaten aus anderen zusammensetzen. Dies wird mit der Teilvon Beziehung (auch partof - Beziehung) erfasst. Sie wird im Rahmen der Modellierungstechniken als Aggregation bezeichnet. Ein einfaches Beispiel zeigt die nachfolgende Abbildung. Dabei soil es um PC gehen, die (u.a.) aus Hauptplatinen, Festplatten und Bildschirmen zusammengesetzt sind. Fur Hauptplatinen wiederum sind als Komponenten Prozessoren, Speicherbausteine und Bussysteme denkbar. Die grafische Notation ist so, dass der Buchstabe A (fur Aggregation) zwischen die Entitatstypen platziert wird. Personal Computer

7^ -. QlSpezifische Attribute

Jjspezifische Attribute^) (Jspezifische Attribute^) (Jjspezifische Attribut^

A b b i l d u n g 4.5-2:

T e i l v o n - Beziehung

Die Attribute sind jetzt jeweils „spezifisch", in dem Sinn, dass jeder Entitatstyp seine eigenen Attribute hat.

Teil von

152

Warum?

4 Entity Relationship - Modellierung

Hier wird also nicht Ahnlichkeit erfasst, wie oben bei der Generalisierung / Spezialisierung, sondem Zusammengehorigkeit. Oft wird die Frage gestellt, ob dieses Konzept wirklich notig ist oder ob es nicht genugen wtirde, einfach alle Attribute einem Entitatstyp zuzuordnen. Dann entstunde im obigen Beispiel ein Entitatstyp PERSONAL COMPUTER mit den Attributen aller in der Abbildung angegebenen Komponenten. Der Nachteil ware, dass die Eigenschaft von Komponenten oder Teilen, in anderen enthalten zu sein, nicht erfasst wurde. Die Teilvon - Beziehungen werden vor allem bei Datenbanken benotigt, die technische Sachverhalte verwalten. Stellen wir uns eine Datenbank vor, in der die technischen Komponenten eines GroBflugzeuges verwaltet werden. Hier zerfallt das gesamte Flugzeug in Komponenten, diese wieder, usw., bis man bei den kleinsten Teilen ankommt, die ftir das Flugzeug verwendet werden. Dieses „Enthaltensein" von Komponenten und Teilen ineinander kann nur durch die Teilvon - Beziehung erfasst werden. Beide Techniken (Generalisierung / Spezialisierung und Aggregation) sind zwar elementar, was die menschliche Wahmehmung angeht, werden aber doch vom relationalen Datenmodell und den alteren Datenmodellen nicht direkt unterstUtzt. Soweit die Darstellung des Instrumentariums fur die ER-Modellierung. Bevor hier ein ausfiihrliches Beispiel vorgestellt wird noch einige Hinweise auf einen Bereich, der meist Schwierigkeiten bereitet, die Erfassung der Beziehungen.

4.6

Beziehungen - vertieft

Am Anfang der Modellierung steht immer die Festlegung von Entitaten und Beziehungen, die dann im weiteren zu Typen zusammengefasst werden. Entitaten konnen damit noch relativ leicht erkannt werden. Entweder direkt (well offensichtlich) oder durch Attribute, deren Erfassung als Ziel der Modellierung vorgegeben wird oder die fiir die gewiinschten Anwendungen notig sind. Schwieriger ist es mit Beziehungen. Einige Beispiele: LIEFERT in einer Datenbank mit Produkten und Kunden BIETET__AN in einer Datenbank zu Datenbanksystemen oder OnlineDatenbanken LEITET__ABTEILUNGundARBEITETJN in einer Datenbank zu den Mitarbeitem eines Unternehmens Die Beispiele machen deutlich: Beziehungen in Datenbanken setzen Entitaten verschiedener Entitatstypen miteinander in Beziehung. Manchmal auch nur die eines Entitatstyps, z.B. in LEITET_ABTEILUNG oder die mehrerer, z.B. in dem in der Literatur vielzitierten Beispiel einer Datenbank zu Projekten, Teilen und Lieferanten, wenn festgehalten werden soil, welches Teil von welchem Lieferanten in welches Projekt geliefert

4.6 Beziehungen - vertieft

153

wird. Hierbei entsteht eine dreisteUige Beziehung zwischen den Entitatstypen. Dieses „in Beziehung setzen" kann naturlich auch auf einem realen Vorgang beruhen, wie in dem oben angeftihrten Beispiel LIEFERT. Oftmals ist es aber nicht einfach zu entscheiden, was Entitat und was Beziehung ist und schon kleine Anderungen der Semantik konnen das Datenmodell andem. Dies soil an einem Beispiel veranschaulicht werden. Nehmen wir als Beispiel Transportvorgange in einem Transportunternehmen. Stehen die Transporte im Vordergrund, konnte es in sehr einfacher Form (vielleicht fur einen Fahrradkurier) wie in der folgenden Abbildung (Losung 1) modelliert werden. Fur jeden Transport werden Absender- und Empfangemame, Zeitpunkt des Transports und weitere Attribute erhoben, die den Transportvorgang selbst beschreiben. AuBerdem werden die Transporte durchnummeriert, was einen problemlosen SchlUssel liefert.

Beispiel: Transporte Variante 1

C^ameEmpfanget Abbildung 4.6-1: Losung 1 - Transport als solcher Fiir den nachsten Schritt nehmen wir an, dass Absender und Empfanger detaillierter beschrieben werden sollen und dass sie auch unterschiedliche Attribute haben, z.B. weil die einen hauptsachlich Untemehmen und die anderen Privatleute sind. Dann ware eine Modellierung wie in der nachsten Abbildung denkbar.

Empfanger

^3 Abbildung 4.6-2: Losung 2 - Absender und Empfanger Es entstehen zwei verschiedene Entitatstypen (mit Schlusseln, die den Absender oder Empfanger identifizieren: IdAbs und IdEmpf) und der Transportvorgang wird durch einen Beziehungstyp erfasst.

Variante 2

154

VarianteS

4 Entity Relationship - Modellierung

Eine weitere Variante zeigt die folgende Abbildung. Sie ist sinnvoll, wenn Absender und Empfanger durch dieselben Attribute beschrieben werden, d.h., wenn sie (datenbanktechnisch) „gleich" sind. Dann mussen sie zu einem einzigen Entitatstyp KUNDEN zusammengefasst werden auf dem sich eine rekursive Beziehung TRANSPORTE befmdet.

Abbildung 4.6-3:

Variante4

Losung 3 Transporte als Kontakte zwischen Kunden

Zu losen bleibt hier noch das Problem der Identifizierung einzelner Transporte. Entweder durch Zusammenfassen der Informationen zu Absender, Empfanger und Zeitpunkt oder durch Einfuhrung eines Attributs IdTransport. Sind sich die KUNDEN beztiglich ihrer Attribute weitgehend aber nicht vollstandig gleich, konnte auch eine Generalisierung/Spezialisierung eingefiihrt werden. Dies zeigt die folgende Abbildung. Hier wurde angenommen, dass sich die Kunden sinnvoll in private und gewerbliche Kunden unterteilen lassen. In letzteren konnen dann noch die GroBkunden separiert werden.

4.7 Beispiel „Sportverein"

155

GroBkunden er15

Abbildung 4.6-4:

Losung 4 - Spezialisierungen

Mit obigen Beispielen sollte deutlich geworden sein, dass gerade bei Beziehungen kleine Anderungen in der Semantik zu groBen Anderungen des Datenmodells fuhren konnen.

4.7

Beispiel „Sportverein"

Mit dem folgenden Beispiel soil auch der Entstehungsprozess eines Datenmodells gezeigt werden - seine Entwicklung „Schritt um Schritt". In vollem Umfang, mit alien Einzelschritten und an einem realen Beispiel, ist dies aus Platzgrunden nicht moglich. Trotzdem sollte das Beispiel einen Eindruck davon geben, wie Datenmodelle entstehen. Aus vielen Diskussionen mit Teilnehmern von Schulungen und Studierenden in Vorlesungen weiB ich, dass reale Sportvereine eine viel reichere und tiefere Semantik haben. Ich bitte daher vor allem alle Sportvereinsmitglieder um Verzeihung fur die Einfachheit des Beispiels, denke aber, dass es trotzdem seine Aufgabe erfiillen kann.

156

Beispiel Sportverein

Ein Sportverein beschlieBt, seine Aktivitaten (Mitgliederverwaltung, Sportveranstaltungen, usw. ) in Zukunft computergestutzt abzuwickeln. Dazu soil im ersten Schritt eine einfache Datenbank aufgebaut werden, fiir die folgende Spezifikationen festgehalten werden: • • • • • • •

Erste Schritte

Entitaten und Entitatstypen erkennen

4 Entity Relationship - Modellierung

Der Sportverein ist in Abteilungen gegliedert. Eine fur Handball, eine fur FuBball. Weitere konnen in der Zukunft dazukommen. Jede Abteilung hat einen Leiter. Jede Abteilung hat mehrere Mannschaften. Von jeder Mannschaft werden die Spieler, der Kapitan und die Liga festgehalten, in der sie spielt (Bundesliga, usw.) Jede Mannschaft hat einen Trainer. Die Begegnungen von Mannschaften des Vereins mit Datum, gegnerischer Mannschaft und Ergebnis sollen festgehalten werden. Die Mitglieder des Vereins werden durch Name, Vomame, PLZ, Ort, StraBe, Telefon, Geburtstag, Alter und eine Mitgliedsnummer festgehalten.

AuBerdem wird fur die Mitglieder erfasst, ob es sich um ein passives oder ein aktives Mitglied handelt. Fiir jedes aktive Mitglied wird dann noch festgehalten, welche Sportart es in welcher Leistungsstufe betreibt; fur die passiven Mitglieder wird erfasst, fiir welche ehrenamtliche Tatigkeit sie zur Verfugung stehen. Wie sehen nun die konkreten Modellierungsschritte aus? SinnvoU ist es, zuerst die Entitatstypen zu suchen. Dies ist dann allerdings keine endgultige Festlegung, sondern eine, die im Verlauf der Modellierung auch wieder korrigiert werden kann. Beginnen wir also mit Entitaten und Entitatstypen. Diese erkennt man im modellierungstechnischen Sinne daran, dass es sich erstens um Objekte im allgemeinen Sinn handelt und dass zweitens diese Objekte durch Attribute beschrieben werden. Zweiteres ist von zentraler Bedeutung, denn sonst kann es sich auch um ein Attribut handeln, wie auch dieses Beispiel gleich zeigen wird. Natiirlich etablieren auch andere nicht-konventionelle Attribute einen Entitatstyp. Z.B. Grafiken, Bilder, Videos, usw. Allerdings sind diese nur Erganzungen der Basisbeschreibung durch Attribute, die auf jeden Fall vorhanden sein muss. Hier ist ein Entitatstyp sofort erkennbar, die MITGLIEDER. Die Vereinsmitglieder existieren - auch im allgemeinen Sinn - und sie werden durch Attribute beschrieben:

4.7 Beispiel „Sportverein"

157

Mitglieder ^ebTag)

/ er2i

(Alter

Abbildung 4.7-1:

)

Modellierung der Mitglieder

Offen bleibt nun noch die Frage, wie die Eigenschaft, aktives oder passives Vereinsmitglied zu sein, erfasst wird. Ginge es nur um diese Eigenschaft, wiirde einfach ein Attribut „aktiv/passiv" mit diesen zwei Eigenschaften an den Entitatstyp MITGLIEDER angefiigt. Nun ist es hier aber so, dass fur die aktiven und passiven Mitglieder jeweils unterschiedliche Attribute festgehalten werden sollen. Deshalb miissen diese Teilgruppen der Mitglieder getrennt erfasst und - da sie ja als Mitglieder auch gemeinsame Attribute haben - in der im ersten Teil vorgestellten Notation als Generalisierung/Spezialisierung angelegt werden: Nr

Status.

Mitglieder

Aktive Mitglieder

Abbildung 4.7-2:

Passive Mitglieder

Aktive und Passive Mitglieder in einer Generalisierung / Spezialisierung

aktiv / passiv

158

4 Entity Relationship - Modellierung

Differenzierung

Soweit der erste Entitatstyp MITGLIEDER. Hinzugenommen wurde ein Attribut Status mit den Auspragungen/^a^^-Zv und aktiv, mit dem es moglich ist, die allgemeinen Attribute (Adressen) der beiden Gruppen gezielt anzusprechen.

Hinweis:

Das Attribut mit den Punkten soli oben und im folgenden die schon vorhereingefuhrten Attribute andeuten.

Totale Beteiligung

Die Mannschaften

Die aktiven Mitglieder erhalten die Attribute Sportart (derzeit nur Handball Oder FuBball) und Leistungsstand. Es wird davon ausgegangen, dass ein Spieler nur eine Sportart betreibt. Das Attribut ehrenamtliche Tatigkeit der passiven Mitglieder erfasst in einer irgendwie verkodeten Form, fiir was das Mitglied zur Verftigung steht. Es handelt sich um ein mehrwertiges Attribut. Oftmals mochte man bei einer Spezialisierung ausdriicken, dass alle Entitaten des tibergeordneten Typs an der Spezialisierung teilnehmen mtissen. Dies geschieht, wie in der obigen Abbildung, durch einen Doppelstrich zwischen dem tibergeordneten Typ und dem d-Kreis. Er signalisiert hier, dass alle Mitglieder entweder aktive oder passive Mitglieder sein mussen. Eine andere Mitgliedschaft gibt es somit modelltechnisch nicht. Alternativ konnten hier statt der Spezialisierung PASSIVE MITGLIEDER nur die ehrenamtlich tatigen Mitglieder erfasst sein. Dann mtisste der Doppelstrich beseitigt werden, da es dann Mitglieder gabe, die in keine der beiden Spezialisierungen eingehen (die passiven, die nicht ehrenamtlich tatig sind). Bei Beziehungen wird „totale Beteiligung" durch die Min-/MaxAngaben festgelegt. Steht als Mindestwert ein Wert groBer 0 da, mtissen alle Entitaten des Entitatstyps an der Verbindung teilhaben. Betrachten wir nun die Mannschaften. Sie tauchen mit folgenden Beschreibungen auf: • •

Jede Abteilung hat mehrere Mannschaften, insofem konnte „Mannschaft" ein Attribut von Abteilung sein. Von jeder Mannschaft werden Spieler, Kapitan, Liga, Trainer und Begegnungen festgehalten.

Letzteres macht die Mannschaften zu Entitatstypen, da sie durch weitere Attribute beschrieben werden. Die Klarung der Frage, ob sie evtl. ein Beziehungstyp sein konnen, wird auf eine spatere Phase des Modellierungsvorgangs verschoben. Damit ergibt sich folgender erster Entwurf:

4.7 Beispiel „Sportverein"

159

Mannschaften

Abbildung 4.7-3:

Entitatstyp MANNSCHAFTEN

Hinzugefiigt wurde ein Attribut Name, mit der Bezeichnung der Mannschaften. Das Attribut Spieler ist mehrwertig, da jede Mannschaft mehrere Spieler hat. Auf die Aufiiahme eines Attributs Begegnung wurde verzichtet, da die Begegnungen durch weitere Attribute zu einer eigenstandigen Existenz kommen. Im beschreibenden Text wurde festgelegt, dass alle Begegnungen von Mannschaften des Vereins mit Tagesdatum, Gegner und Ergebnis festgehalten werden sollen. Damit entsteht ein entsprechender Entitatstyp. Gleichzeitig wird hier der erste Beziehungstyp deutlich, der mit M_B bezeichnet werden soil und schlicht die Tatsache beschreibt, dass die Mannschaften des Vereins an den Begegnungen teilnehmen. Da auch nur solche Begegnungen erfasst werden, handelt es sich um einen singularen Entitatstyp, der durch ein Rechteck mit Doppellinie dargestellt wird. Der zugehorige Beziehungstyp erhalt ebenfalls eine solche.

Abbildung 4.7-4:

Singularer Entitatstyp BEGEGNUNGEN

Das Attribut Beg inn wurde zusatzlich aufgenommen, um mehrere Begegnungen an einem Tag, z.B. im Rahmen eines Tumiers, unterscheiden zu konnen. Schltissel ftir diesen Entitatstyp sind die Attribute Tag, Beginn und Gegner zusammen. Zu beachten ist, dass es nur um die Spiele des betrachteten Vereins geht, nicht um alle Spiele einer Liga, was die Situation verandem wiirde.

Begegnungen

160

Abteilungen

4 Entity Relationship - Modellierung

Als Schlussel wurde hier ein zusammengesetzter genommen, der bei der Uberfiihrung in konkretere Strukturen (Z.B. in Relationen) um den Schlussel von MANNSCHAFTEN erganzt werden musste. Dies ist typisch fur singulare Entitatstypen. Ihre Existenzabhangigkeit zeigt sich auch darin, dass ihr Schlussel um den des anderen Entitatstyps erganzt werden muss, Jetzt mussen noch die Abteilungen betrachtet werden. Ftir sie wurde oben festgehalten, dass der Verein in Abteilungen gegliedert ist (Handball und FuBball), dass jede Abteilung eine/n Leiter/in und mehrere Mannschaften hat. In Konfrontation mit den schon erstellten Modellfragmenten lasst sich damit festhalten, dass ABTEILUNGEN ein Entitatstyp mit den Attributen Leiter und Sportart ist. Die Tatsache, welche Mannschaft zu welcher Abteilung gehort, wird nicht durch ein Attribut festgehalten, sondern durch einen Beziehungstyp M_A zwischen MANNSCHAFTEN und ABTEILUNGEN:

Abbildung 4.7-5:

Mannschaften in Abteilungen

Damit sind die wichtigsten Komponenten des zu erstellenden Datenmodells realisiert. In der folgenden Abbildung werden sie zusammengestellt. Die Min-/Max-Angaben in der Abbildung haben folgende Bedeutung: • •

•

1,1 bei MANNSCHAFTEN -> ABTEILUNGEN (M_A): Eine Mannschaft gehort zu genau einer Abteilung. 0,n bei MANNSCHAFTEN -> BEGEGNUNGEN (M_B): Eine Mannschaft hat an keiner (z.B., wenn sie neu aufgestellt wurde) oder an mehreren Begegnungen teilgenommen. 1,1 bei BEGEGNUNGEN ^ MANNSCHAFTEN (M_B): Eine Begegnung wird nur dann als solche aufgenommen, wenn genau eine Mannschaft „unseres" Vereins teilgenommen hat. Wir schlieBen hier

4.7 Beispiel „Sportverein"

•

161

also bewusst Begegnungen zwischen zwei Mannschaften des Vereins aus. l,n bei ABTEILUNGEN ^ MANNSCHAFTEN (M_A): Eine Abteilung hat mindestens eine Mannschaft.

.-/.— ( Alter )

Aktive Mjtglieder

Abbildung 4.7-6:

Passive Mitglieder

Gesamtmodell SPORTVEREIN - Erster Versuch

162

Defizit: Trennung

Dieses Gesamtmodell ist nun aber in einem wichtigen Punkt fehlerhaft: Eine Trennung eines Datenmodells in zwei unverbundene Teile ist nicht moglich. So etwas gibt es nicht, da ein Datenmodell ja gerade dadurch ausgezeichnet ist, dass zusammengehorige Informationen iiber einen Weltausschnitt verwaltet werden. Sonst sind es zwei Datenmodelle mit zwei verschiedenen Datenbanken. Bei genauerer Betrachtung zeigt sich nun aber, dass natUrlich die Mitglieder mit den organisatorischen Aspekten des Vereins auf vielfaltige Weise verkniipft sind. Insbesondere sind dies folgende Aspekte: • • • •

Verschmelzung

4 Entity Relationship - Modellierung

Aktive Mitglieder spielen in Mannschaften Aktive Mitglieder konnen Kapitan einer Mannschaft sein Aktive Mitglieder trainieren die Mannschaften (wir gehen davon aus, dass die Trainer als aktive Mitglieder zum Verein gehoren) Aktive Mitglieder leiten die Abteilungen

Alle diese Informationen wurden im obigen ersten Entwurf - herruhrend von den Modellkomponenten - als Attribute von Entitatstypen defmiert. Dies muss nun geandert werden. Beginnen wir mit den Spielem der Mannschaften. Diese Information sollte nicht als mehrwertiges Attribut von MANNSCHAFTEN erfasst werden, sondem als Beziehungstyp zwischen MANNSCHAFTEN und AKTIVE MITGLIEDER: AM_S. Damit ist nicht nur die Information der Mannschaftszugehorigkeit eindeutig erfasst, sondem es stehen auch die Adressen der Mannschaftsmitglieder zur Verftigung und die Namen der Spieler werden nur einmal erfasst, im Mitgliederverzeichnis, wo sie hingehoren. Ganz ahnlich bei der Erfassung der Trainer. Bisher als Attribut von Mannschaft erfasst, werden sie nun zu einer Beziehung zwischen Trainem und Mannschaften: AM_T. Die Kapitane der Mannschaften werden ebenfalls durch eine Beziehung zwischen MANNSCHAFTEN und AKTIVE MITGLIEDER erfasst, AM_K, denn die Kapitane sollen in unserem Datenmodell aktive Mitglieder sein. Die Leiter der Abteilungen werden dementsprechend als Beziehung zwischen ABTEILUNGEN und AKTIVE MITGLIEDER erfasst: AM^A. In der folgenden Abbildung nun das Gesamtmodell mit den besprochenen Korrekturen. Weggefallen sind nun die diversen Attribute, mit denen vorher die Beziehungen festgelegt wurden. Die weiteren Min/Max-Angaben sind ebenfalls angegeben. Sie bedeuten: •

0,1 bei AKTIVE MITGLIEDER -> MANNSCHAFTEN und Beziehung AM_S: Ein aktives Mitglied spielt in maximal einer Mannschaft. Selbstverstandlich ware an der zweiten Position auch ein hoherer Wert moglich, falls die Semantik es erfordert. Ebenso ein Wert groBer Null an der ersten Position.

4.7 Beispiel „Sportverein"

163

0,1 bei AKTIVE MITGLIEDER -» MANNSCHAFTEN und Beziehung AM_T: Ein aktives Mitglied kann in maximal einer Mannschaft Trainer sein^^. 0,1 bei AKTIVE MITGLIEDER ^ MANNSCHAFTEN und Beziehung AM_K: Ein aktives Mitglied ist in maximal einer Mannschaft Kapitan. 0,1 bei AKTIVE MITGLIEDER ^ ABTEILUNGEN und Beziehung AM__A: Ein aktives Mitglied leitet maximal eine Abteilung. 1,1 bei MANNSCHAFTEN -> AKTIVE MITGLIEDER und Beziehung AM_T: Eine Mannschaft wird von genau einem aktiven Mitglied trainiert. 11,15 bei MANNSCHAFTEN -> AKTIVE MITGLIEDER und Beziehung AM__S: Eine Mannschaft besteht aus mindestens 11 und maximal 15 Spielem (aktive Mitglieder). 0,1 bei MANNSCHAFTEN •» AKTIVE MITGLIEDER und Beziehung AM_K: Eine Mannschaft hat maximal einen Kapitan.

82

Fur diese und die anderen Festlegungen gilt, dass die Semantik naturlich auch anders sein kann.

164

4 Entity Relationship - Modellierung

C^aa^T)

(^rname^

V $ ^

(Nachname]])

j:^Ort^

Mitglieder

— ^ - — < (^ebTag;

j

('"Alter")

^ress^)

CPLZ^

J

YstraBO

Aktive Mitglieder

Passive Mitglieder

O ^ g , Beginn, G e g n e r ^ 11.15 Begegnungen

Abbildung 4.7-7:

Entity Relationship-Modell SPORTVEREIN

4.8 Die Zeit in Datenmodellen

4.8

165

Die Zeit in Datenmodellen

Ein wirklich pragendes Element unserer Wirklichkeit ist die Zeitachse. Deshalb ist die Fixierung von Informationen auf Zeitpunkte, die Erfassung der historischen Dimension des Weltausschnitts, fiir viele Datenmodelle von groBer Bedeutung. Bei einer Standardmodellierung wie oben ist sie allerdings nicht von vomeherein dabei. Oben ist dies nur beim Entitatstyp BEGEGNUNGEN der Fall, weil diese Entitaten ohne zeitliche Festlegung nicht vorstellbar sind. Bei alien Ubrigen Entitats- und Beziehungstypen wurde so modelliert, dass jeweils nur die aktuellen Daten erfasst werden. Um dies zu verdeutlichen: Wechselt im Sportvereinsbeispiel ein Mitglied seine Adresse, wird die neue eingetragen, die alte ist tiberschrieben. Andert ein Mitglied seinen Namen, wird der alte tiberschrieben. Und so weiter. Standardmodellierung bedeutet meist, dass Datenbanken entstehen, die den aktuellen Stand erfassen, nicht mehr. Wie konnte die Beriicksichtigung zeitlicher Aspekte bei solchen Entitats- und Beziehungstypen aussehen (vgl. auch Abschnitt 3.24)? Geht es um Zeitabschnitte kann der Anfang und das Ende als Attribut festgehalten werden. Z.B. konnten bei den Vereinsmitgliedem im obigen Beispiel auch die erfasst bleiben, die friiher Mitglieder waren und die dies durch Austritt, Wegzug oder Tod nicht mehr sind. Realisiert werden konnte dies durch zwei Attribute Eintritt und Austritt, die in der Abbildung hervorgehoben wurden. Fiir alle aktiven Mitglieder miisste Austritt auf einen Nullwert gesetzt werden.

Mitglieder

Abbildung 4.8-1:

Zeitliche Aspekte bei Entitatstypen

Eine solche Erweiterung hat naturlich Konsequenzen, die hier nur angedeutet werden konnen. Hier z.B. die, dass die totale Beteiligung an den beiden Subklassen natiirlich nicht mehr gegeben ist, da die ehemaligen Mitglieder weder aktiv noch passiv sind.

Nur der aktuelle Stand

Erfassung Zeitabschnitt

166

4 Entity Relationship - Modellierung

Die gleiche Losung kann fiir Beziehungen gewahlt werden. Soil z.B. festgehalten werden, wer fruher eine Mannschaft trainiert hat, muss der Beziehungstyp TRAINIEREN erweitert werden um zwei Attribute von und bis, die das jeweilige Datum festhalten.

Mannschaften Abbildung 4.8-2:

RegelverstoB?

Immer wachsend

Aktive Mitglieder

Historische Aspekte bei Beziehungstypen

Hier werden ebenfalls die weiteren Konsequenzen einer Einfuhrung der Zeitachse deutlich. So wie der obige Modellausschnitt jetzt vorliegt, konnen nur von den aktiven Mitgliedem die historischen Daten erhoben werden, die noch im Verein sind. Ansonsten mussten bei den aktiven Mitgliedem ebenfalls Datumswerte aufgenommen werden. Dasselbe gilt fur die Mannschaften. Grundsatzlich gilt fur Attribute, die einen Zeitabschnitt festlegen, dass das Attribut fur die Festlegung des Endzeitpunktes erst Gtiltigkeit erlangt, wenn das Ende des Zeitabschnitts erreicht ist. Dies ist ein VerstoB gegen die oben eingeflihrte Kegel, dass ein Attribut (immer) ^ r alle Entitaten Gtiltigkeit haben muss. Im obigen Beispiel zu den Mitgliedem kann das Attribut Austritt erst einen Eintrag erfahren, wenn der beschriebene Tatbestand eintritt. Mit diesem „RegelverstoB" muss man allerdings im Falle der Erfassung von Zeitabschnitten leben. D.h., es gibt in der Datenbank Felder, die entsprechende Nulleintrage enthalten. Fur alle Datenbanken mit Zeitpunkten gilt, dass jede einzelne Information zeitlich fixiert ist und nicht geloscht wird, wenn dieselbe Information wieder anfallt: Der Umsatz des Februars tiberschreibt nicht den des Januars. Die neue Adresse des Vereinsmitglieds uberschreibt nicht die alte. Insofern wachsen diese Datenbanken standig, die schon vorhandenen Daten werden nicht tiberschrieben.

4.9

Gleichzeitig Entitat und Beziehung

Es kommt vor, dass ein Realweltphanomen in einem Datenmodell gleichzeitig als Entitatstyp und als Beziehungstyp benotigt wird. In diesem Fall wird in der grafischen Darstellung ein neues Element genutzt. Das Beispiel hierzu stammt aus [Stickel 1991, S. 100]. Der betrachtete Weltausschnitt ist eine Theateragentur, die fur beliebige Theater und Stiicke Karten an ihre Kunden verkauft.

4.9 Gleichzeitig Entitat und Beziehung

167

Die folgende Abbildung zeigt die Ausgangssituation. Auf der Hnken Seite wurde modelHert, dass Kunden fur bestimmte Vorstellungen Karten kaufen. Dazu wurden die Entitatstypen KUNDEN und VORSTELLUNGEN angelegt, die durch einen Beziehungstyp KARTEN verkntipft sind. Dies ist durchaus folgerichtig. Auf der rechten Seite wurden THEATER, S T O C K E und ihre Beziehung modelliert. Dabei muss dann der Entitatstyp THEATER mit dem Entitatstyp STUCKE verkntipft werden. Aus der Sicht einer Theateragentur muss dies uber die Vorstellungen erfolgen, da diese ja verkauft werden: Ein Stiick (z.B. Faust I) wird in einem Theater (z.B. Stadttheater Konstanz) aufgefiihrt und fur diese Vorstellung werden Karten verkauft. Somit ergibt sich, dass VORSTELLUNGEN gleichzeitig als Entitatsund Beziehungstyp benotigt werden.

Die Kunden kaufen Karten fur bestimmte Vorstellungen.

In einem Ttieater werden StCicke aufgefiihrt. Ein bestimmtes Stuck kann in verschiedenen Theatern aufgefuhrt werden.

Vorstellungen

Abbildung 4.9-1:

Entitats- oder Beziehungstyp?

Ein weiteres theoretisches und grafisches Konstrukt lost dieses Problem. Es ist in der folgenden Abbildung angegeben. In der grafischen Notation werden das Rechteck des Entitatstyps und die Raute des Beziehungstyps tibereinander gelegt.

168

4 Entity Relationship - Modellierung

Nr

Kunden 0,n

Name

Theater 0,n

IXOa^^ Das neue Element fur Realweltph&nomene, die gleichzeitig Beziehung and EntiWt sind.

Abbildung 4.9-2:

Entitats- und Beziehungstyp

4.10 Hinweise zur Fehlervermeidung Schlanke Losung

Im Rahmen einer Datenmodellierung gibt es oftmals mehrere Altemativen, die unterschiedlich umfangreich sind, im Grunde aber dasselbe beschreiben. In einem solchen Fall muss immer die einfachste Losung gewahlt werden. So kann z.B. ein Beziehungstyp oftmals aufgespaltet werden in einen Entitatstyp und zwei weitere Beziehungstypen wie im ft)lgenden Beispiel.

4.10 Hinweise zur Fehlervermeidung

169

Losung 1 Mitglieder

Mannschaften

Losung 2 Mannschaften

Abbildung 4.10-1:

Spieltatigkeit

Mitglieder

Richtige („schlanke") und falsche Losung

In diesem Beispiel ist Losung 1 die Richtige! Oftmals werden Entitatstypen verknupft, weil eine vage nebulose Vorstellung besteht, dass diese zusammenhangen. Mit vagen Vorstellungen lasst sich aber nicht modellieren. Deshalb miissen Beziehungen zwischen Entitatstypen immer daraufhin uberpriift werden, ob sie auch semantisch sinnvoll sind, am besten, indem man sie auf ihren Kern, Beziehungen zwischen ganz konkreten Entitaten, zuriickfiihrt. Das ft)lgende Beispiel bezieht sich auf den oben diskutierten Weltausschnitt eines Sportvereins.

Abteilungen

H

Mannschaften

,VA

f^v.s<^ Begegnungen

Abbildung 4.10-2:

Intuition statt Modellierung

Aktive Mitglieder

Unklare Beziehungen

170

Nur statische Aspekte modellieren

Spezialisierung durch verschachtelte Attribute

4 Entity Relationship - Modellierung

Richtig ist hier lediglich, dass die Raute naturlich irgendeine Beziehung ausdruckt. Bei genauerem Hinsehen erkannt man aber, dass es sich in Wirklichkeit um eine Vielzahl von Beziehungen handelt, die man vielleicht allgemein unter dem Begriff Vereinstdtigkeit zusammenfassen konnte. Konkret werden hier so unterschiedliche Beziehungen zusammengefasst wie „Mannschaften werden von aktiven Mitgliedem trainiert", „Mannschaften sind in Abteilungen", „Mannschaften nehmen an Begegnungen teil". Wie kann solch ein Fehler vermieden werden? Ganz einfach, indem man sich uber die Natur von Beziehungen in ER-Modellen klar wird. Diese ist ganz einfach (vgl. auch Abschnitt 4.6): Beziehungstypen in ERModellen setzen Entitaten des einen Entitatstyps mit Entitaten des anderen Entitatstyps (oder: der anderen Entitatstypen) in Beziehung und sie drucken jeweils NUR EINE Beziehung aus. Man muss also lediglich auf die Entitaten zuruckgehen und mit diesen die Beziehung uberprufen (deshalb ist die Betrachtung der Min-/Max-Angaben so hilfreich), dann kann eigentlich nichts mehr schief gehen. Ein ER-Modell ist ein Datenmodell und erfasst als solches nur die statischen Aspekte des Weltausschnitts, d.h. die Beschreibung der Entitaten und Beziehungen durch Attribute. Dynamische Aspekte (Ablaufe, Prozeduren, Prozesse, ...) werden von einem Datenmodell nicht erfasst. Diese Techniken gehoren in den Bereich der Systemanalyse. Nichtsdestotrotz ist der Verfasser der Auffassung, dass sich Datenmodellierung in der Zukunft auch um Prozesse, usw. klimmem muss und dass die konkrete Datenmodellierung der Zukunft eine umfassendere Modellierung der Strukturen und Prozesse des jeweiligen Weltausschnitts sein wird. Verschiedene Grlinde lassen dies vermuten. Der wichtigste ist, dass die vollstandige Verlagerung der dynamischen Aspekte in die Anwendungsprogramme sehr viel aufwendiger ist (bei der Entwicklung und der Wartung), als die zumindest teilweise direkte Realisierung im Datenmodell und dann in der Datenbank. Einen ersten Vorgeschmack gibt diesbezuglich die objektorientierte Modellierung (vgl. Kapitel 7). Oftmals sieht man in Datenmodellen auch „verschachtelte Attribute", die in Wirklichkeit eine Spezialisierung widerspiegeln. Ein Beispiel zeigt die folgende Abbildung. Dieser Modellausschnitt ist naturlich falsch. Gegen das Attribut aktiv/passiv ist erst mal nichts einzuwenden. Die Attribute Sportart, Leistungsstand und ehrenamtliche Tatigkeit wurden nun aber falschlicherweise mit dem Attribut aktiv/passiv verknupft, mit der Absicht, damit die aktiven bzw. die passiven Mitglieder weiter zu beschreiben. Eine solche Struktur gibt es aber aus guten Grunden in der ERModellierung nicht. Attribute dtirfen auf solche Weise nur aneinandergehangt werden, wenn es sich tatsachlich um verschachtelte Attribute handelt.

4.10 Hinweise zur Fehlervermeidung

Abbildung 4.10-3:

171

Falscher "Ausbau"

Die richtige Losung fur diesen fehlerhaften Modellentwurf besteht in der oben beschriebenen Spezialisierung. Im Prinzip kann jedes Attribut dazu dienen, einen Entitatstyp (oder Beziehungstyp) in Teilklassen aufzuspalten. Nehmen wir aus dem Sportvereinsbeispiel das Attribut Sportart des Entitatstyps AKTIVE MITGLIEDER. Sportart soil zwei Auspragungen haben, „HandbaH" und „FuBbaH" wobei es aktive Mitglieder geben soil, die in beiden Sportarten mitwirken. Denkbar ware eine Aufspaltung wie in der folgenden Abbildung 4.10-4. In diesem Beispiel ist diese Losung aber falsch. Richtig ware sie nur, wenn fiir die neu eingerichteten Spezialisierungen Attribute vorliegen wiirden. So wie in der nachfolgenden Abbildung 4.10-5. Wie immer deuten die Punkte Attribute an, bei den Spezialisierungen die Spezifischen. Ist dies nicht der Fall, stellt das Spezialisierungskriterium in Wirklichkeit ein Attribut dar. Hier ist also oft eine Entscheidung daruber zu treffen, ob eine Information zu einem Attribut oder einem Entitatstyp ftihrt. Konkret bedeutet dies, dass die Eigenschaft entweder in ein Attribut oder - sozusagen in der tibergeordneten Ebene - in die Spezialisierung gelegt wird. Die Regel ist hier: keine Spezialisierung, wenn die entstehenden Subklassen keine Attribute mehr haben.

Entitaten versus Attribute

172

4 Entity Relationship - Modellierung

Mitglieder

Aktive Mitglieder

Handball

Abbildung 4.10-4: Verkniipfung von Entitatstypen

Passive Mitglieder

FuSball

Attribute vs. Entitatstypen

Verschiedene Entitatstypen konnen ausschlieBlich durch folgende Techniken in Beziehung gesetzt werden: • • •

durch einen Beziehungstyp im Rahmen einer Generalisierung/Spezialisierung im Rahmen einer Teilvon - Beziehung

Es ist insbesondere nicht moglich, Entitatstypen direkt zu verknupfen. Auf die Situation, in der Entitaten gleichzeitig Beziehungen sind, wurde oben eingegangen.

4.11 Schlussbemerkung Schritte bei der ERModellierung

Die konkreten Schritte bei der Erstellung von ER-Modellen konnen wie folgt zusammengefasst werden: • • •

Sammeln: Entitaten, Beziehungen und Attribute erkennen. Hier steckt auch die in Kapitel 2 vorgestellte konzeptionelle Phase drin. Strukturieren I: Beziehungen, Entitaten, Generalisierungen / Spezialisierungen abklaren. Strukturieren 11: Attribute zuordnen, Typen bilden. Von groBer Bedeutung ist hier die Beachtung des Zusammenhangs zwischen Attributen und Entitaten bzw. Beziehungen.

4.12 Beispiel PC-Beschaffung

•

173

Modellieren: Weitere Prazisierung von Entitats- und Beziehungstypen - im Kontext. Hier geht es u.a. darum, "vergessene" Beziehungstypen zu entdecken.

Die hier vorgestellte grafische Notation orientiert sich am Original und am „Mainstream". Es soil aber nicht verschwiegen werden, dass es, vor allem in den nicht-elementaren Teilen, zahlreiche Variationen gibt.

Aktive Mitglieder

Handball

Passive Mitglieder

FuBball

er36b

Abbildung 4.11-1:

Spezialisierungen mit Attributen

4.12 Beispiel PC-Beschaffung In einem Untemehmen soil der Vorgang der PC-Beschaffung durch eine Datenbank festgehalten werden. Dafur soil ein ER-Modell erstellt werden. Folgende Festlegungen ergaben sich in den Interviews, die im Vorfeld mit den Betroffenen gefuhrt wurden. Die Attributsnamen wurden, soweit moglich, auch gleich geklart:

Hinweis

174

4 Entity Relationship - Modellierung

•

Jeder PC erhalt eine Inventamummer (InvPC), die sich allerdings nicht auf den jeweiligen Bildschirm bezieht. Bildschirme erhalten eine eigene Inventamummer (InvBild). Jedem PC ist genau ein Bildschirm zugeordnet. • Fur jeden PC wird foigendes festgehalten: der Prozessortyp (PROZ), die GroBe des Arbeitsspeichers (ARBSP), ob ein CD-ROM - Laufwerk vorhanden ist und falls ja, welche Bezeichnung und welche Geschwindigkeit (CDROM__BEZ bzw. GESCHW) es hat. AuBerdem werden jeweils mit Hilfe einer Kurzbezeichnung (KBezSK) die sonstigen Komponenten (Streamer, SoundBlaster, usw.) festgehalten. Jede dieser Komponenten ist genau einem PC zugeordnet. Ein PC hat naturlich typischerweise mehrere. • Ftir jede Festplatte wird festgehalten: Name und GroBe (PIName, GroUe) sowie die Zugriffsgeschwindigkeit (Zugriff). Es kommt vor, dass ein PC mehrere Festplatten hat (aber nicht umgekehrt). • Ftir jeden PC wird weiterhin festgehalten, in welcher Abteilung er steht (Abteilung), wer ihn nutzt (erfasst liber die PersNr) und wann er dort eingerichtet wurde (Einrichtung). Es kommt vor, wenn auch nicht oft, dass ein PC von mehreren Mitarbeitem genutzt wird. Allerdings ist er immer einer einzigen Abteilung zugewiesen. • Die Nutzer werden durch ihre Personalnummer (PersNr), den Namen (Name, Vorname) und ihre Telefonnummer (Tel) erfasst. • Ftir Bildschirme wird neben der Seriennummer (SerNr) festgehalten, welchen Typ (BSTyp) und welchen Durchmesser sie haben (Zoll) Einzeigeratvs. ^^

|^jj djegem Beispiel wird noch ein Nebeneffekt angestrebt. Es soil auf die Unterscheidung von Einzelobjekt und Gruppe gleichartiger Objekte (hier im weiteren nicht ganz korrekt „Typ" genannt) hingewiesen werden^^. Z.B. auf die Unterscheidung von einzelner Festplatte (identifiziert durch ihre Seriennummer) und Festplattentyp (alle gleichen). Diese Unterscheidung muss bei der Modellierung beachtet werden. Mehrdazu im Folgenden. Betrachten wir zur Erstellung des Datenmodells nochmals die Spezifikationen, Schritt um Schritt (jeweils eingeriickt): • Jeder PC erhalt eine Inventamummer (InvPC), die sich allerdings nicht auf den jeweiligen Bildschirm bezieht. Bildschirme erhalten eine eigene Inventamummer (InvBild). Jedem PC ist genau ein Bildschirm zugeordnet.

Diese Unterscheidung ist wichtiger Bestandteii unserer Welt, genauer: unserer Wahrnehmung dieser Welt. Sie beruht auf dem, was auch Kategorisierung genannt wird. Wir treffen sie nicht nur in „technischen Weltausschnitten" an, sondern z.B. auch in der Biologic, als Unterscheidung zwischen einzelner Pflanze oder einzelnem Tier und der jeweiligen Gattung.

4.12 Beispiel PC-Beschaffung

175

Hier werden zwei potentielle Entitatstypen direkt durch identifizierende Attribute angesprochen. Um zu erkennen, ob tatsachlich Entitatstypen entstehen, priifen wir die ubrigen Texte und erkennen, dass schon in der nachsten Spezifikation Attribute von PCs genannt werden. Also entsteht ein Entitatstyp PC. Bei den Bildschirmen mtissen wir langer suchen. Erst in der letzten Spezifikation tauchen weitere Attribute fur die Bildschirme auf: • Fiir Bildschirme wird neben der Seriennummer (SerNr) festgehalten, welchen Typ (BSTyp) und welchen Durchmesser sie haben (Zoll) Damit ergibt sich ein Entitatstyps BILDSCHIRME. Ohne diese weiteren Attribute ware InvBild einfach ein Attribut von PC. InvBild^ Bildschirme

Abbildung 4.12-1:

rC^!L5

Entitatstyp BILDSCHIRME

AuBerdem ergibt sich damit gleich ein Beziehungstyp, denn PCs und Bildschirme sind ja verkniipft und wir mtissen sicherlich festhalten, welcher Bildschirm an welchem PC dient. Dazu unten mehr. Mit Hilfe des folgenden Ausschnitts aus der Spezifikation erganzen wir nun die Beschreibung des Entitatstyps PC um die angegebenen Attribute. Unkritisch sind die Attribute Proz und ArbSp. Doch was ist mit den CD-ROM - Laufwerken und mit den „sonstigen Komponenten"? • Fiir jeden PC wird folgendes festgehalten: der Prozessortyp (PROZ), die GroBe des Arbeitsspeichers (ARBSP), ob ein CD-ROM - Laufwerk vorhanden ist und falls ja, welche Bezeichnung (CDROM__BEZ) und welche Geschwindigkeit (GESCHW) es hat. AuBerdem werden jeweils mit Hilfe einer Kurzbezeichnung (KBezSK) die sonstigen Komponenten (Streamer, SoundBlaster, usw.) festgehalten. Jede dieser Komponenten ist genau einem PC zugeordnet. Ein PC hat natUrlich typischerweise mehrere. Die CD-ROM - Laufwerke kommen modellierungstechnisch zu einer eigenen Existenz, da sie identifiziert und beschrieben werden. Also entsteht ein Entitatstyp CD-ROM-LAUFWERKE. Damit ist auch die Frage beantwortet, wie festgehalten wird, ob ein PC eines hat oder nicht: Uber die Beziehung zwischen PC und CD-ROM-LAUFWERKE.

Identifikation + Beschreibung -> Existenz

176

4 Entity Relationship - Modellierung

CD-ROM Laufwerke Abbildung 4.12-2:

Entitatstyp CD-ROM - LAUFWERKE

Fiir die sonstigen Komponenten ist die Situation einfacher. Da sie nur durch eine Kurzbezeichnung KBezSK identifiziert werden, entsteht hier einfach ein Attribut von PC, allerdings ein mehrwertiges, wie der Text auch ausdriicklich festhalt. Insgesamt ergibt sich damit der Entitatstyp PC (erst mal) wie folgt:

Abbildung 4.12-3: Festplatten

Entitatstyp PC - Version 1

Der nachste Abschnitt der Spezifikation legt fest, wie die Festplatten erfasst werden: • Fiir jede Festplatte wird festgehalten: Name und GroBe (PIName, GroUe), die Zugriffsgeschwindigkeit (Zugriff). Es kommt durchaus vor, dass ein PC mehrere Festplatten hat (aber nicht umgekehrt). Sie werden zu einem eigenen Entitatstyp FESTPLATTEN. Die Entitaten werden durch den Namen der Festplatte identifiziert und durch die Plattenkapazitat und die Zugriffsgeschwindigkeit beschrieben.

4.12 Beispiel PC-Beschaffung

177

Festplatten

Abbildung 4.12-4:

Entitatstyp FESTPLATTEN

Der folgende Ausschnitt aus der Spezifikation klart das Umfeld der im Untemehmen eingesetzten PCs. • FUr jeden PC wird weiterhin festgehalten, in welcher Abteilung er steht (Abteilung), wer ihn nutzt (erfasst uber die PersNr) und warm er dort eingerichtet wurde (Einrichtung). Es kommt vor, wenn auch nicht oft, dass ein PC von mehreren Mitarbeitem genutzt wird. Allerdings ist er immer einer einzigen Abteilung zugewiesen. Betrachten wir zuerst die Angabe der Abteilung, in der er steht. Wurden irgendwo die Abteilungen noch weiter beschrieben, mtisste ein eigener Entitatstyp far sie eingerichtet werden. Da dies hier nicht der Fall ist, wird Abteilung(sname) zu einem Attribut von PC. Wie erfassen wir den oben ebenfalls angefuhrten Einrichtungszeitpunkt? Hatten wir einen Entitatstyp ABTEILUNGEN, ware alles einfach. Wir wiirden dann den Einrichtungszeitpunkt auf den Beziehungstyp zwischen ABTEILUNGEN und PC legen, denn da gehort er semantisch hin. Da hier aber die Abteilungen nicht als Entitatstyp gewunscht werden, bleibt nur die Notlosung, Einrichtung zu einem Attribut von PC zu machen.

Abbildung 4.12-5:

Entitatstyp PC - Version 2

Umfeld der PC

178

4 Entity Relationship - Modellierung

Ahnliche Uberlegungen wie bei der Klarung des Standortes (Abteilung) sind bei den Nutzem anzustellen. Sie werden in obigem Text nur tiber die Personalnummer erfasst. Insoweit ware PersNr ein Attribut von PC. Da aber im nachsten Abschnitt der Spezifikation die Nutzer weiter modelliert werden, werden sie zu einem eigenen Entitatstyp NUTZER mit den angegebenen Attributen. • Die Nutzer werden durch ihre Personalnummer (PersNr), den Namen (Name, Vorname) und ihre Telefonnummer (Tel) erfasst.

Abbildung 4.12-6:

Entitatstyp NUTZER

Damit sind die Fragmente des Datenmodells zusammengestellt. Bleibt noch der Zusammenhang, die Beziehungen zwischen den Entitatstypen. Attributsbezug?

^ j ^ . ^ Beziehung zwischen PC und BILDSCHIRMEn ist direkt im Text angegeben, bedarf aber der Klarung, ob Einzelgerate oder Gerdtetypen modelliert werden. Auf Seiten der PCs natiirlich Einzelgerate, dies zeigt auch der vorgeschlagene Schltissel. Bei den Bildschirmen? Der Schltissel InvBild deutet an, dass unsere Auftraggeber hier Einzelgerate modellieren mochten. Damit hatten wir aber Redundanz, wenn wir die Modellierung so belassen wie oben vorgeschlagen und wenn wir einfach einen Beziehungstyp zwischen PC und BILDSCHIRME platzieren. Wenn wir hundert technisch identische Bildschirme kaufen wUrden, wtirde unsere Datenbank hundertmal festhalten, dass diese (z.B.) 24 Zoll haben und vom Typ TFT sind. Wo liegt der Fehler? Ganz einfach, die vier Attribute von Bildschirme beschreiben unterschiedliche Informationstrager. InvBild und SerNr beschreiben Einzelgerate, die beiden anderen (Zoll und BSTyp) aber die Gruppe der technisch gleichen Gerdte, hier Geratetypen genannt. BSTyp kann als Schlussel genommen werden. Also muss dieser Entitatstyp in zwei aufgespaltet werden, die aber verkntipft sind (vgl. die folgende Abbildung): Ein bestimmter Bildschirm gehort zu genau einem Geratetyp, ein Geratetyp hat mindestens ein zugehoriges Gerat (sonst ware er in unserer Datenbank nicht erfasst), kann aber beliebig viele haben. Der Fehler resultierte also aus einem VerstoB gegen eine

4.12 Beispiel PC-Beschaffung

179

zentrale Kegel der ER-Modellierung, dass nur die Attribute zu einem Entitatstyp genommen werden, die genau dessen Entitaten beschreiben.

Bildschirmtypen

Bildschirme

SerNr Abbildung 4.12-7:

Einzelgerat und Gruppe gleichartiger Entitaten als Entitatstypen

Die Beziehung PC_B zwischen BILDSCHIRME und PC muss nun auf Seiten der Bildschirme 1,1 als Min-/Max-Angabe erhalten, da jetzt eine Entitat genau einen Bildschirm beschreibt und ein Bildschirm genau einem PC zugeordnet ist. Auf Seiten der PCs erhalt sie ebenfalls 1,1, da ja ein PC genau einen Bildschirm hat (vgl. die Gesamtgrafik am Schluss). Die Beziehung PC_F zwischen PC und FESTPLATTEN ergibt sich aus unserer Kenntnis der Semantik dieses Weltausschnitts. Ein PC hat Festplatten, Festplatten sind in genau einem PC (Server-Platten, die mehreren „Clients" dienen, werden hier nicht berucksichtigt). Der Schliissel von Festplatten zeigt, dass unsere Auftraggeber hier mit der Modellierung des GerditQtyps zufrieden sind (PIName). Auch die ubrigen Attribute beschreiben die Gruppe gleichartiger Flatten und nicht Einzelgerate. Soweit also alles i.O. Die Min-/Max-Angaben ergeben sich wie folgt: Bei den Festplatten muss l,n (!) stehen, da die Festplatten einer Gruppe (!) natiirlich in mehreren Rechnern sein konnen. Bei den PCs muss ebenfalls l,n stehen, da jeder PC mindestens eine Platte hat (hier genauer: eine Platte aus mindestens einer Gruppe), u.U. aber Flatten aus verschiedenen Gruppen. Z.B. zwei IBM xyz - Flatten und eine Seagate abc - Platte. Dies macht deutlich, dass die Modellierung auf Typebene nicht sehr genau ist. Wir wissen z.B. nicht, wieviele konkrete Festplatten ein PC hat. Diese Information kann auch nicht auf den Beziehungstyp gelegt werden, da dieser ja Plattentyp und PC verkniipft und z.B. festhalt, dass ein PC Flatten dreier Typen hat. Die folgende Abbildung zeigt die grafische Umsetzung dieser Uberlegungen. Die Beziehung CD__P zwischen CD-ROM - Laufwerken und PCs ist wie folgt: Der Entitatstyp CD-ROM - LAUFWERKE modelliert wieder auf TypobQnQ. Dies stort hier aber nicht, da der Text angibt,

180

•

4 Entity Relationship - Modellierung

dass jeder PC maximal ein CD-ROM - Laufwerk hat. Geratetyp und Einzelgerat fallen hiermit zusammen. Damit ist die Min-/Max-Angabe bei den Laufwerken 1,1 und bei den PCs 0,1 (da nicht jeder PC ein CD-ROM - Laufwerk hat). Die Beziehung zwischen PCs und Nutzern ist wiederum im spezifizierenden Text festgelegt: ,,Es kommt vor, wenn auch nicht oft, dass ein PC von mehreren Mitarbeitern genutzt wird'' Damit ergibt sich bei PC die Angabe l,n. Durch Nachfrage haben wir herausbekommen, dass umgekehrt ein Nutzer ebenfalls mehrere PCs nutzen kann. Damit ergibt sich dort ebenfalls die Min-/Max - Angabe l,n.

Die folgende Abbildung zeigt das Datenmodell im Zusammenhang.

4.13 Ubertragung von ERM nach RM

feeschw)

181

CD-ROM Bez"

CD-ROM Laufwerke 1.1

Name Festplatten Nutzer (1^^^^^^^^

(^mame)

Bildschirmtypen

Abbildung 4.12-8:

Datenmodell PC-BESCHAFFUNG

4.13 Ubertragung von ERM nach RM Die tlbertragung von ER-Modellen in Relationale Modelle diirfte in der Praxis sehr oft vorkommen. Der Grund ist einfach. Am Anfang, nach der konzeptionellen Phase, wird meist ein Semantisches Datenmodell erstellt und dies ist heute in der Regel ein ER-Modell. Da das zur Verfugung stehende Datenbanksystem heute fast immer ein relationales ist, wird das

182

Entitatstypen

4 Entity Relationship - Modellierung

ER-Modell vor der Einrichtung der Datenbank in ein relationales Datenmodell libertragen. Das ist der Grund, weshalb hier einige Hinweise auf diesen (nicht schwierigen) Transformationsprozess gegeben werden. Entitatstypen ohne mehrwertige Attribute werden in eine eigene Relation iiberfuhrt.

Abbildung 4.13-1:

Entitatstyp mit Attributen

Das Beispiel der Abbildung wird damit - mit der Annahme, dass das Attribut Name auch Schlusselcharakter hat - zu genau einer Relation: ANGESTELLTE (#PersNr, #Name, Alter, Geschlecht, Gehalt) Die folgende Abbildung zeigt die Attributsonderfalle zusammengesetzte Attribute, abgeleitete Attribute und mehrwertige Attribute.

Mitglieder m

7 —

•

'

-

—

(Alter )

Abbildung 4.13-2:

Attributsonderfalle

Diese Attributsonderfalle werden wie folgt in relationale Datenmodelle abgebildet: •

Bei zusammengesetzten Attributen werden nur die "auBersten" Attribute tibernommen. Die Information, dass die Attribute etwas zusammen modellieren, dass sie „zusammengeh6ren", geht verloren. Hier bleiben also Ort, PLZ und StrafJe sowie Nachname und Vorname tibrig.

4.13 Ubertragung von ERM nach RM •

•

183

Abgeleitete Attribute konnen nicht direkt modelliert werden. Bei vielen Datenbanksystemen ist es allerdings moglich, im Rahmen der Einrichtung der Datenbank, ein solches "berechnetes" Attribut anzulegen. Jedes mehrwertige Attribut wird zu einer eigenen Relation, entsprechend der Behandlung mehrwertiger Attribute im relationalen Ansatz.

Aus dem obigen ER-Modell werden damit die folgenden zwei Relationen: Mitglieder (#Nr, Nachname, Vorname, PLZ, Ort, StrafJe) MitgliederTatigkeiten(#(Nr, Tatigkeit)) Beziehungstypen werden unterschiedlich modelliert, je nach der Kardinalitat und dem Min-/Max-Wert der Beziehung. Betrachten wir dazu nochmals das - zugegeben konstruierte - ER-Modell aus dem Weltausschnitt D A T E N B A N K S Y S T E M E . Hier wird zwischen einer technischen Beschreibung der Datenbanksysteme und einer preislichen unterschieden. Der Grund soil hier sein, dass die technischen Informationen immer erhoben werden, die kaufmannischen aber nur fiir einen Teil der Datenbanksysteme. Diese Situation konnte, so wie hier in Abbildung 4.13-3, zu der Bildung zweier Entitatstypen gefiihrt haben, die durch eine 1:1- Beziehung T___P verknlipft sind. AuBerdem wird zwischen PRODUZENTEN und DATENBANKSYSTEME/TECHNISCHE INFORMATION (DB__T) eine l:n- und zwischen DATENTYPEN und DATENBANKSYSTEME/TECHNISCHE INFORMATION (DB_T) eine n:m - Beziehung angenommen. Fiir die Ubertragung in ein relationales Modell wird zuerst fur jeden Entitatstyp eine Relation angelegt:

Beziehungstypen

PRODUZENTEN (#ProdNr, Name) DATENTYPEN (#Bezeichnung, Typ) DATENBANKSYSTEME/TECHNISCHE INFORMATION (#Bezeichnung, MaxZahlDs^"^) DATENBANKSYSTEME / PREISINFORMATION (#Bezeichnung, LPreis^^, KostenWartung) Fur jede n:m - Beziehung muss (unabhangig von Min-/Max-Werten) bei der Ubertragung eine eigene Relation angelegt werden, so also auch hier fur den Beziehungstyp DB__T: DB__T (#(BezeichnungDB. BezeichnungDatentvp))

Maximale Zahl Datensatze. Listenpreis

Losung fur n:m

184

4 Entity Relationship - Modellierung

TrodNr

Name

Produzenten

Datentypen m

Datenbanksysteme / technische Information

Datenbanksysteme l\ Preisinformation

Abbildung 4.13-3: Losung fiir 1 :n

Drei Kardinalitaten in einem Modellfragment

Alle 1 :n - Beziehungen werden in eine Schliissel/Frenidschlussel - Beziehung ubertragen. Hier muss also die Relation DATENBANKSYSTEME / TECHNISCHE INFORMATION erganzt werden urn den Schlussel von PRODUZENTEN: DATENBANKSYSTEME / TECHNISCHE INFORMATION (#Bezeichnung, MaxZahlDs, ProdNr) Hatten wir bei dem Entitatstyp DATENBANKSYSTEME / TECHNISCHE INFORMATION allerdings die Min-/Max-Angabe 0,1 stehen, mtissten wir eine eigene Relation anlegen: PROD^DBS (#(BezeichnunaDBS. ProdNr))

Losung bei 1:1

Bei 1:1 - Beziehungen ist die Regellosung die, dass einer der beiden Schlussel als Fremdschlussel in die andere Relation genommen wird. Es gibt allerdings Sonderfalle entlang der verschiedenen Varianten der Min/Max-Bedingung (vgl. auch Abschnitt 3.5). Die folgende Abbildung zeigt die Varianten:

4.13 Ubertragung von ERM nach RM

185

CS> G D Mannschaften

Abbildung 4.13-4:

Trainer

Min-/Max-Angaben

Die vierte mogliche wurde weggelassen, well sie strukturell mit der zweiten identisch ist. Im ersten Beispiel wird auf beiden Seiten von einer Min-/Max-Angabe des Typs "1,1" ausgegangen. Dies bedeutet, dass es ftir jede Mannschaft einen Trainer gibt und fur jeden Trainer eine Mannschaft. Dies ist die Regelsituation, wie oben beschrieben. Sie wird einfach so modelliert, dass in einer der beiden Relationen der Schliissel der anderen als Fremdschliissel eingeftigt wird, also z.B. so: MANNSCHAFTEN (#MNR, IrNr, ...) TRAINER (#TrNr, ...) Im zweiten Beispiel Hegt auf einer Seite die Min-/Max-Angabe "0,1" vor. Dies bedeutet: Eine Mannschaft kann, muss aber nicht einen Trainer haben. Umgekehrt blieb es bei der Angabe "1,1". Hier ist also den Trainem immer eine Mannschaft zugeordnet, nicht aber den Mannschaften ein Trainer. In einer solchen Situation muss der Relation mit der Min-/MaxAngabe "1,1" der Schliissel der anderen als Fremdschliissel hinzugefiigt werden. Hier also: MANNSCHAFTEN (#MNR, ...) TRAINER (#TrNr, MNr, ...)

186

4 Entity Relationship - Modellierung

Im untersten Fall liegt auf beiden Seiten die Min-/Max-Angabe "0,1" vor. Dies bedeutet bei einer Fremdschlussellosung, dass auf jeden Fall semantisch bedingte Leereintrdge entstehen. D.h., nicht Leereintrage, die durch fehlende Angaben entstehen, sondem solche, die dadurch entstehen, weil es die entsprechende Information einfach nicht gibt. In einem solchen Fall ist die Anlage einer eigenen Relation sinnvoll, in der die Schltissel der beiden Relationen jeweils auch Schltissel sind:

MANNSCHAFTEN (#MNR, ...) TRAINER (#TrNr, ...) MANNSCHAFTEN^TRAINER (#MNr. #TrNr)) Weil dieser Tatbestand erfahrungsgemaB Probleme bereitet, hier die tabellarische Darstellung. Es gibt vier Mannschaften und drei Trainer. Zwei der Trainer sind fur zwei Mannschaften eingesetzt. Die iibrigen Trainer und Mannschaften sind nicht in einem Trainings verhaltnis. Die Relation MANNSCHAFTEN_TRAINER zeigt, dass in einer solchen Situation tatsachlich beide Attribute Schltisselcharakter haben. MANNSCHAFTEN |#MNr M123 M234 M345 M456 TRAINER |#TrNr T010 T009 T007 MANNSCHAFTEN TRAINER |#TrNr T010 T007

Singulare Entitatstypen

#MNr

1

M123 M345

Diese Losung erinnert an die Verbindungsrelation bei n:m - Beziehungen, hat aber eine andere Ursache. Da in der neuen Relation jeder Mannschaftsname und auch jede Trainemummer nur einmal vorkommen kann, konnen beide als Schltissel dienen. Durch ihre verbindende Funktion mit MANNSCHAFTEN bzw. TRAINER sind sie gleichzeitig auch Fremdschlussel. Singulare Entitatstypen spiegeln so etwas wie Existenzabhdngigkeit eines Entitdtstyps von einem anderen wider. Damit beruhen sie auf einer

4.13 Ubertragung von ERM nach RM

187

Beziehung, die auf einer Seite eine Min-/Max-Angabe mit einem unteren Wert von "1" haben muss, da auf dieser Seite jede Entitat an der Beziehung teilnimmt. Die folgende Abbildung zeigt ein Beispiel.

Abbildung 4.13-5:

Singularer Entitatstyp AUFTRAGSPOSITIONEN

Die Umsetzung erfolgt so, dass fur die beiden Entitatstypen Relationen angelegt werden, wobei - und das ist typisch fiir singulare Entitatstypen mit ihren Existenzabhangigkeiten - der Schltissel der Relation, die aus dem singularem Entitatstyp hervorging, um den Schltissel der anderen erganzt wird^^. Hier also: AUFTRAGSKOPFE (#AuftrNr, KundNr, ...) AUFTRAGSPOSITIONEN (#(AuftrNr PosNr), ArtikelNr, Menge, ...) Damit ergibt sich - wiederum typischerweise - in der „singularen" Relation ein zusammengesetzter Schltissel mit einem Fremdschliissel, der dem Schltissel der anderen entspricht. Das folgende Beispiel macht dies noch deutlicher. Es stammt aus dem weiter oben diskutierten Sportvereinsbeispiel. Tag. Beginn. G e a n e r ^

Abbildung 4.13-6:

Singularer Entitatstyp BEGEGNUNGEN

Der singulare Entitatstyp hat den Schltissel „Tag, Beginn, Gegner", weil die Mannschaften des Vereins an einem bestimmten Tag zu einer beDas ist der Grund, weshalb einige Autoren diese Schlusselerganzung auch gleich im ER-Modell vornehmen, was aber nicht notwendig ist, da der Tatbestand ja durch die Singularitat ausgedriickt wird.

188

4 Entity Relationship - Modellierung

stimmten Uhrzeit gegen einen bestimmten Gegner spielen. Ohne den Namen der Mannschaft unseres Vereins ware der Schltissel aber unvollstandig. Somit ergibt sich: MANNSCHAFTEN (#Name, ...) BEGEGNUNGEN (#(NameMannschaft Tag, Beginn, Gegner), Ergebnis) Oftmals werden aber in ER-Modellen bereits eigenstandige Schlussel ^ r den singularen Entitatstyp eingefuhrt. Dies entspricht nicht der Philosophie des ER-Ansatzes, well damit modelltechnisch die Existenzabhangigkeit beseitigt wird, obwohl sie semantisch nattirlich weiterhin vorhanden ist. Die folgende Abbildung zeigt ein Beispiel. ^

Angestellte Ver85~

"^ersNf)

Abbildung 4.13-7:

Singularer Entitatstyp KINDER

An der Umsetzung andert dies nichts, der Schliissel des singularen Entitatstyps muss in der entstehenden Relation um den Schliissel des anderen Entitatstyps erganzt werden. Hier wurde flir jedes Kind ein unabhangiger Schliissel eingefuhrt. AuBerdem erfordert hier die Semantik, da mindestens ein Eltemteil und maximal zwei im Untemehmen sein konnen, eine Min-/Max-Angabe von „1,2" bei dem singularen Entitatstyp KINDER. In einem solchen Fall wird die Ubertragung in das relationale Modell einfach so wie oben fiir Beziehungen allgemein vorgenommen. Es entsteht je eine Relation fur ANGESTELLTE und KINDER. Der Beziehungstyp wird gemaB den oben eingefiihrten Regeln fiir Beziehungstypen umgesetzt. Liegt bei der singularen Objektklasse eine 1,1Angabe vor, wird in "ihre" Relation der Schliissel der anderen Relation als Fremdschliissel eingefligt. Liegt, so wie hier oben, "1,2" vor und auf der "anderen Seite" ein unterer Wert von 0, wird eine eigene Relation fiir die Verkniipfung eingerichtet. Hier somit: ANGESTELLTE (#PersNr, ...) KINDER (#Nr, Name, VName, ...) A_K (#(PersNr, KinderNr)) Fur alle obigen Falle gilt im iibrigen, dass die Eigenschaft der Singularitat im relationalen Datenmodell verloren geht.

4.13 Ubertragung von ERM nach RM

189

Mehrstellige Beziehungen (vgl. auch Abschnitt 4.7) wie sie die folgende Abbildung zeigt, werden so aufgelost, dass fur jeden Entitatstyp und flir den Beziehungstyp je eine eigene Relation entsteht. In die so entstehende Verbindungsrelation werden die Schlussel der beteiligten anderen Relationen als Fremdschltissel aufgenommen.

Mehrstellige Beziehungen

Name

Trainer

er86

Abbildung 4.13-8:

Dreistellige Beziehungen

Hier entsteht somit: TRAINER (#Name, ...) TRAININGSORT (#Name, ...) MANNSCHAFT (#Name, ...) TRAINING (#(TrainerName. TrOrtName. MannschName). Datum, Beginn, Ends) Sind die Min-/Max-Angaben nicht 1,1 (vgl. die Beispiele in Abschnitt 4.7) wird bei der Schltisselbildung entsprechend dem relationalen Regelwerk verfahren. Eine Generalisierung/Spezialisierung kann auf verschiedene Weise ubertragen werden. Die Variante, die der relationalen Philosophie am nahesten kommt, ist die folgende: Aus dem generalisierten Entitatstyp und aus alien Spezialisierungen wird jeweils eine Relation. Das folgende Beispiel moge dies verdeutlichen:

Generalisierung / Spezialisierung

190

4 Entity Relationship - Modellierung

Name

Typ

Kunden

Privatkunden

GewerbKunden

GroBkunden

Abbildung 4.13-9:

Generalisierung / Spezialisierung bzgl. Kunden

Der Entitatstyp KUNDEN ist hier spezialisiert in PRIVATKUNDEN und GEWERBKUNDEN, letztere dann noch in GROfiKUNDEN. Damit entstehen folgende Relationen: KUNDEN (#Name, Typ, ...) PRIVATKUNDEN (#Name. ...) GEWERBKUNDEN (#Narne, ...) GROBKUNDEN (#Narne, ...) Fremdschltissel besonderer Art

Die Punkte stehen fur weitere Attribute. Im Fall der Relation KUNDEN fiir solche, die alle Kunden gemeinsam haben, bei den anderen fur die jeweils spezifischen Attribute. Die Schlussel der Relationen, die Spezialisierungen darstellen, sind gleichzeitig auch Fremdschltissel. Dies entspricht nicht der ublichen relationalen Verkniipfung, ist aber unvermeidbar. Hier gilt nicht, dass es fiir jede Auspragung des Schltissels eine oder mehrere Auspragungen des Fremdschliissels gibt, sondem dass die Menge der Auspragungen des Schlussels in der „Generalisierungsrelation" die Auspragungen der anderen enthalt und dass es fur jede Schltisselauspra-

4.13 Ubertragung von ERM nach RM

191

gung in der „Generalisierungsrelation" genau eine Auspragung in einer der Spezialisierungen gibt. Das relationale Modell enthalt damit nicht mehr die Information, dass es sich um eine Generalisierung/Spezialisierung handelt. Diese Information muss iiber die Anwendung in das System gebracht werden. Die zweite Losung flir die Ubertragung einer Generalisierung / Spezialisierung besteht darin, fur jede Spezialisierung eine Relation anzulegen, die zusatzlich zu den spezifischen Attributen auch die allgemeinen enthalt. Fiir die Generalisierung wird keine Relation angelegt. Im obigen Beispiel entstiinden damit folgende Relationen:

Zweite Losung

PRIVATKUNDEN (#Name, "allgemeine Attribute", "spezifische Attribute") GEWERBKUNDEN (#Name, "allgemeine Attribute", "spezifische Attribute") GROBKUNDEN (#Name, "allgemeine Attribute", "Attribute von GewerbKunden", "spezifische Attribute") Hier wurde eine totale Beteiligung angenommen, d.h., die Spezialisierungen decken alle Entitaten der Generalisierung ab. Liegt keine totale Beteiligung vor, ist diese Losung nicht geeignet. Die dritte Losung besteht darin, eine einzige Relation zu erstellen, die alle Attribute enthalt. Im Beispiel: KUNDEN (#Name, Typ, "allgemeine Attribute Kunden", "spezifische Attribute Privatkunden", "spezifische Attribute GewerbKunden", "spezifische Attribute GroUkunden") Eine Generalisierung/Spezialisierung des Typs "overlapping" wird entsprechend gelost. Soweit die Ausfuhrungen zur Ubertragung von ER-Modellen in relationale Datenmodelle. Wurde das ER-Modell korrekt erstellt ist das QntstQhende Relationale Datenmodell in der Regel bereits in 3NF.

Dritte Losung

SERM - STRUKTURIERTE ENTITYRELATIONSHIP-MODELLE

Sinz schlagt in seiner Erweiterung des Entity Relationship-Ansatzes (vgl. [Sinz 1990]) einige Veranderungen vor, die praktische Bedeutung gewannen und die zu sog. Strukturierten Entity Relationship-Datenmodellen (SERM) fiihrten. Besondere Bedeutung gewann dieser Ansatz, weil die semantische Datenmodellierung der SAP auf diesem Ansatz aufbaut.

5.1

Von ERM zu SERM

Grundkonzepte

Dieser Modellierungsansatz geht von den iiblichen ER-Konzepten aus, wie sie oben eingefuhrt wurden, allerdings unter Nutzung der Min-/MaxAngaben und nicht der Kardinalitaten. Fur dieses Kapitel gilt: Wenn es urn ER-Modelle geht, wird die im vorigen Kapitel eingefuhrte Begrifflichkeit und grafische Notation verwendet, wenn es urn strukturierte ER-Modelle geht, die von Sinz: ER-Modellierung Entitatstyp Beziehungstyp — Min-/Max-Angabe

Strukturierte ER-Modellierung Entity -Typ (E-Typ) Relationship-Typ (R-Typ) Entity Relationship-Typ (ER-Typ) Komplexitatsgrad

Hinweis

1

|

Dasselbe gilt fur die Angabe der Min-/Max-Angaben: 0,n in der ERModellierung, (0,*) in der SER-Modellierung, usw. Unter Hinweis auf die hohere Aussagekraft der Min-/Max-Angaben definiert Sinz vier Grundtypen von Komplexitatsgraden: (0,1) (0,*) (1,1) (1,*) Der Stem steht in dieser Notation fur "viele". n:m - Beziehungen werden in zwei 1 :n - Beziehungen aufgelost, so dass er in Bezug auf ein Universitatsbeispiel schreiben kann: "Zwischen Studierenden und Vorlesungen liegt sicherlich - z.B. in einem Universitatsdatenmodell - eine n:m - Beziehung vor, da ein Studierender mehrere Vorlesungen besucht und eine Vorlesung von mehreren Studierenden besucht wird." [Sinz 1990]

Zwei mal l:n statt n:m

194

5 SERM - Strukturierte Entity-Relationship-Modelle

Dies soil die Angabe "n:m" liber dem Beziehungstyp in der folgenden Abbildung ausdrucken.

m:n Studierende

(0.*)

(5,*)

Vorlesungen

Abbildung 5.1-1: Min-/Max-Angaben vs. Kardinalitaten

Graphentheorie

Wie oben schon mehrfach diskutiert (vgl. z.B. die Abschnitte 3.5 und 4.5), sind solche Kardinalitaten nicht sehr aussagekraftig. So halten sie nicht fest, ob ein Studierender tatsachlich Vorlesungen besuchen und ob eine Vorlesung tatsachlich Studierende haben muss. Gibt man dagegen Min-/Max-Angaben an, so wie in der Abbildung unter der Lmie, wird die Aussagekraft hoher. Hier wurde z.B. festgelegt, dass ein Studierender tatsachlich auch mal (in einem Semester) keine Vorlesungen horen, dass er aber auch beliebig viele besuchen kann. Umgekehrt wird festgelegt, dass eine Vorlesung von mindestens 5 Studierenden besucht werden muss, dass diese Zahl aber auch hoher sein kann. Jede solche n:m - Beziehung kann zerlegt werden in zwei 1 :n - Beziehungen. Wie dies genau geschieht, wird im folgenden gezeigt. Sinz weist richtig darauf hin, dass alle "normalen" Varianten und Erweiterungen des ERM "bipartite Graphen" darstellen, wahrend sein Ansatz SERM einen "quasi-hierarchischen Graph" darstellt. Gehen wir fiir die weiteren Ausfiihrungen von der Darstellung und Notation in [Sinz 1990] aus, wie sie die folgende Abbildung zeigt.

Abbildung 5.1-2: Darstellung und Notation bei Sinz Sinz bezeichnet die Kardinalitat zwischen A und B mit b(A,B) und die Min-/Max-Angaben mit Komplexitatsgrad comp(A,b) bzw. comp(B,b). Er kommt dann beztiglich der moglichen Komplexitat der Beziehung b(A,B) zu folgender Tabelle:

5.2 Existenzabhangigkeit

195

Komplexitatsgrade und Kardinalitaten b(A,B) 1:1 1:N N:1 M:N

comp(A,b) (0,1) Oder (1,1) (0,*)oder(1,*) (0,1) Oder (1,1) (0,*)oder(1,*)

comp(B,b) (0,1) Oder (1,1) (0,1) Oder (1,1) (0,*)oder(1,*) (0,*)oder(1,*)

Betrachten wir als Beispiel die zweite Zeile genauer unter Bezugnahme auf die obige Grafik. Die Kardinalitat 1 :n umfasst tatsachlich die angegebenen Falle: •

•

•

•

comp(A,b)=(0,*) bedeutet, dass ein Objekt von A nicht an der Beziehung teilhaben muss, dass es aber auch an mehreren Beziehungen teilhaben kann. comp(A,b)=(l,*) bedeutet, dass jedes Objekt von A mindestens eine Beziehung eingeht, dass es aber auch an mehreren Beziehungen teilhaben kann. comp(B,b)=(0,l) bedeutet, ein Objekt von B nicht an der Beziehung teilhaben muss und falls dies doch der Fall ist, mit maximal einer Beziehung. comp(B,b)=(l,l) bedeutet, dass jedes Objekt von B genau eine Beziehung eingeht.

5.2

Existenzabhangigkeit

Mit Hilfe dieses Konzepts definiert er nun Existenzabhdngigkeiten. Er greift dabei auf das Konzept der referentiellen Integritatsbedingungen (vgl. Abschnitt 3.8) der relationalen Datenmodellierung zurtick. Dabei werden "... in einer Beziehung b(A,B) Existenzabhangigkeiten nicht zwischen den Entity-Typen A und B, sondem zwischen dem Relationship-Typ b und einem Entity-Typ angegeben. Wahrend A und B nicht notwendig voneinander abhangen, hangt b stets von A und B ab." [Sinz 1990] Damit kommt er zu zwei Formen der Existenzabhangigkeit eines Relationship-Typs b von einem Entity-Typ E (vgl. die folgende Grafik): • •

Einseitige Existenzabhangigkeit (b hangt von E ab): comp(E,b)=(0,l) Oder comp(E,b)=(0,*) Wechselseitige Existenzabhangigkeit (b und E sind wechselseitig abhangig): comp(E,b)=(l,l) oder comp(E,b)=(l,*).

196

5 SERM - Strukturierte Entity-Relationship-Modelle

Abbildung 5.2-1: Einseitige und wechselseitige Existenzabhangigkeiten Von zentraler Bedeutung fur den Ansatz ist nun folgende Festlegung: "Ein Entity-Typ wird mit denjenigen Relationship-Typen, mit denen er durch eine (1,1) - Beziehung verbunden ist, zu einem Entity-Relationship-Typ (ER-Typ) zusammengefasst. Gegentiber dem ERM entsteht dadurch ein dritter Objekttyp. Im SER-Diagramm ist ein ER-Typ sowohl Zielknoten (R-Anteil) als auch Startknoten (E-Anteil) von Kanten." [Sinz 1990, S. 26] Insgesamt fiihrt Sinz drei verschiedene Knoten ein: den normalen EntityTyp, den Entity-Relationship-Typ (ER-Typ) und den Relationship-Typ (R). Die grafische Darstellung der beiden neuen Graflkelemente ist wie folgt:

K ^^ I K ^ >l Betrachten wir zur Verdeutlichung das Beispiel aus [Sinz 1990]. Zuerst in der ganz normalen ERM-Darstellung, wie im vorigen Kapitel dargestellt, in der folgenden Abbildung. Das Beispiel sollte selbsterklarend sein. Betrachten wir es nun unter dem Gesichtspunkt der Abhangigkeit, wie sie von Sinz defmiert und oben beschrieben wurde. Hilfreich dafiir ist die gleichzeitige Betrachtung des abgeleiteten relationalen Datenmodells (vgl. unten). Es werden nun ein Entity-Typ mit den Relationship-Typen zu einem Entity-Relationship-Typ (ER-Typ) zusammengefasst, die durch 1:1- Beziehungen verbunden ist. Dem entspricht - bei der tJbertragung in ein relationales Datenmodell - die Situation, dass dem Entity-Typ ein Fremdschltissel hinzugefugt wird, der Schliissel des anderen Entity-Typs. Er ist sozusagen Reprasentant des Relationship-Typs. Somit gilt hier, dass aus dem Beziehungstyp KD-AK zusammen mit dem Entitatstyp AUFTRAGSKOPF der Entity-Relationship-Typ (ER-Typ) AUFTRAGSKOPF wird (vgl. Abbildung 5.2-3).

5.2 Existenzabhangigkeit

Auftragskopf

Kunde 0,*

Forderung er65

0,1

Auftragsposition 1,1

AR-AP

0*

Artikel Abbildung 5.2-2:

ER-Modell KUNDEN - AUFTRAGE - ARTIKEL Quelle: [Sinz 1990, S. 21].

Auftragskopf Abbildung 5.2-3: Von Entitatstyp und 1:1 - Beziehung zu ER-Typ

197

198

5 SERM - Strukturierte Entity-Relationship-Modelle

Genau dasselbe geschieht mit dem Entitatstyp FORDERUNG und dem Beziehungstyp KD-FO.

E

Forderung

Abbildung 5.2-4: Von Entitatstyp und 1:1 - Beziehung zu ER-Typ Im Falle des Entity-Typs AUFTRAGSPOSITION werden die beiden Beziehungstypen AK-AP und AR-AP hinzugenommen und in einen ERTyp AUFTRAGSPOSITION verwandelt.

AuftragspositJon I

mi

^ ^

Abbildung 5.2-5: Von Entitatstyp und 1:1 - Beziehung zu ER-Typ

5.2 Existenzabhangigkeit

199

Zwei der Entitatstypen von Abbildung 5.2-2 erweisen sich als unabhangig von den anderen: KUNDE und ARTIKEL. Sie bleiben also Entitatstypen, bzw., in der Sinz'schen Begrifflichkeit Entity-Typen. Damit bleibt vom urspriinglichen ER-Modell nur noch der Beziehungstyp FO-AP tibrig. Dieser wird im SERM zu einem Relationship-Typ (RTyp). Zwischen den nun erzeugten Entity Relationship-Typen und den ETypen besteht nun eine Abhangigkeit im Sinne dieses Ansatzes. Diese Abhangigkeit hat eine Richtung und wird deshalb durch gerichtete Pfeile ausgedruckt^^. Folgende gerichteten(!)^^ Beziehungen liegen in dem entstehenden SERM nun vor: zwischen E-Typ KUNDE und ER-Typ FORDERUNG: zwischen E-Typ KUNDE und ER-Typ AUFTRAGSKOPF: zwischen E-Typ ARTIKEL und ER-Typ AUFTRAGSPOSITION: zwischen ER-Typ FORDERUNG und R-Typ FO-AP: zwischen ER-Typ AUFTRAGSKOPF und ER-Typ AUFTRAGSPOSITION: zwischen ER-Typ AUFTRAGSPOSITION und R-Typ FO-AP:

0,* 0,* 0,* 1,* 1,* 0,1

Fiigt man damit die entstandenen Elemente zusammen, entsteht ein SERModell wie in der folgenden Abbildung.

r'^Bi

Forderung

(1.*)

(0/)

Kunde

I

'' 1 ^

Forderungs-

^1

— A I ^V^uftragsposifionenx"^ I

(0.*)

(0.1)

U)^

Auftragskopf

Artikel

Abbildung 5.2-6:

-|g

Auftragsposition —'

(0.*)

SER-Modell KUNDEN - A U F T R A G E - ARTIKEL

Sinz verwendet fur die gerichteten Beziehungen etwas andere Pfeile. Hier wurde die Pfeilnotation der SAP verwendet, was inhaltlich Iceine Bedeutung hat. In ER-Modellen haben Beziehungen keine Richtung.

Abhangigkeit mit Richtung

200

5 SERM - Strukturierte Entity-Relationship-Modelle

Die Quelle fur die obige Abbildung ist [Sinz 1990, S. 27]. Lediglich die Verbindungslinien wurden leicht verandert und nach der inzwischen gebrauchlicheren SAP-SERM-Notation gestaltet (vgl. Kapitel 6). Bedeutung der Pfeilspitzen: • • • •

Von links nach rechtsimmer abhangiger.

Einfache Pfeilspitze: Bezug auf eine Entitat des Ziels Doppelte Pfeilspitze: Bezug auf mehrere Entitaten des Ziels Senkrechter Strich vor den Pfeilspitzen: Beziehung ist - vom Start aus gesehen, optional. Kein Senkrechter Strich: Eine Entitat des Startelements muss teilhaben

Von den Startelementen aus gesehen, geht es somit nur noch um die Frage, ob jede Entitat an der Beziehung teilnehmen muss oder nicht (optional oder nicht). Von den Zielelementen aus gesehen geht es nur noch darum ob maximal eine Entitat oder mehrere an der Beziehungen teilhaben. Dieses SER-Modell stellt nun recht deutlich die Existenzabhangigkeiten dar. Vollig unabhangig sind ARTIKEL und KUNDE. Diese beiden Entity-Typen benotigen keine anderen ftir ihre Existenz. Die durch sie reprasentierten Daten entstehen im Weltausschnitt bzw. Anwendungsbereich. Wegen ihrer Unabhangigkeit sind sie ganz links eingeordnet. FORDERUNG und AUFTRAGSKOPF dagegen konnen nur existieren, falls es zugehorige KUNDEn gibt. Sie sind deshalb in der zweiten Spalte angeordnet. Fur AUFTRAGSPOSITIONen gilt, dass sie nur existieren konnen, falls in ARTIKEL und in AUFTRAGSKOPF entsprechende Entitaten vorhanden sind. Dabei gilt: Einen Auftragskopf muss es geben, die Artikelangabe ist optional. Die AUFTRAGSPOSITIONen sind deshalb in einer dritten Spalte. Forderungsauftragspositionen (FOAP) wiederum benotigen Entitaten in FORDERUNG und AUFTRAGSPOSITION und landen deshalb in Spalte 4. Dieser Ansatz sorgt durch Beriicksichtigung der Abhangigkeiten zwischen den Modellelementen und durch Visualisierung dieses Tatbestandes fur mehr Ubersicht im Datenmodell. Das Mittel, um dies zu erreichen, entstammt der relationalen Modellierung. Somit ist der SERM-Ansatz zwischen der eigentlichen ER-Modellierung und der relationalen Modellierung angesiedelt. Um dies zu verdeutlichen, hier noch das Relationale Modell zu den obigen beiden Modellen^^. Die Anordnung wurde ahnlich der im SERModell gewahlt.

^'^

Hier wurde bei der Bezeiclinung der Entitatstypen wieder die Melirzahl gewahlt („Kunden" statt „Kunde"). Die Einzahl in den obigen Beispielen ruhrt daher, dass Sinz in seinem Beispiel die Einzahl gewahlt hat.

5.2 Existenzabhangigkeit

201

FORDERUNGEN #ForderungsNr, KundenNr KUNDEN

FO-AP

#KundenNri

#fForderunasNr, fAuftrNr. PosNr)

m67

Abbildung 5.2-7:

Relationales Datenmodell KUNDEN GE-ARTIKEL

AUFTRA-

Die Ubertragung ist - ausgehend von den obigen zwei Modellen (ERM und SERM) nicht schwierig. Folgende Schlussel wurden eingefuhrt, die Ubrigen eventuellen Attribute sind hierfiir ohne Belang: • • • • •

KundenNr als Schlussel von KUNDEN ArtikelNr als Schliissel von ARTIKEL AuftrNr als Schliissel von AUFTRAGSKOPFE ForderungsNr als Schlussel von FORDERUNGEN (AuftrNr, PosNr) als Schliissel von AUFTRAGSPOSITIONEN

Mit den Min-/Max-Angaben zwischen KUNDEN und AUFTRAGSKOPFE muss der Kunde in jedem Auftragskopf vermerkt werden. KundenNr wird also Fremdschlussel in AUFTRAGSKOPFE. Bei der Beziehung zwischen ARTIKEL und AUFTRAGSPOSITIONEN fuhren die Min-/Max-Angaben dazu, dass die ArtikelNr Fremdschlussel in AUFTRAGSPOSITIONEN wird. Genau gleich wird die Beziehung zwischen FORDERUNGEN und KUNDEN verarbeitet. Etwas weniger klar ist die Beziehung FO-AP zwischen AUFTRAGSPOSITIONEN und FORDERUNGEN. Die Min-/Max-Angaben drucken aus, dass es fiir jede Forderung mindestens eine Entitat in FO-AP gibt. Eine Auftragsposition muss aber nicht zu einer Forderungsauftragsposition flihren, falls ja, hochstens zu einer. Dies kann nur durch eine eigene Relation modelliert werden. Die Schliissel- und Fremdschliisselsituation ist dann wie folgt:

Von ERM und SERM nach RM

202

• • •

Fremdschliissel und Abhangigkeit

5 SERM - Strukturierte Entity-Relationship-Modelle

Der Gesamtschlussel besteht aus #(ForderunqsNr (AuftrNr, PosNr)). ForderungsNr alleine ist auch Fremdschlussel. Die Attributkombination (AuftrNr, PosNr) ist ebenfalls Fremdschliissel.

Ein Fremdschliissel, der aus zwei Attributen besteht, ist durchaus ungewohnlich, hier aber unvermeidlich. So entstand das obige relationale Datenmodell. Der Vergleich mit dem SER-Modell macht deutlich, dass die defmierte Existenzabhangigkeit mit dem Gewicht der Fremdschliissel einhergeht. Gibt es keine Fremdschliissel, ist der Entitatstyp unabhangig. Gibt es in Erganzung des Schliissels einen Fremdschliissel, ist die erste Stufe der Existenzabhangigkeit gegeben. Liegt, wie hier in FO-AP, ein zusammengesetzter Schliissel vor, der nur aus Fremdschliisseln besteht, ist die hochste Form der Abhangigkeit erreicht.

DER SAP-ANSATZ FUR DIE DATENMODELLIERUNG

6.1

Das Grundkonzept

Das informationelle Geriist eines Unternehmens wird in Datenbanken erfasst. Dem Ansatz Betriebswirtschaftlicher Standardsoftware (ERPSoftware) entsprechend ist es hier eine einzige, das gesamte Untemehmen und all seine Aktivitaten beschreibende Datenbank^^. Weiter oben wurde schon eine zeitgemaBe und zum Kontext dieses Buches passende Auffassung von Datenbanken angefuhrt; Datenbanken stellen die Informationen zur Verfugung, die fur die Abwicklung der Geschdftsprozesse benotigt werden. Beim Datenbankdesign hat man ein Modell eines bestimmten Aus- Weltausschnitt schnitts der Realitat zu erstellen. Dieser Weltausschnitt (in diesem Kontext wird auch oft von Anwendungsbereich gesprochen) wird in die Datenbank hinein abgebildet. Im Falle von SAP R/3 (oder den Nachfolgeprodukten) besteht der Weltausschnitt somit aus dem gesamten (vorgedachten) Untemehmen. Die hier anstehende Frage ist die des Datenbankdesigns. Hier hat sich in den letzten Jahrzehnten in Datenbank^/z^or/e und (eher zogerlich) DatQvibdiVkpraxis die Auffassung durchgesetzt, dass es sinnvoll ist, im ersten Schritt ein Semantisches Datenmodell zu erstellen (ganz im Sinne der Fachkonzeptsebene und Datensicht des ARIS-Konzepts) und anschlieBend eines, dass naheren Bezug zum ausgewahlten Datenbanksystem hat, z.B. ein relationales. Genauso geht auch die SAP vor, allerdings mit einer Besonderheit. Im Kern erstellt die SAP Datenmodelle auf zwei Ebenen. Auf einer se- Einordnung: mantischen Ebene (diese werden dann SAP-SERM genannt) und auf der ERM SERM Ebene des Relationalen Datenmodells, im Data Dictionary^\ SAP-SERM

Die naturlich in der Praxis trotz ailer Integrationsbemuhungen so gut wie immer durch andere erganzt wird. Ein Data Dictionary ist ein Verzeichnis aller Elemente einer Datenbank, sozusagen eine Metadatenbank. Zu diesen Elementen gehoren, im Fall einer Relationalen Datenbank, die eingerichteten Relationen, die Attribute, die Sichten (views), die Semantischen Integritatsbedingungen (constraints) und alles andere, was das Datenmodell festlegt. Im SAP-Ansatz spielt das Data Dictionary eine ganz besondere Rolle (vgl. unten).

204

Semantische Datenmodellierung

6 Der SAP-Ansatz fur die Datenmodellierung

Wahrend der relationale Ansatz bei der SAP dem iiblichen Vorgehen entspricht, weist der semantische ModelHerungsansatz Besonderheiten auf. SAP-SERM ist eine Variante des SERM-Ansatzes von Sinz, der im vorigen Kapitel vorgestellt wurde. SERM wiederum entstammt den Modellierungsansatzen, die zu den Entity Relationship Modellen fuhrten. Der Entity Relationship-Ansatz wiederum ist der erfolgreichste Vertreter der Gruppe der Semantischen Datenmodelle, die in den 70er und 80er Jahren intensiv diskutiert wurden. Die folgende Abbildung verdeutlicht diesen Zusammenhang. Dabei bedeutet der erste Pfeil, dass ER-Modellierung ein Teilgebiet unter vielen der Semantischen Datenmodellierung war. Die beiden anderen Pfeile bedeuten jeweils eine Modifikation des dariiber angegebenen Ansatzes. Semantische Datenmodelle

Entity Relationship - Modelle (ERM)

Strukturierte Entity Relationship - Modelle (SERM) I (3) SAP-Varlante der Strukturierten Entity Relationship - Modelle (SAP-SERM)

Abbildung 6.1-1:

Physische und logische Ebene

Varianten Semantischer Datenmodellierung

Im folgenden wird der Ansatz der SAP kurz beschrieben. Dabei wird dieser auch immer wieder in Bezug gesetzt zu den Ansatzen der Datenbanktheorie. Wie in der Datenbanktheorie liblich, unterscheiden auch die SAPModellierer eine logische Ebene und eine physische Ebene des Datenbankdesigns. Mit der logischen Ebene ist (hier) das Relationale Datenmodell gemeint, die physische meint die konkreten Dateistrukturen. Die logische Ebene wird im SAP-Sprachgebrauch mit dem Data Dictionary gleichgesetzt. In der Sprache der SAP stellt sich der Zusammenhang wie folgt dar:

6.1 Das Grundkonzept

205

„Im SAP-System wird die physische Organisation der Daten in der Datenbank uberlagert durch eine logische Ebene, auf der alle Daten in einheitlicher Weise beschrieben werden. Diese logische Sicht der Daten wird im SAP Data Dictionary hergestellt und basiert auf dem relationalen Datenmodell." [SAP-BCDD, S. 2-1] Insgesamt ergeben sich damit drei Ebenen: die Semantische Ebene mit einem SAP-SERM, die logische Ebene mit einem Relationalen Datenmodell und die physische Ebene der konkreten Dateiorganisation. In diesem Abschnitt wird im folgenden, der Zielsetzung des Kapitels entsprechend, die erste dieser Ebenen, die semantische, in ihrer SAPspezifischen Auspragung erlautert und dargestellt.

Semantische Ebene Modell des Weltausschnitts Oder Anwendungsbereichs, erstellt mit dem Instrumentarium eines Modellierungsansatzes (z.B. ERM). Ziel: moglichst viel von den Strukturen, Ablaufen, Regein usw. (der Semantik) zu erfassen.

Logische Ebene Datenmodell. Beschreibung der Daten: welche Relationen gibt es, welche Attribute haben diese, wie sind die Auspragungen der Attribute, welche "Regein" liegen auf den Daten, usw.

Physische Ebene Die Daten selbst, so wie sie das Datenbanksystem in Dateien verwaltet.

Abbildung 6.1-2:

Semantische, logische und physische Ebene des Datenbankdesigns

Drei Ebenen

206

6.2 Objekt, entity, Entitat

6 Der SAP-Ansatz fQr die Datenmodellierung

SAP-SERM

Wie in alien Entity Relationship - Ansatzen werden auch hier im ersten Schritt Objekte und Beziehungen^^ unterschieden. Oftmals werden dafiir ^[Q englischen Begriffe entity und relationship verwendet, einige Autoren des deutschsprachigen Raumes verwenden fur Objekte auch den Begriff Entitat, so auch die der SAP. Der Objektbegriff wird hier im allgemeinsten Sinne verwendet: alles was flir die Datenbank durch Informationen beschrieben wird. Da letzteres heute noch in der Regel^^ Attribute^^ sind, kann obige Definition damit so formuliert werden: Objekt im datenbanktechnischen Sinn sind alle Phanomene der Realwelt, die fiir die Datenbank durch Attribute beschrieben werden.

Entitat

Die zentralen Begriffe fur diese SAP-Variante der Datenmodellierung sind damit Entitat, Beziehung und Attribut. Der Begriff Entitat wird im Kern in den SAP-Unterlagen genauso wie ansonsten in der Datenbanktheorie ublich definiert. „Eine Entitat ist ein Objekt, - das interessiert - das eindeutig identifizierbar ist - fur das Information zu erfassen ist" [SAP-BC030, S. 3-7]. Dieser Begriff geht damit einigermaBen konform mit dem des entity, wie er in der angelsachsischen Fachterminologie ublich ist und wie er ja auch von einigen deutschsprachigen Autoren Ubemommen wurde. Er bedeutet somit eigentlich Informationstrdger und damit und nach dem Sprach-

Auf eine Einschrankung bzgl. der Semantischen Datenmodelle soil hier hingewiesen werden: Die im R/3-ReferenzmodeIl angegebenen Datenmodelle spiegeln nicht die gesamte "darunterliegende" Relational Datenbank wider, sondern "lediglich die wichtigsten Informationsobjekte, die bei den Prozessen als Input oder Output eine Rolle spielen, ..." [R/3-Referenzmodell 3.0F, S. 2.12]. Vor allem im kaufmannischen Bereich. Der Verfasser ist sich der Bedeutung der "neuen" multimedialen Informationsarten wie Grafik, Bild, Audiosequenz, Videosequenz, usw. auch und gerade fiir Datenbanken im klaren. Die daraus abgeleiteten Datentypen spielen eine groBe Rolle und werden in der Zukunft eine noch groBere spielen (z.B. auch im kaufmannischen Bereich). Dies andert jedoch nichts an der Aussage, da im Kern der derzeit dominierenden Datenbankansatze Attribute stehen. Nicht umsonst werden alle diese Ansatze in der angelsachsischen Fachliteratur "attribute-based" genannt. Fur die Zwecke dieses Abschnitts Arbeit genugt folgende Definition: Ein Attribut besteht aus einer Bezeichnung und der Definition der moglichen Werte fur das Attribut (Attributauspragungen). Ein einfaches Beispiel ist das Attribut Farbe mit den Auspragungen weifi, schwarz, gelb, usw.). Attribute werden irgendwelchen Informationstragern (sie werden unten Objekte bzw. Entitaten genannt) zugeordnet, Attribute sind somit eine formale Fassung des umgangssprachlichen Eigenschaftsbegriffs. Vgl. auch Kapitel 2.

6.2 SAP-SERM

207

gebrauch alles, was beschrieben werden kann. Im datenbanktechnischen Sinne also alles, was durch Attribute beschrieben werden kann^^. Natiirlich wird auch in diesem Ansatz die Klassenbildung benotigt. Die damit entstehenden Objektklassen werden (wie auch in diesem Buch) mit Entitdtstyp bezeichnet:

Entitatstypen

„Ein Entitatstyp - beschreibt eine Menge von Entitaten gleicher Eigenschaften (Attribute) - besitzt einen Namen - hat Bedeutung" [SAP-BC030, S. 3-9]. Die Definition deutet es an: Zu Klassen werden die Entitaten zusammengefasst, die durch dieselben Attribute beschrieben werden. Dies entspricht der in der Datenbanktheorie iiblichen Vorgehensweise. Damit ergibt sich: Entitaten werden durch Attribute beschrieben. Zum Beispiel einzelne Kunden oder die Angestellten des Untemehmens. Jewells ein Entitatstyp umfasst alle Entitaten, die durch dieselben Attribute beschrieben werden^^. Also z.B. die Kunden bzw. Angestellten insgesamt. Vielleicht ergeben sich aber auch zwei verschiedene Kundengruppen (z.B. wenn man Einmalkunden abtrennt), die durch teilweise unterschiedliche Attribute beschrieben werden. Dann miissen zwei Entitatstypen gebildet werden (vgl. hierzu Kapitel 4). Betrachtet man den Zusammenhang von Prozessbeschreibungen durch Ereignisgesteuerte Prozessketten und Datenmodellen, konnen Funktionen und Entitatstypen in Beziehung gesetzt werden: „Entitatstypen sind Informationen, die zur Durchfuhrung einer betriebswirtschaftlichen Funktion notwendig sind" (R/3-Hilfe: CA - R/3Referenzmodell, Stichwort „Der Entitatstyp"). Wie im ER-Ansatz Ublich werden hier - neben Entitaten - auch Beziehungen betrachtet. Allerdings - gemaB dem SERM-Ansatz - in einer gegentiber dem allgemeinen ER-Ansatz eingeschrankten Form. Geht es um die Beziehungen zwischen Entitatstypen, wird von Beziehungstyp gesprochen. Dabei wird, wie im klassischen Entity Relationship-Ansatz, die Klassenbildung der Entitaten fur die Beziehungen nachvollzogen. Im Vergleich zur herkommlichen ER-Modellierung (vgl. Kapitel 4) sind Beziehungen in diesem Ansatz wesentlich genauer gefasst und enger definiert. Sie bestehen ausschliefilich zwischen Jeweils zwei Entitatstypen, nicht zwischen drei oder mehr, wie es ansonsten auch moglich ist. Sie sind gerichtet und die Richtung druckt eine Hierarchic aus, was in der konventionellen ER-Modellierung nicht tiblich ist. Demzufolge werden Beziehungen durch die beiden beteiligten Entitatstypen definiert. Den Dass heute auch andere Informationstypen wie Bilder, Grafik, Ton, usw. in Datenbanken verwendet werden, tut dem keinen Abbruch. Diese fundamentale Regel aller attributbasierten Datenbankansatze muss naturlich auch hier gelten.

Beziehungen

Allgemeine Definition

208

Eingehende und ausgehende Beziehungen

tibergeordneten nennt die SAP Start-Entitdtstyp bzw. existenzunabhdngigen Oder referierten Entitdtstyp, den zweiten Ziel-Entitdtstyp oder existenzabhdngigen Entitdtstyp. In der Komponente des R/3, mit der die Bearbeitung der Datenmodelle moglich ist, dem Data Modeler wird zwischen den eingehenden und ausgehenden Beziehungen eines Entitatstyps unterschieden: •

•

Eigenschaften von Beziehungen

Kardinalitaten Ubersicht

6 Der SAP-Ansatz fur die Datenmodellierung

Eingehende Beziehung: der gewahlte Entitatstyp ist in diesem Fall der Ziel-Entitatstyp (abhangige Entitatstyp) und der andere der StartEntitatstyp (der unabhangige oder referierte Entitatstyp). Ausgehende Beziehung: der gewahlte Entitatstyp ist in diesem Fall der Start-Entitatstyp (der unabhangige oder referierte Entitatstyp) und der andere der Ziel-Entitatstyp (abhangige Entitatstyp).

Beziehungen in SAP-SERM haben zwei Eigenschaften: • •

Kardinalitat Art

und eine betriebswirtschaftliche Bedeutung. Mit Kardinalitat der Beziehung ist das gemeint, was auch ansonsten in den ER-Ansatzen gemeint ist, allerdings gibt es im SAP-SERM keine n:m - Beziehungen. Konkret werden folgende Kardinalitaten unterschieden: • • • •

1:M - Beziehungen^^ in der tiblichen Festlegung: Eine Entitat des einen Entitatstyps steht mit mehreren des anderen in Beziehung. 1:CM - Beziehung: Eine Entitat des einen Entitatstyps steht mit keinem oder mehreren des anderen in Beziehung. 1:1- Beziehung in der ublichen Notation: Eine Entitat des einen Entitatstyps steht mit einem des anderen in Beziehung. 1:C - Beziehung: Eine Entitat des einen Entitatstyps steht mit keinem oder einem des anderen in Beziehung.

Der Buchstabe "M", der tiblicherweise nur "mehr als eins" bzw. "viele" bedeutet, soil hier auch noch Pflichtfeld {mandatory), der Buchstabe "C" Optionalitat {conditional) und T Zeitabhangigkeit {temporary) signalisieren. Die folgende Abbildung zeigt die grafische Darstellung der Beziehungen. Zwischen je zwei durch Rechtecke reprasentierten Entitatstypen (vgl. unten) wird jeweils einer dieser Pfeile eingefugt:

Start Mwird an einigen Stellen der SAP-Dokukmentation auch //verwendet.

6.2 SAP-SERM

4^ Abbildung 6.2-1:

1:1

Oder

1:{1}

1:C

Oder

1:{0,1}

1:M

Oder

1:{1,m}

1 : CM Oder

1 : {0,m}

209

Beziehungsarten und ihre grafische Notation in SAP-SERM

Entitatstypen werden in SAP-SERM wie ublich durch Rechtecke mit Beschriftung dargestellt. Die Attribute der Entitatstypen werden nicht angegeben. Beziehungstypen haben hier keine Attribute im modelltechnischen Sinn. Hier ein einfaches Beispiel mit der Kardinalitat 1:CM. Fachbereiche

Abbildung 6.2-2:

-m

Kurse

Grafische Darstellung von Beziehungstypen in SAPSERM am Beispiel eines Hierarchischen Beziehungstyps.

In der Sprache des SAP-SERM ist hier der Entitatstyp FACHBEREICHE der Start-Entitatstyp und KURSE der Ziel-Entitatstyp. Nun zu den Beziehungen. Die SAP spricht auch von Beziehungstypen, obwohl dies hier eine andere Bedeutung hat als im herkommlichen ERAnsatz. Die Art einer Beziehung bzw. eines Beziehungstyps kann hierarchisch, aggregierend, referentiell oder extern sein. Mit dem Begriff hierarchischer Beziehungstyp ist in SAP-SERM eine Beziehung zwischen zwei Entitatstypen gememt, bei der der ZielEntitatstyp existenzabhangig ist vom Start-Entitatstyp. Konkret meint dies, dass die Existenz einer Entitat des Ziel-Entitatstyps abhangt von einer Entitat des Start-Entitatstyps. Modellierungstechnisch auBert sich dies so, dass der SchlUssel des Start-Entitatstyp zu einem Teil des Schlussels des Ziel-Entitatstyps wird. Das obige Beispiel zeigt einen hierarchischen Beziehungstyp zwischen den Entitatstypen FACHBEREICHE (Start-Entitatstyp) und KURSE (Ziel-Entitatstyp). Entsprechend ist die Schlusselkonstellation (vgl. auch Kapitel 5 zu diesem Konzept der Existenzabhangigkeiten und seinen Konsequenzen fur den Schltisselaufbau). Der Entitatstyp FACHBEREICHE besitzt (im Universitatsbeispiel der SAP-Dokumentation) die Attribute

Art einer Beziehung

Hierarchischer Beziehungstyp

210

•

6 Der SAP-Ansatz fur die Datenmodellierung

Fachbereichsnummer (dieses dient auch als Schlusselattribut^^) und Fachbereichsname.

Der Ziel-Entitatstyp KURSE besitzt die Attribute •

Fachbereichsnummer, Kursnummer, Nummer des/der Kursleiterln und Kursname. Fachbereichsnummer und Kursnummer dienen zusammen als Schlussel dieses Entitatstyps.

Die Existenzabhangigkeit wird durch den Fremdschltissel Fachbereichsnummer signalisiert (vgl. Kapitel 5). Wegen der Nahe der SERModellierung und damit auch der SAP-SER-Modellierung zum relationalen Ansatz kann der Zusammenhang sehr anschaulich mit der relationalen textlichen Notation dargestellt werden: FACHBEREICH (#Fachbereichsnummer, Fachbereichsname) KURSE (#(Fachbereichsnummer Kursnummer), Nummer des/der Kursleiterin, Kursname) Existenzabhangigkeit

Aggregierender Beziehungtyp

Dieses Beispiel erlaubt auch, nochmals den Begriff der Existenzabhangigkeit TAX betrachten, der in der SAP-Terminologie eine bedeutende Rolle spielt. Hier ist die Tatsache gemeint, dass jede Ziel-Entitat zu ihrer Identifikation eine Start-Entitat benotigt. Im obigen Beispiel: Jeder Kurs benotigt einen Fachbereich. Die folgende Struktur wird Aggregierender Beziehungstyp genannt. Hier sind immer drei Entitatstypen im Spiel, zwei Start-Entitatstypen und ein Ziel-Entitatstyp. Wieder wird die Existenzabhangigkeit des ZielEntitatstyps vom Start-Entitatstyp als Definitionsmerkmal genannt. Hier besteht sie sogar bezuglich zweier Start-Entitatstypen. Der Ziel-Entitatstyp wird vom Start-Entitatstyp erzeugt, d.h. der Start-Entitatstyp hat direkten Einfluss auf die Merkmalsauspragung. In der SAP-Sprache: „Ein Entitatstyp geht aus der Begriffsverkniipfung von mindestens zwei Ausgangsentitaten hervor." [SAP-BC030, S. 3-14] Im folgenden Beispiel: Ein Student kann mehrere Kurse besuchen, ein Kurs hat mehrere Studierende. Zusatzlich driicken die Pfeilspitzen aus, dass die Teilnahme an den Beziehungen konditional ist.

'^^

Ein Attribut, das jede einzelne Entitat identifiziert, dass also fur jede Entitat eine andere Auspragung hat. Vgl. auch die Diskussion zu Schlusseln in den Kapiteln 3 und 4.

6.2 SAP-SERM

211

Studenten l^^ 1^^ {//

Kurse

Abbildung 6.2-3:

Teilnahmebebescheinigungen

1

Grafische Darstellung Aggregierender Beziehungstypen in SAP-SERM.

In einer solchen Konstellation wird die eigentliche Beziehung, die zwischen Studenten und Kursen, durch den Schlussel des Entitatstyps TEILNAHMEBESCHEINIGUNGEN erfasst, der die Schlussel von STUDENTEN und KURSE enthah. Hier wieder die Angabe der Entitatstypen in relationaler Notation (die Punkte deuten die Liste weiterer Attribute an): STUDENTEN (#lmmatrikulationsnummer, ...) KURSE (#Kursnummer, ...) TEILNAHMEBESCHEINIGUNG (#(lmmatrikulationsnummer, Kursnummer) Die Schlussel der Start-Entitatstypen werden Telle des kanonischen Schlussels des Ziel-Entitatstyps. Der einzige Unterschied zwischen dem aggregierenden und dem hierarchischen Beziehungstyp ist, dass bei letzterem zwei Start-Entitatstypen vorliegen. Beim sogenannten Referentiellen Beziehungstyp geht es - ohne dass dies ausgesprochen wird - um dreistellige Beziehungen. In der folgenden Abbildung soil z.B. erfasst werden, dass Professoren Kurse in Fachbereichen halten. Professoren ist Leitervon j ^ ^

Kurse \// J Fachbereiche n

Abbildung 6.2-4:

Dreistellige Beziehungen - Referentieller Beziehungstyp

Die dreistellige Beziehung wird in KURSE erfasst, weshalb dieser Entitatstyp einen Schltissel hat, der aus drei Attributen besteht. Hier konnte allerdings ein Problem auftreten. Wenn in KURSE tatsachlich die einzelnen Vorlesungen und Seminare beschrieben werden,

Referentieller Beziehungstyp:

212

6 Der SAP-Ansatz fur die Datenmodellierung

ware dies hochgradig redundant (VerstoB gegen die 2NF der relationalen Datenbanktheorie). Dann miisste zusatzlich ein eigener Entitatstyp (eine Relation) fiir die Kurse angelegt werden. In der Sprache der SAP ergibt sich die Definition dieses Beziehungstyps, wenn der Ziel-Entitatstyp vom Start-Entitatstyp existenzabhangig ist. Der Start-Entitatstyp legt den Kontext des Ziel-Entitatstyps fest, d.h. eine Attributgruppe des Start-Entitatstyps ist im Ziel-Entitatstyp vorhanden, die den Ziel-Entitatstyp jedoch nicht erzeugt. Die Schliisselattribute des Start-Entitatstyps werden als Nicht-Schlusselattribute in den Ziel-Entitatstyp tibernommen. Zwischen den Entitatstypen PROFESSOREN (Start-Entitatstyp) und KURSE (Ziel-Entitatstyp) besteht die Beziehung IST LEITER VON mit derKardinalitat 1:CN. Dies soil wieder mit Hilfe der relationalen Notation dargestellt werden^^: FACHBEREICHE (#Fachbereichs-Nr., ...) PROFESSOREN (#Professor-Nr., Name, Adresse, Besoldungsklasse) KURSE (#(Fachbereichs-Nr., Kurs-Nr, Professor-Nr.) Konditionalreferentieller Beziehungstyp

Der folgende Beziehungstyp des konditional-referentiellen Beziehungstyps ist wie ein referentieller Beziehungstyp defmiert, jedoch mit einem anwendungsabhangigen Beziehungszusammenhang, der demzufolge nicht immer gegeben ist ([SAP-BC030, S. 3-16]). Das Beispiel hierzu erfasst wieder eine Beziehung zwischen Professoren und Studierenden. Hier kann, aber muss nicht ein (einzelner) Professor an der Beziehung teilhaben, umgekehrt konnen mehrere oder auch kein Studierender teilhaben. Professoren Abbildung 6.2-5:

Externe Beziehungen Starke und schwache Existenzabhangigkeit

^

]rm

Studierende

Konditional - Referentieller Beziehungstyp

Eine Beziehung wird in SAP-SERM extern genannt, wenn sie zwischen einem Entitatstyp innerhalb eines Datenmodells und einem Entitatstyp aufierhalb dieses Datenmodells besteht. Bei der Existenzabhangigkeit wird in der SAP-SER-Modellierung unterschieden zwischen starker und schwacher Existenzabhangigkeit. Bei der starken Existenzabhangigkeit wird gefordert, dass fur jede Auspragung des Ziel-Entitatstyps eine Zuordnung zu genau einer Auspragung des Start-Entitatstyp vorhanden sein muss. Gilt diese Bedingung nur fur eine (zeitabhangige) Teilmenge des Ziel-Entitatstyps, so spricht man von schwacher Existenzabhangigkeit. Vgl. [SAP-BC030,S.3-15]

6.2 SAP-SERM

213

Schwache Existenzabhangigkeit kann bei aggregierenden und referentiellen Beziehungstypen, nicht aber bei hierarchischen Beziehungstypen auftreten. Mit dem nun eingefuhrten Begriff der Abhangigkeit zwischen den Entitatstypen bzw. Entitaten konnen die Kardinalitaten nun neu formuliert werden. Die n:m - Beziehungen ergeben sich damit wie folgt:

Neuinterpretation der Kardinalitaten

n = 1, also l:m Zu jeder abhangigen Entitat gibt es genau eine unabhangige Entitat. n = C, also C:m Es kann Entitaten des abhangigen Entitatstyps geben, die keine Beziehung zu einer Entitat des Start-Entitatstyps besitzen. m = 1, alson:l Zu jeder Entitat des Start-Entitatstyps gibt es genau eine abhangige Entitat. m = C, also n:C Zu jeder Entitat des Start-Entitatstyps gibt es hochstens eine abhangige Entitat. m = N, also n:N Zu jeder Entitat des Start-Entitatstyps gibt es mindestens eine abhangige Entitat. m = CN, also m:CN Zu jeder Entitat des Start-Entitatstyps gibt es beliebig viele abhangige Entitaten. Die Kardinalitaten C:l C:C C:CN C:N sind vor allem bei referentiellen Beziehungen sinnvoll. Moglich sind sie auch bei aggregierenden Beziehungen, nicht aber bei hierarchischen, da hier verlangt ist, dass alle abhangigen Entitaten eine Entitat des StartEntitatstyps referieren miissen, d.h., dass es zu jedem Entitatstyp des abhangigen Entitatstyp eines im unabhangigen Entitatstyp gibt. Alle attributbasierten Datenbankansatze tun sich schwer mit folgender Situation (in der Sprache des SAP-SERM-Ansatzes): Ein Entitatsyp ETi hat bestimmte Attribute, sagen wir Ai, ..., A5. Andere Entitatstypen haben dieselben Attribute aber zusatzlich noch einige mehr. ET2 z.B. AG und A7 und ET3 die Attribute Asj A95 Ai(). Insgesamt also: E T , : Ai, A2, A3, A4, A5 ET2: Ai, A2, A3, A4, A5, Ar, A7 ET3: Ai, A2, A3, A4, A5, Ag, Ac,, A„)

Wie soil eine solche Situation modelliert werden? Sie driickt ja eigentlich Ahnlichkeit im Sinne des attributbasierten Ansatzes aus: Die Entitatstypen haben viele Attribute gemeinsam, einige wenige nicht.

Generalisierung/ Spezialisierung

214

6 Der SAP-Ansatz fur die Datenmodellierung

In den ER-Ansatzen wurde fur diese Situation schon sehr frtih das Konzept der Generalisierung/Spezialisierung entwickelt (vgl. Abschnitt 4.6). Es gibt einen „allgemeinen" Entitatstyp, die Generalisierung, (im obigen Beispiel ETi) und die Spezialisierungen (im obigen Beispiel ET2 und ET3). ETi ist dann die Generalisierung der beiden Spezialisierungen. Die semantische Datenmodellierung, zu der ja auch SAP-SERM gehort, druckt sich damit um die Frage der konkreten Speicherung solcherart erfasster Daten (ist ja auch nicht ihre Aufgabe) und verlagert diese in die Frage der physischen Speicherung. Doch nun hierzu ein Beispiel aus dem Universitatsdatenmodell der SAP. Der allgemeine Entitatstyp seien alle PERSONEN, die an einer Universitat beschaftigt sind. Ihre Attribute seien eine Nummer, ihr Name und die Adresse. Eine der Spezialisierungen seien STUDIERENDE mit den Attributen Immatrikulationsnummer, Betreuender Professor und Studienbeginn. Eine andere Spezialisierung seien die PROFESSOREN mit den Attributen^^^ #Professor-Nr, Name, Adresse, Besoldungsklasse. Ein zugegebenen einfaches Modell, das aber ausreicht, dieses Konzept zu verdeutlichen. Insgesamt ergeben sich damit folgende Attribute (in relationaler Notation), wenn bei den Spezialisierungen die Attribute der Generalisierung weggelassen werden: PERSONEN (#Nummer, Name, Adresse) STUDIERENDE (#lmmatrikulationsnummer, Betreuender Professor, Studienbeginn) PROFESSOREN (#ProfessorNr., Name, Adresse, Besoldungsklasse)

Eigenschaften einer Spezialisierung

Die grafische Notation ergibt sich in SAP-SERM wie in der folgenden Abbildung. Der Schlussel der Generalisierung wird, wie auch im obigen Beispiel, in die Spezialisierungen ubemommen. Dabei kann er naturlich umbenannt werden. Spezialisierungen konnen unterschiedlich strukturiert sein. Liegt eine Situation vor, in der sich die Spezialisierungen nicht tiberlappen, keine Entitat also in mehr als einer Spezialisierung vorkommt, dann spricht man von einer disjunkten Spezialisierung. Die obige durfle mit Sicherheit disjunkt sein, da eine Person iiblicherweise entweder Studierender oder Professor/in ist.

Wir nutzen wieder, wie oben, zur Verdeutlichung die textliche relational Notation.

6.2 SAP-SERM

Personen

215

4 ^T1

ermS

Professoren

Studierende Abbildung 6.2-6:

Generalisierung / Spezialisierung in der SAPNotation

Eine weitere Eigenschaft von Spezialisierungen betrifft die Frage, ob alle Entitaten der Generalisierung in die Spezialisierungen eingehen. 1st dies der Fall, bezeichnet man die Spezialisierung als vollstdndig. Obige Spezialisierung ist mit Sicherheit nicht vollstandig, da es noch andere Personen auBer Studierenden und Professoren an einer Universitat gibt. Generalisierungen/Spezialisierungen mtissen im ubrigen weder disjunkt noch vollstandig sein. Diese beiden Eigenschaften von Spezialisierungen sind keine Besonderheit des SAP-SERM, sondem entstammen dem allgemeinen ER-Ansatz. Die folgende Abbildung zeigt ein Beispiel, das weitgehend dem Universitats-Beispiel der SAP-Unterlagen entstammt und das die oben angefiihrten Modellfragmente enthalt. Es wurde nach den Data DictionaryModellfragmenten in [SAP-BC030] erstellt. Die einzelnen Beziehungen wurden mit Nummem markiert. (1) und (2) stellen die Generalisierung/Spezialisierung dar. Sie bedeutet: Mitarbeiter der Universitat sind (hier) entweder Professoren oder Studierende. Konkrete Bedeutung: MITARBEITER haben bestimmte Attribute gemeinsam, die im gleichnamigen Entitatstyp erfasst werden. PROFESSOREN und STUDIERENDE haben jeweils noch spezifische Attribute, die bei ihrem Entitatstyp angeordnet sind. Bei der spateren Ubertragung in relationale Strukturen bedeutet ein Generalisierungs-ZSpezialisierungsverhaltnis, dass die Relationen durch 1:1 - Beziehungen verkniipft sind, so dass die Beziehung (1) konkret bedeutet: •

Ein Universitatsangehoriger kann ein Professor sein, muss es aber nicht. Auf Datenebene: Ein Tupel der Relation MITARBEITER kann mit hochstens einem Tupel von PROFESSOREN verkniipft sein, muss es aber nicht.

Entsprechend bedeutet die Beziehung (2):

Zusammenfassendes Modellierungsbeispiel

216

•

Betreuung

Lehre

Publikationen

n:m Beziehungen

6 Der SAP-Ansatz fur die Datenmodellierung

Ein Mitarbeiter kann ein Studierender sein, muss es aber nicht. Auf Datenebene: Ein Tupel der Relation MITARBEITER kann mit hochstens einem Tupel von PROFESSOREN verknupft sein, muss es aber nicht.

Solche 1:1- Beziehungen werden in Relationalen Datenmodellen dadurch gelost, dass der SchlUssel der „ubergeordneten" Relation auch als Schliissel in der „untergeordneten" benutzt wird. In der Sprache der relationalen Theorie wird hier sozusagen der Fremdschlussel zum Schltissel, was ja ublicherweise nicht der Fall ist. Doch nun zurtick zur semantischen Modellierung. Die Beziehung (3) zwischen PROFESSOREN und STUDIERENDE druckt in diesem Datenmodell ein Betreuungsverhaltnis aus. Ein Professor kann keinen Oder mehrere Studierende betreuen. Im relationalen Sinn handelt es sich dabei um eine l:n - Beziehung, die durch einen Fremdschliissel (z.B. PROF^NR) in STUDIERENDE erfasst wird. In der SAP-Notation wird allerdings dieser Fremdschliissel noch naher spezifiziert. Die Angabe OPT legt ihn als optionalen Fremdschliissel fest, was hier bedeutet, dass der Fremdschliissel in STUDIERENDE keinen Eintrag haben muss, z.B. wenn der jeweilige Studierende noch keine Diplomand ist. Hier miissen also bewusst semantisch bedingte Leereintrage in Kauf genommen werden. Die Beziehung (4) driickt aus, dass ein Professor keinen, einen oder mehrere Kurse halt. Wieder handelt es sich um eine 1 :n - Beziehung, die erfasst wird, indem in KURSE als Fremdschlussel die PROF_NR genommen wird. Aber auch hier spezifiziert dieser Ansatz etwas genauer: OBL macht den Fremdschliissel zu einem obligatorischen, was hier bedeutet, dass bei jedem Kurs ein Professor eingetragen sein muss. Beziehung (5) legt fest, dass Professoren Publikationen (die in der Datenbank erfasst sind) haben oder auch nicht. Der Zusatz ID legt wiederum fest, dass es sich in PUBLIKATIONEN um einen identifizierenden Fremdschliissel handelt. Diese Beziehung kann auch anders herum beschrieben werden: Eine Publikation kann dann in die Datenbank aufgenommen werden, falls sie von einem in ihr erfassten Professor stammt und dann muss dieser auch angegeben werden. Die Beziehungen (6) und (7) zeigen, wie in diesem Ansatz n:m - Beziehungen (Verbindungsrelationen im relationalen Sinn, vgl. Abschnitt 3.5) erfasst werden. Die n:m - Beziehung besteht zwischen KURSE und STUDIERENDE: Ein Kurs kann mehrere Studierende haben, ein Studierender kann mehrere Kurse besuchen. Im klassischen Entity Relationship-Ansatz wird eine solche Beziehung (genauer: ein Beziehungstyp) als solche gesehen, kann mit Attributen versehen werden und taucht in der grafischen Notation als Raute auf Im Relationalen Modell muss eine solche Beziehung mit drei Relationen gelost werden, wovon eine die eigentliche Verkniipfung widerspiegelt (die Verb indungsrelation).

6.2 SAP-SERM

217

Im SAP-SERM wird die gesamte Beziehung aufgelost in zwei l:n Beziehungen betrachtet. KURSTEILNAHME ist die eigentliche Verkntipfling. Dieser Entitatstyp muss die Schlussel aus KURSE (KURS_NR) und STUDIERENDE (STUD_NR) enthalten. Diese beiden sind dort zusammen Schlussel: #(KURS_NR, STUD_NR). Dieses Beispiel sollte deutlich gemacht haben, dass SAP-SERM, genau wie SERM, naher am Relationalen Ansatz ist als an der klassischen Entity Relationship-Modellierung. Doch zuriick zum SAP-Sprachgebrauch: Beziehung (6) halt fest welcher Studierende an welchem Kurs teilnimmt, indem in KURSTEILNAHME der Schltissel des Studierenden als Fremdschliissel auftaucht. ID legt wiederum fest, dass dieser Fremdschliissel eingetragen werden muss (identifizierender Fremdschliissel). Entsprechendes gilt fiir Beziehung (7)...., nur dass hier verlangt wird, dass jeder Kurs tatsachlich auch in KURSTEILNAHME erscheint: Jeder Kurs muss in mindestens einem Tupel von Kursteilnahem erscheinen. Seine KURS___NR erscheint dort als Fremdschliissel und Telle des Schliissels. Beziehung (8) beschreibt den Zusammenhang zwischen FACHBEREICHE und KURSE. Jeder Fachbereich muss bei mindestens einem Kurs auftreten und wird dort als identifizierender Fremdschlussel erfasst. Beziehung (9) halt fest, dass es zu Kursen auch Kursbeschreibungen gibt. Ein Kurs kann keine, eine oder mehrere Kursbeschreibungen haben.

Kursbesuch

Organisation

Beschreibung

218

Universitat SAP-SERM

6 Der SAP-Ansatz fur die Datenmodellierung

Universitatsangehorige

A

p^ 1

0

\w/

Professoren •'"*>w

C3)

1 (2) Studierende

[/•I

^VT^

©

© Publikationen

/ af

t(\

\\i

/ Kursteilnahme R(

^0

Fachbereiche erm16

J®

\^

Kurse

P Al

©

© ^5 Kursbeschreibung

Abbildung 6.2-7:

Datenmodell UNIVERSITAT - Ein Semantisches

Datenmodell nach SAP-SERM. Quelle: Erstellt nach den Data Dictionary Modellfragmenten in [SAP-BC030]. Zum Vergleich nun dasselbe Datenmodell in der ublichen relationalen Notation. Da hier die SchlUssel und Fremdschltlssel benOtigt werden, wurden diese wie folgt festgelegt: MITARBEITER: PROFESSOREN: STUDIERENDE: PUBLIKATIONEN: FACHBEREICHE: KURSE: KURSBESCHREIBUNG:

MITARB_NR PROF_NR STUD_NR PUBLIK_NR FACHB_NR KURS_NR KURBESCHR NR

6.2 SAP-SERM

219

Damit ergibt sich das in der folgenden Abbildung angegebene relationale Datenmodell. Die Nummem an den relationalen Beziehungen entsprechen denen in der obigen Abbildung. MITARBEITER #MitarbNr

PROFESSOREN

STUDIERENDE

^

^StudNr, ProfNr

#ProfNr

.^ ,

^—

PUBLIKATIONEN *#PublikNr, ProfNr

KURSTEILNAHME frstudNr.KursNr)

FACHBEREICHE #FachbNr

KURSBESCHREIBUNG

Es gilt: PROF_NR Teil von MITARB_NR STUD NR Teil von MITARB NR

#KursbeschrNr, KursNri

Universitat -

Abbildung 6.2-8:

Datenmodell UNIVERSITAT in relationaler Notation.

Wie durch den direkten Vergleich zu erkennen ist, kann die Ubertragung - nicht iiberraschenderweise - sehr direkt vorgenommen werden. Je Entitatstyp entsteht eine Relation, die relationalen Beziehungen konnen an den Pfeilen abgelesen werden. Zur Abrundung zeigt die folgende Abbildung nun noch das Datenmodell in ER-Notation. Als Schltissel wurden die des relationalen Datenmodells genommen.

relational

220

6 Der SAP-Ansatz fur die Datenmodellierung

Universitat ERM

Abbildung 6.2-9:

Datenmodell UNIVERSITAT in ER-Notation (Standardnotation).

Soweit die Darstellung der SAP-Technik zur Semantischen Datenmodellierung (SAP-SERM), auch im Vergleich mit relationaler und ERModellierung. Im folgenden Abschnitt werden einige (sehr kleine) Ausschnitte aus den konkreten Semantischen Datenmodellen von SAP R/3 angegeben.

6.3 Aufbau der Grafiken

Konkrete Beispiele mit Eriauterungen

Die Kennzeichnung des Ansatzes mit dem Begriff strukturiert geht auf den SERM Ansatz von Sinz (vgl. Kapitel 5) zuriick. Die Eigenschaft

6.3 Konkrete Beispiele mit Eriauterungen

221

„strukturiert" bedeutet, dass die Anordnung der Entitatstypen auf der Grafik durch ihren Abhangigkeitsgrad vorgegeben ist. Sind zwei Entitatstypen iiber eine Beziehung oder eine Spezialisierung miteinander verbunden, so steht der Start-Entitatstyp (der unabhangige) immer links vom Ziel-Entitatstyp (dem abhangigen). Im R/3 gab es ftir die Grafiken der Datenmodelle einen sog. LayoutMechanismus, der nach dem Aufruf daftir sorgt, dass die Entitatstypen entsprechend ihrem Abhangigkeitsgrad positioniert werden. Entsprechend der ER-ModelHerung werden Entitatstypen durch Rechtecke dargestellt, in deren Mitte die Bezeichnung des Entitatstyps steht (vgl. die folgende Abbildung). Attribute werden in der Grafik nicht angegeben, sie konnen aber jederzeit durch Zugriff auf das Data Dictionary ausgegeben werden. Im Gegensatz dazu wird eine eventuelle Zeitabhangigkeit eines Entitatstyps durch ein Oval an der linken unteren Ecke des Entitatstyps direkt in der Grafik angegeben (vgl. hierzu die Abbildung Jeder Entitatstyp hat zusatzlich noch eine identifizierende Nummer. Diese steht im linken oberen Feld des Rechtecks. Rechts oben im Rechteck befinden sich zwei kleinere Felder, die nichts direkt mit der Modellierung zu tun haben. Links steht das Customizing-Kennzeichen, das rechte gibt Auskunft iiber die Art der Zuordnung zum Data Dictionary. Das Feld flir das Customizing-Kennzeichen^^^ kann die folgenden Werte annehmen: Blank C A

Entitatstyp wird nicht im Customizing verwendet Entitatstyp wird nur im Customizing verwendet Entitatstyp wird allgemein verwendet

Das Feld flir die Art der Dictionary-Zuordnung (ebenda) kann die folgenden Werte annehmen: Blank T V

Keine Tabelle/kein View zugeordnet Tabelle zugeordnet View zugeordnet

Die folgende Abbildung zeigt nun ein Beispiel, den Entitatstyp Einkaufskontrakt, nach dem auch das gesamte Datenmodell benannt ist, aus dem er stammt. Dieses ist weiter unten angegeben (vgl. Abbildung 6.3-2).

In Abbildung 6.3-4 wanderte das Oval lediglich aus Platzgrunden bei der grafischen Nachbearbeitung des Datenmodells nach rechts. SAP R/3, Rel. 3.1H, Dokumentation BC - Data Modeller, Stichwort Grafik: Darstellungsmethode (SAP-ERM)).

Entitatstypen

222

6 Der SAP-Ansatz fur die Datenmodellierung

Pf5039~ Einkaufskontrakt

jm

Abbildung 6.3-1:

Beziehungen

Darstellung eines Entitatstyps in SAP-SERM Quelle: Entnommen dem Datenmodell Einkaufskontrakt aus SAP R/3, Vom Verfasser grafisch bearbeitet.

Beziehungen werden in den Grafiken als Linien angegeben, wie oben schon eingefuhrt. Zusatzlich wird die ebenfalls oben eingefuhrte Art der Beziehung durch einen Buchstaben angegeben: H fur hierarchisch A fur aggregierend R fur referentiell und Xfiir extern.

Generalisierung/ Spezialisierung

Zusatzlich kann die Bezeichnung der Beziehung an der Linie ausgegeben werden. Der Layout-Mechanismus bei der Ausgabe der Grafik sorgt fur eine weitere Verdeutlichung der Beziehung: Hierarchische und aggregierende Beziehungen kommen von links zu dem abhangigen Entitatstyp, referentielle Beziehungen von oben oder von unten. Die grafische Darstellung von Generalisierungen/Spezialisierungen wurde oben schon beispielhaft dargestellt. Der generalisierte Entitatstyp wird immer links von den spezialisierten Entitatstypen angeordnet. Von der Generalisierung fuhrt eine blaue Linie zu jeder der Spezialisierungen. Ein blaues Dreieck (im Original, hier wurde die Farbgebung beseitigt), sozusagen links von alien Spezialisierungen, signalisiert die Generalisierung/Spezialisierung. Vgl. hierzu die Beispiele in den Abbildungen unten. Die Datenmodelle einer umfassenden ERP-Software (Betriebswirtschaftlichen Standardsoftware) mtissen naturgemaB sehr groB sein. Deshalb werden, um auch bei Ausgabe mehrerer Datenmodelle den Uberblick zu bewahren, die einzelnen Datenmodelle in farbig gekennzeichnete Rechtecke gepackt. Diese musste aus grafischen Grunden bei der Nachbearbeitung der SAP-SERM-Datenmodelle fiir diese Arbeit beseitigt werden. In diesen Rechtecken steht in der linken oberen Ecke die Kurzbeschreibung des Datenmodells (hier immer angegeben). Das erste Beispiel in der folgenden Abbildung zeigt ein sehr kleines Datenmodell zum Thema EINKAUFSKONTRAKT.

6.3 Konkrete Beispiele mit Erlauterungen

223

SAP-Unternehmensdatenmodell mp

Einkaufskontrakt

115039 |A|V Einkaufskontrakt

Abbildung 6.3-2:

115157 ~1A]V Einkaufskontraktp ^^sition

Datenmodell EINKAUFSKONTRAKT Quelle fiir alle Datenmodelle dieses Abschnitts: SAP R/3. Vom Verfasser grafisch bearbeitet.

Es zeigt die im Datenmodell vorgedachte Strukturierung (Aufteilung der Information in EINKAUFSKONTRAKTE, EINKAUFSKONTRAKTPOSITIONEN und ABRUFDOKUMENTATIONEN. Wie zu sehen ist, muss es Einkaufskontraktpositionen geben, was fiir die Abrufdokumentationen nicht gilt. AuBerdem ist in diesem Fragment angedeutet, dass der Entitatstyp EINKAUFSKONTRAKTPOSITION eine Generalisierung anderer Entitatstypen ist. SAP-Unternehmensdatenmodell Einkaufsorganisation 1A|V TOsr tinkaufsorganisat onsgaippjerungKalkulationsschem pflndung

Abbildung 6.3-3:

Datenmodell EINKAUFSORGANISATION

Das Beispiel EINKAUFSORGANISATION in obiger Abbildung macht die datentechnische Strukturierung dieses Teils der Untemehmenswelt

224

6 Der SAP-Ansatz fur die Datenmodellierung

deutlich und die Verkniipfung konzeptioneller Strukturen mit tatsachlich vorhandenen.

Mandant und Mandantenfahigkeit

Exkurs: Organisationsstrukturen Die Bezeichnung Werk in Abbildung 6.3-3 bezieht sich auf die Organisationsstrukturen. Diese sind im Modellierungsansatz der SAP natiirlich auch vorgedacht. Jedem Geschaftsprozess sind die fiir ihn im Rahmen der R/3-Einfuhrung relevanten Organisationseinheiten zugeordnet. Diese konnen auch zu einer Ereignisgesteuerten Prozesskette auf einfache Weise aufgerufen werden. ^in wichtiger Begriff im Organisationskonzept der SAP ist Mandant. Darunter wird eine organisatorische Einheit verstanden, die ein abgeschlossenes betriebswirtschaftliches System darstellt. Mit Mandantenfdhigkeit wird dann die Fahigkeit von SAP R/3 bezeichnet, mehrere abgegrenzte Buchungsbereiche (z.B. fiir verschiedene Unternehmen) zu verwalten. Weitere wichtige Begriffe in diesem Kontext sind Buchungskreis^^^, Werk oder Verkdufergruppe. Die folgende Abbildung zeigt ein wiederum sehr einfaches Datenmodell zum Thema Qualifikation, bei dem der Zeitaspekt mitmodelliert wurde^^"^. SAP-Unternehmensdatenmodell Qualifikation [TTOir

TW

puaiifikationsstr uktur

(^r PfTOOT" Qualifikation

~WN

CSx"

Abbildung 6.3-4: Customizing der Datenstrukturen

Datenmodell Qualifikation

Bin erstes etwas groBeres Datenmodell zeigt die folgende Abbildung zum Weltausschnitt BESTELLUNG. Hier sind auch ganze Generalisierungen integriert. Zum einen zum Entitatstyp BESTELLUNG selbst, der in LIEFERANTENBESTELLUNG und UMLAGERUNGSBESTELLUNG spezialisiert wird. Dies ist ein gutes Beispiel, um das Konzept der Generalisierung/Spezialisierung zu verdeutlichen. Mit ihm kann aber auch der Customizing-Begriff nochmals verdeutlicht werden. Hier konnte z.B. bei einem Unternehmen der Fall vorliegen, dass es keine Umlagerungsbestellungen, dafur aber einen anderen Bestelltyp gibt. Entsprechend miissten dann die Entitatstypen und die Generalisierung verandert werden.

^""^ Die SAP definiert den Begriff Buchungskreis als kleinste organisatorische Einheit des externen Rechnungswesens, fiir die eine voUstandige, in sich abgeschlossene Buchhaltung gebildet werden kann. '"^ Vgl. das besonders eindrucksvoUe Beispiel hierzu in [SAP-PP300, S. 0-12],

6.3 Konkrete Beispiele mit Erlauterungen

225

SAP-Unternehmensdatenmodell Bestellung

Abbildung 6.3-5:

Datenmodell BESTELLUNG

Die zweite Generalisierung betrifft die BESTELLPOSITIONSKONDITION, die in solche mit den Zusatzen MIT STAMM und INDIVIDUELL differenziert werden. Neben den Beziehungen mit optionalem Charakter gibt es in diesen Datenmodellen durchaus auch welche, die vorliegen mtissen. Wie dem Datenmodell entnommen werden kann, kann es zu einer Bestellung GESAMTKONDITIONEN geben, wahrend zu einer BESTELLGESAMTKONDITION einzelne BESTELLPOSITIONSKONDITIONEN vorhanden sein mussen. AuBerdem muss es zu einer Bestellung Bestellpositio-

226

Physische Ebene

R/3 mil Relationalen Datenbanken

Data Dictionary

6 Der SAP-Ansatz fur die Datenmodellierung

nen geben (ist ja auch naheliegend) und zu letzteren BestellpositionsEinteilungen. Soweit die kurze Betrachtung der SAP-spezifischen Semantischen Modellierung. Solche Semantischen Datenmodelle beschreiben in der Kegel recht gut den jeweiligen Weltausschnitt. Sie miissen aber, geht es urn die Realisierung konkreter Datenbanken, in Strukturen abgebildet werden, die naher an der physischen Datenorganisation^^^ in Dateien liegen. Im Datenbankbereich wird dies sehr haufig mit einer Abbildung des Semantischen Datenmodells in ein Relationales Datenmodell realisiert. Der Grund ist, dass Relationale Datenmodelle etwas naher an der konkreten Dateiorganisation sind: Bei vielen Datenbanksystemen entspricht eine Relation einer Datei, zumindest aber sind Relationale Datenbanksysteme in der Lage, Relationen aufzunehmen und so zu verwalten, dass die Nutzer mit der konkreten physischen Datenstruktur nur noch wenig zu tun haben. Deshalb kommen auch bei SAP an dieser Stelle in der Dokumentation die relationalen Datenbanken und ihre Terminologie mit ins Spiel. Die konkrete Datenbank, auf der R/3 agiert, ist immer relational. Dies gilt nattirlich unabhangig davon, welches Datenbanksystem gewahlt wurde^^^. Konkret geht es an dieser Stelle dann immer darum, Semantische Datenmodelle in relationale abzubilden, ganz allgemein (das wird hier betrachtet) und auch zugeschnitten auf die spezifischen Besonderheiten des Jewells gewahlten Datenbanksystems (dies ist nicht Gegenstand dieser Buches). Wie oben schon angemerkt, sehen die SAP-Modellierer diese physische Datenbankebene in einem engen Zusammenhang mit dem Data Dictionary der Datenbank^^^. Wahrend normalerweise ein Data Dictionary hauptsachlich als Verzeichnis der Datenbankelemente dient, hat es hier weitergehende Aufgaben. Es ist zum Beispiel integriert und umfassend, wie es sich far eine Betriebswirtschaftliche Standardsoftware gehort, so dass die SAP-Modellierer ihm eine besondere Rolle zuschreiben konnen: „Das Data Dictionary ist eine zentrale Informationsquelle tiber die Daten eines Untemehmens" [SAP-BCDD, S. 1-1]. Die SAP bezeichnet ihr Data Dictionary daruber hinaus als ein integriertes, womit sie ausdrticken mochte, dass ihr Data Dictionary vollstandig in die Entwicklungsumgebung eingebettet ist. Es ist weiterhin ein aktives, Die eigentliche physische Datenorganisation folgt dem nach und klart die Frage, welche Datei- und Indexierungstechniken Verwendung finden. SAP R/3 kommt ohne Datenbankflinktionalitat zu den Nutzern. Diese muss in Form eines Datenbanksystems dazu gekauft werden. Es stehen unter anderem Oracle, der SQL-Server und DB/2 zur Verfugung. Dies geht soweit, dass teilweise in den Formulierungen Data Dictionary und Relationale Datenbak gleichgesetzt werden. Nur einige Beispiele: "Die zentrale Datenstruktur des ABAP/4 Dictionary ist die Tabelle." [Dokumentation zu SAP R/3 Rel. 3.1H, BC - ABAP/4 Dictionary, Stichwort Uberblick der Grundobjekte des ABAP/4 Dictionary.] oder: „Das Datenmodell des Data Dictionary." [SAP-BCDD, S. 2-1].

6.3 Konkrete Beispiele mit Eriauterungen

227

weil es automatisch erfasste oder geanderte Informationen bereitstellt fur „aktuelle Laufzeitobjekte, Datenintegritat, Datenkonsistenz und Datensicherheit" [SAP-BCDD, S. 1-3]. Als Funktionen des Data Dictionary werden angegeben [SAP-BCDD, S. 1-4]: • • • •

Verwaltung von Datendefinitionen (Metadefinitionen). Zentrale Beschreibung der im Informationssystem verwendeten Daten. Bereitstellung von Informationen fiir Auswertungen. Es liefert Informationen iiber die Beziehungen zwischen den Datenobjekten. Unterstiitzung der Softwareentwicklung Performance-Optimierung

Angesichts dieser wichtigen Rolle des Data Dictionary iiberrascht es nicht, dass in der SAP-Dokumentation die Grundziige des relationalen Datenmodells, nach denen ja modelliert wird, im Kapitel zum Data Dictionary (BC - ABAP/4 Dictionary) diskutiert werden. Woher kommt diese starke Betonung der Bedeutung des Data Dictionary? Die Ursache liegt darin, dass die SAP-Modellierer ihre Datenmodelle nicht am Beispiel eines konkreten Datenbanksystems und seiner Modellierungsinstrumente entwickeln. Dies ist nicht moglich, weil R/3 ohne Datenbankfunktionalitat ausgeliefert wird. Trotzdem mussen aber naturlich - die SAP-Entwickler die Datenmodelle erstellen. Dies ist bei semantischer Datenmodellierung ohne weiteres moglich, da diese ja grundsatzlich wenig Bezug auf konkrete Datenstrukturen und konkrete Datenbanksysteme nimmt. Es wird aber schwierig, wenn es um die etwas konkreteren Datenstrukturen relationaler Datenbanken geht. Hier kommt normalerweise das konkrete Datenbanksystem (bzw. die evtl. in die Betriebswirtschaftliche Standardsoftware integrierte Datenbankfunktionalitat) ins Spiel. Da dies aber hier nicht vorliegt, muss das Data Dictionary von einem Metadatenverzeichnis in ein Werkzeug zur umfassenden Beschreibung der Datenbank umgewandelt werden. Insgesamt liegt hier somit, was die Beschreibung und Erfassung der informationellen Struktur der Untemehmen angeht, die in der folgenden Abbildung skizzierte Situation vor. Zuerst entsteht das oben beschriebene Semantische Datenmodell. Dieses wird in relationale Strukturen abgebildet, was zu einem Meta-Datenmodell im Data Dictionary fuhrt, das umfassend das gesamte informationelle Geriist beschreibt. Dieses wird dann in einem konkreten Datenbanksystem in eine Datenbank umgesetzt. Die fur diese Umsetzung notigen Schnittstelleninformationen werden selbstverstandlich auch von SAP mitgeliefert. Dazu gehort dann z.B. die Abklarung, wie die Felder des Data Dictionary in die Datentypen des jeweiligen Datenbanksystem umgesetzt werden.

Starke Betonung des Data Dictionary

Vom Modeli zu den Daten

228

6 Der SAP-Ansatz fur die Datenmodellierung

Semantische Datenmodellierung mit SAP-SERM I (1) Umsetzung in ein Relationales Datenmodell im ABAP/4 Dictionary (2) ^ '

Umsetzung in eine « Relationaie Datenbank i mit dem ausgewahlten Relationalen Datenbanksystem Abbildung 6.3-6:

Hoher Stand

Vom Semantischen Datenmodell zur Relationalen Datenbank

In diesem Abschnitt konnten die semantischen Modellierungstechniken der SAP nur skizziert werden. Trotzdem sollte deutlich geworden sein, dass es sich um sehr ausgefeilte Techniken handelt, die eine den hohen Anforderungen entsprechende semantische Modellierung erlauben. Man merkt diesen Ansatzen die wohltuende Wirkung der hohen praktischen Anforderung an.

6.4

Business Objekte

Genau gleich wie es bei der Modellierung der Geschaftsprozesse Ubersichtsnotationen gibt, gibt es sie auch bei den Datenmodellen, als sog. Business Objekte. Ein Business Objekt fasst zusammengehorende (aus der Sicht der Anwendung) Datenmodelle so zusammen, dass auch Business Objekte selbst wieder in Beziehung gesetzt werden konnen. Dariiber hinaus werden Business Objekte von der SAP als ein grundsatzliches Gliederungsinstrument gesehen: „Ein SAP Business Objekt reprasentiert ein zentrales betriebswirtschaftliches Objekt aus der realen Welt und beschreibt einen ganzheitlichen betriebswirtschaftlichen Zusammenhang" [SAP Datenmodell 96, S. 17]. Ihnen wird sogar eine besondere Rolle zugewiesen: „Business Objekte sind ausgezeichnete Objekte von zentraler betriebswirtschaftlicher Bedeutung" [SAP Datenmodell 96, S. 17]. Der Begriff Objekt wird in den SAP-Unterlagen sehr unterschiedlich verwendet. Hier ist er wie folgt definiert:

6.4 Business Objekte

229

„Ein Objekt reprasentiert einen ganzheitlichen betriebswirtschaftlichen Zusammenhang. Es ist durch seine innere Struktur naher beschrieben" [SAP Datenmodell 96, S. 17]. Die grafische Darstellung von Business Objekten ist wie folgt: pualifikation

Hinter diesem Business Objekt steht z.B. das Datenmodell von Abbildung 6.3-4. Ein groBeres Business Objekt zeigt die nachste Abbildung. Es handelt sich um den "betriebswirtschaftlichen Zusammenhang" Einkauf. Hier wird deutlich, dass die Meta-Objekte auch in Beziehung gesetzt werden konnen. Wieder ist es die mogliche lineare Anordnung, hier allerdings erganzt um ein Generalisierungs-ZSpezialisierungskonzept, wie das Beispiel EINKAUFSRAHMENVERTRAG (Generalisierung) mit den Spezialisierungen EINKAUFSKONTRAKT und EINKAUFSLIEFERPLAN zeigt. Das Konzept der Generalisierung/Spezialisierung wird also nicht nur (wie ublich) auf der Datenmodellebene, sondern auch auf der MetaEbene der Business Objekte verwendet. Hinter jedem Rechteck liegt ein Ausschnitt eines Datenmodells, der auch direkt aufgerufen werden kann. In diesem Abschnitt wurden oben schon die hierzu korrespondierenden Datenmodelle EINKAUFSKONTRAKT, EINKAUFSORGANISATION und BESTELLUNG angegeben. Zusatzlich sind hier in Abbildung 6.3-8 die drei Datenmodelle EINKAUFSRAHMENVERTRAG, EINKAUFSLIEFERPLAN und EINKAUFSKONTRAKT integriert angegeben. Dies macht nicht nur deutlich, was Zusammengehorigkeit (durch hintereinander anordnen) im Business ObjektDiagramm auf der Ebene des Semantischen Datenmodells bedeutet, sondern zeigt durch die Rechtecke (ursprunglich naturlich farbig) die Anordnung der zu Business Objekten gehorenden Datenmodelle.

Vom Business Objekt zum Datenmodell

230

6 Der SAP-Ansatz fur die Datenmodellierung

Q)

O

E c 0)

^_ X £ 13 (0

c*J\

rS^Sl

rSSSSi

rISEESPI

0)

E 0)

k 1

c

05 C

3

CL

<

(0

Abbildung 6.4-1:

r 1

1 1

I

Business Objekt EiNKAUF.

ij

y

Quelle: SAP R/3. Vom Verfasser grafisch bearbeitet.

6.4 Business Objekte

231

SAP-Unternehmensdatenmodell EInkaufsrahmenvertrag

15053 IT Efnkaui^le?erpla Mngesamtkonditlon

Abbildung 6.4-2:

CR

Business Objekt EINKAUFSRAHMENVERTRAG und nachfolgende Datenmodelle EiNKAUFSLIEFERPLAN und EiNKAUFSKONTRAKT. Quelle: SAP R/3. Vom Verfasser grafisch bearbeitet.

Von alien dem Verfasser bekannten Ansatzen zur Unternehmensmodellierung ist der SAP-Ansatz der griindlichste, der fundierteste und der methodisch fortgeschrittenste. Er ist so gut, dass er - nicht nur bei der Modellierung von Geschaftsprozessen, sondem gerade auch bei der Datenmodellierung - der Theoriediskussion Impulse geben kann.

Gesamteinschatzung SAPModellierung

7

OBJEKTORIENTIERTE MODELLIERUNG

7.1

Einfiihrung

Vielleicht die wichtigste Neuerung in der Informatik der letzten 15 Jahre war und ist die Hinwendung zur Objektorientierung. Die Bedeutung riihrt daher, dass mit ihr eine Methode gefunden wurde, die Realwelt umfassender und effizienter abzubilden. Objektorientierung bedeutet eine neue Art und Weise, mit der in der Informatik Realweltphanomene wahrgenommen werden. In der Systemanalyse und Programmierung die der zu programmierenden Anwendung. Im Bereich der Datenbanken der so genannte Weltausschnitt, der zur Modellierung anstehtlOS. Von besonderem Interesse ist der objektorientierte Ansatz deshalb, weil er dazu fuhrt, dass die Trennung zwischen dynamischen und statischen Aspekten\Q9 eines Anwendungsbereichs zumindest teilweise aufgehoben wird. Der objektorientierte Ansatz ist also ein Modellierungsansatz, ein Werkzeug zur adaquaten Beschreibung eines Anwendungsbereichs. FUr die Anwendungsentwicklung als Systemanalyse und Systemdesign, fiir Datenbanken als Datenmodell. Diese Modelle dienen dann der konkreten Programmierung bzw. der Einrichtung der Datenbank. Das Ergebnis der Modellierungsbemtihungen wird Objektmodell genanntl 10. Der objektorientierte Ansatz ist im Bereich der Programmiersprachen mittlerweile fest etabliert und steht in der Systemanalyse vor dem Durchbruchl 11. Noch nicht ganz so weit ist die Entwicklung bei Datenbanksystemen. Hier ist zwar in der Theorie alles vorbereitet und es existieren erste auch kommerziell verfugbare Datenbanksysteme, der groBe Durchbruch lasst allerdings auf sich warten.

Im weiteren wird in diesem Kapitel fiir die zu modellierende Realwelt der Begriff Anwendungsbereich verwendet. Die genaue Abklarung dieser Begriffe folgt unten. So auch Meier und Wiist fiir den Datenbankbereich, die ein Objektmodell defmieren als die „Zusammenfassung aller notwendigen Klassen einer bestimmten Anwendung." [Meier und Wust 1997, S. 12] Diese Aussage bezieht sich auf die Praxis, nicht auf die Lehre, die Forschungseinrichtungen, usw., wo die UML (vgl. unten) schon langer breite Resonanz fmdet.

Objektorientierung

Dynamisch vs. statisch

Objektmodelle

234

objektorientiertes DatenbankManifest

7 Objektorientierte Modellierung

Selbst die Definition von objektorientierten Datenbanksystemen blieb lange Zeit unklar bzw. umstritten. Um wenigstens dieses Defizit zu beseitigen wurde Ende der 80er-Jahre von Forschungsgruppen, die sich mit objektorientierten Datenbanksystemen befassten, eine fundierte Definition vorgelegt, das objektorientierte Datenbank-Manifest (vgl. [Atkinson 1989], den Nachdruck in [Bancilhon, Delobel, Kanellakis 1992] oder die fundierte und erweiterte Darstellung in [Meier und Wtist 1997, S. 5ff]). Wesentliches Ergebnis war, dass ein objektorientiertes Datenbanksystem (OODBS) ein objektorientiertes Datenmodell (OODM) hat (ebenda). Um es mit [Kim 1990, S. 9f\ zu sagen: „An object-oriented database is a collection of objects whose behaviour and state, and the relationships are defined in accordance with an object-oriented data model." [Kim 1990, S. 9f]

Spezifisch in Datenbanken

Realweltobjekte vs. Datenbankobjekte

Genau dies ist auch in diesem Kapitel, nach einem Ausflug in die grundlegenden Prinzipien der Objektorientierung, der Gegenstand der Arbeit. Sie ist weitgehend auf Fragen der objektorientierten Datenmodellierung konzentriert. Die zu beantwortende Frage ist demnach: Wie erfolgt mit den objektorientierten Konzepten die Datenmodellierung? Denn grundsatzlich geht es auch hier, wie in den librigen Datenmodellierungsansatzen, um die Modellierung von Realweltphanomenen fur die Zwecke der Informationsverarbeitung. Die oben angefiihrte Definition macht deutlich, dass sich objektorientierte Datenbanksysteme in Theorie und Praxis aus mehreren Wurzeln speisen. Da ist zum einen die Objektorientierung an sich, wie sie sich in der Programmierung sowie in Systemanalyse und -design, inzwischen durchgesetzt hat. Da ist aber auch die ganz grundlegende Datenbanktechnologie mit ihren Kriterien, was eine Datenbank ausmacht und was Datenbanksysteme leisten miissen. Sozusagen parallel entwickelt sich aber auch die objektorientierte Systemanalyse, befiiichtet den Datenbankbereich und erhalt durch ihn Impulse. Fur Datenbanken ist der objektorientierte Ansatz aus mehreren Griinden fiiachtbar. Zum einen, weil er erlaubt, die (halbwegs) naturliche Wahmehmung eines Weltausschnitts als Ansammlung von Objekten mit Beziehungen direkt in das Datenmodell hinein abzubilden. Nicht wenige Autoren schreiben sogar von einer l:l-Abbildung zwischen Objekten der Realwelt und Objekten des objektorientierten Datenmodells (vgl. unten). Ein zweiter Punkt ist aber genauso wichtig. Sieht man (statische) Datenbanken letztendlich als informationelle Grundlage von (dynamischen) Geschaftsprozessen, dann erlaubt die im objektorientierten Ansatz vorgenommene Aufhebung der Trennung von dynamischen und statischen Aspekten eines Weltausschnitts u.U. eine geeignetere Modellierung auch im Bereich der Geschaftsprozesse. Dies wurde in [Stand 2001] diskutiert. Die Unterscheidung von Objekten der Realwelt und der Datenbank wurde in dieser Arbeit Mher schon benutzt, hier gewinnt sie nun aber besondere Bedeutung. Die Bedeutung ist dieselbe wie oben: Den Objek-

7.2 Statische Aspekte I - Objekte und Objektklassen

235

ten der Realwelt auf der einen Seite stehen ihre Reprasentanten in der Datenbank gegeniiber. In einer Personaldatenbank z.B. liegen in der Realwelt (datenbanktechnisch: dem Weltausschnitt) die Beschaftigten selbst vor. In der Datenbank finden sie sich dann als Datenbankobjekte mit einer spezifischen Datenstruktur wieder. Fiir die Entwicklung und Darstellung objektorientierter Datenmodelle ist die ER-Notation nur eingeschrankt tauglich, v.a., weil sie die Festlegung der Methoden, des Objektverhaltens nicht erlaubt. Deshalb wird hier die objektorientierte Notation der Systemanalyse verwendet, wie sie sich seit einigen Jahren in der UML artikuliert. Dies geschieht allerdings nur in dem Umfang, wie dies fiir die Datenmodellierung notwendig ist. Object Data Management Group (ODMG: Zusammenschluss von Herstellern objektorientierter Datenbanksysteme. Nach [Geppert 1997, S. 20] waren 1997 dabei: Gemstone, Itasca, 02, ObjectStore. Objectivity POET, UniSQL und Versant. Erinnerung: Um im Text die Ubersichtlichkeit zu erhohen, wird folgende typographische Festlegung getroffen: • Weltausschnitte / Anwendungsbereiche werden fett, etwas vergroBert und in Arial gesetzt: VORLESUNGSBETRIEB. • Datenmodelle sind ebenfalls in Arial sowie in Kapitalchen gesetzt:

Typographische Festlegung

MARKT FUR DATENBANKSYSTEME

•

Relationen, Entitatstypen, Beziehungstypen, Klassen sind in Arial und in GroBbuchstaben gesetzt: ANGESTELLTE

•

Attribute sind in Arial gesetzt: Personalnummer

7.2

7.2.1

Statische Aspekte I - Objekte und Objektklassen Objekte - Attribute - Methoden

Auch dieser Ansatz baut, wie die anderen Modelliemngsansatze fiir Datenbanken auch, wesentlich auf dem Attributkonzept auf. Attribute sind das zentrale Beschreibungsmittel, Attribute sind mitbestimmend daftir, welche Objekte zu einer Klasse (fiirs erste soil dieser Begriff wie oben verwendet werden) zusammengefasst werden. Wir konnen also wie oben bei den anderen Modellierungsansatzen von folgendem Grundszenario ausgehen: Infornnationstrager^^^ irgendwelcher Art werden durch Attribute beschrieben und miteinander in Beziehung gesetzt. "Entity" im angelsachsischen Sprachraum.

Attribute

236

Methoden I

Dies wird hier erganzt durch mehrere weitere Konzepte, die an der Stelle, wo ublicherweise Attributsauspragungen stehen, z.B. andere Objekte zulassen (vgl. unten), weshalb einige Autoren auch etwas allgemeiner von Eigenschaften statt von Attributen sprechen. Soweit nichts neues. In der objektorientierten Modellierung werden aber bereits im ersten Schritt auch Methoden berticksichtigt. Was ist damit gemeint? Mit Objekten der Realwelt konnen bestimmte Dinge gemacht werden, bzw. sie haben ein bestimmtes Verhalten (engl.: behaviour). Einiges davon ist fur die im Anwendungsbereich ablaufenden Geschaftsprozesse und damit fiir die Datenbank von Bedeutung. Zum Beispiel: • •

• •

• Aktivitatenerduldet oder initiiert

7 Objektorientierte Modellierung

PC fur ein Untemehmen konnen beschafft, in einer Abteilung installiert, einem Angestellten zugewiesen oder auch ausgemustert werden. Eine Abteilung in einem Untemehmen kann eingerichtet, mit Personal versehen, einen geografischen Standort mit bestimmten Raumen zugeordnet bekommen oder auch geschlossen werden. Angestellte eines Unternehmens konnen eingestellt, entlassen, befordert, versetzt werden und Gehalter bekommen. Datenbanksysteme (in einem Weltausschnitt zum Markt fur Datenbanksysteme) konnen auf den Markt gebracht bzw. von ihm genommen werden. Rechnungen konnen entstehen, bezahlt, stomiert oder gemahnt werden.

Beide Interpretationen, die passive ("konnen gemacht werden") und die aktive ("haben Verhalten") sind richtig. Es geht immer um Aktivitaten, die mit den Objekten in Zusammenhang stehen. In der Datenbank, bei den entsprechenden Datenbankobjekten, werden diese Methoden durch Operationen reprasentiert und direkt den Objekten zugeordnet. So wie die Realweltobjekte durch die Datenbankobjekte in der Datenbank reprasentiert werden, wird das Verhalten durch die Methoden reprasentiert. "Eingestellt werden" also durch eine Methode, die eine Personalakte in den Datenbanken des Unternehmens anlegt, usw. (vgl. die nahere Betrachtung der Methoden unten).

7.2 Statische Aspekte I - Objekte und Objektklassen

Objekte der Realwelt

..•werden reprasentiert ^^^^^^-

237

Datenbankobjekte \

haben...

...haben...

EigenSChaften

-werden^^^prasentiert

^Attribute

^ ^ ...haben...

...haben..

Vertialten" oo7

Abbildung 7.2-1:

-wird reprasentiert durch

^ Methoden -

Realwelt und ihre Reprasentation in der Datenbank

Damit wird bereits der qualitative Sprung deutlich, der hier vorliegt. In der objektorientierten Datenmodellierung werden die Objekte nicht nur informationell durch Attribute beschrieben, sondem es wird auch ihr Verhalten durch Methoden bzw. Operationen modelliert. Die Begriffe Methoden und Operationen werden oftmals so abgegrenzt, dass Operationen als die „... Dienstleistungen, die von einem Objekt angefordert werden konnen, ..." und als Methoden die Implementierungen der Operationen defmiert werden [Oestereich 1998, S. 236]. Welche Methoden bzw. Operationen auf ein Objekt anwendbar ist, hangt sehr stark von dessen Aufgabe in der Anwendung ab. Einige Operationen sind aber naturlich von grundlegender Bedeutung und liegen immer vor. So z.B. fur die Erzeugung oder die Loschung eines Datenbankobjekts (z.B. NEW und DELETE). Insgesamt geht es also darum, identifizierte Objekte mit gewUnschten Attributen und Methoden in eine geeignete Struktur zu bringen. Verschiedene Aspekte dieser Aufgabe werden in den nachsten Abschnitten betrachtet.

Methoden

Attribute Abbildung 7.2-2:

"Dreierbeziehung" Objekte - Attribute - Methoden

Methoden bzw. Operationen

238

7 Objektorientierte Modeliierung

7.2.2

Objekte finden

Wie sind nun Objekte in diesem Ansatz defmiert? Einige Autoren behelfen sich einfach mit einem Hinweis auf die entsprechenden Realweltobjekte, wie z.B. Bertino/Martino: „In object-oriented systems, each real world entity is represented by an object to which is associated a state and a behaviour." [Bertino und Martino 1993, S. 14]. Damit ist das Problem - zumindest was das Finden (bzw. Festlegen) der Objekte angeht - aber nur verlagert, denn Realweltobjekte besitzen auch nicht immer die Eindeutigkeit, die fur eine Losung der Frage notwendig ware. [Meier und Wust 1997, S. 3] defmieren Objekte als „Grundbausteine, aus welchen objektorientierte Anwendungssysteme aufgebaut werden" und prazisieren dann: „Unter einem Objekt versteht man einen wohlunterscheidbaren Gegenstand aus der realen Welt oder einen abstrakten Begriff aus der Vorstellung." [Meier und Wust 1997, S. 13] Meyer hebt - in Bezug zur objektorientierten Systemanalyse - an dieser Stelle auf statischen Aspekte eines Weltausschnitts ab, wenn er ausflihrt: „Frage nicht zuerst, was das System tut: Frage, WORAN es etwas tut!" [Meyer 1990, S. 54]. Ahnlich Hughes, wenn er als ersten Schritt nennt: „... to extract the meaningful objects and concepts from the real-world enterprise being modelled." [Hughes 1991, S. 82]. Er wird dann allerdings etwas praziser, indem er auf die Eigenschaften und Methoden Bezug nimmt und - mehr oder weniger - ausfuhrt, dass „etwas", was eigene Eigenschaften und Methoden hat, zu einem eigenen Objekt wird. Dies entspricht, lasst man die Methoden weg, dem, wie hier in Kapitel 2 die Objektfmdung defmiert wurde und es soil auch hier so weitergefiihrt werden. Ausgangspunkt sind auch hier die Phdnomene der Realwelt, die im Weltausschnitt beobachtet werden. Definition 7.2-1: Realweltphanomene Wir bezeichnen als Realweltphanomene die Wahmehmung einzelner Aspekte des Weltausschnitts (Anwendungsbereichs) in datenbanktechnischer Hinsicht, d.h. alles was wir mit den Werkzeugen der Datenbanktheorie erkennen konnen.

7.2 Statische Aspekte I - Objekte und Objektklassen

239

In dem Augenblick, in dem wir Realweltphanomene wahrnehmen, stellen sie Information dar. Nicht unbedingt schon Information, die flir eine Datenbank tauglich ist, aber immerhin^^l Im Regelfall sind dies die Phanomene, von denen man annimmt oder weii3, dass sie fiir den Zweck der Datenbank, bzw. die Abwicklung der zugehorigen Geschaftsprozesse von Bedeutung sind. Wesentlich ist nun, dass alle die Realweltphanomene, denen man eigenstdndige Attribute zuordnet, Objektcharakter erhaltenl 14. Die konkrete Auspragung der Attribute eines Objekts wird sein Zustand gQnannt. Die Mehrzahl bei „Attribute" ist hier wichtig. Ein einziges Attribut (das dann nur identifizierend sein konnte) geniigt noch nicht. Aber bereits das Zweite etabliert die Beschreibung von Objekten. Womit sich der Begriff Objekt, wie oben in Kapitel 2 auch schon, auf die Bedeutung von Informationstrdger reduziert. Im Unterschied aber z.B. zum relationalen Ansatz gilt hier: Die Attribute, die ein Objekt (und dann eine Objektklasse, vgl. unten) beschreiben, werden nicht weiter zerlegt, wie im relationalen Ansatz, sondem bleiben (mehr oder weniger, dazu unten mehr) zusammen. Dies lost auch die in der Literatur immer wieder gestellte Frage, wann ein beobachtetes Phanomen Objekt oder Eigenschaft ist. Dient es dazu, ein Realweltphanomen zu beschreiben, ist es Eigenschaft und wird als Attribut bzw. Attributsauspragung modelliert. Wird es selber durch andere Informationen beschrieben, ist es Objekt (genauer, da es sich ja um Informationen handelt: „... identifiziert es ein Objekt"). Hierzu ein Beispiel:

Objektfindung durch Attribute

objekt oder Eigenschaft?

Wenn es Geschaftsstellen eines Untemehmens in mehreren Stadten gibt, sollten dann die Stadte eine Eigenschaft der Objekte Geschaftsstellen sein oder sollten sie zu eigenstandigen Objekten werden? Mit der oben eingeftihrten Kegel, dass zu eigenen Objekten die Realweltphanomene werden, die nicht nur durch eine Benennung identifiziert, sondem durch weitere Attribute naher beschrieben werden, kommt man zu folgendem Ergebnis: Werden die Stadte naher beschrieben, z.B. durch Einwohnerzahl, Kaufkraft, Region, usw. mussen eigene Objekte angelegt werden. Sind die Namen der Stadte allein als Eigenschaften der Geschaftsstellen gefiihrt, dann sollten sie Attribut der Geschaftsstellen sein. Methoden werden tiblicherweise von Objekten abgeleitet und dann mit diesen verwaltet. Oftmals geben Methoden aber auch Hinweise auf zu identifizierende Objekte. Nehmen wir z.B. die Methode Rechnungsstellung. Sie gibt nicht nur einen eindeutigen Hinweis auf die Objekte Rech-

An dieser Stelle soli davon abgesehen werden, dass natiirlich ein getibter Modellierer einen zu modellierenden Weltausschnitt gleich mit den "richtigen" Informationsarten beschreibt, ja evtl. auch gleich mit hoheren Modellierungskonstrukten. Dass dies in weiteren Modellierungsschritten durch das Mitberiicksichtigen von Beziehungen u.U. modifiziert wird, bleibt unbenommen.

objektfindung durch Methoden

240

Durch Methoden zu Attributen

7 Objektorientierte Modellierung

nungen, sondem auch gleich auf die Adressaten der Rechnungen (Kunden) und die Waren oder Dienstleistungen, um die es geht. Nicht vergessen werden soil an dieser Stelle, dass Methoden auch Hinweise auf zu erfassende Attribute geben. Eine Methode Gehaltszahlung erzwingt dann die Erfassung von Attributen wie Familienstand, Steuerklasse, usw. Zusammenfassend und mit Beriicksichtigung der hier auch betrachteten Methoden konnen wir somit den Objektfmdungsprozess wie folgt definieren: Definition 7.2-2: Objekte Objekte im Sinne des objektorientierten Ansatze sind Phanomene der Realwelt, die durch Attribute beschrieben und/oder denen Methoden zugewiesen werden.

Beispiel

Dies ist nur das Ergebnis des ersten Modellierungsschritts, das in den folgenden Schritten (vgl. unten) modifiziert wird. Betrachten wir als Beispiel die Angestellten eines Untemehmens. Sie existieren, wir nehmen sie wahr, wir weisen Informationen zu (die fur die Geschaftsprozesse benotigten), z.B. Name Vomame Postleitzahl (PLZ) Ort StraBe Einstellungsdatum Geburtstag usw. Dann aber auch Methoden wie • • • • •

Einstellen (des Realweltobjekts, Erzeugen des Datenbankobjekts) Entlassen (des Realweltobjekts, Loschen des Datenbankobjekts) Versetzen Befordem Gehalt zahlen

usw. Berucksichtigt man, dass Methoden nur zum Einsatz kommen konnen, wenn Attribute mit ihren Attributsauspragungen da sind**^ kann zusammenfassend festgehalten werden, dass ein Objekt hier genauso wie oben fiir die anderen Modellierungstechniken als ein Informationstrager definiert werden kann, der durch die Zuweisung von Attributen^ ^^ und Attributsauspragungen identifiziert bzw. spezifiziert wird. Welche Information soil sonst verarbeitet werden? Am Anfang jeder Modellierung stehen die Werkzeuge, mit denen wir die Dinge identifizieren und beschreiben. Dies geschieht iiber die Zuweisung von Eigenschaften, die

7.2 Statische Aspekte I - Objekte und Objektklassen

241

Mittlerweile muss auch hier diese Definition von Objekten dahingehend erganzt werden, dass natiirlich weitere Informationstypen wie Grafik, Bild, Text, usw. ebenfalls zur Identifizierung und Spezifizierung von Objekten dienen konnen. Der in diesem Abschnitt beschriebene Zusammenhang zwischen Objekten und Attributen wird in der gesamten Literatur so gesehen, wenngleich oftmals anders dargestellt. So schreiben Bertino/Martino einfach: „...a set of attributes (or instance variables or slots) is associated to each object;..." [Bertino und Martino 1993, S. 13] Andere Autoren schreiben statt von Attributen einfach von Eigenschaften, in Anlehnung an den umgangssprachlichen Begriff. Oftmals geschieht dies, weil durch das Konzept der komplexen Objekte (vgl. unten) nicht nur einfache Attribute den Objekten zugeordnet werden. 7.2.3

1:1-Abbildung

Viele Autoren gehen bei der objektorientierten Datenmodellierung so weit, eine 1:1 - Beziehung zwischen den Objekten der Datenbank und denen des Weltausschnitts zu fordem (So z.B. [Bertino und Martino 1993, S. 14], [Hughes 1992, S. 75]). Diese direkte Ubereinstimmung zwischen Realweltobjekten („real world entities") und Datenbankobjekten („objects")^^^ (bzw. Konstrukten des Datenmodells) wird im Datenbankbereich geradezu als zentral angesehen. Bin Grund dafiir ist sicherlich der Wunsch, die Segmentierung der Information ftir ein Objekt in konventionellen Datenbanken zu uberwinden. In relationalen Datenbanken werden zum Beispiel die Attribute zur Beschreibung eines Objekts in der Kegel (nach der Normalisierung) Uber eine groBere Zahl von Relationen verteilt. Da Ublicherweise eine Relation auch einer Datei entspricht, fuhrt dies zu einer Segmentierung auf logischer und auf physischer Ebene, die viele Auswertungen, Abfragen, usw. sehr kompliziert macht. Es gehort zu den Grundmerkmalen objektorientierter Modelle, dass Attribute vor Direktzugriffen geschutzt sind. Normalerweise kann auf ihre Auspragungen nicht direkt zugegriffen werden, so wie z.B. in Relationalen Datenbanken, sondem nur Uber die Methoden, die fur die Objekte definiert sind. Dies wird auch als Kapselung (encapsulation) bezeichnet, da die Attribute sozusagen vor den Anwendungen versteckt sind und nur uber die Methoden verandert werden konnen (vgl. Abschnitt 7.3.5).

Bildung von Kategorien, usw. In alien diesbeztiglichen methodischen Ansatzen wird diese Vorgehensweise in das Attributkonzept hinein abgebildet. *'^ Die Klammern geben den Sprachgebrauch der internationalen englischen Fachliteratur

Geschutzte Attribute

Kapselung

242

Andere Auffassungen

7 Objektorientierte Modellierung

Ganz wird dieses Prinzip allerdings nicht durchgehalten. Objektorientierte Datenbanksysteme erlauben meist den direkten Zugriff, z.B. zum Zwecke der Abfrage. Es gibt Autoren, die bei der Klarung des Objektbegriffs auf den Attributsbegriff verzichten. So z.B. [Geppert 1997], der zwar auch von der verbreiteten Objektvorstellung ausgeht, "Ein Objekt hat einen Wert (Zustand) und ein vordefiniertes Verhalten" [Geppert 1997, S. 2], der dann aber von den moglichen "Werten" von Objekten schreibt: "Der Wert eines Objekts kann einfach oder zusammengesetzt sein. Einfache Werte werden durch die Anwendung von Wertkonstruktoren gebildet. Typische Konstruktoren sind Menge, Liste und Tupel" (ebenda, Hervorhebungen dort). 7.2.4

Klassen bilden

Die so gefundenen Objekte werden nun zu Objektklassen zusammengefasst. Im Unterschied zu den anderen Datenmodellierungsansatzen, wo dies auch geschieht (vgl. Kapitel 2, 3 und 4), miissen hier noch zusatzlich die Methoden berucksichtigt werden, so dass gilt: Definition

Definition 7.2-3: Objektklasse Objekte, die durch dieselben Attribute beschrieben und auf denen dieselben Methoden eingesetzt werden, werden zu einer Objektklasse zusammengefasst. Diese Klassenbildung ist ein gangiger Abstraktionsmechanismus aller Modellierungsansatze, ein Schritt, um die Komplexitat der realen Welt zu reduzieren. Die angedachte Klassenbildung sollte im Ubrigen bereits bei der Objektfmdung berUcksichtigt werden. Realweltphanomene sollten nur dann zu Objekten gemacht werden, wenn aus diesem Schritt mehrere Objekte entstehen, die dann zu einer Objektklasse werden konnen. D.h., parallel zum Suchen nach den geeigneten Objekten muss bereits reflektiert werden, welche Objekte zusammen in eine Objektklasse gehoren. In einer solchen Klasse fmden sich Objekte mit gemeinsamer Struktur und gemeinsamem Verhalten, also Objekte, die durch dieselben Attribute und sonstige Informationstypen beschrieben werden und auf die dieselben Methoden anwendbar sind. Oftmals denkt man auch bereits an Objektklassen, wenn man iiber Objekte redet, da man diesen Abstraktionsschritt fast automatisch vollzieht. Im objektorientierten Ansatz wird jedes Objekt Instanz seiner Klasse genannt.

7.2 Statische Aspekte I - Objekte und Objektklassen

243

So wie sie nun hier definiert sind, werden Objektklassen auch zu Verwaltern von Informationen*^^. Zu den Informationen, die bei der Klasse verwaltet werden, gehoren • • •

Informationen der Objektklasse

die Informationen der einzelnen Instanzen, Informationen zur Klasse als Ganzes, Prozeduren, mit denen die interne Representation der Datenstruktur (Beschreibung der Objekte) manipuliert wird.

Zu den Informationen fiir die Klasse als Ganzes gehoren Attribute, die fur alle Instanzen gleich sind und Informationen wie „Anzahl Objekte" oder der Mittelwert eines Attributs, fur das ein solcher berechnet werden kann. Solche Attribute werden Klassenattribute genannt. Sie sind so definiert, dass eine Auspragung die gesamte Klasse betrifft. Ein Beispiel ware AnzahlMitarbeiter und Gehaltssumme in einer entsprechenden Objektklasse. Daneben gibt es auch klassenbezogene Methoden (class methods). Sie sind unabhangig von der Existenz der einzelnen Objekte, betreffen stattdessen die Gesamtheit der Objekte der Klasse. Ein Beispiel in einer Klasse PC kormtQ feststellenGesamtzahl sein, eine Methode, die die jeweilige Gesamtzahl erfasster PC feststellt und in einem Klassenattribut Anzahl festhalt. Wie in der UML vorgeschlagen (vgl. [Balzert 1999a, S. 26f| werden in den textlichen und grafischen Darstellungen von Objektklassen Klassenattribute und -methoden durch Unterstreichung gekennzeichnet (vgl. die Abbildungen unten). Klassenmethoden und -attribute machen einen grundsatzlichen Unterschied bei der Klassenbildung im objektorientierten Ansatz und bei alteren Modellierungsansatzen, z.B. der Bildung von Entitatstypen in der ERModellierung, deutlich. Sie zeigen, dass hier auch die Klassen selbst Trager von Attributen und Methoden sein konnen. Der Vorgang der Klassenbildung ist ein sehr grundlegender und nattirlicher. Die menschliche Wahmehmung hangt wesentlich davon ab. Wenn wir Menschen Realitat wahrnehmen, bilden wir standig Kategorien aus Gruppen ahnlich wahrgenommener Objekte, Ereignisse, usw. Nur so konnen wir Informationen aufiiehmen und verarbeiten. Soweit die ersten Schritte, die zu Objekten und Objektklassen fuhren. Es soil nochmals darauf hingewiesen werden, dass diese ersten Ergebnisse natiirlich im weiteren Modellierungsvorhaben noch modifiziert werden konnen. Beziehungen zwischen Realwelt- oder Datenbankobjekten, wie sie z.B. im ER-Ansatz als relationship types festgelegt werden, wurden hier bewusst noch nicht betrachtet. Sie spielen hier, im Gegensatz zu den alteren Ansatzen, im ersten Schritt noch keine RoUe.

Unabhangig vom Umfeld, also in der Datenbank, im System oder im Programm.

Klassenattribute

Klassenmethoden

244

Ausnahmen

Operationen auf Instanzen

In den meisten objektorientierten Systemen kann ein Objekt nur Mitglied einer Objektklasse sein, es gibt aber auch Ausnahmen (vgl. [Bertino und Martino 1993, S. 24] dazu und fur ein Beispiel. Vgl. auch die Ausfiihrungen zur Mehrfachvererbung unten). Wie oben ausgefuhrt, hat jedes Objekt einer Objektklasse denselben Aufbau, d.h. dieselben Attribute und Methoden. Es gibt allerdings Datenmodelle, Bertino/Martino erwahnen O2, die bei einzelnen Objekten einer Objektklasse zusatzliche Attribute und/oder Methoden erlauben. Mit dem Konzept der Objektklasse konnen nun die oben schon angefuhrten Operationen NEW und DELETE besser beschrieben werden: •

• Darstellung von Objektklassen

7 Objektorientierte Modellierung

NEW schafft eine neue Instanz mit genau den durch die Klassendefinition gegebenen Datenstrukturen und Methoden (nattirlich ohne Auspragungen). DELETE loscht eine solche Instanz.

In der Literatur werden Objektklassen meist in Anlehnung an eine sozusagen „durchschnittliche" objektorientierte Programmiersprachennotation textlich so dargestellt: class Angestellte properties Name: character Vorname: character Eintrittsdatum: date Gehalt: money operations create einstellenO entlassen() zahlenGehalt () end Angestellte

Darstellung einzelner Objekte

Fiir die grafische Darstellung wird hier die Notation der UML gewahlt. Bei ihr wird eine Objektklasse durch ein Rechteck dargestellt. Im obersten Teil findet sich der Name der Objektklasse (fett gesetzt), im mittleren die Attribute, darunter die Methoden. Als Klassenname wird ein Substantiv verwendet, evtl. erganzt durch ein Adjektiv. Vgl. die folgende Abbildung. Auch fiir einzelne Objekte und ihren Zusammenhang sieht die UML eine grafische Notation vor. Die dabei entstehenden Objektdiagramme (object diagrams) "sind sozusagen Momentaufiiahmen bzw. Schnappschusse des Systems" [Balzert 1999, S. 19]. Da in der Datenmodellierung Betrachtungen auf der Ebene der Einzelobjekte nicht erfolgen, wird dies hier nicht naher betrachtet.

7.2 Statische Aspekte I - Objekte und Objektklassen

245

Angestellte Name: character Vorname: character Eintrittsdatum: date Gehalt: money Anzahl: integer einstellenO entlassenO zahlenGehaltO bestimmenAnzahlQ

Abbildung 7.2-3:

7.2.5

Objektklassen mit Klassenmethoden und -attributen in der UML

Klassifikation und Instantiierung

Die wichtigste Form der Beziehung zwischen Objekten ist die (strukturelle) Gleichheit. Sie ist Basis der oben beschriebenen Klassenbildung und entspriclit einer grundsatzlichen menschlichen Vorgehensweise, der Kategorisierung wahrgenommener Phanomene. Datenbanktechnisch werden also strukturell (bzgl. Attribute, weiteren Informationstypen und Methoden) gleiche Objekte zusammengefasst. Die Defmitionsmerkmale dieser Objekte werden bei der Klasse hinterlegt, sodass formuliert werden kann: Die Objekte einer Klasse werden durch die Klassendefinition beschrieben. Dieser Vorgang des Zusammenpackens verschiedener Objekte zu einer Klasse wird Klassifikation (classification) genannt. Der gegenteilige Schritt, von der Klasse zum Einzelobjekt, oder auch die Erzeugung neuer Objekte einer Klasse gemaB den bei der Klassendefinition hinterlegten Definitionsmerkmalen wird Instantiierung (instantiation) genannt. Das neu entstehende Objekt wird auch mit Instanz bezeichnet. Instantiierung bedeutet somit, dass ein- und dieselbe Definition benutzt wird, um Objekte mit demselben Aufbau und demselben Verhalten zu erzeugen. Konkret wird Folgendes festgelegt: • • •

die Menge der Attribute der Instanzen die Menge der Operationen die Menge der Methoden, die den Operationen entsprechen

Die Instantiierung bedeutet also die Erzeugung eines neuen Objekts nach den Eigenschaften, die durch die Objektklasse vorgegeben sind. Die dazu verwendete Methode hat meist die Bezeichnung NEW oder CREATE.

Klassifikation

Instantiierung

246

7 Objektorientierte Modellierung

Die Informationen uber die Objekte konnen nach der Klassenbildung so gespeichert werden, dass die Bezeichnungen und Festlegungen der Attribute und Methoden nur bei der Klasse gespeichert werden. Die Attributsauspragungen miissen natiirlich weiterhin getrennt abgespeichert werden. Dies wird so realisiert, dass es zu jeder Klasse ein Klassenobjekt (class-object) gibt, das die Informationen verwaltet, die bei alien Instanzen und Methoden gleich sind. Das Klassenobjekt wird getrennt von den Informationen der Instanzen gespeichert. Hughes vergleicht das Verhaltnis von Klassen und Instanzen mit dem einer „type definition" und Variablendeklarationen in der konventionellen Programmierung [Hughes 1991, S. 86]. 7.2.6

Methoden vertieft

Methoden im Sinne der objektorientierten Datenbanken gehen zurtick auf das Konzept der abstrakten Datentypen. Wie oben schon ausgefiihrt, werden in der objektorientierten Literatur Methoden so gesehen, dass durch sie die "Veranderungen" in die Datenbank und die Anwendung hinein abgebildet werden, die ein Objekt erfahren kann und die fur die zu unterstiitzenden Geschaftsprozesse von Bedeutung sind^^^. Methoden stehen somit im Gegensatz zu den statischen Aspekten der Anwendung, die in der englischsprachigen Literatur Zustand (state) eines Objekts genannt werden: „In object-oriented systems, each real world entity is represented by an object to which is associated a state and a behavior. The state is represented by the values of the object's attributes. The behaviour is defined by the methods acting on the state of the object upon invocation of corresponding operations" [Bertino und Martino 1993, S. 14]. Wie ebenfalls oben schon angemerkt, greift der Begriff Verhalten (behavior) etwas zu kurz, da es hier auch um Veranderungen geht, die ein Objekt von "auBen" erfahren kann. Z.B. der Angestellte, der eingestellt oder entlassen wird. Erst beides zusammen, das Verhalten eines Objekts und die von auBen kommenden zulassigen Veranderungen seines "Zustands" (im datenbanktechnischen Sinn) beschreibt umfassend, was damit gemeint ist: Definition 7.2-4: Methoden: Als Methoden werden alle Aktionen bezeichnet, die mit den Objekten einer Objektklasse geschehen konnen - aktiv (Verhalten) oder passiv.

'*^ Auf einer etwas weniger „prosaischen" Ebene kann dies so formuliert werden, dass die Methoden einer Objektklasse festlegen, auf welche Weise die Information, durch die eine Objektklasse beschrieben wird, verarbeitet werden kann,

7.2 Statische Aspekte I - Objekte und Objektklassen

247

Betrachtet man Methoden nur im Kontext der objektorientierten Programmierung und im Systemdesign, drangt sich diese Unterscheidung nicht so klar auf, auch wenn sie, z.B. in einer fundierten Systemanalyse, naturlich von Bedeutung ist. Denkt man dagegen im Kontext der Datenbanken, wird diese Unterscheidung sehr deutlich. Um einen Begriff von oben wieder aufzunehmen: Methoden resprasentieren auf dieser Stufe die dynamischen Aspekte eines Weltausschnitts, im Gegensatz zu den Attributen, die die statischen reprasentieren. Die folgende Abbildung mochte dies verdeutlichen. Statisch vs. Dynamisch

Die Objekte eines Weltausschnitts haben im Raiimen derzu unterstutzenden Geschaflsprozesse statisciie Aspekte und

(="Zustand" der Objekte reprasentiert durch Attribute, gemessen durch Attributsauspragungen)

dynamisciie Aspekte oo22

Abbildung 7.2-4:

(="Verhalten" der Objekte, reprasentiert durch Methoden)

"Statisch" vs. "Dynamisch"

Die dynamischen Aspekte werden auf dieser Stufe also noch einzelnen Objekten bzw. Objektklassen zugeordnet. Damit stellen sie einen Teil des "Verhaltens" dar, das insgesamt in den Geschaftsprozessen des jeweiligen Weltausschnitts benotigt wird. Dies wird weiter unten vertieft diskutiert. Exkurs: Konzeptionelle Datenmodellierung Die folgende Abbildung soil die in diesem Kapitel bisher diskutierten Modellierungsschritte im Zusammenhang darstellen. Das was die Modellierer ganz zu Beginn ihrer Arbeit wahrnehmen, stellt bereits eine erste Abstraktion der Realitat dar. Um diesen Schritt kummert sich eine ganze Diskussionsrichtung, die Konzeptionelle Datenmodellierung^^^ (conceptual modeling). Sie soil hier nicht betrachtet werden, nur eine Anmerkung sei erlaubt: Da die Wahrnehmung immer durch die bewusst Oder unbewusst mitbedachten Werkzeuge gepragt wird, nimmt man im konzeptionellen Modell vor allem Objekte bzw. Objektklassen wahr und vernachlassigt die vielen anderen Aspekte der Real welt. Mit anderen Worten: Das Werkzeug pragt die Wahrnehmung. Fiir die wahrgenommenen Objekte und ihre Klassen, d.h. fiir deren Eigenschaflen und deren „Verhalten" werden nun Reprasentationen erstellt: Es entstehen Datenbankobjekte. Attribute und Methoden. Dies sollen die Pfeile (2) und (3) in der Abbildung andeuten. Auf den Reprasentationen dieser Objekte und Objektklassen in der Datenbank, den Datenbankobjekten und -objektklassen werden dann auch Reprasentationen Wohl beeinflusst durch die englische Bezeichnung schreiben seit einigen Jahren einige deutschsprachige Autoren von konzeptueller Datenmodellierung.

Verhalten im GeschaftsP^ozess

Werkzeug pragt Wahrnehmung

248

7 Objektorientierte Modellierung

des „Verhaltens" realisiert, die - gleich wie oben - festlegen, was „mit den Datenbankobjekten geschehen kann". Im obigen Beispiel waren das entsprechende Programme, mit denen all das geleistet wird, was mit dem Einstellen, Entlassen, Befordern, usw. von Angestellten verbunden ist.

Re prase ntation des "Verhaltens" durch Methoden.

1

t

Datenbank Datenbankobjekte, Attribute und Methoden Abbildung 7.2-5: Aktivierung von Methoden

Von der Realwelt in die Datenbank

Wodurch konnen Methoden aktiviert werden? Dies wird weiter unten prazisiert. Schon hier soli angemerkt werden, dass die typische Aktivie-

7.2 Statische Aspekte I - Objekte und Objektklassen

249

rung durch Aufiruf aus der eigenen Klasse heraus oder durch Objekte anderer Klassen geschieht. Auf jeden Fall sind hier aber die Methoden mit der zugehorigen Datenstruktur fest verkntipft. Diese Kapselung (vgl. oben) fuhrt dazu, dass die Attribute nur Uber die Methoden angesprochen werden konnen. [Bertino und Martino 1993] geben noch Hinweise auf die Begrifflichkeit im Umfeld objektorientierter Methoden: In general, the definition of a method consists of two components: signature and body. The signature specifies the name of the method, the names and classes of the arguments, and the class of the results, if the method returns one." [Bertino und Martino 1993, S. 18]. Naheres hierzu, auch zur Realisierung in einzelnen Datenbanksystemen ebenda. [Balzert 1999a, S. 32f| weist auf die Moglichkeit hin, Methoden (sie spricht von Operationen) zu klassifizieren: • • • • • • •

Operationen Operationen Operationen Operationen Operationen Operationen Operationen

mit lesendem Zugriff mit schreibendem Zugriff zur Durchfuhrung von Berechnungen zum Erzeugen und zum Loschen von Objekten zur Selektion von Objekten zum Herstellen von Verbindungen zwischen Objekten zur Aktivierung von Operationen anderer Klassen

AuBerdem betont sie die Rolle von Verwaltungsoperationen, die grundlegenden Operationen einer Klasse. Diese werden aus Griinden der Ubersichtlichkeit bei der grafischen Notation nicht angegeben. Zu ihnen gehoren[Balzert 1999a, S. 34]: • • • • • • •

new() zum Erzeugen eines Objekts deleteO zum Loschen eines Objekts setAttribute(): Eintragen einer Attributsauspragung getAttribute: Lesen einer Attributsauspragung link(): Aufbau einer Verbindung zwischen Objekten genauer unlink(): Entfemen einer solchen Verbindung getlink(): Lesen einer Verbindung

Die Unterscheidung externer und interner Operationen, die [Balzert 1999a, S. 33] trifft, thematisiert den Verursacher des Operationsaufrufs. Exteme Operationen werden direkt von der Benutzungsoberflache aktiviert, interne immer von einer anderen Operation "innerhalb des Systems".

Kapselung

signature und body

Identitat und Gleichheit

250

7 Objektorientierte Modellierung

7.2.7

Identitat

Wie oben ausgefuhrt, soil in objektorientierten Datenbanken jedem Realweltobjekt („real world entity") ein Datenbankobjekt („object") entsprechen. Diese werden eindeutig identifiziert durch einen Objektidentifizierer (object identifier, OID), der vom Datenbanksystem vergeben wird. Er ist unabhangig von den Attributen der Objektklasse. Insbesondere darf dieser OID nicht mit dem Schliissel von Relationen verwechselt werden. Mit diesem Konzept kann zwischen Identitat und Gleichheit von Objekten unterschieden werden. Mehrere Objekte konnen absolut gleich sein, gemessen an den Auspragungen ihrer Attribute, und sind doch nicht identisch. Ein Beispiel waren die Produkte einer Serienfertigung, z.B. Femsehapparate, die - gemessen an den beschreibenden Attributen absolut gleich sind. [Bertino und Martino 1993, S. 15] unterscheiden denn auch identity equality und value equality. Erstere erfasst, ob es sich um dasselbe Objekt handelt, zweitere ob die Attribute und Attributsauspragungen gleich sind. Ansatze zur Konstruktion von OID's finden sich bei [Bertino und Martino 1993, S. 16]. Meier/Wust bezeichnen eine Objektidentifikation auch als Surrogat (surrogate) [Meier und Wust 1997, S. 15]. Der Begriff soil andeuten, dass die identifizierende Information Stellvertreter flir das Realweltobjekt ist. Sie definieren dann, neben der Eindeutigkeit und der Unabhangigkeit von Objekteigenschaften, folgende Eigenschaften von Surrogaten: • •

Wertbasierte Suchschlussel

Unverdnderbarkeit: Ein einmal vergebener Wert bleibt unverandert, er wird nicht neu vergeben, auch wenn das Objekt geloscht wird. Ortsunabhdngigkeit: Sie werden unabhangig vom geografischen Speicherungsort und von der Speicherungsform vergeben.

Dies macht sie geeignet flir den "referenzbasierten Aufbau von Beziehungen" zwischen Objektklassen (vgl. unten sowie [Meier und Wust 1997, S. 16], [Geppert 1997, S. 2]). [Meier und WUst 1997] weisen darauf hin, dass trotz der Existenz dieses Systemschlussels andere benutzerbezogene Identifikations- oder Zugriffsschlussel iiber die Attribute eingerichtet werden konnen, z.B. Personalnummem, Produktnummem, Kontonummem, Artikelnummem, usw. Diese nennen [Meier und Wtist 1997] wertbasierte Suchschlussel: "Ein wertbasierter Suchschliissel (value-based search key) ... identifiziert ein bestimmtes Objekt auf Grund von Attributwerten oder Attributwertkombinationen." [Meier und Wust 1997, S. 38]. Seine Spezifizierung erfolgt durch den Zusatz Key in der Klassendefinition, z.B. Key(Personalnummer).

7.3 Statische Aspekte II - Objekte in Beziehung setzen

7.2.8

251

Alles nur Objekte?

Es gibt im objektorientierten Ansatz auch die Uberlegung, alle irgendwie beriicksichtigten Informationen als Objekte aufzufassen. Also auch das, was ublicherweise als Attributsauspragung aufgefasst wird. Mit diesem Standpunkt wird dann das Attribut zu einer Aggregation der Attributsauspragungen, usw. Mit den Worten von Bertino/Martino: „In almost all object-oriented data models, an attribute has associated with it a domain which specifies the classes of the possible objects that can be assigned as values to that attribute." ... „The fact, that an attribute of a class C has a Class C as a domain, implies that each instance of C assumes as the value of the attribute an instance of C , or of a subclass of it. An aggregation relationship is established between the two classes. An aggregation relationship from class C to class C specifies that C is defined in terms of C since C is in turn defined in terms of other classes, the set of classes in the schema is then organized in an aggregation hierarchy."" [Bertino und Martino 1993, S. 24f| Teilweise wird dies auch im Datenbankansatz versucht. Es ist aber nicht sinnvoll, schafft unnotige Komplexitat und wird deshalb hier nicht nachvollzogen. Hier bleibt es bei der grundlegenden Unterscheidung von Objekten und Attributen (bzw. Attributsauspragungen (oft an den entsprechenden Stellen "Werte" (values) genannt), etwa so, wie Bertino/Martino dies formulieren: „However, there are some models in which both objects and values (often called literals) are allowed and in which not all entities are represented as objects. Informally, a value is self-identifying and has no OID associated with it. All primitive entites, such as integers or characters, are represented by values, whereas all non-primitive entities are represented by objects." [Bertino und Martino 1993, S. 14]

7.3

Statische Aspekte II - Objekte in Beziehung setzen

In diesem Abschnitt werden die Techniken betrachtet, mit denen Objektklassen (und damit Objekte) miteinander in Beziehung gesetzt werden konnen, denn naturlich stehen auch in objektorientierten Datenmodellen die einzelnen Objektklassen nicht unverbunden nebeneinander. 7.3.1

Assoziation - Semantische Verknupfung

Eine zentrale datenbanktechnische Verkniipfiing ist die zwischen Objekten verschiedener Objektklassen auf Grund semantischer Gegebenhei-

252

Beispiel PC-Nutzung

Beispiel Abteilungszugehongkeit

objektwertige Attribute

7 Objektorientierte Modellierung

ten^^\ Sie wurde oben in den anderen Modellierungsansatzen bereits angesprochen und sie hat auch hier in der objektorientierten Modellierung Bedeutung. Diese originar datenbanktechnische Verkniipfiingstechnik wird in der Literatur, die sich mit objektorientierter Programmierung oder objektorientierter Systemanalyse beschaftigt, oft Ubersehen, ist aber von zentraler Bedeutung, denn nattirlich sind auch in objektorientierten Datenmodellen die einzelnen Objektklassen semantisch miteinander verkniipft^^l Nehmen wir als Beispiele die zwei Objektklassen PERSONAL und PC. Zwischen ihnen kann eine semantische Beziehung dergestalt existieren, dass einem Mitarbeiter ein PC zugeordnet ist, ein PC aber verschiedenen Mitarbeitem zur Verfiigung steht. Oder die iibliche Abteilungszugehorigkeit, eine Beziehung zwischen den Objektklassen ABTEILUNGEN und PERSONAL. Ein Angestellter jg^ Q^^Q^ Abteilung zugeordnet, eine Abteilung hat mehrere Angestellte. Voraussetzung ist hier nattirlich, dass Abteilungen und Angestellte jeweils als eigene Objektklassen im Datenmodell angelegt sind. Genau um solche Beziehungen geht es. Naturlich werden von der Vielfalt in der Realitat vorkommender semantischer Beziehungen nur die betrachtet, die fur die jeweilige Anwendung und ftir die jeweiligen Geschaftsprozesse von Bedeutung sind. Einige Autoren (z.B. auch [Meier und Wust 1997, Abschnitt 2.3.1], [Balzert 1999a, S. 40]) bezeichnen diese Art Verknupfting in Anlehnung an die UML als Assoziation, andere sprechen von Referenzen zwischen Objekten (so z.B. [Geppert 1999, S. 6f]) oder von objektwertigen Attributen. Gemeint ist immer dasselbe: die Verknupfungen, die sich aus der Semantik des Weltausschnitts ergeben. Exkurs: Konkrete Realisierung von Assoziationen durch objektwertige Attribute Die Beschreibung solcher Beziehungen als objektwertige Attribute sieht so aus, dass Attribute, ahnlich einem Zeiger (pointer) die konkrete Beziehung zwischen den Objekten der einen und der anderen Objektklasse etablieren. Objektwertige Attribute verweisen also von den Objekten der einen Objektklasse direkt auf die Objekte der entsprechenden anderen. Das folgende Beispiel (nach [Hughes 1992, S. 82]) zeigt eine mogliche Realisierung einer solchen Beziehung. Es besteht aus den drei Objektklassen HOTELS, FIRMEN und PERSONEN. In der Klasse HOTELS verweisen die Attribute Eigentiimer und Manager auf andere Objektklassen. Ein Eigentiimer ist Objekt der Objektklasse FIRMEN, ein Manager ist Objekt der Objektklasse PERSONEN. In der objektorientierten Systemanalyse werden Assoziationen so gesehen, dass sie notwendig sind, damit Objekte miteinander kommunizieren konnen (vgl. beispielhaft [Oesterreich 1998, S. 268]). Dies bedeutet naturlich nicht, dass alle Objektklassen mit alien anderen in einer solchen Beziehung stehen. Allerdings gilt, dass jede Objektklasse mit dem Gesamtmodell auf die eine oder andere Weise verbunden sein muss. Isolierte Objektklassen ergeben in einem solchen Modell keinen Sinn.

7.3 Statische Aspekte II - Objekte in Beziehung setzen

253

CLASS Hotels /definiert die Klasse 'Hotels' PROPERTIES /Liste der Attribute Name: string; Adresse: string; Eigentiimer: Firma; Manager: Person; Einrichtungen: Set (OptionsTyp); OPERATIONS /Liste der Methoden Erzeuge (...) Reservierung (Raumnr: integer; Gast: Person; Ankunftsdatum, Abreisedatum: DatumsTyp); END Hotels CLASS Firmen PROPERTIES Name, Hauptsitz, Telefon: String; OPERATIONS END Firmen CLASS Personen PROPERTIES Name, Adresse: String; Geburtsdatum: Date; OPERATIONS END Personen

Insbesondere in Abgrenzung zum relationalen Modell muss hier noch darauf hingewiesen werden, dass die Realisierung dieser Beziehungen zwischen Objekten modelliert wird, indem die entsprechenden Objekte mit Hilfe ihrer Objektidentifizierer verknupft werden und nicht mit Hilfe attributbasierter Schliissel und Fremdschltissel. In einigen Ansatzen wird auch das Yerhaltnis Objekt - Attribut und Attribut - Attributausprdgung als Beziehung zwischen Objekten interpretiert (vgl. oben). Dies schafft allerdings eine erhebliche Komplexitat, die auch dadurch nicht ausgeglichen wird, dass dann auf das Attributkonzept verzichtet werden kann. Andere sprechen bei der Diskussion solcher semantischer Verknupfungen von inversen Beziehungen (so z.B. [Hughes 1992]). Auch hier ist gemeint, dass bei einem Attribut an Stelle einer Attributsauspragung eine andere Objektklasse angegeben werden kann^^^. Mit anderen Worten: Eine Eigenschaft selbst kann wieder eine Klasse sein [Hughes 1992]. Die Begriffswahl macht aber auf die Tatsache aufmerksam, dass eine solche Beziehung zwei Richtungen hat.

123 In [Hughes 1992, S. 83] findet sich dazu auch die Darstellung auf Datenebene.

inverse Beziehungen

254

7 Objektorientierte Modellierung

Dies betonen auch [Meier und Wtist 1997] und schlagen in Anlehnung an die UML vor, diese auch deutlich zu benennen, Jede Einzelne nennen sie Assoziation, sodass aus zwei Assoziationen eine Beziehung wird: „Allgemein werden Beziehungen zwischen Klassen durch je zwei Assoziationen ausgedruckt: Zu jeder Assoziation von einer Klasse Kl zu einer Klasse K2 existiert eine inverse Assoziation von K2 zu Kl. Unter einer Assoziation von einer Klasse Kl zur Klasse K2 wird die Bedeutung und Mdchtigkeit der Beziehung in diese Richtung verstanden" [Meier und Wust 1997, S. 20]. Beziehungswertigkeiten

Ahnlich wie in der ER-Modellierung konnen, in Anlehnung an die UML, folgende Wertigkeitenl24 von Beziehungen 125 festgehalten werden (fur jede Beziehung zweifach): • • • •

einfach (genau ein Objekt): konditionell einfach (kein oder ein Objekt): konditionell mehrfach (null, eines oder viele): mehrfach (eines oder viele/mindestens eines):

1 0..1 * 1..*

Weitere Konkretisierungen bezUglich der maximalen und minimalen Anzahl von Objekten konnen erfolgen, sodass z.B. folgende Angaben moglich sind: • • • • • Kann- und MussAssoziationen

flinf odermehr null bis drei genau flinf drei, vier oder acht alle naturlichen Zahlen auBer elf

5..* 0..3 5 3,4,8 1..10, 12..*

Balzert fuhrt zusatzlich die Begriffe Kann- und Muss-Assoziationen ein. Kann-Assoziationen haben als Untergrenze die Kardinalitat 0, MussAssoziationen die Kardinalitat 1 oder groBer [Balzert 1999a, S. 41f]. Wie auch das folgende Beispiel zeigt, konnen Assoziationen benannt werden. Pro Beziehung gibt es dann zwei Angaben. Im folgenden Beispiel geht es um die oben schon thematisierte Beziehung zwischen ANGESTELLTEN und PC. Hier gilt nun, dass ein Angestellter genau einen PC nutzt und ein PC mindestens einem Angestellten zugeordnet ist. Wie die Abbildung zeigt, werden in der grafischen Notation solche Beziehungen durch eine Linie zwischen den beteiligten Objektklassen ausgedruckt. Erlautemde Texte verdeutlichen die Bedeutung der Assoziationen, die Zahlen geben die Wertigkeiten an.

Oesterreich spricht hier von „Multiplizitaten einer Assoziation" [Oestereich 1998, S. 268]. '^^ [Balzert 1999a, S. 41] spricht hier von Kardinalitaten, wie im ER-Ansatz. Diese sind dort aber anders ("grober") definiert.

7.3 Statische Aspekte 11 - Objekte in Beziehung setzen

255

Ein (in der Datenbank erfasster) Angestellter benutztgenau einen PC. Angestellte

PCs

1 PersonalNr: string Name: string Vorname: string

benulzt ^ ^ 1..*

^— isl" zugeordnet

InventarNr: string 1

Ein (iir? der Datenbank erfasster) PC ist mindestens einem Angestellten zugeordnet

oo15

Abbildung 7.3-1:

1

Semantische Beziehungen zwischen Objektklassen

In der Abbildung ist auch angegeben, wie die Wertigkeiten^^^ aus der grafischen Notation heraus gelesen werden mtissen. Allgemein gilt fur binare Beziehungen zwischen zwei Objektklassen A und B: Bei B wird angegeben, wieviele Objekte von A mindestens und hochstens an der Beziehung teilhaben und auf der Seite von A, wieviele von B. Diese Angaben entsprechen damit den in den Kapiteln 3 und 4 eingeflihrten Min/Max-Angaben. Oft aber nicht immer wird die Aussagekraft einer grafischen Darstellung erhoht, wenn bei den Objektklassen einer Assoziation die Rolle angegeben wird, die die Objekte in der jeweiligen Beziehung spielen. Die Rollennamen werden dann an die Assoziationslinie auf die Seite der Objektklasse gesetzt, deren Rolle in der jeweiligen Beziehung geklart werden soil. Die folgende Abbildung zeigt ein einfaches Beispiel.

Angestellte

Rolle \ \

}

1 PersonalNr: string Name: string 1..* PC-Nutzer Vorname: string

PCs - ^

ist zugeordnet benuizt - •

DV-Ausstattung 1

/ / Rolle

oo17

Abbildung 7.3-2:

InventarNr: string 1

Rollen in Assoziationen

^^^' In der objektorientierten Diskussion wird hier tatsachlich von „Kardinalitaten" gesprochen, obwohl diese Angaben in ihrer Genauigkeit liber die Kardinalitaten der relationalen Datenbanken weit hinausgehen.

Rollen

256

7 Objektorientierte Modellierung

Mehr als zwei in Obige Beziehung ist zweistellig. Neben solchen binaren Assoziationen derBeziehung gibt es auch hoherwertigere. Man spricht dann allgemein von n-dren Assoziationen [Balzert 199a, S. 50], im Fall von dreistelligen Beziehungen von terndren Assoziationen. Ein Beispiel dafiir zeigt die folgende Abbildung. Hier wird angenommen, dass Personal Computer nicht nur Abteilungen bzw. nur Angestellten, sondem Angestellten jeweils in Abteilungen zugewiesen werden. Dann entsteht eine dreistellige Beziehung, wie sie die Abbildung andeutet. PCs InventarNr: string

Angestellte

Abteilung

PersonalNr: string 1,2 Name: string Vorname: string

Abbildung 7.3-3:

<

>

Name: string AbtLeiter: string

Temare Assoziation

Die Wertigkeiten der Beziehungen sind bei hoherwertigeren Assoziation nicht ganz einfach bestimmbar. Man muss sich dabei sehr deutlich machen, was durch die Beziehung modelliert werden soil. Hier also z.B. die Dreiecksbeziehung zwischen PC, ANGESTELLTEN und ABTEILUNGEN. Die Wertigkeiten ergeben sich durch folgende Festlegungen bzw. Feststellungen: • • • • Beziehungsklassen

Mindestens ein Angestellter, maximal zwei nutzen einen PC in einer bestimmten Abteilung. Es geht immer um genau eine Abteilung, d.h. jede Einzelbeziehung bezieht sich immer auf genau eine Abteilung. Es geht immer um genau einen PC. Die "Dreiecksbeziehung" hat zur Folge, dass durchaus ein Angestellter in verschiedenen Abteilungen PC nutzen kann.

Beziehungen zwischen Objekten bzw. Objektklassen hatten in der bisherigen Darstellung keine eigenen Attribute und Methoden, sie stellten einfach eine auf semantischen Gegebenheiten beruhende Verkntipfung von Objekten dar. Dies ist auch oft der Fall, allerdings bei weitem nicht immer, wie ja auch die alteren Datenmodellierungsansatze zeigen. Grund-

7.3 Statische Aspekte II - Objekte in BezJehung setzen

257

satzlich ware auch denkbar, dass die objektorientierte Datenmodellierung Attribute und Methoden von Beziehungen auf andere Weise modelliert, nicht durch die Prazisierung der Beziehungen. Dies scheinen auch viele Autoren in diesem Bereich zu denken, die auf die Betrachtung dieses Sachverhalts verzichten, wodurch er - da er ja nicht verschwindet - in die zu programmierenden Anwendungen verlagert wird und das heiBt, in die Systemanalyse. Dort wird dieses Strukturmerkmal diskutiert, v.a. im UML-Ansatz (vgl. beispielhaft [Balzert 1999a, S. 45], [Oestereich 1998, S. 272ff] und [Meier und Wust 1997]). Sie fiihren Assoziative Klassen (Balzert), Beziehungsklassen (Meier und Wtist), bzw. Attributierte Assoziationen oder Assoziationsklassen (Oestereich) zwischen zwei oder auch mehr Objektklassen ein: „Verfugen Beziehungen zwischen Klassen selbst tiber beschreibende Attribute oder Methoden, so muss zu diesem Zweck eine explizite Beziehungsklasse definiert werden. Eine Beziehungsklasse (association class) ist eine Klasse, die von mehr als einer Klasse abhangig ist" [Meier und Wust 1997, S. 22]. Sie prazisieren und begriinden dann wie folgt: "Typisch bei jeder Beziehungsklasse ist, dass die Beziehungsattribute weder der einen noch der anderen Klasse zugeordnet werden konnen, da solche Merkmale ein Verhaltnis zwischen mindestens zwei Klassen ausdrucken" [Meier und Wust 1997, S. 22]. Im obigen Beispiel zu Angestellten und ihren PCs konnten solche Attribute z.B. die Art des "Besitzverhaltnisses" sein: als Administrator, als Nutzer, als Gast (mit jeweils spezifischen Rechten); der Beginn und das Ende der Nutzung. Eine Methode darauf konnte z.B. das Erstellen einer Mitteilung bzw. Eintragung, Austragung oder Anderung an eine zentrale Nutzerverwaltung sein. Das folgende Beispiel zeigt ein solches Beispiel unter Nutzung der in der UML vorgeschlagenen grafischen Notation (vgl. [Meier und Wtist 1997, S. 22f] und [Balzert 1999a, S. 45 und 50]). Dabei wird die assoziative Klasse mit ihren Attributen und Methoden mittels einer gestrichelten Linie mit der zu beschreibenden Beziehung verbunden.

Verlagerung in die Anwendungsprogramme

258

7 Objektorientierte Modellierung

Angestellte

PC

PersonalNr: string Name: string 1..* Vorname: string

1 istzugeordnet

InventarNr: string 1

Besitzverhaltnia Art: string Beginn: date Ende: date eintragenO austragenO andernO

Abbildung 7.3-4:

Beziehungsklasse auf binarer Beziehung

Damit besitzt, wie [Balzert 1999a, S. 45] richtig schreibt, die Assoziation die Eigenschaften einer Klasse. Solche assoziativen Klassen sind auch ftir hoherwertige Beziehungen moglich. Die folgende Abbildung 7.3-5 zeigt eine fur die oben eingefuhrte dreistellige Beziehung zwischen PC, ANGESTELLTE und ABTEILUNGEN. In der Spezifizierung der Beziehung konnte zusatzlich zum Eintragen, Austragen und Andem noch festgehalten werden, auf welche Kombination von Abteilung und PC sich die konkrete Nutzung bezieht. In der Literatur zur UML fehlt nicht der Hinweis, dass eine solche Beziehungsklasse im Feindesign der Systemanalyse zu einer „richtigen" Klasse wird, wobei dann naturlich die Wertigkeiten der Beziehung entsprechend iibemommen werden mtissen (vgl. [Oestereich 1998, S. 274]). Abbildung 7.3-6 zeigt das obige Beispiel zu ANGESTELLTE und PC mit der Beziehungsklasse B E S I T Z V E R H A L T N I S entsprechend aufgelost. Die Wertigkeiten bestehen jetzt jeweils in Bezug auf das Besitzverhaltnis: Aus Ein Angestellter nutzt genau einen PC wird •

Ein Angestellter hat genau ein Besitzverhaltnis und

•

Ein Besitzverhaltnis bezieht sich auf einen Angestellten Aus Ein PC ist mehreren Angestellten zugeordnet wird

• •

Ein PC hat mehrere Besitzverhaltnisse und Ein Besitzverhaltnis bezieht sich auf genau einen PC.

7.3 Statische Aspekte II - Objekte in Beziehung setzen

PCs InventarNr: string

Angestellte

Abteilung

o

PersonalNr: string 1,2 Name: string Vorname: string

Name: string AbtLeiter: string

Besitzverhaltnis Art: string Beginn: date Ende: date eintragenQ austragenO andernQ ^ zuordnenQ

Abbildung 7.3-5:

Beziehungsklasse auf temarer Beziehung

Angestellte

PC

1 PersonalNr: string Name: string Vorname: string

InventarNr: string 1

1 1..*

Besitzverhaltnis hat-^

1

- ^ bezieht_ sich_auf

CO

8

Abbildung 7.3-6:

Art: string Beginn: date Ende: date

0..*

- 4 - hat

bezieht_sich_auf—•

eintragenQ austragenO andernQ

Aufgeloste Beziehungsklasse

259

260

Implementierung von Assoziationen

Wie Geppert richtig ausfuhrt, konnen die in diesem Abschnitt betrachteten semantischen Beziehungen, je nach Datenbanksystem, auf verschiedene Weise implementiert werden [Geppert 1997, S. lf\: • • •

Rekursive Assoziation

7 Objektorientierte Modellierung

wertbasiert mit Referenzen als Unterobjekte

Wertbasiert meint, dass identifizierende Attributsauspragungen eines Attributs der einen Klasse in der anderen hinterlegt werden. Im obigen PC-Beispiel wurden damit bei jeder Instanz in der Objektklasse ANGESTELLTE die Inventamummem der PCs hinterlegt, die in der Verfugungsgewalt des jeweiligen Angestellten sind. Dies entspricht dem Konzept der objektwertigen Attribute, das oben eingefuhrt wurde. Die Beziehung ist hier implizit (Geppert) und basiert weitgehend auf Attributen und ihren Auspragungen. Eine Losung mit Referenzen sieht so aus, dass es durch das System verwaltete Verweise von der einen in die andere Objektklasse gibt. Diese werden mit Hilfe der Objektidentifikatoren eingerichtet. Im Beispiel ware dann bei der Objektklasse ANGESTELLTE ein Attribut InvPC, von dem die Zeiger in die andere Objektklasse PC verweisen. Die Losung mit Unterobjekten sieht so aus, dass ein Objekt als Teil eines anderen definiert wird. Dies fuhrt zu dem Konzept der komplexen Objekte. Liegt eine Assoziation vor, an der nur eine Objektklasse beteiligt ist, spricht man von einer rekursiven Assoziation. Es geht also um eine Beziehung zwischen den Objekten einer Klasse, bei der jedes Objekt mit einem anderen Objekt in Beziehung gesetzt wird. Betrachten wir als Beispiel eine Objektklasse ANGESTELLTE mit den tiblichen Hierarchiestufen (z.B. Sachbearbeiter, Abteilungsleiter, Hauptabteilungsleiter, usw.). Hier stehen tatsachlich die Angestellten untereinander in einer Beziehung. Z.B. alle Sachbearbeiter einer Abteilung mit dem Abteilungsleiter und umgekehrt. Die folgende Abbildung zeigt die grafische Notation einer solchen rekursiven Assoziation. Angegeben sind auch Lesehinweise und die unterschiedlichen Rollen, die die Angestellten bei dieser Assoziation einnehmen.

7.3 Statische Aspekte II - Objekte in Beziehung setzen

261

Ein Sachbearbeiter hat genau einen Abteilur

Angestellte PersonalNr: string Name: string Vorname: string

Sachbearbeiter

1..*

1

AbtLeiter 1 ist_ vorgesetzt—• • ^ - ist_untergeben

Ein Abteilungsleiter hat mindestens einen ihm unterstellten Sachbearbeiter. Abbildung 7.3-7:

7.3.2

Rekursive Assoziation

Generalisierung / Spezialisierung

Das welter oben - bei den anderen Datenmodellierungsansatzen - eingefiihrte Konzept der Generalisierung/Spezialisiemng^^^ gibt es auch im objektorientierten Ansatz. Auch hier bedeutet es "Ahnlichkeit", Ahnlichkeit von Objektklassen. Ahnlich sind Objekte aus verschiedenen Objektklassen, falls sie Attribute gemeinsam haben. Im objektorientierten Datenbankdesign kommen noch die Methoden dazu. Ahnlichkeit bedeutet hier auch, dass Objekte teilweise ein „gleiches Verhalten" haben, bzw. dass auf sie dieselben Methoden anwendbar sind. Eine andere Sichtweise betont den Vorgang der Unterscheidung von Objekten, der hier vorliegt. Die Unterscheidung in „uber-„ und „untergeordnete" Objekte und dann - genauso wichtig - die Unterscheidung der untergeordneten voneinander. Oestereich schreibt hier vom Diskriminator, der im Rahmen des Modellierungsvorgangs gewahlt werden muss [Oestereich 1998, S. 261f| und meint damit das Kriterium, nach dem die Objekte unterschieden und die Objektklassen gebildet wurde. Im unten folgenden Beispiel zu datenverwaltenden Systemen ware dies z.B. die Speichertechnik (in eine Datei, in verknupfte Dateien, in invertierte Listen). Dabei kann eine Spezialisierungshierarchie durchaus mehrere Diskriminatoren berticksichtigen und diese konnen in der grafischen Notation angegeben werden (vgl. unten). Das Konzept der Generalisierung/Spezialisierung geht auf [Smith und Smith 1977a,b] zuruck.

Objektorientierte Ahnlichkeit

Diskriminatoren

262

Baumstruktur

1st einBeziehung Grafische Notation

7 Objektorientierte Modellierung

Die Generalisierung/Spezialisierung fuhrt zu einer Baumstruktur mit liber- und untergeordneten Klassen. Eine untergeordnete Klasse {Subklasse wird als eine Spezialisierung einer iibergeordneten Klasse {Superklasse) (evtl. auch mehrerer, vgl. unten) defmiert. An der Spitze der so entstehenden Baumstruktur ist die Wurzel (root), sozusagen die allgemeinste Objektklasse des Datenmodells, z.B. „Objekte an sich". Die Wurzel ist Superklasse fur alle anderen, die jeweils unterste Ebene der Objektklassen hat nur die Eigenschaft Subklasse zu sein, alle Objektklassen dazwischen sind gleichzeitig Super- und Subklassen. Ein solcher "Baum" wird als Klassenhierarchie bezeichnet^^^. Stellen wir uns die Baumstruktur so vor, dass die Wurzel oben angeordnet ist und nach unten jeweils die Verzweigungen, dann liegen von oben nach unten Spezialisierungen und von oben nach unten Generalisierungen vor. Die Beziehungen zwischen den einzelnen Klassen entsprechen, von "oben nach unten", einer „Ist_ein - Beziehung" („is_a"). In der UML wird fur die grafische Darstellung einer Generalisierung/Spezialisierung von jeder Subklasse zur Superklasse eine Linie mit einem groBen nicht ausgefiillten Pfeil gefuhrt. Die Pfeillinien eines Diskriminators konnen auch zusammen in eine Pfeilspitze gefuhrt werden. Die Diskriminatoren konnen in der grafischen Notation angegeben werden, entweder bei jedem Pfeil oder fur mehrere Pfeile durch eine gestrichelte Linie, die diese Pfeile verbindet. Alle diese Varianten sind im folgenden Beispiel dargestellt. Die Objektklasse PERSONEN wurde zum einen nach der Art des Arbeitsverhaltnisses (Diskriminator) in ARBEITER, ANGESTELLTE und BEAMTE unterteilt. Zum anderen nach nach der Rolle im Lehrbetrieb in PROFESSOREN und STUDIERENDE und nach dem Diskriminator Umfang der Beschdftigung in V O L L Z E I T B E S C H A F T I G T E und TEILZEITBESCHAFTIGTE.

FUr tiberlappende Klassen schlagen [Meier und Wiist 1997] vor, die Schnittmenge als eigene Klasse zu verarbeiten (S. 28). Insgesamt konnen folgende Subklassenvarianten unterschieden werden [Meier und Wust 1997, S. 30]: • • • •

"disjunkte und vollstandige Uberdeckung einer Menge durch ihre Spezialisierungsmengen" "unvollstandige, gegenseitig disjunkte Uberdeckung. "uberlappende und vollstandige Uberdeckung" "unvollstandige und uberlappende Uberdeckung"

^^^ Ganz korrekt und in der Begrifflichkeit der Graphentheorie formuliert, handelt es sich um einen azyklischen, gerichteten, nicht unbedingt zusammenhangenden Graphen mit den Klassen als Knoten und der Ist_ein-Beziehung als Kanten [Geppert 1997, S. 10].

7.3 Statische Aspekte II - Objekte in Beziehung setzen

263

Fiir vollstandige Uberdeckungen wird das Konzept der abstrakten Klasse benotigt. Dies ist definiert als eine "kunstlich eingefuhrte Klasse, die keine Instanzen enthalt" [Meier und Wust 1997, S. 30].

Arbeiter

Angestellte

Umfang'

Beamte

Vollzeit- 1 1 Teilzeit- 1 beschaftige beschaftigte

Abbildung 7.3-8:

7.3.3

Generalisierung / Spezialisierung in einer Klassenhierarchie

Vererbung

Mit Hilfe der Baumstruktur, die eine Generalisierung / Spezialisierung darstellt, kann nun ein zentrales Element des objektorientierten Ansatzes eingefuhrt werden, die Vererbung. Betrachten wir zur Erlauterung die folgende Abbildung. Sie stellt eine Generalisierungs-ZSpezialisierungshierarchie dar. Stellen wir uns wie im Beispiel oben vor (und wie, bis auf die Methoden, in Abschnitt 4.6), dass jede iibergeordnete Klasse die Attribute und Methoden enthalt, die alle jeweils untergeordneten gemeinsam haben. Im Beispiel der folgenden Abbildung:

264

• •

•

7 Objektohentierte Modellierung

Die oberste Klasse enthalt alle Attribute und Methoden, die die Subklassen 1, 2 und 3 gemeinsam haben. Subklasse 3 ist gleichzeitig Superklasse fur die Subklassen 3/1 und 3/2 und enthalt somit die Attribute und Methoden, die diese beiden gemeinsam haben. Subklasse 3/1/1 wiederum enthalt eine Teilmenge von Subklasse 3/1 mit Objekten, die spezifische Attribute und Methoden haben (solche, die nicht alle Objekte der Subklasse 3/1 haben).

Fiir den Einsatz dieses Konzepts in Systemen und Datenbanken gilt nun, dass in der jeweiligen Subklasse auch die Attribute und Methoden der Superklasse verfugbar sind. Das jeweilige System^^^ nimmt sie, wenn ihm die Generalisierungshierachie und der Vererbungsvorgang bekannt sind, einfach von der jeweiligen Superklasse. Von diesem Vorgang rlihrt der Begriff Vererbung (inheritance). Die Subklasse erbt sozusagen die Attribute und Methoden der Superklasse. Das ganze ist eine Technik, um defmierende Informationen sparsam zu verwalten. Bei den Subklassen mlissen nur die Methoden, Attribute und Nachrichten verwaltet werden, die bei diesen zusatzlich dazukommen. Umgekehrt wird durch diese Vorgehensweise natiirlich auch die Klassenhierarchie und die I S A - Beziehung geklart. An der Spitze der Hierarchic steht die allgemeinste Klasse, mit Attributen und Methoden, die alle Klassen gemeinsam haben. Die erste Ebene der Subklassen erganzt diese dann um ihre jeweiligen spezifischen Attribute, usw. Aus obigem folgt bereits, dass natiirlich Superklassen auch Subklassen einer tibergeordneten Superklasse sein konnen.

'^'^ Z.B. der Compiler der objektorientierten Programmiersprache, der dies im Programm so anlegt, oder das objektorientierte Datenbanksystem.

7.3 Statische Aspekte II - Objekte in Beziehung setzen

265

Oberste Klasse (Superklasse / Wurzel / root) Vererbung: Subklasse 2 hat alle Attribute und Methoden der Superklasse

Vererbung Vererbung

/

i

Subklasse 1

Subklasse 3

\

Subklasse 2

und Superklasse fur die nachfolgenden Subklassen

Vererbung

I

Subklasse 3/1 und Superklasse fur die nachfolgende Subklasse oo23

Vererbung

I

Subklasse 3/2

I

Vererbung

\ Subklasse 3/1/1 Abbildung 7.3-9:

Vererbung entlang einer Generalisierungshierarchie

Das folgende Beispiel moge das Konzept der Vererbung etwas veranschaulichen. Angenommen, es sollen Fahrzeuge unterschiedlichster Art erfasst werden. Dann benotigt man fiir jeden Fahrzeugtyp eine Klassendefinition, weil jeder Fahrzeugtyp durch jeweils (teilweise) unterschiedliche Attribute und Methoden beschrieben wird. Auf diesen Klassendefmitionen kann eine Generalisierungshierarchie angelegt werden, da sie ja alle auch Attribute und Methoden gemeinsam haben. An der Spitze dieser Hierarchic soil eine Klasse FAHRZEUGE (im Sinne von "Fahrzeuge aller Art") stehen. Die Attribute und Methoden, die auf den Fahrzeugen insgesamt und auf den einzelnen Spezialisierungen (PKW, LKW, Busse, Kettenfahrzeuge, Zweirader, usw.) definiert sind, werden nun so angeordnet, dass die Klasse der Fahrzeuge alle Attribute und Methoden erhalt, die fur alle

Beispiel: Fahrzeuge

266

Attribute neu definieren

7 Objektorientierte Modellierung

Fahrzeuge gleich sind. Die Spezialisierungen erhalten dann nur die Attribute und Methoden, die fiir die jeweilige Klasse spezifisch sind. Durch die Angabe der Vererbung (inherit) wird dann festgelegt, dass die Subklasse von ihrer Superklasse die Attribute und Methoden „erbt", was nichts anderes heiBt, als dass die Attribute und Methoden der Superklasse ebenfalls zur Verfugung stehen. Im textlichen Beispiel unten sind eine Klasse FAHRZEUGE und eine Klasse PKW angegeben. Durch die Angabe „inherit" erhalt die Klasse PKW zusatzlich die Attribute und Methoden der Klasse FAHRZEUGE. Es ist auch moglich, ein Attribut in einer Subklasse neu zu definieren, wie es hier mit Kraftstofftyp geschehen ist (unter der Annahme, dass PKW nur verbleiten oder unverbleiten Kraflstoff tanken). CLASS Fahrzeug PROPERTIES Kennzeichen, Fabrikat, Modell: String; Farbe: FarbenTyp; Kilometerstand: Integer: Kraftstofftyp: (verbleit, unverbleit, Diesel); Erstzulassung: Integer; OPERATIONS Neues_Fahrzeug (...) Wert (...) Fahren (...) Verkaufen (...) END Fahrzeug CLASS Auto INHERIT Fahrzeug PROPERTIES Kraftstofftyp: (verbleit, unverbleit); [neu definiert] [zusatzliche Eigenschaften von Autos] Groiie. (kompakt, mittel, groB) Extras. Menge(OptionsTyp): END Auto

Ausnahmen

Unter Umstanden muss hier auch die Situation der „Ausnahmen" berUcksichtigt werden, dass - z.B. beziiglich einer Methode - bestimmte Objekte einer Objektklasse eine Methode nicht ohne Modifikation „erben" konnen. Denken wir nur z.B. an die Objektklasse VOGEL. Deren Instanzen haben sicherlich alle die Eigenschaft „kann fliegen", bis auf einige Ausnahmen. Solche Ausnahmen konnen erfasst werden, indem fur die Ausnahmeobjekte die „geerbten" Methoden und Attribute iiberschrieben werden konnen. Vererbung uber einen weniger einfachen Abstraktionsmechanismus (z.B. eine Partof - Beziehung) ist meist nicht sinnvoU und falls benotigt schwieriger zu realisieren (vgl. [Buchmann, Carrera und VazquezGalindo 1986, S. 38] fur ein Beispiel). Die oben diskutierte Vererbung basiert u.a. auf einer Weitergabe der Attribute und nicht der Auspragungen. Es sind aber auch Situationen denkbar, wo die Werte dieser Attribute von einem Objekt zum anderen

7.3 Statische Aspekte II - Objekte in Beziehung setzen

267

iibertragen werden. Dies wird „instance inheritance relationships" oder auch „value inheritance" genannt. 1st eine Klasse Subklasse mehrerer Superklassen, wird die Baumstruktur durchbrochen. Es liegt dann mehrfache Vererbung (engl. multiple inheritance) vor, die von einigen Datenbanksystemen angeboten wird:

Mehrfache Vererbung

„In certain systems, a class can have several superclasses, in which case one talks of multiple inheritance, whereas others impose the restriction of a single superclass, single inheritance" [Bertino und Martino 1993, S. 29]. In einem solchen Fall erbt also eine Subklasse die Methoden und Attribute mehrerer iibergeordneter Klassen. Wahrend die „einfache" Vererbung zwischen einer Superklasse und einer Subklasse leicht zu losen ist, bereitet die Mehrfachvererbung groBere Probleme. Hier kann es zu kollidierenden Attributen und Methoden kommen, z.B. wenn ein Attribut in zwei iibergeordneten Superklassen mit unterschiedlichen Wertebereichen auftritt. 7.3.4

Aggregation und Komposition

Bei der Aggregation geht es um Beziehungen^^^, die den Tatbestand beschreiben, dass bestimmte Objekte in anderen enthalten sind^^^ (vgl. auch Abschnitt 4.6). Diese Komponenten konnen wiederum andere Objekte enthalten, die Beziehung kann also mehrstufig sein. Zum Beispiel besteht ein PC (Personal Computer) typischerweise (u.a.) aus einer Hauptplatine, Festplatten und einem Bildschirm. Auf der Hauptplatine wiederum fmden sich (u.a.) Prozessoren, Speicherbausteine und Bussysteme (vgl. das Beispiel unten). Beliebt in der Literatur ist auch das Beispiel modemer Flugzeuge, die naturlich - vielstufig - aus zahlreichen Komponenten bestehen. Diese Komponentenstruktur liegt sehr oft vor, vor allem aber nicht nur im technischen Bereich. Meier/Wiist schlagen die Begriffe Aggregationsklasse fur die ubergeordnete und Komponentenklassen ftir die untergeordneten vor [Meier und Wiist 1997]. Eine Komponentenklasse kann wiederum fur weitere Objekte Aggregationsklasse sein. Oftmals wird diese Beziehung auch Teil_von - Beziehung (partof - Beziehung) genannt. Geppert weist darauf hin, dass bei einer solchen Teilvon - Beziehung weitere Konsistenzbedingungen (neben der des "Enthaltenseins") moglich Bei einigen Autoren, z.B. [Balzert 1999] auch als Assoziationen aufgefasst, wodurch "Assoziation" zu einem ubergeordneten Begriff flir Beziehungen aller Art wird. Bei einigen Autoren wird hiermit auch - wie oben beschrieben - der Zusammenhang zwischen Attributsnamen und Attributsauspragungen erfasst. Bei dieser Auffassung bedeutet dann der Schritt von der Menge der Auspragungen zum Attribut (als solchem) eine Aggregation. Auch die Vorgehensweise in der ER-Modellierung, mehrere Attribute zu einem entity type zusammenzufassen, kann als Aggregation interpretiert werden.

Aggregation

Beispiel

Begriffe

268

Beispielin UML-Notation

7 Objektorientierte Modellierung

sind. Z.B. kann ein Unterobjekt als teilbar definiert werden, was bedeutet, dass es Teil von mehr als einem komplexen Objekt sein kann, oder als exklusiv, wonach es nur Teil von einem komplexen Objekt^^^ sein kann. Eine Definition als unabhdngig bzw. abhdngig bedeutet, dass es auch ohne bzw. nicht ohne sein komplexes Objekt existieren kann [Geppert 1997, S. 8]. In der folgenden Abbildung ist das oben erwahnte Beispiel in der UML-Notation angegeben. Jede Verbindungslinie von einer Komponenten- zu einer Aggregationsklasse bedeutet eine Teilvon - Beziehung und wird durch eine Raute wie in der Abbildung gezeigt grafisch ausgedruckt^^^. Die Raute kennzeichnet die Aggregation. Die einzelnen Beziehungen werden auch als Assoziationen bezeichnet und konnen auch mit den oben eingefuhrten Wertigkeiten spezifiziert werden. Eine textliche Beschreibung der Assoziationen wurde beispielhaft angegeben. Sie sind alle gleich. Die Wertigkeiten legen die Beziehungen*^"^ fest: Ein PC hat genau eine Hauptplatine Eine Hauptplatine steckt in maximal einem PC Ein PC hat mindestens eine Festplatte Jede Festplatte gehort zu maximal einem PC Ein PC hat genau einen Bildschirm Ein Bildschirm gehort zu maximal einem PC Eine Hauptplatine enthalt mindestens einen, maximal vier Prozessoren. Jeder Prozessor gehort zu maximal einer Hauptplatine Eine Hauptplatine enthalt mindestens einen Speicherbaustein Jeder Speicherbaustein gehort zu maximal einer Hauptplatine^^^ Eine Hauptplatine enthalt mindestens ein, maximal drei Bussysteme Jedes Bussystem gehort zu einer Hauptplatine

Vererbung?

Bei der Aggregation gibt es keine Vererbung wie bei der Generalisierung/Spezialisierung, da die Subklassen von den Superklassen grundsatzlich verschieden sind. Naturlich existiert hier eine Komponentenklasse nur, falls die Aggregationsklasse da ist. Es liegt also eine Existenzabhangigkeit zwischen den Objekten der tiber- und untergeordneten Klassen vor.

132 133

Ein Objekt, das aus anderen besteht, wird auchi komplexes Objekt genannt. Einige Autoren fassen bei einer baumartigen Anordnung der Aggregationsbeziehungen die Rauten zu jeweils einer zusammen. Dem Verfasser ist bewusst, dass hier teilweise auch andere Werte moglich sind. Hier wird deutlich, dass es nicht um Typen (von Speicherbausteien), sondern um einzelne Exemplare geht.

7.3 Statische Aspekte II - Objekte in Beziehung setzen

269

Personal Computer

M^

Abbildung 7.3-10:

Erfassung einer Komponentenstruktur durch Aggregation

Das bekannte Beispiel einer Stuckliste kann auch hier zur Veranschaulichung einer rekursiven Definition einer Objektklasse benutzt werden. Geht es um die zwei Beziehungen „Teil_von" und „Obermenge_von", kann eine Stuckliste so wie in der nachsten Abbildung grafisch dargestellt und entsprechend modelliert werden. Bis auf ein Teil (das „oberste") ist jedes „Teil_von" genau einem anderen, woraus sich die konditionell einfache Assoziation in diese Richtung ergibt. Umgekehrt kann jedes Teil „Obermenge_von" vielen anderen Teilen sein, muss aber nicht (die „untersten"), woraus sich die konditionell mehrfache Assoziation in diese Richtung ergibt (vgl. auch [Meier und Wust 1997, S. 25fl).

Rekursive Definition

270

7 Objektorientierte Modellierung

Teile

1 Obermenge_von

Abbildung 7.3-11:

Einsatz dieser Beziehungsart

Einschatzung

Shared aggregation Komposition

- ^

0..*

Stuckliste - objektorientiert: reflexive Assoziation bzw. rekursive Klasse (in Anlehnung an [Meier und Wust 1997, S. 25]

Auch dieses „enthalten sein" ist ein zentrales Strukturmerkmal unserer Welt, das demzufolge auch in Modellen dieser Welt zur Verfugung stehen sollte. Grundsatzlich ist diese Art der Modellierung aber nur dann sinnvoll, wenn alle in der Aggregationsklasse erfassten Objekte auf dieselbe Art zusammengesetzt sind. Z.B., wenn strukturell identische Produkte hergestellt werden. Deshalb taucht in der Literatur hierzu auch meist als Beispiel FLUGZEUGE auf (wobei die Autoren von gleich aufgebauten ausgehen). Dieses Modellierungskonstrukt ist nicht geeignet, wenn sich die Zusammensetzung andert, wenn es also das eine Komponentenobjekt nur bei bestimmten Objekten der Aggregationsklasse gibt. Welchen Nutzen bringt dieses Konzept, dieses Erfassen des „Enthaltenseins" fur das Datenbankdesign? Prinzipiell wird die Abfrage erleichtert, wenn dann entsprechend leistungsstarke Abfragesprachen vorliegen, denn bei der Frage nach einem Objekt konnen automatisch die Komponenten mitausgegeben werden. Ahnliches gilt fur Loschvorgdnge. Zusammen mit einem Objekt konnen (mussen aber nicht, vgl. die Ausfiihrungen zu Kompositionen unten) automatisch seine Komponenten mit geloscht werden. Auch das Einfugen neuer Objekte wird erleichtert, da das Datenbanksystem die Komponenten automatisch anfordem kann. Zwei weitere Begriffe aus dem Umfeld der Aggregation, die im Kontext der UML diskutiert werden, seien hier noch angeftihrt (vgl. [Balzert 1999,S.47ff|). Shared aggregation: bedeutet, dass ein Teilobjekt mehreren ubergeordneten Aggregatobjekten zugeordnet werden kann. Dies ist normalerweise nicht der Fall. Bei einer Komposition gilt zusatzlich zu dem, was fur Aggregationen gilt, dass jedes Objekt einer Komponentenklasse (Balzert spricht von Teilklassen) zu einem bestimmten Zeitpunkt nur Komponente eines einzigen Objekts der Aggregatklasse sein darf Es muss also bei der Aggregationsklasse eine Kardinalitat von nicht groBer als eins vorliegen (unshared aggregation, strong ownership). AuBerdem gilt, dass bei einem Loschen eines Aggregationsobjekts die entsprechenden Komponentenobjek-

7.3 Statische Aspekte II - Objekte in Beziehung setzen

271

te ebenfalls geloscht werden. Die Komponenten sind also existenzabhangig vom Ganzen^^^. Das klassische Beispiel hierfur ist die Beziehung zwischen einem Rechnungskopf und den Rechnungspositionen, das in der folgenden Abbildung angegeben ist. Rechnungskopfe

hat - •

Abbildung 7.3-12:

Rechnungspositionen

•4— geh6rt_zu 1..*

Die Beziehung zwischen Rechnungskopfen und Rechnungspositionen als Komposition

Bei Kompositionen wird die Raute eingeschwarzt, ansonsten ist die grafische Notation dieselbe wie fiir Aggregationen. Die Kardinalitat auf der Seite der Aggregation ist immer eins, sodass sie auch oft weggelassen wird. Als wesentlich fur eine Komposition wird die Existenzabhangigkeit zwischen Aggregat und Komponente gesehen, die auch dazu flihrt, dass bei einem Loschen des Aggregats alle Komponenten mitgeloscht werden (was bei einer einfachen Aggregation nicht verlangt ist). Methoden bei der Rechnung konnten hier z.B. die Bestimmung der Anzahl Positionen und die Bestimmung der Gesamtsumme sein. Zur konkreten Abgrenzung von Assoziationen, Aggregationen und Kompositionen vgl. [Balzert 1999, S. 48f]. Oestereich gibt einen Hinweis auf die Organisation der Methoden im Rahmen einer Aggregation. Hier ubemimmt die Aggregationsklasse Aufgaben stellvertretend ftir ihre Komponentenklassen. Sie enthalt z.B. Operationen, die keine unmittelbare Veranderung in der Aggregationsklasse bewirken, die aber Nachrichten an die Komponenten weiterleiten (Propagieren von Operationen) [Oestereich 1998, s. 284]. Objekte werden auch im objektorientierten Ansatz in erster Linie durch Attribute beschrieben. Attribute in der ganz iiblichen Auffassung wie oben beschrieben. Zusatzlich konnen hier allerdings die Auspragungen eines Attributs nicht nur die iiblichen einfachen Attributsauspragungen sein, sondern ganze Objekte, Mengen von Attributsauspragungen oder Mengen von Objekten. Mit den Worten von Bertino/Martino: „The values of an object's attributes can be other objects, both primitive and non-primitive ones." [Bertino und Martino 1993, S. 16] Mit den „primitive objects" sind hier Attributsauspragungen gemeint. Liegen nun aber als „Attributsauspragungen" nicht-primitive Objekte vor, spricht man von komplexen oder zusammengesetzten Objekten. Vgl. die Diskussion der Existenzabhangigkeit in den Kapiteln 4 und 5.

Methoden

Komplexe Objekte

272

7 Objektorientierte Modellierung

[Balzert 1999, S. 542] und [Meier und Wust 1997, S. 6] beschreiben komplexe Objekte als solche, „deren Attribute selbst wiederum Objekte sein konnen". Bin komplexes Objekt besteht also (u.a.) aus einfacheren Objekten, die auch Unterobjekte [Geppert 1997, S. 7] genannt werden. Das Verhaltnis von Objekten zu Unterobjekten setzt Geppert mit einer Teilvon - Beziehung bzw. Aggregation gleich. Die Verwaltung dieser komplexen Objekte durch das Datenbanksystem ist unterschiedlich. Entweder wird als „Attributsauspragung" nur der OID gespeichert oder - falls das Datenbanksystem komplexe Objekte in vollem Umfang untersttitzt - das ganze komplexe Objekt [Bertino und Martino 1993, S. 16]. 7.3.5

Kapselung und Information Hidding

Mit dem Begriff der Kapselung (encapsulation) wird im objektorientierten Ansatz die Technik benannt, Datenstrukturen (die Objekte und Beziehungen reprasentieren) und Prozeduren zur Manipulation der intemen Reprasentation der Datenstruktur logisch und softwaretechnisch zusammenzufassen^^^. Jedes Objekt enthalt und defmiert die Prozeduren (Methoden) und die Schnittstelle (das Interface) durch die es angesprochen und manipuliert werden kann (durch andere Objekte). Die Schnittstelle eines Objekts besteht aus einer Menge von Operationen, die auf das Objekt angewandt werden konnen. Somit kann der Zustand eines Objekts (the state of an object), d.h. die konkreten Auspragungen seiner Attribute, nur durch die Methoden verandert werden, die durch die entsprechenden Operationen aufgerufen werden. Damit bleibt die interne Reprasentation der Datenstruktur und der Methoden dem Nutzer verborgen. D.h. die Nutzer sehen nur die Objekte, usw., wie diese intern realisiert werden, bleibt fur sie unsichtbar. Verkapselung erlaubt somit „information hidding" und liefert einen weiteren Abstraktionsmechanismus ^^^. Die Kapselung erlaubt somit auch, dass sich z.B. die Methoden einer Klasse andem konnen, ohne dass der ubrige Bereich der Anwendung tangiert wird (falls die Schnittstelle gleich bleibt). Insofern ist der objektorientierte Ansatz „weiter weg" von den physischen Datenstrukturen und den Programmkontrollstrukturen. Er folgt damit einem Trend in der Softwareentwicklung. Er steht fiir eine bestimmte hohere Form logischer Datenunabhangigkeit (vgl. hierzu auch [Bertino und Martino 1993, S. 18]). Vielfach wird darauf hingewiesen (vgl. z.B. [Bertino und Martino 1993, S. 18], [Geppert 1997, S. 10)], dass Kapselung bei Objektorientierten Datenbanken so gut wie nie umfassend ist. Fast alle Systeme lassen Dieses Konzept geht auf das der abstrakten Datentypen zuriick. In Bezug auf Datenbanksysteme stellt dieses Konzept eine Fortsetzung der sog. logischen und physischen Datenunabhangigkeit dar.

7.4 Dynamische Aspekte - Nachrichten

273

den direkten lesenden und schreibenden Zugriff auf die Attribute zu , da viele Anfragen logische Ausdrucke darstellen, die auf den Attributen basieren. Dieser direkte Zugriff auf die Attribute bzw. deren Auspragungen widerspricht aber eigentlich dem Konzept der Kapselung. 7.3.6

Uberladen und Uberschreiben

Mit Uberladen (overloading) und uberschreiben (overriding) wird die Technik beschrieben, verschiedene Methoden mit dem Namen einer Operation zu verbinden. Das System entscheidet dann angesichts der realen Objekte, welche Operation durchgefuhrt wird. Diese Technik beruht auf dem Konzept des Polymorphismus aus der objektorientierten Programmierung, das die Moglichkeit einer Programmiereinheit beschreibt, sich zur Laufzeit des Programms auf Instanzen einer Vielzahl von Klassen zu beziehen. Im Rahmen der Uberladung kann dann z.B. das Plus-Zeichen („+") die ubliche Addition zweier ganzer Zahlen, zweier reeller Zahlen usw. bedeuten, aber auch das Zusammenfugen zweier beliebiger Zeichenketten oder das theoretisch fundierte Aneinanderftigen komplexer Information. Uberschreiben (overriding) bezieht sich auf Vererbungshierarchien. Ist der Name eines Attributs oder einer Methode in einer Klasse derselbe wie in der Superklasse, wird das Attribut oder die Methode der Superklasse nicht „geerbt", es wird sozusagen uberschrieben durch die neue Definition. (vgl. z.B. [Bertino und Martino 1993, S. 29]).

7.4

Dynamische Aspekte - Nachrichten

Die Trennung von statischen und dynamischen Aspekten ist im objektorientierten Ansatz, wie oben schon andiskutiert, teilweise aufgehoben. Hauptursache ist die direkte Verkniipfung von Daten und Methoden. Dadurch ist die Trennung von Datenmodellierung und Systemanalyse nicht mehr so deutlich zu erkennen, wie diesfrUher""'der Fall war. Konnte friiher formuliert werden, dass die Datenmodellierung das informationelle Geriist fur die mit Hilfe der Systemanalyse konzipierte Anwendung bereitstellt, ist dies heute nicht mehr moglich, weil - natiirlich - die modellierten Methoden einen Teil der Anwendung ausmachen. Deshalb gehen einige Autoren, auch wenn sie das Thema objektorientiertes Datenbankdesign haben, bei ihrer Darstellung der Modellierungstechniken recht weit in die Techniken der objektorientierten Systemanalyse (heute vor allem: der UML) hinein. Trotzdem verlassen wir hier das eigentliche Gebiet der Datenmodellierung. Dies zeigt sich auch darin, dass viele der hier diskutierten Konzepte '^'^ Zu den Vorteilen dieser Vorgehensweise vgl. [Bertino und Martino 1993, S. 191] ^^^ Damit ist die Ara vor der objektorientierten gemeint, also ER-Modellierung und relationale Modellierung in der Datenmodellierung und die nicht-objektorientierten systemanalytischen Ansatze (z.B. die Strukturierte Analyse) in der Systemanalyse.

Systemanalyse vs. Datenmodellierung

Daten(?)modellierung

274

Methoden Operationen Nachrichten

7 Objektorientierte Modellierung

von den objektorientierten Datenbanksystemen der Gegenwart nicht unterstutzt werden. Sie spielen aber insofem eine Rolle, dass sie Hinweise auf die optimierte Gestaltung des Datenmodells geben. Deshalb werden sie betrachtet, wobei bei jedem Konzept auch seine unmittelbare Tauglichkeit fur die Datenmodellierung betrachtet wird. Eine wichtige Grundlage fiir das, was die dynamischen Aspekte einer Anwendung ausmacht, ist der gegenseitige Aufruf von Methoden durch Objekte bzw. Objektklassen. Wie oben gezeigt, sind bei den Objektklassen Methoden hinterlegt^'^^ mit denen die Objekte der jeweiligen Klasse verarbeitet werden konnen. Dabei handelt es sich um Methoden, die zur Erfullung einer Teilaufgabe in der Gesamtanwendung dienen. Fur viele Aufgaben ist es aber notwendig, dass die Methoden verschiedener Objektklassen im korrekten Zusammenspiel aufgerufen werden. Dies wird so realisiert, dass Objekte der einen Objektklasse Methoden einer anderen aufrufen konnen. Modellierungstechnisch wird dies mit dem Konzept von NachrichtemQdMsxQvt, die zwischen den Objekten und Objektklassen ausgetauscht werden. Inzwischen gehort dieses Konzept auch zum festen Instrumentarium der objektorientierten Z)a/e/?modellierung. Deshalb werden im Datenmodell die Nachrichtenkanale explizit mit modelliert, d.h. es werden die fiir die Anwendung notwendigen Aufrufe von Methoden vorgedacht und im Datenmodell festgehalten^"^^. Defmiert man, wie oben geschehen, Operationen als Dienste, die von einem Objekt angefordert werden konnen, und als Methoden die Implementierungen der Operationen, dann konnen Nachrichten so defmiert werden: „Eine Nachricht uberbringt einem Objekt die Information daruber, welche Aktivitat von ihm erwartet wird und fordert es zur Ausflihrung einer Operation auf" [Oestereich 1998, S. 236] Nur unwesentlich verkurzt bei Meier/Wiist:

Meldungsverkehr

„Unter einer Nachricht (engl. message) versteht man die Aufforderung eines Objektes an ein anderes, eine bestimmte Methode auszufuhren. Die Menge aller offentlichen Meldungsnachrichten, die einer Klasse zur Verfugung stehen, wird als Protokoll bezeichnet" [Meier und Wtist 1997, S. 32]. Erhalt ein Objekt einer Klasse eine Nachricht, fuhrt es somit entweder seine eigenen Methoden aus oder es erzeugt selbst neue Nachrichten, die Methoden anderer Objektklassen aufrufen. Dies alles natiirlich im Rahmen der Erledigung einer bestimmten Aufgabe.

^^^ Dazu kommen die Methoden, die evtl. von der Superklasse bezogen („geerbt") werden konnen. ^"^^ Dies bedeutet nicht automatisch, dass es auch objektorientierte Datenbanksysteme gibt, die dieses Konzept direkt unterstutzen.

7.4 Dynamische Aspekte - Nachrichten

275

Nachrichten haben einen Namen und Parameter. Nachrichten und Methodenname mit Ein- und Ausgabeparametem werden als Signatur der Methode bezeichnet (vgl. auch oben). In der grafischen Darstellung objektorientierter Datenmodelle werden Nachrichtenkanale durch Pfeilsymbole zwischen Objektklassen kenntlich gemacht. Die Richtung der Nachricht zeigt vom sendenden zum empfangenden Objekt. Falls eine Ruckantwort erfolgen soil, wird ein entsprechender Kanal modelliert. Damit, so [Meier und Wust 1997, S. 33], werden „werden samtliche Interaktionen zwischen Objekten unterschiedlicher Klassen durch Nachrichten modelliert." Unterschieden wird dabei der Aufruf von Instanzmethoden und von Klassenmethoden. Erstere betreffen Methoden, die einzelne Instanzen verandem, z.B. eine Preisanderung beziiglich einer Instanz einer Objektklasse zu Produkten. Zweitgenannte betreffen Methoden, durch die alle Objekte einer Objektklasse angesprochen sind, z.B. die Veranderung der Mengenangabe bei Einfugen eines neuen Produkts. Der Aufruf von Methoden steht bei realen Anwendungen in der Regel oft in einem groBeren Zusammenhang, z.B. dann, wenn der Aufruf eine von vielen Operationen aus der Abarbeitung einer groBeren Aufgabe betrifft. Ganz besonders deutlich wird dies bei Echtzeitanwendungen, wie Meier/Wiist ausfiihren (Hervorhebung durch J.L. Stand): „Manchmal steht dabei die Reihenfolge der einzelnen Interaktionen (Nachrichten) im Vordergrund, manchmal das zeitliche Verhalten unter Beriicksichtigung von Wartezeiten und Ausfuhrungszeiten. Bei solchen Echtzeitanwendungen mussen bereits bei der Analyse oder beim Entwurf die zeitlichen Anforderungen miteinbezogen werden. Ereignisse werden durch Nachrichten modelliert und neben der Identifikation von einzelnen Nachrichten wird die Reihenfolge der Nachrichten auch in einer zeitlichen Abhangigkeit spezifiziert. Solches Verhalten kann mittels Zustandsiibergangsdiagrammen ... oder Nachrichtensequenzen ... modelliert werden." [Meier und Wust 1997, S. 33] Das Nachrichtenkonzept ist sehr sinnvoll, auch fur die Datenmodellierung. Es festigt nicht nur das eigentliche Datenmodell, indem es Anforderungen aus der Ausgabenerfullung klart, sondem es konnte auch von zukiinftigen objektorientierten Datenbanksystemen direkt unterstiitzt werden, was zu einer sinnvollen Verlagerung „dynamischer Aspekte" in die Datenbank hinein fuhren wtirde.

276

7 Objektorientierte Modellierung

7.5

Verhaltensmodellierung

7.5-1

Urn was geht's?

In diesem Abschnitt wird betrachtet, welche weitergehenden Konzepte die UML fiir die Verhaltensmodellierung bereitstellt. Dies geschieht auch auf dem Hintergrund des hohen Anspruches der Urheber der UML: "Note that UML can be used to model different kind of systems: software systems, hardware systems, and real world organizations. Business modeling models real-world organizations." [UML 1997a, S. 1] Unternehmensmodellierung

Fiinf Aspekte der Verhaltensmodellierung

Mit der Modellierung von „real-word organizations" ist (auch) die Modellierung von Geschaftsprozessen bzw. die Thematik enterprise modeling gemeint. Dies sind sicherlich nicht Themen, die man sofort und ohne Zogern der Da/^wmodellierung zuordnet. Bei genauerer Betrachtung wird man aber erkennen, dass die Kenntnis der Ablaufe bzw. Geschaftsprozesse, denen die Datenbank „zu dienen" hat, nattirlich auch der Datenmodellierung hilft, bzw. bei einer zeitgemaBen Datenmodellierung unbedingt beriicksichtigt werden muss. Folgende fiinf Modellelemente, die Aspekte von Prozessen und Geschaftsprozessen abdecken konnen, werden in der objektorientierten Systemanalyse, wie sie in der UML ausformuliert wurde (vgl. [OMG 1999] und die umfangreiche Literatur^"^^), thematisiert: •

•

•

•

•

Anwendungsfdlle (use cases) beschreiben das Zusammenwirken von Anwendem mit dem System und geben damit einen Uberblick zur Gesamtftinktionalitat des zu entwickelnden Systems Sequenzen (sequences) beschreiben die Interaktion von Objekten des Systems miteinander (im Rahmen einer Aufgabenerftillung) durch Nachrichtenaustausch (und damit Methodenaufruf) mit Berucksichtigung der zeitlichen Dimension. Kollaborationen (collaborations) beschreiben den Nachrichtenaustausch zwischen Objekten und damit v.a. die Kommunikationsbeziehungen eines einzelnen Objekts (ohne Berucksichtigung zeitlicher Aspekte). ZustandsUbergdnge beschreiben das interne Objektverhalten, den Lebenszyklus eines Objektes mit den verschiedenen moglichen Objektzustanden. Aktivitdten beschreiben den Kontrollfluss von Aktivitat zu Aktivitat.

^^^ Herausragend ist das Buch [Booch, Rumbaugh und Jacobson 1999]. Es ist, ohne Verlust an Tiefe, verstandlich geschrieben und auch hervorragend ubersetzt (was leider nicht selbstverstandllich ist).

7.5 Verhaltensmodellierung

7.5.2

277

Anwendungsfalle (use cases)

Anwendungsfalle^"^"^ {use cases) beschreiben das Zusammenwirken von Anwendem mit dem System. Sie gehen zuruck auf die schon frUher in der objektorientierten wie auch der traditionellen Systementwicklung behandelten Szenarien, mit deren Hilfe - eher informell - die Anforderungen an das System beschrieben wurden [Fowler und Scott 1998, S. 53]. Fiir die notige Prazisierung sorgte Jacobson, in inhaltlicher Hinsicht wie auch in der Frage der grafischen Representation (Anwendungsfalldiagramm / use case diagram). Er definierte sie als Werkzeug, um einen Uberblick Uber die Gesamtfunktionalitat des zu entwickelnden Systems zu erreichen. Sie beschreiben also das Verhalten, das von dem zu entwickelnden System erwartet wird: „Ein Anwendungsfall ist eine Menge von Aktionsfolgen, einschlieBlich ihrer Varianten, die ein System durchfahrt, um ein erkennbares nutzliches Ergebnis far einen Akteur zu erzielen." [Booch, Rumbaugh und Jacobson 1999, S. 248] Anwendungsfalle kennen somit zwei Elemente: den eigentlichen Anwendungsfall (definiert uber eine Interaktion mit dem zu entwickelnden System) und Akteure, die mit dem System umgehen, z.B. Systemnutzer. Sie erfassen damit mit anderen Worten die Beziehungen zwischen Akteuren und Anwendungsfallen im System [OMG 1999, S. 3-89]. Ein Anwendungsfall i.e.S. stellt eine Folge zusammenhangender Aufgaben (Funktionalitaten) dar:

Anwendungsfall im engeren Sinn

„A use case is a kind of classifier representing a coherent unit of functionality provided by a system, a subsystem, or a class as manifested by sequences of messages exchanged among the system and one or more outside interactors (called actors) together with actions performed by the system. [OMG 1999, S. 3-91] Die Akteure (actors) werden mithilfe der spezifischen Aufgaben, die sie im Umgang mit dem System haben (Rollen) definiert: „An actor defines a coherent set of roles that user of an entity can play when interacting with the entity. An actor may be considered to play a separate role with regard to each use case with which it communicates" [OMG 1999, S. 3-92]. Ein Akteur ist also eine "vom Anwender in Bezug auf das System eingenommene Rolle" [Fowler und Scott 1998, S. 55]. Ein Anwender kann mehr als eine Rolle einnehmen. Ein Akteur kann aber auch ein extemes System sein, das Informationen vom betrachteten System benotigt. Der Begriff geht urspriinglich auf Jacobson zuruck. Er bezeichnet damit eine Folge von Aktionen, die von einem Systemnutzer im Dialog mit dem System ausgefuhrt werden [Booch, Rumbaugh und Jacobson 1999, S. 250].

Akteure

278

7 Objektorientierte Modellierung

Anwendungsfalle konnen in Beziehung zueinander stehen. Dabei werden folgende Falle unterschieden (ebenda): • • •

Include - Beziehung Extend - Beziehung (Erweiterungen des Anwendungsfalls) Vererbungsbeziehung

Eine Include - Beziehung ([Fowler und Scott 1998, S. 59] sprechen von „uses relationship") wird verwendet, wenn ein Verhaltensanteil in verschiedenen Anwendungsfallen gleich ist. Dann wird dieser aus alien, in denen er vorkommt, ausgelagert. Damit handelt es sich um eine gerichtete Beziehung, z.B. von einem Anwendungsfall AFl zu einem Anwendungsfall AF2. Sie besagt (in diesem Beispiel), dass bei Ausfuhrung des Falls AFl der Anwendungsfall AF2 immer ebenfalls ausgefiihrt werden muss. AFl enthalt (als Aufgabe) AF2. Die Extend - Beziehung zwischen zwei Anwendungsfallen AFl und AF2 besagt, dass AFl in AF2 eingefligt werden kann, aber nicht muss. Die Beziehung ist ebenfalls gerichtet. Man benutzt sie bei Anwendungsfallen, „die einem anderen Anwendungsfall ahnlich sind, aber noch ein wenig mehr bewerkstelligen." [Fowler und Scott 1998, S. 58]. [Fowler und Scott 1998] fuhren das Beispiel eines Anwendungsfalls an, der „Handel durchftihren" beschreibt. Dieser beschreibt dann den Standardfall, bei dem alles glatt geht. Modelliert man auch Nicht-Standardsituationen (z.B. die Uberschreitung des Maximalbetrags) oder andere mogliche Abweichungen werden diese in den Erweiterungen des Anwendungsfalles festgehalten. [Fowler und Scott 1998] empfehlen, bei der Beschreibung des „normalen" Anwendungsfalls bei jedem Schritt zu iiberlegen, was schief gehen kann und diese Variationen als Erweiterungen des Anwendungsfalles zu modellieren [Fowler und Scott 1998, S. 58]. Eine Generalisierungsbeziehung zwischen einem Ubergeordneten und mehreren untergeordneten Anwendungsfallen driickt aus, dass ein untergeordneter Anwendungsfall alle Eigenschaften des Ubergeordneten erbt, einschliefilich dessen Kommunikationsbeziehungen. Vererbungsbeziehungen konnen auch zwischen Akteuren bestehen, was dann besagt, dass die Kommunikationsbeziehungen zu Anwendungsfallen, die der iibergeordnete Akteur hat, vom untergeordneten Akteur geerbt werden. Die grafische Darstellung von Anwendungsfallen (vgl. auch die folgende Abbildung) ist wie folgt: Jeder Anwendungsfall (use case) wird durch eine beschriftete Ellipse dargestellt, alle Anwendungsfalle werden durch ein Rechteck umrahmt, auBerhalb des Rechtecks sind Symbole flir die Akteure (Strichmannchen). Linien halten die Beziehungen zwischen Akteuren und Anwendungsfallen fest. Die Beziehungen (zwischen Anwendungsfallen) werden durch je einen gerichteten Pfeil dargestellt und durch den Begriff „include" bzw. „extend" bezeichnet. Eine Vererbungsbeziehung wird wie bei Klassendia-

7.5 Verhaltensmodellierung

279

grammen durch eine Linie, mit einem Dreieck auf der Seite der vererbenden Instanz dargestellt. Angestellte Einstellen

A

Personalabteilung

A

Rechenzentrum

Abteilungsleiter

Abbildung 7.5-1:

Ein Anwendungsfalldiagramm (einfachste Form)

Anwendungsfalldiagramme (use case diagrams) gehoren zu den ersten Diagrammen, die im Rahmen einer objektorientierten Systemanalyse erstellt werden. Sie stellen tiberblicksartig die Gesamtfunktionalitat des zu entwickelnden Systems dar und beschreiben das Zusammenwirken von Anwender und System. Sie gehen nicht auf die interne Struktur der Anwendungsfalle ein, sie beschreiben nicht die geplante Implementierung. Nach dieser Beschreibung liegt der Gedanke an Geschaftsprozesse schon nahe, v.a., wenn [Booch, Rumbaugh und Jacobson 1999, S. 249] noch betonen, dass ein Anwendungsfall ein greifbares Arbeitsergebnis liefert, dass dieses Konzept auf das ganze System anwendbar ist und eine Menge von Folgen beschreibt, „... in der jede Folge eine Interaktion von etwas aufierhalb des Systems (seinen Akteuren) mit dem System selbst ... ist" [Booch, Rumbaugh und Jacobson 1999, S. 248]. Es Uberrascht deshalb nicht, dass einige Autoren den Begriff use case mit Geschaftsprozess gleichsetzen ([Balzert 2001, S. 126ff], [Balzert 1999, S. 63], [Meier und Wtist 1997, S. 42]). Fur Meier und Wust sind die Begriffe Anwendungsfall (sie sprechen von Anwenderftinktion) und Geschaftsprozess synonym. Den Gesamtzusammenhang sehen sie so, dass der Gesamtumfang der Anwendung durch die Systemziele und Systemgrenzen

Aufgabe im Design

Geschaftsprozesse?

280

7 Objektorientierte Modellierung

festgelegt ist und die Geschaftsprozesse oder Anwenderfunktionen zur Erfiillung der Systemziele dienen. Hinzu kommt, dass eine detailliertere (i.d.R. textliche) Beschreibung der Anwendungsfalle tatsachlich gefordert wird. Unter der Uberschrift „vom Groben zum Detail" beschreiben z.B. Meier und Wtist den Einsatz von Anwenderfunktionen durch Geschdftsprozesskarten ([Meier und Wiist 1997, S. 4If]). Dabei Wwdjeder spezifische Anwendungsfall durch Geschdftsprozesskarten erfasst, d.h. textlich beschrieben. Trotzdem kann der Gleichsetzung von Geschaflsprozessen und Anwendungsfallen nicht zugestimmt werden. Anwendungsfalle beschreiben nur einige wenige (wenn auch wichtige) Aspekte von Geschaflsprozessen. Es fehlt vor allem das, was in den Ereignisgesteuerten Prozessketten der Kontrollfluss erfasst: das gezielte Miteinander der einzelnen Funktionen eines Geschaftsprozesses. Anwendungsfalle sind ganz und gar auf das ausgerichtet, was ja auch ihr Name andeutet: die Interaktion der Nutzer mit dem System. So sehen dies auch [Booch, Rumbaugh und Jacobson 1999, S. 247], wenn sie darauf hinweisen, dass Anwendungsfalle die Kommunikation zwischen Entwicklern und spateren Anwendem des Systems ermoglichen. Trotz dieser Einschrankung (mangelnde Tauglichkeit fiir die Geschaftsprozessbeschreibung) sind Anwendungsfalle flir die Datenmodellierung wichtig. Sie klaren die Anforderungen an das System und damit die Anforderungen an die Datenbank, die dem System dient. 7.5.3

Sequenzen

Sequenzen modellieren das dynamische Verhalten des Systems. Konkret wird durch sie erfasst, wie die Objekte des Systems miteinander agieren und Nachrichten untereinander austauschen. Dabei geht es um Nachrichten, die im Rahmen einer bestimmten Aufgabenerfullung notwendig sind. Eine Folge solcher versendeten Nachrichten wird Interaktion genannt: „The sequences of Stimuli exchanged among Objects to accomplish a specific purpose is called an Interaction." [OMG 1999, S. 3-110] Das besondere an Sequenzen ist, dass die zeitliche Reihenfolge der Nachrichten hervorgehoben wird. In den zugehorigen Sequenzdiagrammen (vgl. die folgende Abbildung) werden die Objekte, die Nachrichten austauschen, als Rechtecke horizontal nebeneinander gestellt. Das Objekt, das die Interaktion initiiert, wird dabei i.d.R. ganz links angeordnet. Unterhalb eines jeden Objekts ist eine gestrichelte Linie, die Lebenslinie (lifeline), die die Existenz eines Objekts wahrend eines Zeitraums darstellt. Typischerweise fiir die gesamte Interaktion, dann uber die gesamte Lange, sonst nur in Teilen.

7.5 Verhaltensmodellierung

281

Eine Saule uber der Lebenslinie gibt den Zeitraum an, in dem ein Objekt eine Aktion ausfiihrt, entweder direkt oder durch ein nachgeordnetes Objekt. Dies wird Kontrollfokus genannt [Booch, Rumbaugh und Jacobson 1999, S. 280]. Zwischen diesen Saulen geben Pfeillinien die versendeten Nachrichten an. Diese sind, von oben nach unten, in einer zeitlichen Reihenfolge (vgl. die folgende Abbildung) sortiert. Die vertikale Achse stellt somit eine Zeitachse dar, wahrend in der horizontalen die Objekte angeordnet sind. Insgesamt beschreibt die OMG Sequenzdiagramme wie folgt: „A sequence diagram shows an interaction arranged in time sequence. In particular, it shows the instances participating in the interaction by their „lifelines" and the stimuli they exchange arranged in time sequence. It does not show the associations among the objects." [OMG 1999, S. 3-97] Das folgende einfache Beispiel beschreibt sehr grob einen Bestellvorgang. Ein Kunde bestellt ein Produkt mit der Methode bestellenProdukt. Danach wird vom Lieferanten der Lagerbestand abgefragt und eine Reservierung vorgenommen. AnschlieBend wird eine Auftragsbestatigung verschickt. Anaestellter

Lager

Lieferant

sd2

bestelh9nF^rodukt

1 1

1

abfragenBestand

^ bestatJgenAuftrag

^ reservierenProdukt \ 1

!

1 1

Abbildung 1.5-2:

Eiii S equenzdi
(einfachste Form)

Selbst diese kurzen Ausfuhrungen und das einfache Beispiel diirften deutlich machen, dass hier Ablaufe (also „dynamische Aspekte") beschrieben werden. Diese Beschreibung von Geschaftsprozessfragmenten kann, genauso wie oben bei den Anwendungsfallen beschrieben, bei der Datenmodellierung hilfi-eich sein. 7.5.4

Kollaborationen

Mit dem Konzept der Kollaboration und den zugehorigen Kollaborationsdiagrammen (collaboration diagrams) wird

282

7 Objektorientierte Modellierung

"... das Modellieren der strukturellen Beziehungen, die zwischen Objekten in einer Interaktion bestehen konnen..." [Booch, Rumbaugh und Jacobson 1999, S. 243] Nachrichtenaustausch bei Aufgabenerflillung

ermoglicht. Ein Kollaborationsdiagramm beschreibt damit den Nachrichtenaustausch zwischen Objekten im Rahmen einer bestimmten Aufgabenerfullung. Im Vergleich zu Sequenzdiagrammen, die besonders gut geeignet sind, die Nachrichten innerhalb komplexer Systeme zu tiberblicken, erlauben Kollaborationsdiagramme besser, die Kommunikationsbeziehungen eines einzelnen Objekts zu beschreiben [OMG 1999, S. 3-97]. Damit sind Kollaborationsdiagramme auf einen ganz bestimmten Aspekt von Systemen - das Objektverhalten - konzentriert: "Behavior is implemented by sets of objects that exchange stimuli within an overall interaction to accomplish a purpose. To understand the mechanisms used in a design, it is important to see only those objects and their interaction involved in accomplishing a purpose or a related set of purposes, projected from the larger system of which they are part for other purposes. Such a static construct is called a Collaborationr [OMG 1999, S. 3-109] Ein Kollaborationsdiagramm ist ein Graph, dessen Knoten die Objekte darstellen, die an einer bestimmten Interaktion beteiligt sind. Die Objektbeziehungen stellen die Kanten dar. Den Objektbeziehungen werden dann die Nachrichten zugeordnet, die die Objekte senden und empfangen. Dadurch dass diese Nachrichten mithilfe der Dezimalklassifikation strukturiert sind, geben sie den Kontrollfluss bezUglich der jeweiligen Interaktion an. Booch, Rumbaugh und Jacobson weisen auf die Motive fur die beiden Visualisierungen hin. Sequenzdiagramme betonen die zeitliche Reihenfolge der Nachrichten, wahrend Kollaborationsdiagramme die strukturelle Organisation der Nachrichten sendenden Objekte in den Vordergrund stellen [Booch, Rumbaugh und Jacobson 1999, S. 243]. Ansonsten betonen sie aber die semantische Aquivalenz der beiden Konzepte. Bei den Kollaborationsdiagrammen wird besonders deutlich, wie sehr die UML bei der Modellierung dynamischer Aspekte vom Nachrichtenverkehr zwischen den Objekten abhangig ist. Hinweise flir die Datenmodellierung durften sich aus Kollaborationsdiagrammen nur wenige gewinnen lassen. Auch die Eignung far die Geschaftsprozessmodellierung und damit zumindest indirekt fiir die Datenmodellierung ist nur gering, da bis auf die Einbeziehung der Objektstruktur ansonsten dieselben Defizite beziiglich einer umfassenden Geschaftsprozessmodellierung vorliegen wie bei den Sequenzen.

Hinweis

Kollaborationsdiagramme und Sequenzdiagramme machen zusammen die Interaktionsdiagramme (interaction diagrams) aus. Dies fuhrt bei einigen Autoren zu Verwechslungen.

7.5 VerhaltensmodellJerung

7.5.5

283

ZustandsiJbergange

Bei Zustandstibergangen geht es nun nicht um die Interaktionen zwischen Objekten, sondem um das interne Objektverhalten. Zustandsiibergange erfassen den Lebenszyklus eines Objekts mit den verschiedenen moglichen Objektzustanden und den Zustandstibergangen. Der Lebenszyklus eines Objekts besteht aus Zustanden, in denen Objekte eine bestimmte Zeit verharren und auf Ereignisse warten. Von einem Zustand aus sind verschiedene Zustandsubergange moglich, die Transitionen genannt werden. Ausgelost wird die Zustandsanderung durch ein Ereignis, das zu einem bestimmten Zeitpunkt eintritt und selbst keine Zeit in Anspruch nimmt. Welche Zustandsanderung eintritt, hangt von dem Ereignis und dem Objektzustand zum Zeitpunkt des Ereignisses ab. „Sie beschreiben alle moglichen Zustande, die ein bestimmtes Objekt annehmen kann, und wie sich sein Zustand als Ergebnis von das Objekt erreichenden Ereignissen verandert." [Fowler und Scott 1998, S. 123] Meist werden Zustandsdiagramme fiir eine einzelne Klasse entworfen, um das Verhalten wahrend der Lebenszeit eines einzelnen Objektes aufzuzeigen [Fowler und Scott 1998, S. 123]. Zustandsubergangsdiagramme (statechart diagrams) bestehen aus folgenden Elementen: • • • •

einem Startzustand Zustanden Zustandsanderungen einem Endzustand

Die Zustande (graphisch dargestellt als Rechtecke mit abgerundeten Ecken) sind durch Pfeillinien (sie reprasentieren die Transitionen) verbunden, die vom Ausgangs- zum Endzustand fiihren. Die dadurch entstehende Folge von Zustanden sind die Zustandsiibergange. Die grafischen Rechtecksymbole fiir Zustande sind durch eine Linie unterteilt. Im oberen steht der Name des Zustandes, im unteren konnen Aktionen stehen, die mit Zustanden verbunden sind. Die Pfeile fiir die Transitionen sind beschriftet mit: • • •

dem auslosenden Ereignis, einer Bedingung (in eckigen Klammem), einer Aktion, die im Zuge der Transition auszufuhren ist, z.B. Anfrage eingetroffen [Produkt lieferbar]/liefem

Das Zustandsubergangsdiagramm beginnt mit einem Startsymbol und endet mit dem Endesymbol (vgl. die nachste Abbildung). Das folgende Beispiel soil die Grundzuge verdeutHchen. Es geht um eine (vereinfachte) Kundenanfrage. Der Kunde fragt an, ob ein bestimm-

284

7 Objektorientierte ModeHierung

tes Produkt geliefert werden kann. Sobald ein Sachbearbeiter diese Anfrage bearbeitet und die grundsatzliche Machbarkeit bejaht, wird sie existent und ihr Zustand auf „in Arbeit" verandert. Nun wird nacheinander zuerst die Produktionskapazitat und der Materialbestand gepruft, was den Zustand der Anfrage jeweils verandert. Die letztere Priifung setzt auBerdem den Zustand auf „erledigt". Die Beantwortung der Anfrage beendet dann den Prufvorgang. Start •^

zu eriedigen

1

Anfrage eingetroffen [Machbarkeit bejaht]/ bearbeiten in Arbeit Produktionskapazitat prufen[bejaht]/l\/laterial prufen Prod.KapazitaF^ gepruft ^

C

IVIaterialbestand prufen [ausreichend]/ beantworten Bearbeitung fertig JT Material ^ Anfrage ^ / ^ ll^gepruft; ErledigtJ K * ) ^nde Abbildung 7.5-3:

Ein Zustandstibergangsdiagramm (einfachste Form)

Zustandsiibergange beschreiben damit wichtige Aspekte des Systemverhaltens. [Meier und Wiist 1997, S. 33f] heben deshalb bei der Definition und Beschreibung von Zustandstibergangsdiagrammen auch gleich auf Systeme ab: „Ein Zustandstibergangsdiagramm (engl. state transition diagram) zeigt die Ablauffolge der Zustande, die ein System vom Startzustand zum Endzustand einnehmen kann. Zustandsanderungen werden durch Ereignisse (oder Nachrichten) ausgelost. Zustandstibergangsdiagramme konnen auf unterschiedlichen Abstraktionsebenen eingesetzt werden, z.B. auf der Systemebene, fur einen bestimmten Anwendungsbereich oder sogar fiir das Verhalten einzelner Objekte" [Meier und Wust 1997, S. 33f| Damit sind Zustandsubergange fur die Datenmodellierung von groBem Interesse. Sie geben Hinweise darauf, welche Veranderungen die Daten, durch die die Klasse reprasentiert wird, zu erwarten haben.

7.5 Verhaltensmodellierung

285

Auch bzgl. der Geschaftsprozessmodellierung hat dieses Konzept Bedeutung. Es kann am besten mit dem dort tiblichen Konzept der Geschaftsobjekte verglichen werden: ZustandsUbergangsdiagramme beschreiben die Veranderung von Geschaftsobjekten im Laufe ihrer Bearbeitung. Ftir eine umfassende Modellierung von Geschaftsprozessen eignen sie sich aber nicht. 7.5.6

Aktivitatsfolgen

Nur kurz soil noch ein Blick auf das Konzept der Aktivitdten geworfen werden: „Eine Aktivitat ist ein andauernder, nichtatomarer Ablauf in einem Automaten. Eine Aktivitat fuhrt letztendlich zu einer Aktion, die aus ausfUhrbaren, atomaren Berechnungen besteht, die eine Zustandsanderung des Systems bewirkt oder einen Wert zuruckliefert." [Booch, Rumbaugh und Jacobson 1999, S. 291]. Nicht so sehr in dieser Definition, aber in den Beispielen (vgl. insbesondere Abbildung 19-1 auf Seite 293 in [Booch, Rumbaugh und Jacobson 1999]) zeigen Aktivitaten eine deutliche Ahnlichkeit mit dem, was bei Ereignisgesteuerten Prozessketten als Funktionen bezeichnet wird. In den zugehorigen Aktivitatsdiagrammen werden die Akivitatszustande und Aktionszustande, die Zustandstibergange und die Objekte in ihrem Zusammenhang dargestellt. Die folgende Abbildung zeigt ein Beispiel. Es geht um die Bearbeitung einer Anfrage mit den Ausgangen „Machbarkeit bejaht" und „Machbarkeit vemeint". Danach werden zwei Aktivitaten angeworfen (vgl. den UND-Operator in Ereignisgesteuerten Prozessketten), nach deren Erledigung die Zusage an den Kunden erfolgt. Im Falle einer Vemeinung wird dem Kunden abgesagt.

286

7 Objektorientierte Modellierung

[Machbarkeit

bearbeiten \ vemeint] Anfrage

}

[Machbarkeit bejaht]

(

sT^

Kapazitat prufen

( I

\ j

I

Material prufen

3 f

Kunde \ zusagen J

I

Kunde zusagen

^

(fy Abbildung 7.5-4: Anmerkung

Dieser Abschnitt beschreibt, dam Zweck des Buches entsprechend, nur die Grundstrukturen dieser Konzepte zur Beschreibung dynamischer Aspekte. Fur eine vertiefte Darstellung vgl. die umfangreiche Literatur, insbesondere [Booch, Rumbaugh und Jacobson 1999], [Oestereich 1999], [Balzert 1999].

7.6

Eignung fiir Datenmodellierung

Bin Aktivitatsdiagramm (einfachste Form)

Einschatzung

Die UML ist in erster Linie fur das Softwareengineering entwickelt worden, auch wenn der Anspruch heute ein umfassenderer ist (vgl. das Zitat am Beginn des Abschnitts 7.5). Da zum Softwareengineering bzw. fiir die dabei notwendige Systemanalyse Datenmodelle und Datenbankdesign unabdingbar sind, ist die Eignung hierfiir auch voll gegeben. Insbesondere die in den Abschnitten 7.1 - 7.4 beschriebenen Techniken und Konzepte eignen sich hervorragend fur die Erstellung von Datenmodellen. Die Konzepte von Abschnitt 7.5 erganzen dies, indem sie weitere Hinweise darauf geben, was mit den Daten geschieht. Um Betrachtungen dieser Art kommt emsthafte Datenmodellierung nicht herum.

7.6 Einschatzung

287

Sie wird sogar noch mehr tun, sie wird den ganzen Geschaftsprozess, dem die Datenbank zu dienen hat, mitberucksichtigen. Hier versagen allerdings die Mittel der UML. Sie beschreiben nicht Geschaftsprozesse in einem umfassenden Sinn, wie z.B. Ereignisgesteuerte Prozessketten (vgl. [Stand 2001]), sondem nur einzelne Aspekte, letztendlich nur Systemverhalten. Dies hat eine tief im objektorientierten Ansatz liegende Ursache. Objekte mit ihren Klassen konnen zusammenwirken, z.B. durch den Austausch von Nachrichten (wie oben gezeigt), und man kann damit auch zielgerichtetes Handeln im Kleinen (im System) modellieren. Es fehlt aber die Ubergeordnete Ebene, die „steuernde Hand" des Kontrollflusses. Daftir gibt es kein im Kern des objektorientierten Ansatzes integriertes Konzept und die oben beschriebenen, dem objektorientierten Ansatz zum Teil aufgepfi"opften Konzepte zur Beschreibung dynamischer Aspekte liefem jeweils nur Teilergebnisse. Es kann somit ohne Einschrankung Oestereich zugestimmt werden, der in Bezug auf die Geschaftsprozessmodellierung ausfuhrt: „Dennoch erreichen die verfiigbaren UML-Mittel noch nicht die Ausdrucksstarke und Universalitat wie etwa ereignisgesteuerte Prozessketten und Werkzeuge wie ARIS-Toolset." [Oestereich 1999, S. 79]

Keine Eignung fur Geschaftsprozessmodellierung

8

INDEX

1:1- Beziehung ER 131 relational 26 1:1 - Beziehung in SAP-SERM 208 1:C - Beziehung in SAP-SERM 208 1 :CM - Beziehung in SAPSERM 208 1:M - Beziehung in SAP-SERM 208 1 :n - Beziehung BeispielER 132 ER 131, 132 1 :n - Beziehungen Definition (relational) 29 INF Bedeutung 58 2NF Definition 70 Faustregel 75 3NF Definition 84 4NF Definition 104 5NF Definition 111 Abhangigkeiten zwischen Attributen 103 Abhangigkeiten zwischen den Attributen einer Relation Zusammenfassung 103 abstrakte Datentypen 246 abstrakte Klasse 263 Aggregation 151 Aggregationsklasse 267 Aggregierender Beziehungstyp

SAP-SERM 210 Ahnlichkeit von Entitatstypen 213 aktives Data Dictionary 226 Aktualisierungsanomalie 57 Aktualisierungs-Anomalie Beispiel 82,94,97 Alles nur Objekte? 251 Anomalien Beispiel 76 Beispiele mit BCNF 93 Anomalien in Relationen 56 Anwendungsfalle 277 Assoziation 252 n-are 256 rekursive 260 temare 256 Attributbasierte Datenbankansatze 2 Attribute Beispiele 7 Definition 117 ER 133 objektwertige 252 Attributsauspragungen 9 Beispiele 7 Attributsnamen 9 Ausgehende Beziehungen....208 Auspragungen von Attributen Beispiele 7 BCNF 92,94 Definition 94 Benennungen Definition 9 Beziehungen 130 ER 170 in SAP-SERM 207

290

Index

Beziehungsklasse (in objektorientierter 257 Datenmodellierung) Beziehungsklassen 47 Beziehungstyp 133 inSAP-SEPlM 207 Beziehungstypen 130 Darstellung SAP-SERM 209 Binary Large Objects 11, 44 body 249 Boyce/Codd-Normalform Definition 94 Buchungskreis 224 Definition business objects 21 classification 245 Data Dictionary 226 aktives 226 integriertes 226 Data Modeler 208 Datenbankobjekte vs Realweltobjekte 234 Datenmodell 18 Datentypen 11 Definition Attribute 117 Buchungskreis 224 Entitatstyp 207 Mandant 224 Relation 118 Deskriptive Attribute 134 Determinante 62 Definition Diagramm der funktionalen Abhangigkeiten 60 disjunkte Spezialisierung.... 214 domain 9, 113 Domane 9 Dynamisch vs statisch 233 echte mehrwertige Abhangigkeiten 103 Eigenschaften von Datenbanksystemen 2 Eigenschaften von Relationen23

einfache funktionale Abhangigkeit Definition 66 einfache funktionale Abhangigkeiten 66 Einfiige-Anomalie 57 Beispiel 82,94,97 Eingehende Beziehungen 208 encapsulation 241 endliche Relation 112 Entitat 130,206 Definition in SAP-SERM 206 Entitatstyp 130 Definition... 207 Entitatstypen Darstellung 130 grafische Darstellung 221 entity 12,206 13 Definition Entity 130 existenzabhangiger Entitatstyp 208 Existenzabhangigkeit 210 SAP-SERM Existenzabhangigkeit eines Entitatstyps von einem 186 anderen Existenzabhangigkeiten bei Sinz 195 existenzunabhangiger Entitatstyp 208 Extend - Beziehung use case 278 Exteme Beziehung 212 FA-Diagramm 60 flache Tabelle 23 FremdschlUssel Definition 27,37 funktionale Abhangigkeit.... 102 Basis 60 Bedeutung 61 Definition 66 Gegenseitig unabhangig 69 (Attribute) Generalisierung/Spezialisierung 214

Index

Definition 149 Geschaftsobjekt 118 Geschaflsobjekte 21 Gleichheit vs. Identitat 250 Gleichzeitig Entitat und Beziehung 166 grafische Darstellung Aggregation (ERM) 151 Generalisierung / Spezialisierung (UML) 262 rekursive Assoziation (UML) 260 relationale Datenmodelle . 27, 55 Relationen 25 Grundregel der Normalisierung 51 hierarchischer Beziehungstyp 209 Hinweis nur Statik, nicht Dynamik 120 Identitat vs. Gleichheit 250 identity equality 250 Include - Beziehung use case 278 information bidding 272 Informationstrager 130,206 Definition 13 objektorientiert 235 inheritance 264 instantiation 245 Instantiierung 245 Instanz 242, 245 integriertes Data Dictionary 226 Istein - Beziehung 262 Kapselung 272 objektorientiert 241 Kardinalitat 26 Kardinalitat einer Beziehung208 ER 143 kartesisches Produkt 115 Klassen 47 Klassenattribute 243 klassenbezogene Methoden. 243 Klassenbildung 245 Klassenhierarchie 262

291

Klassenmethoden 243 Klassenobjekt 246 Klassifikation 245 komplexe Objekte 271 Komponentenklasse 267 Konkrete Schritte bei der ERModellierung 172 konkurrierende SchlUssel 36, 134 logische Ebene 204 Losche-Anomalie 58 Beispiel 82,94,97 Mandant Definition 224 mehrfache Vererbung 267 Mehrfacheintrage Definition 23 mehrstellige Beziehungen....l89 mehrwertige Abhangigkeit... 102 Definition 103 echte 103 Methoden 236, 237, 274 body 249 in der objektorientierten Datenmodellierung 236 klassenbezogene 243 signature 249 Methoden und abstrakte Datentypen 246 Methoden und Operationen..237 Min-/Max-Angaben 34, 145 relational 28 multiple inheritance 267 Muss-Assoziationen 254 MWA 102, 103 n:m - Beziehung 32 ER 131 SAP-SERM 216 Nachricht Definition 274 Nachrichten 274 Nachrichtensequenz 275 n-are Assoziationen 256 n-Zerlegbarkeit 107, 108 oberste Regel des Datenbankentwurfs 48

292

Index

Object Data Management Group 235 object identifier 250 Objekt 206 Definition im SAP-Ansatz 206 Objekt = Informationstrager 239 Objekt Oder Eigenschaft?.... 239 Objektbegriff. 240 SAP-SERM 206 Objekte komplexe 271 Objekte (im 00-Ansatz) Definition 239 Objektidentifizierer 250 Objektintegritat 44, 57 Objektklasse (im objektorientierten Ansatz) Definition 242 Objektklassen 47 Objektmodell Definition 233 objektwertige Attribute 252 Operationen 236, 237, 274 partof - Beziehung 151, 267 physische Ebene 204 Polymorphismus 273 Primarschlussel 36 Projektion 75, 106 Qualitative Attribute Definition 10 Quantitative Attribute Definition 10 Realweltobjekte vs Datenbankobjekte 234 Redundanz 48 referentielle Integritat 44 Referenzen zwischen Objekten 252 Referierter Entitatstyp 208 rekursive Assoziation 260 Relation Definition 118 mathematisch 114 Relationale Datenbank Definition 112

relationale Datenmodelle grafische Notation 55 textliche Notation 55 Relationale Operatoren 104 relationale Verkniipfimg ..27, 40 Relationen Bedeutung 23 Definition 22 Eigenschaften 23 grafische Darstellung 25 textliche Schreibweise 24 Relationenbegriff 113 relationship 206 SAPR/3 Business Objekte 228 Mandantenfahigkeit 224 SAP-SERM 203, 204, 205 Schlussel 22,70 Definition 36,70 Schlussel (zusammengesetzte) textliche Notation 36 Schlusselbestimmung Beispiel 89 Schltisselkandidat 37 schwache Existenzabhangigkeit SAP-SERM 212 Sekundarschliissel 36 Semantik eines Weltausschnitts 3 Semantisch bedingte Leereintrage 186 SERM Beschreibung des Ansatzes 206 Signatur 275 signature 249 singularer Beziehungstyp 133 singularer Entitatstyp.. 133, 159, 186 Beispiel 187, 188 Spezialisierung disjunkte 214 vollstandige 215 SQL..2, 7, 11,25, 106, 117,226 SQL-Notation 25 Starke Existenzabhangigkeit

Index

SAP-SERM 212 Start-Entitatstyp 208 Subklasse 262 Superklassen 262 Surrogat 250 Teilvon - Beziehung 267 Teil_Von - Beziehung 151 temare Assoziationen 256 textliche Notation relationaler Datenmodelle 55 totale Beteiligung 142 transitive Abhangigkeit... 80, 83 Definition 83 Tupelvermehrung 46, 98 mehrfach 100 tjberladen 273 iiberlappender Fremdschliissel 125 Uberschreiben 273 tjbertragung von ERM nach RM 181 Beziehungstypen 183 Entitatstypen 182 Generalisierung / Spezialisierung 189 Mehrstellige Beziehungenl89 singularer Entitatstyp 186 Unabhangigkeit (Attribute)... 69 Universalrelation 49, 58 unnormalisierte Relationen... 49 Update-Anomalie 57 use cases 277 value equality 250 Verbindungsrelation 52 Beispiel 90 Definition 33 Verbund 75 Verbund zweier Relationen. 104 Vererbung 263

293

Definition 264 mehrfache 267 Verhalten von Realweltobjekten 236 voile funktionale Abhangigkeit Definition 59, 66, 61 vollstandige Spezialisierung 215 Weltausschnitt 1 wertbasierte Suchschlussel...250 Wertebereich 113 wichtigste Beziehung zwischen den Attributen einer Relation 58 Wiederholungsgruppen Definition 23 Wurzel 262 Zeit in Datenmodellen 165 Zeitliche Aspekte bei Entitatstypen Beispiel 165 Zeitliche Dimension ER 165 relational 126 Ziel-Entitatstyp 208 Zusammengefasst Attribute 12 Beziehungswertigkeiten 35 Relationen 24 zusammengesetzte Objekte..271 zusammengesetzte Schltissel Beispiel 33 Zustand eines Objekts ..239, 272 Zustandsubergange 283 Zustandsubergangsdiagramme 275 Zweck der Datenbank 42 Zweite Normalform Definition 70

9

LiTERATURVERZEICHNIS

Atkinson 1989 Atkinson, M. et al.: The Object-Oriented Database System Manifesto. In: Proceedings of the 1. International Conference on Deductive and Object-Oriented Databases, Kyoto, Japan, November 1989, S. 40-57Atkinson 1989] Balzert 1998 Balzert, Helmut: Lehrbuch der Software-Technik 11. Software-Management. Software-Qualitdtssicherung. Unternehmensmodellierung. Heidelberg und Berlin 1998 Balzert 1999 Balzert, Helmut: Lehrbuch Grundlagen der Informatik. Heidelberg 1999 Balzert 1999a Balzert, Heide: Lehrbuch der Objektmodellierung. Analyse und Entwurf Heidelberg und Berlin 1999 Balzert (Heide) 2001 Balzert, Heide: UML kompakt. Mit Checklisten. Heidelberg und Berlin 2001 Balzert (Helmut) 2001 Balzert, Helmut: Lehrbuch der Software-Technik L Software-Entwicklung (2. Auflage). Heidelberg und Berlin 2001 Bancilhon und Kanellakis 1992 Bancilhon, F.; Delobel, C ; Kanellakis, P.: Building an Object-Oriented Database System. The Story of O2, San Mateo 1992 Bertino und Martino 1993 Bertino, Elisa; Martino, Lorenzo: Object-Oriented Data-

296

Literatur

base Systems, Concepts and Architectures. Wokingham u.a. 1993 Booch 1994 Booch, Grady: Objektorientierte Analyse und Design, Bonnu.a. 1994 Booch, Rumbaugh und Jacobson 1999 Booch, Grady; Rumbaugh, James; Jacobson, Ivar: Das UML-Benutzerhandbuch Bonnu.a. 1999 Burkhardt 1997 Burkhardt, Rainer: UML - Unified Modeling Language. Objektorientierte Modellierung fur die Praxis, Bonn u.a. 1997 Burkhardt 1999 Burkhardt, Rainer: UML - Unified Modeling Language. Objektorientierte Modellierung fur die Praxis (2., aktualisierte Auflage), Bonn u.a. 1997 Burleson 1999 Burleson, Donald K.: Inside the Database Object Model, Boca Raton u.a. 1998 Cattel 1996 Cattell, R.G.G. (Hrsg.): The Object Database Standard: ODMG-93. Release 1.2, San Francisco 1996 Date 1986 Date, C.J.: An Introduction to Database Systems, Volume I (4. Auflage), Reading u.a. 1986 Date 1990 Date, C.J.: An Introduction to Database Systems. Volume I (5. Auflage), Reading u.a. 1990 Date und Darwen 1998 Date, C.J.; Darwen, Hugh: Foundation for Object/Relational Databases. The Third Manifesto, Reading (Mass.) u.a. 1998

Literatur

297

Eriksson und Penker 2000 Eriksson, Hans-Erik; Penker, Magnus: Business Modeling with UML. Business Pattern at Work, New York u.a. 2000 Ferstl und Sinz 1990 Ferstl, Otto K.; Sinz, Elmar J.: Objektmodellierung betrieblicher Informationssysteme im Semantischen Objektmodell (SOM), in: Wirtschaftsinformatik, 32. Jahrgang, Heft 6, Dezember 1990, S. 566 - 581 Ferstl und Sinz 1991 Ferstl, Otto K.; Sinz, Elmar J.: Ein Vorgehensmodell zur Objektmodellierung betrieblicher Informationssysteme im Semantischen Objektmodell (SOM), in: Wirtschaftsinformatik, 33. Jahrgang, Heft 6, Dezember 1991, S. 477 - 491 Ferstl und Sinz 1993a Ferstl, Otto K.; Sinz, Elmar J.: Geschdftsprozessmodellierung, in: Wirtschaftsinformatik, 35 (1993) 6, S. 589 - 592 Ferstl und Sinz 1993b Ferstl, Otto K.; Sinz, Elmar J.: Der Modellierungsansatz des Semantischen Objektmodells (SOM). Bamberger Beitrage zur Wirtschaftsinformatik Nr. 18, September 1993 Ferstl und Sinz 1994 Ferstl, Otto K.; Sinz, Elmar J.; Der Ansatz des Semantischen Objektmodells (SOM) zur Modellierung von Geschdftsprozessen. Bamberger Beitrage zur Wirtschaftsinformatik Nr. 21, Dezember 1994 Ferstl und Sinz 1995 Ferstl, Otto K.; Sinz, Elmar J.: Der Ansatz des Semantischen Objektmodells (SOM) zur Modellierung von Geschdftsprozessen, in: Wirtschaftsinformatik 37 (1995) 3, S. 209-220 Ferstl und Sinz 1996 Ferstl, Otto K.; Sinz, Elmar J.: Geschdftsprozessmodellierung im Rahmen des Semantischen Objektmodells, in: [Vossen und Becker 1996], S. 47 - 61

298

Literatur

FerstlundSinzl997 Ferstl, Otto K.; Sinz, Elmar J.: Modeling of Business Systems Using the Semantic Object Model (SOM) - A Methodological Framework. Bamberger Beitrage zur Wirtschaftsinformatik Nr. 43, July 1997 Fowler und Scott 1998 Fowler, Martin; Scott, Kendall: UML - konzentriert. Die Standardobjektmodellierungssprache anwenden. Bonn u.a. 1998 Geppert 1997 Geppert, Franz: Objektorientierte Datenbanksysteme. Ein Praktikum. Heidelberg 1997 Heuer 1992 Objektorientierte Datenbanken. Konzepte, Modelle, Systeme. Bonn u.a. 1992 Hughes 1991 Hughes, J. G.: Object-Oriented Databases. New York u.a. 1991 Hughes 1992 Hughes, J. G.: Objektorientierte Datenbanken. Miinchen u.a. 1992 (Ubersetzung von [Hughes 1991] Karge 1996 Karge, Reinhard: Real Objects. Konzepte und Praxis objektorientierter Datenbanken. Bonn u.a. 1996 Kemper und Eickler 1999 Kemper, A.; Eickler, A.: Datenbanksysteme. Eine Einfuhrung. Miinchen und Wien 1999 Kemper und Moerkotte 1993 Kemper, A.; Moerkotte, G.: Basiskonzepte objektorientierter Datenbanksysteme, in: Informatik-Spektrum (1993) 16, S. 69-80. Kim 1990 Kim, Won: Introduction to Object-Oriented Databases. Cambridge (Mass.) und London 1990

Literatur

299

Marshall 2000 Marshall, Chris: Enterprise Modeling with UML Designing Successful Software through Business Analysis. Reading (Mass.) u.a. 2000 Meier und Wust 1997 Meier, Andreas; Wtist, Thomas: Objektorientierte Datenbanken. Ein Kompafifur die Praxis-. Heidelberg 1997 Meyer 1990 Meyer, Bertrand: Objektorientierte Softwareentwicklung. Wienu.a. 1990 Oestereich 1998 Oestereich, Bernd: Objektorientierte Softwareentwicklung. Analyse und Design mit der Unified Modeling Language (4. Auflage). Mtinchen und Wien 1998 OMG 1999 Object Management Group: OMG Unified Modeling Language Specification, Version L3, June 1999 Petri 1962 Petri, C. A.: Kommunikation mit Automaten. Dissertation Universitat Bonn 1962 R/3 -Prozessmodell 3.1G Handbuch BC - Das R/3-Prozessmodell (Release 3.10) zu SAP-R/3, Release 3.1, SAP AG Walldorf, Mai 1997 R/3-Referenzmodell 3.0F Handbuch CA-R/3-Referenzmodell (Release 3. OF) zu SAP-R/3, Release 3.1, SAP AG Walldorf, Mai 1997 Rumbaughu.a. 1993 Rumbaugh, James; Blaha, Michael; Premerlani, William; Eddy, Frederick; Lorensen, William: Objektorientiertes Modellieren und Entwerfen, Mtinchen u.a. 1993 et al Saake, Tiirker und Schmitt 1997 Saake, Gunter; Schmitt, Ingo; Tiirker, Can: Objektdatenbanken. Konzepte, Sprachen, Architekturen. Bonn u.a. 1997

300

Literatur

SAP Analyzer SAP R/3-Analyzer. System R/3. Release 2.1 (Handbuch), Walldorfl994 SAP Datenmodell 96 SAP Datenmodell. Referenzmodell ftir Business Objekte (Michael Seubert). Material-Nr. 50011391. 1996. Schulungsunterlagen der Firma SAP. SAP-BC030 SAP Data Dictionary R/3 (R/3 System Release 2.1 Februar 1994). Schulungsunterlagen der Firma SAP. SAP-BCDD BC - SAP Data Dictionary. (R/3-System M i 1992). Schulungsunterlagen der Firma SAP. SAP-PP300 SAP-Informationsmodell Modellgestutztes Informationsmanagement im R/3-System. Das Datenmodell Produktionsplanung (Workshop PP300, Mdrz 1995). Schulungsunterlagen der Firma SAP. Schader und Korthaus 1998 Schader, M.; Korthaus, A. (Hrsg.): The Unified Modeling Language - Technical Aspects and Applications. Heidelberg 1998 Schader und Rundshagen 1994 Schader, Martin; Rundshagen, Michael: Objektorientierte Systemanalyse. Eine Einftihrung, Berlin u.a. 1994 Schulungsunterlagen Analyzer Schulungsunterlagen „SAP R/3-Analyzer'' Release 2.1 der SAP AG Sinz 1990 Sinz, Elmar J.: Das Entity-Relationship-Modell (ERM) und seine Erweiterungen, in: HMD 152 (1990), S. 17 - 29 Sinz 1991 Sinz, Elmar J.: Objektorientierte Analyse, in: Wirtschaftsinformatik, 33. Jahrgang, Heft 5, Oktober 1991, S. 455 457