Datenmodellierung am Beispiel des Einkaufs

Inhalt

1 Daten als Unternehmensressource

2 Datenbankarchitektur

3 Datenbankentwurf
3.1 Strategische Vorgehensweise
3.2 Phasen des Datenbankentwurfs

4 Szenario

5 Informationsbedarfsanalyse
5.1 Informations- und Funktionsanforderung
5.2 Verfahren zur Informationsbedarfsanalyse

6 Semantischer Entwurf
6.1 Entity Relationship Modell
6.1.1 Entity Typen und Entities
6.1.2 Beziehungstypen, Beziehungen und Kardinalitäten
6.1.3 Attribute und Wertebereich
6.2 Semantische Modellierung des Szenarios

7 Logischer Entwurf
7.1 Relationale Datenbankmodelle
7.2 Transformation des ERM in das Relationen-Modell
7.3 Normalisierung
7.4 Logische Modellierung des Szenarios

8 Datenmodellierung in neuen Informationssystemen

Quellenverzeichnis

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 Produktionsfaktor 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 erforderlichen 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 -metho-den 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 Datenbankmanagementsystem. Die Datenbank ist eine integrierte und strukturierte Sammlung inhaltlich zusammengehöriger Daten. Das Datenbankmanagementsystem umfasst alle 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.

Abbildung in dieser Leseprobe nicht enthalten

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:

- Verständlichkeit: Erstellung eines transparenten Modells, das einfache Zugriffe durch Programme und Personen erlaubt.
- Minimalität: Reduzierung des Modells auf die Sachverhalte, welche für die geplanten Anwendungen relevant sind.
- Neutralität: Erarbeitung eines Modells, welche die flexible Nutzung unterschiedlicher Anwendungen ermöglicht.
- Integrität: Vermeidung von inhaltlichen Widersprüchen bei der Darstellung der Daten.
- Erweiterbarkeit: Sicherstellung der Erweiterbarkeit des Modells hinsichtlich neuer Informations- und Verarbeitungsanforderungen.
- Redundanzfreiheit: Vermeidung mehrfacher Darstellung von Daten, um eine redundanzfreie Speicherung und einfache Wartung sicherzustellen.
- Effizienz: Unterstützung einer leistungsstarken Datenbank [REIN95, S. 119].

Zwischen den Formalzielen können Zielkonflikte entstehen. Z. B. verbessert die Redundanzfreiheit 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, Einkaufsorganisation, Einkäufergruppe, Mitarbeiter) und deren Beziehungen untereinander (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 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 unverbunden 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.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Phasen des Datenbankentwurfs (in Anlehnung an [REIN95, S. 127] )

Der in der Abbildung dargestellte sequentielle Ablauf wird in der Realität selten eingehalten, da ein ständiges Überprüfen und Hinterfragen der einzelnen Teilergebnisse immer wieder zu Rückverweisen und Iterationen führt [LANG95, S. 294].

4 Szenario

Die Vorgehensweise der konzeptuellen Datenbankmodellierung soll anhand eines Praxisbeispiels aus dem Bereich Einkauf/Beschaffung demonstriert werden. Das ausgewählte Beispiel stammt aus der betrieblichen Standardanwendungssoftware SAP/R3 der Firma SAP AG, und beschreibt den Prozess einer Materialbestellung angefangen bei einer verbrauchenden Stelle, wie Vertrieb oder Produktion, bis hin zur Erfassung der gelieferten Ware.

Es soll der Teil einer Datenbank modelliert werden, mit dessen Hilfe die Anwendungssoftware eine Bestellung mit Hilfe aller relevanten Daten tätigen kann. Die Bestellung wird dadurch ausgelöst, dass z. B. der Vertrieb durch einen Verkaufsauftrag bestimmte Materialien benötigt. Diesen Bedarf teilt er der Einkaufsabteilung mit, in dem er eine Bestellanforderung mit ein oder mehreren Position anlegt. Diese wird darauf folgend durch den zuständigen Einkäufer bearbeitet, der daraus einen Bestellauftrag generiert. Dabei können die Daten aus der Bestellanforderung übernommen werden, so dass in beiden Belegen die gleichen Positionen vorkommen. Der Bestellauftrag (kurz: Bestellung) wird an den Lieferanten übermittelt, welcher die entsprechenden Materialien liefert. Abschließend wird die eingegangene Lieferung im Wareneingang verbucht.

Da der beschriebene Vorgang dem Ablauf in SAP/R3 entspricht, werden die spezifischen Begriffe sowie ihre Funktionen und Zusammenhänge im Folgenden erläutert:

Eine Bestellanforderung ist eine Aufforderung an den Einkauf ein Material oder eine Dienstleitung in einer bestimmten Menge zu einem bestimmten Zeitpunkt zu besorgen. Sie ist ein interner elektronischer Beleg, dem bei jeder Generierung eine laufende, eindeutig identifizierende Nummer vom System zugeordnet wird [SAP01].

Dabei besteht sie aus mehreren Positionen, welche u. A. Positionsnummer sowie Menge und Wunschliefertermin der benötigten Ware enthalten. Des Weiteren wird in der Position mit Hilfe einer Positionsart festgelegt, um welche Beschaffungsart, wie z. B. Normal- oder Dienstleistungsbeschaffung, es sich handelt [SAP01].

Aus der Bestellanforderung generiert der Einkäufer einen oder mehrere Bestellaufträge. Letzteres ist dann der Fall, wenn die Ware von unterschiedlichen Lieferanten bezogen wird. Um den Prozess zu beschleunigen, können die Positionen automatisch in die Bestellung übernommen und dort inhaltlich modifiziert werden. Auch bei der Bestellung handelt es sich um einen elektronischen Beleg, der bei seiner Erfassung eine laufende Identifikationsnummer erhält. Allerdings hat er keinen internen Charakter, da er per Fax, eMail, EDI oder XML an den zuständigen Lieferanten gesendet wird [SAP01].

Im Wareneingang werden die gelieferten Waren mengen- und wertmäßig erfasst sowie mit dem Lieferdatum versehen. Somit kann überprüft werden, in wieweit ein Lieferant von den vereinbarten Konditionen und Terminen abweicht. Des Weiteren werden ausgehend davon Einlagerung und Kontierung der Materialien vorgenommen. Wie auch die anderen Belege erhält jeder gebuchte Wareneingang eine Identifikationsnummer [SAP01].

In der Realität darf dieser Ausschnitt nicht alleine betrachtet werden, sondern als Teil eines unternehmensweiten Datenmodells. Im Folgenden werden zu diesem Vorgang eine Informationsbedarfsanalyse durchgeführt, sowie ein semantischer und ein logischer Entwurf für ein relationales Datenbankmodell erstellt.

[...]