Seminar  : Anwendungsorientierte Informatik im Wintersemester  

2002/03  zum  

Thema  : Datenmodellierung am Beispiel des Einkaufs  

Nummer  des Themas:  7

von:  Frank Echinger aus Mödling  

Inhalt   

1  Daten als Unternehmensressource.  3

2  Datenbankarchitektur.  3

3  Datenbankentwurf.  5

3.1  Strategische Vorgehensweise  6

3.2  Phasen des Datenbankentwurfs  7

4  Szenario.  8

5  Informationsbedarfsanalyse.  10

5.1  Informations- und Funktionsanforderung  10

5.2  Verfahren zur Informationsbedarfsanalyse  10

6  Semantischer Entwurf  13

6.1  Entity Relationship Modell  13

6.1.1  Entity Typen und Entities.  14

6.1.2  Beziehungstypen, Beziehungen und Kardinalitäten  15

6.1.3  Attribute und Wertebereich  17

6.2  Semantische Modellierung des Szenarios.  18

7  Logischer Entwurf  19

7.1  Relationale Datenbankmodelle.  20

7.2  Transformation des ERM in das Relationen-Modell.  20

7.3  Normalisierung  22

7.4  Logische Modellierung des Szenarios  23

8  Datenmodellierung in neuen Informationssystemen  25

Quellenverzeichnis   27

1 Daten als Unternehmensressource

Nach heutiger Auffassung spielen für wirtschaftlich operierende Unternehmen Daten als Ressource eine genauso wichtige Rolle wie Personal, Maschinen, Rohstoffe und Finanzmittel. Daten werden hierbei als besonderer Rohstoff aufgefasst, aus dem bei Verarbeitung Informationen hervorgehen. Weiterhin werden Sie oft als vierter Pro-duktionsfaktor gesehen [LOCK93, S. 715].

Wie jede andere betriebliche Ressource müssen daher auch Informationen professionell geplant, beschafft, verwaltet und genutzt werden. Das Ziel des Informationsmanagements besteht darin, jeder Stelle im Unternehmen alle relevanten Informationen zum richtigen Zeitpunkt, am richtigen Ort und in der für den Verwendungszweck er-forderlichen Qualität zur Verfügung zu stellen [SCHW02, S 6]. Dabei spielen Datenbanksysteme (DBS) als Instrumente des Informationsmanagements eine wesentliche Rolle. Die konzeptuelle Datenmodellierung ist Bestandteil eines Datenbankentwurfs und wichtige Grundlage zur Bestimmung des Inhalts und des Aufbaus der Datenbank. Sie dient dazu ein Modell der realen Geschäftswelt mit Hilfe mathematischer, graphischer und textueller Formalismen so zu beschreiben, dass eine transparente, präzise und überschaubare Grundlage für den Aufbau einer Datenbank entsteht [RAUH97, S. 14ff.].

Im Folgenden soll beschrieben werden, wie die Datenmodellierung zu einem effizienten Einsatz der Unternehmensressource Information beiträgt. Dabei werden zuerst die wesentlichen Merkmale einer Datenbank erläutert sowie strategische Vorgehensweisen und Phasen bei einem Datenbankentwurf vorgestellt. Anschließend erfolgt eine detaillierte Beschreibung der einzelnen Modellierungsphasen und -methoden anhand eines Szenarios aus dem Unternehmensbereich Einkauf/Beschaffung. Abschließend wird auf die Bedeutung der Datenmodellierung in neuartigen Informationssystemen hingewiesen.

2 Datenbankarchitektur

Ein Datenbanksystem besteht aus den Komponenten Datenbank und Datenbankma-nagementsystem. Die Datenbank ist eine integrierte und strukturierte Sammlung in-haltlich zusammengehöriger Daten. Das Datenbankmanagementsystem umfasst alle Anwendungsorientierte Informatik Seite 3

Datenmodellierung am Beispiel des Einkaufs

