Datenbanken im Unternehmen: Analyse, Modellbildung und Einsatz [2., korr. Aufl. Reprint 2015] 9783486594850, 9783486272109

Table of contents :
1 Einleitung und Übersicht
1.1 Anforderungserhebung und -analyse
1.2 Konzeptuelle Modellbildung
1.3 Logischer Entwurf
1.4 Implementationsphase
1.5 Allgemeine Datenbankbegriffe
1.6 Zusammenfassung
1.7 Literatur
1.8 Kontrollaufgaben
2 Anforderungserhebung und -analyse
2.1 Dateisystem vs. Datenbankmanagementsystem
2.1.1 Isolierte Dateiverwaltung
2.1.2 Integrierte Dateiverwaltung
2.1.3 Architektur von Datenbankmanagementsystemen
2.2 Anforderungserhebung
2.2.1 Dokumentenanalyse
2.2.2 Fragebogentechnik
2.2.3 Interviewmethode
2.2.4 Berichtsmethode
2.2.5 Selbstaufschreibung
2.2.6 Beobachtungsmethode
2.3 Anforderungsdokument
2.3.1 Informationsanforderungen
2.3.2 Funktionale Anforderungen
2.3.3 Bearbeitungsanforderungen und dynamische Aspekte
2.4 Zusammenfassung
2.5 Literatur
2.6 Kontrollaufgaben
3 Konzeptueller Datenbankentwurf
3.1 Strukturorientierte Modellbildung
3.1.1 Grundlagen des Entity-Relationship-Modells
3.1.2 Weiterentwicklungen des Entity-Relationship-Modells
3.1.3 Literatur
3.1.4 Kontrollaufgaben
3.2 Struktur- und funktionsorientierte Modellbildung
3.2.1 Gründe für die Verwendung der Kombinationsmethode
3.2.2 Kombination von ERM und DFD
3.2.3 Kontrollaufgaben
3.3 Objektorientierte Modellbildung
3.3.1 Konzepte der Objektorientierung
3.3.2 Unified Modeling Language (UML)
3.4 Weitere Formen der Modellbildung
3.4.1 Geschäftsprozessorientierte Modellbildung
3.5 Sichtenintegration und Schemakonsolidierung
3.5.1 Prozess der Sichtenintegration
3.5.2 Kontrollaufgaben
3.6 Formaler Datenbankentwurf
3.6.1 Das relationale Datenbankmodell
3.6.2 Grundlagen des formalen Datenbankentwurfs
3.6.3 Relationentheorie und Normalisierung
3.6.4 Kontrollaufgaben
3.7 Zusammenfassung
3.8 Literatur
4 Logischer Entwurf
4.1 Transformation von Entitytypen
4.2 Transformation von Beziehungstypen
4.2.1 Transformation rekursiver Beziehungstypen
4.2.2 Transformation binärer Beziehungstypen
4.2.3 Transformation n-ärer Beziehungstypen
4.3 Transformation von Generalisierung und Subtypenhierachie
4.4 Zusammenfassung
4.5 Literatur
4.6 Kontrollaufgaben
5 Einführung in Datenbankmanagementsysteme
5.1 Architektur eines Datenbankmanagementsystems
5.1.1 Die Schemaarchitektur
5.1.2 Die Systemarchitektur
5.2 Die Verwaltung von Metadaten
5.3 Literatur
6 Grundlagen von Anfragesprachen
6.1 Formale Einführung der Grundlagen von Datenbankmodellen
6.2 Typen von Relationen
6.3 Anforderungen an Anfragesprachen
6.4 Sprachansätze
6.5 Relationale Algebra
6.5.1 Mengenoperationen
6.5.2 Zusätzliche relationale Operationen
6.5.3 Beispiele
6.5.4 Eigenschaften der Relationenalgebra
6.5.5 Zusammenfassung
6.5.6 Literatur
6.6 Relationenkalkül
6.6.1 Tupelkalkül
6.6.2 Bereichskalkül
6.6.3 Mächtigkeit der Relationenkalküle
6.6.4 Zusammenfassung
6.6.5 Literatur
6.7 Funktionen auf Mengen von Tupeln
6.8 Zusammenfassung
6.9 Kontrollaufgaben
7 Die relationale Datenbanksprache SQL
7.1 Einführung in SQL
7.2 Die Datendefinitionssprache (DDL)
7.2.1 Anlegen einer Datenbank
7.2.2 Datentypen in SQL-92
7.2.3 Anlegen einer Tabelle
7.2.4 Integritätsbedingungen
7.2.5 Ändern des Datenbankschemas
7.2.6 Beispiel eines Datenbankschemas für eine Unternehmung
7.2.7 Kontrollaufgaben
7.3 Die Datenbankanfragesprache (DRL)
7.3.1 Die SELECT-Klausel (Projektion)
7.3.2 Die FROM-Klausel (Ausgangstabelle)
7.3.3 Die WHERE-Klausel (Selektion)
7.3.4 Die GROUP BY-Klausel (Bilden von Untertabellen)
7.3.5 Geschachtelte Anfragen
7.3.6 Mengenoperationen in SQL
7.3.7 Die ORDER BY-Klausel (Sortieren der Ergebnistabelle)
7.3.8 Zusammenfassung
7.3.9 Kontrollaufgaben
7.4 Die Datenmanipulationssprache (DML)
7.4.1 Einfügen von Zeilen
7.4.2 Ändern von Zeilen
7.4.3 Löschen von Zeilen
7.5 Datensichten
7.5.1 Motivation
7.5.2 Vorteile von Sichten
7.5.3 Probleme mit Sichten
7.5.4 Änderungen auf Sichten
7.6 Die Datenkontrollsprache (DCL)
7.7 Die Speicherungsstrukturdefinitionssprache (SSL)
7.8 Datenschutz, Datensicherung und Datenkonsistenz
7.9 Kritische Würdigung von SQL-92
7.10 Charakteristika relationaler DBMS
7.11 Einbettung von SQL in Wirtssprachen (Embedded SQL)
7.12 Programmgeneratoren
7.13 Anfragebearbeitung und -Optimierung
7.13.1 Anfragebearbeitung
7.13.2 Anfrageoptimierung
7.14 Zusammenfassung
7.15 Literatur
7.16 Kontrollaufgaben
8 SQL:1999
8.1 Struktur von SQL:1999
8.2 Datentypen und Typkonstruktoren
8.2.1 Vordefinierte Datentypen
8.2.2 Typkonstruktoren
8.2.3 Individualisierte Datentypen (distinct data type)
8.2.4 Benutzerdefinierte strukturierte Datentypen bzw. benannte Zeilentypen
8.3 Objektorientierte Konzepte in SQL: 1999
8.3.1 Beziehungsarten zwischen Vaterobjekten und eingebundenen Objekten in komplexen Objekten
8.3.2 Objektidentität
8.3.3 Datenabstraktion/Kapselung
8.3.4 Vererbung
8.3.5 Polymorphismus
8.3.6 Einige Anmerkungen zu komplexen Objekten in SQL: 1999
8.3.7 Zusammenfassung
8.4 Trigger
8.5 Weitere Neuerungen im Überblick
8.5.1 Sichten
8.5.2 Benennung von SFW-Blöcken
8.5.3 Rekursion
8.5.4 Datenschutz und Datensicherheit
8.5.5 On/ine Analytical Processing (OLAP)
8.5.6 Sicherungspunkte
8.5.7 SQL/MM (Multimedia-Unterstützung)
8.5.8 SQL/MED (Management of External Data)
8.5.9 Java Sprachanbindung
8.6 Literatur
9 Transaktionsverarbeitung und Fehlertoleranz
9.1 Transaktionsmanagement
9.1.1 Probleme bei der Parallelarbeit auf der DB
9.1.2 Das Transaktionskonzept
9.1.3 Serialisierbarkeit
9.1.4 Literatur
9.2 Synchronisationsverfahren
9.2.1 Klassifikation
9.2.2 Sperrverfahren
9.2.3 Zeitstempelverfahren
9.2.4 Optimistische Synchronisationsverfahren
9.2.5 Synchronisation in SQL-92
9.2.6 TP-Monitor
9.2.7 Literatur
9.3 Fehlertoleranz
9.3.1 Fehler in Transaktionssystemen
9.3.2 Maßnahmen zur Fehlerbehandlung
9.3.3 Literatur
9.4 Geschachtelte Transaktionen
9.4.1 Geschlossen geschachtelte Transaktion
9.4.2 Offen geschachtelte Transaktion
9.4.3 Entwicklungstransaktion
9.4.4 Literatur
9.5 Kontrollaufgaben
Literatur
Sachverzeichnis

Citation preview

Lehrbücher Wirtschaftsinformatik Herausgegeben von Prof. Dr. Karl Kurbel Europa-Universität Frankfurt/Oder

Datenbanken im Unternehmen Analyse, Modellbildung und Einsatz von Prof. Dr. Günther Pernul, Prof. Dr. Rainer Unland Universität Essen 2., korrigierte Auflage

Oldenbourg Verlag München Wien

Die Deutsche Bibliothek - CIP-Einheitsaufnahme Pernul, Günther: Datenbanken im Unternehmen : Analyse, Modellbildung und Einsatz / von Günther Pernul ; Rainer Unland. - 2., korrigierte Aufl.. - München ; Wien : Oldenbourg, 2003 (Lehrbücher Wirtschaftsinformatik) ISBN 3-486-27210-1

© 2003 Oldenbourg Wissenschaftsverlag GmbH Rosenheimer Straße 145, D-81671 München Telefon: (089) 45051-0 www.oldenbourg-verlag.de Das Werk einschließlich aller Abbildungen ist urheberrechtlich geschützt. Jede Verwertung außerhalb der Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Bearbeitung in elektronischen Systemen. Lektorat: Irmela Wedler Satz: LE-TeX Jelonek, Schmidt & Vöckler GbR Herstellung: Rainer Hartl Umschlagkonzeption: Kraxenberger Kommunikationshaus, München Gedruckt auf säure- und chlorfreiem Papier Druck: R. Oldenbours GraDhische Betriebe Druckerei GmbH

Vorwort Heute haben fast alle Unternehmen den Wert der Information als Produktionsfaktor erkannt und ihre Datenhaltung auf Basis eines unternehmensweiten Datenmodells organisiert. Zur Verwaltung des Datenbestandes kommt zunehmend moderne Datenbanksoftware zum Einsatz. Das vorliegende Lehrbuch bietet eine anwendungsorientierte Einführung in die Datenmodellierung und Datenbanktechnologie unter besonderer Berücksichtigung der Anforderungen von Unternehmen. Schwerpunkte des Buches sind deshalb hauptsächlich die Methoden, Konzepte, Sprachen und Komponenten, die einen effizienten Datenbankeinsatz gewährleisten. Das Buch besteht aus zwei aufeinander aufbauenden Teilen. Der erste Teil (Kapitel 1 bis 4) beinhaltet die Analyse, die Modellbildung und den systemunabhängigen Entwurf von Datenbankanwendungen. Im zweiten Teil (Kapitel 5 bis 8) liegt der inhaltliche Schwerpunkt auf dem Einsatz der Datenbanktechnik. Der Entwurf einer Datenbank (DB) wird typischerweise in mehrere Phasen unterteilt, die selbst wiederum durch unterschiedliche Aktivitäten strukturiert sind. In Kapitel 1 wird eine übliche Vorgehensweise für den Entwurfsprozess dargestellt. Seine einzelnen Phasen werden anhand des Lebenszyklus einer Datenbank identifiziert. Die systemunabhängigen Aktivitäten, die in diesen Phasen durchzuführen sind, werden in jeweils einem nachfolgenden Kapitel genau beschrieben. Des Weiteren werden noch die wichtigsten Datenbankbegriffe eingeführt. Eine sorgfältige Erhebung und nachfolgende Analyse der Anforderungen der potenziellen Nutzer stellt die Grundvoraussetzung für die Entwicklung einer effizient nutzbaren DB dar. Das Kapitel 2 beginnt mit einer Abgrenzung der Datenbankmanagementsysteme (DBMS) von Dateisystemen. Anschließend werden die unterschiedlichen Methoden der Anforderungserhebung erläutert. Ähnlich wichtig wie die sorgfältige und vollständige Erhebung der Anforderungen ist ihre übersichtliche Darstellung und die Analyse der Ergebnisse der Erhebung im Anforderungsdokument. Wir klassifizieren Anforderungen hinsichtlich ihrer Eigenschaften in die vier Typen Informationsanforderungen, funktionale Anforderungen, dynamische Anforderungen und Bearbeitungsanforderungen, zeigen unterschiedliche Methoden der Analyse und erläutern die Dokumentation der Anforderungen im Anforderungsdokument. Die im Anforderungsdokument enthaltenen Aufgaben und Vorgaben bilden die Grundlage für den konzeptuellen Datenbankentwurf. Das Kapitel 3 stellt den Schwerpunkt des 1. Teiles des Buches dar und widmet sich den unterschiedlichen Paradigmen des konzeptuellen Entwurfs einer Datenbank. Das Kapitel beginnt mit der Darstellung der strukturorientierten Modellbildung, einer Technik, die ausschließlich Informationsanforderungen nutzt. Weiter Raum wird dem Entity-Relationship-Modell (ERM) als De-facto-Standard für die konzeptuelle Modellbildung gewidmet. Neben den Basiskonstrukten werden einige wichtige Erweiterungen sowie prominente Vertreter von „erweiterten" ERM vorgestellt. Alle Modelle dieser Klasse beinhalten jedoch die Einschränkung, dass sie

VI

Vorwort

den Schwerpunkt der Analyse auf die Struktur der Daten legen und damit die funktionalen Anforderungen an die Datenbank überwiegend vernachlässigen. Es liegt also nahe, Informationsund funktionale Anforderungen aus dem Anforderungsdokument gemeinsam zu betrachten und in eine einheitliche Methode zu integrieren. Als zweites Paradigma der konzeptuellen Modellbildung betrachten wir die Kombination von struktur- und funktionsorientierter Modellbildung. Diese Vorgehensweise basiert auf einer schrittweisen Verfeinerung eines Funktions- und eines Datenmodells. Sie hat den Vorteil, dass das konzeptuelle Datenmodell aus diesen beiden Sichten stufenweise herausgearbeitet werden kann. Dies führt dazu, dass die Struktur der Datenbank und die auf sie zugreifenden funktionsorientierten Programme sehr gut aufeinander abgestimmt sind und die Schnittstelle zwischen Datenbanksystem und Anwendungsprogrammen klein und übersichtlich gehalten werden kann. Aus objektorientierter Sichtweise sind die Komponenten eines informationstechnischen Systems seine Daten, seine Zustände und die Ereignisse, die Änderungen an Zuständen initiieren. Bei der objektorientierten Modellbildung werden alle drei Merkmale gleichberechtigt betrachtet und dem zentralen Konzept „Objekt" zugeordnet. In Unterkapitel 3.3 diskutieren wir die wesentlichen Eigenschaften einer objektorientierten Vorgehensweise und erarbeiten ein integriertes Objektmodell, das neben den Aspekten, die bereits in den klassischen Modellen beinhaltet sind, auch Konzepte zur Modellierung von Verhalten zur Verfügung stellt. Objektmodelle nutzen daher auch dynamische Anforderungen aus dem Anforderungsdokument. Die Struktur des Kapitel 3 wurde nicht zufallig gewählt, sondern reflektiert die chronologische Reihenfolge, in der sich Wissenschaftler und Unternehmen gleichermaßen mit Methoden zur Analyse von betrieblichen Informationssystemen beschäftigt haben. Die Entwicklung von Methoden und Techniken ist auch heute noch nicht vollständig abgeschlossen. Es entwickeln sich weiterhin neue Denkansätze. So rückte z.B. in den letzten Jahren die Analyse und Modellierung von Geschäftsprozessen als Basis für den Datenbankentwurf zunehmend in den Mittelpunkt der Betrachtung. Unterkapitel 3.4 fasst aktuelle Trends und weitere Ansätze zur konzeptuellen Modellbildung zusammen. Das Kapitel 3 wird noch durch zwei weitere Unterkapitel abgerundet: In Unterkapitel 3.5 wird das Gebiet der Sichtenintegration behandelt. Sichtenintegration wird notwendig, wenn ein unternehmensweites Datenmodell nicht als Ganzes, sondern durch Integration und Konsolidierung mehrerer Bereichsdatenmodelle entwickelt wird. Das Kapitel wird mit dem formalen Datenbankentwurf (Unterkapitel 3.6) abgeschlossen. Diese Entwurfsmethode wird hauptsächlich beim Entwurf relationaler Datenbankschemata verwendet. Weiterhin wird das relationale Datenbankmodell eingeführt, sowie dessen Grundlagen erklärt. Für Leser, die in diese Materie tiefer einsteigen möchten, schließen wir das Themengebiet mit einer komprimierten Darstellung der Normalisierung relationaler Datenbanken ab. Bei den bisher geschilderten Phasen der Modellbildung ist es möglich, ein konzeptuelles Datenmodell losgelöst von seiner späteren Implementation zu entwerfen. In Kapitel 4 behandeln wir den logischen Datenbankentwurf, eine Entwurfsphase, in der nun erstmals ein systemabhängiges Zielmodell entwickelt wird. Darunter wird die Repräsentation des Realweltausschnitts mit den Methoden und Techniken des zu Grunde liegenden Datenbankmodells verstanden. Als Ergebnis entsteht das konzeptuelle Datenbankschema. Wir werden uns in diesem Buch auf

Vorwort

VII

das relationale Datenbankmodell beschränken und zeigen, wie ein ERM in ein auf dem relationalen Datenbankmodell beruhendes konzeptuelles Datenbankschema transformiert werden kann. Der zweite Hauptteil des Buches widmet sich dem Datenbankeinsatz. Dabei geht es weniger um die technische Umsetzung und interne Arbeitsweise eines DBMS, sondern vielmehr um die Frage, wie ein Benutzer bzw. eine Anwendung mit einem DBMS arbeitet. Die wichtigste Schnittstelle zur Anwendung stellen dabei zweifelsohne die Datenbanksprachen dar, zu deren wichtigsten Vertretern die Datendefinitions-, die Datenmanipulations- und die Anfragesprache gehören. Dementsprechend werden sie auch ausführlich und praxisnahe anhand des De-factoStandards für relationale Datenbanksysteme, der Anfragesprache SQL, diskutiert. Kapitel 5 gibt eine knappe Einführung in die grundsätzliche Architektur und Arbeitsweise eines DBMS. Dabei werden die einzelnen Konzepte nur in so weit diskutiert, wie sie für das Verständnis des Hauptteils des Buches von Nutzen sind. Kapitel 6 widmet sich den Grundlagen von Anfragesprachen, wobei insbesondere auch Wert auf eine solide Theoriebildung gelegt wird. Erst das Verständnis der formalen Grundlagen einer Sprache wird es einem Nutzer ermöglichen, die Qualität einer Sprache und damit ihre Stärken und Schwächen fundiert beurteilen zu können. Einem kurzen formalen Ausflug in die Welt der Typsysteme und Hilfsmittel zur Datenmodellierung folgt eine intensive Diskussion der Entwurfsprinzipien für (Datenbank-)Sprachen allgemein und Anfragesprachen im Besonderen. Obwohl entsprechende Entwurfsprinzipien schon seit einigen Jahrzehnten bekannt sind und diskutiert werden, werden manchmal immer noch gravierende Designfehler gemacht, die sich im praktischen Einsatz einer Sprache dann böse rächen können. Hier muss man schon zugeben, dass der Informatik gelegentlich noch die fundierte, nach festen Regeln erfolgende ingenieurwissenschaftliche Vorgehensweise beim Entwurf komplexer Systeme fehlt. Nach einer kurzen Diskussion von Sprachansätzen werden die beiden formalen Basisansätze vieler Anfragesprachen, die Relationenalgebra und die Relationenkalküle eingeführt. In diesem Kapitel wird einerseits Wert auf eine saubere Einführung der formalen Basiskonstrukte dieser Sprachen gelegt, andererseits wird aber auch versucht, dies so verständlich wie nur möglich zu tun, indem beispielsweise statt formaler mathematischer Notationen eine etwas sprechendere Formulierungsweise bei Anfragen gewählt wurde. Kapitel 7 bildet den inhaltlichen Schwerpunkt dieses zweiten Teils des Buches und widmet sich dem Einsatz von SQL, dem De-facto-Standard beim Zugriff auf relationale Datenbanksysteme. SQL feiert zwischenzeitlich auch schon sein 25-jähriges Jubiläum, weshalb man dieser Sprache auch alle Höhen und Tiefen eines Sprachenlebens ansehen kann. Dem ersten noch vom Forschergeist angehauchten Prototypen folgte eine an den Pragmatismus der Praxis angepasste kommerzielle Variante, der einiges von der konzeptuellen Klarheit des Prototyps abhanden gekommen war. Zwischenzeitlich haben die Standardisierungsbemühungen um SQL zwar auch die Sprache wieder konzeptuell sauberer werden lassen, aufgrund von nicht mehr einfach auszuräumenden Altlasten konnte eine Sanierung aber nicht im vollen Umfang gelingen. Das Buch präsentiert die für den durchschnittlichen Nutzer von SQL relevanten Konzepte dieser Sprache recht ausführlich, wobei bewusst eine Abstützung auf den SQL: 1999 Standard erfolgte. Dieser wird zwar in seiner vollen Breite von keinem kommerziellen SQL-Dialekt abgedeckt, andererseits ist er aber in Bezug auf die Klarheit und Sauberkeit der Sprache

VIII

Vorwort

am ehesten geeignet, den Ansprüchen einer Hochschulausbildung in Richtung konzeptuelles Verständnis gerecht zu werden. Die drei Hauptteile dieses Kapitels widmen sich den wichtigsten Teilsprachen von SQL, der Datendefinitions-, der Datenanfrage- und der Datenmanipulationssprache und zwar in dieser Reihenfolge. Gerade bei der Datendefinition wird sehr ausführlich auf das Typkonzept eingegangen, weil dieses erheblichen Einfluss auf eine sauber und konsistent modellierte Datenbank hat. Der Anfrageteil ist aufgrund seiner Mächtigkeit auch am längsten geraten. Es wurde versucht, die Darstellung durch möglichst viele Beispiele lesbar zu gestalten. Manchmal hilft ein Beispiel eher, ein Konzept zu beschreiben, als eine ausführliche verbale Diskussion. Zugriffsstrukturen sowie Datensicherheit, -integrität und -schütz werden in diesem Buch nur sehr knapp behandelt. Der Grund liegt darin, dass diese Teile noch nicht oder erst teilweise standardisiert wurden. Eine Diskussion der grundsätzlichen Konzepte liegt aber außerhalb der Intention dieses Buches und soll daher anderer Literatur überlassen bleiben. Zum Abschluss dieses Kapitels wird noch kurz auf die Bearbeitung und Optimierung von Anfragen eingegangen. Auch wenn SQL eine deskriptive Anfragesprache ist, bei der eigentlich nur angegeben werden soll, was man gerne wissen möchte, sieht die Realität anders aus. Unterschiedliche Formulierungen des gleichen Sachverhaltes werden normalerweise auch eine unterschiedlich effiziente Ausführung der Anfrage nach sich ziehen. Damit ist es (leider) immer noch wichtig, die Grundlagen einer Anfrageoptimierung zu verstehen. Datenbanksysteme stehen einer Vielzahl von Benutzern und Anwendungen für eine parallele, aber voneinander isolierte Nutzung zur Verfügung. Jedoch muss die Parallelarbeit auf einem gemeinsamen Datenbestand korrekt synchronisiert werden, will man keine Probleme wie Konsistenzverletzungen der Datenbank oder falsche Ergebnisse von Anfragen in Kauf nehmen. Dieser Thematik und dem so wichtigen Gebiet der Fehlertoleranz widmet sich Kapitel 8. Auch hier trifft wieder zu, dass die dem Transaktionsmanagement zu Grunde liegenden Konzepte nur teilweise an der Schnittstelle des DBMS zu Tage treten. Viel läuft mehr oder weniger unsichtbar auf der internen Ebene ab. Trotzdem gilt auch hier, dass ein grundsätzliches Verständnis dieser Problematik den Umgang mit Datenbanksystemen erheblich vereinfachen und insbesondere auch sicherer machen kann. Neben den klassischen Themen wie Synchronisation und Recovery widmet sich dieses Kapitel am Ende auch noch neueren Konzepten, die langsam in kommerzielle Systeme Eingang finden, wie z.B. geschachtelten Transaktionen. Auch wenn sie wegen ihrer scheinbaren Komplexität nicht sehr beliebt ist, das solide Verständnis der einem Konzept oder allgemein einem System zu Grunde liegenden Theorie kann erheblich zur effizienten und zielgerichteten Arbeit mit dem System beitragen. Deshalb haben wir uns in diesem Buch bemüht, trotz oder gerade wegen seines anwendungsorientierten Charakters auch immer dann etwas Theorie einzustreuen, wenn sie zum Verständnis des Stoffes von Nutzen ist. Alle Kapitel folgen einem einheitlichen Aufbauschema. Jedes Kapitel wird mit einer Zusammenfassung und Angaben zu weiterführender Literatur abgeschlossen. Einige Kapitel und Unterkapitel, die uns als sehr wichtig erscheinen, sind am Ende mit Kontrollaufgaben ausgestattet. Da es sich um ein Lehrbuch handelt, wurde auch besonderer Wert auf viele und didaktisch sinnvolle Beispiele gelegt.

Vorwort

IX

Obwohl das Buch als eine Einheit konzipiert wurde, können die Teile Analyse und Modellbildung sowie Datenbankeinsatz auch unabhängig voneinander studiert werden. Das Buch richtet sich an Studenten, die als Unterstützung zu einer anwendungsorientierten Datenbankvorlesung eine Darstellung von relevanten Themen zum Datenbankeinsatz diskutieren möchten. Es richtet sich aber auch an interessierte Praktiker, die mit Datenbanken arbeiten (wollen) und/oder lernen möchten, wie man ein Datenbankschema als ein redundanzfreies Abbild eines Realweltausschnittes entwerfen kann. Durch seine konsequente Anwendungsorientierung ist das Buch insbesondere auf Vorlesungen zugeschnitten, wie sie in (modernen) Studienplänen des Studienganges Wirtschaftsinformatik, Wirtschaftsingenieurwesen oder aber auch der angewandten und praktischen Informatik angesiedelt sind. Unserer Einschätzung nach kann der durch dieses Buch vermittelte Inhalt entweder kompakt in einer vier Semesterwochenstunden (SWS) umfassenden Vorlesung oder aber unter Einschluss und intensiver Diskussion von ausführlichen Beispielen auch in zwei Vorlesungen zu je drei SWS vermittelt werden. Wir selbst setzen das Buch in zwei Vorlesungen ein. Dozenten, die dieses Buch als Grundlage für ihre Lehrveranstaltung in Erwägung ziehen, können von den Autoren Folienvorlagen bzw. Lösungen zu ausgewählten Kontrollaufgaben anfordern. Es gibt bereits eine Vielzahl von Büchern, die sich mit der Thematik Datenmodellierung und Datenbankmanagementsysteme beschäftigen. Viele dieser Bücher haben ihre eigenen Stärken, weshalb sie auch sehr empfehlenswert sind. Die Stärke des vorliegenden Buches ist seine Anwendungsorientiertheit und seine Zielrichtung hin zu Methoden und Techniken, die den effizienten Einsatz der Datenbanktechnik ermöglichen. Danksagung Das Schreiben eines Buches ist nicht nur eine Einzelleistung der Autoren, sondern die Leistung einer ganzen Gruppe von mit unterschiedlichsten Aufgaben befassten Personen. Die Autoren möchten sich bei allen Beteiligten recht herzlich für die angenehme und engagierte Mitarbeit bedanken und auch dafür, dass die weniger erquicklichen Stressphasen des Buchschreibens mit Humor und Verständnis beantwortet wurden. Zu den unverzagt engagierten konstruktiven Kritikern gehören unsere (ehemaligen) Mitarbeiter(innen) Boris Bachmendo, Gaby Herrmann, Torsten Heverhagen, Andre Humberg, Helmut Nienaber, Torsten Priebe, Jörg Rudnick und Ulrich Wanka. Viel Dank geht auch an Karsten Bach, Ingo Pospiech, Torsten Schlichting und Kay Wilhelm für Vorarbeiten zu einzelnen Unterkapiteln und für die Ausarbeitung von SQL-Anfragen, Torsten Mandry für die Erstellung der meisten Abbildungen und Elisabeth Becker und Ingrid Kleinstoll für die sorgfältige Erledigung vieler Schreibarbeiten. Herzlich bedanken möchten wir uns auch bei Herrn Dr. Nelson Mattos von IBM, der uns mit der Zur-Verfügung-Stellung immer wieder aktualisierter Foliensätze zum neuen SQL: 1999Standard das unerquickliche Suchen und Identifizieren der relevanten Neuerungen in den entsprechenden Standardisierungsunterlagen erheblich erleichtert hat. Besonders bedanken möchte sich Günther Pernul bei seiner Familie für die Geduld und das Verständnis für die diesem Buch geopferten Abende und Wochenenden. Beide Autoren gemeinsam möchten sich bei den Mitarbeitern vom Oldenbourg Verlag, insbesondere bei Irmela Wedler und Angelika Sperlich für die Umsetzung des Buches bedanken. Last but not least sei auch unserem Kollegen Karl Kurbel ein herzlicher Dank ausgesprochen.

Vorwort

χ

Er hat sich nicht nur mit sehr viel Engagement für diese Reihe stark gemacht, sondern auch durch konstruktive Kritik und viel Geduld zur Entwicklung dieses Lehrbuches beigetragen. Kontakt Die inhaltliche Verantwortung für dieses Werk aber tragen alleine die Autoren. An sie möge man sich wenden, wenn Dinge zu kritisieren, Fehler zu bemängeln oder einfach nur Verbesserungsvorschläge zu machen sind. Wie in der heutigen Zeit üblich, gibt es auch zu diesem Buch eine WWW-Adresse (siehe unten). Hier werden Fehler unter Nennung der „Entdecker" abgelegt. Geplant ist auch die Bereitstellung von Folien, Übungsaufgaben und Lösungen sowie weiterer Informationen und Dienste, die im Umfeld des Buches von Nutzen sein können (Internet-Adresse: siehe unten). Schließlich sei noch angemerkt, dass die Autoren bei der Erstellung dieses Buches auch die letzten Windungen ihres Gehirns ausgepresst haben, trotzdem aber am Ende der Arbeit erheblich schwerer da standen als zu Beginn. Hieraus lässt sich unweigerlich der Schluss ziehen, dass Datenbankwissen schwer wiegt und auch wir massiv dazugelernt haben. Wir wünschen dem Leser, dass er den letzten Punkt der Aussage auf sich bezogen nach Lektüre des Buches auch erfahren hat. Günther Pernul und Rainer Unland

WWW-Seiten: http://www.cs.uni-essen.de/dawis/publications/DBSiU/ http://www.wi-inf.uni-essen.de/~ifs/DBSiU/ E-mail: p e r n u l @ w i - i n f . u n i - e s s e n . d e (Günther Pernul) u n l a n d R @ i n f o r m a t i k . u n i - e s s e n . d e (RainerUnland)

Inhalt 1

Einleitung und Übersicht

1

1.1

Anforderungserhebung und -analyse

6

1.2

Konzeptuelle Modellbildung

7

1.3

Logischer Entwurf

8

1.4

Implementationsphase

9

1.5

Allgemeine Datenbankbegriffe

10

1.6

Zusammenfassung

12

1.7

Literatur

13

1.8

Kontrollaufgaben

13

2

Anforderungserhebung und -analyse

15

2.1 2.1.1 2.1.2 2.1.3

Dateisystem vs. Datenbankmanagementsystem Isolierte Dateiverwaltung Integrierte Dateiverwaltung Architektur von Datenbankmanagementsystemen

18 19 19 21

2.2 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6

Anforderungserhebung Dokumentenanalyse Fragebogentechnik Interviewmethode Berichtsmethode Selbstaufschreibung Beobachtungsmethode

25 27 27 28 29 30 30

2.3 2.3.1 2.3.2 2.3.3

Anforderungsdokument Informationsanforderungen Funktionale Anforderungen Bearbeitungsanforderungen und dynamische Aspekte

31 33 42 56

2.4

Zusammenfassung

60

2.5

Literatur

61

2.6

Kontrollaufgaben

61

XII

Inhalt

3

Konzeptueller Datenbankentwurf

65

3.1 3.1.1 3.1.2 3.1.3 3.1.4

Strukturorientierte Modellbildung Grundlagen des Entity-Relationship-Modells Weiterentwicklungen des Entity-Relationship-Modells Literatur Kontrollaufgaben

68 69 79 84 85

3.2 3.2.1 3.2.2 3.2.3

Struktur- und funktionsorientierte Modellbildung Gründe für die Verwendung der Kombinationsmethode Kombination von ERM und DFD Kontrollaufgaben

88 88 89 95

3.3 3.3.1 3.3.2

Objektorientierte Modellbildung Konzepte der Objektorientierung Unified Modeling Language (UML)

95 97 100

3.4 3.4.1

Weitere Formen der Modellbildung Geschäftsprozessorientierte Modellbildung

113 113

3.5 3.5.1 3.5.2

Sichtenintegration und Schemakonsolidierung Prozess der Sichtenintegration Kontrollaufgaben

118 121 132

3.6 3.6.1 3.6.2 3.6.3 3.6.4

Formaler Datenbankentwurf Das relationale Datenbankmodell Grundlagen des formalen Datenbankentwurfs Relationentheorie und Normalisierung Kontrollaufgaben

133 133 140 145 158

3.7

Zusammenfassung

162

3.8

Literatur

164

4

Logischer Entwurf

165

4.1

Transformation von Entitytypen

165

4.2 4.2.1 4.2.2 4.2.3

Transformation von Beziehungstypen Transformation rekursiver Beziehungstypen Transformation binärer Beziehungstypen Transformation n-ärer Beziehungstypen

167 167 168 172

4.3

Transformation von Generalisierung und Subtypenhierachie

173

4.4

Zusammenfassung

177

4.5

Literatur

178

4.6

Kontrollaufgaben

178

Inhalt

XIII

5

Einführung in Datenbankmanagementsysteme

181

5.1 5.1.1 5.1.2

Architektur eines Datenbankmanagementsystems Die Schemaarchitektur Die Systemarchitektur

181 181 183

5.2

Die Verwaltung von Metadaten

186

5.3

Literatur

189

6

Grundlagen von Anfragesprachen

191

6.1

Formale Einführung der Grundlagen von Datenbankmodellen

191

6.2

Typen von Relationen

199

6.3

Anforderungen an Anfragesprachen

200

6.4

Sprachansätze

205

6.5 6.5.1 6.5.2 6.5.3 6.5.4 6.5.5 6.5.6

Relationale Algebra Mengenoperationen Zusätzliche relationale Operationen Beispiele Eigenschaften der Relationenalgebra Zusammenfassung Literatur

208 208 213 226 227 230 230

6.6 6.6.1 6.6.2 6.6.3 6.6.4 6.6.5

Relationenkalkül Tupelkalkül Bereichskalkül Mächtigkeit der Relationenkalküle Zusammenfassung Literatur

230 232 242 248 249 249

6.7

Funktionen auf Mengen von Tupeln

250

6.8

Zusammenfassung

251

6.9

Kontrollaufgaben

252

7

Die relationale Datenbanksprache SQL

255

7.1

Einführung in SQL

255

7.2 7.2.1 7.2.2 7.2.3 7.2.4 7.2.5 7.2.6 7.2.7

Die Datendefinitionssprache (DDL) Anlegen einer Datenbank Datentypen in SQL-92 Anlegen einer Tabelle Integritätsbedingungen Ändern des Datenbankschemas Beispiel eines Datenbankschemas für eine Unternehmung Kontrollaufgaben

264 264 265 287 289 304 307 313

XIV

Inhalt

7.3 7.3.1 7.3.2 7.3.3 7.3.4 7.3.5 7.3.6 7.3.7 7.3.8 7.3.9

Die Datenbankanfragesprache (DRL) Die SELECT-Klausel (Projektion) Die FROM-Klausel (Ausgangstabelle) Die WHERE-Klausel (Selektion) Die GROUP BY-Klausel (Bilden von Untertabellen) Geschachtelte Anfragen Mengenoperationen in SQL Die ORDER BY-Klausel (Sortieren der Ergebnistabelle) Zusammenfassung Kontrollaufgaben

316 317 328 354 363 376 391 395 396 399

7.4 7.4.1 7.4.2 7.4.3

Die Datenmanipulationssprache (DML) Einfügen von Zeilen Ändern von Zeilen Löschen von Zeilen

403 403 406 408

7.5 7.5.1 7.5.2 7.5.3 7.5.4

Datensichten Motivation Vorteile von Sichten Probleme mit Sichten Änderungen auf Sichten

409 409 414 415 417

7.6

Die Datenkontrollsprache (DCL)

421

7.7

Die Speicherungsstrukturdefinitionssprache (SSL)

427

7.8

Datenschutz, Datensicherung und Datenkonsistenz

428

7.9

Kritische Würdigung von SQL-92

437

7.10

Charakteristika relationaler DBMS

439

7.11

Einbettung von SQL in Wirtssprachen (Embedded SQL)

442

7.12

Programmgeneratoren

446

7.13 7.13.1

Anfragebearbeitung und -Optimierung Anfragebearbeitung

449 449

7.13.2

Anfrageoptimierung

452

7.14

Zusammenfassung

456

7.15

Literatur

457

7.16

Kontrollaufgaben

458

8

SQL:1999

461

8.1

Struktur von SQL: 1999

461

8.2 8.2.1

Datentypen und Typkonstruktoren Vordefinierte Datentypen

463 463

Inhalt 8.2.2 8.2.3 8.2.4

XV Typkonstruktoren Individualisierte Datentypen (distinct data type) Benutzerdefinierte strukturierte Datentypen bzw. benannte Zeilentypen

467 480

Objektorientierte Konzepte in SQL: 1999 Beziehungsarten zwischen Vaterobjekten und eingebundenen Objekten in komplexen Objekten Objektidentität Datenabstraktion/Kapselung Vererbung Polymorphismus Einige Anmerkungen zu komplexen Objekten in SQL: 1999

483 484 490 495 508 513

8.3.7

Zusammenfassung

517

8.4

Trigger

519

8.5 8.5.1 8.5.2 8.5.3 8.5.4 8.5.5 8.5.6 8.5.7 8.5.8 8.5.9

Weitere Neuerungen im Überblick Sichten Benennung von SFW-Blöcken Rekursion Datenschutz und Datensicherheit On/ine Analytical Processing (OLAP) Sicherungspunkte SQL/MM (Multimedia-Unterstützung) SQL/MED (Management of External Data) Java Sprachanbindung

522 522 523 523 524 525 527 527 528 530

8.6

Literatur

532

9

Transaktionsverarbeitung und Fehlertoleranz

535

9.1 9.1.1 9.1.2 9.1.3 9.1.4

Transaktionsmanagement Probleme bei der Parallelarbeit auf der DB Das Transaktionskonzept Serialisierbarkeit Literatur

535 536 540 542 550

9.2 9.2.1 9.2.2 9.2.3 9.2.4 9.2.5 9.2.6 9.2.7

Synchronisationsverfahren Klassifikation Sperrverfahren Zeitstempelverfahren Optimistische Synchronisationsverfahren Synchronisation in SQL-92 TP-Monitor Literatur

550 550 551 565 566 571 573 576

8.3 8.3.1 8.3.2 8.3.3 8.3.4 8.3.5 8.3.6

481

516

XVI

Inhalt

9.3 9.3.1 9.3.2 9.3.3

Fehlertoleranz Fehler in Transaktionssystemen Maßnahmen zur Fehlerbehandlung Literatur

576 578 580 595

9.4 9.4.1 9.4.2 9.4.3 9.4.4

Geschachtelte Transaktionen Geschlossen geschachtelte Transaktion Offen geschachtelte Transaktion Entwicklungstransaktion Literatur

595 599 600 601 601

9.5

Kontrollaufgaben

602

Literatur

605

Sachverzeichnis

619

1

Einleitung und Ubersicht • ·

Eine sorgfältige Erhebung der Anforderungen, ihre Analyse und eine nachfolgende Modellbildung ist eine Grundvoraussetzung für den Entwurf einer effizienten Datenbank. Die während dieser Tätigkeiten durchzuführenden Aufgaben sind in der Regel komplexe, zeitaufwändige und somit auch kostenintensive Angelegenheiten. Dies ist darauf zurückzuführen, dass die geplante Datenbank als Datenspeicher für unterschiedlichste Anwendungen fungieren wird und die Anforderungen verschiedenster, oft sehr heterogener Benutzergruppen, erfüllen soll. Die Komplexität des Designvorganges ist des Weiteren darin begründet, dass die Entwurfsphase der Datenbank ganz am Anfang des Lebenszyklus der Datenbankanwendung steht und daher bereits in einer so frühen Phase neben allen bekannten Anforderungen alle zukünftig wichtigen Anforderungen an das System erahnt werden müssen, um in Entwurfsentscheidungen entsprechend einfließen zu können. Auf alle Fälle ist es notwendig, beim Entwurf einer Datenbank ausreichend technische Kompetenz zu besitzen und Sorgfalt walten zu lassen, da falsche Entwurfsentscheidungen oft starke Auswirkungen auf die Leistungsfähigkeit der Datenbank haben und später nur mit sehr hohem Aufwand korrigiert werden können. Analyse und Modellbildung für die Entwicklung einer Datenbankanwendung beginnen mit der Erstellung einer Machbarkeitsstudie (Durchführbarkeitsstudie). Ergibt diese Studie, dass der Einsatz eines Datenbanksystems zielführend ist, so erfolgt vorerst eine sorgfältige Anforderungserhebung und -analyse. Anforderungen werden in Anforderungsdokumenten festgeschrieben, die die Aufgabe haben, als Grundlage für die Erstellung einer gemeinsamen abstrakten Darstellung, einer Konzeptualisierung aller Daten (konzeptuelles Datenmodell), die eventuell in der Datenbank verwaltet werden, zu dienen. Für eine bestimmte Datenbankanwendung kann es unterschiedliche konzeptuelle Modelle geben, da unterschiedliche Entwerfer die Realität möglicherweise unterschiedlich sehen und ihre Schwerpunkte auf unterschiedliche Ereignisse legen oder zur Modellbildung verschiedene Konzepte verwenden können. Anforderungsanalyse und die Erstellung eines konzeptuellen Modells einer Datenbank sind systemunabhängige Aktivitäten. Darunter verstehen wir, dass es für diese Phasen des Datenbankentwurfes vollkommen unerheblich ist, welche Datenbanksoftware später zum Einsatz kommen wird. Die nächste Entwurfsphase wird als logisches Design bezeichnet und besteht aus der Transformation des konzeptuellen Datenmodells in ein Zielmodell, das so genannte Implementationsmodell oder auch das logische Datenmodell. Diese Aktivität ist bereits teilweise systemabhängig, da sie vom Datenmodell der ausgewählten Datenbanksoftware beeinflusst ist. Fast alle am Markt befindlichen Datenbankprodukte bieten die Funktionalität, mit einfachen Methoden die Beschreibung des logischen Datenmodells einer Datenbank zu implementieren, physische Optimierung am Implementationsmodell vorzunehmen und das physische Datenbankschema auf die Anwendungen abzustimmen. Dieser Vorgang wird in der Regel als physisches Design bezeichnet und führt zu einem physischen Datenmodell.

2

1 Einleitung und Übersicht

Der Begriff „Datenmodell" wurde jetzt bereits mehrmals erwähnt und es erscheint notwendig, auf diesen Begriff näher einzugehen (siehe auch unter 1.6). Unter einem Modell versteht man ein immaterielles Abbild einer Realität unter Verwendung vorgegebener Strukturierungsprinzipien. Ein Datenmodell ermöglicht es, für alle Anwendungen eine gemeinsame Basis zu schaffen und damit die Datenorganisation sämtlicher Anwendungen eines Unternehmens zu vereinheitlichen. Unter Verwendung der vom Datenbankmodell zur Verfügung gestellten Strukturierungsprinzipien ist vom Datenbankentwerfer während der Analyse und Modellbildung der Aufgaben des zu entwickelnden Datenbanksystems im einzelnen festzulegen: •

Was bedeuten die Begriffe des betrachteten Realitätsausschnittes? Welche Beziehungen bestehen zwischen Begriffen? Wie sind bestehende Daten strukturiert?

•

Welche gemeinsamen Eigenschaften kennzeichnen die Objekte, die mittels der eingeführten Begriffe benannt werden? Wie sind diese Eigenschaften beschrieben?

•

Welche Begriffe bilden zentrale Komponenten einer Anwendung und können zu Objekttypen oder Beziehungstypen zusammengefasst werden?

•

Welche konsistenzgewährleistenden Einschränkungen (Integritätsbedingungen) sind bekannt und können zur Vervollständigung der Datendefinition formuliert werden? Welche Operationen können auf Objekttypen ausgeführt werden, welche Zustände und Ereignisse sind bekannt, welche betrieblichen Vorgänge sollen modelliert werden?

Ein konzeptuelles Datenmodell wird verwendet, um eine gemeinsame abstrakte Beschreibung aller Daten, die eventuell in der Datenbank verwaltet werden, zu erreichen. Konzeptuelle Datenbankmodelle werden auch semantische Datenbankmodelle genannt, da sie die Mächtigkeit besitzen, einen Großteil der Semantik des zu modellierenden Realitätsausschnittes im Modell abzubilden. Im Gegensatz dazu stehen Implementationsmodelle oder logische Datenbankmodelle. Hierbei handelt es sich um Modelle, die von Datenbankprodukten als Schnittstelle zum Nutzer hin zur Verfügung gestellt werden. Zielführend ist es jedoch stets, für konzeptuelle Modellbildung ein mächtiges semantisches Datenbankmodell mit einer Vielzahl von Strukturierungsmöglichkeiten einzusetzen und sich nicht bereits vorab zwingend für ein bestimmtes logisches Datenbankmodell zu entscheiden. Während ein Datenmodell ausschließlich die Beschreibung der Struktur der Daten enthält, bietet ein Funktionsmodell Mechanismen zur Modellierung von betrieblichen Abläufen und Prozessen, die die Abläufe steuern. Einen Schritt weiter gehen integrierte Modelle. So wird z.B. in integrierten Objektmodellen die strukturorientierte und die funktionsorientierte Sichtweise auf ein betriebliches Informationssystem in einem einheitlichen Modell integriert. Objektmodelle bieten darüber hinaus auch noch die Möglichkeit, für Objekte bestimmte Zustände und Bedingungen für Zustandsübergänge zu formulieren. Der Entwurf einer Datenbank ist gewöhnlich ein iterativer Prozess, der oft auf „trial and error" beruht. In der wissenschaftlichen Literatur gibt es keine einheitliche Meinung darüber, wie der Entwurfsprozess einer Datenbank exakt in einheitliche Teilaktivitäten gegliedert werden kann. Vielmehr ist es der Fall, dass einzelne Entwurfsaktivitäten nicht streng sequentiell abgearbeitet werden, sondern eng miteinander verzahnt sind. In der gängigen Praxis hat sich eingebürgert, den Designvorgang in vier Hauptaktivitäten zu gliedern:

1 Einleitung und Übersicht

3

1. Anforderungserhebung und -analyse 2. Konzeptuelle Modellbildung 3. Logischer Entwurf 4. Implementationsphase (physisches Design) Begleitend zu den Entwurfsaktivitäten sollen ständig Verifikations- und Validationstechniken eingesetzt werden. Das bedeutet, dass das Ergebnis eines Entwurfsschrittes auf Korrektheit geprüft, also verifiziert werden soll, bzw. dass es validiert wird, d.h. es sollte geprüft werden, ob es als Spezifikation auch tatsächlich alle Anforderungen korrekt und vollständig wiedergibt. Diese phasenbegleitenden Aktivitäten zur Qualitätssicherung sind meist bewährte Methoden aus dem Bereich des Software Engineerings. Hier können zum Einsatz kommen: 1. Formale Verifikation Die eingesetzten Datenbankmodelle basieren meist auf einer klaren mathematischen Semantik, die es ermöglicht, sowohl manuelle als auch computerunterstützte Verfahren zur formalen Spezifikation und nachfolgender Verifikation einzusetzen. 2. Experimentelles Prototyping Vor der endgültigen Implementierung sollen potentielle Nutzer unter Verwendung von realen Daten an einem eingeschränkten Prototyp die Richtigkeit des Systementwurfs evaluieren. 3. Statistisches Testen Unter Verwendung künstlich erzeugter oder realer Testdaten kann am Prototyp eine Überprüfung der Richtigkeit des Entwurfs mit Hilfe statistischer Testverfahren erfolgen. Ähnlich wie die Verifikation und die Validation ist auch die Dokumentation des Entwurfsprozesses sowie die Erstellung der Dokumentation des Datenbanksystems eine Aktivität, die parallel zum gesamten Datenbankentwicklungsprozess erfolgen sollte. Eine gute Dokumentation ist für den laufenden Betrieb und die nachfolgende Wartung der Datenbank von großer Bedeutung, da die in dieser Phase anfallenden Kosten die ursprünglichen Entwurfskosten in der Regel übersteigen. Es ist ratsam, schon in der Entwurfsphase durch saubere Dokumentation aller Entwurfsentscheidungen für die Möglichkeit einer leichten Modifikation des Datenbanksystems vorzusorgen. In Abbildung 1.1 zeigen wir den Entwicklungszyklus einer Datenbankanwendung. Er beginnt mit der Durchführbarkeitsstudie, einer Vorstudie, die Kosten- und Effizienzüberlegungen, Entscheidungen zu verschiedenen Systemkomponenten und weitere Grundlagenentscheidungen enthält, aus denen hervorgeht, dass der Einsatz eines Datenbanksystems das richtige technische Realisierungskonzept für die Problemstellung darstellt. Während der Anforderungserhebung und -analyse werden in Zusammenarbeit mit Benutzern Tätigkeitsfelder und zu lösende Probleme des Informationssystems analysiert und in einem Anforderungsdokument zusammengefasst. Dem folgt die eigentliche Modellbildung, die zentrale Aufgabe während des Datenbankentwurfs. Mittels Tools kann im Rahmen des Entwurfsprozesses ein vereinfachter, ineffizienter Prototyp der gewünschten Datenbank werkzeugunterstützt erstellt und

1 Einleitung und Übersicht

Anforderungsdokument

Datenmodell

Physischer Entwurf

Abb. 1.1: Entwicklungszyklus

einer

Datenbankanwendung

vom Benutzer evaluiert werden. Herrscht Konsens über den Systementwurf, folgt die Implementation der Datenbank und nach einer Testphase der Datenbankeinsatz. Eine nachfolgende Wartungsphase umfasst neben der Fehlerbehandlung auch die Anpassung der Datenbank an veränderte Bedingungen. Jede der Hauptphasen des Datenbankentwurfsprozesses besteht wiederum aus mehreren unterschiedlichen Schritten, von denen jeder für sich allein betrachtet in der Literatur mehr oder weniger gut dokumentiert ist. Aus mehreren Gründen ist es jedoch nicht einfach, eine systemunabhängige, durchgängige Methode für alle vier Hauptaktivitäten und die involvierten Schritte zu entwickeln: •

Unterschiedliche Entwurfsphasen verwenden oft verschiedene Datenmodelle. Eine durchgängige Methode muss daher Abbildungsvorschriften von Modell Α nach Modell Β beinhalten.

•

Jedes Datenbankmodell unterstützt möglicherweise unterschiedliche Modellierungskonzepte und -mechanismen, und es ist schwierig, die unterschiedlichen Konzepte in verschiedenen Modellen zu vereinheitlichen.

1 Einleitung und Übersicht •

5

Logischer Entwurf und physisches Design der Datenbank sind systemabhängig. Während der logische Entwurf vom Typ der ausgewählten Datenbanksoftware abhängig ist, ist das physische Design in vielen Fällen sogar produktabhängig. Die Bindung an bestimmte Produkte macht es fast unmöglich, für die späten Phasen der Datenbankentwicklung allgemein gültige Aussagen zu treffen und eine einheitliche Entwurfsmethode vorzuschlagen.

Abb. 1.2: Phasen des

Datenbankentwurfs

Beim Entwurf einer Datenbank müssen zumindest zwei unterschiedliche Sichtweisen auf ein Anwendungssystem berücksichtigt werden. Wie in Abbildung 1.2 dargestellt ist, besteht der Entwurf einer Datenbank vorerst aus zwei parallelen Aktivitäten. Die beiden Aktivitätsstränge repräsentieren zwei unterschiedliche Sichtweisen auf die in der Datenbank abzubildende Realität. Die eine Sichtweise bezieht sich hauptsächlich auf die Struktur der Daten. Die zweite Sichtweise sieht ein Datenbanksystem aus dem Blickwinkel der Anwendungen und stellt die gewünschte Funktionalität des Systems in den Vordergrund. Abhängig davon, welche der beiden Sichtweisen favorisiert wird, bezeichnet man den Datenbankentwurfsvorgang als eher „strukturorientiert" oder als eher „funktionsorientiert". Beide Aspekte sollten bei der Entwicklung einer Datenbank jedoch gleichrangige Bedeutung besitzen, was der Forderung nach einer integrierten Entwurfsmethode eindringlich Nachdruck verleiht.

1 Einleitung und Übersicht

6

Der Entwurf einer Datenbank wird von einem Datenbankentwurfsteam oft in Zusammenarbeit mit Domänenexperten durchgeführt. In der Folge wollen wir auf die durchzuführenden Aktivitäten im Rahmen der Datenbankentwicklung ein wenig genauer eingehen.

1.1

Anforderungserhebung und -analyse

Die Erhebung und Analyse der Anforderungen an die Datenbank kann als Spezialfall einer generellen Anforderungsanalyse beim Softwareentwurf betrachtet werden. In dieser Phase erfolgt die Abgrenzung des Anwendungsbereiches der Datenbank. Die Anforderungserhebung und -analyse orientiert sich vor allem am Informationsbedarf der zukünftigen Nutzer. Sie beginnt mit der Befragung ausgewählter Nutzer, der Niederschrift ihrer Anforderungen und der Analyse des Informationsbedarfs. Während dieser Entwurfsphase erstellt der Datenbankentwerfer ein Anforderungsdokument, in dem sowohl Anforderungen an die Struktur der Daten, Bearbeitungsanforderungen als auch Anforderungen, die an das Eintreten bestimmter Ereignisse geknüpft sind, eingetragen werden. Jeweils abhängig vom betrachteten Sachverhalt, lassen sich die folgenden unterschiedlichen Teilschritte bei der Erstellung eines Anforderungsdokumentes feststellen: •

Strukturanalyse

Die benötigten Daten und Informationseinheiten (gekennzeichnet durch eng miteinander in bezug stehende Daten) werden erarbeitet. Danach folgen ihre Gruppierung in Klassen, die Bestimmung ihrer Eigenschaften und die Aufstellung von Beziehungen zwischen Informationseinheiten. •

Funktionsanalyse

Die Funktionssicht eines Anwendungssystems kann auf unterschiedlichen Abstraktionsebenen betrachtet werden. Oberste Verdichtungsstufe sind Geschäftsprozesse während elementare Bearbeitungsfunktionen den höchsten Detaillierungsgrad einer entsprechenden Vorgangskette beschreiben. •

Transaktionsanalyse

Sofern bereits bekannt, werden die Bearbeitungsanforderungen der wichtigsten Transaktionen beschrieben. Dazu gehört ihr Ein- und Ausgabeverhalten, die Häufigkeit ihrer Anwendung sowie Querverweise auf ihre Bezugsdaten. Viele der wichtigen Datenbankanfragen und Datenmanipulationsoperationen (Transaktionen) sind bereits zum Entwurfszeitpunkt der Datenbank bekannt. Während der frühen Phasen im Entwurfslebenszyklus einer Datenbank gilt es, diese Sachverhalte genau zu spezifizieren und die funktionalen Eigenschaften zu Grunde liegender Transaktionen zu analysieren. Die Analyse der möglichen Transaktionen ist für die Erstellung des konzeptuellen Datenmodells nur von geringer Bedeutung liefert aber für den physischen Entwurf und die physische Organisation der Datenbank wertvolle Informationen. Die Analyse der Bearbeitungsanforderungen und der Entwurf des physischen Datenbankschemas sind systemabhängige Aufgaben, die oft auch durch die Auswahl eines bestimmten

1.2 Konzeptuelle Modellbildung

7

Datenbankproduktes beeinflusst sind. Im Rahmen dieses Buches werden wir auf Bearbeitungsanforderungen und den physischen Entwurf eines Datenbankschemas aus diesem Grund nur am Rande eingehen. Angesichts der Menge der erhobenen Eigenschaften der Realität ist bei der Anforderungserhebung und -analyse Rechnerunterstützung wünschenswert oder sogar notwendig. Das Ergebnis der Anforderungsanalyse ist eine Anzahl individueller Anforderungsdokumente. Jedes Dokument spezifiziert die Anforderungen einer bestimmten Benutzergruppe und besteht hauptsächlich aus Anforderungen an die Struktur der Daten sowie aus allgemeinen Anforderungen zur Realisierung der Geschäftsprozesse des betrachteten Unternehmens. Die individuellen Anforderungen der einzelnen Nutzergruppen können sehr unterschiedlich sein. Alle Anforderungen zusammen repräsentieren das unternehmensweite Anforderungsdokument. Der Vorgang der Anforderungserhebung und -analyse ist völlig systemunabhängig. In Kapitel 2 dieses Buches schildern wir unterschiedliche Techniken der Anforderungserhebung und zeigen, wie unterschiedliche Formen von Anforderungen im Anforderungsdokument dargestellt werden können. Ebenso werden in diesem Kapitel die wesentlichen Unterschiede zwischen Dateiverwaltungssystemen und Datenbanksystemen dargestellt, um im Rahmen einer Vorstudie festzustellen, ob ein Datenbanksystem oder ein Dateisystem zur Realisierung der Anwendung eingesetzt werden soll.

1.2

Konzeptuelle Modellbildung

Die Hauptaufgabe der konzeptuellen Modellbildung ist es, alle individuellen Anforderungen aus den Anforderungsdokumenten in einer einheitlichen Spezifikation zu repräsentieren. Dazu bedient man sich der Beschreibungsmittel eines semantischen Datenmodells. Das Ergebnis der konzeptuellen Modellbildung ist ein semantisches oder konzeptuelles Datenbankschema, das systemunabhängig und allgemein gehalten ist und daher in den meisten Fällen nicht direkt in einem Datenbanksystem implementiert werden kann. Um ein konzeptuelles Datenmodell zu entwerfen, reicht es nicht aus, alle Anforderungen zu sammeln und direkt im konzeptuellen Schema zu repräsentieren. Die Sachlage ist um einiges komplizierter, da einerseits Benutzer gleiche oder ähnliche Dinge der Realität unterschiedlich sehen und somit unterschiedlich im Anforderungsdokument beschreiben und andererseits unterschiedliche Entwerfer denselben Sachverhalt unterschiedlich modellieren. Es gibt noch weitere Konfliktursachen, auf die wir in Kapitel 3 dieses Buches näher eingehen werden. Folgende Vorgehensweise bei der Erstellung eines konzeptuellen Datenmodells ist zielführend: Zuerst wird jedes individuelle Anforderungsdokument in ein semantisches Schema transformiert. Dieses Schema repräsentiert für jede Anwendergruppe eine ihr gemäße Sicht auf die Datenbasis. Ein Schema, das eine lokale Sicht beschreibt, wird auch als externes Datenbankschema oder externe Sicht bezeichnet. In einem zweiten Schritt werden die unterschiedlichen Sichten zu einem konzeptuellen Schema zusammengefasst, wobei Überlappungen konsolidiert, Konflikte zwischen externen Schemata und Homonyme (ein und derselbe Bezeichner für unterschiedliche Sachverhalte) sowie Synonyme (ein Sachverhalt der Realität trägt unterschiedliche Bezeichner) in bezug auf die Benennungen bereinigt werden. Diesen Vorgang bezeichnet man auch als Sichtenintegration.

8

1 Einleitung und Übersicht

In manchen Entwurfsprojekten ist man sich schon im vorhinein darüber im klaren, dass als Ergebnis des Datenbankentwurfs eine relationale Datenbank entstehen soll. Für kleinere und übersichtliche Anwendungen ist es möglich, ohne Verwendung eines semantischen Datenmodells ein relationales Datenbankschema direkt zu entwerfen. Die relationale Datenbanktheorie kennt den Vorgang der Normalisierung, mit dem ein relationales Datenmodell entworfen werden kann, die Güte eines Entwurfs überprüft und ein relationales Datenbankmodell, falls notwendig, verbessert werden kann. Obwohl das Verfahren der Normalisierung ausschließlich für relationale Datenbanken entwickelt wurde und daher in unserer Klassifikation eine systemabhängige Tätigkeit darstellt, reihen wir dieses Modellierungsverfahren unter konzeptuelle Modellbildung ein, da es möglich ist, dieses Konzept in leicht abgeänderter Form im Kontext anderer Datenmodelle ebenfalls anzuwenden. Kapitel 3 dieses Buches ist ausschließlich der konzeptuellen Modellbildung gewidmet. Dort werden wir uns hauptsächlich mit dem wichtigsten Vertreter der semantischen Datenmodelle, dem Entity-Relationship-Modell (ERM) und seinen Erweiterungen beschäftigen. Die ausschließliche Verwendung des ERM zur konzeptuellen Modellbildung bevorzugt die strukturorientierte Sicht auf die Datenbankanwendung. Die Funktionssicht eines Anwendungssystems kann unter Verwendung der Modellierungskonzepte des ERM nicht dargestellt werden. Da die funktionalen Aspekte beim Datenbankentwurf jedoch nicht vernachlässigt werden dürfen, stellen wir nach der rein statischen Modellbildung (strukturorientierte Modellbildung) eine Entwurfsmethode vor, die sowohl die statischen als auch die funktionalen Aspekte einer Anwendung beim Entwurf eines konzeptuellen Datenbankschemas berücksichtigt. Obwohl diese Methode viele Vorteile gegenüber einer rein statischen Analyse besitzt, ist sie nur als eine Art Zwischenschritt hin zur Verwendung integrierter Objektmodelle zu sehen, da Verhaltensfragen und Ereignisabläufe mit ihr nur bedingt modelliert werden können. In Kapitel 3 dieses Buches schlagen wir dann als dritte Entwurfsmethode die Verwendung integrierter Objektmodelle vor, die auch die dynamischen Aspekte einer Datenbankanwendung in ein konzeptuelles Modell integrieren. Die Entwicklung von Methoden und Techniken zum konzeptuellen Datenbankentwurf ist noch nicht abgeschlossen. Des Weiteren kommen in diesem Bereich auch „allgemeine" Methoden der Systemplanung und -analyse zum Einsatz und es ist nicht möglich, eine genaue Abgrenzung zwischen den Methoden zum konzeptuellen Datenbankentwurf und denen einer allgemeinen Systemplanung vorzunehmen. Als abschließende Diskussion dieses Themenkreises weisen wir auf aktuelle Trends hin, wie z.B. die Entwicklung unternehmensweiter Datenmodelle aufgrund der Analyse bestehender Geschäftsprozesse. In Kapitel 3 behandeln wir noch ausführlich Methoden der Sichtenintegration und die Methode des formalen Datenbankentwurfs unter Verwendung der Normalisierungstheorie.

1.3

Logischer Entwurf

Ein konzeptuelles Datenmodell kann nur in den wenigsten Fällen direkt in das Datenbankmodell des zur Verfügung stehenden Datenbanksystems implementiert werden. Der logische Entwurf einer Datenbank hat die Übersetzung des semantischen Schemas der konzeptuellen Modellbildung in ein logisches Datenmodell zur Aufgabe. Das Ergebnis eines logischen Entwurfs sollte möglichst nahe der Datendefinitionssprache (data definition language, DDL) des ausgewählten Datenbankproduktes sein.

1.4 Implementationsphase

9

In Kapitel 4 dieses Buches werden wir uns bei den logischen Datenmodellen auf das relationale Datenmodell beschränken und zeigen, wie ein ERM in ein relationales Datenmodell transformiert werden kann.

1.4

Implementationsphase

Liegt das logische Datenmodell vor, so kann unter Verwendung der Datendefinitionssprache des eingesetzten Datenbanksystems das Datenmodell implementiert und die Datenbank erstellt werden. Datenbankdefinitionssprachen unterscheiden sich von Produkt zu Produkt in Syntax, Semantik und Benutzerschnittstelle. Jedoch ist ihre Funktionalität immer ähnlich. Sobald die Relationenschemata angelegt sind, wird der Datenbankadministrator die Zugriffsrechte für einzelne Nutzer (-gruppen) festlegen und möglicherweise auch virtuelle Tabellen (views) anlegen, um für bestimmte Benutzer den Zugriff auf sensitive Daten zu verhindern oder aber auch, um komplexere Abfragen zu vereinfachen. Viele Datenbankprodukte lassen ihr Leistungsverhalten optimieren. Das Dilemma der Benutzer und Systemadministratoren besteht jedoch oft darin, die Werte der Einstellparameter festlegen zu müssen, ohne tiefere Kenntnisse von der Systemrealisierung zu besitzen. Oft ist es notwendig, die gewählten Einstellparameter nach einer gewissen Probephase und nach Beobachtung des Leistungsverhaltens der Datenbank zu korrigieren. Das Erzielen der gewünschten Antwortzeit ist auch oft eine Gratwanderung zwischen einer guten Antwortzeit für bestimmte Transaktionen und einem akzeptablen Arbeiten aus der Sicht der Gemeinschaft aller Nutzer. Während der Implementationsphase legt der Datenbankadministrator Primärindizes an, um Eindeutigkeit zu gewährleisten oder Sekundärindizes, um Zugriffspfade vorzubereiten und damit die Antwortzeit bestimmter Abfragen zu beschleunigen. In dieser Phase werden auch die Anwendungsprogramme geschrieben, die die geforderte Funktionalität der Datenbankanwendungen gewährleisten. Der letzte Schritt vor der ersten Inbetriebnahme der Datenbank besteht im Laden oder Erfassen der Daten. In den meisten Fällen sind bereits Datenbestände vorhanden, die noch in ein bestimmtes Datenformat konvertiert werden müssen. Die meisten Datenbankprodukte bieten dazu Hilfsprogramme an. Sobald die Daten geladen sind und nach einer Testphase kann mit dem Benutzerbetrieb begonnen werden. Danach beginnt bereits die Wartungsphase, in der versucht wird, etwaige Entwurfsfehler zu korrigieren bzw. die Datenbank aufgrund einer sich geänderten Realität für neue Anforderungen zu adaptieren. Auf die Wartungsphase und die damit in Zusammenhang stehenden Methoden des Reverse- bzw. Re-Engineerings von Datenbanken kann in diesem Buch aus Platzgründen nicht eingegangen werden. Abbildung 1.3 zeigt in graphischer Form den Zusammenhang zwischen den unterschiedlichen Entwurfsphasen und gibt exemplarisch Modelle an, die die Aktivitäten während dieser Phasen unterstützen.

10

1 Einleitung und Übersicht

Abb. 1.3: Entwurfsphasen,

1.5

Daten- und

Datenbankmodelle

Allgemeine Datenbankbegriffe

Um zu einem ersten einheitlichen Verständnis der in diesem Buch verwendeten Terminologie zu gelangen, werden wir in diesem Abschnitt häufig verwendete Begriffe voneinander abgrenzen und in kurzer Form erklären. Eine detaillierte Definition der Begriffe folgt in den Kapiteln, in denen die entsprechenden Themengebiete genauer behandelt werden. Datenmodell1

Hierbei handelt es sich um eine formale Beschreibung des zu modellierenden Ausschnittes der Realität, wobei die strukturorientierte Betrachtungsweise dominiert. Gegenstand der Betrachtung sind die Struktur der Daten, Beziehungen innerhalb der Daten, Klassenbildung, gültige Wertebereiche und weitere Integritätsbedingungen. 1 Leider ist der Begriff Datenmodell semantisch überladen. Einerseits wird damit das mit den gegebenen Mitteln eines spezifischen Werkzeuges zusammengesetzte Modell von etwas Gegebenen bezeichnet, andererseits aber eben auch das Werkzeug selber, also die Beschreibung der grundlegenden Konzepte, mit deren Hilfe das „Vorbild" modelliert werden kann. Hier wird der Begriff Datenmodell immer im eigentlichen Sinne des Wortes verwendet, also im Sinne der ersten Definition. Ist das Werkzeug gemeint, spezifizieren wir den Begriff weiter, sprechen also beispielsweise von dem relationalen Datenmodell.

1.5 Allgemeine Datenbankbegriffe

11

Funktionsmodell Ein Funktionsmodell beschreibt eine Datenbankanwendung aus der Sicht der Datenbankfunktionen und der involvierten Prozesse auf unterschiedlichen Abstraktionsniveaus. Auf dem obersten Niveau werden Geschäftsprozesse betrachtet, die im Einklang mit den betrieblichen Zielen einen oft komplexen Ablauf, von seiner Entstehung bis zu seiner Beendigung, beschreiben. Ist ein hoher Detaillierungsgrad erwünscht, so erfolgt eine Zerlegung der einzelnen Abläufe in Teilfunktionen bzw. bis hin zu elementaren Bearbeitungsfunktionen. Funktionsmodelle unterstützen die funktionsorientierte Sicht auf ein Anwendungssystem. Integriertes Objektmodell In einem integrierten Objektmodell findet eine gemeinsame Betrachtung von Daten und der auf den Daten ausführbaren Funktionen statt. Neben der Modellierung von statischen Strukturen erfolgt hier auch die Verhaltensmodellierung. Dabei werden die nötigen Abläufe und Ereignisse beschrieben, die Objekte des Informationssystems zur Veränderung ihres Zustandes veranlassen. Datenbank Unter einer Datenbank versteht man einen logisch integrierten Datenbestand, der unter Verwendung eines DBMS verwaltet wird und mit Hilfe eines Datenmodells beschrieben ist. Datenbankmodell Ein Datenbankmodell besteht aus einer vorgegebenen Menge genau festgelegter Modellierungskonzepte, mit denen ein Datenmodell einer Anwendung erstellt werden kann. Jedes DBMS unterstützt ein Datenbankmodell. Das heute gebräuchlichste Datenbankmodell ist das relationale Datenmodell. Datenbankschema Ein Datenbankschema ist eine maschinell verarbeitbare Formulierung eines Datenmodells. DBMS Ein DBMS (DBMS, auch Datenbanksoftware) ist eine Sammlung von Programmen zur Erzeugung und Instandhaltung einer Datenbank. Die Hauptaufgabe eines DBMS besteht in der Verwaltung der Daten, der Sicherung der Integrität, der Gewährleistung von Systemsicherheit und Fehlertoleranz und der Synchronisation konkurrierender Zugriffe im Mehrbenutzerbetrieb. Datenbanksystem Ein Datenbanksystem besteht aus einem DBMS und einer konkreten Datenbank. Die Formulierung des Schemas dieser Datenbank ist das Ziel des Datenbankentwurfsprozesses. Involvierte Berufsgruppen Datenbankdesigner sind für den Entwurf einer Datenbank verantwortlich. In den frühen Entwurfsphasen werden sie durch Systemanalytiker unterstützt. Systemanalytiker erheben die Benutzeranforderungen und spezifizieren die Funktionalität von Datenbankoperationen. Systemanalytiker arbeiten eng mit den Datenbankprogrammierern zusammen. Diese erstellen aufgrund der Spezifikation der Systemanalytiker Programme, die dann die erhobenen Benutzeranforderungen erfüllen sollen. Datenbankadministratoren übernehmen die technische Verwaltung des Datenbanksystems. Sie sind für die Abstimmung von logischem Datenmodell und physischer Datenorganisation verantwortlich, legen Benutzer an, vergeben Zugriffsrechte und führen die Datensicherung durch.

12

1 Einleitung und Übersicht

Datenbanknutzer Bei den eigentlichen Nutzern des Datenbanksystems kann man schließlich auch unterschiedliche Klassen feststellen. Gelegentliche Nutzer benutzen das Datenbanksystem eher selten. Sie haben in den meisten Fällen unterschiedliche aber oft recht komplexe Anfragen an die Datenbank, die oft von Datenbankprogrammierern vorbereitet werden. Bei gelegentlichen Nutzern handelt es sich meist um Mitarbeiter aus dem mittleren bis höheren Management einer Organisation. Der Großteil der Nutzer greift jedoch auf vorgefertigte Transaktionen zurück (parametrische Nutzer), die ausschließlich auf einem vordefinierten Datenbereich operieren. Die Transaktionen werden wiederholt in nicht veränderter Form aber mit sich ändernden Eingabeparametern ausgeführt. Ein Beispiel für diese Kategorie von Nutzern sind z.B. Schalterbeamte in Banken, Reisebüromitarbeiter an Flugreservierungssystemen oder Autovermieter. Erfahrene Benutzer haben meist recht komplexe Anforderungen an die Datenbank und sind im Umgang mit dem interaktiven Teil der Datenbankabfragesprache geübt. Sie sind ständig darauf bedacht sich weiterzubilden und besitzen Detailwissen über die Struktur der Datenbank. Oft haben sie auch Programmierkenntnisse. Datenbanksprache Die Datendefinitionssprache (data definition language, DDL) wird zur Definition des logischen Schemas einer Datenbank verwendet. Die Datenmanipulationssprache (data manipulation language, DML) unterstützt Kommandos für die Durchführung von Abfrage-, Einfüge-, Löschund Datenveränderungsoperationen. Es gibt Systeme, in denen die DML in eine Abfragesprache (data retrieval language, DRL) und die eigentliche Manipulationssprache gegliedert ist. Des Weiteren existieren DBMS, die über DDL und DML hinaus noch über eine weitere Subsprache zur Definition des internen Datenbankschemas (storage definition language, SDL) oder über eine Sichten-Definitions-Sprache (view definition language, VDL) zur Definition externer Datenbanksichten verfügen. Gelegentlich ordnet man auch noch die Vergabe von Zugriffsrechten einer eigenen Sprache (data control language, DCL) zu. Transaktion Darunter versteht man eine Folge von Datenbankoperationen, die logisch eine Einheit bilden und als Einheit vollständig und fehlerfrei ausgeführt werden müssen. Können sie das nicht, muss das DBMS die von der Transaktion durchgeführten Änderungen zurücksetzen.

1.6

Zusammenfassung

Der Entwurf einer Datenbank ist ein iterativer Vorgang, der aus mehreren eng miteinander verzahnten Teilaktivitäten besteht. Er beginnt mit der Erstellung einer Durchführbarkeitsstudie und einer nachfolgenden sorgfältigen Anforderungserhebung und -analyse. Daran schließt sich die konzeptuelle Modellbildung an, die eine Konzeptualisierung aller vom DBMS verwalteten Daten zum Ziel hat. Die nächste Phase besteht aus dem logischen Entwurf - einer Abbildung des konzeptuellen Datenmodells in das Zielmodell. Bevor das Datenmodell und die Anwendungsprogramme implementiert werden, soll die Güte des Entwurfs anhand eines Prototypen evaluiert werden. Nach der Implementation und einer Testphase kommt es zum Datenbankeinsatz an den unmittelbar die Wartungsphase anschließt. Begleitend zu allen Phasen des Entwurfs sollen Verifikations- und Validationstechniken zum Einsatz kommen und alle Entwurfsentscheidungen vollständig dokumentiert werden.

13

1.7 Literatur

1.7

Literatur

Zur Beschreibung einer sinnvollen Vorgehensweise für den Datenbankentwurf und der Beschreibung des Entwicklungszyklus einer Datenbank wird in der Literatur auf Vorgehensmodelle für den Softwareentwicklungsprozess zurückgegriffen. Die meisten dieser Ansätze gehen auf Boehm [Boeh76] zurück, der die Phasen Analyse, Design, Implementierung, Test und Wartung vorschlägt. Die Phasen müssen sequentiell durchlaufen werden, und jede Phase endet mit der Erstellung eines Abschlussberichtes. In den frühen Versionen dieses als Wasserfallmodell bekannten Ansatzes waren Rückkopplungen zwischen aufeinanderfolgenden Entwicklungsphasen noch nicht vorgesehen. Als eine Erweiterung des Wasserfallmodells wurde 1986 wiederum von Boehm [Boeh86] das Spiralmodell vorgeschlagen, das eine iterative Vorgehensweise beinhaltet, in der die unterschiedlichen Entwurfsphasen mehrere Male durchlaufen werden. Schleifen im Entwicklungsprozess werden immer dann notwendig, wenn Anforderungen sich nachträglich verändern oder wenn durchgeführte Entwicklungsschritte nicht zu zufrieden stellenden Ergebnissen geführt haben. Ein Beispiel für ein Vorgehensmodell, das Entwicklungszyklen für den gesamten Entwicklungsprozess vorsieht, ist die prototypingorientierte Softwareentwicklung, wie sie z.B. in [PoB196] vorgeschlagen wird. Vorschläge für weitere Phasenmodelle, insbesondere solche zur objektorientierten Entwicklung von Informationssystemen, können aus den Büchern entnommen werden, die in den Quellenangaben zu Kapitel 2 und Kapitel 3 angeführt sind. Bücher bzw. Übersichtsartikel, die den früheren Phasen im Lebenszyklus einer Datenbank entsprechend Raum widmen, sind in der Datenbankliteratur nicht sehr zahlreich vorhanden. Empfehlenswerte Ausnahmen sind z.B. [BaCN92], [LaLo95], [MaDL87], [Teor98] oder [NaPe92]. Von besonderer Bedeutung für die Wirtschaftsinformatik sind u.a. [BÖFP96], [MBKPOO], [MMM093], [FeSi98], [Rauh90] oder [RaSt97], Zu den Begriffen „Modell", „Modellbildung" und „Daten" siehe [LeHM95],

1.8 Aufgabe 1.1:

Kontrollaufgaben Motivation für die Modellbildung

Warum besitzen Analyse und Modellbildung im Rahmen der Entwicklung einer Datenbankanwendung so große Bedeutung? Geben Sie Beispiele für die Wichtigkeit einer unternehmensweit konsolidierten Datenbasis an. Aufgabe 1.2:

Aktivitäten beim Datenbankentwurf

Nennen Sie die Hauptaktivitäten sowie alle Ihnen bekannten begleitenden Aktivitäten, die im Rahmen des Entwurfs einer Datenbank durchgeführt werden sollen. Welche weiteren Phasen sind noch im Entwurfszyklus einer Datenbank enthalten? Aufgabe 1.3:

Systemabhängige und -unabhängige Entwurfsphasen

Welche der Entwurfsphasen einer Datenbank sind systemunabhängig, welche sind systemabhängig, und welche Phasen sind durch den Einsatz bestimmter Datenbankprodukte bestimmt (produktabhängig)?

14

1 Einleitung und Übersicht

Aufgabe 1.4: Abgrenzung wichtiger Entwurfsphasen Grenzen Sie die Entwurfsphasen „konzeptuelle Modellbildung" und „logisches Design" voneinander ab. Geben Sie Modelle an, die in diesen Phasen eingesetzt werden können. Aufgabe 1.5: In die Datenbanknutzung involvierte Berufsgruppen Nennen Sie unterschiedliche Berufsgruppen, die in die Erstellung und Nutzung einer Datenbank involviert sind. Aufgabe 1.6: Abgrenzung wichtiger Datenbankbegriffe Grenzen Sie die Begriffe Datenmodell, Datenbankmodell, Datenbank, Datenbankschema, Datenbanksystem und DBMS voneinander ab.

2

Anforderungserhebung und -analyse

Der Realisierung einer Datenbankanwendung geht zuallererst eine Durchführbarkeitsstudie (Vorstudie) voraus, in der geklärt werden muss, ob der Einsatz eines DBMS zielführend ist, oder ob die Anwendung unter Verwendung eines anderen technischen Realisierungsmittels erstellt werden soll. Bevor diese Frage geklärt werden kann, ist es notwendig, zumindest einen Teil der Nutzeranforderungen zu erheben und einer ersten Analyse zu unterziehen. Während der Anforderungserhebung und -analyse werden in Zusammenarbeit mit den zukünftigen Nutzern Tätigkeitsfelder und zu lösende Probleme des Informationssystems analysiert und in einem Anforderungsdokument niedergeschrieben. Eine wesentliche Voraussetzung für eine erfolgreiche Anforderungserhebung und -analyse ist ein gemeinsames Vorgehen von Systemanalytikern und ausgewählten Nutzervertretern (partizipative Systemanalyse), und damit verbunden eine starke Einbindung der vom Systemeinsatz Betroffenen am eigentlichen Entwicklungsprozess. Dies empfiehlt sich aus folgenden Gründen: •

Der partizipative Systemansatz führt bei den zukünftigen Anwendern zur Akzeptanzsteigerung, da sie unmittelbar in den Entwurfsprozess eingebunden sind und Entwurfsentscheidungen aktiv mitbestimmen können.

•

Das Fachwissen der Anwender fließt in Entwurfsentscheidungen ein. Expertenwissen muss nicht extern eingekauft werden.

•

Die Kommunikation zwischen Systemanalytikern und Anwendern wird vereinfacht.

Anforderungen an ein Datenbanksystem können auf verschiedene Art und Weise klassifiziert werden. Mögliche Klassifikationskriterien für Anforderungen sind z.B. die Benutzergruppe (Programmierer, Sachbearbeiter, Top-Management, usw.), die sie aufgestellt hat oder der Grad der Abhängigkeit einer Anforderung von einem bestimmten System (Betriebssystem, Informationssystem, Kommunikationssystem). Klassifiziert man nach der Art der Anforderung, kann man zumindest vier Arten von Anforderungen unterscheiden: •

Informationsanforderungen

Hierunter fallen alle statischen Informationsbeschreibungen, welche das betreffende Datenbanksystem im späteren Betrieb verwalten wird. Informationsanforderungen umfassen z.B. Angaben über Daten, Realwelt-Objekte und deren Typen, die Daten charakterisierenden Eigenschaften bzw. Attribute und deren Wertebereiche, Beziehungen und Abhängigkeiten zwischen Daten und Objekten sowie allgemeine Integritätsbedingungen, über welche die Konsistenz einer Datenbank definiert wird.

2 Anforderungserhebung und -analyse

16 •

Funktionale Anforderungen Sie beschreiben betriebliche Vorgänge auf unterschiedlichen Verdichtungsstufen. Oberste Verdichtungsstufe und damit Ausgangspunkt der Betrachtung sind Geschäftsprozesse, die einen komplexeren betrieblichen Ablauf von seiner Entstehung bis hin zu seiner Beendigung auf einem hohen Abstraktionsniveau beschreiben. Auf einer tieferen Abstraktionsebene werden betriebliche Abläufe in elementare Arbeitsschritte (Prozesse) gegliedert und der Input- und Outputdatenfluss zwischen Prozessen beschrieben.

•

Dynamische Anforderungen Realwelt-Objekte durchleben während der Existenz ihrer Entsprechung in der Datenbank (Datenbank-Objekt) unterschiedliche Zustände. Der Wechsel von einem Zustand in einen anderen ist an das Eintreten bestimmter Ereignisse gebunden (Auslösebedingungen). Dynamische Anforderungen repräsentieren den Lebenszyklus von Datenbank-Objekten in Form von Zuständen und Ereignissen. Wenn sich ein Datenbank-Objekt in einem bestimmten Zustand befindet, und ein Ereignis eintritt, so kann es zu einem Zustandswechsel kommen. Dynamische Anforderungen bringen Ereignisse und Zustände zueinander in Relation.

•

Bearbeitungsanforderungen Sie beinhalten die verfügbaren Informationen über Transaktionen, die auf den Daten des Datenbanksystems ausgeführt werden sollen, z.B. Operationen wie Anfragen oder Updates, Auswertungen oder Berichterstellungen. Daneben sind Informationen darüber zu sammeln, wie häufig die Transaktionen ausgeführt werden sollen, ob zwischen einzelnen Operationen gewisse Reihenfolgen einzuhalten sind, oder allgemeiner, welche Abhängigkeiten zwischen den Transaktionen bestehen (z.B. Prioritäten), und welches Datenvolumen von den einzelnen Prozessen benötigt wird. Zu den Bearbeitungsanforderungen gehören insbesondere auch Aussagen über die Anzahl der zu erwartenden Nutzer, Informationen hinsichtlich des Grades ihrer unterschiedlichen Anforderungsprofile und damit verbunden auch Aussagen über die Verfügbarkeit oder die Sicherheit der Daten in der Datenbank.

Beispiel 2.1:

Unterschiedliche Arten von Anforderungen

Wir betrachten unterschiedliche Arten von Anforderungen aus dem Anwendungsgebiet Einkauf und Lagerhaltung eines typischen Handelsbetriebes. Informationsanforderungen beschreiben die statischen Eigenschaften z.B. eines Lagerartikels. Von Interesse sind u.a. die Artikelnummer, die Artikelbezeichnung, Daten über den Lieferanten, die physische Lokation des Artikels im Hochregallager, der aktuelle Lagerbestand, die kritische Lagermenge, etwaige Ersatzlieferanten (falls der bisherige Lieferant in Lieferverzug kommt), preis- und kostenbezogene Informationen, Termine, Lieferbedingungen und möglicherweise weitere Informationen mit Bezug zum Einkauf und zur Lagerhaltung. Funktionale Anforderungen beschreiben betriebliche Vorgänge, wie z.B. die Auswahl eines neuen Lieferanten. So könnte es sein, dass bevor ein Auftrag an einen neuen Lieferanten vergeben wird, die Qualifikation, der Service und die Liefersicherheit des Lieferanten geprüft und mit Konkurrenzangeboten verglichen wird. Funktionale Anforderungen beschreiben

2 Anforderungserhebung und -analyse

17

die einzelnen Vorgänge im Detail, die innerhalb des Geschäftsprozesses „Lieferantenwahl" anfallen. Nehmen wir an, es kommt zu einem Geschäftsabschluss, und wir bestellen bei dem neu gewählten Lieferanten. Die einzelnen Zustände von Objekten des Typs „Bestellung" und Ereignisse, die Zustandsübergänge verursachen, werden als dynamische Anforderungen beschrieben. Die Geschäftsbeziehung zwischen dem betrachteten Handelsbetrieb und dem Lieferanten wird vorerst im Zustand „Angebot" sein. Wenn man sich zur Bestellung entschlossen hat (das Ereignis tritt ein), wird das Objekt „Angebot" seinen Zustand in der Datenbank ändern und in den Zustand „Bestellung" übergehen. Abhängig von bestimmten Ereignissen wird die Bestellung die Zustände „bestätigte Bestellung", „Bestellung in Bearbeitung", usw. annehmen, um schließlich nach dem Ereignis „Beladen des LKW abgeschlossen" in den Zustand „Lieferung" überzugehen. Auch im Zustand „Lieferung" wird es wieder unterschiedliche Subzustände und entsprechende Ereignisse geben, die als Teil der dynamischen Anforderungen im Anforderungsdokument spezifiziert werden. Als Beispiel einer Bearbeitungsanforderung betrachten wir das Aktualisieren des Lagerbestandes nach Eintreffen der Lieferung. Diese Datenbankoperation ist Teil einer komplexen Transaktion, die u.a. den Bereich Wareneingangsprüfung der Einkaufsabteilung, die Bereiche Wareneingang, Verbindlichkeiten-Lieferant der Finanzbuchhaltung und diverse Kostenstellen im Lager betrifft. Für die Operation „Erhöhe Lagerbestand" sind folgende Teile der Bearbeitungsanforderungen von Bedeutung: eine detaillierte Beschreibung der Eingaben (Artikelnummer, Liefermenge, Datum der Lieferung, Lieferantenbezeichnung), der Ausgabedaten (Lagerbestand), der anfallenden Rechenoperationen (Lagerbestand = Lagerbestand + Liefermenge), die Häufigkeit der Anwendung der Operation (z.B. 5mal täglich) und Querverweise zu Bezugsdaten (Artikelnummer muss bereits in der Datenbank existieren, Lieferantenbezeichnung muss in der Lieferantendatei bereits eingetragen sein). Abbildung 2.1 zeigt eine graphische Darstellung der unterschiedlichen Arten von Anforderungen. Die Zuordnung einer Anforderung zu einer bestimmten Anforderungsklasse ist nicht immer eindeutig. Insbesondere die Grenzen zwischen funktionalen und dynamischen Anforderungen sind fließend und hängen vom subjektiven Betrachtungsstandpunkt des jeweiligen Analytikers ab. Informationsanforderungen und funktionale Anforderungen stellen die wichtigsten Klassen von Anforderungen dar, die den systemunabhängigen Teil des Entwurfs einer Datenbankanwendung beeinflussen. Dynamische Anforderungen zeigen das zeitabhängige Verhalten der Datenbank und sind für den Entwurf des statischen Datenbankschemas von untergeordneter Bedeutung. Für die Erstellung von Programmen, die auf die Daten zugreifen, ist das dynamische Modell dagegen sehr wichtig, da es die Reihenfolge von Interaktionen und damit den zeitlichen Ablauf von Operationen festlegt. Die Auswertung von Bearbeitungsanforderungen liefert die Grundlage für den physischen Entwurf der Datenbank und soll helfen, zwei prinzipielle Fragen zu klären. Einerseits soll entschieden werden, ob sich die Datenbankanwendung mit der zur Verfügung stehenden Hardware und dem ausgewählten DBMS überhaupt innerhalb des vorgegebenen Zeitrahmens implementieren lässt und andererseits muss abgeklärt werden, ob Hardware und DBMS ausreichen, um die Bearbeitungsanforderungen bestehender und zukünftig geplanter Geschäftsprozesse ausreichend zu unterstützen. Das Ergebnis der Analyse von Bearbeitungsanforderungen spielt eine wichtige Rolle für die

18

2 Anforderungserhebung und -analyse

Artikelnummer Artikelbezeichnung — Lieferantendaten Lokation im Lager Lagerbestand kritische Lagermenge Ersatzlieferanten Kosten und Preise

Lieferantenauswahl - Überprüfe Qualifikation und Service - Referenzen einholen - Liefersichertieit prüfen - Konkurrenzangebote einholen

Lagcrartikcl

Lieferanten

v"

Informationsanforderungeii

funktionale Anforderungen

Lieferung

dynamische Anforderungen

Abb.

2.1:

Unterschiedliche

Anforderungstypen

Bearbeitungsanforderungen

im

Anforderungsdokument

Auswahl von physischen Zugriffsstrukturen zur Leistungsoptimierung. Auch sind Simulationsmodelle, analytische Modelle oder Datenbank-Benchmark-Verfahren zur Leistungsvorhersage von der Qualität der erhobenen Bearbeitungsanforderungen abhängig. Eine erste oberflächliche Erhebung und Analyse der Anforderungen wird vorerst in eine Durchführbarkeitsstudie einfließen. Ziel dieser Studie ist es, festzustellen, ob sich die Aufgabenstellung mit den zur Verfügung stehenden Ressourcen realisieren lässt bzw. ob die Entwicklung eines Datenbanksystems überhaupt zielführend ist.

2.1

Dateisystem vs. Datenbankmanagementsystem

Die Anzahl und Komplexität der betrieblichen Aufgaben, die durch ein unternehmensweites Datenbanksystem unterstützt werden sollen, sind in vielen Fällen sehr groß und schwer überschaubar. Bevor man mit einer detaillierten Anforderungserhebung und -analyse beginnt, ist zunächst anhand einer Vorstudie festzustellen, welche Art von Datenverwaltungssystem grundsätzlich zur Unterstützung der Aufgaben eingesetzt werden kann. Die Vorstudie soll in relativ kurzer Zeit und mit möglichst geringem Ressourceneinsatz Aussagen darüber liefern, ob der Ist-Zustand überhaupt verändert werden soll, und, sofern dieses der Fall ist, welches technische Realisierungskonzept das geeignetste ist. Die Erstellung einer Vorstudie ist nicht ausschließlich eine systemunabhängige Tätigkeit, da mit ihr entschieden werden soll, ob der Einsatz von Datenbanktechnologie angebracht ist. Diese Entscheidung beeinflusst jedoch die nachfolgende detaillierte Anforderungserhebung und Anforderungsanalyse nicht maßgeblich,

2.1 Dateisystem vs. Datenbankmanagementsystem

19

was an dieser Stelle wiederum berechtigt, einen Exkurs in die unterschiedlichen Entwicklungsstufen von Datenbanksystemen zu machen. Die historische Entwicklung von DBMS wird üblicherweise in drei Stufen beschrieben. Die erste Stufe kann man als isolierte Dateiverwaltung, die zweite Stufe als integrierte Dateiverwaltung und die dritte Entwicklungsstufe schließlich als Datenbanksystem bezeichnen.

2.1.1

Isolierte Dateiverwaltung

Isolierte Dateisysteme haben ihren Ursprung im Beginn der Massendatenverarbeitung. Daten werden in elementaren Dateien abgelegt, die Struktur der Dateien ist im jeweiligen Anwendungsprogramm festgelegt und jedes Programm verwendet ausschließlich die ihm zugeordneten Dateien. Aus der engen Bindung von Anwendungsprogrammen an Dateien ergeben sich folgende Nachteile: Abhängigkeit zwischen Programmlogik und physischer Datenstruktur (physische Datenabhängigkeit). Dadurch bedingt erfordern Änderungen oder Erweiterungen an den Dateien Veränderungen an der Struktur der Anwendungsprogramme. Daten gleicher Bedeutung werden unter Umständen mehrfach gespeichert. Die redundante Datenhaltung birgt die Gefahr von Inkonsistenzen in sich. Durch die anwendungsspezifische Datenorganisation ist die gleichzeitige Verwendung von Dateien in unterschiedlichen Anwendungsprogrammen nur schwer möglich.

Beispiel 2.2:

Isolierte Dateiverwaltung

In Abbildung 2.2 geben wir eine graphische Beschreibung eines isolierten Dateiverwaltungssystems anhand der zwei Anwendungen „Gehaltsabrechnung" und „Projektberichte". Während „Gehaltsabrechnung" ausschließlich die Datei ANGESTELLTE benutzt, greift „Projektberichte" auf die Dateien PROJEKTE und PROJEKTBETEILIGTE zu. Daten aus ANGESTELLTE und PROJEKTE sind in PROJEKTBETEILIGTE redundant gehalten. Aufgrund der existierenden physischen Datenabhängigkeit existiert zwischen Dateien und Anwendungsprogrammen eine sehr enge Bindung. So würde z.B. eine physische Änderung an der Datei ANGESTELLTE (z.B. Aufnahme eines Datenfeldes Telefon-Nr.) eine Änderung im Programm-Code von „Gehaltsabrechnung" bedingen.

2.1.2

Integrierte Dateiverwaltung

Die zweite Entwicklungsstufe ist durch die Verwendung zentraler Dateiverwaltungssysteme charakterisiert. Alle Dateien werden unter Verwendung des Dateiverwaltungssystems an zentraler Stelle gesammelt. Eine allgemein zugängliche Referenzdatei enthält die Strukturbeschreibung aller Dateien. Die Weiterentwicklung gegenüber isolierter Dateiverwaltung liegt darin begründet, dass nunmehr unerwünschte Redundanz von Daten weitgehend vermieden wird und somit die Konsistenz des Datenbestandes leichter gewährleistet werden kann. Des Weiteren liegt keine Abhängigkeit zwischen Programmlogik und den physischen Dateien vor.

20

2 Anforderungserhebung und -analyse

Programm Gehaltsabrechnung: Datei Angestellte (SV-Nr., Name, Adresse, Geburtsdatum, Gehalt) Programm Projektberichte: Datei Projekte (Projekt-Nr., Projektbeschreibung) Datei Projektbeteiligte (Projekt-Nr., SV-Nr., Name, Adresse, Geburtsdatum, Telefon-Nr.)

Programme

Gehaltsabrechnung

7

SV-Nr., Name, Adresse, Geburtsdatum, Gehalt

i

Dateien

Abb.

2.2:

Angestellte

Isolierte

Projektberichte

Projekt-Nr., Projektbeschreibung

Τ

Projekt-Nr., SV-Nr., Name, Adresse, Geburtsdatum, Telefon-Nr.

1 Projekte

Projektbeteiligte

Dateiverwaltung

Einige Einschränkungen existieren jedoch weiterhin. So erfordern Änderungen oder Erweiterungen an den Dateien weiterhin Änderungen an den Programmen. Diesmal zwar nicht mehr an den Anwendungsprogrammen, sondern jetzt an den Abbildungsprogrammen, die relevante Dateiauszüge für Anwendungsprogramme erzeugen. Im Modell der integrierten Dateiverwaltung können über den indirekten Weg der Dateiauszüge mehrere Anwendungsprogramme auf eine Datei zugreifen.

Beispiel 2.3:

Integrierte Dateiverwaltung

Wir betrachten die Situation aus Beispiel 2.2 und zeigen die Struktur eines integrierten Dateiverwaltungssystems. Kontrollierte Datenredundanz ergibt sich aus der Tatsache, dass Redundanz ausschließlich auf Ebene der Dateiverwaltungssysteme vorliegt, und die zentralen Dateien keinen redundanten Datenbestand mehr aufweisen.

Aus Abbildung 2.3 ist ersichtlich, dass die zentralen Dateien eines integrierten Dateiverwaltungssystems bereits einen direkten semantischen Bezug zu Objektbeschreibungen der Realität besitzen. Datei PERSONAL beschreibt ausschließlich Eigenschaften von Objekten vom Typ Person, Datei PROJEKTE enthält ausschließlich Informationen zu Projekten und Datei PROJEKTBETEILIGUNG enthält Informationen darüber, welche Personen an welchen Projekten arbeiten. Die individuellen Sichten der einzelnen Anwendungsprogramme werden über spezielle Abbildungsprogramme erzeugt. Dies ist ein entscheidender Vorteil gegenüber

21

2.1 Dateisystem vs. Datenbankmanagementsystem Zentrale Dateien: Personal (SV-Nr., Name, Adresse, Geburtsdatum, Gehalt, Telefon-Nr.) Projektbeteiligung (Projekt-Nr., SV-Nr.) Projekte (Projekt-Nr., Projektbeschreibung) Programme

Gehaltsabrechnung

7

SV-Nr., Name, Adresse, Geburtsdatum, Gehalt

Abbildungsprogramme

Dateiverwaltungssystem 1

Projektberichte

Projekt-Nr., SV-Nr., Name, Adresse, Geburtsdatum, Telefon-Nr.

Projekt-Nr., Projektbeschreibung

1

Zentrale Dateiverwaltung

Abb. 2.3: Integrierte

Dateiverwaltung

isolierten Dateisystemen, macht aber eine sorgfältige Planung der Struktur der einzelnen Dateien notwendig. Wir werden im Kapitel 3 Techniken der konzeptuellen Datenmodellierung beschreiben, die zur Strukturierung der Dateien erfolgreich eingesetzt werden können.

2.1.3

Architektur von Datenbankmanagementsystemen

Im Modell der integrierten Dateiverwaltung sind keine Abbildungsvorschriften von Dateien auf Dateiverwaltungssysteme vorgegeben. Im Prinzip kann also jedes Dateiverwaltungssystem seine eigenen Strukturierungsregeln und Dienstfunktionen vereinbaren bzw. seine logische Struktur verändern. Eine Änderung hätte dann zur Folge, dass die Anwendungsprogramme, die Dateiauszüge verwenden, geändert werden müssen. In DBMS verlangt man nun neben physischer Datenunabhängigkeit auch logische Datenunabhängigkeit, also Immunität von Anwendungsprogrammen gegenüber Änderungen der logischen Struktur der Datenbank. Erreicht wird dies durch vereinheitlichte Strukturierungsregeln und festgelegte Dienstfunktionen, die einem bestimmten Datenmodell genügen müssen. Eine zentrale Idee in DBMS ist die Trennung der in Dateisystemen existenten Einheit DateienProgramme in zwei unterschiedliche Schichten: der logischen und der physischen Beschreibung von Daten. Das bedeutet, dass Programme ausschließlich mit „logischen Dateien" arbeiten und dass die physische Realisierung der Dateien (die Dateiorganisation) für Benutzer nicht sichtbar ist. Die Trennung der Beschreibung der Daten in zwei separate Ebenen hat neben dem Vorteil der kontrollierbaren Datenredundanz und der damit einhergehenden Konsistenz des Daten-

22

2 Anforderungserhebung und -analyse

bestandes noch einen weiteren gravierenden Vorteil. So ist für Anwendungsprogramme eine gesteigerte Flexibilität gegeben, da über die logische Beschreibung der Daten zum einen für jede Anwendung eine eigene Sicht (externes Modell) auf die mit anderen Anwendungen gemeinsam genutzten Daten zur Verfügung gestellt werden kann und zum anderen Belange der physischen Speicherung der Daten (internes oder physisches Modell) für Anwendungsprogramme ohne Bedeutung sind. Aus letzterem ergibt sich auch die physische Datenunabhängigkeit, nämlich, dass eine Änderung an den physischen Speicherstrukturen keine Änderung an auf die Dateien zugreifenden Programmen bedingt. Beispiel 2.4:

Architektur eines DBMS (zweischichtiger Aufbau)

Abbildung 2.4 zeigt einen zweischichtigen Aufbau und die Gliederung in externes und internes Modell eines Datenbanksystems anhand der beiden bekannten Anwendungen.

Abb. 2.4: Externes und internes Modell einer

Datenbankverarbeitung

Die zweischichtige Architektur eines Datenbanksystems stellt jedoch nur einen Zwischenschritt hin zu der Architektur der heute gängigen Datenbanksysteme dar. Wie aus Abbildung 2.4 ersichtlich ist, ist die Ebene des externen Modells durch voneinander unabhängige logische Dateien beschrieben. Dies entspricht nicht unbedingt der Realität, denn Angestellte und Projekte stehen ja über die Datei PROJEKTBETEILIGUNG miteinander in Beziehung und können nicht isoliert voneinander betrachtet werden. Zur Darstellung dieser „unternehmensweiten" Sicht hat man zwischen externer und interner Schicht eine dritte Schicht, die so genannte konzeptuelle Schicht aufgenommen. Dieses Drei-Schichten-Konzept einer Datenbankarchitektur ist auch als ANSI/X3/SPARC-Architekturmodell' bekannt (siehe Abbildung 2.5).

2.1 Dateisystem vs. Datenbankmanagementsystem

23

Externe Modelle Abbildung Externe Modelle / Konzeptuelles Modell

Konzeptuelles Modell

Abbildung Konzeptuelles Modell / Internes Modell

Internes Modell Abb. 2.5: ANSI/SPARC Architekturmodell

Feststellung 2.1:

Architekturmodell

DBMS mit heute üblicher Technologie sind also in drei Schichten realisiert. Das interne Datenbankschema beschreibt die physischen Speicherstrukturen und Zugriffspfade. Das externe Datenbankschema beschreibt die unterschiedlichen Sichten einzelner Anwendungen (bzw. auch Datenbanknutzer) auf die Datenbasis. Dazwischen liegt das konzeptuelle Datenbankschema. Es repräsentiert eine gesamtheitliche Sicht der Datenbasis, indem es die externen Sichten aller Anwender in ein einheitliches konzeptuelles Modell integriert. Bevor man nun aufgrund der Erkenntnisse aus der Vorstudie entscheiden kann, ob ein DBMS zum Einsatz kommen soll oder nicht, muss man sich auch überlegen, welche Dienstfunktionen zur Realisierung der Anwendung bereits im DBMS inkludiert sind und somit nicht mehr in den Anwendungsprogrammen realisiert werden müssen. Die nachfolgend dargestellten Dienstfunktionen werden üblicherweise von DBMS angeboten. Auf die meisten dieser Funktionen werden wir in den späteren Kapiteln noch näher eingehen. •

Persistenz Im Unterschied zur Verarbeitung von Daten mit Programmiersprachen „überleben" diese das Ende von Datenbanktransaktionen und werden automatisch auf Sekundärspeicher abgelegt.

•

Speichermanagement Datenbankanwendungen sind Ein-/Ausgabe intensiv. Große Datenmengen werden üblicherweise auf Plattenspeicher ausgelagert. Das DBMS unterstützt spezifische Techniken

1 Vom Standards Planning and Requirements Committee (SPARC) of the American Standards Committee on Computers and Information Processing (ANSI/X3) wurde 1975 diese Drei-Schichten-Architektur für Datenbanksysteme vorgeschlagen.

24

2 Anforderungserhebung und -analyse zur Erhöhung der Performanz, z.B. Hauptspeicherpufferung, Indizierung, Clusterbildung oder Abfrageoptimierung.

•

Mehrbenutzerbetrieb Mehrere Benutzer können gleichzeitig mit den Daten arbeiten. Das DBMS sorgt dafür, dass keine unerwünschten Wechselwirkungen durch gleichzeitige Manipulation derselben Daten eintreten können. Etwaige Konfliktsituationen müssen durch Synchronisationsverfahren überwacht und reguliert werden (sog. concurrency control).

•

Konsistenzüberwachung Die Überwachung der Konsistenz des Datenbestandes wird auch als Integritätssicherung bezeichnet. Das DBMS übernimmt die Gewährleistung der korrekten Ausführung von Transaktionen. Kommt es zu Systemfehlern (z.B. Fehler in der Zentraleinheit, Hauptspeicher, Platte oder Stromausfall), kann der letzte gültige Datenbankzustand wiederhergestellt werden.

•

Datensicherheit und Fehlertoleranz Das DBMS unterstützt die Vergabe und Verwaltung von Zugriffsrechten für unterschiedliche Benutzer, da in vielen Anwendungen nicht jeder Benutzer alles mit den Daten tun darf. Oft wird auch die Benutzeridentifikation (Eingabe einer Benutzer-ID) und nachfolgende Authentifikation (z.B. durch Passwortverfahren) unterstützt.

•

Anfragesprache Das DBMS stellt eine Anfragesprache zur ad hoc Formulierung von Datenbankanfragen sowie zur Veränderung des Datenbestandes zur Verfügung.

•

Dienstprogramme Die bisher angeführten Dienstfunktionen werden noch durch eine Reihe von Dienstprogrammen erweitert. Viele Datenbanksysteme beinhalten Programmgeneratoren zur raschen Anwendungsentwicklung, Reportgeneratoren zur Erstellung von Berichten, Konvertierungsprogramme zur Änderung von Datenformaten oder auch Backup-Utilities zur Unterstützung der Datensicherung.

Das Einsatzgebiet von DBMS ist äußerst breit gefächert. Datenbanksysteme stellen einen Basisdienst sowohl in vielen Standard-Anwendungen als auch in kaufmännischen wie technischen Spezialanwendungen dar. Als Beispiele für unterschiedliche Anwendungen seien Buchungsund Auskunftssysteme wie sie von Fluglinien, Reisebüros oder Mietwagenunternehmen eingesetzt werden, geographische Informationssysteme, wie z.B. das automatisierte Grundbuch oder geographische Umweltinformationssysteme, und Datenbanksysteme als zentrale Komponente einer rechnerintegrierten Fertigung genannt. Aufgrund der vielfältigen Möglichkeiten des Einsatzes von DBMS ist es verständlich, dass Produkte sehr allgemein gehalten sind und erst über bestimmte Einstellparameter für bestimmte Anwendungen getuned werden müssen. In den meisten Fällen muss man hier jedoch Kompromisse zwischen optimalem Leistungsverhalten einer Anwendung und dem Nutzen aus den Dienstfunktionen des Datenbanksystems eingehen. Wann soll man nun ein Dateisystem einsetzen, und wann ist der Einsatz eines Datenbanksystems angebracht? Auf diese Frage kann man keine allgemein gültige Anwort geben, denn ihre Beantwortung wird immer von der gegenwärtigen Situation und der individuellen Anwen-

2.2 Anforderungserhebung

25

dung abhängen. Einige Hinweise zur Entscheidungsfindung können jedoch gegeben werden. Datenbanksysteme eignen sich besonders für Anwendungen mit den folgenden Eigenschaften: •

Heterogene Benutzergruppen mit gemeinsamer integrierter Datenhaltung.

•

Keine bzw. kontrollierte Datenredundanz wird gewünscht.

•

Benutzerverwaltung und Autorisierung ist notwendig.

•

Unterschiedliche Schnittstellen für unterschiedlich geschulte Benutzer sollen zur Verfügung gestellt werden.

•

Der Datenbestand ist integriert. Daten stehen miteinander in Beziehung.

•

Die Integritätsmechanismen des Datenbanksystems sollen genutzt werden.

•

Backup und Fehlerbehandlung bei Systemfehlern sind gewünschte Eigenschaften.

•

Anwendungsprogramme können sich ändern und geringere Entwicklungskosten durch den Einsatz von Programmgeneratoren sind erwünscht.

Durch die eher allgemeine Ausrichtung der Datenbanksoftware und dem Overhead, der durch die Vielzahl der Dienstfunktionen entstanden ist, ist der Einsatz von Standard-DBMS für zeitkritische Anwendungen kritisch zu prüfen. Der Einsatz von Dateisystemen kann vorteilhaft sein, wenn •

Echtzeitanforderungen bestehen,

•

der Overhead für Benutzerverwaltung, Backup, Fehlerbehandlung und Synchronisation nicht benötigt wird,

•

Anwendungen sich nicht oder sich nur sehr wenig ändern und

•

nur geringe Investitionskosten eingeplant sind. Hier ist jedoch zu bedenken, dass die Preise für DBMS gerade in der letzten Zeit beträchtlich gesenkt wurden und die Kosten der Entwicklung komplexerer Anwendungen unter Verwendung von Dateisystemen erfahrungsgemäß weit höher als bei Verwendung von Datenbanksystemen liegen.

2.2

Anforderungserhebung

Die Erhebung von Anforderungen umfasst die quantitative und qualitative Erfassung des IstZustandes eines abgegrenzten betrieblichen Aufgabensystems. Grundsätzlich kann zwischen einer Primär- und einer Sekundärerhebung unterschieden werden. Bei der Primärerhebung werden die Informationen erstmalig und primär für den Erhebungszweck erhoben, während bei der Sekundärerhebung auf bereits vorhandene Dokumentationen zurückgegriffen wird. Die Anforderungserhebung kann sowohl von den betroffenen Benutzern als auch von den Systemanalytikern erstellt werden - in den meisten Fällen ist jedoch eine Kooperation von beiden (partizipative Systemanalyse) am sinnvollsten. Die am häufigsten in der Literatur genannten und in der Praxis eingesetzten Methoden zur Erhebung der Anforderungen sind: •

Dokumentenanalyse

•

Fragebogentechniken

26

2 Anforderungserhebung und -analyse

•

Interviews

•

Selbstaufschreibung

•

Beobachtung

•

Berichtsmethode

Welche Methode im einzelnen eingesetzt wird, hängt vom Untersuchungsgegenstand und Untersuchungsziel ab. Die beste Methode gibt es leider nicht. In der Praxis hat sich auch bewährt, unterschiedliche Methoden miteinander zu kombinieren. So kann z.B. die Interviewmethode mit allen anderen Methoden kombiniert werden, um mit ihr erlangte Erkenntnisse einer ersten Validation zu unterziehen. In Abbildung 2.6 beschreiben wir den Einsatz der unterschiedlichen Erhebungstechniken. Der obere Bereich des Bildes beschreibt Inputfaktoren und Anwendungsbereiche der sechs Erhebungstechniken. Die Kanäle in der Mitte der Abbildung zeigen den unterstützenden Charakter der Dokumentenanalyse, Fragebogentechnik, Selbstaufschreibung, Berichtsmethode und Beobachtung. Der untere Teil der Abbildung zeigt die Output-Informationen der Erhebungstechniken.

Abb. 2.6: Auswahl von Erhebungstechniken (nach

[Hane84])

2.2 Anforderungserhebung

2.2.1

27

Dokumentenanalyse

Viele neu zu entwickelnde Informationssysteme basieren teilweise oder vollständig aufbereite bestehenden Systemen. Sofern die vorhandenen Unterlagen korrekt und aktuell sind, stellen sie einen guten Ausgangspunkt zur Anforderungserhebung dar. Solche Unterlagen können z.B. sein: •

Organisationshandbücher, Stellen- und Arbeitsplatzbeschreibungen, Ausbildungsunterlagen, Aufgabenpläne, Stellenbesetzungspläne.

•

Geschäftsberichte, Bilanzen, Kennzahlen, Statistiken, Revisionsberichte, Inventurverzeichnisse.

•

Betriebs- und Arbeitsablaufpläne, technische Verfahrensbeschreibungen, Materialflusspläne, Stücklisten, Datenflusspläne.

•

Kunden- und Lieferantenverzeichnisse, Telefonverzeichnisse, Raumpläne, Produktbeschreibungen.

•

Vorhandene Programme, Programmdokumentationen und Handbücher, Eingabemasken und Reports, Dateibeschreibungen.

•

Formulare, ausgefüllte Vordrucke und Datenträger, Listen und Berichte.

Das Studium der vorhandenen Unterlagen sollte zu Beginn der Erhebung stattfinden. Die Analyse vorhandener Dokumente hat den Vorteil, rasch eine breite Informationsbasis zu liefern und den bestehenden Betriebsablauf nicht zu stören. Sie zeichnet sich zudem durch einen geringen Erfassungsaufwand aus. Als wesentlicher Nachteil der Methode ist zu nennen, dass die Qualität der erhobenen Informationen stark von der Richtigkeit und Aussagekraft der untersuchten Dokumente abhängig ist. Des Weiteren beschreiben die dokumentierten Daten das Aufgabensystem ausschließlich zum Erfassungszeitpunkt, und es ist zu beurteilen, ob die in der Vergangenheit dokumentierten Sachverhalte auch noch in der Zukunft Gültigkeit haben werden.

2.2.2

Fragebogentechnik

Ein Weg um möglichst effektiv Informationen von einer Vielzahl potentieller Datenbanknutzer zu erhalten, ist der Gebrauch von Fragebögen. Ein Fragebogen besteht aus einer Menge von unterschiedlichen Fragen, die von den Befragten schriftlich beantwortet werden müssen. Um Auffassungsunterschiede und Verständnisprobleme einzuschränken, empfiehlt sich vor der endgültigen Formulierung des Fragebogens die Erprobung an mehreren Testpersonen. Fragebögen sollten so beschaffen sein, dass die Antworten kurz, einfach auszuwerten und eindeutig sind, z.B. durch eine Auswahl von vorgegebenen Antworten. Um eine hohe Beantwortungsrate zu erreichen, sollte ein Fragebogen nicht zu lang, gut strukturiert und an spezielle Benutzer gerichtet sein. Nach folgenden Gesichtspunkten werden verschiedene Fragebogentypen unterschieden:

28

2 Anforderungserhebung und -analyse

•

Standardfragebogen oder differenzierter Fragebogen

•

Fragebogen mit offenen bzw. geschlossenen Fragen

•

Individual- oder Gruppenfragebogen

Während beim Standardfragebogen alle Befragten dieselben Fragen beantworten, wird beim differenzierten Fragebogen zwischen z.B. Befragten aus unterschiedlichen Fachabteilungen oder Befragten mit unterschiedlichem Ausbildungsniveau unterschieden. Bei offenen Fragen sind keine Alternativantworten vorgegeben. Der Befragte muss mit eigenen Worten eine Antwort auf die Fragen formulieren. Bei geschlossenen Fragen werden mehrere Antwortalternativen vorgegeben und der Befragte muss nur mehr auswählen. Bei Verwendung geschlossener Fragen hat man den Vorteil einer vollständigen Beantwortung der Fragen und einer vereinfachten Auswertung. Offene Fragen ermöglichen meist spontane Antworten und lassen auch Antwortalternativen zu, die bei geschlossenen Fragen möglicherweise nicht berücksichtigt wurden. Ein Individualfragebogen wird an alle Mitglieder einer Gruppe verteilt, während ein Gruppenfragebogen von einzelnen Befragten stellvertretend für eine Gruppe beantwortet wird. Im Allgemeinen ist bei Erstellung von Fragebögen darauf zu achten, dass verschiedene Arten von Fragen gestellt werden sollten. Überblicksfragen erleichtern den Einstieg und schaffen ein Gesamtbild der Aufgabenstellung. Detailfragen schaffen Monotonie und Unlust, sie sollten durch Unterbrechungsfragen aufgelockert werden. Anregungsfragen schaffen einen Freiraum, in dem Befragte eigene Vorschläge unterbreiten oder wichtige Anregungen geben können. Fragebögen sollen auch unauffällige Kontrollfragen enthalten, anhand derer die Richtigkeit der gemachten Angaben überprüft werden kann. Die Fragebogenmethode hat den Vorteil einer leichteren statistischen Auswertung und der geringen Kosten. Sie eignet sich besonders für geographisch verteilte Erhebungen und bei gleichförmigem und ähnlichem Informationsbedarf unterschiedlicher Nutzer. Als Nachteile sind vor allem der hohe Aufwand der Auswertung von offenen Fragen und die Möglichkeit einer subjektiven Färbung von Antworten zu nennen. Werden Arbeitsmengen oder -Zeiten erhoben, sind die Ergebnisse der Erhebung mit besonderer Vorsicht zu genießen.

2.2.3

Interviewmethode

Das Interview ist die am häufigsten verwendete und ergiebigste Erhebungstechnik. Ein Interview ist eine persönliche Befragung potentieller Datenbanknutzer. Es sollte einerseits strukturiert sein und nach einer schriftlichen Vorlage ablaufen und andererseits für unvorhergesehene Antworten flexibel genug sein. Interviews können nach folgenden Gesichtspunkten gestaltet werden: •

standardisiertes bzw. nicht-standardisiertes Interview

•

Einzel-, Gruppenbefragung bzw. Konferenzmethode

•

offenes bzw. verdecktes Interview

2.2 Anforderungserhebung

29

Bei einem standardisierten Interview ist die Reihenfolge der Fragen fest vorgegeben, während beim nicht-standardisierten Interview Fragen in beliebiger Reihenfolge gestellt werden, und auch Zusatzfragen zulässig sind. Bei der Einzelbefragung wird jeder potentielle Nutzer einer Gruppe einzeln befragt. Im Gegensatz dazu werden bei der Gruppenbefragung mehrere Gruppenmitglieder gleichzeitig befragt. Bei der Konferenzmethode erfolgt die Befragung über unterschiedliche Gruppengrenzen hinweg. Mitglieder unterschiedlicher Fachabteilungen diskutieren hier gemeinsam Antworten zu den einzelnen Fragen des Interviews. Bei einem offenen Interview ist der Befragte über Sinn und Zweck des Interviews informiert, während bei verdeckten Interviews die Befragung versteckt ohne das Wissen des Befragten stattfindet. Bei der Gestaltung der Fragen sind im wesentlichen dieselben Aspekte zu berücksichtigen, wie bei der Fragebogenmethode. Auch was die Vorbereitung der Fragen und die Auswertung der Antworten anbelangt, sind die Interviewmethode und die Fragebogentechnik sehr ähnlich zueinander. Die Interviewmethode besteht aus fünf nacheinander anfallenden Phasen: 1. Bestimmen der Interviewpartner 2. Erstellen des Fragenkataloges 3. Durchführung des Interviews 4. Dokumentation der Ergebnisse 5. Aufarbeiten des Interviews Die Dokumentation der Ergebnisse des Interviews sollte schon während der Befragung begonnen und unmittelbar nach dem Interview abgeschlossen werden. Unter dem Aufarbeiten des Interviews versteht man die Mitteilung der Ergebnisse an die Befragten und ihr Feedback auf die Dokumentation des Interviews. Oft werden in dieser Phase Fehler ausgeräumt, und manchmal wird es auch notwendig sein, einzelne Phasen des Interviews zu wiederholen. Die Interviewmethode hat den Vorteil, die Vertiefung der Befragung durch Zusatzfragen leicht zu ermöglichen, einen persönlichen Kontakt zwischen Systemanalytikern und potentiellen Datenbanknutzern herzustellen und qualitativ sehr gute Erhebungsergebnisse zu ermöglichen. Demgegenüber stehen jedoch der hohe Zeitaufwand einer Befragung, die Störung des Betriebsablaufs durch die Befragung und die notwendige hohe Qualifikation des Interviewers im Anwendungsbereich, die eine Voraussetzung für ein erfolgreiches Interview darstellt.

2.2.4

Berichtsmethode

Die Berichtsmethode ist eine Tätigkeit, die allein vom Aufnahmeteam ohne Hinzuziehung Dritter vorgenommen wird. Sie eignet sich besonders zur Aufnahme von Aktivitäten innerhalb einer für die Anwendung typischen Zeitspanne und liefert einen Überblick über Aufgaben, Aktivitäten und Kommunikation potentieller Datenbanknutzer. Die Berichtsmethode wird oft mit einer Dokumentenanalyse gemeinsam durchgeführt und durch ein standardisiertes Interview ergänzt. Der Vorteil der Berichtsmethode liegt in der geringen Beeinträchtigung des Arbeitsablaufs. Diesem Vorteil steht jedoch der hohe Zeitaufwand, der für die Berichterstellung durch das Aufnahmeteam notwendig ist, entgegen.

2 Anforderungserhebung und -analyse

30

2.2.5

Selbstaufschreibung

Bei der Aufschreibung der Anforderungen durch die zukünftigen Datenbanknutzer wird der Informationsbedarf von den Fachexperten der beteiligten Abteilungen (den Datenbanknutzern) niedergeschrieben. Nach der Form des entstehenden Dokumentes unterscheidet man in Berichte mit völliger Formfreiheit und solche, in denen gewisse Richtlinien (z.B. Strukturierung, Mengengerüst, Mindestbestandteile) eingehalten werden müssen. Werden hinsichtlich der Form des Berichtes keine Vorgaben gemacht, kann jeder Mitarbeiter die Schwerpunkte seiner Tätigkeit nach eigenem Ermessen darstellen. Dies hat den Vorteil, dass zumindest die aus der Sicht des Mitarbeiters wichtigen Aufgabengebiete besondere Berücksichtigung finden können, während Bereiche, die für die Tätigkeit des Mitarbeiters unwesentlich sind, vernachlässigt werden können. Wird bei der Erstellung des Berichtes auf völlige Formfreiheit verzichtet und sind feste Richtlinien vorgegeben, so wird dadurch die Auswertung der Berichte erheblich erleichtert. Der Vorteil der Selbstaufschreibung liegt in der genauen Beschreibung der unterschiedlichen Arbeitsbereiche. Zusätzlich dazu können die einzelnen Mitarbeiter ihre Vorstellungen und Lösungsansätze in den Entwurfsprozess sehr gut einbringen. Als Nachteile dieser Erhebungsmethode sind zu nennen, dass die Selbstaufschreibung durch den Zeitaufwand, der zur Erstellung des Berichtes notwendig ist, gestört wird, und dass Berichte durch die subjektive Darstellung der Mitarbeiter mit besonderer Vorsicht zu genießen sind. Dies bezieht sich insbesondere auf Mengen- und Zeitangaben.

2.2.6

Beobachtungsmethode

Als Beobachtung bezeichnet man die Aufnahme von Anforderungen unmittelbar an der Quelle ihres Entstehens durch optische Aufnahme und ihre nachfolgende Interpretation durch den Systemanalytiker. Nach den folgenden Kriterien können verschiedene Formen der Beobachtung unterschieden werden: •

offene und verdeckte Beobachtung

•

strukturierte und unstrukturierte Beobachtung

•

Einzelbeobachtung, Dauerbetrachtung oder unterbrochene Beobachtung

•

direkte und indirekte Beobachtung

Von offener Beobachtung spricht man, wenn für alle Beteiligten ersichtlich ist, dass eine Erhebung stattfindet. Bei einer strukturierten Beobachtung erfolgt die Beobachtung nach im Vorhinein festgelegten Richtlinien. Bei einer Einzelbeobachtung wird der Beobachtungsgegenstand ein einziges Mal erhoben, während im Rahmen einer Dauerbetrachtung die Beobachtung ohne Unterbrechung über eine längere Zeitdauer hinweg stattfindet. Bei einer unterbrochenen Beobachtung werden bestimmte Zeitpunkte einer Tätigkeit zur Beobachtung (MultimomentVerfahren) ausgewählt. Von direkter Beobachtung spricht man, wenn die Beobachtung vom Aufnahmeteam direkt durchgeführt wird. Eine indirekte Beobachtung findet statt, wenn Ereignis und Beobachtung zeitversetzt stattfinden, z.B. durch den Einsatz technischer Hilfsmittel wie der Videoaufzeichnung. Die Beobachtungsmethode zeichnet sich dadurch aus, dass der Arbeitsablauf nicht beeinträchtigt wird und dass quantitative und zeitbezogene Anforderungen

2.3 Anforderungsdokument

31

leicht erhoben werden können. Die Beobachtungsmethode (zumindest in der Form der direkten Beobachtung) ist sehr zeitaufwändig, da der Beobachter für die Dauer der Beobachtung seinen Platz nicht verlassen darf. Bei der Anforderungserhebung handelt es sich um einen häufig langwierigen Systemanalyseprozess, in dem alle beschriebenen Methoden zum Einsatz kommen können. Ebenso wichtig wie die sorgfaltige Erhebung des Ist-Zustandes ist die übersichtliche Darstellung und Auswertung der Ergebnisse der Erhebung im Anforderungsdokument. Im folgenden Unterkapitel werden wir unterschiedliche Klassen von Anforderungen kennenlernen und zeigen, wie die erhobenen Anforderungen analysiert und im Anforderungsdokument entsprechend repräsentiert werden können.

2.3

Anforderungsdokument

Ähnlich wichtig wie die sorgfältige und vollständige Erhebung der Anforderungen ist die übersichtliche Darstellung und die Analyse der Ergebnisse der Erhebung im Anforderungsdokument. Im Idealfall ist das Anforderungsdokument eine Spezifikation des zu entwickelnden Systems, die alle Informationen enthält, die notwendig sind, um die Datenbank erstellen zu können. Prinzipiell kann zwischen den zwei Typen unternehmensweite Anforderungsspezifikation und individuelle Anforderungsspezifikation unterschieden werden. Beim unternehmensweiten Anforderungsdokument werden alle Nutzeranforderungen und erhobenen Sachverhalte in einem einzigen Anforderungsdokument festgehalten. Diese Vörgehensweise empfiehlt sich nur für übersichtliche und einfache Anwendungen. In der Vielzahl der Fälle wird hingegen je ein Anforderungsdokument für jede Benutzergruppe und jeden Funktionsbereich (eine individuelle Anforderungsspezifikation) im Unternehmen erstellt. Ein Vorteil des unternehmensweiten Anforderungsdokumentes liegt in der Möglichkeit, Redundanzen, Homonyme und Synonyme, Inkonsistenzen und Fehler vorzeitig zu erkennen. In komplexen und umfangreichen Anwendungsgebieten werden unternehmensweite Anforderungsdokumente jedoch sehr rasch unübersichtlich. Hier empfiehlt sich die Erstellung von mehreren Anforderungsdokumenten, die jedoch in späteren Entwurfsphasen zu einem unternehmensweiten Datenmodell konsolidiert werden müssen. In Unterkapitel 3.5 werden wir auf die Sichtenintegration und Schemakonsolidierung genauer eingehen. Für beide Vorgehensweisen gilt jedoch, dass Anforderungsdokumente die folgenden Eigenschaften aufweisen müssen: •

Korrektheit

Eine Spezifikation ist korrekt, wenn durch sie die Realität wahrheitsgetreu beschrieben wird. •

Vollständigkeit

Anforderungsdokumente sind vollständig, wenn sie alle erhobenen Anforderungen enthalten und diese Anforderungen ausreichen, die Datenbank zur Zufriedenheit der Nutzer zu erstellen. •

Konsistenz

Ein Anforderungsdokument ist konsistent, wenn es keine Anforderungen enthält, die miteinander in Konflikt stehen. Beispiele für Konflikte sind widersprüchliche Begriffe, Konzepte und Konsequenzen.

32 •

2 Anforderungserhebung und -analyse Eindeutigkeit

Alle Anforderungen sind eindeutig, wenn sie nur eine einzige Interpretation erlauben. •

Einfachheit

Anforderungen sollten verständlich und so einfach wie nur möglich formuliert sein. Gegebenenfalls sollten Anforderungen durch Kommentare ergänzt werden. Die beste Möglichkeit diese Forderungen zu erfüllen besteht darin, Anforderungsdokumente hinsichtlich des Typs der Anforderungen in die vier unterschiedlichen Teile Informationsanforderungen, funktionale Anforderungen, Bearbeitungsanforderungen und dynamische Anforderungen zu strukturieren. Es gibt eine Reihe verfügbarer Darstellungstechniken für die erhobenen Anforderungen, die entweder eine textuelle, graphische oder tabellarische Darstellungsform wählen. Welche Darstellungsform im Einzelnen eingesetzt werden soll, hängt sowohl vom Untersuchungsziel als auch von der Art der dokumentierten Anforderungen ab. Informationsanforderungen werden häufig textuell beschrieben. Funktionale Anforderungen werden meist durch graphische Darstellung und ergänzenden Text beschrieben. Dynamische Anforderungen eignen sich ebenfalls gut zur Darstellung in graphischer Form, während Bearbeitungsanforderungen, wie z.B. erhobene Transaktionsfrequenzen, oft in Tabellenform dargestellt werden. In der Praxis hat sich auch bewährt, die einzelnen Darstellungsformen miteinander zu kombinieren. Oft ist es sinnvoll, zu allererst eine textuelle Analyse der vorliegenden Anforderungen vorzunehmen und erst danach eine detaillierte Beschreibung zu erstellen und ein graphisches Beschreibungsmittel einzusetzen. Die graphischen Konzepte und tabellarischen Darstellungen werden oft auch mit ergänzendem Text beschrieben. Bevor wir auf die unterschiedlichen Typen von Anforderungen näher eingehen werden, geben wir einige Hinweise zur Strukturierung des ergänzenden Textes. Während der textuellen Analyse, d.h. während der Analyse der in natürlicher Sprache vorliegenden Anforderungsbeschreibung, müssen Mehrdeutigkeiten entlarvt und ein einheitliches Verständnis von Beschreibungsdetails gewährleistet werden. Dies ist insbesondere dann nicht immer einfach, wenn Texte von unterschiedlichen Personen erstellt wurden und aus Interviews, Diskussionen oder direkt von den zukünftigen Datenbanknutzern stammen und dadurch nur wenig strukturiert sind. Die Analyse von natürlichsprachigem Text setzt ein hohes Anwendungswissen des Systemanalytikers voraus. Man kann jedoch einige Regeln beachten, mit denen Ungenauigkeiten und Mehrdeutigkeiten entdeckt und eliminiert werden können: •

Begriffe sollen in einem korrekten Abstraktionsniveau benutzt werden. So sollte anstelle von allgemeinen Bezeichnern wie z.B. „Name" eine genauere Bezeichnung wie „Projektname", anstelle von „Datum" „Geburtsdatum" oder anstelle von „Stadt" der Begriff „Ort" gewählt werden. Zu genaue Beschreibungen sind jedoch auch nicht immer sinnvoll. Anstelle von Ausprägungen oder Instanzen von Begriffen sollen eher Überbegriffe als Bezeichner gewählt werden. Ein Beispiel dafür wäre die Verwendung des allgemeinen Konzeptes „Wertpapier" anstelle von „Aktie". Begriffe müssen einen eindeutigen Zeitbezug haben. Ein allgemeiner Begriff wie z.B. „Umsatz" kann sich auf einen Tag, auf eine Woche, einen Monat oder eine andere Abrechnungsperiode beziehen. Eine richtige Begriffswahl wäre z.B. „Jahresumsatz".

2.3 Anforderungsdokument

33

•

Mehrdeutige Wörter und umschreibende Ausdrücke sollten vermieden werden. So sollte z.B. die Bezeichnung „Student" in textuellen Anforderungsbeschreibungen anstelle von „sich in akademischer Ausbildung befindliche Person" gewählt werden. Mehrdeutigkeiten entstehen, wenn Referenzen zwischen Begriffen nicht spezifiziert sind. Ein Beispiel dafür wäre eine „Telefonnummer", wobei nicht hervorgeht, ob es sich um einen Privatanschluss oder die Firmennummer handelt.

•

Verwendung von strukturiertem Text. Die Strukturierung des Textes ergibt sich durch einen Standardsatzbau und durch eingerückte Sätze und Absätze. Zur Beschreibung von Arbeitsabläufen empfiehlt es sich, eine einfache Art von Pseudocode und eine Strukturierung des Textes wie (Bedingung) „dann" {Aktion} „ansonsten" „falls" (Bedingung) „dann" (Aktion) usw. zu verwenden.

•

Vermeidung von Homonymen und Synonymen. Synonyme sind verschiedene Worte mit der gleichen Bedeutung, wie z.B. „Rechner" und „Computer", während mit Homonymen unterschiedliche Bedeutungen eines Wortes gemeint sind, z.B. „Name" einmal als Projektbezeichnung und ein anderes Mal als Ortsname.

•

Die Erstellung eines Stichwortverzeichnisses ist sinnvoll. Es sollen nur Bezeichner verwendet werden, die im Stichwortverzeichnis aufgeführt sind. Für jeden Bezeichner sollten eine kurze Erklärung und mögliche Synonyme im Stichwortverzeichnis angegeben sein.

Nach dieser ersten Analyse der vorliegenden Anforderungsbeschreibung ist es nun an der Zeit, mit der Erstellung des Anforderungsdokumentes zu beginnen. Jedes Anforderungsdokument sollte zumindest aus vier Teilen bestehen, je einen Teil für jede Anforderungsform. In den folgenden Unterkapiteln wollen wir auf die Darstellung und Analyse der Anforderungen näher eingehen.

2.3.1

Informationsanforderungen

Informationsanforderungen beschreiben die Struktur und die Art der anfallenden Daten und eignen sich daher vorzüglich zur Durchführung einer strukturellen Analyse. Neben einer vollständigen Datenbeschreibung sind hier Angaben über die Integrität der Daten, Referenzen zwischen den Daten, gültige Wertebereiche sowie Abschätzungen über die Minimal- und Maximalkapazitäten der Datenelemente von Interesse. Informationsanforderungen beschreiben eine zeitunabhängige und damit rein statische Sicht auf die betrachtete Diskurswelt. Man geht davon aus, dass die erhobenen Anforderungen direkt aus den Erfordernissen der Realität entwickelt wurden, die aus ihnen abgeleiteten Datenstrukturen über einen längeren Zeitraum hinweg Bestand haben werden und für das Unternehmen daher eine bleibende Ressource darstellen. Aus diesem Grund kommt der strukturellen Analyse der erhobenen Anforderungen beim Datenbankentwurf eine zentrale Bedeutung zu. 2.3.1.1

Analyse der Informationsanforderungen

Aus den erhobenen Informationsanforderungen können drei grundlegende Konzepte hergeleitet werden: Gegenstand, Attribut, Beziehung. Ein Gegenstand ist ein reales oder abstraktes

34

2 Anforderungserhebung und -analyse

„Ding" (z.B. eine Person, ein Ereignis, ein Lagerartikel), das im Datenbanksystem gespeichert werden soll und für den Betreiber der Datenbank von Interesse ist. Ein Attribut ist eine elementare Eigenschaft eines Gegenstandes, die unterschiedliche Werte annehmen kann. Eine Beziehung beschreibt eine Assoziation zwischen Gegenständen. In der Folge werden wir auf diese grundlegenden Konzepte zur Strukturierung und Analyse statischer Informationsanforderungen genauer eingehen. Da in diesem Bereich eine große Begriffsvielfalt herrscht, werden wir bei der Erklärung der einzelnen Konzepte Synonyme, ähnlich verwendete Begriffe oder auch oft die englischsprachigen Bezeichnungen jeweils in Klammern angeben. Ein Entity (Gegenstand, Entität, Instanz, Objekt, Ausprägung) ist das zentrale Strukturierungskonzept einer Informationsanforderung und stellt eine Informationseinheit innerhalb der Diskurswelt dar. Jedes Entity hat beschreibende Eigenschaften, die Attribute (Eigenschaften, Merkmale, Charakteristika) genannt werden. Ein Entity aus der Diskurswelt eines KFZ-Unternehmens ist z.B. der Lagerartikel „Zylinderkopfdichtung", der durch die Merkmale Artikel-Nummer, Artikel-Bezeichnung, Einstandspreis, Motortyp, usw. beschrieben wird.

2.3.1.1.1

Attribut

Attribute sind die kleinsten Informationseinheiten und den Entities zugeordnet. Ein Entity besitzt für jedes seiner Attribute einen bestimmten Wert (value). Einige der erhobenen Attribute können möglicherweise noch weiter zerlegt werden. Ein Beispiel dafür ist ein Attribut „Lieferantenanschrift", das aus Straße, Hausnummer, Postleitzahl und Ort zusammengesetzt ist. Attribute, die aus mehreren Komponenten bestehen, heißen zusammengesetzte Attribute (composite attributes). Attribute, die nicht weiter zerlegt und jeweils nur einen einzigen Wert annehmen können, heißen atomare oder einwertige Attribute (single-valued attributes), während Attribute mit mehreren möglichen Werten für ein bestimmtes Entity mehrwertige Attribute (multi-valued attributes) heißen. Ein Beispiel für ein einwertiges Attribut ist z.B. das Merkmal „Einstandspreis" von Artikeln. Ein bestimmter Lagerartikel hat genau einen Einstandspreis. Ein Beispiel für ein mehrwertiges Attribut eines Entitytyps „Zylinderkopfdichtung" ist z.B. die Eigenschaft „Motortyp", sofern die Zylinderkopfdichtung in mehrere Motortypen (z.B. E30, E31, E33) eingebaut werden kann. Es kann auch vorkommen, dass ein bestimmtes Entity für ein Attribut keinen Wert besitzt. Das kann bedeuten, dass es nie einen Wert für dieses Attribut haben wird, oder dass dieser Wert zur Zeit nicht bekannt ist. In diesem Fall wird dem Attribut ein spezieller Wert, die so genannte „Nullmarke" (null-valued attribute) zugeordnet. Wird ein Attributwert in Abhängigkeit von bestimmten Ereignissen berechnet (wie z.B. Alter von Geburtsdatum und aktuellem Tagesdatum) oder von Werten anderer Attribute abgeleitet (z.B. Brutto von Netto und MwSt-Satz), so spricht man von abgeleiteten Attributen (derived attributes). Jedes Attribut besitzt einen zugeordneten Wertebereich (domain), der die Menge der Werte definiert, die für einen bestimmten Attributwert zulässig sind. Bestimmte Attribute können ausreichen, um ein Entity von allen anderen Entities zu unterscheiden. Solche Attribute besitzen eine identifizierende Eigenschaft (identifizierende Attribute). Abbildung 2.7 fasst die einzelnen Strukturierungsmerkmale für Attribute nochmals zusammen.

35

2.3 Anforderungsdokument einfach / zusammengesetzt atomar (einwertig) / mehrwertig Nullwert möglich / nicht möglich nicht abgeleitet / abgeleitet nicht identifizierend / identifizierend

Abb. 2.7: Strukturierungsmerkmale flir Attribute

2.3.1.1.2

Entity typ

Entities mit ähnlichen Eigenschaften werden zu einem Entitytyp (Gegenstandstyp, Objekttyp, Entitätsklasse) zusammengefasst. Ein Entity ist somit eine Ausprägung oder Instanz eines bestimmten Entitytyps. Ein Entitytyp besteht aus η unterschiedlichen Attributen, während ein Entity dieses Typs durch η Attributwerte beschrieben wird. Beispiel 2.5:

Typ vs. Ausprägungsebene

(Entitytyp)

Wir betrachten einen Entitytyp „Lagerartikel" mit den Eigenschaften Artikelnummer (Artikel-Nr), Bezeichung (Α-Bezeichnung), Standort und Fahrzeugtyp. Abbildung 2.8 zeigt das unterschiedliche Abstraktionsniveau anhand exemplarischer Ausprägungen.

Artikel (Artikel-Nr, Α-Bezeichnung, Standort, Fahrzeugtyp,...)

10752-1, 27392-7, 32791-2,

Zylinderkopfdichtung, Lenkgetriebe, Bremszylinder,

H37D001, D02H123, D07H007,

{E30, E31, E35}, {E31}, {E30, E31},

r Entitytyp

y Entities

Abb. 2.8: Entitytyp mit Ausprägungen

Eine wichtige Eigenschaft von Entities eines bestimmten Typs ist Eindeutigkeit und damit verbunden Unterscheidbarkeit von anderen Entities desselben Typs und Identität von Entities. Ein Gegenstand oder ein Ereignis der Diskurswelt sollte als genau ein Entity eines bestimmten Typs dargestellt sein. Diese Forderung bildet die Grundlage für eine der wichtigsten Eigenschaften von Datenbanken, nämlich dass ein identifizierbares Ereignis der Realität nur mit einem einzigen Identifikator in der Datenbank gespeichert sein darf (l:l-Abbildung zwischen Diskurswelt und seiner Repräsentation in der Datenbank). Da wir in der Realwelt zwischen Gegenständen unterscheiden können (sie besitzen quasi eine Identität), ist diese Unterscheidbarkeit zur Gewährleistung einer eindeutigen Abbildung auch für Datenbankobjekte gefordert. In der Realwelt unterscheiden wir zwischen unterschiedlichen Gegenständen aufgrund unterschiedlicher Eigenschaften (z.B. den Lieferanten aus Essen von dem aus Düsseldorf, das Cabrio vom Mini-Van, das rote Auto von dem Auto mit grüner Farbe). Um diese Unterscheidung auch in der Datenbank zu gewährleisten, muss jeder Entitytyp über identifizierende Attribute verfügen.

2 Anforderungserhebung und -analyse

36

Werte identifizierender Attribute (Schlüsselattribute) sind immer für alle Entities eines bestimmten Typs unterschiedlich. Manchmal bilden erst mehrere Attribute gemeinsam die identifizierende Eigenschaft, und manchmal gibt es auch verschiedene Attribute, die Entities eindeutig bestimmen. Identifizierende Eigenschaften sind in den meisten Datenbankmodellen von zentraler Bedeutung. Wir werden im Unterkapitel 3.6 nochmals auf sie zurückkommen und ihre Eigenschaften aus einem formaleren Blickwinkel betrachten. 2.3.1.1.3

Beziehungstyp

Beziehungstypen (relationship types, Assoziationstypen) beschreiben Beziehungen und Zusammenhänge zwischen Entitytypen. Eine Beziehung (relationship, Assoziation) ist eine bestimmte Instanz eines Beziehungstyps und beschreibt die individuellen Zusammenhänge zwischen Entities. Beispiel 2.6:

Typ- vs. Ausprägungsebene

(Beziehungstyp)

In Abbildung 2.9 zeigen wir den Unterschied zwischen Typebene und Ausprägungsebene für Beziehungstypen. Über den Beziehungstyp „liefert" werden Lieferanten zu Artikeln (und umgekehrt) in Beziehung gesetzt. Jede Ausprägung des Beziehungstyps beschreibt eine Zuordnung eines spezifischen Lieferanten zu allen Artikeln, die er liefert bzw. für einen bestimmten Artikel zu allen Lieferanten, die diesen Artikel im Programm haben. Beziehungstypen können auch Eigenschaften besitzen, wie in dem Beispiel das Attribut „Preis", das den Preis eines ausgewählten Artikels bei einem bestimmten Lieferanten beinhaltet.

Lieferant (Lief Nr, LiefName, Anschrift)

Artikel

Abb. 2.9: Beziehungstyp ,,liefert" mit Ausprägungen Als den Grad (degree, Stelle) eines Beziehungstypen bezeichnet man die Anzahl der an der Beziehung beteiligten Entitytypen. Beziehungstyp „liefert" aus Abbildung 2.9 ist vom Grad 2 (binäre Beziehung). Beziehungen können auch vom Grad 1 (rekursive Beziehung) oder n-äre Beziehungen (η Entitytypen sind an der Beziehung beteiligt) sein. Abhängig von der Art der Teilnahme der Entities an der Beziehung kann ein Beziehungstyp eine optionale oder

37

2.3 Anforderungsdokument

eine totale Teilnahme festlegen. Bei einem totalen Beziehungstyp müssen alle Entities eines bestimmten Typs an einer Beziehung teilnehmen, während bei einem optionalen Beziehungstyp die Teilnahme an einer Beziehung für Ausprägungen des betroffenen Entitytyps freigestellt ist. Bei optionalen Beziehungstypen hatten wir den Fall, dass ein Entity entweder einmal oder eben keinmal an der entsprechenden Beziehung teilnimmt. Diesen Fall kann man verallgemeinern, indem man die Kardinalität (cardinality ratio, Komplexität) von Beziehungstypen einführt. Typische Kardinalitätsangaben sind (1:1), (1:N), (N:l) oder (N:M) und beschreiben die Anzahl von Entities, die maximal an einer Beziehung teilnehmen können. Ein Beispiel für eine Beziehung der Form (1:1) ist (Artikelart: Verpackungsart) mit der Semantik, dass ein Artikel eines bestimmten Typs immer genau die Verpackung einer bestimmten Art bekommt, und dass zwei Artikel unterschiedlichen Typs nie eine Verpackung desselben Typs haben können. Eine Beziehung der Form (1:N) stellt z.B. die Zuordnung zwischen Abteilung und Mitarbeiter dar. Ein bestimmter Mitarbeiter ist genau einer Abteilung zugeordnet, aber eine Abteilung besteht aus mehreren Mitarbeitern. Der in Abbildung 2.9 dargestellte Beziehungstyp „liefert" besitzt die Kardinalität (N:M), da ein bestimmter Artikel von unterschiedlichen Lieferanten bezogen werden kann und ein Lieferant mehrere Artikel in seinem Programm hat. Jeder Entitytyp, der an einem Beziehungstyp teilnimmt, nimmt an der Beziehung in einer entsprechenden Rolle teil. Die Zuordnung von Rollenbezeichnungen ist nicht immer einfach, da eine sinnvolle Rollenbezeichnung von der Leserichtung der Beziehung abhängig ist. Entities eines bestimmten Typs können miteinander auch in mehrfachen Beziehungen stehen. Ein Beispiel dafür sind die zwei Beziehungen „ist-zugeordnet" und „leitet" zwischen den Entitytypen „Mitarbeiter" und „Abteilung". Der erste Beziehungstyp repräsentiert die Semantik, welche Mitarbeiter welchen Abteilungen zugeordnet sind, und der zweite Beziehungstyp setzt den Mitarbeiter, der die betrachtete Abteilung leitet, in Relation zur Abteilung. Die unterschiedlichen Strukturierungsmerkmale für Beziehungstypen sind in Abbildung 2.10 zusammengefasst. Grad optional / total Kardinalität Rollen mit / ohne Attribute

Abb. 2.10: Strukturierungsmerkmale

für

Beziehungstypen

In einer ersten Analyse der Informationsanforderungen (siehe dazu auch Kapitel 3.1) werden Kandidaten für Entitytypen, Beziehungstypen und Attribute ermittelt. In einem nachfolgenden Schritt werden die Integritätsbedingungen festgelegt. Integritätsbedingungen sind Prädikate, die die Menge der Ausprägungen eines bestimmten Typs einschränken. Beispiele für mögliche Integritätsbedingungen auf Ebene der Attribute sind das Festlegen bestimmter Wertebereiche, Existenzabhängigkeiten (gültige Werte eines Attributes müssen als Attributwert bereits in einem anderen Entity existieren) und Beziehungen zwischen Attributwerten innerhalb eines Entities. Beispiele für Integritätsbedingungen auf Ebene der Entitytypen sind Schlüsselbedingungen für die Gewährleistung von Eindeutigkeit, Existenzabhängigkeiten von Entities

38

2 Anforderungserhebung und -analyse

unterschiedlicher Typen oder Sicherheitseinschränkungen. Integritätsbedingungen für Beziehungstypen werden durch den Grad, die Kardinalität und die Art der Teilnahme beteiligter Entities an der Beziehung beschrieben. Um die definierten Begriffe zu verdeutlichen, betrachten wir zunächst eine vereinfachte Darstellung der Informationsanforderungen eines typischen Bestellvorganges. Auf dieses Beispiel werden wir später wieder zurückkommen.

Beispiel 2.7:

Informationsanforderungen an einen Bestellvorgang

Ein Handelsunternehmen vergibt Bestellaufträge an Lieferanten. Aufträge bestehen aus Auftragspositionen, die wiederum genau einem bestellten Artikel entsprechen. Nach Durchführung der Lieferung schickt der Lieferant eine Rechnung, die unterschiedliche Rechnungspositionen aufweist. In der hier verwendeten vereinfachten Darstellung sind Aufträge durch eine eindeutige Auftragsnummer (Auftrags-Nr) und durch das Auftrags-Datum beschrieben. Jede Auftragsposition bezeichnet den bestellten Artikel über seine eindeutige Artikel-Nr, die Artikel-Bezeichnung und seinen Preis. Des Weiteren enthält jede Auftragsposition noch die Bestellmenge (Anzahl). Über Lieferanten soll in der Datenbank der Name

Kandidaten für Entitvtvpen: Auftrag:

Auftrags-Nr, Auftrags-Datum

Auftragsposition:

Artikel-Nr, Artikel-Bezeichnung, Anzahl, Preis

Lieferant:

Lief-Nr, Lief-Name, Anschrift, Konto-Nr

Rechnung:

Rech-Nr, Rech-Betrag, Steuersatz, Zahlungsart

Rechnungsposition:

Artikel-Nr, Artikel-Bezeichnung, Anzahl, Preis

Artikel:

Artikel-Nr, Artikel-Bezeichnung, Standort

Kandidaten für Beziehungstvpen: "Geht-an":

Auftrag: Lieferant (Ν: 1) Ein Auftrag geht an einen bestimmten Lieferanten und ein Lieferant kann mehrere Aufträge erhalten.

"Enthält":

Auftrag: Auftragsposition, (1:N) Ein Auftrag besteht aus mehreren Auftragspositionen. Eine Auftragsposition ist genau einem Auftrag zugeordnet.

"Verweist-auf":

Auftragsposition: Artikel, (Ν: 1) Jede Auftragsposition verweist auf genau einen Artikel. Ein bestimmter Artikel kann jedoch in mehreren Positionen vorkommen.

"legt":

Lieferant: Rechnung, (1 :N) Jede Rechnung ist genau einem Lieferanten zugeordnet. Es können jedoch von einem Lieferanten mehrere Rechnungen existieren.

"Besteht-aus":

Rechnung: Rechnungsposition, (1 :N ) Jede Rechnung besteht aus mehreren Rechnungspositionen und jede Position ist genau einer Rechnung zugeordnet.

"Entspricht":

Rechnungsposition: Auftragsposition, (1:1) Jeder Rechnungsposition ist genau eine Auftragsposition zugeordnet und

Abb. 2.11: Teil der Informationsanforderungen

an Entitytyp

,.Auftrag"

39

2.3 Anforderungsdokument

1. Beschreibung des Entitytyps: Name: Geschätzte Anzahl: Integritätsbedingungen: Beschreibung: 2. Beschreibung der Attribute: Attributname: Beschreibung: Wertebereich: Wertebereichseinschränkungen: Wertemenge: Prädikate: Referentielle Abhängigkeiten: Null-Wert erlaubt? Wiederholungsfaktor der Werte des Entitytyps: Anzahl eindeutiger Werte im Entitytyp: Primärschlüssel (Ja/Nein): Abhängigkeiten mit weiteren Attributen: Auftrags-Datum 3. Beschreibung der Beziehungstypen: Beziehungsname: Beschreibung des Beziehungstyps: Teilnehmende Entitytypen: Kardinalität der Beziehung: Verbindung (mit allen Beteiligten Entitytypen): Obligatorisch / Optional: Attribute des Beziehungstyps: Attributname: Beschreibung Wertebereich: Einschränkungen des Wertebereichs: Wertemenge: Prädikate: Referentielle Abhängigkeiten: Null-Wert erlaubt? Wiederholungsfaktor der Werte des Beziehungstyps: Anzahl eindeutiger Werte des Beziehungstyps:

Abb. 2.11: Teil der Informationsanforderungen an Entitytyp,,Auftrag"

Auftrag 10.000 -

eingehende Aufträge Auftrags-Nr Eindeutige Nummer 1 -99999 Ganze Zahlen -

Keine Nein Keine Wdh. -

Ja

Geht-an Auftrag geht an Lieferanten Auftrag; Lieferant Ν: 1 Kunde Obligatorisch Keine -

(Fortsetzung)

(Lief-Name), eine fortlaufende Nummer als Identifikator (Lief-Nr), ihre Anschrift und ihre Kontonummer (Konto-Nr) gespeichert werden. Rechnungen haben eine eindeutige Rechnungsnummer (Rech-Nr), weisen einen Endbetrag (Rech-Betrag) und einen Steuersatz auf und geben eine Zahlungsart vor. Jede Rechnungsposition muss einer Auftragsposition entsprechen. Über die bestellten Artikel soll die Artikelnummer (Artikel-Nr), ihre Bezeichnung und der Standort des Artikels im Lager gespeichert werden. Aus diesen Informationsanforderungen lassen sich Kandidaten für Entitytypen und Beziehungstypen, wie in Abbildung 2.11 dargestellt, herleiten.

Um zu einer besseren Darstellungsform zu gelangen, werden die Eigenschaften von Entitytypen und Beziehungstypen in einem Datenanforderungsformular (Entity-Katalog) als Teil des Anforderungsdokumentes eingetragen. In der Praxis geht die Analyse der erhobenen Informationsanforderungen mit der strukturorientierten Modellbildung (siehe Unterka-

40

2 Anforderungserhebung und -analyse

pitel 3.1) einher. Die Informationen aus den Datenanforderungsformularen werden in ein Entity-Relationship-Modell übertragen, und die Entitykataloge dienen der näheren Beschreibung der Entity-Relationship-Diagramme. Abbildung 2.11 zeigt anhand einer Auswahl der Anforderungen an den Entitytyp „Auftrag" eine mögliche Strukturierung eines Datenanforderungsformulars. Die Entscheidung, ob ein Ereignis der Realität als Entitytyp, als Beziehungstyp oder als Attribut dargestellt werden soll, ist nicht immer einfach und hängt oft von der subjektiven Einschätzung des Systemanalytikers ab. Das bedeutet, dass es oft die alleinig richtige Lösung nicht gibt, und dass ein Ereignis der Realwelt unterschiedlich modelliert werden kann. Bevor wir einige informelle Richtlinien zur Herleitung von Entitytypen, Beziehungstypen und Attributen besprechen werden, wollen wir auf Beispiel 2.7 noch einmal kurz eingehen, um unsere Entwurfsentscheidungen zu argumentieren. Dem Leser könnten bei der Analyse der Informationsanforderungen folgende Fragen durch den Kopf gegangen sein: •

Warum kommt das betrachtete Handelsunternehmen nicht vor? Weder in Form eines Entity typs noch als Attribut wird auf das betrachtete Unternehmen eingegangen. Das Unternehmen kommt nicht vor, da wir ein einziges Unternehmen betrachten, dessen Einkaufsabteilung Bestellungen zentral vornimmt. Würden wir in das Beispiel Filialen aufnehmen, die selbstständig Bestellungen durchführen können, so wäre die Aufnahme eines Entitytyps „Filiale" mit für Filialen spezifischen Eigenschaften sinnvoll.

•

Warum reicht es aus, den Standort eines Artikels im Lager über ein einziges Attribut abzubilden? Wäre es nicht sinnvoll, einen eigenen Entitytyp zu erzeugen und ihm zusätzliche Eigenschaften zu geben? Das wäre eine sinnvolle Lösung, wenn das betrachtete Handelsunternehmen mehrere Lagerstätten hätte und jedes Lager mit individuellen Eigenschaften beschrieben ist. In unserer vereinfachten Darstellung gehen wir jedoch nur von einem einzigen Lager aus, und in diesem Lager hat jeder Artikel ausschließlich einen Standort. Des Weiteren gibt es keine zusätzlichen Hinweise über Eigenschaften, die den Standort betreffen (wie z.B. die Kapazität).

•

Ist es notwendig, Auftrag und Auftragsposition bzw. Rechnung und Rechnungsposition als jeweils einzelne Entitytypen zu modellieren? Würde es nicht ausreichen, Auftrag und Auftragsposition als einen einzigen Entitytyp (z.B. als Bestellung) zusammenzufassen? Dies wäre nur dann sinnvoll, wenn die Auftrags-Nr und das Auftrags-Datum direkt der Bestellung zugeordnet wären. Wäre dies nicht der Fall, dann müssten sie für η Auftragspositionen η — lmal redundant mitgeführt werden.

•

Warum war es notwendig, einen Entitytyp „Auftrag" einzuführen? Wäre es nicht sinnvoller gewesen, zwischen dem Entitytyp „Lieferant" und dem Entitytyp „Lagerartikel" einen Beziehungstyp „liefert" einzuführen? Der Beziehungstyp könnte die relevanten Attribute wie Auftrags-Nr, Auftrags-Datum, Artikel-Nr, Artikel-Bezeichnung, Anzahl und Preis beinhalten? Das wäre durchaus eine akzeptable Lösung, die jedoch zwei wesentliche Probleme beinhalten würde. Erstens würde die Information über Auftrags-Datum wieder redundant für

2.3 Anforderungsdokument

41

mehrere Auftragspositionen gespeichert werden, und zweitens wäre es nicht mehr möglich, Auftragspositionen direkt Rechnungspositionen zuzuordnen. Dies ist dann sinnvoll, wenn man die Bezahlung von Teillieferungen vorsieht, die fällig werden, bevor der Rest des Auftrags zu bezahlen ist. In diesem Beispiel könnten dem sorgfältigen Leser möglicherweise auch unerwünschte Redundanzen aufgefallen sein: •

Warum wird Anzahl und Preis in den Entitytypen „Auftragsposition" und in „Rechnungsposition" und Artikel-Bezeichnung in Entitytypen „Auftragsposition", „Rechnungsposition" und „Artikel" geführt? Auch das könnte zumindest zwei Ursachen haben. Zum einen könnte es sich um abgeleitete Attribute handeln, zum anderen könnte es der Fall sein, dass die Bezeichnungen in den Produktkatalogen des Lieferanten mit den Bezeichnungen, wie sie im betrachteten Handelsunternehmen verwendet werden, nicht übereinstimmen.

2.3.1.2

Vorgehensweisen für die statische Analyse

Zur Analyse von Informationsanforderungen (Strukturanalyse, statische Analyse) sind prinzipiell zwei Vorgehensstrategien möglich: Top-down und Bottom-up. Die Top-down-Strategie geht von im Problemraum erkannten Entitytypen aus, denen Attribute und Beziehungstypen hinzugefügt werden. Die Bottom-up-Strategie geht von bekannten Informationseinheiten aus, aus denen dann Entitytypen und Beziehungstypen gebildet werden. Wie wir bereits gesehen haben, ist die Entscheidung für ein bestimmtes Strukturierungskonzept oft von der subjektiven Einschätzung des Systemanalytikers abhängig und nicht immer leicht nachvollziehbar. Aus der Literatur sind jedoch einige Regeln und Ratschläge bekannt, die neben der Erfahrung des Analytikers mithelfen, aus den Anforderungsspezifikationen Entitytypen, Beziehungstypen und Attribute zu erkennen. Bevor man für die Darstellung eines erhobenen Sachverhaltes die endgültige Entscheidung für ein bestimmtes Strukturierungsprinzip vornimmt, ist es oft sinnvoll, vorerst Kandidaten aufzustellen und die Wahl durch typische Beispiele zu belegen. Entitytyp-Kandidaten sind meist Entitytypen, wenn sie entweder reale oder abstrakte Objekte des betrachteten Problemraumes (wie z.B. Unternehmen, Abteilungen, Kostenstellen, Konten, Artikel), natürliche Personen (wie z.B. Mitarbeiter, Kunden, Lieferanten), wichtige Ereignisse (wie z.B. Rechnungsabschluss, Inventur, Bilanz, Geschäftsberichte) oder allgemein gültige Grundsätze und Gepflogenheiten (wie z.B. Zahlungsbedingungen, Rechtsvorschriften, Handelswaren,...) darstellen. Entitytyp-Kandidaten sind Entitytypen, wenn sie eine eigene Bedeutung besitzen, d.h. wenn sie durch weitere Eigenschaften beschrieben sind und sich ihre Ausprägungen voneinander unterscheiden. Entitytyp-Kandidaten werden nicht zu Entitytypen, wenn sie das Ergebnis von Berechnungen oder Funktionen darstellen (wie z.B. Auswertungen oder Statistiken) und nur als Ergebnis und nicht als eigenständiges Objekt im Realitätsausschnitt Bedeutung finden. Sind einmal Entitytypen identifiziert, kennt man in vielen Fällen bereits auch die meisten Attribute, die den jeweiligen Entitytyp näher charakterisieren. Nichtidentifizierende Attribute besitzen keine Identität. Darunter verstehen wir, dass die Existenz eines Attributwertes nur nach Zuordnung zu einem Entity Sinn macht, und dass die Attribute auch nicht durch weitere Eigenschaften näher beschrieben werden.

2 Anforderungserhebung und -analyse

42

Beziehungstypen kann man erkennen, indem man die gefundenen Entitytypen einander gegenüberstellt und nach in der Realität existierenden Verknüpfungsaussagen untersucht. Das Herleiten von binären Beziehungstypen ist so über paarweise Betrachtungen von Entitytypen leicht möglich, das Herleiten von w-ären Beziehungstypen gestaltet sich schwieriger. Da Beziehungstypen auch Attribute besitzen können, die Beziehungen näher spezifizieren, ist genau abzuwägen, ob die Attribute nun Eigenschaften des Beziehungstyps oder Eigenschaften der an der Beziehung beteiligten Entitytypen darstellen. Auch hier ist schließlich die Erfahrung des Systemanalytikers gefordert. In der Praxis geht die Analyse der statischen Anforderungen mit der strukturorientierten Modellbildung (siehe Unterkapitel 3.1) einher. Für eine detailliertere Analyse und weiterführende Modellbildung wird dann sehr oft das Entity-Relationship-Modell eingesetzt, das auf die hier beschriebenen Konzepte aufbaut.

2.3.2

Funktionale Anforderungen

Funktionale Anforderungen spezifizieren die betrieblichen Funktionen, die ein System oder eine Systemkomponente erfüllen bzw. zur Verfügung stellen muss. Dabei werden betriebliche Vorgänge algorithmisch beschrieben. Der besondere Schwerpunkt liegt auf der Transformation von Eingabegrößen durch Prozesse in Ausgabegrößen. Im Rahmen der Analyse der funktionalen Anforderungen (funktionsorientierte Modellbildung) ist es erwünscht, einen Überblick über die Prozessaktivitäten im geplanten System zu gewinnen. Dabei interessiert vorerst nicht die zeitliche Reihenfolge der Abarbeitung unterschiedlicher Prozesse sondern eher die Frage „Was leistet der Prozess?" oder die Frage „Wie erreicht ein Prozess sein Ziel?". Um komplexe Systeme analysieren und besser beschreiben zu können, unterstützen die meisten Verfahren zur Analyse funktionaler Anforderungen unterschiedliche Abstraktionsebenen (Verdichtungsebenen), auf denen unter Verwendung unterschiedlicher Detaillierungsgrade betriebliche Abläufe von ihrer Entstehung bis hin zu ihrer Beendigung beschrieben werden können. Die Analyse der funktionalen Anforderungen ist im Rahmen des Datenbankentwurfes aus zwei Gründen von Bedeutung: Zum einen fließen funktionale Anforderungen in eine struktur- und funktionsorientierte Modellbildung (siehe Unterkapitel 3.2) direkt ein, zum anderen bilden funktionale Anforderungen für viele implementationstechnische und physische Entwurfsentscheidungen eine wichtige Grundlage. 2.3.2.1

Analyse mit Datenflussdiagrammen

Funktionale Anforderungen werden als Funktionsmodell beschrieben. Funktionsmodelle bestehen i.a. aus einem oder mehreren Datenflussdiagrammen, die den Datenfluss beginnend von externen Eingaben über unterschiedliche Prozesse und interne Datenspeicher bis hin zu externen Ausgaben zeigen. Ein Datenflussdiagramm (DFD) ist eine graphische Darstellungsform funktionaler Anforderungen. Es besteht aus vier grundlegenden Konzepten: Prozesse, die Daten transformieren, Datenflüsse, die Daten bewegen, Datenspeicher, die anzeigen, dass Daten auf Externspeicher abgelegt werden, und Akteure, die Daten generieren und konsumieren. Die verwendete Notation in DFD weicht bei verschiedenen Autoren voneinander ab. Prozesse werden entweder als Kreise, Ellipsen oder Rechtecke mit abgerundeten Ecken dargestellt.

43

2.3 Anforderungsdokument

Einige Autoren unterscheiden explizit zwischen Datenfluss, Materialfluss und Kontrollfluss und verwenden für ihre Darstellung unterschiedliche Arten von Pfeilen. Andere Autoren treffen diese Unterscheidung nicht und sprechen allgemein von „Wertfluss". Datenspeicher werden entweder durch zwei parallele Linien oder durch Rechtecke mit offenen rechten Seiten dargestellt. Akteure werden meist in Form von Rechtecken gezeichnet. Die in diesem Buch gewählte Notation zur Darstellung von DFD wird in Abbildung 2.12 zusammengefasst. Datenspeicher

Prozess

Akteur

Nr. Nr.

Bezeichnung

Bezeichnung ausgeführt_von

Datenfluss Bezeichnung

Abb. 2.12: Elemente im Datenflussdiagramm

Prozesse sind für die Datentransformation verantwortlich. In Abhängigkeit vom gewählten Detaillierungsgrad wird ein Prozesssymbol entweder zur Darstellung einer Folge von Arbeitsschritten benutzt, die innerhalb einer Funktionseinheit anfallen, oder jeder einzelne Arbeitsschritt wird selbst als ein eigener Prozess dargestellt. Gezeichnet werden Prozesse als Rechtecke mit abgerundeten Ecken. Jeder Prozess hat eine Nummer, die auf eine nicht im Diagramm enthaltene detaillierte Prozessbeschreibung verweist und den Prozess näher erläutert, eine Bezeichnung und einen Vermerk, wer den Prozess ausführt. Die ausführende Stelle kann entweder eine Person in einer bestimmten Funktion, ein Anwendungsprogramm oder aber auch eine Organisationseinheit sein. Die Nummerierung der Prozesse kann ein Hinweis auf eine zeitliche Abfolge sein. Jeder Prozess hat eine feste Anzahl einmündender und entspringender gerichteter Kanten, die Datenflüsse beschreiben und von denen jeder einen Wert eines bestimmten Typs befördert. Jede Kante kann beschriftet sein und somit die Rolle der über diese Kante fließenden Daten bei der Transformation bezeichnen. Beispiel 2.8:

Prozess im Datenflussdiagramm

In Abbildung 2.13 zeigen wir die graphische Darstellung von Prozessen in DFD. Im Prozess „Erhöhe Lagerbestand" wird ausgehend von einem bestehenden Lagerbestand, einem Lieferumfang (Anzahl) und einer Artikelnummer (Artikel-Nr) der aktualisierte Lagerbestand des bezeichneten Artikels berechnet. Datenspeicher sind die passiven Elemente in einem DFD. Sie führen Operationen nicht selbstständig aus, sondern reagieren ausschließlich auf Anforderungen zum Speichern und Einlesen von Daten. Über Datenspeicher ist es möglich, auf Daten in beliebiger Reihenfolge zuzugreifen. Datenspeicher können z.B. Karteien, Verzeichnisse oder aber auch Tabellen in Datenbanken sein. Die geplante technische Realisierung eines Datenspeichers ist zu diesem Zeitpunkt noch nicht von Bedeutung.

44

2 Anforderungserhebung und -analyse /•

Ν P1

Artikel-Nr Lagerbestand

Erhöhe

Lagerbestand

Lagerbestand Anzahl LaBeweg

V Abb. 2.13: Prozess im

Datenflussdiagramm

Datenspeicher werden durch ein auf der rechten Seite offenes Rechteck dargestellt und mit einer Bezeichnung und einer Nummer gekennzeichnet. Die Nummer verweist auf beschreibenden Text, der nicht in die graphische Darstellung des DFD aufgenommen wird. Am Datenspeicher entspringende gerichtete Kanten geben die Richtung an, in die der Datenfluss stattfindet. Einmündende Kanten deuten Schreiboperationen im Datenspeicher an, mit denen abgelegte Informationen ergänzt oder verändert werden. Ausgehende Kanten weisen auf Leseoperationen hin, mit denen Informationen aus dem Speicher gelesen werden. Beispiel 2.9:

Datenspeicher im Datenflussdiagramm

Zwei Beispiele für die Verwendung von Datenspeichern in Datenflussdiagrammen sind in Abbildung 2.14 dargestellt. In Abbildung 2.14(a) wird ein DFD zur Berechnung des aktuellen Lagerbestandes angegeben, in dem der alte Lagerbestand aus dem Artikelverzeichnis gelesen wird, Prozess PI den neuen Lagerbestand berechnet und diesen im Artikel Verzeichnis ablegt, um ihn dann noch an weitere Prozesse (z.B. Kostenrechnung) zur Weiterverarbeitung zu übergeben. Abbildung 2.14(b) zeigt das Eintragen von Außenständen in ein Datenverzeichnis für offene Rechnungen. Prozess P2 „Rechnung erstellen" erzeugt aus Bestelldaten und Kundendaten Rechnungen und schreibt sie in den Datenspeicher D2.

D1

P1

Artikel-Nr

Kundendaten Bestelldaten

Lagerbestand LaBeweg

,

f

P2

^ Rechnungen

Rechnung erstellen

w

„

(a) Abb. 2.14: Datenspeicher im

w

Lagerbestand ,

Erhöhe .

Außenstände

ET

3

Anzahl

D2

Artikelverzeichnis

Faktura

w

J

(b)

Datenflussdiagramm

Akteure stellen die aktiven Komponenten in einem DFD dar. Sie aktivieren einen Datenfluss im System, indem sie Werte erzeugen, und beenden einen Datenfluss, indem sie Werte ver-

2.3 Anforderungsdokument

45

brauchen. Aus diesem Grund sind die Bezeichnungen Quelle und Senke bzw. Initiatoren und Terminatoren für Akteure ebenso gebräuchlich. Akteure sind somit Sender und Empfänger von Informationseinheiten und folglich an den Ein- und Ausgängen von DFD angeordnet. Graphisch werden sie als Rechtecke dargestellt. Pfeile zwischen Akteuren und dem DFD bezeichnen Eingaben an und Ausgaben durch das Diagramm. Beispiel 2.10:

Akteure im Datenflussdiagramm

Wir betrachten Lieferanten als Akteure, weil sie jedes Mal, wenn sie neue Lieferungen anbringen, einen Datenfluss in Form von Artikel-Nr und der gelieferten Stückzahl initiieren. In Abbildung 2.15 ist eine entsprechende Situation dargestellt.

Abb. 2.15: Akteure im

Datenflussdiagramm

Datenflüsse verbinden Prozesse, Datenspeicher und Akteure und werden üblicherweise als gerichtete Kanten zwischen Erzeuger und Verbraucher im Datenflussgraph dargestellt. Die Kanten sind mit der Bezeichnung der Daten markiert. Oft wird auch zwischen Datenfluss und Materialfluss unterschieden. Ein Datenfluss kann an mehrere Verbraucher gehen, bzw. aus unterschiedlichen Werten kann ein Datentyp einer höheren Aggregationsstufe erzeugt werden. Daten können während des Datenflusses jedoch nicht verändert werden. Beispiel 2.11:

Formen von Wertfluss im Datenflussdiagramm

In Abbildung 2.16 zeigen wir (a) das Kopieren, (b) das Verzweigen und (c) das Bilden eines Datenaggregates in Datenflüssen. In Abbildung 2.16(d) unterscheiden wir explizit zwischen Materialfluss und Datenfluss, indem wir für ihre Darstellung unterschiedliche Pfeiltypen verwenden. Für die Analyse großer und komplexer Systeme werden in der Literatur unterschiedliche Strategien und Vorgehensweisen vorgeschlagen. Auch hier gibt es keine optimale Strategie. Für jedes Problem ist neu zu prüfen, welche die geeignetste Vorgehensweise ist. Prinzipiell unterscheidet man zwischen Vorgehensweisen, die von einem ersten Grobentwurf ausgehen und in mehreren Verfeinerungsschritten ein Feinkonzept entwickeln (Top-down-Verfahren), die von bekannten Elementprozessen ausgehen und daraus ein funktionales Modell auf hohem Abstraktionsniveau erzeugen (Bottom-up-Verfahren), Mischformen aus Top-down- und Bottom-up-Vorgehensweisen und Inside-out-Strategien, die innerhalb einer Aufgabenstellung

46

2 Anforderungserhebung und -analyse

Abb. 2.16: Formen von Wertfluss im

Datenflussdiagramm

beginnen und versuchen, alle nötigen Prozesse, Datenspeicher, Datenflüsse und Terminatoren, die zur Lösung des Problems notwendig sind, herzuleiten. Alle Strategien bestehen aus einer Menge von Schematransformationen, die ein Ausgangsschema in ein Ergebnisschema transformieren. Bevor wir auf die unterschiedlichen Vorgehensweisen zur funktionalen Analyse eingehen werden, fassen wir in Abbildung 2.17 die wichtigsten Schematransformationen für DFD zusammen: Schematransformation Ti spaltet einen Prozess in zwei Prozesse auf. Dies ist notwendig, wenn festgestellt wird, dass innerhalb eines Prozesses eine detailliertere Darstellung gewünscht wird und der Datenfluss zwischen Subprozessen dargestellt werden soll. •

Schematransformation T2 verfeinert einen Prozess durch Aufspaltung in zwei Prozesse und einen Datenspeicher. Dies wird notwendig, wenn zwei Teilprozesse Daten zu einem unterschiedlichen Zeitpunkt benötigen und daher Zwischenspeichern müssen.

•

Schematransformation T3 verfeinert einen Prozess durch Aufspaltung in zwei unabhängige Prozesse, die nicht über einen Datenaustausch in Beziehung stehen.

•

Schematransformation T4 spaltet einen Datenfluss in mehrere unabhängige Datenflüsse. Diese Transformation wird angewendet, wenn festgestellt wird, dass die über die Kante fließenden Daten voneinander unabhängige Informationseinheiten darstellen.

•

Schematransformation T 5 verfeinert einen Datenfluss in zwei Datenflüsse und einen Prozess. Sie wird notwendig, wenn festgestellt wird, dass der Datenfluss im Ausgangsschema eine verdeckte Transformation beinhaltet.

•

Schematransformation Tö verfeinert einen Datenspeicher in mehrere unabhängige Datenspeicher. Sie wird notwendig, wenn festgestellt wird, dass unterschiedliche Prozesse auf voneinander unabhängige Teile des Datenspeichers im Ausgangsschema zugreifen.

•

Schematransformation T7 verfeinert einen Datenspeicher durch Aufspaltung in mehrere Datenspeicher und einen weiteren Prozess. Sie wird notwendig, wenn festgestellt wird, dass im Datenspeicher des Ausgangsschemas verdeckte Datentransformationen stattfinden.

2.3 Anforderungsdokument

Schematransformation

47

Ausgangsschema

Ergebnisschema

T, : Prozessverfeinerung mit Datenfluss

T 2 : Prozessverfeinerung mit mehrfach genutztem Datenspeicher

T 3 : Verbinduiigslose Prozessverfeinerung

T„: Datenflussverfeinerung

T 5 : Transformation von Datenfluss

T 6 : Teilung von Datenspeicher

T,: Erzeugung neuer Datenspeicher

Abb. 2.17: Schematransformationen

in Datenflussdiagrammen

nach [BaCN92]

2 Anforderungserhebung und -analyse

48 2.3.2.2

Vorgehensweisen für die funktionale Analyse

Ähnlich wie bei der Analyse von Informationsanforderungen können bei der Analyse funktionaler Anforderungen unterschiedliche Vorgehensweisen angewendet werden. Wir wollen drei dieser Vorgehensweisen anhand eines Beispiels genauer betrachten. 2.3.2.2.1

Top-down-Vorgehensweise

Das Top-down-Verfahren ist die am häufigsten zur Anwendung kommende Vorgehensweise. Man beginnt mit einem so genannten Kontextdiagramm, das die betriebliche Aufgabenstellung auf einem sehr hohen Abstraktionsniveau zeigt. In den meisten Fällen besteht das Kontextdiagramm aus einem zentralen Prozess und seinen Schnittstellen nach außen. Zumindest ein Initiator und ein Terminator sind notwendig. In weiteren Schritten wird der Elementarprozess in Teilprozesse zerlegt. Dabei sollte man so vorgehen, dass zuerst jene Prozesse gespalten werden, die die wenigsten Datenströme referenzieren. Der Schritt der Verfeinerung wird so lange fortgesetzt, bis der gewünschte Abstraktionsgrad erreicht bzw. bis keine Zerlegung der Prozesse mehr möglich ist.

Beispiel 2.12:

Top-down-Analyse einer Auftragsbearbeitung

Wir betrachten die Top-down-Strategie anhand einer Analyse der Auftragsbearbeitung in einem Produktionsunternehmen. Ein Kunde informiert sich über ein Produkt. Sind alle Produktionsfaktoren vorrätig, bestellt der Kunde, und der Auftrag geht in die Fertigung. Kann das Produkt nicht oder nicht zeitgerecht erzeugt werden, wird der Auftrag nicht angenommen, und der Kunde erhält eine Absage. Eine entsprechende Top-down-Analyse der funktionalen Anforderungen ist in Abbildung 2.18 dargestellt.

Γ Kunde

1

Auftragsbearbeitung

Fertigung

(a) Schritt 1

Kunde

(b) Schritt 2

1.1 Auftrag prüfen OrdChk

1.2 Auftrag annehmen OrdAcc

Abb. 2.18a,b: Top-down-Vorgehensweise, Schritt 1 und 2

Fertigung

49

2.3 Anforderungsdokument 1.1.1 Kunden aufnehmen CustEdit

Kunde

1.1.3 Absage schreiben Cancel

Prod-Mittel prüfen PrMtChk

(c) Schritt 3

1.2 Auftrag annehmen OrdAcc

Kundendatei

1.1.2

( Kunde

1.1.3 Absage schreiben Cancel

\

1.1.1 Kunden aufnehmen CustEdit

1r 1.1.2 Prod-Mittel prüfen PrMtChk

2

>·

Arbeitsvorbereitung

Fertigung

\

Kundendatei

\

Arbeitsvorbereitung /

Kundendatei

3

1.2.1 Auftrag erstellen OrdCrt

Auftragsdaten

(d) Schritt 4 Abb. 2.18c,d: Top-down-Vorgehensweise

Fertigung

(Fortsetzung)

In Abbildung 2.18(a) beginnen wir mit einem Kontextdiagramm, bestehend aus einem Prozess, mit dem die Auftragsbearbeitung auf höchstem Abstraktionsniveau beschrieben ist. Im nächsten Schritt (b) prüft die Auftragsbearbeitung den Auftrag, gibt ihn entweder an die Fertigung weiter oder informiert den Kunden über die Ablehnung. Im dritten Schritt (c) erfolgt eine weitere Verfeinerung. Die Auftragsprüfung registriert den Kunden, falls er noch nicht in der Kundendatenbank vorhanden ist. Danach wird überprüft, ob alle notwendigen Produktionsfaktoren verfügbar sind. Wenn nicht, geht eine Absage an den Kunden. Sonst wird der Auftrag angenommen. In diesem Arbeitsschritt sind nun mehrere Verfeinerungen durchgeführt worden. Zuerst wird „Auftrag prüfen" durch drei Prozesse („Kunden aufnehmen", „Produktionsmittel

50

2 Anforderangserhebung und -analyse

prüfen", „Absage schreiben") ersetzt. Zwei dieser Prozesse benötigen einen Datenspeicher. Prozess „Kunden aufnehmen" sucht zuerst den Kunden in der Kundendatei. Wird der Kunde nicht gefunden, legt der Prozess die Daten im Speicher ab. Prozess „Produktionsmittel prüfen" liest Daten aus der Arbeitsvorbereitung, um zu prüfen, ob alle Produktionsfaktoren noch verfügbar sind, und der Auftrag angenommen werden kann. In Schritt 4 wird nochmals verfeinert. Den Auftrag anzunehmen bedeutet, ihn abzuspeichern und einen Fertigungsauftrag auszustellen. Für den Fertigungsauftrag werden Kundendaten benötigt. In Abbildung 2.18(d) haben wir zwischen den Prozessen „Produktionsmittel prüfen" und „Auftrag erstellen" eine Zwischenspeicherung in einem Datenspeicher vorgenommen. Um einen Auftrag an die Fertigung weiterzugeben, sind noch die Kundendaten notwendig. In Schritt 3 wurde durch Prozess „Kunde aufnehmen" ein entsprechender Datenspeicher bereits definiert. Aufgrund der schrittweisen Verfeinerung und der Top-down-Vorgehensweise und der damit verbundenen Trennung von Datenspeichern unterschiedlicher Abstraktionsniveaus ist es jedoch nicht möglich, diesen Datenspeicher auf der Ebene 4 zu benutzen. Zwangsläufig muss aufgrund dieser Einschränkung im Funktionsmodell redundante Datenhaltung vorgesehen werden. Die Inhalte des Datenspeichers „Kundendatei" sind in Schritt 3 und in Schritt 4 möglicherweise unterschiedlich. Bei der Top-down-Zerlegung kann jeder Prozess durch ein neues DFD genauer spezifiziert werden. Als Konsistenzregel ist einzuhalten, dass alle in den Prozess einmündenden Datenflüsse auch in das DFD einmünden, das diesen Prozess verfeinert. Wann soll nun die hierarchische Verfeinerung beendet werden? Die Antwort auf diese Frage hängt sicherlich von der Komplexität des betrachteten Prozesses ab. Als allgemeiner Richtwert wird von einigen Autoren als optimales Ende einer Verfeinerung ein Zustand angegeben, in dem jeder Prozess auf der „untersten" Hierarchieebene auf etwa einer Textseite durch Pseudocode, ein Struktogramm oder eine Spezifikation in natürlicher Sprache beschrieben werden kann. Für die meisten Problemstellungen ist die Top-down-Vorgehensweise zur Erstellung eines DFDs die vorteilhafteste Alternative. Bei Verwendung dieser Strategie kann es jedoch auch zu Problemen kommen. Datenredundanzen können auftreten, wenn zwei Prozesse aus unterschiedlichen Abstraktionsebenen einen Datenspeicher benötigen. Bei enger Auslegung einer Top-down-Vörgehensweise führt das unweigerlich zu zwei eigenständigen Speichern. Bei einem System mit vielen unterschiedlichen Datenstrukturen und Routineprozessen, die in unterschiedlichen Teilbereichen angesiedelt sind, sollte man von der Verwendung der Topdown-Strategie Abstand nehmen und eher eine Bottom-up-Vorgehensweise wählen. 2.3.2.2.2

Bottom-up-Vorgehensweise

Die Bottom-up-Vorgehensweise ist eine Umkehrung der Top-down-Vörgehensweise, bei der, ausgehend von allen Elementarprozessen, durch Aggregation und Zusammenfassung ein Kontextdiagramm auf hohem Abstraktionsniveau entwickelt wird. Die Strategie geht davon aus, dass sämtliche Prozesse bereits bekannt sind.

Beispiel 2.13:

Bottom-up-Analyse einer Auftragsbearbeitung

Wenn wir die Bottom-up-Strategie auf das Beispielszenario aus der Auftragsbearbeitung anwenden, ergibt sich das in Abbildung 2.19 dargestellte Bild.

2.3 Anforderungsdokument

51

Wir beginnen mit der Aufstellung aller elementaren Prozesse, die in der Auftragsbearbeitung vorkommen können (siehe Abbildung 2.19(a)). Danach werden Initiatoren und Terminatoren sowie Datenflüsse von und zu den Prozessen, die direkt mit Initiatoren und Terminatoren interagieren, eingetragen (Schritt (b)). Im nächsten Schritt (c) werden alle weiteren Datenflüsse eingetragen. Die Reihenfolge der Analyse der Datenflüsse ist nicht von Bedeutung, da wir ja ausschließlich auf einem einzigen Abstraktionsniveau modellieren. Im abschließenden vierten Schritt (Abbildung 2.19(d)) werden alle Datenspeicher eingetragen.

v

Kunden aufnehmen CustEdit >

3 Absage schreiben Cancel „

Prod-Mittel prüfen PrMtChk

Auftrag erstellen OrdCrt,

(a) Schritt 1

Kunde

schreiben Cancel

Kunden aufnehmen CustEdit

Prod-Mittel prüfen PrMtChk

(b) Schritt 2 Abb. 2.19a,b: Bottom-up-Vorgehensweise,

Schritt 1 und 2

2 Anforderungserhebung und -analyse

52

Durch die Vorgehensweise bei der Lösung des Beispiels 2.13 wird erstmals der wesentliche Vorteil der Bottom-up-Methode, nämlich die mehrfache Verwendung von Datenspeichern, ersichtlich. Da wir bei der Analyse des Prozesses „Auftrag erstellen" feststellen, dass wir Daten aus einem Datenspeicher „Kundendatei" auslesen und dieser Datenspeicher bereits existiert, können wir den bereits vorliegenden Speicher neuerlich verwenden. Bei Anwendung der Top-down Vorgehensweise war das nicht möglich, da der Datenspeicher auf unterschiedlichen Verfeinerungsstufen angesprochen wurde. Bei der Bottom-up-

Kunde

—

•

Ik

1 Kunden aufnehmen L Cus Edit J >

r Absage schreiben Cancel

Prod-M ittel prüfen PrMtChk

(c) Schritt 3

Kunde

• f

1

1

Kunden aufnehmen L CustEdit J

I

Kundendatei

ιr
Absage schreiben ^ Cancel J

Γ

Ί

Prod-Mittel prüfen L PrMtChk J

3

Arbeitsvorbereitung

> Auftragsdaten

Auftrag erstellen OrdCrt

(d) Schritt 4 Abb. 2.19c,d: Bottom-up-Vorgehensweise

(Fortsetzung)

Fertigung

2.3 Anforderungsdokument

53

Vorgehensweise operieren wir auf einer einheitlichen Ebene und können somit bestehende Datenspeicher mehrfach nutzen. Nachdem das DFD vollständig vorliegt, müsste man anfangen, die bestehenden Prozesse zusammenzufassen und unter Verwendung von Zwischendiagrammen ein Kontextdiagramm herzuleiten. Wir werden diesen Aggregationsschritt jedoch vernachlässigen, da die Besonderheiten der Bottom-up-Vorgehensweise in der Anfangsphase liegen und die einzelnen Zwischenschritte hin zum Kontextdiagramm aus der Darstellung in Abbildung 2.18 leicht abgeleitet werden können. Die reine Bottom-up-Vörgehensweise wird nur bei der Analyse kleinerer Systeme zum Einsatz kommen, da dem Entwickler im Vorhinein klar sein muss, wie das System funktioniert. Alle Elementarprozesse müssen bekannt sein. Neben der Vermeidung von Datenredundanz durch mehrere Datenspeicher mit ähnlichem Inhalt auf unterschiedlichen Abstraktionsniveaus ist als weiterer Vorteil der Bottom-up-Vörgehensweise bei der Erstellung eines DFD zu nennen, dass der Analysevorgang sehr schnell und effizient durchzuführen ist, da es sich bei den einzelnen Verfeinerungsschritten ausschließlich um Ergänzungen und nicht um Ersetzungen wie beim Top-down-Verfahren handelt. 2.3.2.2.3

Mischform aus Top-down und Bottom-up

In der Praxis werden die Top-down- und die Bottom-up-Vörgehensweise zur Erstellung eines DFD oft miteinander kombiniert. Bei der Anwendung der Mischform ist es dem Entwickler überlassen, mit welcher Verfahrensweise er die Analyse beginnt. Bei komplexeren Anwendungen ist es angeraten, top-down zu beginnen und für alle Prozesse des Kontextdiagramms eigene individuelle DFD zu entwickeln. In einer nachfolgenden Analysephase werden die individuellen DFD bottom-up zu einem einzigen DFD zusammengefasst. Hat der Entwickler die Aufgabe, bereits existierende Prozesse in ein neues System zu integrieren, wird er den Bottom-up-Ansatz wählen und mit diesen Prozessen und zumindest je einem Initiator und Terminator beginnen. Bevor das System unübersichtlich wird, kann bei dieser Mischform auf die Top-down-Methode umgeschwenkt und auf einem höheren Abstraktionsniveau mit der Analyse fortgesetzt werden. Die Mischform zwischen Top-down- und Bottom-up-Verfahrensweise ist die am häufigsten angewandte Strategie, da sie aus beiden Strategien die Vorteile enthält. Die Anwendung der Methode setzt jedoch große Erfahrung voraus, da man den Wechsel zwischen den beiden Methoden zum richtigen Zeitpunkt durchführen muss. 2.3.2.2.4

Inside-out- Vorgehensweise

Eine interessante Variante, die einen völlig anderen Ansatz verfolgt, stellt die Inside-outStrategie dar. Im Gegensatz zu den vorher beschriebenen Ansätzen versucht man, ein Problem direkt zu lösen, ohne dabei ein Komplettsystem entwickeln zu wollen. Diese Strategie ist zur Analyse kleinerer Anwendungen geeignet, in denen rasch eine unkomplizierte Lösung für zumindest ein Teilproblem gewünscht wird. Die Methode beginnt mit einem Terminator und einer gezielten Aufgabenstellung. Mit der Aufgabenstellung im Hinterkopf verfolgt man den Datenfluss und ergänzt alle Prozesse, Datenspeicher, Datenflüsse und Terminatoren, die mit der Aufgabenstellung in Zusammenhang

54

2 Anforderungserhebung und -analyse

stehen. Alle diese Aktionen geschehen auf der untersten Hierarchieebene. Sobald das Teilproblem analysiert ist, endet diese Methode. Beispiel 2.14:

Inside-out-Analyse einer Auftragsbearbeitung

Die Inside-out-Strategie wird in Abbildung 2.20 dargestellt. In diesem Beispiel entwickeln wir für die schon bekannte Auftragsverwaltung ein Subsystem, das die Kommunikation mit dem Kunden beschreibt. In Abbildung 2.20(a) beginnen wir mit der Registrierung des Kunden. Dabei muss auf die Kundendaten zugegriffen werden und bei Neukunden ein Eintrag vorgenommen werden. Wenn wir die Analyse fortsetzen (Abbildung 2.20(b)) ersehen wir, dass die Produktionsmittel überprüft werden. Ergibt die Überprüfung, dass der Auftrag nicht übernommen werden kann, wird dem Kunden eine Absage geschrieben. Eine Auftragsbestätigung erfolgt nicht. Die Insideout-Strategie endet an dieser Stelle, denn der Kunde hat auf seine Anfrage hin eine Antwort bekommen. In diesem Beispiel ist Kunde sowohl Initiator als auch Terminator des Datenflusses. Der Vorteil der Inside-out-Vorgehensweise gegenüber den anderen Methoden liegt darin, dass die Analyse auf die gleiche Art und Weise vorgenommen wird, wie das Diagramm später gelesen wird. Als Nachteil ist zu nennen, dass wir nur ein Teilsystem analysieren mit der Folge, dass später eine Integration von Teilsystemen notwendig wird, um zum Gesamtsystem zu gelangen. Die Anwendung dieser Vorgehensweise ist nur zu empfehlen, wenn das Teilsystem eine isolierte Aufgabe innerhalb des Gesamtsystems darstellt.

Kunde

1.1.1 Kunden aufnehmen CustEdit

1.1.3 Absage schreiben Cancel

Prod-Mittel prüfen

1.1.2

PrMtChk

(b) Abb. 2.20: Beispiel einer

Kundendatei

Inside-out-Vorgehensweise

2

Arbeitsvorbereitung

2.3 Anforderungsdokument 2.3.2.3

55

Ausgewählte Beispielmethoden

Die hier erwähnten Beispielmethoden zur Dokumentation und Analyse funktionaler Anforderungen stellen eine Auswahl aus der großen Zahl von publizierten Methoden und Verfahren dar. Die bekanntesten Methoden basieren auf dem Prinzip der funktionalen Zerlegung und dem Datenflussansatz. Sie gehen von einer Hauptfunktion aus und zerlegen diese in entsprechende Unterfunktionen. SADT, SA/SD und HIPO sind die in der Praxis am häufigsten verwendeten Verfahren. Alle drei Methoden unterstützen eine graphische Darstellungsform, die auch in einigen CASE-Werkzeugen (Computer Aided Software Engineering) zur automationsunterstützten funktionalen Analyse integriert ist. SA/SD (Structured Analysis, Structured Design) Die strukturierte Analyse (SA) wurde ebenfalls Ende der 70er Jahre entwickelt und ist heute der bekannteste datenflussorientierte Ansatz zur Darstellung und Analyse funktionaler Anforderungen. SA verwendet im Wesentlichen drei unterschiedliche Darstellungsformen: •

Datenflussdiagramme

•

Datenverzeichnisse Sie dienen zur genauen Beschreibung aller im DFD enthaltenen Daten, Datenflüsse und Akteure

•

Prozessspezifikationen Sie dienen zur Beschreibung aller Prozesse, die am untersten Abstraktionsniveau eines DFDs angesiedelt sind. Prozessspezifikationen werden in einer Art Pseudocode dargestellt.

Eine Ergänzung zu SA stellt der strukturierte Entwurf (SD) dar, der zusätzlich zu den in SA inkludierten Darstellungsformen Strukturpläne vorsieht, die zur Zerlegung eines Anwendungssystems in Module verwendet werden können. SADT (Structured Analysis and Design Technique) Der Grundgedanke in SADT besteht in der strukturierten Aufteilung aller Aktivitäten einer Organisation in einen funktionalen Bereich (Aktivitätsmodell) und einen strukturellen Teil (Datenmodell). SADT unterstützt ein Vorgehensmodell sowie eine graphische Notation aus beschrifteten rechteckigen Kästchen und Pfeilen. Die Kästchen eines SADT-Diagramms können in hierarchisch tiefer liegenden Ebenen weiter verfeinert werden, wobei jedoch auf einer Hierarchieebene ausschließlich ein Kästchen liegen darf. Die Verfeinerung wird solange fortgeführt, bis der gewünschte Detaillierungsgrad vorliegt. Auf jeder Abstraktionsebene soll ein System auf zwei Arten dargestellt werden: zum einen als Datenmodell und zum anderen als Aktivitätsmodell. Diese duale Darstellung soll die wechselseitige Überprüfung des Modells auf Vollständigkeit und Konsistenz ermöglichen. Die meisten CASE-Werkzeuge auf der Basis von SADT beschränken sich jedoch meist auf die Aktivitätsdiagramme und ersetzen die Darstellung des strukturellen Teils der Anwendung durch Entity-Relationship-Diagramme.

56

2 Anforderungserhebung und -analyse

HIPO (Hierarchical Input, Process, Output) HIPO wurde von der Firma IBM Mitte der 70er Jahre entwickelt und beruht auf der Zerlegung einer Anforderung in die Komponenten Dateneingabe, Verarbeitung und Datenausgabe. Die Methode unterstützt ein graphisches Beschreibungsverfahren, das im Wesentlichen aus drei unterschiedlichen Formen von Diagrammen besteht. Das Hierarchiediagramm enthält die Hauptfunktionen und zeigt die hierarchische Zerlegung in Unterfunktionen. Aus diesem Diagramm kann man eine gute Gesamtübersicht eines Systems erhalten und den Zusammenhang unterschiedlicher Funktionen ersehen. Das Übersichtsdiagramm beschreibt für wichtige Funktionen die Dateneingaben, die einzelnen Verarbeitungsschritte sowie die durch die Funktion erzeugten Datenausgaben. Das Detaildiagramm unterscheidet sich vom Übersichtsdiagramm durch einen höheren Detaillierungsgrad und beschreibt jeden elementaren Verarbeitungsschritt mit seinen Ein- und Ausgabewerten. Zusätzlich zur graphischen Darstellung gibt es im Detaildiagramm die Möglichkeit, textuelle Beschreibungen, Entscheidungstabellen oder Ablaufdiagramme aufzunehmen. Die Methode HIPO eignet sich vornehmlich zur Dokumentation von funktionalen Anforderungen. Die Möglichkeit zur statischen Analyse der Anforderungen ist eingeschränkt. Eine weitere Einschränkung stellt das Fehlen von Möglichkeiten zur genaueren Spezifikation der Eingabe- und Ausgabeflüsse von Daten in Funktionen dar. Einige Autoren stellen auch fest, dass sich Funktionsstrukturen im Unternehmen im Zeitablauf wesentlich rascher ändern als Datenstrukturen, und daher eine Analyse aufgrund der Zerlegung von Funktionen isoliert von der strukturellen Analyse der Anforderungen durchgeführt werden soll. Die funktionale Zerlegung besitzt als eigenständige Analysemethode daher heute kaum noch praktische Bedeutung.

2.3.3

Bearbeitungsanforderungen und dynamische Aspekte

Die Bearbeitungsanforderungen und die dynamischen Aspekte der Anwendung sind für die Erstellung eines konzeptuellen Datenmodells von untergeordneter Bedeutung, stellen aber für die Implementierung der Datenbank und die Spezifikation der Programme, die auf die Datenbank zugreifen, eine wichtige Grundlage dar. Dynamische Anforderungen zeigen das zeitabhängige Verhalten von Datenbankobjekten. Während der statischen Analyse werden die erhobenen Anforderungen zeitpunktbezogen analysiert. Das bedeutet, dass die Anforderungen eine auf einen bestimmten Zeitpunkt (den Erhebungszeitpunkt) bezogene Aussage darstellen. Viele der erhobenen Informationseinheiten (Entityoder Beziehungstypen) können jedoch im Laufe ihrer Existenz verschiedene Zustände und damit verbunden verschiedene Werte annehmen. Ein Zustand einer Informationseinheit ist durch gleich bleibende Attributwerte und sich nicht verändernde Verknüpfungen zu in Beziehung stehenden Informationseinheiten charakterisiert. Ändert sich eine für die Anwendung relevante Eigenschaft, so wechselt z.B. ein Entity seinen Zustand. Unterschiedliche Zustände eines Entities vom Typ „Bestellung" können z.B. vom Attribut „Status" abhängig sein, das z.B. die Werte „erfasst", „geliefert", „teilgeliefert", „storniert", „offen" u.a. annehmen kann. Zustandsveränderungen werden durch das Eintreten vordefinierter Ereignisse verursacht. Die Reaktion auf ein eingetretenes Ereignis hängt wieder vom aktuellen Zustand der Informationseinheit ab. Der Zyklus der Zustandsänderungen einer Informationseinheit wird auch als ihr Lebenszyklus bezeichnet.

57

2.3 Anforderungsdokument

Im Zuge einer Analyse der dynamischen Aspekte der erhobenen Anforderungen werden zunächst Ereignisfolgen identifiziert, die in vielen Vorgehensmodellen als Szenarios bezeichnet werden. Ein Szenario erhält man, indem man ein existierendes System ausführt und die Ereignisfolgen notiert, oder indem man ein geplantes System gedanklich nachvollzieht und alle Ereignisabfolgen Schritt für Schritt zu einem Szenario zusammenfügt. Wenn ein Szenario feststeht, werden im nächsten Schritt die beteiligten Objekte identifiziert und in einem Ereignisabfolgediagramm dargestellt. Wir werden auf die Analyse der dynamischen Aspekte einer Datenbankanwendung im Zuge der objektorientierten Modellbildung (Unterkapitel 3.3) noch genauer eingehen. Beispiel 2.15:

Szenario und Ereignisabfolgediagramm

„Bestellvorgang"

Abbildung 2.21 enthält ein Beispiel für ein mögliches Szenario eines Bestellvorganges und ein entsprechendes Ereignisabfolgediagramm, das die Kommunikation zwischen Kunde und Lieferant darstellt und damit den Zustand der Bestellung widerspiegelt.

Kunde Lieferant kon taktieren Bestellformular übermitteln Auftragsbestätigung abwarten Erste Teillieferung erhalten Zweite Teillieferung erhalten Erhalt bestätigen Rechnung abwarten

Lieferant informelle Anfrage Lieferbereitschaft

Bestellformular übermitteln bestätigt Auftrag Teillieferung 1 Teillieferung 2 Erhalt bestätigt Rechnungslegung

Szenario für Bestellvorgang

Abb. 2.21: Szenario und Ereignisabfolgediagramm

Ereignisabfolgediagramm für Bestellvorgang „Bestellvorgang"

Bearbeitungsanforderungen werden während der Analyse der geplanten Transaktionen untersucht. Dabei geht man davon aus, dass ein Großteil der wichtigsten Datenbanktransaktionen bereits zum Entwurfszeitpunkt der Datenbank bekannt ist. Das Ziel der Transaktionsanalyse ist, eine genaue Darstellung der systembedingten Eigenschaften der Transaktionen (Bearbeitungsanforderungen) im Hinblick auf eine spätere Implementierung der Datenbank und der auf

58

2 Anforderungserhebung und -analyse

sie zugreifenden Programme zu erhalten. Da während der Transaktionsanalyse bereits gewisse Kenntnisse über die Struktur der Daten notwendig sind, erfolgt die Transaktionsanalyse gegen Ende der Analysephase oder oft erst auch als Teil des physischen Entwurfs der Datenbank. Die erste Aktivität innerhalb der Transaktionsanalyse ist die Unterscheidung der Transaktionen in Datenbankanfragen und Datenbankmanipulationen. Eine Datenbankanfrage (database query) ist eine Transaktion, die ausschließlich die Ausgabe von Informationen beinhaltet. Eine Datenbankmanipulation ändert den Inhalt der Datenbank durch Anwendung eines oder mehrerer der folgenden Operationstypen: •

delete (Datensätze werden aus der Datenbank entfernt),

•

insert (Datensätze werden in die Datenbank eingefügt),

•

update (Datensätze werden verändert).

Im Rahmen der Analyse der Bearbeitungsanforderungen ist es nun notwendig, die folgenden Eigenschaften der wichtigsten Transaktionen zu spezifizieren: 1. Transaktionstyp (delete, insert, update oder query) 2. Erwartete Frequenz der Transaktion (z.B. fünfmal täglich) 3. Zeitbeschränkung (z.B. max. Laufzeit zehn Sekunden) 4. Informationseinheiten, die von der Transaktion berührt werden 5. Attribute, die zur Auswahl der Datensätze (Selektion) benutzt werden 6. Attribute, deren Werte zur Verknüpfung von Informationseinheiten verwendet werden 7. Attribute, deren Werte durch eine Datenmanipulation verändert werden In der Praxis ist es meist nicht notwendig, alle Transaktionen bis ins kleinste Detail vorauszuplanen, da es im Allgemeinen nur wenige Transaktionen sind, die die meiste Bearbeitungszeit beanspruchen. Dieser Sachverhalt wird oft als „80-20 Regel" bezeichnet, wobei damit ausgedrückt werden soll, dass lediglich 20% der Transaktionen bereits etwa 80% der Bearbeitungszeit aller Transaktionen verbrauchen. Bei den verbleibenden 80% der Transaktionen handelt es sich dann meistens um interaktive Anfragen, während die wichtigen bekannten Transaktionen meistens durch vorgefertigte Prozeduren realisiert werden. Die Ergebnisse der Transaktionsanalyse sind für die systemunabhängigen Entwurfsphasen von untergeordneter Bedeutung, sie spielen aber für den physischen Entwurf der Datenbank eine große Rolle. Insbesondere die Spezifikation der in den Punkten 5 bis 7 genannten Attribute bilden oft die Grundlage für physische Entwurfsentscheidungen. Diese Entscheidungen, die sich im Allgemeinen auf die Performanz der Datenbank auswirken, werden unter dem Begriff Datenbanktuning zusammengefasst. Die wohl wichtigste Aktivität zur Verbesserung der Zeiteffizienz ist das Erstellen von Indizes, durch die ein wesentlich schnellerer Zugriff auf die Daten ermöglicht wird. Kandidaten für solche Indizes sind die unter Punkt 5 und 6 beschriebenen Attribute. Insbesondere Anfragen, die eine Verknüpfung von Informationseinheiten (z.B. von zwei Entitytypen über einen gemeinsamen Beziehungstyp) beinhalten, sind

2.3 Anforderungsdokument

59

sehr zeitintensiv. Beim Anlegen von Indizes muss jedoch bedacht werden, dass bei Datenbankmanipulationen auch die Indexstruktur aktualisiert werden muss und deshalb für Attribute, die während der Transaktion verändert werden (das sind solche, die im Punkt 7 genannt sind), mit diesem Hilfsmittel eher sparsam umgegangen werden sollte.

Beispiel 2.16:

Transaktionsanalyse,,Bestellung

erstellen "

Um die Vorgehensweise bei der Transaktionsanalyse zu verdeutlichen, betrachten wir das nachfolgende Beispiel: Ein Handelsunternehmen kontrolliert einmal am Tag den Lagerbestand. Hierbei wird für jeden Artikel der Ist-Bestand mit dem Meldebestand verglichen. Falls der Meldebestand unterschritten wurde, soll automatisch ein Bestellformular erzeugt werden, das für jede Bestellung die Bestellmenge, die Artikelnummer, die Lieferantennummer sowie weitere für die Bestellung relevante Daten enthält. Eine die Bestellung realisierende Transaktion (vgl. dazu Abbildung 2.22) ist wie folgt aufgebaut: Während der Transaktion werden sequentiell alle Artikel auf eine Unterschreitung des Meldebestandes kontrolliert (Schritt 1) und falls dieses zutrifft, wird durch eine Verknüpfung von Lieferant, liefert und Artikel (Schritt 2) festgestellt, von wem der Artikel bezogen wird. Schlussendlich wird jede Bestellung in das Bestellformular eingetragen (Schritt 3).

Lief Nr Lief Name Maier KG 123 124 Müller & Co 125 Ölschläger

Anschrift Wiesbaden Düsseldorf Wien

ArtikelNr 10752-1 27392-7 32791-2

A_Bezeichnung Μ Best Ist Best 48 ... Zylinderkopfdichtung 50 45 ... Lenkgetriebe 30 25 ... Bremszylinder 30

Schritt 1: Kontrolle der Artikel

Lief Nr Artikel Nr 123 10752-1 124 10752-1 123 27392-7 125 27392-7 32791-2 125

Lief_Nr 124 125

Preis 170 165 450 450 187

Artikel_Nr Bestellmenge 10752-1 100 32791-2 60

Abb. 2.22: Transaktion ,,Bestellungen

erstellen"

Schritt 2: Verknüpfung der Tabellen

Schritt 3: Eintragung der Bestellung

2 Anforderungserhebung und -analyse

60

Beschreibung:

Überprüfung des Lagerbestandes und Erstellen der Bestellungen

Transaktionstyp:

Insert

Häufigkeit:

lmal täglich

Zeitbeschränkung:

keine (erfolgt nach Geschäftsschluss automatisch)

Informationseinheit

Attribut

Verknüpfung

Lieferant

Lief_Nr

X

liefert

Lief_Nr

X

ArtikeLNr

X

Artikel_Nr

X

Artikel

Bestellung

Abb. 2.23: Anforderungsformular

Selektion

Ist_Best

X

M_Best

X

Manipulation

Lief_Nr

X

ArtikeLNr

X

Bestellmenge

X

der Transaktion „Bestellungen

erstellen"

Kommen für einen Artikel mehrere Lieferanten in Frage, so könnte die Auswahl des Lieferanten aufgrund einer Prioritätsregel erfolgen, die den niedrigsten Bezugspreis oder aber auch die kürzeste Lieferzeit als Entscheidungsgrundlage beinhaltet. Anforderungen dieser Art beeinflussen die Bearbeitung der Transaktion nur in geringem Rahmen und finden daher ausschließlich während der funktionalen Analyse Berücksichtigung. Das in Abbildung 2.23 dargestellte Anforderungsformular stellt die notwendigen Eigenschaften der Transaktion in strukturierter Form dar und bietet eine Möglichkeit, die Bearbeitungsanforderungen in das Anforderungsdokument aufzunehmen.

2.4

Zusammenfassung

Das Ziel der Anforderungserhebung und -analyse ist die Erstellung eines Anforderungsdokumentes. Im Idealfall ist das Anforderungsdokument eine vollständige Spezifikation aller Sachverhalte, die in den Entwurfsprozess einer Datenbank einfließen müssen. Das Anforderungsdokument kann eine „unternehmensweite" Sicht der Anforderungen an die Datenbank darstellen oder den individuellen Ausschnitt eines bestimmten Funktionsbereiches im Unternehmen repräsentieren. Bevor erhobene Anforderungen in das Anforderungsdokument übertragen werden, empfiehlt sich eine textuelle Analyse der Anforderungsspezifikationen. Anforderungsdokumente enthalten zumindest vier unterschiedliche Typen von Anforderungen: Informationsanforderungen beschreiben die Struktur und die Art der anfallenden Daten.

61

2.5 Literatur

Darunter fallen Angaben über Realwelt-Objekte, ihre Gruppierung in Typen, die Daten charakterisierenden Eigenschaften bzw. Attribute und ihre Wertebereiche, Beziehungen und Abhängigkeiten zwischen Daten und Objekten sowie allgemeine Integritätsbedingungen, die die Konsistenz der Datenbank beschreiben. Funktionale Anforderungen beschreiben betriebliche Vorgänge auf unterschiedlichen Verdichtungsstufen. Die oberste Verdichtungsstufe stellt Geschäftsprozesse dar, die einen bestimmten betrieblichen Ablauf von seiner Entstehung bis hin zu seiner Beendigung auf hohem Abstraktionsniveau beschreiben. Auf einer unteren Verdichtungsstufe erfolgt die Darstellung in Form elementarer Arbeitsschritte (Prozesse) und ihrer Input- und Outputdatenflüsse. Dynamische Anforderungen beschreiben gültige Zustände und Bedingungen für Zustandsübergänge, die Objekte während ihrer Existenz in der Datenbank durchleben können. Im Rahmen der Transaktionsanalyse werden Bearbeitungsanforderungen erhoben, die für die wichtigsten bereits bekannten Datenbankoperationen ihre Häufigkeit, das involvierte Datenvolumen, Prioritäten und Reihenfolgen oder ähnliche Nutzeranforderungen enthalten. Informationsanforderungen und funktionale Anforderungen stellen die wichtigste „Klasse" von Anforderungen dar, die den systemunabhängigen Teil des Entwurfs einer Datenbank beeinflussen. Die im Anforderungsdokument enthaltenen Aufgaben und Vorgaben bilden die Grundlage für den konzeptuellen Datenbankentwurf.

2.5

Literatur

Eine umfassende Darstellung der Planung von Softwaresystemen mit besonderer Berücksichtigung der Erstellung einer Vorstudie ist in [Hei96a] enthalten. Viele Bücher über die Grundlagen der Wirtschaftsinformatik beinhalten umfangreiche Darstellungen der Methoden der Anforderungserhebung und -analyse. Als Beispiel dafür seien [StHa97], [Kral96] oder [Hans96] genannt. Arbeiten, die sich vorwiegend mit der Analyse der Informationsanforderungen beschäftigen, sind meistens Bücher, die die frühen Phasen des Entwurfszyklus einer Datenbank in den Vordergrund stellen. Als Beispiel dafür seien [BaCN92], [RaSt97] oder [MMM093] genannt. Die Darstellung einer Vorgehensweise für funktionale Analyse ist in [MaMc75] für SADT, [DeMa79] für strukturierte Analyse, [YoCo79] für strukturiertes Design, [Stay76] für HIPO und in [GaSa79] für eine allgemeine Datenflussmodellierung enthalten. [Balz82] enthält einen· sehr guten Überblick der unterschiedlichen Methoden. Die Methoden der Analyse der dynamischen Aspekte der Anforderungen sind in vielen Büchern über objektorientierte Analyse und Design enthalten. Auf sie wird im nächsten Kapitel hingewiesen werden. Die Analyse der Bearbeitungsanforderungen wird in vielen Datenbankbüchern vernachlässigt. Lobenswerte Ausnahmen stellen [LaLo95] und [MaDL87] dar. Eine Darstellung neuer Entwicklungen, insbesondere des Einsatzes von Szenarien, ist in dem Sonderheft [Soft98] enthalten.

2.6 Aufgabe 2.1:

Kontrollaufgaben Charakteristika für den Einsatz von DBMS

Welche Charakteristika müssen betriebliche Aufgaben besitzen, so dass DBMS ein geeignetes technisches Realisierungskonzept darstellen?

62

2 Anforderungserhebung und -analyse

Aufgabe 2.2: Techniken zur Anforderungserhebung Diskutieren Sie Vor- und Nachteile der wichtigsten Techniken zur Erhebung von Nutzeranforderungen an das zu entwickelnde Datenbanksystem. Welche Techniken ergänzen sich gegenseitig und können gemeinsam eingesetzt werden? Aufgabe 2.3: Datei- vi. Datenbanksystem Beschreiben Sie anhand frei gewählter Aufgabenstellungen in den drei Funktionsbereichen „Einkauf, „Lagerhaltung" und „Verkauf die historischen Entwicklungsstufen von Datenbanken. Gehen Sie auf die wesentlichen Unterschiede zwischen Dateisystemen und Datenbanksystemen ein und geben Sie an, wie in den einzelnen Systemen Datenredundanz kontrolliert werden kann. Aufgabe 2.4: Unterschiedliche Klassen von Anforderungen Ordnen Sie nachfolgende Anforderungen den vier unterschiedlichen Anforderungsklassen zu. Begründen Sie Ihre Antworten und führen Sie eine erste Anforderungsanalyse durch. •

Applikation „Vorbereitung-Bestellung" registriert den Kunden und trägt Neukunden in die Kundendatei ein.

•

Besitzt der Kunde eine gute Bonität und ist die Höhe der Bestellung über Euro 10.000, so wird ein Rabatt in Höhe von 3% in Abzug gebracht.

•

Ein bestimmtes Produkt kann unter Verwendung bestimmter Maschinen vom Typ Α gefertigt werden. Jede dieser Maschinen besitzt eine eindeutige Maschinenkennnummer, einen Standort und einen individuellen Belegungsplan. Alle Maschinen vom Typ Α haben die gleiche PS-Leistung, dasselbe Gewicht, aber ein individuelles Kaufdatum.

•

Die Entleihung eines Buches aus der Universitätsbibliothek kann wie folgt beschrieben werden: Ist das Buch nicht verfügbar, so ist die Entleihung im Zustand „Reservierung". Wird das Buch nach Fälligkeit nicht retourniert, wird dem Entleiher eine Mahnung geschickt. Ist das Buch verfügbar und nicht vorgemerkt, kann es entliehen werden.

•

Nachdem ein Mietwagen retourniert ist, werden der Retourschein erfasst und die Rechnung erstellt. Der Rechnungsbetrag errechnet sich aus der gewählten Wagenkategorie, den gefahrenen Kilometern, der Rabattgruppe des Kunden, der Mietdauer und aus dem Tankinhalt nach Rückgabe.

Aufgabe 2.5: Eigenschaften von Attributen und Beziehungstypen Diskutieren Sie Strukturierungsmerkmale für Attribute und Beziehungstypen. Geben Sie für jedes Ihnen bekannte Merkmal zumindest ein Beispiel an. Aufgabe 2.6: Anforderungsanalyse Sportverein Identifizieren Sie im nachfolgenden Text alle Entitytypen, Attribute und Beziehungstypen und diskutieren Sie ihre Eigenschaften. Ein professioneller Sportverein (mit mehreren Mannschaften) möchte seine Mitgliederverwaltung automatisieren. Mitglieder des Sportvereins sind ausschließlich aktive Mitglieder oder Förderer. Für Mitglieder soll ihre Mitgliedsnummer, Name, Anschrift und Eintrittsdatum gespeichert werden. Für Förderer des Sportvereins soll zusätzlich noch die Höhe ihres Beitrags und ein Textfeld für weitere Anmerkungen geführt werden. Aktive Mitglieder sind entweder

2.6 Kontrollaufgaben

63

Trainer, Spieler in einer Mannschaft oder können auch beides sein. Für Trainer wird das Datum ihrer Lizenz, die Art der Lizenz und das Gehalt gespeichert. Spieler werden durch das Attribut Eigenschaft und ebenfalls durch ihr Gehalt beschrieben. Ein Trainer kann mehrere Mannschaften trainieren. Jede Mannschaft hat jedoch zu einem Zeitpunkt nur einen Trainer. Es soll aufgezeichnet werden, wann (Datum) der Trainer die Mannschaft übernommen hat, wie oft (Anzahl) in der Woche ein Training stattfindet und welche Trainer diese Mannschaft bisher schon trainiert haben. Maximal 16 Spieler können einer Mannschaft angehören. Jeder Spieler kann zu einem Zeitpunkt nur einer Mannschaft angehören, kann aber während seiner Zugehörigkeit zum Verein schon für andere Mannschaften gespielt haben. Für jeden Spieler soll das Eintrittsdatum in eine Mannschaft, seine Spielposition und ein eventuelles Austrittsdatum aus der Mannschaft gespeichert werden. Jede Mannschaft hat einen Mannschaftskapitän. Er muss Spieler dieser Mannschaft sein und für ihn sollen seine Telefonnummer und eine Prämienzulage gespeichert werden. Jede Mannschaft wird eindeutig durch ihren Namen bestimmt und hat als weitere Eigenschaft die Bezeichnung der Liga, in der die Mannschaft spielt. Aufgabe 2.7: Anforderungsanalyse Kursverwaltung Die Kursverwaltung der Firma „ABC Ltd." soll rechnerunterstützt durchgeführt werden. Führen Sie aufgrund der nachfolgenden Angaben eine funktionale und statische Analyse des Realweltausschnittes durch. Das betrachtete Unternehmen unterhält eine Ausbildungsabteilung, deren Aufgabe es ist, unterschiedliche Kurse durchzuführen. Jeder Kurs findet innerhalb des Unternehmens an verschiedenen Orten statt. Die zu erstellende Datenbank enthält aktuelle Kurse, die bereits abgehaltenen Kurse, und auch Kurse, deren Abhaltung erst geplant ist. Folgende Details sollen modelliert werden: •

Für jeden Kurs: Kursnummer (eindeutig), Kursbezeichnung, Kursbeschreibung, vorausgesetzte Kurse (falls vorhanden), Zeitbezug (durchgeführt, geplant).

•

Für jeden vorausgesetzten Kurs seine Kursnummer und Kursbezeichnung.

•

Für jedes Kursangebot: Datum, Ort (Bezeichnung, Raumkapazität), Art (z.B. ganztägig, halbtägig), beteiligte Leiter, beteiligte Teilnehmer.

•

Für jeden Kursleiter eines angebotenen Kurses: Mitarbeiternummer und Name.

•

Für jeden Kursteilnehmer an einem angebotenen Kurs: Mitarbeiternummer, Name, Gehalt.

Kursteilnehmer müssen die Teilnahme an Kursen beantragen. Die Vergabe erfolgt in der Reihenfolge der Anmeldung, wobei die maximale Raumkapazität der Teilnehmerobergrenze für den jeweiligen Kurs entspricht. Vor der Zuordnung wird überprüft, ob der Kandidat für den jeweiligen Kurs alle Voraussetzungen erfüllt. Aufgabe 2.8: Schematransformationen Erklären Sie anhand eines frei gewählten Beispiels mögliche Schematransformationen in Datenflussdiagrammen. Aufgabe 2.9: Top-down-Verfeinerung,, Wareneingangsprüfung " Verfeinern Sie den in Abbildung 2.16(d) dargestellten Vorgang „Wareneingangsprüfung". Wenden Sie im Zuge der Verfeinerung ausschließlich die in Abbildung 2.17 dargestellten Transformationsregeln an.

64

2 Anforderungserhebung und -analyse

Aufgabe 2.10: Formen der funktionalen Analyse Erklären Sie die wesentlichen Unterschiede der Top-down-, der Bottom-up-, der Kombinationsmethode und der Inside-out-Vorgehensweisen zur Durchführung einer funktionalen Analyse. Wie können diese unterschiedlichen Ansätze miteinander kombiniert werden? Aufgabe 2.11: Wichtige Transaktionen Nennen Sie die wichtigsten Eigenschaften von Transaktionen, die im Zuge der Anforderungserhebung und -analyse dokumentiert werden sollen. Aufgabe 2.12: Zusammenhänge unterschiedlicher Anforderungstypen Diskutieren Sie Zusammenhänge zwischen Informationsanforderungen und dynamischen Anforderungen. Converted from Microsoft Word to LaTeX

3

Konzeptueller Datenbankentwurf

Beim Entwurf einer Datenbank kommt der konzeptuellen Modellbildung des zu beschreibenden Realitätsausschnittes eine zentrale Bedeutung zu. Die Hauptaufgabe dieser Entwurfsphase ist es, alle individuellen Anforderungen aus den Anforderungsdokumenten in einer einheitlichen Spezifikation, dem unternehmensweiten Datenmodell, zu repräsentieren und damit für alle Anwendungen eine einheitliche Schnittstelle für den Zugriff auf die Datenbank zu schaffen. In diesem Kapitel sollen die wesentlichen Schritte der konzeptuellen Modellbildung näher betrachtet werden. Eine Datenbank muss den aus Sicht der zu bedienenden Anwendungsklassen relevanten Realweltausschnitt abdecken. Nun ist die Realwelt allerdings zu komplex und vielschichtig aufgebaut, als dass sie sich einfach so auf einem Rechner abbilden ließe. Daher braucht man Ausdrucksmittel, mit denen die Realwelt so vereinfacht dargestellt werden kann, dass die resultierende Darstellung abstrakt genug ist, um die aus Sicht der Anwendungsklassen unwichtigen Details kaschieren zu können, gleichzeitig aber ausdrucksstark genug ist, um alle erwünschten Merkmale und Beziehungen auch ausdrücken zu können. Als Werkzeuge zur Modellierung einer solchen Darstellung werden aussagekräftige und mächtige Datenmodelle eingesetzt. Die Ergebnisse der Anforderungserhebung liegen in den meisten Fällen in sehr informeller Form vor. Für den konzeptuellen Entwurf einer Datenbank benötigt man ein Beschreibungsmittel, mit dem die Spezifikationen aus den Anforderungsdokumenten einheitlich und systemunabhängig dargestellt werden können. Die „semantische" Informationsbeschreibung ist Gegenstand der konzeptuellen Modellbildung und wird von so genannten semantischen Datenmodellen, die für den konzeptuellen Datenbankentwurf eingesetzt werden, unterstützt. Ein semantisches Datenmodell erlaubt es, den relevanten Ausschnitt der Realität unter Verwendung der Strukturierungsprinzipien des Modells präzise, wahrheitsgetreu und möglichst umfassend darzustellen. Es zwingt zu einem gründlicheren und vollständigeren Analysieren des Informationsbedarfs und hilft dabei, Lücken in den Anforderungsspezifikationen aufzudecken. Von einem semantischen Datenmodell wird in der Regel gesprochen, wenn es das relationale Datenbankmodell an semantischer Aussagekraft übertrifft. Seit dem Ende der 60er Jahre begann man sich Gedanken darüber zu machen, wie Daten in eine „normale" Form gebracht und entsprechend dargestellt werden könnten. In den letzten 30 Jahren wurde eine Vielfalt von Modellierungsarten und Darstellungstechniken bekannt, aus denen man einige Meilensteine der Entwicklung identifizieren und einige Trends herleiten kann. Einer der ersten, der sich mit der Konzeptualisierung von Daten befasst hat, war C. W. Bachmann [Bach69] etwas später entwickelte E. F. Codd [Codd70] ein relationales Datenbankmodell, mit dem er versuchte, die Beschreibung von Daten mengentheoretisch vorzunehmen und Normalformen zu entwickeln, mit denen die Güte einer relationalen Datenbank beurteilt werden kann. Die zu jener Zeit geprägten Grundsätze und Regeln besitzen heute noch Gül-

66

3 Konzeptueller Datenbankentwurf

tigkeit. Die nächsten Jahre wurden durch die Entwicklung von Modellen geprägt, mit denen versucht wurde, die semantische Aussagekraft der Daten zu erhöhen. Einen ersten Meilenstein in der Entwicklung von semantischen Datenmodellen stellt das Entity-Relationship-Modell durch Peter P. Chen [Chen76] dar, das in den Folgejahren um viele Aspekte erweitert wurde und heute einen Quasi-Standard für den konzeptuellen Datenbankentwurf darstellt. Entity-Relationship-Modelle legen ihren Schwerpunkt auf die strukturelle Analyse der Anforderungen und beschreiben vornehmlich die Struktur der Daten. Parallel zu ihrer Entwicklung entstanden Ende der 70er Jahre Funktionsmodelle, die eher eine funktionsorientierte Sichtweise auf die Anwendung favorisieren, jedoch die Struktur der Daten vernachlässigen. Wir haben die Idee hinter diesen Modellen in Unterkapitel 2.3.2 bei der Analyse der funktionalen Anforderungen vorgestellt. Die späten 70er Jahre und der Beginn der 80er Jahre wurden durch Arbeiten und Entwicklungen mit dem Ziel geprägt, diese beiden unterschiedlichen Denkweisen in eine einheitliche Vorgehensweise zur konzeptuellen Modellbildung zu integrieren. Die Mitte und das Ende der 80er Jahre waren der Entwicklung von objektorientierten Modellen gewidmet. Inzwischen war das methodische Modellieren der Daten und Funktionen weit verbreitet und man war zur Überzeugung gekommen, dass eine ganzheitliche und objektorientierte Sichtweise auf ein betriebliches Informationssystem auch dynamische Aspekte, also die Modellierung von Objektklassen durch Struktur und Verhalten, beinhalten sollte. Die Entwicklung von Methoden und Techniken zum konzeptuellen Datenbankentwurf scheint auch heute noch nicht vollständig abgeschlossen zu sein. Es entwickeln sich weiterhin neue Denkansätze. So rückte z.B. die Analyse und Modellierung von Geschäftsprozessen als Basis für den Datenbankentwurf in den letzten Jahren zunehmend in den Mittelpunkt der Betrachtung. Die Struktur dieses Kapitels spiegelt die einzelnen Phasen der Entwicklung von Methoden zum konzeptuellen Datenbankentwurf wider und ist in Abbildung 3.1 zusammengefasst. Wir beginnen das Kapitel mit der Darstellung des Entity-Relationship Ansatzes, einer Methode zur ausschließlich strukturorientierten Modellbildung (Unterkapitel 3.1). In Unterkapitel 3.2 erweitern wir diesen Ansatz und stellen eine Methode vor, in der Daten- und Funktionsmodelle gleichberechtigt zur Erstellung eines konzeptuellen Datenmodells herangezogen werden. Bei der objektorientierten Vorgehensweise wird zwischen einer Struktur- und einer Verhaltensmodellierung unterschieden. In Unterkapitel 3.3 wird ein integriertes Objektmodell erarbeitet, das neben den Aspekten der klassischen Modelle auch Konzepte zur Modellierung von Verhalten beinhaltet. Das Unterkapitel 3.4 widmet sich den aktuellen Forschungstrends und fasst einen weiteren Ansatz zur konzeptuellen Modellbildung, die geschäftsprozessorientierte Modellbildung, zusammen. Dieser Ansatz kann jedoch aus Kapazitätsgründen nicht mehr im Detail behandelt werden. Das Kapitel 3 wird durch zwei weitere Unterkapitel ergänzt: In Unterkapitel 3.5 wird das Gebiet der Schemaintegration behandelt. Schemaintegration wird notwendig, wenn ein konzeptuelles Datenmodell nicht als Ganzes, sondern durch Integration und Konsolidierung mehrerer Bereichsdatenmodelle entwickelt wird. Kapitel 3 wird mit der Normalisierung abgeschlossen, einer Entwurfsmethode, die vorwiegend zum Entwurf relationaler Datenbanken eingesetzt wird. Es gilt noch die allgemeine Frage zu beantworten, welche generellen Gestaltungsempfehlungen für konzeptuelle Modellbildungen existieren, deren Anwendung die Qualität eines Modells erhöhen. Dabei ist es sehr schwierig, eine Metrik zur Gewichtung einer Qualität in einer festen und objektiven Weise vorzugeben. In den meisten Fällen beruht solch ein Maß auf

67

3 Konzeptueller Datenbankentwurf

Anforderungs-

Strukturorientierte

dokument

Modellbildung

Schemaintegration 3.1

3.5

Funktionsorientierte

Anforderungsanalyse

Formaler Datenbankentwurf

Modellbildung 3.2

3.6

Integrierte Objektmodelle 3.3

weitere Ansätze zur Modellbildung 3.4

Kapitel 3 Abb. 3.1: Ansätze zur konzeptuellen Modellbildung

subjektiver Einschätzung. Ein erster Ansatz wurde in [BeRS95] entwickelt, einer Arbeit, in der Grundsätze ordnungsgemäßer Modellbildung aufgestellt werden, denen als Vorbild die im Rechnungswesen geltenden Grundsätze ordnungsgemäßer Buchführung nach Leffson dienen. Dabei werden insbesondere betrachtet: •

Grundsatz der

Richtigkeit

Dieser Grundsatz gliedert sich in zwei Aspekte: Die syntaktische Richtigkeit wird eingehalten, wenn ein Modell den Notationsregeln der gewählten Modellierungsmethode entspricht. Die semantische Richtigkeit bewertet den „Inhalt" des Modells, also inwieweit das Modell dem entsprechenden abzubildenden Realweltausschnitt entspricht. Hierzu müssen alle sachlogischen Gegebenheiten und Zusammenhänge des relevanten Realitätsausschnitts im Modell abgebildet sein. •

Grundsatz der

Relevanz

Das Modell sollte keine überflüssigen Informationen enthalten noch sollten relevante Informationen fehlen. Im Modell dargestellte Sachverhalte gelten dann als relevant, wenn der Nutzeneffekt des Modells sinken würde, falls man Informationen entfernen oder hinzufügen würde. •

Grundsatz der

Wirtschaftlichkeit

Dieser Grundsatz stellt den betriebswirtschaftlichen Wirtschaftlichkeitsaspekt dar. Die Wirtschaftlichkeit eines Modells lässt sich nur sehr schwer bewerten, weil sich Kosteneinsparungen am Modell erst in den späteren Phasen des Datenbankentwurfs rächen. •

Grundsatz der

Klarheit

In diesem Grundsatz werden die Aspekte der Strukturiertheit, der Übersichtlichkeit und der Lesbarkeit zusammengefasst. Sie betreffen folglich die Anschaulichkeit eines Modells.

68

3 Konzeptueller Datenbankentwurf

•

Grundsatz der Vergleichbarkeit Dieser Grundsatz gliedert sich ebenfalls in zwei Aspekte: Die syntaktische Vergleichbarkeit stellt die Kompatibilität von Modellen dar, die mit verschiedenen Modellierungstechniken (Methoden) erstellt wurden. Die semantische Vergleichbarkeit beschreibt die inhaltliche Vergleichbarkeit von Modellen. Auf diesen Grundsatz werden wir im Unterkapitel 3.5 nochmals näher eingehen.

•

Grundsatz des systematischen Aufbaus Bei der Erstellung eines Modells sollte eine systematische Vorgehensweise gewählt werden. So sollten z.B. Bereichsdatenmodelle schon im Hinblick auf eine spätere Integration in ein unternehmensweites Datenmodell erstellt werden.

Bei allen Grundsätzen wird sehr deutlich, wie wichtig der Einbezug der subjektiven Beurteilung der einzelnen Personengruppen, die bei Analyse, Modellbildung und Einsatz eines Datenbanksystems involviert sind, in die Bewertungsansätze ist. So hat z.B. ein Anwendungsprogrammierer sicherlich andere Anforderungen und Erwartungen an ein Modell als ein Endbenutzer. Dementsprechend unterschiedlich wird auch der Begriff „Nutzen" bei beiden Nutzergruppen definiert sein.

3.1

Strukturorientierte Modellbildung

Bei der strukturorientierten (datenorientierten) Modellbildung stehen die Daten und ihre Beschreibung in einem semantischen Datenmodell im Mittelpunkt der Betrachtung. Semantische Datenmodelle eignen sich hervorragend zur Analyse der im Anforderungsdokument enthaltenen statischen Informationsanforderungen. Vorwiegend zwischen 1975 und 1985 wurde eine Vielzahl an semantischen Datenmodellen erarbeitet, die sich zwar in Detailaspekten und ihrer Begriffswahl unterscheiden, aber sich inhaltlich in ihren Grundkonzepten durchaus ähnlich sind. Alle Modelle haben gemeinsam, dass sie die Welt als eine Menge von System-Komponenten (reale oder abstrakte Gegenstände), Eigenschaften von Systemkomponenten und unterschiedliche Formen von Beziehungen zwischen Systemkomponenten beschreiben und Abstraktionsprinzipien verwenden, um elementare Eigenschaften der Realität zu aggregieren und zu Informationseinheiten eines höheren Abstraktionsniveaus zusammenzufassen. Zu den wichtigsten Abstraktionsprinzipien, die in den meisten Modellen enthalten sind, gehören: •

Klassifikation Objekte mit ähnlichen Eigenschaften werden als Instanzen einer Objektklasse betrachtet. Ein Objekttyp besitzt alle Eigenschaften, die die Instanzen der Objektklasse beschreiben.

•

Assoziationen Objekte bzw. Objekttypen können miteinander in Beziehung stehen. Beziehungen können selbst wieder Objekte sein und daher auch Eigenschaften besitzen.

•

Aggregation Aggregation kann es auf verschiedensten Hierarchieebenen eines semantischen Datenmodells geben. Sie beschreibt, wie bestimmte Informationseinheiten zu einem Objekt einer höheren Informationseinheit zusammengefasst werden können. So werden z.B. Werte von

3.1 Strukturorientierte Modellbildung

69

Attributen eines Objekttyps zu einem individuellen Objekt aggregiert, bestimmte Objekte zu einer Unterklasse des Objekttyps zusammengefasst oder zwei Objekte, die miteinander in Beziehung stehen, zu einem Datenaggregat verbunden. •

Generalisierung

Ähnliche Objekte werden aufgrund unterschiedlicher Eigenschaften zu Spezialisierungen zusammengefasst. In Spezialisierungen redundant geführte Attribute bilden einen generischen Objekttyp. Das wohl bekannteste semantische Datenmodell ist das Entity-Relationship-Modell von Peter P. Chen [Chen76], Dieses Modell erfreut sich heute einer sehr großen Beliebtheit. Man kann im Zusammenhang mit diesem Modell durchaus von einem Defacto-Standard für den konzeptuellen Datenbankentwurf sprechen. Das Entity-Relationship-Modell wurde in den letzten zwei Jahrzehnten in vielfältige Varianten abgeändert, so dass man heute auch von der „Familie" der Entity-Relationship-Modelle spricht.

3.1.1

Grundlagen des Entity-Relationship-Modells

In seiner Urform unterstützt das Entity-Relationship-Modell (ERM) ausschließlich die Konzepte Entity, Beziehung und Attribut und hat sich hauptsächlich an den zum Zeitpunkt seiner Entwicklung üblichen Datenbankmodellen, dem hierarchischen und dem relationalen Datenbankmodell orientiert. Die graphischen Konzepte sind sehr einfach gehalten und leicht zu verstehen, was sicher mit ein Grund dafür ist, dass dieses Modell sich gegen eine Vielzahl anderer Modelle durchgesetzt und in der Praxis einen breiten Siegeszug angetreten hat. Das Modell ist in vielen CASE-Werkzeugen und Vorgehensmodellen zur konzeptuellen Modellbildung integriert und wird nicht nur für den Datenbankentwurf, sondern zur Modellierung und Analyse vieler Fragestellungen einer allgemeinen Systemanalyse verwendet. Die Anschaulichkeit und leichte Lesbarkeit des ERM mag der Grund für seine weite Verbreitung sein. Durch seine Einfachheit und die Orientierung an den eher traditionellen Datenbankmodellen ist das ursprüngliche ERM nicht sehr mächtig und vermag die Semantik der Realität nur sehr eingeschränkt widerzuspiegeln. Schon bald nach seiner Publikation haben sich zahlreiche Forschungsprojekte zum Ziel gesetzt, einerseits das ERM um verschiedenste Aspekte zu erweitern und die formalen und theoretischen Grundlagen eines exakten ERM zu erarbeiten bzw. andererseits Modelle aus der Familie des ERM für unterschiedlichste Modellierungszwecke anzuwenden. Heute sind die wichtigsten Fragestellungen im Zusammenhang mit dem ERM in den wissenschaftlichen Journalen und Tagungsbänden vieler Datenbank- und Wirtschaftsinformatikkonferenzen publiziert und es gibt eine eigene wissenschaftliche Konferenzreihe, die jährlich tagt (2001 bereits zum 20. Mal) und die ausschließlich mit Forschungsund Anwendungsfragen im Zusammenhang mit dem ERM beschäftigt. Das ERM wird hauptsächlich zur Beschreibung und Analyse der Struktur der als Informationsanforderungen erhobenen Daten verwendet. Im ERM werden gleichartige Entities zu einem Entitytyp und gleichartige Beziehungen zu einem Beziehungstyp zusammengefasst. Die Beschreibung der Eigenschaften von Entity- und Beziehungstypen erfolgt durch Attribute. Einem Entitytyp müssen, einem Beziehungstyp können Eigenschaften zugeordnet werden. Alle Attribute werden durch Zuordnung eines Wertebereiches typisiert.

70

3 Konzeptueller Datenbankentwurf

Feststellung 3.1:

ERM zur Analyse der Informationsanforderungen

Die Struktur der Informationsanforderungen eines betrachteten Realitätsausschnittes kann durch Herleiten von Entitytypen, Beziehungstypen und Attributen durch ein ERM sehr gut analysiert und durch ein Entity-Relationship-Diagramm (ERD) visualisiert werden.

In einem ERD werden Entitytypen durch Rechtecke, Beziehungstypen durch Rauten und Eigenschaften durch Ellipsen symbolisiert. Die verschiedenen Symbole werden durch ungerichtete (in den meisten Darstellungsformen) Kanten zu einem ERD zusammengefasst. Abbildung 3.2 zeigt die grundlegenden Konzepte eines ERDs in der für dieses Buch gewählten Notation. Bevor wir die einzelnen Konzepte des ERM im Detail betrachten, wollen wir vorerst ein einfaches Beispiel modellieren.

Attribut

Entitytyp Schwacher Entitytyp

Schlüssclattribut Mehrwertiges Attribut

Beziehungstyp

Zusammengesetztes Attribut

Identifizierender Beziehungstyp

Abgeleitetes Attribut

Totale Teilnahme von E2 in Beziehungstyp R

F

1

>N

ρ2

Kardinalität < 1 :N > für E , : E2

Strukturelle Einschränkung (min, max) der Teilnahme von Ε an R

Abb. 3.2:

ERD-Notation

3.1 Strukturorientierte Modellbildung Beispiel 3.1:

71

ERD einer Kursverwaltung

Relevante Entitytypen sind Kurs, Kursleiter, Teilnehmer, Buch und Abteilung, die miteinander in einem semantischen Zusammenhang stehen. Alle Kurse müssen einen Kursleiter haben, und ein Leiter kann mehrere Kurse abhalten. Da in dem ERM kein Zeitbezug dargestellt ist, können mehrere Kurse eines bestimmten Leiters zum selben Zeitpunkt (z.B. im gleichen Semester) stattfinden. Außerdem lässt die Beziehung „leitet" auch Kursleiter zu, die keinen Kurs anbieten. Für bestimmte Kurse sind möglicherweise andere Kurse Voraussetzung, und jeder Kurs kann wiederum Voraussetzung für andere Kurse sein. Für bestimmte Kurse wird das Studium gewisser Bücher empfohlen. Ein bestimmtes Buch kann möglicherweise für mehrere Kurse genutzt werden. Kursleiter müssen, Teilnehmer an Kursen können Abteilungen zugeordnet sein. Kurse können nur stattfinden, wenn sie zugeordnete Teilnehmer haben. Die Beziehung „nimmt_teü" besitzt die qualifizierenden Attribute Beitrag und Note. Kursteilnehmer können an mehreren Kursen teilnehmen. Ein ERD, das diesen Sachverhalt abbildet, ist in Abbildung 3.3 dargestellt.

Abb. 3.3:

Kursverwaltung

Schon dieses kleine und einfache Beispiel konnte den Eindruck vermitteln, dass man mit den wenigen Konzepten des ERM recht rasch komplexe und umfangreiche Analysen einer Anwendung durchführen kann. Häufige Fehlerquellen bei Aufstellung eines ERM sind die richtige Unterscheidung von Konzepten der Realität in Entitytypen oder Beziehungstypen, die Benennung der richtigen Kardinalität für Beziehungstypen bzw. die richtige Modellierung von optionalen und totalen Beziehungstypen. Oft ist die Wahl eines bestimmten Konzeptes auch durch die subjektive Einschätzung des Entwerfers geprägt. So wäre es in Beispiel 3.1 durchaus

72

3 Konzeptueller Datenbankentwurf

möglich, anstelle des Beziehungstypen „nimmt-teil" einen eigenen Entitytypen „Kursteilnahme" einzuführen, der in (1:N)-Beziehung mit Teilnehmer und Kurs steht. Dies könnte gerechtfertigt werden, da sowohl Teilnehmer als auch Kurs verpflichtend an der Beziehung teilnehmen (daher gäbe es in Kursteilnahme keine Nullmarken) und der Beziehungstyp eigene Eigenschaften besitzt. Allerdings müsste in Kursteilnahme eine identifizierende Eigenschaft aufgenommen werden (z.B. eine eindeutige fortlaufende Nummer für alle Teilnahmen), über die alle individuellen Teilnahmen eindeutig identifiziert werden können. Ein großes Problem beim Erstellen eines ERDs ist der mangelnde Platz, der für die Darstellung des Modells zur Verfügung steht. Stehen keine Softwarewerkzeuge zur Unterstützung zur Verfügung, wird man sehr schnell an die Grenzen der graphischen Darstellungsmöglichkeiten eines ERDs gelangen. Um die Übersichtlichkeit nicht zu verlieren, und um etwas Platz einzusparen, werden Attribute in der graphischen Darstellung oft weggelassen und zu jedem ERD wird ein Entity-Katalog erstellt, der für jeden Entity- und Beziehungstyp die erhobenen Attribute mit den entsprechenden Wertebereichen enthält. Eine mögliche Strukturierung eines Entity-Kataloges wurde bereits in Abbildung 2.11 vorgeschlagen. Die folgende Darstellung der Grundkonzepte des ERM ist sehr an die Darstellung der Merkmale von Informationsanforderungen (siehe Unterkapitel 2.3.1) angelehnt und erfolgt daher in straffer Form: Ein Entitytyp beschreibt unter Verwendung von Attributen eine Menge von Entities mit ähnlichen Eigenschaften. Einige der Attribute (oder auch Attributkombinationen) stellen identifizierende Eigenschaften von Entities dar, die es erlauben, über ihren Wert genau ein Entity des jeweiligen Typs eindeutig zu identifizieren. Die Kardinalität und der Grad eines Beziehungstyps definieren das Verhältnis, in welchem Entities der beteiligten Entitytypen zueinander in Beziehung stehen. Abbildung 3.4 enthält Beispiele unterschiedlicher Formen von Beziehungstypen. Der Grad und die Kardinalität eines Beziehungstyps definieren das Verhältnis, in dem Entities der beteiligten Entitytypen zueinander in Beziehung stehen. Der Grad (auch Steifigkeit) einer Assoziation beschreibt die Anzahl der beteiligten Entitytypen. Ein Grad kann jede beliebige Größe annehmen. In den meisten Fällen treten jedoch lediglich Beziehungen mit binärem Grad (zweistellige Beziehungstypen) auf. Zum besseren Verständnis mancher Beziehungstypen in einem Modell wird gelegentlich auf die Bezeichnung durch Rollennamen zurückgegriffen. Eine Rolle definiert die Art und Weise, in der Entities an der Beziehung teilnehmen. Zwingend vorgeschrieben ist die Verwendung von Rollennamen, wenn Entities eines bestimmten Typs mehr als nur einmal an einer Beziehung teilnehmen und dabei in verschiedenen Rollen auftreten können. Ein weiteres Beispiel für die Notwendigkeit von Rollennamen ist ein rekursiver Beziehungstyp, für den Rollennamen erforderlich sind, um die jeweilige Rolle der Entities in der Beziehung zu definieren. Ein Beispiel eines rekursiven Beziehungstyps ist „vorausgesetzt" aus der Kursverwaltung (siehe Abbildung 3.3), in der Kurse entweder in der Rolle „setzt voraus" bzw. „ist Voraussetzung für" auftreten können. In der graphischen Darstellung werden Rollenbezeichnungen an jene Kanten gesetzt, die die entsprechende Beziehung beschreiben. Die Kardinalität eines Beziehungstyps beschreibt die Anzahl von Entities, die an entsprechenden Beziehungen teilnehmen können. Beziehungstypen binären Grades besitzen in der Regel Kardinalitäten von (1:1), (1:N) oder (N:M). Abhängig von der Art der Teilnahme von Entities an einer Beziehung, kann man zwischen einer totalen und einer optionalen Teilnahme unterscheiden. Bei einer totalen Teilnahme müssen alle Entities eines bestimmten Typs an der Beziehung teilnehmen. Eine totale Beziehung impliziert eine Existenzabhängigkeit, da die

3.1 Strukturorientierte Modellbildung Beziehungstypen

Darstellung

Grad rekursiv binär

binär

dreistellig

Kardinalität





Optional / Total optional

total

nicht spezifiziert

Abb. 3.4: Beispiele unterschiedlicher Beziehungstypen

73

74

3 Konzeptueller Datenbankentwurf

Existenz eines Entities von seiner Beziehung zu einem anderen Entity abhängig ist. Bei einer optionalen Teilnahme müssen nicht unbedingt alle Entities eines Typs an der Beziehung teilnehmen, sondern lediglich ein Teil von ihnen. Im Beispielmodell der Kursverwaltung (siehe Abbildung 3.3) sind Entities vom Typ „Teilnehmer" in zwei Beziehungen unterschiedlicher Form involviert. Entities vom Typ „Teilnehmer" können nur existieren, wenn sie zumindest einem Kurs zugeordnet sind (totale Teilnahme). Ob eine Zuordnung zu einer Abteilung existiert, ist nicht spezifiziert. Für diesen Fall kann eine optionale Teilnahme angenommen werden. Eine weitere Methode, die Art der Teilnahme von Entities an einer Beziehung und die Kardinalität eines Beziehungstyps festzulegen, besteht darin, jeden Beziehungstyp mit einem Paar von Integer-Zahlen (min, max) zu belegen. Hierbei stehen die Zahlen in dieser Min-MaxSchreibweise für die jeweils minimale und maximale Anzahl von Beziehungen, an denen Entities der beteiligten Typen teilzunehmen haben (0 < min < max > 1 ) . Der Vorteil dieser Methode ist, dass sie wesentlich präziser ist, Zuordnungen jeglichen Grades und jeglicher Kardinalität sowie eine optionale Beziehung mit min = 0 und totale Beziehungen mit min > 0 ausgedrückt werden können. Als Nachteil ist anzusehen, dass die graphische Darstellung im ERD mehr Platz benötigt. Wir legen uns in diesem Buch auf keine Darstellungsform fest und verwenden die Doppelstrich- und die Zahlenpaarnotation synonym zur Unterscheidung totaler/optionaler Beziehungstypen. Oft gibt es semantisch zusammengehörende Attribute, die einen eigenen Entitytyp bilden, aber nicht ausreichen, um durch ihre Ausprägungen alle Entities dieses Typs eindeutig zu identifizieren, oder es gibt Situationen, in denen die Existenz eines Entities an die Existenz eines Entities eines anderen Typs gebunden ist. Im ersten Fall existieren für den Entitytyp keine Attribute mit Schlüsseleigenschaft. Im zweiten Fall existiert zwischen den Entitytypen eine Existenzabhängigkeit. Um beide Sachverhalte im ERM darstellen zu können, verwendet man das Konzept des schwachen Entitytyps (abhängiger Entitytyp). Voraussetzung für die Modellierung eines schwachen Entitytypen ist eine (1 :N) -Beziehung oder (1:1) -Beziehung zwischen einem entsprechenden „starken" Entitytyp und dem schwachen Entitytyp. Im ERD wird ein schwacher Entitytyp durch ein doppelt umrandetes Rechteck und die dazu gehörende identifizierende Beziehung durch eine doppelt umrandete Raute dargestellt. Eine zweite Möglichkeit, schwache Entitytypen in ein ERD einzubinden, besteht darin, sie als zusammengesetzte oder mehrwertige Attribute darzustellen. Im Allgemeinen ist die Art der Darstellung dem Modelldesigner überlassen. Grundsätzlich sollte jedoch die Darstellung als Entitytyp bevorzugt werden, wenn der schwache Entitytyp über viele Attribute verfügt und/oder selbstständig an weiteren Beziehungen teilnimmt. Abbildung 3.5 illustriert das Konzept des schwachen Entitytyps anhand der Analyse der Informationsanforderungen des Bestellvorganges, wie er im Beispiel 2.7 dargestellt ist. Da in unterschiedlichen Methoden und CASE-Tools oft unterschiedliche graphische Konzepte gewählt werden, fassen wir in Abbildung 3.6 die gebräuchlichsten Darstellungsformen für ERD zusammen.

Beispiel 3.2:

Beispiel Bestellvorgang (Fortsetzung)

Siehe dazu die Analyse der Informationsanforderungen aus Beispiel 2.7. Ein entsprechendes ERM ist in Abbildung 3.5 dargestellt. Die korrekte Verwendung n-stelliger Beziehungstypen in einem ERM ist nicht immer ganz einfach und von der Beantwortung zweier Fragestellungen beeinflusst: Wie wird die Kardina-

3.1 Strukturorientierte Modellbildung

Abb. 3.5: Beispiel Bestellvorgang

75

(Fortsetzung)

lität des Beziehungstyps ermittelt und lässt sich die η-stellige Beziehung unter Verwendung binärer Beziehungstypen äquivalent ausdrücken? Diese Fragen sind auch von großer praktischer Bedeutung, da einige Vorgehensmodelle und Entwurfswerkzeuge ausschließlich binäre Beziehungstypen zulassen. Wir werden diese Problematik anhand eines Beispiels diskutieren. Beispiel 3.3:

Dreistellige

Beziehungstypen

In diesem Beispiel wollen wir unterschiedliche Interpretationen dreistelliger Beziehungstypen untersuchen. Wir betrachten eine Produkt: Teil: Lieferant-Beziehung mit der Semantik, dass für unterschiedliche Produkte Teile benötigt werden, die über Lieferanten bezogen werden. Bei der Bestimmung der Kardinalität eines n-stelligen Beziehungstyps müssen immer (n-1) der an der Beziehung beteiligten Entity typen zusammengefasst werden, um die Anzahl der Entities des verbleibenden Typs zu bestimmen. Für den Beziehungstyp „liefert" aus Abbildung 3.7 ergeben sich somit folgende Situationen: In Abbildung 3.7(a) bezieht das betrachtete Unternehmen von einem Lieferanten ein Teil, das genau in ein Produkt einfließt. Ein bestimmtes Teil in einem Produkt kann ausschließlich von einem Lieferanten stammen und ein Lieferant kann nicht mehr als ein bestimmtes Teil zum Produkt beisteuern. In der Situation, die in Abbildung 3.7(b) beschrieben ist, wird diese Einschränkung aufgehoben, indem ein bestimmter Lieferant für ein Produkt auch mehrere Teile liefern kann. Es gilt jedoch weiterhin, dass jedes Teil dieses Lieferanten ausschließlich für ein Produkt

3 Konzeptueller Datenbankentwurf

76 ERD-Notation dieses Buches

Krähenfuß-Notation wird geleitet

Abteilung

Abteilung

II

II

Kechnungsposition

beschäftigt

Ν Mitarbeiter

beschäftigt

Abteilung

Lieferant

Mitarbeiter

λ

Mitarbeiter

liefert

Artikel

Γ\

Rechnungsposition ist_Gruppenleiter_von

Mitarbeiter

Mitarbeiter iter

Cr

OMT-Notation, nach [RBPE91]

Diamant-Notation, nach [ T E Y F 8 6 ]

wird_geleitet

beschäftigt Abteilung

Mitarbeiter

Abteilung

Mitarbeiter

Abteilung

Artikel

Lieferant

beschäftigt

1·^

beschäftigt

A

Mitarbeiter

beschäftigt Abteilung

Ο

Mitarbeiter

liefert Lieferant

Ο

J+

liefert

Kechnungsposition

ist_Gruppenleiter.von Mitarbeiter

\

|Jpr ^

ist_Gruppenleiter von

Mitarbeiter

Abb. 3.6: Gegenüberstellung von Darstellungsformen flir ERD, nach [Teor98]

Artikel

3.1 Strukturorientierte Modellbildung

77

(a)-Beziehungstyp

(b) < 1 : 1 : P>-Beziehungstyp

(c) -Beziehungstyp

(d) -Beziehungstyp

Abb. 3.7a-d: Beispiele dreistelliger

Beziehungstypen

verwendet werden kann und dass für jedes Teil im Produkt ein einziger Lieferant als Bezugsquelle existieren kann. Diese Einschränkung ist in Abbildung 3.7(c) aufgehoben. Hier kann ein bestimmtes Teil eines Produktes auch von unterschiedlichen Lieferanten bezogen werden. Es gilt aber weiterhin die Einschränkung, dass ein Teil, das bei einem bestimmten Lieferanten bezogen wird, nur in ein Produkt eines bestimmten Typs eingebaut werden darf. Wird dieses Teil auch von anderen Lieferanten bezogen, so kann es auch für Produkte eines anderen Typs verwendet werden. Abbildung 3.7(d) enthält die Darstellung einer Situation, in der keine Einschränkungen hinsichtlich der Verwendung von Teilen in Produkten bestehen. Es kann jetzt ein Lieferant ein Teil liefern, das auch in unterschiedlichen Produkten Verwendung finden kann. Die semantische Aussagekraft dreistelliger Beziehungstypen kann noch erhöht werden, wenn für Entities bestimmter Typen eine verpflichtende Teilnahme an der Beziehung vorgeschrieben wird.

78

3 Konzeptueller Datenbankentwurf

Beispiel 3.3:

Dreistellige Beziehungstypen (Fortsetzung)

In Abbildung 3.7(e) wird eine Situation beschrieben, in der eine Eigenproduktion ausgeschlossen wird, und alle Teile, die Bestandteil von Produkten sind, über Lieferanten bezogen werden. Unter Verwendung von dreistelligen Beziehungstypen kann mehr an Information dargestellt werden als mit drei binären Beziehungstypen möglich ist. In Abbildung 3.7(f) wird eine Situation beschrieben, die nicht mit der Situation, wie sie in Abbildung 3.7(d) dargestellt ist, übereinstimmt. Stellt ein Lieferant Ζ ein bestimmtes Teil t her (t, l) und ist t in einem Produkt ρ enthalten {t, p), das somit Teile enthält, die vom Lieferanten / bezogen werden {p, /), so bedeutet das nicht notwendigerweise, dass die Beziehung auch in „liefert" von Abbildung 3.7(d) enthalten sein muss. Eine äquivalente Darstellung (mit derselben semantischen Aussagekraft) zu Abbildung 3.7(d) kann erreicht werden, wenn man in das Datenmodell einen zusätzlichen Entitytyp „Lieferung" aufnimmt. Die Existenz von Entities vom Typ „Lieferung" ist dann von der Existenz von Instanzen in allen anderen beteiligten Entitytypen abhängig. Abbildung 3.7(g) zeigt eine entsprechende Darstellung.

(e) totale Teilnahme von Produkt

Abb. 3.7e-g:

Beispiele dreistelliger

Beziehungstypen

(f) 3 binäre Beziehungstypen

(Fortsetzung)

3.1 Strukturorientierte Modellbildung

3.1.2

79

Weiterentwicklungen des Entity-Relationship-Modells

Ohne Anspruch auf Vollständigkeit sollen in diesem Unterkapitel die wichtigsten der in der umfangreichen Literatur genannten Erweiterungen des ERM genannt werden. Am Ende des Unterkapitels werden auch zwei prominente Vertreter von „erweiterten" Entity-RelationshipModellen vorgestellt. Die Aggregation wird verwendet, wenn durch Zusammenfassen bestehender Konzepte ein neues Objekt eines höheren Abstraktionsniveaus erzeugt werden soll. Aggregation gibt es auf unterschiedlichstem Niveau. So ist bereits im ursprünglichen ERM vorgesehen, dass Attribute zu zusammengesetzten Attributen aggregiert werden können, oder dass eine Attributmenge zu einem Entitytyp zusammengefasst werden kann. Erweiterungen des ERM schlagen vor, Aggregation auch zur Vereinigung unterschiedlicher Typen zu einem neuen Entitytypen zuzulassen. Beispiel 3.4:

Aggregation im ERM

In Abbildung 3.8 geben wir Beispiele für unterschiedliche Formen von Aggregation. Im ersten Beispiel werden mehrere Attribute zu einem komplexen Attribut aggregiert. Darunter zeigen wir die Aggregation von Attributen zu einem Objekt eines höheren Abstraktionsniveaus, einem Entitytyp. Das dritte Beispiel zeigt die Aggregation von in Beziehung stehenden Entitytypen zu einem neuen Entitytyp. Eine Vorgehensweise, die von einigen Varianten des ERM unterstützt wird.

Abb. 3.8: Aggregation

im ERM

80

3 Konzeptueller Datenbankentwurf

Ein Erweiterungsvorschlag, der in vielen Modellen inkludiert ist, ist das Konzept der Generalisierung (Generalisation). Unter Generalisierung versteht man, dass Entities eines Typs aufgrund gemeinsamer Merkmalsausprägungen in Unterklassen (Sub-Klassen) zusammengefasst werden. Es entsteht somit eine Super-Klasse/Sub-Klassen-Hierarchie, wobei die Generalisierung vorschreibt, dass jedes Mitglied der Sub-Klasse ebenso ein Mitglied der übergeordneten Super-Klasse sein muss. Für die Super-Klasse hat sich auch die Bezeichnung generischer Objekttyp und für eine Sub-Klasse die Bezeichnung Spezialisierung eingebürgert. Der generische Objekttyp beinhaltet alle Attribute, die in allen Spezialisierungen gemeinsam gelten. Dies gilt auch für jenes Attribut, aufgrund dessen Werte die Zuteilung der Entities zu den einzelnen Spezialisierungen erfolgt. Solche Attribute werden auch als Diskriminatoren bezeichnet und im ERD als flaches Sechseck dargestellt. Die Generalisierung definiert eine IS-A-Beziehung (Ist-vom-Typ) zwischen Spezialisierung und generischem Objekttyp und impliziert eine Vererbung von Attributen von Super-Klassen zu Sub-Klassen. Es werden zwei Arten von Generalisierung unterschieden: Bei der Generalisierungshierarchie müssen die Entity-Mengen der Spezialisierungen disjunkt sein, während bei der Subtypenhierarchie Spezialisierungen auch überlappen können.

Beispiel 3.5:

Generalisierungs- und Subtypenhierarchie

In Abbildung 3.9 zeigen wir ein Beispiel für eine Generalisierungs- und eine Subtypenhierarchie. Entities vom Typ „Person" werden aufgrund von Werten ihres Attributes „Status" den disjunkten Klassen „Geschäftspartner" bzw. „Mitarbeiter" zugeordnet. Der Entitytyp „Person" enthält alle gemeinsamen Attribute, die sowohl im Entitytyp „Mitarbeiter" als auch im Entitytyp „Geschäftspartner" gelten. Beide Spezialisierungen erben diese Attribute und werden noch zusätzliche Attribute haben, für die ausschließlich Entities

Abb. 3.9: Generalisierungs-

und Subtypenhierarchie

81

3.1 Strukturorientierte Modellbildung

des entsprechenden Typs Werte aufweisen können. In dem Beispiel ist Typ „Geschäftspartner" auch in eine Subtypenhierarchie involviert. Das bedeutet, dass Entities existieren können, die sowohl vom Typ „Lieferant" als auch vom Typ „Kunde" sein können. Das Prinzip der Vererbung gilt auch für die Subtypenhierarchie. In dem Beispiel bedeutet dies, dass z.B. „Kunde" alle Eigenschaften von „Person" und „Geschäftspartner" enthält und möglicherweise noch weitere eigene Eigenschaften zugeordnet hat.

In den folgenden Unterkapiteln werden wir zwei prominente Vertreter von „erweiterten" ERM vorstellen. Beide Ansätze haben das ursprüngliche ERM um unterschiedliche Aspekte erweitert. Unsere Darstellung beschränkt sich jedoch jeweils nur auf die wichtigsten Konzepte und ist sehr kurz gehalten. Für ein genaueres Studium muss auf die Originalliteratur verwiesen werden. 3.1.2.1

Strukturiertes Entity-Relationship-Modell (SERM)

Das strukturierte Entity-Relationship-Modell (SERM) [Sinz88] [Sinz93] zielt darauf ab, sowohl die Analysemöglichkeiten als auch die graphische Darstellungsform eines ERM für große Modellierungsprojekte zu verbessern. Unter Beachtung von Existenzabhängigkeiten ordnet das Modell die Entitytypen geometrisch so an, dass der Grad der Abhängigkeit von links nach rechts zunimmt. Alle Paare von in Beziehung stehenden Entitytypen werden nach dem Kriterium originär/abhängig geordnet, so dass ein SER-Diagramm, die graphische Darstellung eines SERM-Datenschemas, die Struktur eines gerichteten azyklischen Graphen aufweist. Durch die implizite Einführung einer „Leserichtung" wird es dem Betrachter erleichtert, geeignete Einstiegsknoten zur Analyse des Diagramms zu finden. Das SERM unterscheidet drei unterschiedliche Arten von Objekttypen: Den Ε-Typ und den R-Typ als Äquivalent zum Entity-Typ und Beziehungstyp im ursprünglichen ERM sowie den ER-Typ (Entity-Relationship-Typ), welcher zur Modellierung eines Entitytyps und einer (1:1 >-Beziehung verwendet wird. Aus der Sicht des ursprünglichen ERMs entstehen ER-Typen durch das Zusammenfassen eines E- und eines zugehörigen (l:l)-R-Typen zu einer Einheit. Jede Objekttypart besitzt innerhalb eines SER-Diagramms ein spezielles Rechtecksymbol. Beziehungen zwischen Objekttypen werden als Kanten dargestellt. Abbildung 3.10 zeigt die für SER-Diagramme gewählte Notation.

Entitytyp (E-Typ)

ψ ψ

ER

V

_QJ_

Entity-Relationship-Typ (ER-Typ) Relationshiptyp (R-Typ)

Abb. 3.10: Konzepte des SERM [FeSi98]

1, 1 (nur für Sonderfalle)

82

3 Konzeptueller Datenbankentwurf

Für den Aufbau eines SER-Diagramms gelten folgende Darstellungsregeln, die die quasihierarchische Struktur des Diagramms festlegen: 1. Jede Kante wird gerichtet interpretiert und verläuft vom Gegenstandsanteil eines Objekttyps zum Beziehungsanteil eines Objekttyps. Somit können als Startknoten einer Kante nur Eund ER-Symbole, als Zielknoten ER- und R-Symbole verwendet werden. 2. Jede Kante wird von links nach rechts dargestellt, sodass der Startknoten einer Kante geometrisch links vom Zielknoten angeordnet ist. Die Modellierung eines SERM-Datenschemas läuft auf zwei Ebenen ab. Die erste Ebene umfasst die Aufstellung eines SER-Diagramms, die zweite die Zuordnung von Attributen zu den Objekttypen. Abbildung 3.11 zeigt die SERM-Notation anhand der Struktur des Bestellvorganges. Eine Vergleichsmöglichkeit mit einer äquivalenten Darstellung in der in diesem Buch gewählten Notation bietet Abbildung 3.5.

Beispiel 3.6:

Beispiel Bestellvorgang als SERM (Abbildung 3.11)

Siehe dazu die Analyse der Informationsanforderungen aus Beispiel 2.7.

gehl_an

Lieferant

Auftrag

legt ^

Rechnung enthält

besteht aus

entspricht

/RechnungsV

Artikel

/

Auftragsposition

position

verweist

Abb. 3.11: Bestellvorgang in SERM (nach [FeSi98])

auf

3.1 Strukturorientierte Modellbildung

83

Im Beispiel 3.6 sind Lieferant und Artikel nicht existenzabhängige Objekttypen und daher im SERM-Diagramm ganz links anzuordnen. An einen Lieferanten können ein oder mehrere Aufträge ergehen, jeder Auftrag bezieht sich jedoch auf genau einen Lieferanten. Ähnlich ist die Situation mit Rechnung. Ein Lieferant legt eine oder mehrere Rechnungen vor, und jede Rechnung bezieht sich auf genau einen Lieferanten. Da Lieferanten ohne zugehörige Rechnung zulässig sind, besteht eine einseitige Existenzabhängigkeit zwischen Lieferant und Rechnung. Eine wechselseitige Existenzabhängigkeit besteht z.B. zwischen Rechnung und Rechnungsposition, da jede Rechnung zumindest eine Rechnungsposition haben muss und die Existenz einer Rechnungsposition von der Existenz einer entsprechenden Rechnung abhängt. Als Konsequenz der Anordnungsvorschriften in SERM ist es nicht möglich, zyklische Existenzabhängigkeiten zwischen Objekttypen zu modellieren. Dies kann als Vorteil der Methode gegenüber dem ursprünglichem ERM gewertet werden, da Zyklen oft die Ursache für semantische Inkonsistenzen darstellen. Zusätzliche, in SERM inkludierte Erweiterungen des ERM stellen Generalisierung und Aggregation dar. Des Weiteren beinhaltet das Modell eine Methode zur Überführung von SER-Diagrammen in das relationale Datenbankmodell. 3.1.2.2

Entity-Category-Relationship-Modell (ECR-Modell)

Das ECR-Modell geht auf Elmasri et al. [E1WH85] zurück. Die Konzepte des Modells sind ähnlich den in den Unterkapiteln 3.1.1 und 3.1.2 dargestellten Konzepten. Eine besondere Beachtung verdienen die Strukturierung von Entitytypen in Super- und Subklassen und die damit in Beziehung stehenden Konzepte der Spezialisierung, Generalisierung und Kategorisierung. Im ECR-Modell wird unter einer Superklasse ein Entitytyp verstanden, der über mehrere,Untergruppierungen' (Subklassen) verfügt. Jede Ausprägung einer Subklasse ist auch Entity der Superklasse, wodurch automatisch eine IS-A-Beziehung zwischen Sub- und Superklassen definiert wird. Bei einem Entity einer Subklasse und dem entsprechenden Entity der Superklasse handelt es sich also um dasselbe real existierende Objekt. Aus diesem Grand besitzt ein Entity einer Subklasse nicht nur Werte für Attribute der Subklasse, sondern „erbt" die entsprechenden Attributwerte für Attribute der Superklassen. Im ECR-Modell wird unter dem Begriff der Spezialisierung der Prozess der Definition von Subklassen eines Entitytyps unter Berücksichtigung eines speziellen Charakteristikums der betroffenen Entities verstanden. Hierbei handelt es sich um eine Top-down-Vörgehensweise. Unter der Generalisierung hingegen versteht man den Umkehrprozess der Spezialisierung, bei der kleinere Unterschiede zwischen ähnlichen Entitytypen vernachlässigt werden, um die Entitytypen aufgrund ihrer sonstigen Übereinstimmungen zu einer generischen Superklasse zusammenzufassen. Die Generalisierung ist dabei durch eine Bottom-up-Vorgehensweise gekennzeichnet. Für Spezialisierungen und Generalisierungen können im ECR-Modell bestimmte Einschränkungen (constraints) definiert werden. Unter Verwendung der definition constraint kann der Designer festlegen, aufgrund der Werte welcher Attribute der Superklasse eine Zuordnung von Entities zu Subklassen erfolgt. Die disjointness constraint einer Spezialisierung bzw. Generalisierung gibt an, ob die Subklassen einer Superklasse disjunkt (disjoint) oder aber überlappend (overlapping) sind. Die completeness constraint gibt an, in welchem Maß und Umfang die Entities einer Superklasse einer untergeordneten Subklasse zugeordnet werden. Unterschieden wird dabei zwischen einer totalen Teilnahme, bei der jedes Entity der Superklasse Mitglied

3 Konzeptueller Datenbankentwurf

84

mindestens einer Subklasse sein muss und einer optionalen Teilnahme, bei der ein Entity der Superklasse nicht zwingend auch ein Mitglied einer Subklasse sein muss. Bisher wurde bei Super-/Subklassen-Beziehungen immer von einer einzigen Superklasse ausgegangen. Im ECR-Modell sind IS-A-Beziehungen höherer Komplexität vorgesehen, an denen mehrere Superklassen beteiligt sind. Eine Kategorie ist eine Subklasse mit stets zwei oder mehreren Superklassen. Im Gegensatz zur Attributsvererbung innerhalb von IS-A-Beziehungen bei Generalisierung und Spezialisierung geht die Vererbung im Falle von Kategorien wesentlich genauer vor. Ein Entity einer Kategorie erbt nur jene Attribute einer Superklasse, in der es auch Mitglied ist. Da für unterschiedliche Entities einer Kategorie somit unterschiedliche Attribute geerbt werden können, spricht man in diesem Fall auch von selektiver Vererbung. Die für das ECR-Modell gewählte graphische Notation unterscheidet sich nur durch die schematische Darstellung der neuen Konzepte von der in diesem Buch bisher verwendeten Notation. Da Super- und Subklassen Entitytypen darstellen, werden sie durch Rechtecke im ERD symbolisiert. IS-A-Beziehungen werden durch eine Kante zwischen Super- und Subklasse dargestellt, wobei das Untermengensymbol (C) die Richtung der Mengeninklusion angibt. Mehrfache Spezialisierungen werden durch zusätzliche Kreise in der IS-A-Beziehung dargestellt. Der Kreis steht in diesem Zusammenhang für die Angabe der disjointness constraint. Sind die Subklassen disjunkt, so wird dies durch ein ,d' im Kreis, ansonsten durch ein ,o' gekennzeichnet. Handelt es sich um totale Teilnahme, so wird dies durch einen Doppelstrich ausgedrückt. Um eine Kategorie in einem ERD auszudrücken, werden alle Superklassen über eine IS-ABeziehung und einen Kreis mit dem Entitytyp, der die Kategorie darstellt, verbunden. Das Untermengensymbol wird wiederum verwendet, um die Mengeninklusion auszudrücken und in den Kreis wird ein ,u' (union) eingetragen, um die Mengenvereinigung der Superklassen zu symbolisieren. Im Fall der Kategorisierung können IS-A-Beziehungen ein Prädikat enthalten, das zur selektiven Vererbung genutzt werden kann. Ebenso wie bei der Generalisierung und Spezialisierung wird eine totale Teilnahme an der Kategorisierung durch einen Doppelstrich ausgedrückt.

Beispiel 3.7:

Kategorisierung im ECR-Modell

In Abbildung 3.12 zeigen wir die graphische Notation der Kategorisierung anhand zweier Beispiele. Entities vom Typ Eigentümer erben Attributwerte entweder von Person, Bank oder Firma. Ähnlich ist die Situation bei Zulassung. Abhängig vom Typ des betrachteten Fahrzeugs erbt ein Entity vom Typ Zulassung entweder Attributwerte von Pkw oder Lkw.

3.1.3

Literatur

Das ERM ist nunmehr seit vielen Jahren Gegenstand einer eigenen wissenschaftlichen Konferenzreihe. Um dem interessierten Leser einen raschen Zugang zu Originalarbeiten zu ermöglichen, wollen wir an dieser Stelle einen Quellenhinweis auf die seit 1990 erschienenen Berichte dieser Reihe geben ([E1KT94], [EmGo97], [Kang90], [Louc94], [Papa95], [PeTj92], [Teor91], [Thal96]). Allgemeine Literaturhinweise zum ERM finden sich unter den Quellenangaben am Ende dieses Kapitels.

3.1 Strukturorientierte Modellbildung

3.1.4 Aufgabe 3.1:

85

Kontrollaufgaben Konzepte des ERM

Beschreiben Sie anhand eines frei gewählten Beispiels die unterschiedlichen Konzepte des ERM. Gehen Sie auf die verschiedenen graphischen Darstellungsformen ein und geben Sie an, welche Konzepte bereits im ursprünglichen Modell nach Chen enthalten waren und welche später neu hinzu gekommen sind. Aufgabe 3.2:

Eigenschaften fiir Attribute und Beziehungstypen

Zeigen Sie anhand eines frei gewählten Beispiels, wie die in Abbildung 2.7 und Abbildung 2.10 gezeigten Strukturierungsmerkmale für Attribute und Beziehungstypen aus dem Anforderungsdokument in einem ERD ausgedrückt werden können.

86

3 Konzeptueller Datenbankentwurf

Aufgabe 3.3: Weiterentwicklungen des ERM Beschreiben Sie die wesentlichen Einschränkungen im ERM und zeigen Sie, wie im SERMund ECR-Modell versucht wurde, diese Einschränkungen zu umgehen. Aufgabe 3.4: ERM des Sportvereins Erstellen Sie aufgrund der in Aufgabe 2.6 durchgeführten Analyse der Informationsanforderungen des Sportvereins ein ERM. Aufgabe 3.5: ERM zur Verwaltung von Umweltschutzprojekten Entwerfen Sie ein ERD als Grundlage für eine zu erstellende Datenbank zur Verwaltung von Umweltschutzprojekten. Projekte können nicht eindeutig in Kategorien eingeteilt werden. Es gibt Projekte mit Zielsetzung 1) Verringerung von Schadstoffemissionen, 2) Entwicklung von alternativen Verpackungsformen, 3) Energiesparmaßnahmen, 4) Entwicklung von alternativen Energieformen. Jede dieser Projektkategorien wird durch unterschiedliche Eigenschaften charakterisiert. Alle Projekte gemeinsam haben eine eindeutige Projektnummer, einen Projektträger (entweder eine natürliche oder eine juristische Person), einen Standort, einen Projektbeginn und ein voraussichtliches Abschlussdatum. Bei Projekten, die ihren Standort im Ausland haben, wird obige Einteilung in Kategorien nicht vorgenommen. Dafür wird zusätzlich zum Standort noch die Anschrift einer Kontaktperson mitgeführt. Inlandsprojekte werden entweder vom Fonds zur Förderung der wissenschaftlichen Forschung, vom Wirtschaftsförderungsfonds oder von beiden gemeinsam gefördert. Es soll pro Projekt und beteiligter Förderungsstelle die Höhe der Förderung, die Zahlungsart und das Datum der ersten Geldüberweisung gespeichert werden. Für jedes Projekt werden die Mitarbeiter am Projekt gespeichert. Ein Mitarbeiter darf nur an einem Projekt arbeiten. Für ein Auslandsprojekt darf es nicht mehr als 10 Projektmitarbeiter geben. Einer davon, der Leiter des Auslandsprojektes, muss die Sprache des Landes beherrschen, in dem das Projekt, das er leitet, angesiedelt ist. Außerdem wird für alle Mitarbeiter an Auslandsprojekten eine Ortszulage gewährt (sie kann für jeden Mitarbeiter individuell verschieden hoch sein). Mitarbeiter an Inlandsprojekten können einen Dienstwagen (Kennzeichen, Typ, Baujahr) haben. Aufgabe 3.6: ERM Autoverleihfirma Beschreiben Sie durch ein ERD folgenden Ausschnitt aus den Anforderungen an ein Informationssystem einer Autoverleihfirma: Es sollen Daten über Angestellte, Kunden und Fahrzeuge verwaltet werden. Angesteile (Anr, Name, Adresse, Gehalt) werden nach ihrer Verwendung in die zwei Gruppen Verwaltungsangestellte und Kfz-Mechaniker eingeteilt. Für Verwaltungsangestellte wird eine Liste ihrer speziellen Fähigkeiten geführt (z.B. Maschineschreiben, Englisch, Excel, . . . ) . Mechaniker werden zu Teams zu jeweils 5 Leuten zusammengefasst. Jedem Team ist ein Leiter zugeteilt, er muss die Kfz-Meisterprüfung abgelegt haben. Jedes Fahrzeug des Unternehmens ist genau einem Mechanikerteam zugeordnet. Fahrzeuge sind in Kategorien eingeteilt. Mögliche Kategorien sind: Nutzfahrzeuge, Personenkraftwagen, Kombi, Fun-Car, Motorräder. Die Einteilung in Kategorien ist nicht eindeutig, so wird z.B. ein Cabrio sowohl in der Kategorie Fun-Car als auch in der Kategorie Personenkraftwagen geführt. Über Fahrzeuge sollen folgende Daten gespeichert werden: Kennzeichen,

3.1 Strukturorientierte Modellbildung

87

Anschaffungsdatum, Typenbezeichnung, PS. Für jede der angegebenen Kategorien sollen unterschiedliche Eigenschaften gespeichert werden. Wird ein Fahrzeug von einem Mechanikerteam repariert bzw. gewartet, sollen die Daten der Reparatur oder Wartung ebenfalls aufgezeichnet werden. Dabei ist relevant, welches Fahrzeug betroffen war, welches Team die Arbeit ausgeführt hat, wann die Arbeit ausgeführt wurde, wie viel Zeit benötigt wurde und welche Ersatzteile in welcher Menge verwendet wurden. Im Ersatzteillager wird ein Verzeichnis geführt, in dem für jedes Ersatzteil die Ersatzteilbezeichnung, die lagernde Menge und ein Meldebestand verwaltet werden. Über die Kunden des Unternehmens werden folgende Daten verwaltet: Kundennummer, Name, Adresse. Beim Abschluss eines Mietvertrages werden Datum, Zeit und Ort der Fahrzeugausgabe und der Fahrzeugrückgabe vereinbart. Es wird der Kilometerstand zum Zeitpunkt der Vergabe und zum Zeitpunkt der Rückgabe im Mietvertrag verzeichnet. Jeder Mietvertrag wird eindeutig durch den Kunden, das Fahrzeug und das Abschlussdatum bestimmt. Aufgabe 3.7: ERM Krankenhausinformationssystem Erstellen Sie für nachfolgende Anforderungen an ein Krankenhausinformationssystem ein ERD. Eine Station wird durch die Stat-Nr, Stat-Bezeichnung und die Bettenanzahl beschrieben. Jede Station hat einen leitenden Arzt und eine Menge an zugeteilten Ärzten. Ein Arzt kann nur eine Station leiten, kann aber mehreren Stationen zugeteilt sein. Ärzte werden durch ihre SVNr eindeutig beschrieben und besitzen die Eigenschaften Name, Fachgebiet und Gehalt. KIS soll ein Verzeichnis aller bekannten Krankheiten und aller in der EU zugelassenen Medikamente beinhalten. Krankheiten werden eindeutig durch ICD sowie durch ihre Bezeichnung und die Therapie beschrieben. Für Medikamente sollen die Codex-Nr (eindeutig), die M-Bezeichnung, die Erzeugerfirma und die bekannten Nebenwirkungen aufgezeichnet werden. Ein Medikament kann mehrere Nebenwirkungen haben und Medikamente können sich hinsichtlich ihrer Wirkung gegenseitig beeinflussen. Für den Fall einer Beeinflussung soll ein Textfeld „Art der Beeinflussung" vorgesehen werden. Medikamente heilen Krankheiten. Für Patienten soll eine Patienten-Nr, die SVNr, der Name und das Geb-Datum gespeichert werden. Patienten leiden unter bestimmten Krankheiten (auch mehrere möglich), liegen auf einer Station und bekommen von einem bestimmten Arzt Medikamente in unterschiedlicher Dosierung verabreicht. Für bestimmte Patienten soll Information über Verwandte gespeichert werden können. Verwandte sollen durch ihren Namen, das Verwandtschaftsverhältnis und das Geburtsdatum beschrieben werden. Es soll aus dem ERD ersichtlich sein, dass Ausprägungen von Verwandten nur so lange in der Datenbank gespeichert bleiben, solange zugehörige Patienten im KIS enthalten sind. Aufgabe 3.8: ERM Kursverwaltung Stellen Sie den nachfolgend dargestellten Sachverhalt als ERD dar. Das betrachtete Unternehmen unterhält eine Ausbildungsabteilung, deren Aufgabe es ist, unterschiedliche Kurse durchzuführen. Jeder Kurs findet innerhalb des Unternehmens an verschiedenen Orten statt. Die zu erstellende Datenbank enthält sowohl Kurse, die bereits abgehalten wurden, als auch Kurse, deren Abhaltung erst geplant ist. Folgende Details sollen modelliert werden:

88

3 Konzeptueller Datenbankentwurf

•

Für jeden Kurs: Kursnummer (eindeutig), Kursbezeichnung, Kursbeschreibung, vorausgesetzte Kurse (falls vorhanden), Zeitbezug (durchgeführt, geplant).

•

Für jeden Vorausgesetzen Kurs seine Kursnummer und Kursbezeichnung.

•

Für jedes Kursangebot: Datum, Ort, Art (z.B. ganztägig, halbtägig), beteiligte Leiter, beteiligte Teilnehmer.

•

Für jeden Kursleiter eines angebotenen Kurses: Mitarbeiternummer und Name

•

Für jeden Kursteilnehmer an einem angebotenen Kurs: Mitarbeiternummer, Name, Gehalt.

Aufgabe 3.9: ERM Flughafeninformationssystem Die zu erstellende Datenbank soll einen Ausschnitt der Anforderungen an ein Flughafeninformationssystem darstellen. Eine umfangreiche Anforderungsanalyse hat zu folgender informellen Beschreibung der Anforderungen geführt: Die Datenbank soll zur Verwaltung von Informationen über Flugzeuge, ihre Eigner, Angestellte des Flughafens (Piloten, Techniker) und Wartungsarbeiten verwendet werden. Jedes Flugzeug hat eine Registriernummer, gehört zu einem bestimmten Typ und ist einem Hangar zugeordnet. Jeder Flugzeugtyp hat eine bestimmte Modellbezeichnung, Passagierkapazität und Gewicht. Ein Hangar wird durch eine Nummer, seine Kapazität und seinen Standort charakterisiert. Eigner von Flugzeugen sind entweder natürliche Personen oder Firmen und haben Flugzeuge zu einem bestimmten Zeitpunkt erworben. Techniker sind für Wartungsarbeiten an bestimmten Flugzeugtypen eingeschult und führen Wartungen durch. Für jede Wartung wird ein Servicebuch geführt, wobei das Datum, Arbeitsstunden und die Art der Arbeit eingetragen werden. Wartungen konsumieren Ersatzteile. Piloten besitzen Lizenzen und dürfen davon abhängig Flugzeuge fliegen. Modellieren Sie den dargestellten Sachverhalt unter Verwendung des ERM.

3.2

Struktur- und funktionsorientierte Modellbildung

3.2.1

Gründe für die Verwendung der Kombinationsmethode

Die klassischen Spezifikations- und Entwurfsmethoden nutzen als Entwurfsgrundlage vornehmlich die Funktionen, die ein System oder eine Systemkomponente zur Verfügung stellen muss. Als Beschreibungsmittel werden meist Datenflussdiagramme (siehe Unterkapitel 2.3.2) eingesetzt, die die Eingabe, Ausgabe und Transformation von Daten durch Prozesse und den Datenfluss zwischen Prozessen auf unterschiedlichem Abstraktionsniveau darstellen. In den letzten Jahren hat sich die rein funktionsorientierte Vorgehensweise beim Datenbankentwurf als nicht zweckmäßig herausgestellt, da eine ausschließliche Betrachtung von Funktionen zwangsläufig zu wenig integrierten und oft starke Redundanz aufweisenden Datenbeständen führt. Außerdem verfügen Funktionsmodelle über klar definierte Systemgrenzen, die Erweiterungen bzw. Veränderungen eines Systems nur schwer ermöglichen. Die Funktionsmodellierung ist als Spezifikations- und Entwurfsmethode nur für Anwendungen geeignet, in denen die zu verarbeitenden Daten eine viel geringere Bedeutung als die darauf zugreifenden Funktionen besitzen.

3.2 Struktur- und funktionsorientierte Modellbildung

89

Der funktionsorientierten Vorgehensweise beim Datenbankentwurf steht die rein strukturorientierte Vorgehensweise gegenüber. Bei der strukturorientierten Vorgehensweise stehen die Daten und ihre Beschreibung in einem Datenmodell im Mittelpunkt der Betrachtung. Das Datenmodell ist sowohl Ausgangspunkt für den technischen Entwurf der Datenbank als auch für die Spezifikation der Funktionen. Es ist statisch, d.h. es beschreibt keine Abläufe zur Verarbeitung der Daten, sondern ausschließlich eine zeitpunktunabhängige Darstellung der Struktur der Daten. Die strukturorientierte Vorgehensweise ist eine wichtige Voraussetzung für die Integration betrieblicher Informationssysteme, da die Daten hier so strukturiert werden, dass sie von den Funktionen und Programmen weitgehend unabhängig sind. Es lassen sich so Redundanzen und Inkonsistenzen in den Datenbeständen weitgehend vermeiden. Aufgrund der Einschränkungen der funktionsorientierten Modellbildung wird in vielen Entwurfsprojekten das Datenmodell gegenüber dem Funktionsmodell favorisiert. Dies wird auch dadurch gerechtfertigt, dass die relevanten Daten einer Unternehmung leichter zu erheben sind als die Funktionen. Des Weiteren weisen die Daten in den meisten Fällen eine längere Lebensdauer auf und haben eher eine statische Struktur, während sich Funktionen häufiger ändern. Allerdings kann eine Überbewertung der Daten zu einer Vernachlässigung der funktionalen Aspekte führen, d.h. es werden nur die konzeptuellen Datenstrukturen ermittelt und dargestellt, aus denen sich dann später die funktionalen Zusammenhänge jedoch nicht mehr ableiten lassen. Feststellung 3.2:

Kombination von Daten- und Funktionsmodellen

Bei einer getrennten Analyse von Daten und Funktionen sind Datenstrukturen und funktionsorientierte Programme nur schwer aufeinander abstimmbar. Werden Funktions- und Datenmodelle eigenständig entwickelt, entsteht zwischen Datenbanksystem und auf die Daten zugreifenden Programmen eine sehr breite und pflegebedürftige Schnittstelle. Es liegt daher nahe, Daten- und Funktionsmodelle zu kombinieren, um diese Nachteile zu vermeiden und die Vorteile beider Methoden in eine einheitliche Methode zu integrieren. Welche Möglichkeiten dafür in Frage kommen, soll in diesem Unterkapitel untersucht werden. Es sind verschiedene Vorgehensweisen denkbar, um Daten- und Funktionsmodelle zu kombinieren. So kann z.B. erst eine Funktionsanalyse mit anschließender Datensynthese erfolgen. Bei dieser Vorgehensweise werden die Funktionen eines Systems schrittweise zerlegt und für die so entstandenen elementaren Funktionen werden dann Datenmodelle entworfen, die in einer Synthese zu einem unternehmensweiten Datenmodell integriert werden. Eine andere Vorgehensweise wäre, das Datenmodell ähnlich wie das Funktionsmodell direkt top-down schrittweise zu verfeinern. Diese Vorgehensweise hätte den Vorteil, dass Daten- und Funktionsmodellierung parallel durchgeführt werden können und das Informationssystem aus diesen beiden Sichten stufenweise herausgearbeitet werden kann. Im folgenden Unterkapitel wird die Kombination aus struktur- und funktionsorientierter Modellbildung anhand der zweiten Alternative genauer besprochen.

3.2.2

Kombination von ERM und DFD

Die integrierte Methode für die Daten- und Funktionsanalyse wurde von Batini, Ceri und Navathe [BaCN92] vorgeschlagen und beruht auf einer integrierten Top-down-Verfeinerung

90

3 Konzeptueller Datenbankentwurf

eines Funktions- und Datenmodells. Die Methode führt zu einem unternehmensweiten Datenmodell, in dem Verfeinerungen, Verdichtungen und Ergänzungen zu beiden Modellen in einem iterativen und nicht in einem ausschließlich phasenbezogenen Prozess vorgenommen werden. Die Methode soll zuerst vorgestellt und dann anhand eines Beispiels näher erläutert werden. Ausgangspunkt der Methode ist die Vorstellung vom zu entwickelnden Informationssystem oder eines ausgewählten Funktionsbereiches einer bestimmten Nutzergruppe (externe Sicht auf das Datenbanksystem). Im nächsten Schritt werden die Schnittstellen zwischen den einzelnen Funktionsbereichen im Unternehmen sowie die Schnittstellen zwischen Informationssystem und seiner Umwelt (z.B. bestehende Applikationen, Nutzer, ...) charakterisiert. Dies führt zu einer ersten Festlegung der Input-/Outputflüsse und damit verbunden der Hauptprozesse des Informationssystems, die die zuvor gefundenen Schnittstellen nutzen. Aus den Hauptprozessen ergibt sich ein erstes funktionales Kontextdiagramm, das so genannte F-Grundschema. Aus dem F-Grundschema wird ein erstes Datenmodell entwickelt, das die Struktur der Daten auf dem hohen Abstraktionsniveau des Kontextdiagrammes repräsentiert. Das Datenmodell wird als D-Grundschema bezeichnet. Beim Entwurf des D-Grundschemas muss geprüft werden, ob alle Initiatoren und Terminatoren des F-Grundschemas im Informationssystem enthalten sein sollen. Dies ist ein schwieriger Vorgang, weil es nicht immer eindeutig ist, ob entsprechende Entities im Informationssystem eine Rolle spielen oder lediglich eine Informationsquelle für das System von außen darstellen. Sind im D-Grundschema die ersten Entitytypen identifiziert, muss überprüft werden, ob sie auf demselben Abstraktionsniveau wie die entsprechenden Komponenten des F-Grundschemas liegen. Ist dies nicht der Fall, müssen Aggregationen und Generalisierungen verwendet werden, um das Abstraktionsniveau des D-Schemas dem des F-Schemas anzugleichen. Nach diesen vorbereitenden Schritten ist die Bestimmung des Dund F-Grundschemas abgeschlossen. Beide Schemata zeigen eine anfängliche Darstellung der Daten bzw. der Funktionen, die in den folgenden Phasen nach und nach weiter verfeinert werden. Die eigentliche Modellbildung entsteht durch fortschreitende Verfeinerung von F- und DSchema. Das F-Schema kann entweder durch Anwendung der Top-down-Vorgehensweise verfeinert werden, indem jeder Prozess in mehrere Teilprozesse untergliedert wird, oder es kann die Inside-Out-Strategie zur Anwendung kommen. Dabei wird der Datenfluss zwischen Initiator und einem Prozess betrachtet, der die Ursache dafür sein kann, dass der Prozess in Teilprozesse gegliedert werden kann. Für die so entstandenen neuen Prozesse im F-Schema werden Datenspeicher und Prozesse bestimmt, aus denen Informationen ausgelesen oder an die Daten weitergegeben werden. Danach wird wieder geprüft, ob die Datenspeicher und Prozesse Informationen von noch nicht im F-Schema enthaltenen Komponenten erhalten bzw. weitergeben. Ist dies der Fall, so werden solche Komponenten in das F-Schema aufgenommen. Das D-Schema wird verfeinert, indem geprüft wird, ob alle Komponenten des F-Schemas eine Entsprechung im D-Schema besitzen. Ist das nicht der Fall, so werden in das D-Schema neue Entity- und Beziehungstypen aufgenommen bzw. durch Bildung von Generalisierungen und Aggregationen Verfeinerungen vorgenommen. Das D-Schema ist schließlich komplett in Bezug auf das F-Schema, wenn die Struktur aller Initiatoren, Terminatoren und Datenspeicher des F-Schemas im D-Schema beschrieben ist. Das F-Schema ist komplett in Bezug auf das D-Schema, wenn jeder Entitytyp aus dem DSchema zumindest in einem Prozess im F-Schema Verwendung findet. D- und F-Schema

3.2 Struktur- und funktionsorientierte Modellbildung

91

befinden sich im Fall von gegenseitiger Vollständigkeit auf demselben Abstraktionsniveau, eine Verfeinerungsstufe ist abgeschlossen und die nächste kann beginnen. Alle folgenden Verfeinerungsstufen beginnen wieder mit einer Verfeinerung des F-Schemas, wobei die Vorgehensweise dieselbe bleibt. Es wird mit der Top-down- oder Inside-OutVorgehensweise geprüft, ob irgendwelche Prozesse noch weiter untergliedert werden können oder weitere Datenspeicher eingeführt werden müssen. Dazu kann jetzt auch das überarbeitete D-Schema aus der vorhergegangenen Verfeinerungsstufe Hilfe leisten. Es wird geprüft, ob alle Entity- und Beziehungstypen, die in diesem verwendet wurden, durch Prozesse und Datenspeicher abgedeckt sind oder weitere hinzugefügt werden müssen. Auch die weiteren Verfeinerungen des D-Schemas entsprechen der ersten. In der letzten Verfeinerung des DSchemas werden den Entitytypen und Beziehungstypen alle nötigen Attribute, die aus den Entitykatalogen des Anforderungsdokumentes bekannt sind, hinzugefügt. Sind beide Schemata ausreichend verfeinert, wird ein abschließender Vollständigkeitstest durchgeführt. Für das D-Schema wird dabei geprüft, ob alle Entity- und Beziehungstypn von einem oder mehreren Datenspeichern und Prozessen benutzt werden. Für das F-Schema wird untersucht, ob es für jeden Entity- und Beziehungstyp einen Prozess gibt, der diese erzeugt oder benutzt. Gegenseitige Vollständigkeit ist folgendermaßen definiert: Das D-Schema ist vollständig in Bezug auf das F-Schema, wenn alle Anforderungen, die durch Datenflüsse und Datenspeicher im FSchema ausgedrückt werden, auch im D-Schema vorkommen. Das F-Schema ist vollständig in Bezug auf das D-Schema, wenn alle Operationen, die eine Datenanfrage oder -manipulation erwirken, durch einen Prozess des F-Schemas erfolgen. Es muss also für jedes gespeicherte Datenelement einen Prozess geben, der es erzeugt, verändert und eventuell auch löscht. Die Kombination aus struktur- und funktionsorientierter Modellbildung soll nun anhand eines Fallbeispiels erörtert werden. Beispiel 3.8:

Struktur- und funktionsorientierte

Modellbildung

Das Beispiel behandelt einen Teilbereich des Bestellwesens, nämlich die Auswahl von Lieferanten aufgrund ihrer Angebote nach einer Ausschreibung. U.a. sind in diesem Beispiel folgende Informationen von Relevanz: Für bestimmte Artikel sind vorgegebene Liefervoraussetzungen (wie z.B. Transport im Kühlwagen, Lieferservice innerhalb von zwölf Stunden, Mindestbezüge) vorgesehen und Lieferanten bieten Artikel mit unterschiedlichen Konditionen an (z.B. Mindestabnahme, Transportzuschlag, Zahlungskonditionen). In den Auswahlprozess werden auch subjektive Einflussgrößen (wie z.B. bisherige Erfahrungen mit diesem Lieferanten oder seine Reputation) einbezogen. Die struktur- und funktionsorientierte Modellbildung des Funktionsbereiches „Lieferanten-Auswahl" ist in Abbildung 3.13 dargestellt. Der Vorgang „Lieferanten-Auswahl" wird von einem Initiator „Lieferant" angestoßen, der für bestimmte Artikel ein Angebot vorlegt. Diese Situation ist im F-Grundschema (Abbildung 3.13(a)) dargestellt. Der Prozess 1 wird von einem Lieferanten initiiert, trifft nach Zugriff auf Artikeldaten eine Entscheidung und informiert den Lieferanten über das Ergebnis. Aus diesem ersten Kontextdiagramm kann bereits ein D-Grundschema (Abbildung 3.13(b)) entwickelt werden. Der Datenspeicher „Artikel" und der Initiator „Lieferant" werden vorerst als Entitytyp abgebildet. Da Artikel von Lieferanten angeboten werden, wird zur Darstellung dieses Sachverhaltes ein Beziehungstyp vorgesehen. Das Fund D-Grundschema beschreiben den Funktionsbereich „Lieferantenwahl" auf der höchst-

92

3 Konzeptueller Datenbankentwurf

Lieferant

%D i l

1 ίLieferantenΊ Artikeldaten


r

ί

1 3

1

Weiterverarbeitung L Weiter J Benachrichtigung

(c) F-Schema nach erster Verfeinerung

N

Μ

Angebot

Ν >

Μ

Artikel

(d) D-Schema nach erster Verfeinerung

Abb. 3.13a-d:

Struktur- und funktionsorientierte

Modellbildung

3.2 Struktur- und funktionsorientierte Modellbildung

93

möglichen Abstraktionsebene. In der ersten Verfeinerung des F-Schemas wird der Prozess „Lieferanten-Auswahl" aus dem F-Grundschema genauer analysiert und im Rahmen einer Top-down-Zerlegung durch ein neues DFD genauer spezifiziert. Aus Abbildung 3.13(c) ist ersichtlich, dass alle eingegangenen Angebote in einem Datenspeicher „Angebote" abgelegt werden. Dies ist notwendig geworden, da das D-Schema eine Beziehung „bietet-an" vorsieht, die im F-Schema bisher keine Entsprechung hat. In einem weiteren Bearbeitungsschritt wird der Lagerbestand für in Angeboten genannte Artikel geprüft. Weitere Details sind aus dieser ersten Verfeinerung nicht ersichtlich. Das F-Schema bildet nun wieder die Grundlage zur Überarbeitung des D-Schemas aus dem vorhergegangenen Analyseschritt. Die bisherige Version des D-Schemas differenziert nicht zwischen Angeboten und Artikeln. Diese Darstellung im Datenmodell ist nun nicht mehr konsistent mit der dargestellten Situation im Funktionsmodell und eine Verfeinerung des D-Schemas ist angebracht. In Abbildung 3.13(d) haben wir uns zur Differenzierung für einen Entitytyp „Angebot" und einen Beziehungstyp „wird-bezogen" entschieden. In bestimmten Situationen hätte man den Sachverhalt durchaus auch anders modellieren können, z.B. Angebote als Beziehungstypen zwischen Lieferant und Artikel oder Angebote als Spezialisierung von Artikel im Rahmen einer Generalisierungshierarchie. In einem weiteren Verfeinerungsschritt wird das F-Schema einer neuerlichen Analyse unterzogen, und der Prozess „Weiterverarbeitung" wird in seine Teilprozesse aufgespalten. In Abbildung 3.13(e) ist die Verfeinerung wie folgt dargestellt: Prozess „Voraussetzung prüfen" greift auf einen Datenspeicher „Artikel" zu und prüft, ob für die im Angebot genannten Artikel besondere Liefervoraussetzungen existieren. Prozess „Bedingungen prüfen" prüft die im Angebot angeführten Lieferbedingungen anhand der für die Artikel bestehenden Liefervoraussetzungen. Prozess „Erfahrungen auswerten" greift auf den Datenspeicher „Lieferant" zu, um eventuell vorhandene Informationen über den Angebotleger zu eruieren. Im Prozess „Entscheidung treffen" werden die erhobenen Daten miteinander verglichen und es wird entschieden, ob eine Bestellung vorgenommen wird oder nicht. Im Falle einer Bestellung erfolgt die Zuordnung von „Lieferant" zum Terminator „Artikel" und die Benachrichtigung des Angebotlegers. Im Falle einer Ablehnung erfolgt eine Mitteilung an den Angebotleger. Abbildung 3.13(e) enthält das endgültige funktionale Modell der Lieferantenwahl. Aufgrund der Top-down-Vorgehensweise und der mehrmaligen Verwendung ähnlicher Datenspeicher auf unterschiedlichen Modellierungsebenen, weist das DFD Datenredundanzen auf, die bei der Ermittlung des endgültigen D-Schemas vermieden werden sollen. Zur Erstellung des endgültigen D-Schemas wird vorerst das bisherige Datenmodell herangezogen und anhand des F-Schemas auf Vollständigkeit überprüft. Eine mögliche Lösung für das endgültige D-Schema ist in Abbildung 3.13(f) dargestellt. In einem abschließenden Entwurfsschritt werden beide Schemata gegenseitig auf Vollständigkeit geprüft und das D-Schema um Attribute erweitert. In dem Beispiel sind Attribute nur exemplarisch angegeben. Die dargestellte Kombinationsmethode aus struktur- und funktionsorientierter Vorgehensweise zur Bildung eines Datenmodells zeichnet sich dadurch aus, dass zwischen Daten- und Funktionsmodellierung eine starke Interaktion herrscht. Änderungen am F-Schema können Änderungen am D-Schema verursachen und Änderungen am D-Schema können wiederum Änderungen am F-Schema zur Folge haben. Wird z.B. bei einer Verfeinerung des F-Schemas ein Prozess

94

3 Konzeptueller

Lieferant Ii

Angebot

η

w

1 1 · Ί Angebot ablegen L A Ableg

f

ί

1 2

Bestand prüfen l Β Prüf

Ί J

An9eb

Datenbankentwurf

° V [D2[Ängeböte

^ Artikel- Γ bestandj a

Artikel

1 3 1 Γ · · Ί Voraussetz. . Liefer- ίΐ " voraus-1; prüfen l Voraus J Setzungen

JD4| Angebot Lieferbedingungen

Informationen |D5| Lieferant

k

1.3.6 keine Bestellung Absage

(e) endgültiges

ί

1 3 5 Ί Bestellung Lieferant vornehmen l Zusage J

F-Schema

ρ Datum — Gültigkeit — Zahlungsmodalitäten

N

Angebot

— Mindestmenge —Transportform —Stückpreis

Μ

r Lieferdatum Ν Ν

(f) endgültiges

Abb.

3.13e,f:

/ ^ r d \ xpezogen/

Μ

Artikel

i-A-Nr _ - A-Bez — Min-Bestand — Akt-Bestand

I— — —

LV-Nr Transportart Versicherung max. Dauer Anmerkung

D-Schema

Struktur-

und funktionsorientierte

Modellbildung

(Fortsetzung)

Artikel

3.3 Objektorientierte Modellbildung

95

in mehrere Teilprozesse gegliedert, so kann das zu drei unterschiedlichen Auswirkungen im D-Schema führen: Bezieht sich jeder der Teilprozesse auf eine disjunkte Untermenge eines Entitytyps, so kann im D-Schema eine Generalisierung des Entitytyps vorgenommen werden. Bezieht sich nur einer der Teilprozesse auf eine Teilmenge der Entities eines bestimmten Typs, so kann im Datenmodell eine Untermengenhierarchie gebildet werden. Die letzte Möglichkeit besteht darin, dass sich alle Teilprozesse weiterhin auf alle Entities eines bestimmten Typs beziehen. Ist dies der Fall, so kann keine Verfeinerung am Datenmodell vorgenommen werden. Verfeinerungen am D-Schema können jedoch auch Auswirkungen auf das F-Schema haben. Wird z.B. im D-Schema eine Generalisierung vorgenommen, so kann das Auswirkungen im F-Schema haben. Aus einem Prozess können weitere entstehen und jeder Teilprozess wirkt sich auf eine Spezialisierung im Datenmodell aus. Die Teilprozesse können unabhängig voneinander sein oder durch Datenfluss oder über Datenspeicher miteinander verbunden werden. Um ein vollständiges und konsistentes System zu erhalten, ist es wichtig, sowohl funktionale als auch die Datenstruktur betreffende Aspekte in den Entwurfsprozess zu integrieren. Dabei ist wichtig, dass Daten- und Funktionsmodelle nicht getrennt voneinander entwickelt werden, sondern dass beide Aspekte im Laufe der gesamten Entwicklung nebeneinander berücksichtigt werden. Dies ist insbesondere darin begründet, dass zwischen den unterschiedlichen Modellen eine strenge Bindung herrscht und Hinzufügungen oder Änderungen in dem einen Modell durchaus Auswirkungen auf das andere Modell haben können. Die in diesem Unterkapitel dargestellte Modellierungstechnik basiert auf diesen Überlegungen.

3.2.3

Kontrollaufgaben

Aufgabe 3.10: Struktur- vs. funktionsorientierte Modellbildung Erklären Sie anhand eines freigewählten Beispieles den Unterschied zwischen strukturorientierter und funktionsorientierter Modellbildung. Wie können sich beide Vorgehensweisen zur Anwendungsentwicklung ergänzen? Aufgabe 3.11: Kursverwaltung Die Kursverwaltung der Firma „ABC Ltd" soll rechnerunterstützt durchgeführt werden. Führen Sie aufgrund der Angaben aus Aufgabe 2.7 eine funktions- und eine strukturorientierte Analyse unter Verwendung der Kombinationsmethode durch.

3.3

Objektorientierte Modellbildung

Aus objektorientierter Sicht sind die wesentlichen Merkmale eines informationstechnischen Systems seine Objekte, ihre Zustände und die Ereignisse, die Zustandsübergänge von Objekten initiieren. Bei den bisher diskutierten Methoden der Modellbildung werden abhängig vom Zweck des Systems die Schwerpunkte bei seiner Entwicklung auf diese drei Merkmale unterschiedlich gesetzt. Liegt der Schwerpunkt des Systems auf seinen Prozessen und Verfahren, so ist es sinnvoll, das Gesamtsystem in einer Top-down-Vörgehensweise in Funktionen zu zerlegen, die dann auf unterster Ebene beschrieben und implementiert werden. Diese Vörgehensweise haben wir bereits bei der funktionsorientierten Modellbildung kennen gelernt. Beim Entwurf von Datenbanken stehen die vom System verwalteten Informationseinheiten, also die Daten, im Vordergrund. Wie wir zu Beginn dieses Kapitels gesehen haben, eignen sich zur Analyse der Struktur der Informationseinheiten am besten semantische Datenmo-

96

3 Konzeptueller Datenbankentwurf

delle. Für Datenbanken sind von weiterer Bedeutung, jedoch nicht mehr im eigentlichen Zentrum des Interesses die Prozesse, die Daten transformieren und die möglichen Zustände der Informationseinheiten, die durch Integritätsbedingungen vom Datenbanksystem oder den Anwendungsprogrammen geprüft werden sollen. Bei der Entwicklung von Systemen mit zeitkritischen und dynamischen Eigenschaften liegt der Schwerpunkt auf der Analyse der Ereignisse, auf die das System reagieren muss. Diese Eigenschaften spielen in Standarddatenbankanwendungen nur eine untergeordnete Rolle. Die Methoden zur objektorientierten Modellbildung werden nicht ausschließlich zum Datenbankentwurf eingesetzt. Da sie sehr allgemein gehalten sind und eine umfassende Sichtweise auf ein System unterstützen, werden sie für Analyse und Modellbildung unterschiedlicher komplexer Problemstellungen für Softwaresysteme allgemeiner Art eingesetzt. Feststellung 3.3:

Objektorientierte Modellbildung

Bei der objektorientierten Modellbildung werden alle drei Merkmale eines informationstechnischen Systems (Objekte, Zustände und Ereignisse) gleichberechtigt betrachtet und dem zentralen Konzept „Objekt" zugeordnet. Das wesentliche Charakteristikum der objektorientierten Modellbildung sind also die ganzheitliche Vorgehensweise bei der Analyse des Systems und das zentrale Konzept des Objektes, das alle Eigenschaften der Informationseinheiten beinhaltet. Ausgangspunkt einer objektorientierten Analyse sind weiterhin die Informationseinheiten des Systems. Sie werden zunächst in einem statischen Modell zeitpunktbezogen untersucht. Im Anschluss daran werden für alle Informationseinheiten Verhaltensweisen, Zustände und zulässige Operationen analysiert und zu einem integrierten Objektmodell zusammengefasst. Im Allgemeinen bestehen objektorientierte Ansätze zur Modellbildung zumindest aus folgenden Komponenten: •

Objektmodell Zur Analyse der Struktur der Informationseinheiten und Darstellung der ganzheitlichen Sicht auf das Informationssystem.

•

Dynamisches Modell Jeder Objekttyp wird während seiner Existenz in der Datenbank unterschiedliche Zustände durchlaufen. Die Ereignisse, die zu einem Zustandswechsel führen können, werden im dynamischen Modell beschrieben.

•

Funktionales Modell Analog zur funktionsorientierten Modellbildung werden hier Funktionen und Prozesse, Datenflüsse und Verfahren analysiert.

Ausgangspunkt einer objektorientierten Modellbildung bildet eine strukturorientierte Analyse, während der die identifizierten Objekte des Problembereichs und ihre Struktur ermittelt werden. Die Ergebnisse dieser Analyse werden dann in ein Objektmodell eingetragen. Neben den strukturellen Eigenschaften beinhalten Objekte auch eine Menge an zulässigen Operationen und besitzen Beziehungen zu anderen Objekten. Operationen sind die einzige Möglichkeit, auf die Attributwerte von Objekten zuzugreifen. Die wichtigsten Operationen jeder Objektklasse werden unter Verwendung eines funktionalen Modells (z.B. Datenflussdiagramm im Rahmen

3.3 Objektorientierte Modellbildung

97

einer funktionsorientierten Modellbildung) analysiert und in das Objektmodell aufgenommen. Das Verhalten von Objekten ist über Datenwerte oder Beziehungen zu anderen Objekten charakterisiert, die sich im Laufe der Existenz eines Objektes ändern. Tritt ein Ereignis ein, das zu einer Änderung eines solchen Datenwertes oder zur Änderung einer entsprechenden Beziehung führt, so muss eine entsprechende Operation ausgeführt werden und der Zustand des Objektes ändert sich. Diese zeitlichen Aspekte, die auch den Lebenszyklus eines Objektes beschreiben, werden gewöhnlich durch Zustandsdiagramme erfasst, die zu jedem Objekttyp des Objektmodells angefertigt werden. Die Methoden der objektorientierten Modellbildung wurden sehr stark von der Entwicklung objektorientierter Programmiersprachen beeinflusst. In diesem Bereich wurde schon sehr früh erkannt, dass die Analyse der Zustände von Realwelt-Objekten sehr wichtig für das betrachtete System ist. So wurde am Norwegian Computing Center bereits in den 60er Jahren zur ereignisund prozessorientierten Simulation die Sprache SIMULA (Simulation Language) entwickelt, die wohl als älteste objektorientierte Programmiersprache betrachtet werden kann. In den 80er Jahren wurden dann einige objektorientierte Programmiersprachen, wie C++, Smalltalk oder Eiffel vorgestellt. Die ersten Verfahren zur objektorientierten Analyse und Modellbildung gehen auf das Ende der 80er und den Beginn der 90er Jahre zurück. Wie schon in der Einleitung zu Kapitel 3 festgestellt wurde, ist die objektorientierte Modellbildung keinesfalls eine gänzlich neue Entwicklung, sondern stellt eher einen evolutionären Schritt in der Systemanalyse dar und baut auf der semantischen Datenmodellierung, der dynamischen Modellbildung sowie der objektorientierten Programmierung auf. Die objektorientierte Betrachtungsweise eines Systems ermöglicht es, die Funktionalität des Systems durch interagierende Objekte darzustellen und dabei auch die sich ändernden Zustände zu berücksichtigen, die wiederum auf das Eintreten von vordefinierten Ereignissen zurückzuführen sind. Auf diese Weise wird erreicht, dynamische Anforderungen und Bearbeitungsanforderungen aus dem Anforderungsdokument in die Modellbildung zu integrieren. Mit den bisher bekannten Methoden war es nur möglich, Informationsanforderungen und funktionale Anforderungen in einem Modell zu vereinen, um so die Konsistenz und Verständlichkeit des Systems zu erhöhen. Neben der Integration unterschiedlicher Betrachtungsweisen auf ein System bietet die Methode der objektorientierten Modellbildung den zusätzlichen Vorteil, dass in einem umfangreichen Projekt auf der Basis einer gemeinsamen Vorgehensweise gearbeitet werden kann, da das objektorientierte Paradigma auf viele Bereiche Einfluss genommen hat. So kann ausgehend von der Systemanalyse, über die Modellbildung, die Gestaltung der Benutzerschnittstelle, die Implementation oder aber auch für das Datenbankmodell auf objektorientierte Konzepte zugegriffen werden. Im nun folgenden Teil des Unterkapitels wollen wir die wichtigsten objektorientierten Konzepte darstellen, um dann aus der großen Anzahl von bekannten Methoden zur objektorientierten Modellbildung auf eine der neuesten und aussichtsreichsten Methoden näher einzugehen.

3.3.1

Konzepte der Obj ektorientierung

Es soll nicht Aufgabe diese Abschnitts sein, die Konzepte des objektorientierten Paradigmas gänzlich zu beschreiben. Wir wollen hier nur die wichtigsten betrachten, denn für eine detaillierte Übersicht sei dem interessierten Leser die Lektüre weiterführender Literatur empfohlen.

98 3.3.1.1

3 Konzeptueller Datenbankentwurf Objekttyp und Objektklasse

Das Konzept des Objekttyp hat sich aus dem aus Programmiersprachen bekannten Konzept des abstrakten Datentypen (ADT) entwickelt. Wie beim Konzept der Typisierung in semantischen Datenmodellen werden „ähnliche" Objekte der Realität in einem gemeinsamen Objekttyp klassifiziert. Ähnlichkeit bedeutet in diesem Zusammenhang, dass alle Objekte eines Typs durch gleiche Charakteristiken, nämlich die gleiche Struktur, gleichförmiges Verhalten und eine gemeinsame Menge möglicher Zustände beschrieben sind. Ein Objekttyp ist somit ein Muster, das als Vorlage zur Erzeugung neuer Objekte genutzt wird. Die im Typ definierten Attribute bilden die Struktur der Objekte, die dem Objekttyp zugeordneten Operationen implementieren das Verhalten von Objekten. Die Operationen sind dem Typ zugeordnet, werden jedoch von allen Objekten (Exemplaren, Instanzen eines Objekttyps) gemeinsam genutzt, um die Objektdaten (Attributwerte) zu manipulieren. Weitere Kriterien zur Klassifikation von Objekten zu einem gemeinsamen Objekttyp sind gemeinsame Beziehungen zu anderen Objekten oder ihre Verwendung zur Erreichung eines gemeinsamen Ziels. Besonders das zweite Kriterium wird oft in der Literatur vernachlässigt, obwohl es von entscheidender Bedeutung ist. Es kann durchaus sinnvoll sein, dass individuelle Objekte vom Typ „Software", „Gebäude" und „Maschinen", die auf den ersten Blick nur wenig Gemeinsamkeiten aufweisen, in einem Objekttyp enthalten sind, wenn z.B. die Aufgabe besteht, Vermögensgegenstände eines Unternehmens in die Modellbildung mit einzubeziehen. Über den Begriff Objektklasse existieren in der Literatur unterschiedliche Ansichten. Die wohl häufigste Interpretation verwendet die Begriffe Objekttyp und Objektklasse synonym. Eine vorteilhaftere Sichtweise sieht den Objekttyp als Spezifikation von Objekten mit gleicher Struktur und gleichem Verhalten, während die Objektklassse eine Menge von Objekten beschreibt, die gleiche Struktur und gleiches Verhalten aufweisen. 3.3.1.2

Objekte

Bei einem Objekt handelt es sich um eine strukturierte Informationseinheit, die ein bestimmtes Verhalten aufweist und verschiedene Zustände annehmen kann. Jedes Objekt ist eindeutig durch den Objektidentifikator identifizierbar, der während der gesamten Lebenszeit des Objektes nicht geändert wird. Ein Zustand eines Objektes wird durch die Attributwerte und die strukturellen Beziehungen des Objektes zu anderen Objekten definiert. Das dynamische Verhalten eines Objektes ist durch den Wechsel seiner Zustände gegeben, die durch Ereignisse initiiert und durch Operationen ausgeführt werden. 3.3.1.3

Attribute

Die Struktur eines Objektes wird durch die Attribute des entsprechenden Objekttyps bestimmt, seine Attributwerte gemeinsam mit den aktuellen Beziehungen des Objektes definieren seinen Zustand. Die Namen der Attribute sowie ihre Wertebereiche sind für alle Objekte eines Objekttyps identisch. Der Wertebereich eines Attributes kann entweder ein elementarer Datentyp oder selbst wieder ein komplex strukturierter Objekttyp sein. In einem solchen Fall stehen entsprechende Objekte durch einen Assoziationstyp in Verbindung. 3.3.1.4

Operationen und Methoden

Eine Operation ist die einzige Möglichkeit, die Attributwerte von Objekten zu beeinflussen. Das Konzept der Operationen ist ähnlich der Funktionen in prozeduralen Programmierspra-

3.3 Objektorientierte Modellbildung

99

chen. Operationen können jedoch nur mit dem dazugehörigen Objekt ausgeführt werden. Operationen sind Objekttypen zugeordnet und alle Objekte eines Typs nutzen dieselbe Operation. Jedes Objekt kennt seinen Objekttyp, wodurch auch Operationen mit gleichem Namen für unterschiedliche Objekttypen existieren können (siehe Polymorphismus). Die Operation erhält das Objekt, auf das diese angewendet wird, als implizites Argument und kann weitere explizite Argumente erhalten, die die Methode parametrisieren. Der Name der Operation einschließlich der Argumente und evtl. einem Rückgabewert bilden zusammen die Signatur der Operation. Operationen können wie folgt klassifiziert werden: •

Konstruktoren

(erzeugen ein Objekt)

•

Destruktoren

(löschen ein Objekt)

•

Selektoren

(lesen die Informationen eines Objektes)

•

Modifikatoren

(ändern von Werten eines Objektes)

•

Iteratoren

(eine Operation wird auf mehrere Objekte angewendet)

Für Operationen und Methoden gilt dasselbe wie für Objekttypen und Objektklassen. Auch hier sind die Begriffsdefinitionen in der Literatur nicht eindeutig. Meist werden die Begriffe Operation und Methode synonym benutzt. Bei einigen Autoren ist die Methode die Implementierung der Operation (z.B. für eine Operation Drucken können verschiedene Methoden existieren, z.B. Rechnung drucken oder Lieferschein drucken). 3.3.1.5

Nachrichten

Objekte kommunizieren ausschließlich über das Senden von Nachrichten miteinander. Mit anderen Worten, die Operation eines Objektes (Sender) ruft die Operation eines anderen Objektes (Empfänger) auf. Die Nachricht ist dabei aus einem Selektor (der Name der Operation) und einer optionalen Liste mit Argumenten zusammengesetzt. Der Name des Empfängerobjektes ist implizit gegeben, da die Operation nur mit diesem zusammen aufgerufen werden kann. Durch den Erhalt einer Nachricht wird also eine Operation beim Empfängerobjekt ausgeführt. Der Empfänger könnte nun seinerseits anderen Objekten Nachrichten schicken, dem Sender seine Zustandsinformationen melden oder seinen Zustand durch Änderung der Attributwerte verändern. Dieser Umstand ist auch die Ursache dafür, dass Objekte miteinander in Kollaboration stehen, d.h. sie benutzen Dienste anderer Objekte, um ihre Aufgaben zu erfüllen. 3.3.1.6

Vererbung

Das Konzept der Vererbung ist ähnlich den IS-A-Beziehungen aus den semantischen Datenmodellen, wo es in Form von Generalisierung bzw. Spezialisierung Verwendung findet. Für die Objektorientierung ist es von wesentlicher Bedeutung, da es die Erzeugung von Varianten eines Objekttyps ermöglicht, ohne die Struktur des bereits bestehenden Objekttyps zu modifizieren oder redundante Kopien zu erzeugen. Dadurch wird nicht nur der Wartungsaufwand des Systems verringert, sondern auch die Übersichtlichkeit und Verständlichkeit erheblich erhöht. Unter Vererbung versteht man, dass Merkmale (Attribute und Operationen) eines Objekttyps von der Basisklasse (Oberklasse, Superklasse, generische Klasse) an die abgeleitete Klasse (Unterklasse, Subklasse, Spezialisierung) vererbt werden. Sollte es notwendig sein, das Verhalten der Exemplare des abgeleiteten Objekttyps zu verändern, können neue Operationen

100

3 Konzeptueller Datenbankentwurf

implementiert oder bestehende abgeändert werden (siehe Polymorphismus). Eine Besonderheit bildet das Konzept der abstrakten Basisklassen, da sie nur der Vererbung und nicht der Objekterzeugung dienen. Ein Beispiel hierfür wäre der Artikelbestand eines Computerherstellers. Von einer abstrakten Basisklasse Artikel würden die Klassen Monitor, Tastatur, Gehäuse usw. abgeleitet, wobei diese die Attribute (z.B. Preis) und Operationen (z.B. Preisänderung) der Basisklasse erben. Erfolgt die Vererbung wie in diesem Beispiel in mehrere Subklassen, so wird ein Diskriminator verwendet, dessen Wert die Zuordnung von Objekten in die Subklassen bestimmt. In manchen Systemen können Subklassen auch mehrere Oberklassen haben. In diesem Fall spricht man von Mehrfachvererbung und besonderes Augenmerk ist auf die Konflikterkennung und -Vermeidung bei Vererbung gleichlautender Merkmale aus unterschiedlichen Oberklassen zu legen. 3.3.1.7

Polymorphismus

Auch wenn es vielen vielleicht nicht bewusst ist, so sind die meisten Leser mit großer Wahrscheinlichkeit schon mit Polymorphismus in Berührung gekommen. Polymorphie (griechisch: „Auftreten in mehreren Modifikationen") bedeutet, dass ein Konzept mit unterschiedlicher Implementierung existieren kann, dabei aber immer dieselbe Semantik besitzt. Ein Beispiel ist das Zeichen „+", das wohl immer zur Addition benutzt wird, jedoch in unterschiedlichen Implementierungen vorkommen kann (z.B. für Operanden vom Typ integer, real, oder auch Zeichenketten). Polymorphismus kommt in der Objektorientierung besondere Bedeutung zu, da es durch das Vererbungsprinzip möglich ist, Operationen einer Basisklasse über mehrere Ebenen hinweg beizubehalten und erst sehr tief in der Vererbungshierarchie die Implementierung einer Operation zu modifizieren. 3.3.1.8

Objektorientierte Assoziation

Eine Assoziation entspricht einem Beziehungstypen in einem ERM und beschreibt eine Relation zwischen Objekttypen. Da in einem objektorientierten Modell Attribute von komplexen Objekttypen selbst wieder Objekttypen sein können, wird die Assoziation in einem Objektmodell nicht immer explizit dargestellt. Aus Gründen der besseren Aussagekraft und der Flexibilität des Modells ist es jedoch wünschenswert, dass Assoziationen auch als solche modelliert werden. Dies hat den zusätzlichen Vorteil, dass Assoziationen aus beliebiger Richtung betrachtet werden können und eigene Attribute haben können.

3.3.2

Unified Modeling Language (UML)

Im Oktober 1994 begannen die Methodenautoren Grady Booch und Jim Rumbaugh von der Rational Software Corporation ihre bis dahin sehr verbreiteten Methoden zur objektorientierten Modellbildung zusammenzuführen und um bewährte Ansätze aus unterschiedlichsten Bereichen zu erweitern. Durch die Vereinigung von OOD (Object Oriented Design, Booch) und OMT (Object Modeling Technique, Rumbaugh) entstand im Oktober 1995 die erste Version von UML. Zu dieser Zeit wurde das Entwicklerteam um Ivar Jacobson, dem Entwickler von OOSE (Object-Oriented Software Engineering) erweitert. Das Ergebnis der ersten Zusammenarbeit war die Entwicklung der Version UML 0.9 und kurz darauf UML 0.91, in der nun use cases (begründet durch Jacobson) enthalten waren. Da UML in seiner zum Zeitpunkt der Entstehung dieses Buches aktuellen standardisierten Version 1.1 als legitimer Nachfolger der bis dahin sehr populären Methoden der objektorientierten Modellbildung von Booch, Rumbaugh

3.3 Objektorientierte Modellbildung

Abb. 3.14: Entwicklungsgeschichte

101

der Unified Modeling Language UML

und Jacobson angesehen werden kann, wollen wir in diesem Unterkapitel die Konzepte hinter UML 1.1 vorstellen. Die historische Entwicklungsgeschichte der Unified Modeling Language UML ist in Abbildung 3.14 zusammengefasst. Im Zuge der Entwicklung von UML wurden unnötige Unterschiede in der Notation und Terminologie der Methoden der beteiligten Autoren beseitigt und Elemente, die sich in der Praxis nicht bewährt haben, aus den Methoden entfernt. Im Gegenzug wurden Konzepte aus anderen Methoden, die besser geeignet schienen Sachverhalte der Realwelt zu modellieren, in UML integriert. Es versteht sich von selbst, dass UML nicht sämtliche Konzepte aus Methoden, die im Laufe der Jahre entwickelt wurden, berücksichtigen kann. Aber insbesondere die Abwesenheit von Datenflussdiagrammen wird dem Leser auffallen. Diese Tatsache wird kontrovers diskutiert und von den Entwicklern damit erklärt, dass es nicht möglich ist, Konzepte der funktionsorientierten Modellbildung einwandfrei in ein konsistentes objektorientiertes Paradigma zu integrieren. In diesem Buch kann nur ein grober Überblick von UML gegeben werden. Obwohl eine der Zielsetzungen von UML das Auskommen mit nur wenigen graphischen Konstrukten war, besitzen diese eine so umfangreiche Gestaltungsvielfalt, dass ein ganzes Buch notwendig wäre, um sie vollständig zu beschreiben. UML verwendet eine Vielfalt an Modellen, um alle Aspekte eines Systems auf dem gewünschten Abstraktionsniveau zu beschreiben. Dadurch soll erreicht werden, dass das System aus unterschiedlichen Blickwinkeln betrachtet werden kann, um zu einem unfassenden Verständnis des geplanten Systems zu gelangen. Jedes der unterschiedlichen Modelle wird durch

102

3 Konzeptueller Datenbankentwurf

ein Diagramm repräsentiert, das ohne auf andere Informationsquellen zurückgreifen zu müssen selbstständig einen bestimmten Sachverhalt des geplanten Systems beschreibt. Zwischen den einzelnen Modellen bestehen bestimmte Schnittstellen, die zur Konsistenzprüfung genutzt werden. Beispielsweise stellen Operationen im Klassendiagramm Ereignisse des dynamischen Modells dar, für ein Sequenzdiagramm muss auch ein entsprechender Anwendungsfall vorhanden sein und zu einem Zustandsdiagramm gehört auch eine Klasse des Klassendiagramms. Die folgenden Diagramme sind in UML enthalten: •

Klassendiagramm (Objektmodell)

•

Anwendungsfalldiagramm

•

Verhaltensdiagramme (Dynamisches Modell) -Zustandsdiagramm -Aktivitätsdiagramm -Sequenzdiagramm -Kollaborationsdiagramm

•

Implementationsdiagramm -Komponentendiagramm -Entwicklungsdiagramm

In den meisten Diagrammen können zu den unterschiedlichen Konzepten Einschränkungen (constraints) formuliert werden, die in geschweiften Klammern dargestellt werden und entweder in einer Kontrollsprache (OCL, object control language) oder in natürlicher Sprache

Klassendarstellung

Klasse

Angestellter

Attribut:Typ = Init {Einschränkung}

name:String strasse:String

Operation(Parameter):Rückgabewert {Einschränkung}

gehaltserhoehung(summe) {summe>0}

Objektdarstellung

Objekt: Klasse

Attribut:Typ = Init {Einschränkung}

Operation(Parameter):Rückgabewert {Einschränkung}

Abb. 3.15: Klassen und Objekte in UML

o1: Angestellter name = Müller strasse = Musterstr. 1

3.3 Objektorientierte Modellbildung

103

formuliert werden. In Abbildung 3.15 ist die Einschränkung {summe > 0} einer Operation zugewiesen worden und bedeutet in diesem Kontext, dass der Parameter der Operation einen Wert größer als 0 haben muss. Bei der Beschreibung der unterschiedlichen Modelle werden wir auf die Formulierung von Einschränkungen zurückkommen, um zu verdeutlichen, welch hohen semantischen Informationsgehalt dieses Konstrukt bereitstellt. 3.3.2.1

Klassendiagramm

Im Klassendiagramm (Objektmodell) werden alle Objekte erfasst, die in dem System, das es zu modellieren gilt, von Bedeutung sind. Außer der Darstellung der eigentlichen Objekte wird auch deren Struktur abgebildet, d.h. ihre Attribute und Operationen sowie die Beziehungen zu anderen Objekten. Klassen und Objekte werden in UML als Rechtecke dargestellt, die in drei Abschnitte eingeteilt werden können (vgl. Abbildung 3.15). Der erste Abschnitt beschreibt den Namen der Klasse bzw. des Objektes und zusätzliche Informationen, auf die wir in diesem Buch aber nicht weiter eingehen wollen. Der zweite Abschnitt enthält die Attribute der Klasse, die mit einem Typ, einem Initialisierungswert und einer Einschränkung versehen werden können. Der dritte Abschnitt ist für die Operationen vorgesehen, die Parameter übergeben bekommen, einen Rückgabewert besitzen können und ebenfalls mit Einschränkungen versehen werden können. Die Sichtbarkeit von Attributen und Operationen erfolgt in Anlehnung an die Programmiersprache C++ und kann als public, protected und private dargestellt werden. Eine Assoziation stellt, wie schon im Abschnitt Konzepte beschrieben, Beziehungen zwischen Objekttypen dar. Binäre Assoziationen werden als direkte Verbindung zwischen den Klassen dargestellt. Assoziationen sind mit einer Richtung versehen, wobei die Richtung durch ein kleines Dreieck angezeigt wird. Assoziationen können analog zu Klassen Attribute und Operationen besitzen, die in einem Klassensymbol (Assoziationsklasse) durch eine gestrichelte Linie mit der Assoziationslinie verbunden sind. Ternäre Assoziationen und solche mit höherer Ordnung werden in UML nicht durch direkte Verbindungen der beteiligten Klassen, sondern durch eine Raute dargestellt. In diesem Fall gibt es keine Unterschiede zu der in diesem Buch für die Darstellung in Entity-Relationship-Diagrammen gewählten Notation. Die Multiplizität (Kardinalität) einer Assoziation legt fest, wie viele Exemplare einer Klasse mit einem Exemplar der in Beziehung stehenden Klasse verknüpft sein dürfen. Die Festlegung einer zu geringen Multiplizität würde die Flexibilität einschränken, eine Überschätzung der Multiplizität würde jedoch den Aufwand für Programmierung und Verwaltung in der Implementierung erhöhen. Die Multiplizität wird in einzelnen Werten oder als Intervall angegeben und kann mehrere durch Kommata getrennte Bereiche umfassen. Ein * steht dabei für 0 oder mehrere. Objekte können an Assoziationen unter Ausübung unterschiedlicher Rollen beteiligt sein. Dies wird durch Aufnahme eines Rollennamens an die die Assoziation darstellende Kante im Diagramm gekennzeichnet. Durch die Angabe einer Qualifikation innerhalb einer Assoziation wird ein Attribut ausgezeichnet, das in (1:M)- oder (N:M)-Assoziationen eine besondere Bedeutung einnimmt. Eine qualifizierte Assoziation ist ähnlich einer ternären Assoziation und primär dazu gedacht, die semantische Aussagekraft des Modells zu verbessern, ohne einen zusätzlichen Objekttyp in die Darstellung aufnehmen zu müssen. Eine Qualifikationsangabe wird als kleines Rechteck neben der Klasse, die sie qualifiziert, dargestellt.

104

3 Konzeptueller Datenbankentwurf

UML kennt die Aggregation als einen Spezialfall der Assoziation. Eine Aggregation repräsentiert die Zusammensetzung eines Objektes aus Einzelteilen. Sie sollte immer dann der „normalen" Assoziation vorgezogen werden, wenn eine enge Verbindung (oder auch eine Existenzabhängigkeit) zwischen beteiligten Objekttypen besteht. Graphisch wird die Aggregation durch eine Raute dargestellt. Die Raute ist ausgefüllt, wenn es sich um eine Wert-Aggregation handelt. Bei Referenz-Aggregationen wird die Raute hingegen nicht ausgefüllt. Einschränkungen haben auch im Kontext der Assoziation eine große Bedeutung. Einschränkungen können verwendet werden, um eine Assoziation mit Bedingungen oder Eigenschaften zu versehen. In UML existieren aber auch eine Reihe vordefinierter Einschränkungen für Assoziationen. Eine davon ist die Einschränkung {ordered}, die explizite Reihenfolge der Exemplare einer Assoziation hervorhebt und daher nur bei einer Multiplizität größer als 1 auftreten kann. Im folgenden Beispiel wollen wir die unterschiedlichen Ausprägungsformen der Assoziation in UML darstellen.

Beispiel 3.9:

Formen der Assoziationen in UML

Wir beginnen mit dem einfachsten Fall einer binären Assoziation. In Abbildung 3.16(a) zeigen wir die binäre Assoziation „beschäftigt", der die Attribute „Gehalt" und „Einstellungsdatum" zugewiesen sind. Des Weiteren ist die Semantik dargestellt, dass eine Abteilung mehrere Mitarbeiter beschäftigen kann, aber für jede Abteilung zumindest ein Mitarbeiter vorhanden sein muss. Ein Mitarbeiter darf ausschließlich in einer Abteilung beschäftigt sein.

Abb. 3.16: Assoziation

in UML

3.3 Objektorientierte Modellbildung

105

Eine Einschränkung vom Typ {or} ist in Abbildung 3.16(b) dargestellt. Sie legt fest, dass ein Exemplar der Klasse „Artikel" zu einem Zeitpunkt nur mit einer der beiden Klassen „Abteilung" oder „Lieferant" verbunden sein kann. Dieses Beispiel repräsentiert die Semantik, dass es sich bei einem Artikel entweder um eine Eigenfertigung oder um einen Fremdbezug handelt. Eine qualifizierte Assoziation ist in Abbildung 3.16(c) dargestellt. Durch die Qualifikation „Lieferant" kann im Zusammenhang mit einem bestimmten Produkt das Teil eines bestimmten Lieferanten identifiziert werden. Diese Assoziation stellt in etwa den gleichen Informationsgehalt dar, wie durch eine ternäre Beziehung zwischen Objekttypen „Produkt", „Lieferant" und „Teil" ausgedrückt werden könnte. Allerdings handelt es sich bei dem Lieferanten in Abbildung 3.16(c) nicht um einen Objekttyp, sondern lediglich um ein Attribut. Eine rekursive Assoziation wird in Abbildung 3.16(d) gezeigt. Objekte vom Typ „Mitarbeiter" werden durch die Rollen „Vorgesetzter" und „Angestellter" unterschieden. In Abbildung 3.16(e) sind zwei Aggregationen dargestellt, die bedeuten, dass ein Unternehmen aus Abteilungen zusammengesetzt ist, die wiederum aus zugeordneten Mitarbeitern bestehen. Das Beispiel zeigt auch die unterschiedliche Darstellung von Wert-Aggregation (ausgefüllte Raute) und Referenz-Aggregation (Raute ist ausgefüllt). Eine Vererbungshierarchie wird in UML durch einen Pfeil von der Unterklasse zur Oberklasse dargestellt. Dabei erbt die Unterklasse alle Eigenschaften der Oberklasse. Zwei unterschiedliche Notationen sind zulässig (siehe Abbildung 3.17). Hinsichtlich der Spezialisierungen können folgende vordefinierte Einschränkungen formuliert werden: •

overlapping (Exemplare können in mehreren Unterklassen sein)

•

disjoint (ein Exemplar kann zur selben Zeit nur in einer Unterklasse sein)

•

complete (es bestehen keine weiteren Unterklassen)

•

incomplete (es sind noch weitere Unterklassen vorhanden)

Die unterschiedliche Darstellung der Generalisierung und die Verwendung von Einschränkungen wird im nachfolgenden Beispiel erläutert.

Abb. 3.17: Generalisierung

in UML

106

3 Konzeptueller Datenbankentwurf

Beispiel 3.10:

Generalisierung in UML

In Abbildung 3.17 zeigen wir die unterschiedlichen Darstellungsformen für Generalisierungen. Von der Klasse „Person" werden die Klassen „Kunde", „Lieferant" und „Angestellter" abgeleitet. In Abbildung 3.17(b) sind die Einschränkungen {overlapping, incomplete} dargestellt. Durch {overlapping} wird ausgedrückt, dass ein Exemplar der Klasse „Person" durchaus auch gleichzeitig in der Unterklasse „Angestellter" und „Kunde" sein kann. Die Einschränkung {incomplete} stellt klar, dass es auch Exemplare der Klasse „Person" geben kann, die in keiner der drei Spezialisierungen enthalten sind. 3.3.2.2

Anwendungsfalldiagramm

Ein Anwendungsfalldiagramm (use case diagram) bildet die Beziehungen der Akteure außerhalb des Systems zu den verschiedenen Anwendungsfällen (use cases) innerhalb der Systemgrenzen ab. Welche Anwendungsfälle modelliert werden, hängt davon ab, auf welche Vorgänge das System reagieren soll. Alle Anwendungsfälle gemeinsam beschreiben das Verhalten des Gesamtsystems. Das Anwendungsfalldiagramm repräsentiert somit die externe Funktionalität eines Systems oder einer Klasse, wie sie sich dem Akteur darstellt und ist als geschlossene Transaktion von Nachrichten zwischen Akteuren und Anwendungsfallen definiert. Ein physisches Objekt der Realität kann dabei mehrere Rollen übernehmen und deshalb auch als verschiedene Akteure modelliert werden. Graphisch werden Anwendungsfalldiagramme wie folgt dagestellt: „Strichmännchen" symbolisieren externe Akteure, die Systemgrenzen werden durch abgerundete Rechtecke und die Anwendungsfälle durch Ellipsen dargestellt. Die Verbindungen zwischen den Akteuren und den Anwendungsfallen beschreiben die Kommunikation des Anwendungssystems mit seiner Umwelt. Akteure können zu Anwendungsfällen und zu anderen Akteuren eine Beziehung aufweisen. Die Assoziation zwischen einem Anwendungsfall und einem Akteur kann ebenfalls eine Multiplizitätsangabe aufweisen. Assoziationen zwischen Akteuren (bspw. eine Generalisierung) befinden sich zwar außerhalb des Systems, können jedoch das Verständnis des Modells erheblich erhöhen. Für die Anwendungsfälle untereinander werden drei Beziehungstypen unterschieden, nämlich include für die Darstellung hierarchischer Verknüpfungen zwischen Anwendungsfällen und extends für eine Erweiterungsbeziehung zwischen Anwendungsfällen. Eine Erweiterungsbeziehung kann auch als eine optionale include-Beziehung betrachtet werden. Des Weiteren besteht die Möglichkeit einer Generalisierung zwischen Anwendungsfällen. Anwendungsfalldiagramme können bis zum gewünschten Detaillierungsgrad hierarchisch verschachtelt und dann durch Interaktionsdiagramme beschrieben werden. Zudem kann jeder Anwendungsfall durch ein oder mehrere Szenarios genauer dargestellt werden. Diese Szenarios bilden dann später die Grundlage für Sequenzdiagramme. Beispiel 3.11:

Anwendungsfalldiagramm in UML

In Abbildung 3.18 ist ein Wareneinkauf als Anwendungsfalldiagramm modelliert. Am Wareneinkauf sind die externen Akteure „Beschaffung", die „Warenannahme" und ein „Lieferant" beteiligt. Des Weiteren sind die Anwendungsfälle „Warenlieferung", „Qualitätskontrolle" und „Bestellung" dargestellt. Die Assoziation des Lieferanten zeigt an, dass ein Lieferant an mehreren Wahrenlieferungen beteiligt sein kann. Der Anwendungsfall

3.3 Objektorientierte Modellbildung

107

Abb. 3.18: Anwendungsfalldiagramm in UML

„Bestellung" ist weiter in seine Bestandteile strukturiert und nutzt über eine includeBeziehung die Anwendungsfälle „Lagerabgleich" und „Produkte bestellen", d.h. diese beiden Anwendungsfälle werden ebenfalls ausgelöst, sobald ein Anwendungsfall „Bestellung" eintritt. Der Anwendungsfall „Lieferantenauswahl" ist als eine Erweiterung des Anwendungsfalles „Bestellung" dargestellt. Dies bedeutet, dass für Produkte, die bisher noch von keinem Lieferanten bezogen wurden, der Anwendungsfall „Lieferantenauswahl" erfolgen muss. Das statische Modell bildet die Struktur des Systems ab. Die Veränderungen, die das System und dessen Objekte mit der Zeit erfahren, werden durch das dynamische Modell erfasst. Ein Objekt kann im Laufe seiner Existenz in der Datenbank eine ganze Reihe unterschiedlicher Zustände „erleben", die jeweils durch seine Attributwerte und den zu einem bestimmten Zeitpunkt existenten Beziehungen des Objektes zu anderen Objekten charakterisiert sind. Es ist jedoch eine sehr schwierige Aufgabe, diese zeitlichen Aspekte des Systems zu analysieren. Durch ein statisches Modell wird eine zeitpunktbezogene Momentaufnahme ausgeführt und dabei werden Objekttypen, die zu dem Zeitpunkt Relevanz besitzen, analysiert. Im dynamischen Modell wird untersucht, ob der Objekttyp einen wesentlichen dynamischen Aspekt für

108

3 Konzeptueller Datenbankentwurf

das Gesamtsystem aufweist, und welche Zustände er mit der Zeit durchläuft. Zunächst wollen wir die wichtigsten Begriffe der dynamische Modellbildung definieren, um zu einem einheitlichen Verständnis zu gelangen und dann später auf die unterschiedlichen Diagrammtypen eingehen zu können. Ein Ereignis ist ein zeitpunktbezogener Vorfall, der die Attribute und somit den Zustand eines Objektes verändern kann. Ereignisse können zeitgleich auftreten. Ereignisse, die in einem Kausalzusammenhang stehen, müssen jedoch eine logische Reihenfolge besitzen. Ein Kausalzusammenhang existiert immer dann, wenn sich Ereignisse aufeinander auswirken. Ein Beispiel dafür ist eine Bestellung durch einen Kunden: Sie könnte nicht bearbeitet werden, bevor der Kunde die Bestellung aufgegeben hat. Ereignisse ohne Kausalzusammenhang bezeichnet man als parallele Ereignisse. Der Zustand eines Objektes wird durch seine Attributwerte und seine Beziehungen zu anderen Objekten zu einem bestimmten Zeitpunkt definiert. Nicht jede Änderung eines Wertes führt auch zu einer Änderung eines Zustandes. Es können auch Wertemengen zusammengefasst und einem Zustand zugeordnet werden. Ein Zustand besitzt im Gegensatz zum Ereignis eine Zeitspanne, in der er besteht. Die Menge der möglichen Zustände eines Objektes beschreibt sein Verhalten. Ein Szenario stellt eine Aneinanderreihung von Ereignissen dar, die für eine bestimmte Operation eines Systems benötigt werden. Bei der Erzeugung von Szenarios wird im Allgemeinen der Ablauf einer Operation eines existierenden Systems beobachtet oder die Ausführung für ein geplantes System simuliert. Ereignisse und Zustände werden in den meisten Fällen mithilfe von Zustandsdiagrammen zu einander in Relation gebracht. D.h. zu jedem Objekttyp, der ein für das System wichtiges Verhalten aufweist, wird im Zuge einer objektorientierten Modellbildung ein Zustandsdiagramm erzeugt. Auf diese Weise wird sichtbar, auf welche Ereignisse Objekte dieses Typs reagieren müssen, und welche Zustände sie annehmen können. In UML ist das dynamische Modell aber nicht auf die Anwendung von Zustandsdiagrammen beschränkt. Es existieren noch weitere Diagramme, die dynamische Zusammenhänge des Systems abbilden. Insbesondere das Sequenz- und das Kollaborationsdiagramm weisen überwiegend dynamische Aspekte auf. Sequenz- und Kollaborationsdiagramm bilden jeweils ähnliche Sachverhalte ab, setzen dabei jedoch unterschiedliche Schwerpunkte. Während ein Sequenzdiagramm den zeitlichen Verlauf des Nachrichtenaustauschs zwischen den Objekten in den Vordergrund stellt, bildet ein Kollaborationsdiagramm die Beziehung zwischen den Objekttypen ab. Nachfolgend soll auf beide Diagrammarten näher eingegangen werden. 3.3.2.3

Sequenzdiagramm

Das Sequenzdiagramm (sequence diagram) leitet sich von Szenarios ab und stellt eine Weiterentwicklung so genannter Ereignispfad-Diagramme dar, die in OMT1 Verwendung fanden. Die Ereignisfolge, die für eine bestimmte Operation des Systems durchlaufen wird, kann mit Hilfe von Sequenzdiagrammen sehr detailliert wiedergegeben werden. 1 OMT ist eine Vorgängermethode von UML, deren wesentliche Komponenten in UML eingeflossen sind. Siehe dazu auch Abbildung 3.14.

3.3 Objektorientierte Modellbildung

109

Graphisch werden die Objekttypen, die von einer Operation des Systems betroffen sind, als senkrechte Linien, und die Nachrichten, die zwischen den Objekten ausgetauscht werden, als Pfeile zwischen diesen dargestellt. Der zeitliche Verlauf nimmt im Diagramm nach unten zu. Zusätzlich kann auch eine metrische Zeitachse angegeben werden, falls diese z.B. für Angabe von Realzeiten nötig sein sollte. Die Achsen des Sequenzdiagramms sind austauschbar, d.h. die zeitliche Komponente kann auch horizontal von links nach rechts aufgetragen und die Objekte können vertikal angeordnet werden. Labels wie Zeitmarken oder Beschreibungen können an der Seite des Sequenzdiagramms oder in der Nähe der Übergänge angegeben werden.

Beispiel 3.12:

Sequenzdiagramm in UML

In Abbildung 3.19 ist ein Szenario eines Ausschnittes aus einem typischen Bestellvorgang dargestellt. Folgende Semantik wird repräsentiert: Zuerst werden für die einzelnen Bestellpositionen die Artikel und deren Anzahl ermittelt. Danach wird geprüft, ob der gewünschte Artikel in der entsprechenden Anzahl im Lager verfügbar ist. Ist dies der Fall, können die Artikel kommissioniert werden. Ansonsten müssen diese bei einem Lieferanten bestellt werden.

3.3.2.4

Kollaborationsdiagramm

Bei einem Kollaborationsdiagramm (collaboration diagram) werden in erster Linie die Beziehungen der einzelnen Objekte betrachtet, auf eine separate Dimension für die Zeit wird verzichtet. Ein Kollaborationsdiagramm enthält folgende zwei Aspekte: •

strukturelle Beschreibung (die Objekte und deren Beziehungen zueinander) und

•

dynamische Beschreibung (der notwendige Nachrichtenaustausch, um eine Operation auszuführen).

Abb. 3.19: Sequenzdiagramm in UML

110

3 Konzeptueller Datenbankentwurf

Die Objekte und ihre Beziehungen zueinander werden als Kollaboration bezeichnet und der mit ihr in Verbindung stehende Nachrichtenaustausch als Interaktion. Um verschiedene Interaktionen zu modellieren, müssen alle Nachrichten einer Kollaboration analysiert werden. Kollaborationsdiagrmme haben den großen Vorteil, dass mit ihrer Hilfe die Implementierung einer Operation veranschaulicht werden kann. Die Namen der Objekte repräsentieren ihre Rollen innerhalb der Kollaboration und zu jeder dieser Rollen muss ein Objekt existieren, das die Operation unterstützt. Die Verbindungen der Objekte können verschiedene Ursachen haben. Im klassischen Fall existiert eine Assoziation oder Aggregation im statischen Modell. Alle Objekte, die direkt oder indirekt an der Ausführung der Operation beteiligt sind, werden im Kollaborationsdiagramm dargestellt und können unter anderem mit folgenden „Marken" versehen werden: •

{new}

(Objekt wird durch die Operation erzeugt)

•

{destroyed}

(Objekt wird durch die Operation zerstört)

•

{transient}

(Objekt existiert nur während dieser Operation)

Werden alle Kollaborationen einer Klasse zusammengefasst, so erhält man den Bezugsrahmen zur Implementierung der Klasse. Interaktionen können auch durch die zuvor beschriebenen Sequenzdiagramme dargestellt werden. Kollaborationsdiagramme stellen jedoch ein mächtigeres Konzept dar, da sie neben dem involvierten Nachrichtenaustausch auch die Beziehungen zwischen den Objekttypen explizit beinhalten. Die Nachrichten in Kollaborationsdiagrammen können unterschiedlich dargestellt werden. Ein kleiner Pfeil zeigt dabei die Richtung der Nachricht an. Die Verarbeitungsart der Nachricht

Abb. 3.20: Kollaborationsdiagramm

in UML

3.3 Objektorientierte Modellbildung

111

wird durch die verschiedenen Pfeilspitzen (wie in Abbildung 3.20 dargestellt) wiedergegeben. Der Aufbau der Nachricht setzt sich folgendermaßen zusammen: Vorgänger Bedingung Sequenzausdruck Rückgabe :=Nachricht( Argumente) Vorgänger, Bedingung und Sequenzausdruck legen gemeinsam fest, wann eine Nachricht gesendet wird. Bei Vorgänger handelt es sich um eine Liste von Sequenznummern, die vorgekommen sein müssen, bevor die Nachricht aktiviert werden kann. Bedingung stellt einen logischen Ausdruck dar, der erfüllt sein muss und Sequenzausdruck stellt die Reihenfolge der Nachrichten her. Beispielsweise erfolgt die Nachricht 1.5.6 im Anschluss an die Nachricht 1.5.5 innerhalb von 1.5. Die Verwendung von Kollaborationsdiagrammen soll anhand eines Beispiels veranschaulicht werden. Beispiel 3.13:

Kollaborationsdiagramm in UML

Im Kollaborationsdiagramm in Abbildung 3.20 ist dargestellt, wie die Operation „Abgleichen des Lagers" nach Aufnahme der Bestellung vollzogen wird. Zunächst wird aus der Bestellung jede einzelne Position extrahiert, um den bestellten Artikel und dessen Anzahl zu ermitteln. Dabei wird die Abarbeitungsreihenfolge der Nachrichten 1.1.1 a+b nicht festgelegt, da es für die Operation ohne Belang ist, welche dieser Nachrichten zuerst gesendet wird. Anschließend wird geprüft, ob der Artikel in der gewünschten Anzahl im Lager verfügbar ist (Nachricht 1.1.2). Die Verfügbarkeit wird vom Lager mit der Zahl 1 beantwortet. Für den positiven Fall ist die Bedingung [av == 1] der Nachricht 1.1.3 erfüllt und die Artikel können reserviert bzw. kommissioniert werden. Im negativen Fall ist die Antwort des Lagers — 1. Für diesen Fall wird aus der Menge der Lieferanten einer ausgewählt (Nachricht 1.1.4), der diesen Artikel in seinem Sortiment führt, und der Artikel wird bei dem gewählten Lieferanten bestellt (Nachricht 1.1.5). 3.3.2.5

Zustandsdiagramm

Wir haben bereits festgestellt, dass alle Objekte eines Objekttyps dasselbe Verhalten aufweisen. In UML wird das mögliche Verhalten von Objekten mit Zustandsdiagrammen (state chart diagrams) illustriert, die einzelnen Objekttypen zugeordnet sind. Es ist nicht notwendig, für alle Objekttypen des Systems ein Zustandsdiagramm zu entwickeln. Von Bedeutung sind ausschließlich Typen, die ein wichtiges Verhalten in Bezug auf das System aufweisen. Bei einem Zustandsdiagramm handelt es sich um einen gerichteten Graphen, dessen Knoten die potentiellen Zustände eines Objektes während seiner Lebenszeit abbilden. Die Transitionen (Zustandsübergänge) werden durch Kanten dargestellt. Die Objekte bewegen sich nun unabhängig voneinander durch diesen Graphen, je nachdem welche Ereignisfolge eintritt. Folglich ist außer dem Ereignis und einer möglichen Bedingung, auch der aktuelle Zustand eines Objektes maßgebend für den Folgezustand. Oft ist der Zustand eines Objektes mit ausführbaren Aktionen verbunden. Aktionen sind immer atomar und die ihnen vorausgehenden Ereignisse werden in einem separaten Abschnitt des Zustandes im Zustandsdiagramm dargestellt. Attribute für einen Zustand können ebenfalls in einem Abschnitt hinterlegt werden. Der Aufbau der Abschnitte ist analog zu dem von Klassen und Objekten. Die Angabe der einzelnen Abschnitte ist optional. Wird der Name eines Zustandes ausgelassen, so handelt es sich um einen anonymen Zustand.

112

3 Konzeptueller Datenbankentwurf

Zwei besondere Zustände in Zustandsdiagrammen sind der Start- und Endzustand. Der Startzustand wird als ausgefüllter Kreis dargestellt, dem kein Zustand vorausgehen kann. Der Endzustand erhält zusätzlich noch einen weiteren Kreis. Es können durchaus auch mehrere Endzustände in einem Zustandsdiagramm auftreten. Ereignisse und Aktionen werden wie folgt dargestellt: Ereignis(Argumente) [Bedingung] / Aktion Innerhalb eines Zustandes existieren drei vordefinierte Ereignisse, die mit Aktionen belegt werden können: •

do / Aktion (wird wiederholt ausgeführt, solange der Zustand besteht)

•

entry / Aktion (wird ausgeführt, wenn das Objekt in diesen Zustand eintritt)

•

exit / Aktion (wird beim Verlassen des Zustandes ausgeführt)

Die Verwendung von Zustandsdiagrammen soll nun auch an einem Beispiel veranschaulicht werden. Beispiel 3.14:

Zustandsdiagramm in UML

Im Zustandsdiagramm in Abbildung 3.21 sind die verschiedenen Zustände abgebildet, die eine Bestellung in einem bestimmten Problembereich durchlaufen kann. Folgende Semantik wird dargestellt: Nachdem der Artikelbestand geprüft wurde, werden die Artikel bestellt, deren Bestand nicht ausreicht, die Nachfrage zu decken. Sobald das Ereignis „Bestellung vollständig" eintritt, befindet sich die Bestellung im Zustand „Terminüber-

Abb. 3.21: Zustandsdiagramm

in UML

3.4 Weitere Formen der Modellbildung

113

wachung". Werden die Artikel geliefert, überführt das die Bestellung in den Zustand „Qualitätsprüfung". Wird der Termin jedoch nicht eingehalten oder weisen die gelieferten Artikel Qualitätsmängel auf, ändert sich der Zustand der Bestellung in „Reklamation". Sollte eine Nachlieferung der Artikel möglich sein, so wird die Bestellung erneut in den Zustand „Terminüberwachung" transformiert. Andernfalls terminiert das Objekt Bestellung (wird aus der Datenbank gelöscht). Diese Situation tritt auch ein, wenn nach Zustand „Qualitätsprüfung" eine zufrieden stellende Qualität festgestellt werden konnte. Einige abschließende Aussagen über die objektorientierte Modellbildung sind noch angebracht. Objektorientierte Analyse und Entwurf sind „allgemeine" Methoden der Systemplanung und -entwicklung und werden deshalb für viele unterschiedliche Fragestellungen beim Entwurf von Software eingesetzt. Steht die Entwicklung einer Datenbankanwendung im Vordergrund, so stellen die Informationsanforderungen aus dem Objektmodell die wichtigste Klasse an Informationen dar, die den systemunabhängigen Teil des Entwurfs einer Datenbank beeinflussen. Ein Objektmodell kann jedoch nur konfliktfrei und vollständig sein, wenn die Designer eine Vorstellung von der zu entwickelnden Anwendung besitzen und neben den statischen Aspekten die beteiligten Akteure aus den Anwendungsfalldiagrammen, die Analyse der Ereignisse aus Sequenzdiagrammen, die Interaktionen zwischen Objekten aus den Kollaborationsdiagrammen und das Verhalten von Objekten aus den Zustandsdiagrammen in ihre Entwurfsentscheidungen einbeziehen. Anforderungen, die das zeitabhängige Verhalten der Datenbank betreffen, besitzen beim Entwurf des statischen Datenbankschemas eine untergeordnete Bedeutung. Sie sind jedoch für die Erstellung von Programmen, die auf die Datenbank zugreifen, von essentieller Wichtigkeit, da sie die Reihenfolge von Interaktionen und damit den zeitlichen Ablauf von Operationen festlegen.

3.4

Weitere Formen der Modellbildung

Der Aufbau der vorherigen Abschnitte wurde nicht zufällig gewählt, sondern reflektiert die chronologische Reihenfolge, in der sich Wissenschaftler und Unternehmen gleichermaßen mit Methoden zur Analyse von betrieblichen Informationssystem beschäftigt haben. Im folgenden Unterkapitel wollen wir die Grundlagen und die wesentlichen Ideen der geschäftsprozessorientierten Modellbildung vorstellen. Das Unterkapitel wird mit einer kurzen Darstellung zweier konkreter Ansätze, die geschäftsprozessorientierte Modellbildung unterstützen, abgeschlossen. Ähnlich wie auch schon bei der objektorientierten Modellbildung ist die Zielrichtung der in diesem Unterkapitel dargestellten Methoden nicht mehr ausschließlich die Unterstützung des Datenbankentwurfsprozesses. Vielmehr sind die Methoden sehr allgemein gehalten, unterstützen unterschiedliche Sichtweisen auf Anwendungen und können für die Repräsentation und Analyse komplexer Systeme in unterschiedlichsten Bereichen zum Einsatz kommen.

3.4.1

Geschäftsprozessorientierte Modellbildung

Für die permanente Entwicklung neuer Methoden ist außer dem technischen Fortschritt auch der immer stärker werdende Wettbewerb, dem sich die Unternehmen ausgesetzt sehen, verantwortlich. Es ist offensichtlich, dass im Zuge der Globalisierung der Wirtschaft die Konkurrenz sehr groß geworden ist, so dass sich ein Unternehmen sehr schnell an die sich ändernden

114

3 Konzeptueller Datenbankentwurf

Märkte anpassen muss, um überlebensfähig zu bleiben. Aus diesem Umstand heraus haben sich in den letzten Jahren eine Vielzahl von Reorganisationsansätzen entwickelt, die unter dem Oberbegriff „Business Process Reengineering" (BPR) subsumiert werden. BPR steht für eine Erneuerung der Unternehmensstruktur, mehr Flexibilität in den betrieblichen Abläufen und eine Fokussierung auf die wichtigsten Geschäftsprozesse, deren Optimierung und schnelle Adjustierung auf geänderte Rahmenbedingung notwendig geworden ist. Der Wunsch nach mehr Flexibilität erfordert eine kontinuierliche und umfassende Modellbildung, die nicht ein statisches System betrachtet, sondern von einem ganzheitlichen Unternehmensmodell mit sich ständig verändernden Prozessen ausgeht. Die geschäftsprozessorientierte Modellbildung verfolgt einen primär betriebswirtschaftlichen Ansatz, indem sie sich von vorwiegend informationstechnischen Elementen löst und die Aufgaben, Ereignisse und Organisationseinheiten des Unternehmens im Hinblick auf eine mögliche Neugestaltung der existierenden Geschäftsprozesse analysiert. Bereits die objektorientierte Modellbildung unterstützt einen ganzheitlichen Modellbegriff, indem sie zumindest Konzepte zur statischen, funktionalen und dynamischen Analyse beinhaltet. Ähnlich den davor diskutierten klassischen Ansätzen geht sie jedoch weiterhin von den zu modellierenden Funktionsbereichen im Unternehmen aus und versucht durch Analyse dieser drei Aspekte ein Realweltmodell zu entwickeln. Bei der geschäftsprozessorientierten Modellbildung ist dies nun anders. Feststellung 3.4:

Geschäftsprozessorientierte Modellbildung

Die geschäftsprozessorientierte Modellbildung geht von den existierenden Geschäftsprozessen aus und versucht quer durch alle betrieblichen Funktionsbereiche alle relevanten Aspekte von aufeinander folgenden Aktivitäten (Geschäftsvorgängen) darzustellen. Des Weiteren berücksichtigt sie die Aufgabenträger, die in die Ausführung der Geschäftsprozesse involviert sind und setzt ihren Schwerpunkt auf die Erneuerung (Reorganisation) bestehender Prozesse. In seiner allgemeinsten Form besteht ein Geschäftsprozess aus einer Folge von aufeinander folgenden und logisch zusammengehörenden Aktivitäten, die innerhalb der Wertschöpfungskette eines Unternehmens verschiedene Aufgaben realisieren. Die Wertschöpfungskette eines Unternehmens bildet die direkt an der Wertschöpfung2 beteiligten Funktionen ab und könnte durchaus selbst als ein Geschäftsprozess auf höchster betrieblicher Ebene dargestellt werden. In der Literatur gibt es unterschiedliche Definitionen des Begriffs Geschäftsprozess. Als charakteristische Merkmale von Geschäftsprozessen werden dabei insbesondere genannt [FeSi98]: (a) Sammlung von Aktivitäten, die anhand gemeinsamer Merkmale abgrenzbar sind, (b) ereignisgesteuerter Ablauf von Aktivitäten, (c) Übernahme von Inputs und Erzeugung von Outputs als Beitrag zur Wertschöpfung, (d) Zuordnung und Nutzung von Ressourcen. Wichtig erscheint dabei noch die Motivation für eine geschäftsorientierte Modellbildung - nämlich die Analyse bestehender Strukturen hinsichtlich einer möglichen Reorganisation. Wie aus den bisherigen Ausführungen zu schließen ist, ist es nicht möglich, die Geschäftsprozesse eines Unternehmens mit allen vorhandenen Aspekten in einem einzigen Modell adäquat zu repräsentieren und zu analysieren. Deshalb verwenden die meisten Verfahren, die die 2 Als Wertschöpfung versteht man die Bewertung aller vom Unternehmen erbrachten Leistungen abzüglich aller extem bezogener Vorleistungen.

3.4 Weitere Formen der Modellbildung

115

geschäftsprozessorientierte Modellbildung unterstützen, unterschiedliche Sichten auf das Gesamtsystem, um so die Komplexität zu reduzieren. Zwei dieser Ansätze wollen wir im Folgenden kurz vorstellen. Für ein genaueres Studium wird auf die jeweiligen Originalarbeiten verwiesen. 3.4.1.1

Architektur integrierter Informationssysteme

Ziel der Architektur integrierter Informationssysteme (ARIS) [Sche98a], [Sche98b] ist es, einen Orientierungsrahmen für die Entwicklung betrieblicher Informationssysteme zur Verfügung zu stellen. Die ARIS-Architektur sieht eine ganzheitliche Beschreibung von Unternehmensprozessen vor und liefert dafür verschiedene Zerlegungssichten, die jede wiederum in weitere Beschreibungsebenen unterteilt wird (siehe Abbildung 3.22). Zerlegungssichten Die unterschiedlichen Sichten der ARIS-Architektur analysieren verschiedene Aspekte des Gesamtsystems. Die Organisationssicht erfasst organisatorische Einheiten und Aufgabenträger des Unternehmens und stellt Struktur sowie Beziehungen zwischen Aufgabenträgern dar. Die zu erfüllenden Aufgaben sowie ihre hierarchische Anordnung werden in der Funktionssicht abgebildet. Die Daten des Unternehmens sowie die durch sie repräsentierten Zustände und Ereignisse werden in der Datensicht beschrieben. Die Steuerungssicht verbindet die anderen Sichten miteinander und ermöglicht eine ganzheitliche Modellierung des Informationssystems.

Organisationssicht

Betriebswirtschaftliche iiche Problemstellung

Fachkonzept (semantische Modelle) Fachkonzept

DV-Konzept

•

Fachkonzept

DV-Konzept

Fachkonzept

Η

DV-Konzept

Implementierung

Implementierung

Implementierung

Datensicht

Steuerungssicht

Funktionssicht

DV-Konzept (DV-bezogene Beschreibungsebene)

Implementierung (DV-mäßige Realisierung)

9

Informationstechnik

Abb. 3.22: ARIS-Zerlegungssichten und -Beschreibungsebenen [nach Sch98a]

116

3 Konzeptueller Datenbankentwurf

Zur Modellierung von Geschäftsprozessen werden in der Steuerungssicht die Methoden der erweiterten ereignisgesteuerten Prozessketten (eEPK) und Vorgangskettendiagramme (VKD) angeboten, mit denen die zeitliche und logische Reihenfolge von Aktivitäten dargestellt werden können. Beschreibungsebenen In ARIS wird jede Zerlegungssicht um drei weitere Beschreibungsebenen ergänzt. Die Beschreibungsebenen ermöglichen eine durchgängige Beschreibung von der betriebswirtschaftlichen Problemstellung bis hin zur technischen Realisierung. Die drei Ebenen werden als Fachkonzept, DV-Konzept und Implementierung bezeichnet. Das Fachkonzept enthält ein Modell des betriebswirtschaftlichen Anwendungsgebietes. Das DV-Konzept überträgt die Begriffe aus dem Fachkonzept in die Kategorien der informationstechnischen Umsetzung. Die Implementierung beschreibt die technische Realisierung des Fachkonzeptes. Die Beschreibungsebenen sind durch unterschiedliche Änderungszyklen charakterisiert. Das betriebswirtschaftliche Fachkonzept ändert sich eher selten, wohingegen die Implementierung eng mit der Informationstechnik verbunden ist, die sehr schnellen Innovationszyklen unterliegt. Durch die vorgenommene Unterteilung in Beschreibungsebenen wird versucht, die Fachkonzeptebene von ihrer Realisierung und der verwendeten Informationstechnologie zu abstrahieren. Innerhalb der Ebenen und Sichten können in ARIS verschiedene Modellierungstechniken zum Einsatz kommen. Die wichtigsten Modelle, die dabei zum Einsatz kommen können, sind in Abbildung 3.23 in das ARIS-Haus eingeordnet. Des Weiteren unterstützt ARIS ein Vorgehensmodell, branchenspezifische Referenzmodelle und softwaremäßige Unterstützung der Modellbildung durch das ARIS-Toolset.

Aufgabenträgerebene ^ ^ ^

Organigramm

Netzdiagramm

Netztopologie

1

\ufgabenebene

WMSSSiii:

-eERM - eERM-Attributzuordnungsdiagramm

-

Informationsflussdiagramm Funktionszuordnungsdiagramm Wertschöpfungskettendiagramm eEPK und VKD

- Relationendiagramm - Attributzuordnungsdiagramm

- Zugriffsdiagramm

- Anwendungssystemtypendigramm

- Tabellendiagramm

- Zugriffsdiagramm (physikalisch)

- Anwendungssystemdiagramm

Abb. 3.23: Metamodelle in ARIS [nach Scha98a]

- Funktionsbaum - Y-Diagramm - Zieldiagramm

117

3.4 Weitere Formen der Modellbildung 3.4.1.2

Semantisches Objektmodell

Ausgangspunkt der Betrachtung im semantischen Objektmodell SOM [FeSi90], [FeSi98] stellt eine Unternehmensarchitektur, bestehend aus dem Unternehmensplan, Geschäftsprozessmodellen und Anwendungssystemen dar. Der Unternehmensplan beinhaltet das Ergebnis der betriebswirtschaftlichen Unternehmensplanung, identifziert die Unternehmensziele, analysiert Chancen und Risiken und bestimmt unterschiedliche Strategien zur Realisierung der Unternehmensziele. SOM sieht Geschäftsprozessmodelle als Spezifikation von Lösungsverfahren für die Umsetzung des Unternehmensplans. Anwendungssysteme stellen Ressourcen zur Durchführung von Geschäftsprozessen dar. Auch SOM reduziert die Komplexität von Unternehmensmodellen durch die Einführung von Ebenen und Sichten. Allerdings unterscheidet SOM - im Gegensatz zu ARIS - primär drei Ebenen und sekundär eine strukturorientierte und eine verhaltensorientierte Sicht. Die einzelnen Modellsichten, ihre Beziehungen sowie die methodischen Abhängigkeiten zwischen den Modellsichten sind im Vorgehensmodell (V-Modell) des SOM-Ansatzes zusammengefasst. Die Abhängigkeiten zwischen diesen beiden Sichten innerhalb der einzelnen Modellebenen werden durch den Abstand der Schenkel im V-Modell repräsentiert (siehe Abbildung 3.24). Eine detaillierte Darstellung der Vorgehensweise bei der geschäftsprozessorientierten Modellbildung unter Verwendung von SOM findet sich in [FeSi95]. 1. Ebene: Unternehmensplan (Objektsystem und Zielsystem) Basis der Modellbildung bildet die Unterscheidung in Objekt- und Zielsystem. Das Objektsystem besteht aus einer strukturorientierten Beschreibung der relevanten Teile des Unternehmensplans und aus der Abgrenzung der Diskurswelt von ihrer Umwelt. Das Zielsystem beschreibt eine verhaltensorientierte Sicht auf den Unternehmensplan. Zur Modellierung beider Komponenten wird auf informale Darstellungsformen (textuelle Beschreibung) zurückgegriffen.

strukturorientierte Sicht

verhaltensorientierte Sicht

Objektsystem

Zielsystem

Interaktionsmodell IM

Aufgabensystem A S

2. Ebene: Geschäftsprozesse

Vorgangsobjektschema VOS

3. Ebene: Anwendungssysteme

Konzeptueltes Objektschema KOS

Abb. 3.24: V-Modell des SOM-Ansatzes

[nach

1. Ebene: Unternehmensplan

FeSi95]

118

3 Konzeptueller Datenbankentwurf

2. Ebene: Ebene: Geschäftsprozesse (Interaktionsmodell und Aufgabensystem) In Ebene 2 des Modells werden Lösungsverfahren zur Umsetzung des Unternehmensplans in Form eines Systems von Geschäftsprozessen beschrieben und im Rahmen der Modellbildung schrittweise verfeinert. Die strukturorientierte Sicht auf das Objektsystem wird in einem Interaktionsmodell, die verhaltensorientierte Sicht auf die Aufgaben und Ziele des Unternehmensplans durch ein Aufgabensystem spezifiziert. Während der Modellbildung werden die beiden Sichten zunehmend verfeinert, so dass sie hinsichtlich des Detaillierungsgrades korrespondieren. Durch eine sukzessive Zerlegung des betrieblichen Objektsystems entsteht ein Interaktionsmodell, welches aus einer Folge von Interaktionsdiagrammen mit zunehmendem Detaillierungsgrad besteht. Innerhalb eines solchen Diagramms wird das Objektsystem als Menge von Objekten modelliert, die durch Flüsse miteinander verbunden sind. Parallel zum Interaktionsmodell wird das Aufgabensystem von der Gesamtaufgabe ihres Zielsystems abgeleitet. Das Aufgabensystem besteht aus einer Folge von Aufgabenzerlegungen, die mit je einem Interaktionsdiagramm korrespondieren. Zur Beschreibung der Ebene 2 des V-Modells wird eine semiformale Darstellungsform (Diagramme) angeboten. 3. Ebene: Anwendungssysteme (KOS und VOS) Auf dieser Ebene erfolgt die Spezifikation der Geschäftsprozesse aus der Sicht von Anwendungssystemen. Das strukturorientierte konzeptuelle Objektschema (KOS) besteht aus einer Menge von miteinander in Beziehung stehenden Objekttypen und stellt eine objektorientierte Erweiterung von SERM (vgl. Unterkapitel 3.1.2.1) um Objekttypen, Nachrichten und Methoden zur Behandlung eingehender Nachrichten dar. Die Modellierung des verhaltensorientierten Vorgangsobjektschemas (VOS) stellt die abschließende Phase der Objektmodellierung im SOM dar. Es beschreibt das Zusammenwirken konzeptueller Objekttypen bei der Durchführung betrieblicher Aufgaben, die in Form von Vorgängen durchgeführt werden. Jeder Vorgang besteht aus einer Folge von Aktionen, wird durch ein auslösendes Ereignis generiert und kann seinerseits weitere Ereignisse generieren. Für die Modellierung verwendet das VOS eine Menge so genannter Vorgangsobjekttypen, die für eine oder mehrere verwandte Aufgaben das Zusammenwirken der an der Aufgabendurchführung beteiligten konzeptuellen Objekttypen des KOS beschreiben. Zur Beschreibung der Ebene 3 des V-Modells wird ebenfalls eine semiformale Darstellungsform angeboten.

3.5

Sichtenintegration und Schemakonsolidierung

Die bisher geschilderte Vörgehensweise zur Erstellung einer Datenbank eignet sich nur für kleine und übersichtliche Entwurfsprojekte. In vielen großen Anwendungen geht die Anzahl der involvierten Entitytypen in mehrere Hunderte - dementsprechend hoch ist auch die Anzahl der erhobenen Attribute und Beziehungstypen. Um die Analyse der umfangreichen Anforderungen und damit verbunden die Komplexität des Entwurfs der Datenbank zu beherrschen, wird in vielen Projekten die Gesamtheit aller Anforderungen in kleinere und damit übersichtlichere Bereiche (Funktionsbereiche) geteilt und von unterschiedlichen Analytikern eine getrennte Analyse der Bereiche vorgenommen. Dieser Vorgehensweise kommt entgegen, dass die Analyse der Funktionsbereiche parallel erfolgen kann und Bereichsexperten eingesetzt werden können, die durch ihre Sachkenntnis zur verbesserten Qualität des Datenbankentwurfs beitragen können.

3.5 Sichtenintegration und Schemakonsolidierung

119

Die getrennte Vorgehensweise bei Anforderungserhebung und/oder -analyse durch mehrere Analytiker hat jedoch auch Nachteile. Unterschiedliche Personen können unterschiedliche Schwerpunkte in ihren Analysen setzen und verschiedene Aspekte unterschiedlich beurteilen und bewerten. Dies kann zur Folge haben, dass ein Sachverhalt der Realität in unterschiedlichen Analysen unterschiedlich dokumentiert wird oder aber auch zwei verschiedene Sachverhalte in zwei oder mehreren Modellen gleich bewertet werden. Dies ist darauf zurückzuführen, dass die unterschiedlichen Bereiche, die Gegenstand der Analyse sind, nicht unabhängig voneinander sind und unterschiedliche Interpretationen (Sichtweisen) auf gemeinsam genutzte Daten erlauben. Beispiel 3.15:

Sichtweisen auf Artikeldaten

In Abbildung 3.25 zeigen wir unterschiedliche Sichtweisen auf Artikeldaten aus unterschiedlichen Funktionsbereichen eines Unternehmens. Für jede Abteilung sind einige Begriffe dargestellt, die während der Analyse im Zusammenhang mit Artikeln gesammelt wurden. Dieses Beispiel zeigt eine der Problematiken der getrennten Analyse, nämlich die Gefahr der Verwendung von Homonymen und Synonymen durch unterschiedliche Entwerfer. So stellen die Begriffe „Artikel" im Einkauf und „Komponente" in der Produktion möglicherweise den gleichen Sachverhalt dar. Der „Artikel" aus dem Absatzbereich und das „Produkt" in der Produktionsabteilung sind ebenfalls Synonyme. Wenn der Leiter der Einkaufsabteilung von „Kosten" spricht, so meint er in erster Linie die Kosten der

« Qualität * Artikel * Preis ^mllffif^^ffi ^Ί Ii»

Ι , ! fP™*

• Kosten • Lager

Abb. 3.25: Sichtweisen auf Artikeldaten

120

3 Konzeptueller Datenbankentwurf

Beschaffung, d.h. den Preis, die Kosten für eine Eingangskontrolle, Lagerhaltungskosten, etc. In der Produktionsabteilung sind „Kosten" die Produktionskosten (Betriebsmittel, Betriebsstoffe, ...), und im Absatzbereich handelt es sich bei „Kosten" um Vertriebskosten (Kommissionierung, Absatzlager, ...). Ähnlich verhält es sich mit dem Begriff „Lager": Hierbei handelt es sich um Beschaffungslager, Zwischenlager, Produktionslager, Kommissionierungslager, Absatzlager, usw. Die „Qualität" im Absatzbereich bezieht sich auf die eigenen Erzeugnisse und damit auf die Produktion. Im Einkauf geht es bei „Qualität" jedoch um die Qualität der Lieferantenartikel (bspw. Rohstoffe). Feststellung 3.5:

Sichtenintegration, Schemakonsolidierung

Wird die Analyse der Anforderungen bereichsbezogen vorgenommen bzw. sind unterschiedliche Analytiker mit der Analyse von Teilproblemen befasst, so ist es notwendig, das Entwicklungszyklusmodell einer Datenbank um eine weitere Phase, die so genannte Sichtenintegration und Schemakonsolidierung, zu erweitern. Diese Phase findet üblicherweise während der konzeptuellen Modellbildung (vgl. Abbildung 1.1) statt, geht also davon aus, dass die Anforderungen der unterschiedlichen Bereiche individuell erhoben und analysiert wurden und als Bereichsdatenmodelle vorliegen. Die Integration erfolgt in den meisten Fällen auf der Basis zu konsolidierender Entity-RelationshipModelle. Die Integration kann auch bereits nach der Anforderungserhebung erfolgen, jedoch hat das den Nachteil, dass Anforderungen noch relativ schlecht strukturiert sind, und im Zuge der Analyse noch ein besseres Verständnis der Anwendung gewonnen werden kann. Eine Integration während des logischen Entwurfs der Datenbank wäre auch vorstellbar. Jedoch hat das den Nachteil, dass durch die eingeschränkte semantische Darstellungskraft des Relationenmodells relevante Sachverhalte in Integrationsentscheidungen ungenügend Berücksichtigung finden könnten. Bei der Integration unterschiedlicher Sichten wird immer von zumindest zwei Phasen ausgegangen. Während der ersten Phase werden unterschiedliche Bereiche bestimmt, die Benutzergruppen der Bereiche identifiziert, und eine Sicht auf die Daten erstellt, die die Anforderungen der Benutzer des jeweiligen Bereiches reflektiert (Bereichsdatenmodell). In der zweiten Phase erfolgt die eigentliche Integration der Sichten zu einem einheitlichen konzeptuellen Schema, das oft auch Unternehmensdatenmodell genannt wird und eine einheitliche Sicht auf den Datenbestand des Unternehmens repräsentiert. Da sich die Sichten der einzelnen Bereiche sehr oft überschneiden, ist es nicht möglich, das konzeptuelle Datenmodell durch einfaches Zusammenfügen von Bereichsdatenmodellen zu erzeugen. Vielmehr ist es notwendig, Konflikte zwischen der Darstellung in unterschiedlichen Bereichsmodellen zu erkennen und zu bereinigen, Konzepte mit identischer oder oft auch ähnlicher Semantik zusammenzufassen und neue Generalisierungen und Aggregationen zu bilden, um alle Sichten im konzeptuellen Modell adäquat und konsistent zu repräsentieren. Ein weiterer Aspekt der Aufteilung der Arbeit zwischen unterschiedlichen Analytikern ist der Zeitpunkt, zu dem die Analyse durchgeführt wird. In vielen Unternehmen gibt es bereits bestehende Datenbanksysteme, die oftmals in das neu zu schaffende System integriert werden sollen oder die nicht mehr als Insellösungen für bestimmte Bereiche betrieben werden, sondern zu einem einzigen System zusammengeführt werden sollen. In beiden Fällen liegt bereits ein Datenbankschema vor, das nun ebenfalls Gegenstand der Integration ist.

3.5 Sichtenintegration und Schemakonsolidierung

121

Bei der Integration von Sichten geht man davon aus, dass die Zeitpunkte der Erhebung der Anforderungen der Nutzer der unterschiedlichen Bereiche nicht weit auseinander liegen. Des Weiteren erfolgte die Erhebung koordiniert und unter Verwendung einheitlicher Vorgehensmodelle. Bei der Integration unterschiedlicher Datenbanken ist dies meistens nicht der Fall. Die Datenbanken sind meist unkoordiniert entstanden und da ihre Entstehungszeitpunkte weit auseinander liegen können, kamen oft unterschiedliche Produkte, ja oft sogar Systeme, die auf unterschiedlichen Datenbankmodellen beruhen, zum Einsatz. Ist dies der Fall, so müssen die einzelnen heterogenen Datenbankschemata in einem einheitlichen Schema abgebildet und Strukturunterschiede zwischen den Datenbankmodellen ausgeglichen werden. Des Weiteren findet der Integrationsprozess nach der Population der Datenbank mit Daten statt. Das hat zur Folge, dass Widersprüche auf der Instanzenebene auftreten können, die während der Integration auf geeignete Weise berücksichtigt werden müssen. Für die nachfolgenden Betrachtungen unterstellen wir Einheitlichkeit bezüglich der verwendeten Datenbankmodelle. Wurden während der Analyse unterschiedliche Datenmodelle eingesetzt oder basieren die zu integrierenden Datenbanken auf unterschiedlichen Modellen, so unterstellen wir, dass eventuell notwendige Transformationen bereits stattgefunden haben.

3.5.1

Prozess der Sichtenintegration

Bevor mit der eigentlichen Sichtenintegration begonnen werden kann, muss in einer Vorphase entschieden werden, in welcher Reihenfolge die Bereichsdatenmodelle integriert werden und welche Integrationsstrategie angewendet werden soll. Der Integrationsprozess ist mit der Entstehung vorübergehender Schemata verbunden, die ein Zwischenergebnis darstellen und zur weiteren Integration mit anderen Bereichsdatenmodellen verglichen werden. In der Frage, wie viele Schemata zu einem Zeitpunkt verglichen werden, lassen sich binäre und n-stellige Ansätze der Sichtenintegration unterscheiden. Bei der binären Integration werden schrittweise zwei Schemata zu einem teilintegrierten Schema konsolidiert, das im nächsten Schritt mit einem weiteren Bereichsdatenmodell zu einem neuen teilintegrierten Schema konsolidiert wird. Dieser Vorgang wird so lange fortgesetzt, bis das unternehmensweit konsolidierte Datenmodell entwickelt ist. Die n-stellige Integration unterliegt nicht der Einschränkung, dass nur zwei Schemata pro Schritt integriert werden können. Die „One-shot"-Methode fügt in nur einem Schritt alle Schemata zum globalen konzeptuellen Schema zusammen. Wenn innerhalb der n-stelligen Integration Zwischenschritte zugelassen sind, spricht man von iterativer Integration. Der Vorteil der n-stelligen Methode gegenüber der binären liegt in der Verfügbarkeit von mehr Informationen innerhalb eines Schrittes und in der größeren Flexibilität der Analytiker, da diese die Anzahl der zu integrierenden Schemata variieren können. Der Nachteil ergibt sich jedoch aus der größeren Komplexität, die eine Ursache für Designfehler darstellen kann. Ein wesentliches Problem des Integrationsprozesses stellt die Wahl der Reihenfolge der zu integrierenden Sichten dar. Hierzu wird in der Literatur oft eine Gewichtung der Sichten vorgeschlagen, die die Qualität und Relevanz der Sichten repräsentieren soll. Die Gewichtung wird durch die Rolle der Aufgabenträger in der Organisation und die Zuverlässigkeit, die für den vorhergegangenen Entwurfsschritt (Anforderungserhebung und -analyse) angenommen werden kann, bestimmt. Sichten mit höherer Gewichtung sollen dann früher in den Integrationsprozess

122

3 Konzeptueller Datenbankentwurf

aufgenommen werden, um eine höhere Stabilität und Konvergenz der teilintegrierten Schemata zu erreichen. Oft wird auch vorgeschlagen, Sichten mit einer zusätzlichen Gewichtung zu versehen, wenn die zugehörigen Benutzer „unumstrittene Experten" in dem modellierten Bereich sind. Der eigentliche Integrationsprozess läuft in den drei Phasen Vergleichsphase, Anpassungsbzw. Vereinheitlichungsphase und Zusammenführungs- bzw. Konsolidierungsphase ab. Hierbei muss man jedoch einschränkend erwähnen, dass diese Phasen auch in Kombination durchgeführt werden können. Auch schlagen viele Autoren eine iterative Vorgehensweise der Sichtenintegration vor, mit dem Vorteil, dass einzelne Integrationsphasen wiederholt durchgeführt werden können, um eine Konsolidierungsphase zu umgehen. In den folgenden Unterkapiteln soll auf die einzelnen Phasen näher eingegangen werden. 3.5.1.1

Vergleichsphase

Nachdem die Integrationsstrategie gewählt worden ist, kann mit der eigentlichen Integration begonnen werden. Die entscheidende Aufgabe in der Vergleichsphase besteht in der Analyse und Dokumentation des Zusammenhanges zwischen den unterschiedlichen Bereichsdatenmodellen und der Identifikation möglicher Konflikte. Unterschiedliche Funktionsbereiche können über gemeinsam genutzte Datenbestände miteinander in Zusammenhang stehen. In der Vergleichsphase müssen die Zusammenhänge festgestellt werden, da sie Ursache möglicher Konflikte sein können. Zwei Schemata bzw. Schemakonstrukte können im Allgemeinen auf vier verschiedene Arten in Korrespondenzbeziehung stehen. •

Identisch:

Die Bereichsdatenmodelle stellen den gleichen Sachverhalt der Realität dar. Das verwendete Modellierungskonstrukt zur Abbildung des Sachverhaltes ist identisch. •

Disjunkt:

Die betrachteten Bereichsdatenmodelle referenzieren keine identischen Ereignisse der Realität. Es existiert jedoch eine Korrespondenz zwischen den Modellen über gemeinsam genutzte Bezeichner. •

Überlappend:

Einige Schemakonstrukte des einen Bereiches kommen auch in einem anderen vor. Die Bereichsdatenmodelle besitzen jedoch auch eigene Elemente. •

Enthalten:

Ein Schema (Schemakonstrukt) ist eine Teilmenge des anderen. Im nächsten Schritt muss der Designer für korrespondierende Schemakonstrukte aus unterschiedlichen Bereichen feststellen, ob (Modellierungs-)Konflikte vorliegen. Dabei lassen sich unterschiedliche Arten von Konflikten feststellen. •

Namenskonflikte

Sie können in zwei unterschiedlichen Varianten auftreten. Im ersten Fall verwenden verschiedene Entwickler zur Bezeichnung eines Sachverhaltes der Realität dasselbe Modellierungskonstrukt, jedoch unterschiedliche Namen. In diesem Fall spricht man von

3.5 Sichtenintegration und Schemakonsolidierung

123

Synonymen (zwei identische Konstrukte, z.B. Entity typen tragen unterschiedliche Namen). In der zweiten Variante werden zwei Sachverhalte der Realität mit unterschiedlicher Bedeutung mit einem identischen Bezeichner versehen. In diesem Fall spricht man von Homonymen. •

Strukturkonflikte Hier tritt der Fall auf, dass in den Bereichsmodellen derselbe Sachverhalt unter Verwendung unterschiedlicher Strukturierungskonzepte dargestellt wurde. Man kann drei Arten von Strukturkonflikten unterscheiden. Ein Typkonflikt zwischen zu integrierenden Bereichsmodellen liegt vor, wenn ein Sachverhalt der realen Welt mit unterschiedlichen Modellierungskonzepten dargestellt wird. So kann z.B. ein Entitytyp der einen Sicht als Beziehungstyp oder auch als Attribut in einer anderen Sicht modelliert sein. Wenn ein Sachverhalt der realen Welt unterschiedlich modelliert werden kann, so spricht man in diesem Zusammenhang auch von semantischem Relativismus. Ein Beziehungskonflikt oder aber auch Abhängigkeitskonflikt bezieht sich auf unterschiedlich gewählte Integritätsbedingungen. Ein Beispiel dafür sind verschiedene Kardinalitäten von Beziehungstypen, die denselben Sachverhalt referenzieren. Z.B. kann in einer Sicht eine Beziehung zwischen zwei Entity typen als (N:M)-Beziehungstyp definiert sein, und in einer anderen Sicht gilt eine (1:N)-Einschränkung. Auch äquivalente Darstellungen (siehe Abbildung 3.7) identischer Sachverhalte können die Ursache von Beziehungskonflikten sein. Die dritte Klasse von Strukturkonflikten bilden die Schlüsselkonflikte. Diese entstehen, wenn in unterschiedlichen Bereichen für identische Sachverhalte unterschiedliche Schlüssel gewählt wurden.

•

Verhaltens- und Abstraktionskonflikte Von Verhaltenskonflikten sind hauptsächlich Einfüge- und Löschoperationen betroffen. Der Begriff „Verhalten" bezieht sich hier auf die Einhaltung referentieller Integrität. So könnte in einem Bereich spezifiziert sein, dass nach dem Löschen der letzten Referenz auf einen Sachverhalt dieser Sachverhalt auch gelöscht werden soll, während in einem anderen Bereich spezifiziert ist, dass er weiterhin gespeichert bleiben soll. Abstraktionskonflikte treten auf, wenn identische Sachverhalte in unterschiedlichen Bereichen auf unterschiedlichem Abstraktionsniveau dargestellt werden. Beispiele dafür sind unterschiedliche Detaillierungsgrade in Generalisierungs- oder Subtypenhierarchien oder (l:l)-Beziehungstypen, die in einer Sicht dargestellt sind und in einer anderen Sicht zu einem einzigen Entitytyp zusammengefasst wurden.

3.5.1.2

Anpassungs- und Vereinheitlichungsphase

Die entdeckten Konflikte aus der vorherigen Phase müssen in diesem Schritt gelöst werden, um die Schemata für die Integration vorzubereiten. Dies kann dadurch erreicht werden, dass eine der beteiligten Sichten „nachgibt", um durch Transformation der in Konflikt stehenden Teile Konsens zwischen den Sichten zu erreichen. Die Schwierigkeit liegt darin, geeignete Transformationen zwischen den Schemata zu wählen. Namenskonflikte lassen sich im Vergleich zu den anderen Konfliktarten noch relativ leicht lösen, obwohl in größeren Datenmodellen durchaus Konflikte übersehen werden können. Bestimmte Merkmale weisen jedoch auf die Existenz möglicher Konflikte hin. Haben Konstrukte mit verschiedenen Namen mehrere gemeinsame Eigenschaften und unterliegen diese auch den gleichen Einschränkungen, so deutet diese Ähnlichkeit auf ein Synonym hin. Im Gegensatz

124

3 Konzeptueller Datenbankentwurf

dazu weisen gleiche Namen von Konstrukten mit unterschiedlichen Eigenschaften und Einschränkungen auf ein Homonym hin. Homonyme sind offensichtlich leichter zu erkennen als Synonyme. Als Lösung von Namenskonflikten bieten sich Namensanpassungen oder -änderungen an. Nachdem Namenskonflikte gelöst worden sind, erhält man eindeutige Bezeichner für alle Konstrukte. Nach dieser Phase kann vorausgesetzt werden, dass Konstrukte mit identischem Bezeichner auch wirklich denselben Sachverhalt der realen Welt darstellen. Die anderen Konfliktarten lassen sich nicht so einfach lösen. Während der Vergleichsphase wurden vom Designer zwischen den Konstrukten unterschiedlicher Schemata Korrespondenzbeziehungen definiert. Die Korrespondenzbeziehungen beruhen jedoch auf Vermutungen, die es nun in der Vereinheitlichungsphase zu verifizieren gilt. Dies wird in den meisten Fällen durch Beiziehung von Bereichsexperten oder durch Konsultation der Personen, die die Bereichsdatenmodelle erstellt haben, geschehen. Die Zusammenführung der Bereichsdatenmodelle erfolgt dann abhängig von der Art der festgestellten Korrespondenzbeziehung in der nächsten Phase. 3.5.1.3

Zusammenführungs- und Konsolidierungsphase

Die abschließende Phase im Integrationsprozess gliedert sich in zwei Teilschritte. Im ersten Teil werden die vereinheitlichten Bereichsdatenmodelle in Abhängigkeit der festgestellten Korrespondenzbeziehungen integriert. Im zweiten Teil werden Restrukturierungsmaßnahmen auf dem integrierten Schema ausgeführt, um dieses zu optimieren. 3.5.1.3.1

Zusammenführung

von

Entitytypen

Die Zusammenführung erfolgt abhängig von der Art der in der Vergleichsphase festgestellten Korrespondenzbeziehungen zwischen Entitytypen. •

Identische Entitytypen aus unterschiedlichen Bereichsdatenmodellen werden im integrierten Schema zu einem Entitytyp zusammengefasst. Dabei werden die Attribute beider Entitytypen in den integrierten Entitytyp aufgenommen.

•

Bei zwei Entitytypen aus unterschiedlichen Bereichsdatenmodellen mit überlappenden Attributen oder gemeinsamen Entities werden im integrierten Schema drei Entitytypen gebildet. Der Durchschnitt der Attribute der Entitytypen bildet einen genetischen Entitytyp, die beiden anderen Entitytypen mit den noch verbleibenden Attributen bilden Spezialisierungen. Sind Spezialisierungen nicht disjunkt, wird der Sachverhalt als Untermengenhierarchie dargestellt.

•

Wenn ein Entitytyp alle Entities eines Entitytypen eines anderen Bereichsdatenmodells enthält, so werden beide Entitytypen als Klasse und zugehörige Subklasse in das integrierte Schema übernommen.

•

Referenzieren Entitytypen unterschiedliche Sachverhalte der realen Welt, so sind sie disjunkt und werden in das integrierte Schema als eigenständige Entitytypen aufgenommen. Wurde jedoch eine Korrespondenzbeziehung festgestellt (z.B. wegen korrespondierender Attribute), kann auch eine Integration der Entitytypen erwogen werden.

3.5 Sichtenintegration und Schemakonsolidierung Beispiel 3.16:

125

Korrespondierende Attribute bei disjunkten Entitytypen

Wir betrachten die Entitytypen „Professor" mit Attributen SVNr, Name, Gehalt und „Student" mit Attributen SVNr, Name, Gehalt, Studienrichtung. Wir nehmen an, dass Entities vom Typ Professor nicht mehr studieren und beide Entitytypen daher disjunkt sind. Obwohl Korrespondenzen über gemeinsame Attribute existieren, ist es nicht notwendigerweise sinnvoll, die Entitytypen zu integrieren. Beispiel 3.17:

Integration enthaltender Entitytypen

In Abbildung 3.26 betrachten wir korrespondierende Entitytypen aus den Bereichsdatenmodellen von Absatz und Produktion. Im Absatzbereich sind für jeden Artikel u.a. seine Artikelnummer (A-Nr) und sein Preis von Bedeutung. In der Produktion der Produktionsort (P-Ort), die involvierten Arbeitsstunden (Stunden) und die Maschine, auf der das Produkt gefertigt wurde. Da jedes Produkt auch verkauft wird, ist Entitytyp „Eigenfertigung" im Entitytyp „Artikel" enthalten und die Integration kann über die Einführung einer Untermengenbeziehung im integrierten Schema erfolgen.

Abb. 3.26: Integration enthaltender Entitytypen

Beispiel 3.18:

Integration überlappender Entitytypen

In Abbildung 3.27 betrachten wir Ausschnitte aus den Bereichsdatenmodellen der Einkaufsabteilung und der Produktion. Es wird angenommen, dass es Artikel gibt, die sowohl in Eigenfertigung erstellt, als auch über Lieferanten bezogen werden. Die Entitytypen Fremdbezug und Eigenfertigung sind somit überlappend, und die Darstellung im integrierten Schema erfolgt als Untermengenhierarchie.

3.5.1.3.2

Zusammenftihrung von Beziehungstypen

Mit dem Zusammenführen von Beziehungstypen kann unmittelbar nach der Zusammenführung der Entitytypen begonnen werden. Wurden zwei Entitytypen zusammengeführt, so sind alle Beziehungstypen, in die sie involviert waren, ebenfalls Kandidaten für eine Zusammenführung.

126

3 Konzeptueller Datenbankentwurf A_Nr

Fremdbezug