Datenmodellierung und Datenbankentwurf: Ein Vergleich aktueller Methoden [1 ed.] 9783540205777, 3540205772 [PDF]

Zitiervorschau

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 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 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, 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 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