Funktionen zur korrekten Handhabung und zentralen Verwaltung der Datenbank. Ziel des Einsatzes ist eine integrierte, redundanzfreie und anwendungsunabhängige Datenverarbeitung, was durch eine spezielle Datenbankarchitektur erreicht wird. Hier hat sich bis heute die 3-Schema-Architektur weitgehend durchgesetzt, welche 1975 von der amerikanischen Organisation ANSI/X3/SPARC Study Group on Database Systems vorgestellt wurde. Dabei wird zwischen der externen, internen und konzeptuellen Ebene unterschieden, welche je ein bestimmtes Schema enthalten [REIN95; S. 32ff.].

Das konzeptuelle Schema ist ein abstrahiertes Abbild bzw. Modell der realen Unternehmenswelt. Es stellt die logische Struktur aller für die betrachteten Anwendungen relevanten Daten dar und ist datenneutral sowie datenunabhängig. Datenneutral bedeutet die Neutralität des Modells gegenüber unterschiedlichen Anwendungen aus Benutzersicht und datenunabhängig die Unabhängigkeit von der physischen Speicherung der Daten. Weiterhin kann das konzeptuelle Schema in zwei Subschemata unterteilt werden, das semantische und das logische Subschema (semantisches und logisches Datenmodell). Das semantische Datenmodell stellt mit Hilfe geeigneter Formalismen die Struktur der Daten des relevanten Bereiches der realen Unternehmenswelt dar. Daraus wird das logische Datenmodell je nach verwendetem Datenbankverwaltungssystem in das relationale, hierarchische, objektorientierte oder Netzwerk Datenbankmodell abgeleitet [FISC92, S. 72f.]. Die Modellierung eines konzeptuellen Schemas ist Kernpunkt dieser Arbeit.

Das interne Schema beschreibt die logische und physische Speicherung der Daten des konzeptuellen Schemas mit Hilfe verschiedener Dateiorganisationsverfahren auf unterschiedlichen Speichermedien [FISC92, S. 73].

Das externe Schema stellt die Daten den unterschiedlichen Anwendungsprogrammen zur Verfügung und ist somit die Schnittstelle zwischen Datenbank und Anwender. Dabei werden aus dem konzeptuellen Schema beliebig viele anwendungsbezogene Datensichten kreiert, welche sich vom Inhalt und Informationsbedarf je nach Anwender unterscheiden [FISC92, S. 74]. Die folgende Abbildung 1 verdeutlicht die Funktion der 3-Schema-Architektur.

Seite 4 Anwendungsorientierte Informatik

Abbildung 1: 3-Schema-Architektur einer Datenbank nach ANSI/X3/SPARC (in Anlehnung an [SCHE02, S. 4] )

Die Kommunikation zwischen den Ebenen funktioniert über Transformationsregeln, welche Vorschriften zur Abbildung der Inhalte einer Ebene auf einer anderen beinhalten. Findet z. B. auf der konzeptuellen Ebene eine Modifikation statt, hat das keine direkten Auswirkungen auf das interne- bzw. externe Schema. Es müssen lediglich die spezifischen Transformationsregeln geändert werden [REIN95; S 35].

3 Datenbankentwurf

Der Datenbankentwurf enthält diejenigen Schritte, die notwendig sind, um eine Datenbank nach der oben beschriebenen Architektur aufzubauen. Dazu gehören „die Erfassung der Sachverhalte des für eine Anwendung interessierenden Ausschnitts der realen Welt“ [BÖHN90, S. 116], sowie dessen Umsetzung in ein konzeptuelles (semantisches und logisches) Datenmodell mit Hilfe geeigneter Formalismen. Die Erarbeitung eines internen und externen Schemas fällt zwar unter den Entwurf, wird aber nicht zur Datenmodellierung gezählt und ist deshalb nicht im Detail behandelt [REIN95, S. 118].

Der Datenbankentwurf entscheidet über die Qualität hinsichtlich Inhalt und Funktion der Datenbank, weshalb eine Reihe von Formalzielen zur Sicherung der Ergebnisqualität bei der Modellierung berücksichtigt werden müssen:

Anwendungsorientierte Informatik Seite 5

Datenmodellierung am Beispiel des Einkaufs

Zwischen den Formalzielen können Zielkonflikte entstehen. Z. B. verbessert die Re-dundanzfreiheit Speicherausnutzung und Wartungsaufwand, hemmt aber die Leistung der Datenbank. Um den Anforderungen möglichst gerecht zu werden, sollte auf bewährte strategische Vorgehensweisen und Modellierungsmethoden zurückgegriffen werden.

3.1 Strategische Vorgehensweise

Für die Erstellung konzeptueller Datenbankschemata bieten sich zwei unterschiedliche Strategien an, die Top-Down- und die Bottom-Up-Vorgehensweise. Bei der Top-Down-Vorgehensweise geht man von einem groben Unternehmensdatenmodell aus, welches die betrachteten Bereiche und deren Zusammenwirken auf einem hohen Abstraktionsniveau beschreibt [GABR95, S. 179]. Ausgehend davon wird das Modell sukzessiv verfeinert, indem jeder relevante Bereich (z. B. Einkauf, Produktion, Vertrieb) weiter in seine Informationsobjekte (z. B. Abteilung, Ein-kaufsorganisation, Einkäufergruppe, Mitarbeiter) und deren Beziehungen unterein-ander (z. B. leitet, bestellt, bearbeitet) differenziert wird. Ergebnis ist ein unternehmensweites, semantisches Datenbankmodell welches alle Objekt- und Beziehungstypen sowie Attribute darstellt und somit als Basis für alle Anwendungsprogramme

Seite 6 Anwendungsorientierte Informatik

dient [REIN95, S. 120]. Vorteil dieser Methode ist die hohe Integrität des Modells, da die einzelnen Teilbereiche zusammenhängend und ausgehend von einem gemeinsamen Schema modelliert werden. Außerdem können Schwachstellen in der Organisation frühzeitig erkannt und behoben werden. Nachteile dieser Strategie sind der hohe Zeitbedarf und die große Komplexität des Modells [BROM93, S. 181]. Bei der Bottom-Up-Vorgehensweise ist Ausgangspunkt der Modellierung eine detaillierte Erfassung der Informationsobjekte sowie deren Beziehungen und Attribute innerhalb eines bestimmten Unternehmensbereiches. Nach der Erstellung der einzelnen Bereichsmodelle müssen diese zu einem gesamten Unternehmensmodell integriert werden, wobei deren Detaillierungsgrad wieder teilweise reduziert und einander angepasst wird. Ergebnis ist auch hier ein semantisches, unternehmensweites Datenbankmodell als Basis für alle Anwendungsprogramme [BROM93, S. 182]. Vorteil der Bottom-Up-Vorgehensweise ist die schnelle Erstellung einsatzreifer Teillösungen. Allerdings ist der Integrationsaufwand der Teilbereiche sehr hoch und oft fehleranfällig [REIN95, S. 121].

Um die Vorteile beider Strategien zu nutzen, bietet sich eine hybride Form der zwei Vorgehensweisen an. Dabei wird zuerst gemäß der Top-Down-Vorgehensweise ein grobes Datenmodell mit allen Teilbereichen des Unternehmens hierarchisch aufgebaut. Eine Detaillierung der einzelnen Bereiche findet nur soweit statt, insofern es für eine Integration notwendig ist. Erst nach Erarbeitung dieses Basismodells werden die Details nach der Bottom-Up-Vorgehensweise erarbeitet. Diese Methode hat den Vorteil, dass später modellierte Bereiche des gesamten Komplexes nicht vollständig un-verbunden zu bereits realisierten Teilen stehen [THOM, D.4.4, S.1].

3.2 Phasen des Datenbankentwurfs

Die Einteilung des Datenbankentwurfs in mehrere Phasen ist notwendig, um die Komplexität der Gesamtaufgabe durch Zerlegung in aufeinanderfolgende Teilaufgaben zu reduzieren und um einzelne Phasenziele zu definieren [STAH02, S. 222]. Beim Datenbankentwurf hat sich die Vorgehensweise nach dem Database-Lifecycle-Konzept durchgesetzt, welches in Abbildung 2 dargestellt ist.

Anwendungsorientierte Informatik Seite 7