Migration eines Mittelverwaltungssystems in eine Multiuserumgebung

Inhaltsverzeichnis

1 Einleitung
1.1 Problemstellung
1.2 Software Engineering
1.2.1 Aktivitäten beim Software Engineering
1.2.2 Prozeßmodelle des Software Engineering
1.2.3 Paradigmen des Software Engineering
1.2.4 Phasenmodell des Datenbankentwurfs
1.3 Gliederung

2 Datenbanken
2.1 Historische Entwicklung
2.2 Datenbankkonzept
2.2.1 Datenbankarchitektur
2.2.2 Datenbankverwaltungssystem
2.2.3 Vor- und Nachteile des Datenbankkonzepts
2.3 Datenmodelle
2.3.1 Grundelemente
2.3.2 Hierarchisches Datenmodell
2.3.3 Netzwerkartiges Datenmodell
2.3.4 Objektorientiertes Datenmodell
2.4 Relationales Datenmodell
2.4.1 Klassisches Relationenmodell
2.4.2 Normalisierung
2.4.3 Entity-Relationship-Modell
2.4.4 Erweitertes Relationenmodell
2.4.5 Codd’s Regeln
2.5 Datenintegrität
2.5.1 Datenkonsistenz
2.5.2 Datensicherheit
2.5.3 Datenschutz
2.6 Datenbanken als Teil eines betrieblichen Informationssystems

3 Verteilte Anwendungen
3.1 Computernetzwerke
3.1.1 Vorteile und Anforderungen
3.1.2 Netzwerk-Technologie
3.2 Verteilte Systeme
3.2.1 Definition und Eigenschaften
3.2.2 Architektur
3.2.3 Verteilte Anwendungen
3.2.4 ODBC

4 Analyse
4.1 Fachliche Vorstudie
4.1.1 Allgemeine Zielsetzung und Anwendungsbereich
4.1.2 Beschreibung des Anwendungsbereichs
4.1.3 Gegenwärtige Informationsverarbeitung
4.1.4 Lösungskonzept
4.2 Durchführbarkeitsstudie
4.2.1 Auswahl von Computersystem und Standardsoftware .
4.2.2 Projektkalkulation und Kosten/Nutzen-Analyse
4.2.3 Alternative Lösungen
4.2.4 Projektrisiken
4.3 Pflichtenheft
4.4 Fachliches Analysemodell
4.4.1 Datenflußmodell
4.4.2 Datenmodellierung
4.4.3 Analyse der Antwort-Anforderungen

5 Entwurf
5.1 Datenbankentwurf
5.1.1 Softwaretechnische Aspekte der Datenbank-Realisierung
5.1.2 Konzeptionelles Schema
5.1.3 Externe Schemata
5.1.4 Internes Schema
5.2 Entwurf des Access-Anwendungsprogramms
5.2.1 Softwaretechnische Aspekte der Realisierung
5.2.2 Schnittstellen zwischen Datenbank und Anwendungsprogramm
5.2.3 Modulkonzept für Microsoft Access
5.2.4 Systemarchitektur
5.2.5 Objektentwurf
5.2.6 Entwurf der Stored Procedures
5.2.7 Entwurf der Benutzungsoberfläche

6 Implementierung
6.1 Implementierung der Datenbank auf der Server-Entwicklungsmaschine
6.2 Realisierung des Anwendungssystems
6.2.1 Erste Masterversion: Bestell- und Rechnungswesen
6.2.2 Erste Userversion: Bestell- und Rechnungswesen
6.2.3 Zweite Masterversion: Benutzerverwaltung
6.2.4 Dritte Masterversion: Fehlerbehandlung
6.2.5 Dritte Userversion: Fehlerbehandlung
6.2.6 Vierte Masterversion: Verwaltung interner Bestellnummern . .
6.2.7 Vierte Userversion: Verwaltung interner Bestellnummern
6.2.8 Fünfte Masterversion: Verwaltung des Inventars
6.2.9 Fünfte Userversion: Verwaltung des Inventars
6.3 Installation und Einrichtung der Server-Basismaschine
6.4 Test des Anwendungssystems während der Implementierung

7 Abnahme und Einführung
7.1 Abnahme
7.2 Einführung
7.2.1 Inbetriebnahme der Server-Basismaschine
7.2.2 Installation und Einrichtung des Softwaresystems auf den Clients
7.2.3 Benutzerschulungen
7.2.4 Einführungsphase

8 Zusammenfassung

A Analysedokumente
A.1 Pflichtenheft
A.1.1 Globale Ziele
A.1.2 Produkteinsatz
A.1.3 Produktumgebung
A.1.4 Produktfunktionen
A.1.5 Produktdaten
A.1.6 Produktleistungen
A.1.7 Qualitätsanforderungen
A.1.8 Benutzungsoberfläche
A.1.9 Entwicklungsumgebung
A.1.10 Abnahme- und Einführungsfestlegungen
A.1.11 Projektrahmenfestlegungen
A.2 Datenlexikon
A.2.1 Datenelemente
A.2.2 Datenstrukturen
A.2.3 Datenflüsse
A.2.4 Datenspeicher
A.2.5 Beschreibung von Prozessen

B Entwurfsdokumente
B.1 Tabellen des konzeptionellen Datenbankschemas
B.2 Menüstruktur des Anwendungsprogramms
B.3 Migrierte Microsoft Access-Objekte der Legacy-Anwendungen
B.4 Objektdiagramme der Masterversion (Hauptmenü, Benutzerverwaltung, Interne Bestellnummern)
B.5 Objektbeschreibungsschemata der neu entworfenen Objekte
B.5.1 Formular Benutzer
B.5.2 Formular BnrIntholen
B.5.3 Formular BnrIntMenue
B.5.4 Formular BnrIntprüfen
B.5.5 Formular BnrIntzeigen
B.5.6 Formular DatenBenutzer
B.5.7 Formular DeleteBenutzer
B.5.8 Formular EditBenutzer
B.5.9 Formular Hauptmenü
B.5.10 Formular NeuBenutzer
B.5.11 Formular PasswortBenutzer
B.5.12 Bericht ReportLastBnrInt
B.5.13 Bericht ReportLastBnrInt2
B.6 Referenz des in der Arbeit verwendeten Pseudocodes
B.7 Spezifikationen der Access-Objekte in Pseudocode .
B.7.1 Formular Benutzer
B.7.2 Formular BnrIntholen
B.7.3 Formular BnrIntMenue
B.7.4 Formular BnrIntprüfen
B.7.5 Formular BnrIntzeigen
B.7.6 Formular DatenBenutzer
B.7.7 Formular DeleteBenutzer
B.7.8 Formular EditBenutzer
B.7.9 Formular Hauptmenue
B.7.10 Formular NeuBenutzer
B.7.11 Formular PasswortBenutzer
B.8 Spezifikationen der Stored Procedures in Pseudocode
B.8.1 SP BezahltUpdate
B.8.2 SP BezahltUpdateBnrInt
B.8.3 SP BnrIntBerechtigt
B.8.4 SP BnrIntEinrichtung
B.8.5 SP EditBest
B.8.6 SP EinrIntUmbBnrInt
B.8.7 SP EtatUpdate
B.8.8 SP IDBnrIntEinrBestellungenBnrVerg
B.8.9 SP IDLiefEinrBestellungenBnrInt
B.8.10 SP InsertBnrInt
B.8.11 SP IntUmbAnlass
B.8.12 SP IntUmbCountBnrInt
B.8.13 SP IntUmbMaxBnrInt
B.8.14 SP IntUmbSummeBnrInt
B.8.15 SP JADelete
B.8.16 SP LiefEinrBestellungenBnrInt
B.8.17 SP MaxExtUmbBnrInt
B.8.18 SP PruefKont
B.8.19 SP RoundMaxIntUmbBnrInt
B.9 Dialogelemente der Formulare der Benutzungsoberfläche
B.9.1 Dialogelemente für die neuen Formulare
B.9.2 Geänderte Dialogelemente der angepaßten bestehenden Formulare

C Implementierungsdokumente
C.1 Ablauf Realisierung der ersten Masterversion
C.1.1 Implementierungs- und Testplan
C.1.2 Detaillierte Auflistung der Arbeitsschritte
C.2 Ablauf Realisierung der ersten Userversion
C.2.1 Implementierungs- und Testplan
C.2.2 Detaillierte Auflistung der Arbeitsschritte
C.3 Ablauf Realisierung der zweiten Masterversion
C.3.1 Implementierungs- und Testplan
C.3.2 Detaillierte Auflistung der Arbeitsschritte
C.4 Ablauf Realisierung der dritten Masterversion
C.4.1 Implementierungs- und Testplan
C.4.2 Detaillierte Auflistung der Arbeitsschritte
C.5 Ablauf Realisierung der dritten Userversion
C.5.1 Implementierungs- und Testplan
C.5.2 Detaillierte Auflistung der Arbeitsschritte
C.6 Ablauf Realisierung der vierten Masterversion
C.6.1 Implementierungs- und Testplan
C.6.2 Detaillierte Auflistung der Arbeitsschritte
C.7 Ablauf Realisierung der vierten Userversion
C.7.1 Implementierungs- und Testplan
C.7.2 Detaillierte Auflistung der Arbeitsschritte
C.8 Ablauf Realisierung der fünften Masterversion
C.8.1 Implementierungs- und Testplan
C.8.2 Detaillierte Auflistung der Arbeitsschritte
C.9 Ablauf Realisierung der fünften Userversion
C.9.1 Implementierungs- und Testplan
C.9.2 Detaillierte Auflistung der Arbeitsschritte
C.10 Nutzung des Access Upsizing-Assistenten zum Anlegen der Datenbank Haushalt
C.11 Abbildungen der Benutzungsoberfläche der neu erstellten Formulare
C.12 Fehlerbeseitigung (fünfte Versionen)

D Anleitungen

E OSI- und TCP/IP-Referenzmodell

Literaturverzeichnis

Verzeichnis der Akronyme

Abbildungsverzeichnis

1.1 Das Teufelsquadrat

1.2 Evolutionäres Modell mit vollständiger Analyse

1.3 Softwareentwicklung mit integrierter Datenbankentwicklung

2.1 Datenbankebenen im ANSI-Architekturmodell

2.2 Grafische Darstellung einer Beziehung zwischen zwei Entitätsmengen

2.3 Konzept für integrierte betriebliche Informationssysteme

3.1 Drei-Schicht-Architektur eines verteilten Systems

4.1 Kontextdiagramm des Haushaltsprogramms

4.2 Grobes Datenflußdiagramm des Haushaltsprogramms

4.3 Verfeinertes Datenflußdiagramm des Prozesses Benutzerverwaltung

4.4 Verfeinertes Datenflußdiagramm des Prozesses Interne Bestellnummern verwalten

4.5 Entitätenblockdiagramm des vorläufigen Datenmodells

4.6 Relationales Datenmodell

4.7 Relationales Datenmodell in expliziter Relationenschreibweise

4.8 Entity-Relationship-Diagramm der global normalisierten Datenbasis

A.1 Anwendungsfalldiagramm der wichtigsten Anwendungsfälle des Haushaltspro- gramms

A.2 Funktionsbaum der wichtigsten Funktionen des Haushaltsprogramms

B.1 Ornigramm des Hauptmenüs

B.2 Ornigramm des Menüs Bestellungen und Rechnungen bearbeiten

B.3 Ornigramme der Untermenüs Externe Umbuchungen bearbeiten und Interne Umbuchungen bearbeiten

B.4 Ornigramm des Menüs Inventar verwalten

B.5 Ornigramm des Menüs Berichte erstellen

B.6 Ornigramm des Menüs Titelzuweisungen bearbeiten

B.7 Ornigramm des Menüs Benutzerverwaltung

B.8 Ornigramm des Menüs Tabellen anzeigen

B.9 Ornigramm des Menüs Interne Bestellnummern

B.10 Objektdiagramm der Steuerschicht des Hauptmenüs

B.11 Objektdiagramm der problemorientierten Schicht des Hauptmenüs

B.12 Objektdiagramm des Menüs für die Verwaltung der Internen Bestellnummern

B.13 Objektdiagramm des Menüs für die Benutzerverwaltung

C.1 Upsizing Assistent: Auswahl Portierungsmethode

C.2 Upsizing Assistent: Auswahl Datenbank und Benutzerkennung

C.3 Upsizing Assistent: Auswahl zu exportierender Tabellen

C.4 Upsizing Assistent: Einstellungen für den Export der Tabellenattribute

C.5 Benutzungsoberfläche des Formulars Benutzer

C.6 Benutzungsoberfläche des Formulars NeuBenutzer

C.7 Benutzungsoberfläche des Formulars EditBenutzer

C.8 Benutzungsoberfläche des Formulars DatenBenutzer

C.9 Benutzungsoberfläche des Formulars PasswortBenutzer

C.10 Benutzungsoberfläche des Formulars DeleteBenutzer

C.11 Benutzungsoberfläche des Formulars BnrIntMenue

C.12 Benutzungsoberfläche des Formulars BnrIntHolen

C.13 Benutzungsoberfläche des Formulars BnrIntZeigen

C.14 Benutzungsoberfläche des Formulars BnrIntPrüfen

C.15 Benutzungsoberfläche des Formulars TabeleBenutzer

C.16 Benutzungsoberfläche des Formulars TabeleBnrInt

Tabellenverzeichnis

2.1 Wesentliche Merkmale des ANSI-Architekturmodells

2.2 Die Assoziationstypen der Datenmodellierung

2.3 Operationen der Relationenalgebra

2.4 Vergleich von Dateisystem und Datenbanksystem

4.1 Die Editionen des Microsoft SQL Server 2005

4.2 Hardwareanforderungen für das Serversystem

4.3 Hardware-Komponenten des Serversystems

4.4 Vergleich der jährlichen Kosten zwischen altem und neuem Softwaresystem

4.5 Konsistenzbedingungen der Datenbasis

5.1 Die Zugriffsrechte auf die Datenbank für die Institutsverwaltung

5.2 Die Zugriffsrechte auf die Datenbank für die Benutzer

6.1 Allgemeine Testfälle

B.1 Tabelle Bendaten des konzeptionellen Modells

B.2 Tabelle Benutzer des konzeptionellen Modells

B.3 Tabelle Bestellungen des konzeptionellen Modells

B.4 Tabelle BnrInt des konzeptionellen Modells

B.5 Tabelle Einrichtungen des konzeptionellen Modells

B.6 Tabelle ExtUmb des konzeptionellen Modells

B.7 Tabelle IntUmb des konzeptionellen Modells

B.8 Tabelle InvTab des konzeptionellen Modells

B.9 Tabelle Rechnungen des konzeptionellen Modells

B.10 Tabelle Titels des konzeptionellen Modells

B.11 Tabelle Zuteilungen des konzeptionellen Modells

C.1 Implementierungs- und Testplan für die Objekte des Anwendungssystems in der ersten Masterversion

C.2 Implementierungs- und Testplan für die Objekte des Anwendungssystems in der ersten Userversion

C.3 Implementierungs- und Testplan für die Objekte des Anwendungssystems in der zweiten Masterversion

C.4 Implementierungs- und Testplan für die Objekte des Anwendungssystems in der dritten Masterversion

C.5 Implementierungs- und Testplan für die Objekte des Anwendungssystems in der dritten Userversion

C.6 Implementierungs- und Testplan für die Objekte des Anwendungssystems in der vierten Masterversion

C.7 Implementierungs- und Testplan für die Objekte des Anwendungssystems in der vierten Userversion

C.8 Implementierungs- und Testplan für die Objekte des Anwendungssystems in der fünften Masterversion

C.9 Implementierungs- und Testplan für die Objekte des Anwendungssystems in der fünften Userversion

E.1 Das OSI-Referenzmodell

Kapitel 1 Einleitung

1.1 Problemstellung

Bei einer zeitlichen Betrachtung läßt sich die Geschichte der Menschheit in mehrere Epochen unterteilen. Der Wechsel zwischen verschiedenen Epochen geht oft einher mit bedeutenden technologischen Errungenschaften, wie zum Beispiel die Verwendung von Eisen (Eisenzeit) oder die Entwicklung der Dampfmaschine (Zeitalter der Industrialisierung). Auch in den letz- ten Jahren hat sich durch die Digitaltechnik eine Zeitenwende vollzogen, die sich deutlich in dem Übergang von der Industriegesellschaft zur Informationsgesellschaft (MERTENS, P. (2001, S.239f.))äußert. Die ersten Digitalcomputer, als dessen erster funktionsfähiger Vertreter der von Konrad Zuse im Jahr 1941 gebaute Z3 (JÜRGENS, A. (2007); ROJAS, R. u. BAUER, F. L. (1998); ZUSE, H. (2003)) angesehen wird, waren Großrechner, mit denen nur wenige Menschen praktische Erfahrungen hatten. Erst die Einführung der Personal Computer (PC), daß heißt von Computern, die im Gegensatz von Großrechnern durch einzelne Personen bedient, genutzt und gesteuert werden können, hatte eine Durchdringung des Alltags mit der Digitaltechnik zur Fol- ge. Als erster realisierte der von Steve Jobs und Steve Wozniak entwickelte Apple I das Konzept des „persönlichen“ Computers Mitte der 1970er Jahre (WOZNIAK, S. u. SMITH, G. (2006)). Zu der enormen Verbreitung des PCs führte aber erst der 1981 vorgestellte IBM-PC IBM 5150, dessen Hardware-Architektur bis heute im Wesentlichen Industriestandard ist (ALLNER, J. u. ALLNER, K. (2003)). Gegenwärtig besitzen in Deutschland 77 % aller Haushalte einen PC (BITKOM (2007)).

Diese Verbreitung hat in stärkerer Weise die betriebliche Datenverarbeitung erfahren, die erheb- lich von den Möglichkeiten der Digitalcomputer profitiert hat. Gerade in der Anfangszeit brach- te die Verwendung von PCs auch neue Probleme mit sich. Besonders problematisch war, daß die PCs nicht über leistungsfähige Kommunikationssysteme verbunden waren. Dies hatte einerseits zur Folge, daß die Daten auf jedem PC redundant gespeichert werden mußten und entsprechend große Festspeicher in jedem Gerät benötigt wurden. Ferner führten sich laufendändernde Daten schnell zu Inkonsistenzen zwischen den Datenbeständen der verschiedenen PCs und erschwer- ten Auswertungen auf einer aktuellen Datenbasis deutlich. Diese Probleme bestanden aufgrund unterschiedlicher Dateiformate sogar zwischen den Daten verschiedener Anwendungen eines PCs. Die Nachteile gaben Anlaß zur Entwicklung der Datenbank-Technologie, welche eine Da- tenbasis mit einem zentralen Verwaltungssystem für alle PCs über ein Netzwerk bereitstellt (GEHRING, H. u. HOMBERGER, J. (1993, KE1 S.3)). Dabei darf nicht vernachlässigt werden, daß die Entwicklung immer leistungsfähiger Rechner-Netzwerke die Nutzung einer zentralen Datenbank für mehrere PCs erst ermöglichte. Gegenwärtig ist die Datenbank-Technologie eine nicht mehr wegzudenkende Kerntechnologie der betrieblichen Datenverarbeitung.

Diese Arbeit beschäftigt sich mit einem Teil der betrieblichen Datenverarbeitung des Instituts Physik an der Universität Dortmund: Die Verwaltung der Haushaltsmittel und des Inventars der Einrichtungen, in die sich das Institut untergliedert. Die computergestützte Datenverarbeitung befindet sich in der Situation, daß zwar eine zentrale Datenbank für die Haushaltsmittel und das Inventar existiert, auf diese aber nur von einem PC aus zugegriffen werden kann. Da dieser PC nur von der Institutsverwaltung benutzt werden kann, müssen die Einrichtungen eigene Lösungen mit redundanten Datenbeständen für ihre Datenverarbeitung verwenden.

Der Anreiz zur Verbesserung dieser Situation ergab sich aus folgenden Gründen. Zu Beginn des Jahres 2006 wurde an den nordrhein-westfälischen Universitäten der Globalhaushalt eingeführt. Neben der Umstellung von der kameralistischen auf die kaufmännische Buchführung, gibt die- ser den Instituten und Einrichtungen eine größere Flexibilität bei der Planung ihrer Haushalts- mittel. Gleichzeitig war er jedoch Anlaß zu deutlichen Kürzungen der Haushaltsmittel. In den gleichen Zeitraum fiel der Eintritt des Altersruhestands des für die zentrale Datenverwaltung zuständige Mitarbeiters. Aufgrund der Kürzungen der Haushaltsmittel ergab sich die Notwen- digkeit diese Stelle nicht mehr neu besetzen zu können. Daraus entwickelte sich die Aufgabe im Rahmen dieser Diplomarbeit eine neue Software-Lösung für diesen Teil der Mittelverwaltung des Instituts Physik zu entwerfen. Diese soll den neuen Bedürfnissen und den verbesserten tech- nischen Gegebenheiten gerecht wird, welche sich durch die Entwicklung von leistungsfähigeren Rechner-Netzwerken und Datenbank-Technologien ergeben haben.

1.2 Software Engineering

Bei der Entwicklung der Lösung werden die Prinzipien, Methoden, Konzepte und Werkzeuge des Software Engineering nach BALZERT, H. (1982, 1996, 1998); BORTFELD, A. (2001); GEHRING, H. (1993); PAGEL, B.-U. u. SIX, H.-W. (1994); WEDEKIND, H. (1973) verwendet. Dabei wird beachtet, daß es sich um ein Projekt handelt, das nur von einer Person durchgeführt wird.

Unter Software Engineering versteht man die Unterstützung bei der Beherrschung von Pro- blemstellungen der Softwareherstellung mit ingenieurmäßig-systematischer Vorgehensweise, die sich an den grundlegenden Anforderungen der Softwareherstellung orientiert. Diese An- forderungen sind die Realisierung von vorgesehener Funktionalität und Qualität und die Ein- haltung von Kostenlimits und Fertigstellungsterminen (BORTFELD, A. (2001, KE1 S.10)). Die Notwendigkeit Software Engineering zu verwenden ergibt sich aufgrund mehrerer Aspekte. Zum einen lassen sich die vier grundlegenden Anforderungen nicht einfach unabhängig von- einander realisieren, sondern erzeugen aufgrund ihrer Interdependenz einen enormen Druck auf die Softwareentwicklung (BORTFELD, A. (2001, KE1 S.9-14)). In der Literatur (SNEED, H. M. (1987)) wird diese Interdependenz treffend unter dem Stichwort „Teufelsquadrat“ beschrieben (siehe Abbildung 1.1).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.1: Das Teufelsquadrat nach SNEED, H. M. (2005, S.6).

Ferner ist der besondere Charakter von Software problematisch, der sich primär in Immateria- lität (Software kann man nicht „anfassen“.) und Abbildcharakter (Software ist das spezifische Abbild eines Problems oder Realitätsausschnitts.)äußert. Diesäußert sich beispielsweise dar- in, daß Software schwer zu veranschaulichen ist und hohes Abstraktionsvermögen und große Kreativität bei der Abbildung der realen Problemstellungen erfordert (BORTFELD, A. (2001, KE1 S.14f.)). Letztlich führen die rasanten Fortschritte der Computertechnologie in der letzten Zeit, zu immer stärker wachsenden Anforderungen an die Softwareentwicklung (BALZERT, H. (1996, S.25-34)).

1.2.1 Aktivitäten beim Software Engineering

Die durchzuführenden Aktivitäten beim Software Engineering lassen sich jeweils einem der folgenden Teilgebiete zuordnen:

- Entwicklung = Erstellung des Softwareprodukts
- Management = Koordination der Aktivitäten, Kundenkontakt
- Qualitätssicherung = Überprüfung des Softwareprodukts.

Dieses Projekt befaßt sich primär mit der Entwicklung. Projektmanagement und Qualitätssiche- rung können zwar nicht vollständig vernachlässigt werden, jedoch eignen sich die entsprechen- den Methodiken des Software Engineering für dieses Projekt nicht besonders, da sie originär für Mehrpersonenprojekte gedacht sind. Hauptproblem ist der große Aufwand bei einer Durch- führung dieser Aktivitäten, welcher in keiner Relation zu dem entstehenden Nutzen stünde.

Die für ein Softwareprojekt durchzuführenden grundlegenden Entwicklungs-Aktivitäten werden in der nachfolgenden Übersicht charakterisiert:

Abbildung in dieser Leseprobe nicht enthalten

1.2.2 Prozeßmodelle des Software Engineering

Bei der Durchführung der Aktivitäten während des Softwareentwicklungs-Prozesses werden diese zu sogenannten Phasen¹ zusammengefaßt. Die Phaseneinteilung und -abfolge wiederum wird durch Prozeßmodelle (auch Vorgehensmodelle genannt) unterstützt. Grundsätzlich lassen sich viele unterschiedliche Prozeßmodelle in der Literatur finden (BALZERT, H. (1998, S.97- 138); BLÜMMEL, B. u. DE VRIES, A. (2005, S.7-15); DENERT, E. u. HESSE, W. (1980); GEHRING, H. (1993, KE1 S.8-15); WEDEKIND, H. (1973, S.17-20)). Diese verfolgen alle die Zielsetzung, den Gesamtprozeß der Softwareentwicklung zu gliedern und aufeinander auf- bauende Phasen-Ergebnisse zu definieren, um eine disziplinierte und kontrollierbare Softwa- reentwicklung sicherzustellen. Obwohl sich die Phasen in den verschiedenen Prozeßmodellen unterscheiden, sind die entscheidenden Phasen Analyse, Entwurf und Implementierung in allen vorhanden. Diese überbrücken die „semantische Lücke“ (BORTFELD, A. (2001, KE1 S.24)) zwischen Realweltausschnitt und verfügbarer Systemumgebung (Hard- und Software). In der Analysephase, die in der Literatur auch als „Analyse- und Definitionsphase“ bezeichnet wird (z.B. PAGEL, B.-U. u. SIX, H.-W. (1994, S.77)), werden die Planungs- und Definitionsaktivi- täten zusammengefaßt. Je nach Modell kann durch Iteration und zeitlich überlappende Durch- führung eine starke Verschränkung der jeweiligen Phasen auftreten.

Die Auswahl eines geeigneten Prozeßmodells erfolgt, nachdem sich der Entwickler einen Über- blick über das zu entwickelnde System verschafft hat. Bei dem vorliegenden Projekt wird nach dem „evolutionären Modell mit vollständiger Analyse“ vorgegangen, welches eine Variation des „evolutionären Modells“ ist (BORTFELD, A. (2001, KE1 S.34); BALZERT, H. (1998, S.120- 123)). In der Literatur wird das evolutionäre Modell häufig auch als „inkrementell(-iteratives) Modell“ (BLÜMMEL, B. u. DE VRIES, A. (2005, S.9-12); BALZERT, H. (1998, S.122f.)) be- zeichnet.

Bei dem evolutionären Modell wird ausgehend von Kernanforderungen eine einsatzfähige Ver- sion des Produkts entwickelt, welche dann basierend auf den Erfahrungen der Vorversion zu immer weiteren Versionen weiterentwickelt wird. Das Softwaresystem wird somit als eine Serie von aufeinander aufbauenden Teilprodukten mit ständig steigender Funktionalität erstellt. Für jedes Teilprodukt werden die in Abbildung 1.2 dargestellten Aktivitäten durchgeführt (jedoch nur für die zusätzlichen bzw. geänderten Anforderungen), so daß das Projekt in einer Folge iterativer Durchführungen der Analyse-, Entwurfs- und Implementierungsaktivitäten abläuft. Vorteile der evolutionären Modelle im Vergleich zu anderen Vorgehensmodellen sind, daß ein- satzfähige Produkte in kürzeren Zeitabständen vorliegen, eine kontinuierlichere und intensivere Zusammenarbeit mit dem Auftraggeber erfolgt und die Erkenntnisse aus den praktischen Ein- sätzen der ersten Produktversionen bei der Produktentwicklung berücksichtigt werden können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.2: Evolutionäres Modell mit vollständiger Analyse.

Als Modifikation werden beim evolutionären Modell mit vollständiger Analyse bereits zu Beginn die vollständigen Anforderungen erfaßt. Dies mindert das Übersehen wichtiger Anforderungen bei der Ermittlung der Kernanforderungen, welches das größte Risiko bei Verwendung des evolutionären Modells ist.

Für das evolutionären Modell mit vollständiger Analyse können drei Phasen abgegrenzt werden: Analyse, iterative Konstruktion und Produkteinsatz. Die Phase iterative Konstruktion umfaßt die Aktivitäten Entwurf und Implementierung. Eine Wartungsphase entfällt im evolutionären Modell, da deren Aktivitäten (z.B. Fehlerbeseitigung und Modifikationen der Funktionalität) wie die Erstellung einer neuen Version gehandhabt werden.

1.2.3 Paradigmen des Software Engineering

In der Anfangszeit des Software Engineering zwischen 1970 und 1990 wurden verschiedene Varianten einer strukturierten Softwareentwicklung vorgeschlagen (DEMARCO, T. u. PLAU- GER, P. J. (1979); MYERS, G. J. (1975, 1978); PAGE-JONES, M. (1988); STEVENS, W. P. u. MYERS, G. J. (1974); STEVENS,W. P. (1981); YOURDON, E. N. u. CONSTANTINE, E. L.

(1979)), als dessen leistungsfähigste Methode die Moderne Strukturierte Analyse (MSA) von YOURDON, E. N. (1989) angesehen werden kann. Inzwischen steht mit dem objektorientierten Ansatz ein für komplexe Problemstellungen, Wartungsfreundlichkeit und Wiederverwendbar- keit von Komponenten besserer Denkansatz zur Verfügung (BORTFELD, A. (2001, KE1 S.5)). Die beiden unterschiedlichen Ansätze, die auch als Paradigmen bezeichnet werden, wirken sich dabei primär auf die auszuführenden Aktivitäten der ersten drei Phasen Analyse, Entwurf und Implementierung aus.

Der große Vorteil der objektorientierten Methode ergibt sich aus der Änderungsflexibilität und Durchgängigkeit der Objektorientierung (BALZERT, H. (1995, S.15)). Die Ergebnisdokumente der jeweiligen Phasen werden direkt als Ausgangspunkt für die nächste Phase übernommen. Die problemlose Übernahme wird dabei durch eine einheitliche Modellierungssprache, die 1996 eingeführte und 1997 standardisierte Unified Modeling Language (UML), sicher gestellt. Diese liegt aktuell in der zweiten Version vor (BORN, M. u. a. (2004); JECKLE, M. u. a. (2003)). Die UML ist eine Zusammenführung der Booch-Methode von BOOCH, G. (1994), der Object- Modelling Technique (OMT) von RUMBAUGH, J. R. u. a. (1991), des Object-Oriented Software Engineering (OOSE) von JACOBSON, I. u. a. (1992) und weiterer Methoden (DE VRIES, A. (2005, S.5)). Inzwischen existieren auch speziell objektorientierte Prozeßmodelle, als deren mächtigster Vertreter der Rational Unified Process (RUP) angesehen wird (BLÜMMEL, B. u. DE VRIES, A. (2005, S.13-15); JACOBSON, I. u.a. (1999); KRUCHTEN, P. (2004)).

Trotz der Vorteile der objektorientierten Methode ist sie für das vorliegende Projekt ungeeignet, weil sie an die objektorientierte Technik gebunden ist. Da die bestehenden Anwendungen in der prozeduralen Makrosprache Visual Basic für Applikationen (VBA) implementiert sind, würde die Verwendung einer objektorientierten Softwareentwicklung die Möglichkeit einer Weiterentwicklung der bestehenden Anwendungen behindern. Eine Weiterentwicklung ist bei diesem Projekt jedoch besonders vorteilhaft und wird primär verfolgt. Da zudem keine relevante Ereignis-Orientierung (BALZERT, H. (1996, S.420)) des zu entwickelnden Anwendungssystems vorliegt, wird nach der Variante der strukturierten Softwareentwicklung vorgegangen, wie sie in GEHRING, H. (1993, KE2) beschrieben wird.

1.2.4 Phasenmodell des Datenbankentwurfs

Eine Besonderheit des Ablaufs der Softwareentwicklung im Rahmen dieser Arbeit ist, daß der Entwurf einer Datenbank ein zentraler Bestandteil der Entwicklung ist. Für den Datenbankentwurf existieren in der Literatur spezielle Phasenmodelle (BALZERT, H. (1996, S.714); GEHRING, H. u. HOMBERGER, J. (1993, S.86f.); HEUER, A. u. SAAKE, G. (2000, S.172f.); JOHANNES, H. (2002, S.22f.)). Basierend auf diesen Modellen wird folgende Phaseneinteilung für das Projekt im Rahmen dieser Arbeit vorgenommen:

- Ermittlung und Analyse Informationsbedarf
- Definition des logischen Datenmodells
- Entwurf von konzeptionellem, internem und externen Schemata
- Installation Datenbanksystem (DBS) und Implementierung der Entwurfsergebnisse auf das DBS

Dabei wird der spezielle Ansatz dieser Arbeit, die Entwicklung einer relationalen Datenbank mit Drei-Schichten-Architektur (vgl. Kapitel 2) im Rahmen einer Anwendungsentwicklung, berücksichtigt.

Die Integration der Phasen in das hier verwendete evolutionäre Prozeßmodell erfolgt analog zu BALZERT, H. (1996, S.717):

Die Ermittlung und Analyse des Informationsbedarfs bedarf keiner besonderen Behandlung, da diese Anforderungen bereits im Rahmen der Erstellung des Pflichtenhefts in der Analysepha- se des Software Engineering ermittelt werden. Analog zu GEHRING, H. (1993, KE2 S.41-48) kann die Definition des logischen Datenmodells im Rahmen des Fachlichen Modells ebenfalls in der Analysephase des Software Engineering vorgenommen werden, da diese unabhängig von einem konkreten Datenbankverwaltungssystem (DBVS) erfolgt. Diese frühe Definition bevor- zugten inbesondere die durch die Legacy-Systeme bekannte Strukturierung der Daten und der frühe Zeitpunkt, zu dem bei diesem Projekt der DBS-Einsatz feststand. In der Literatur wird Definition des logischen Datenmodells teilweise zum Entwurf gezählt (vgl. z.B. PAGEL, B.-U. u. SIX, H.-W. (1994, S.629-632)). Kritisch ist die Zuordnung bei Verwendung des vorliegen- den Prozeßmodells jedoch nicht, da dieser Schritt in der Literatur entweder als letzter Schritt der Analyse oder als erster Schritt des Entwurfs erfolgt und sich im Gesamtablauf dadurch nicht verschiebt.

Zum Entwurf wird in dieser Arbeit erst die darauf folgende Erstellung des konzeptionellen, internen und der externen Schemata der Datenbank gezählt. Daran schließt sich der Entwurf der Anwendung an. Für die Implementierung kann analog verfahren werden: Zuerst wird die Datenbank implementiert (Installation DBS und Implementierung der Schemata), bevor die Implementierung der Anwendung vorgenommen wird.

Das sich aus den Ausführungen ergebende, modifizierte Modell wird in Abbildung 1.3 dargestellt. Obwohl es nicht explizit in der Abbildung dargestellt ist, wird die iterative Wiederholung der einzelnen Phasen im Rahmen des evolutionären Prozeßmodells durch die zusätzlichen Phasen nicht tangiert. ZEHNDER, C. A. (2002, S.114f.) schreibt sogar, daß der Entwurf einer Datenbank ein iterativer Prozeß ist.

1.3 Gliederung

Die Gliederung der Arbeit orientiert sich primär an den Phasen der Softwareentwicklung. Die- sem Kapitel, welches zur Einführung in das Thema und der Darstellung der Vorgehensweise mittels des Software Engineering dient, folgen in den nächsten beiden Kapitel die Erläuterung

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1.3: Softwareentwicklung mit integrierter Datenbankentwicklung.

der wichtigsten Grundlagen von Datenbanken und verteilten Anwendungen. Die beiden Kapi- tel basieren hauptsächlich auf den Ausführungen von DE VRIES, A. (2004), GEHRING, H. u. HOMBERGER, J. (1993) und JOHANNES, H. (2002). Anschließend wird in den Kapiteln „Ana- lyse“, „Entwurf“, „Implementierung“ und „Abnahme und Einführung“ die Entwicklung der Software im strukturierten Paradigma beschrieben. Die in den einzelnen Kapiteln beschriebe- nen Aktivitäten orientieren sich dabei an mehreren Literaturquellen, um den Softwareentwick- lungsprozeß möglichst optimal auf die bestehende Problemstellung anzupassen. Im einzelnen sind dies die Arbeiten von BALZERT, H. (1982, 1996, 1998); BLÜMMEL, B. u. DE VRIES, A. (2005); BORTFELD, A. (2001); GEHRING, H. u. HOMBERGER, J. (1993); GEHRING, H. (1993); HEUER, A. u. SAAKE, G. (2000); PAGEL, B.-U. u. SIX, H.-W. (1994); WEDEKIND, H. (1973); ZEHNDER, C. A. (2002). Abgeschlossen wird die Arbeit mit einer kurzen Zusammenfassung.

Kapitel 2 Datenbanken

2.1 Historische Entwicklung

Wie bereits in dem Einleitungskapitel erwähnt, gaben die Nachteile der konventionellen betrieblichen Datenverarbeitung den Anstoß für die Entwicklung der Datenbank-Technologie. Präziser läßt sich die Entwicklung der Datenverarbeitung in drei Entwicklungsstufen unterteilen, die jeweils mit entsprechenden technischen Fortschritten einhergehen.

In der Anfangszeit wurden die Daten von jedem Anwendungsprogramm in sequentiellen Datei- en verwaltet, die exklusiv einem Programm zugeordnet sind (GEHRING, H. u. HOMBERGER, J. (1993, KE1 S.8-11)). In diesen entspricht die logische Datenstruktur der physischen Speicher- reihenfolge. Die Datendefinitionen und alle Befehle zur Dateimanipulation werden direkt in den Anwendungsprogrammen gespeichert. Mit diesem Verfahren sind somit weder Redundan- zen noch Inkonsistenzen auszuschließen. Zudem ist die physische Datenabhängigkeit extrem inflexibel, da Erweiterungen und Änderungen immer Anpassungen sowohl des Programms als auch der zugehörigen Dateien erfordern.

Die Ablösung der Magnetbänder durch die leistungsfähigeren Direktspeicher (Festplatten) En- de der 1960er Jahre, welche hardwareunabhängige (z.B. serielle oder direkte) Dateizugriffe ermöglichen, führte zum Einsatz der ersten Dateiverwaltungssysteme (GEHRING, H. u. HOM- BERGER, J. (1993, KE1 S.12-14); JOHANNES, H. (2002, KE1 S.11)). Bei diesen wird die Dateiverwaltung aus den Anwendungssystemen ausgelagert und zentralisiert. Die Verwendung interner Zugriffsunterstützungs-Techniken, wie z.B. B*-Bäume oder Hashing, ermöglichen Da- teiverwaltungssystemen einen deutlich schnelleren Zugriff auf die Daten. Es existiert jedoch weiterhin keine einheitliche Datenbasis, da verschiedene Dateiformate nebeneinander vorlie- gen. Somit können Inkonsistenzen und Redundanzen nur für Anwendungen gemildert werden, die auf die gleichen Dateien zugreifen. Ebenso besteht weiterhin das Problem der physischen Datenabhängigkeit, welches sich hier sogar noch schlimmer auswirkt, da mehrere Anwendungs- programme auf die selben Dateien zugreifen. Trotzdem haben sich bei kleineren Datenmengen, überwiegend sequentiellem Zugriff oder rein administrativen Aufgaben Dateiverwaltungssysteme bis heute bewährt und sind noch vielfach im Einsatz.

Diese Defizite führten zur Entwicklung der Datenbank-Technologie, deren Nutzung besonders durch die in den 1980er Jahren zunehmende Vernetzung der PCs vorangetrieben wurde. Die grundlegenden Konzepte wurden mehr als ein Jahrzehnt vorher entwickelt. Den Anfang mach- ten 1968 IBM mit dem hierarchischen Datenmodell und die Gruppe Conference on Data Sy- stems Language - Data Base Task Group (CODASYL-DBTG) mit dem netzwerkartigen Da- tenmodell (GEHRING, H. u. HOMBERGER, J. (1993, KE1 S.7f.)). Diese wurden relativ schnell durch das relationale Datenmodell verdrängt, welches 1970 von CODD, E. F. (1970, 1990) ent- wickelt und als System R experimentell umgesetzt wurde. So wurde das von der Firma Ashton- Tate entwickelte relationale Datenbanksystem (RDBS) dBase zu einem Quasistandard für PCs und besaß beispielsweise in der Bundesrepublik Deutschland in der zweiten Hälfte der 1980er Jahre einen Marktanteil von 60% bis 70% bei den PC-Datenbanksystemen (LEE, D. (2007, S.59); KAMMER, W. (1991)).

Gegenwärtig sind DBSe aus der betrieblichen Praxis nicht mehr wegzudenken. Sie werden überall eingesetzt, wo größere Datenmengen zu verwalten sind und einem oder mehreren Benutzern zur Verfügung gestellt werden müssen. Die Möglichkeiten reichen dabei von speziellen Anwendungen für Auftragsbearbeitung, Fakturierung, Materialwirtschaft, Vertriebsunterstützung, CAD oder Meßdatenverarbeitung über Buchungs- und Verwaltungssysteme bis zu leistungsstarken Informationssystemen zur Unterstützung sämtlicher Vorgänge eines Unternehmens (z.B. SAP R/3). Gerade bei größeren Unternehmen existieren aufgrund historisch gewachsener Rechnerstrukturen häufig mehrere DBVSe auf unterschiedlichen Rechnerebenen, deren Integration jedoch nicht immer gut gelöst ist (JOHANNES, H. (2002, S.14f.)).

2.2 Datenbankkonzept

2.2.1 Datenbankarchitektur

Grundlegend für das Datenbankkonzept ist die anwendungsübergreifende Denkweise, welche eine Modellierung der Datenwelt des gesamten Unternehmens vorsieht. Nicht mehr jede Anwendung soll spezielle Daten haben, sondern eine zentrale Datenhaltung ist zu realisieren. Das Hauptproblem der Dateiverwaltungssysteme, die physische Datenabhängigkeit, wird im Datenbankkonzept durch ein Zwei-Schichten-Konzept bewältigt. Dies trennt strikt zwischen der Handhabung der Daten auf logischer Ebene, der sogenannten „externen Schicht“, und der physischen Speicherung und Manipulation, der sogenannten „internen Schicht“.

Für jedes Anwendungsprogramm existiert im Zwei-Schichten-Konzept jeweils eine Benutzer- sicht, die durch ein externes Datenmodell bzw. Datenschemata gebildet wird. Die externen Schemata orientieren sich dabei an den Bedürfnissen der jeweiligen Benutzer und bilden die ex- terne Schicht. An die externe Schicht grenzt die interne Schicht an, welche die Benutzersichten der externen Schicht inhaltlich durch das interne Datenmodell bzw. Datenschema abdeckt. Kon- kret legt das interne Schema die physische Organisation der logischen Datenstrukturen auf dem Speichermedium fest. Die Speicherstruktur der Datenbank bleibt den Benutzern dadurch unbe- kannt. Die Verbindung zwischen den Daten in der Datenbank und den Anwendungssystemen wird durch das DBVS hergestellt, welches die logischen Anforderungen der Anwendungspro- gramme in physische Speicheroperationen transformiert. Es entkoppelt somit die interne und externe Schicht, so daß die physische Datenunabhängigkeit realisiert werden kann.

Logische Datenunabhängigkeit wird durch das Zwei-Schichten-Konzept jedoch nicht gewähr- leistet. Sofern neue Anwendungsprogramme hinzukommen, deren Datenanforderungen von den bisherigen externen Datenmodellen nicht abgedeckt werden, sind Änderungen an den bestehen- den Datenmodellen notwendig, die dann wiederum Änderungen an den bestehenden Anwen- dungssystemen zur Folge haben können. Das Drei-Schichten-Konzept vermeidet dieses Pro- blem durch das Einfügen einer zusätzlichen Abstraktionsebene, der sogenannten „konzeptio- nellen Schicht“, zwischen der externen und internen Schicht. Das zugrunde liegende konzeptio- nelle Datenmodell stellt den gesamten Ausschnitt aus der realen Welt dar. Die Benutzersichten der externen Schicht sind jeweils Ausschnitte des konzeptionellen Modells, die für die jewei- lige Benutzergruppe relevant sind. Die logische Gesamtsicht bleibt dabei den Benutzern ver-

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Datenbankebenen im ANSI-Architekturmodell nach GEHRING, H. u. HOMBERGER, J. (1993, KE1 S.23). Die Beschreibung der jeweiligen Ebenen ist durch die jeweiligen Datenmodelle gegeben.

borgen. Die Isolation der externen Schemata von dem konzeptionellen Schema macht es mög- lich die Daten in dem konzeptionellen Schema unabhängig von den Anwendungsprogrammen zu verwalten, so daß nun sowohl physische als auch logischen Datenunabhängigkeit gewährlei- stet wird. Für das konzeptionelle Datenmodell wird entweder das hierarchische, netzwerkartige oder relationale Datenmodell verwendet, welche im nächsten Abschnitt näher vorgestellt wer- den. Für das DBVS steigt in dem Drei-Schichten-Konzept der Aufwand, da es eine zweistufige Transformation von der internen über die konzeptionelle in die externe Schicht vornehmen muß. Aufgrund seiner Vorteile wurde das 3-Schichten-Konzept 1975 in das auch heute noch gültige ANSI-Architekturmodell aufgenommen (siehe ANSI (1975) und Abbildung 2.1). Neben der Trennung in die drei Schichten, die dort als Ebenen bezeichnet werden, sieht das ANSI-Archi- tekturmodell spezielle Sprachen für die Datenbeschreibung und personelle Instanzen für jede der Ebenen vor, welche in Tabelle 2.1 aufgeführt werden.

Der Zugriff der Anwendungen auf die Datenbank erfolgt mit speziellen Datenmanipulationssprachen (DML), welche oft in andere Programmiersprachen eingebettet sind.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.1: Wesentliche Merkmale des ANSI-Architekturmodells. Da die externen Datenschemata nur Subschemata des konzeptionellen Schema sind, werden für diese die selben Sprachmittel verwendet.

2.2.2 Datenbankverwaltungssystem

Von zentraler Bedeutung für die Mehr-Schichten-Architektur ist das DBVS, welches die Ver- bindung zwischen der Datenbank und den Anwendungssystemen herstellt. In der Literatur wird anstelle von DBVS auch der synonyme Begriff Datenbankmangementsystem (DBMS) verwen- det (CODD, E. F. (1985b, a)). Durch das DBVS präsentiert sich die Datenbank dem Benutzer als abstrakter Speicher, welcher die Daten nicht durch ihre physische Speicher-Organisation, sondern auf der logischen Ebene beschreibt. Da ausschließlich das DBVS auf der Datenbank operiert, muß es folgende Aufgaben erfüllen können (GEHRING, H. u. HOMBERGER, J. (1993, KE1 S.33):

- Daten speichern und entsprechende Zugriffspfade anlegen
- Datenbankoperationen ausführen (lesen,ändern, löschen, usw.)
- Transformation zwischen den Datenbankebenen (ES/KS-Trafo zwischen den externen Schemata und dem konzeptionellen Schema und KS/IS-Trafo zwischen dem konzeptionellen und internen Schema)
- Synchronization der Benutzeraktivitäten
- Prüfung Zugangsberechtigungen der Benutzer
- Protokollieren aller Datenbankvorgänge und Fehler

Im Normalfall ist ein DBVS eine systemnahe Anwendung und setzt direkt auf das Betriebssy- stem auf. Die Kombination aus der Datenbank mit den gespeicherten Daten und dem DBVS bildet ein DBS. Während ein DBS nach dem ANSI-Architekturmodell in drei Schichten aufge- baut ist (vgl. Abschnitt 2.2.1), wird zur Beschreibung der Realisierung eines DBVS ebenfalls ein Mehr-Schichten-Modell verwendet. Am bekanntesten ist das Fünf-Schichten-Modell, welches einen Kompromiß aus der Forderung nach Datenunabhängigkeit und zugleich möglichst effi- zienter Ausführung von Datenbank-Operationen darstellt. Als oberste Schicht dient eine men- genorientierte Datenbank-Schnittstelle für die Ebene der logischen Datenstrukturen, welche Zu- griffsmöglichkeiten über deskriptive Sprachen (z.B. Structured Query Language (SQL)) bietet. Die nächste Ebene wird durch eine satzorientierte Datenbank-Schnittstelle zur Verfügung ge- stellt und realisiert die logischen Zugriffspfade. Die konkreten Speicherstrukturen (interne Sät- ze und physische Zugriffspfade) folgen als interne Satz-Schnittstelle in der nächsten Schicht. Die Ebene der Seitenzuordnungsstrukturen realisiert die Datenbank-Puffer-Schnittstelle, wel- che Segmente mit sichtbaren Seitengrenzen als lineare Addressräume im Datenbank-Puffer zur Verfügung stellt. Die unterste Schicht, welche die Speicherzuordnungsstrukturen verkör- pert, bildet die Dateischnittstelle, auf der von konkreten Gerätecharakteristika wie Speichertyp, Zylinder- oder Spuranzahl, etc. abstrahiert wird. Dies stellt die Verbindung zur Schnittstelle des Geräts her, welches zur Speicherung der Daten eingesetzt wird (z.B. einer Festplatte).

Für weitergehende Informationen zu DBVSen wird auf JOHANNES, H. (2002, S.103-107) und insbesondere zum Fünf-Schichten-Modell auf HÄRDER, T. u. RAHM, E. (2001) verwiesen.

2.2.3 Vor- und Nachteile des Datenbankkonzepts

Zusammenfassend bietet das Datenbankkonzept folgende Vorteile:

- zentral in der Datenbank gespeicherte, gering redundante Daten (nur durch Verarbeitungseffizienz begründete Redundanzen)
- synchronisierter gleichzeitiger Mehrbenutzerzugriff auf die Daten ist möglich
- hohe Datensicherheit durch zentrale Zugriffsberechtigungssysteme
- Erhaltung der Konsistenz und Integrität der Daten durch zentrale Prüfung (in der Regel durch in den Datenmodellen vorhandene Bedingungen) (siehe auch Abschnitt 2.5)
- Elimination von physischen und logischen Datenabhängigkeiten durch Mehr-Schichten- Architektur, um eine flexible Erweiterbarkeit der Datenbankstruktur sicher zu stellen
- Elimination von Inflexibilitäten durch Benutzersichten
18 DATENBANKEN
- zuverlässiges Recovery nach DBVS-Abstürzen und Festplattenfehlern durch Protokolldateien, Transaktionskonzept und Backupdateien (siehe auch Abschnitt 2.5)
- mächtige Datenbanksprachen als Schnittstelle zu Anwendungen (z.B. SQL).

Hauptsächlich aufgrund der hohen Komplexität von DBSen resultieren jedoch auch einige Nachteile des Datenbankkonzepts (GEHRING, H. u. HOMBERGER, J. (1993, KE1 S.19f.)):

- für Einrichtung und Betrieb sind hoch qualifizierte Fachkräfte erforderlich
- Verwaltungsaufwand steigt, so daß die Verarbeitungseffizienz sinkt
- DBSe erfordern einen hohen Systemaufwand in Bezug auf Hardware und Software
- es besteht das Risiko des Totalverlusts aller Daten, falls der Datenschutz oder die Datensicherung versagt
- die Datenbank-Benutzer sind abhängig von der zentralen Datenbank-Instanz (beispielsweise in Bezug auf bereitgestellte Abfragesprachen, Geräteschnittstellen, usw.).

2.3 Datenmodelle

Zur Beschreibung der Daten der konzeptionellen Ebene verwenden DBVSe unterschiedliche Datenmodelle. Es wird zwischen den klassischen Datenmodellen, zu denen das hierarchische, das netzwerkartige und das relationale Datenmodell gehören, und dem objektorientierten Datenmodell unterschieden. Das gegenwärtig dominierende relationale Datenmodell wird wegen seiner Bedeutung in dem separaten Abschnitt 2.4 erläutert.

Unterschieden wird zudem zwischen DBVS-gestützten Datenmodellen, welche die Restriktio- nen des jeweiligen DBVS beachten, und allgemeinen Datenmodellen, welche die Datenwelt ei- nes Realitätsausschnitts semantisch vollständig wiedergeben (GEHRING, H. u. HOMBERGER, J. (1993, KE2 S.6)).

2.3.1 Grundelemente

Den klassischen Datenmodellen sind die Grundelemente „Entitäten“, „Attribute“, „Beziehun- gen“ und „Schlüssel“ gemeinsam. Unter einer Entität versteht man ein Element der Datenwelt, das ein reales oder gedankliches Phänomen im betrachteten Realitätsausschnitt repräsentiert (GEHRING, H. u. HOMBERGER, J. (1993, KE2 S.7)). Jede Entität besteht aus einem oder meh- reren Attributen, die die Eigenschaften der Entität beschreiben und aus einem Namen und einem Wert bestehen. Um eine Entität zu identifizieren, wird eine minimale Teilmenge der Attribute als eindeutiger Primärschlüssel bzw. Identifikationsschlüssel definiert. Die Zusammenfassung von Entitäten mit gleichen Attributen, jedoch nicht zwingend gleichen Attributwerten, wird En- titätsmenge genannt. Es können disjunkte, überlappende und umschließende Entitätsmengen

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.2: Die Assoziationstypen der Datenmodellierung nach ZEHNDER, C. A. (2002, S.65).

auftreten. Beziehungen zwischen Entitäten werden aus einer Assoziation a (Ei, Ek), welche angibt wie viele Entitäten der Entitätsmenge Ek einer beliebigen Entität der Entitätsmenge Ei zugeordnet sind, und der zugehörigen Gegenassoziation a (Ek, Ei) gebildet. Die Assoziationen können einen von vier möglichen Typen, die in Tabelle 2.2 aufgeführt werden, annehmen, so daß sich insgesamt 10 Beziehungstypen ergeben.

2.3.2 Hierarchisches Datenmodell

Das hierarchische Datenmodell (GEHRING, H. u. HOMBERGER, J. (1993, KE2 S.21-26); JO- HANNES, H. (2002, S.15f.)) orientiert sich an den in der Realität häufig vorkommenden hierar- chischen Strukturen (z.B. Stücklisten). Es kann anhand von drei Merkmalen beschrieben wer- den:

- Die Spitze der Hierarchie bildet genau eine Entitätsmenge, welcher keine andere Entitätsmenge übergeordnet ist („Vater“).
- Allen anderen Entitätsmengen ist genau eine Entitätsmenge übergeordnet.
- Jeder Entitätsmenge können beliebig viele Entitätsmengen direkt untergeordnet sein („Söhne“).

Erlaubt sind im hierarchischen Datenmodell nur die vier 1: x -Beziehungstypen (x =1, c, m, mc). Eine einfache Darstellung für ein hierarchisches Datenmodell ist ein Baum mit der Vater-Entität als Wurzel.

Hierarchische Strukturen erweisen sich durch ihre sequentielle Darstellbarkeit besonders gut für eine sequentielle Verarbeitung. Zudem wird eine sehr effiziente Auswertung entlang der Hierarchiepfade ermöglicht. Problematisch am hierarchischen Datenmodell sind einerseits die semantische Armut, da nur 1: x - Beziehungstypen erlaubt sind, und zudem die, aus strukturellen Gründen entstehende, Datenredundanz und geringe Auswertungsflexibilität entlang der Nicht- Hierarchiepfade. Ein Beispiel für ein hierarchisches DBS ist das Information Management System (IMS) von IBM (MELTZ, D. u. a. (2004)), welches bei Banken und Versicherungen bis heute weit verbreitet ist.

2.3.3 Netzwerkartiges Datenmodell

Beim netzwerkartigen Datenmodell (GEHRING, H. u. HOMBERGER, J. (1993, KE2 S.31-39)) wird das hierarchische Modell um netzwerkartige Strukturen erweitert, so daß die Beschrän- kung auf nur vier Beziehungstypen wegfällt. Damit dürfen alle Entitäten mehrere Vorgänger und Nachfolger haben. Nicht mehr möglich ist die sequentielle Darstellung, so daß gemeinsa- me Attribute oder Zeiger für die Darstellung der Netzwerke verwendet werden. Seit den 1990er Jahren ist die Bedeutung dieses Datenmodells stark zurückgegangen und es wird gegenwär- tig hauptsächlich noch auf Großrechnern eingesetzt. Ein Beispiel für ein netzwerkartiges DBS ist das Universal Datenbank System (UDS) von Siemens, welches inzwischen in der Version UDS/SQL V2.4 zusätzlich das relationale Datenmodell beinhaltet (FUJITSU SIEMENS COM- PUTERS (2004); KOTZIAS, K. (2004); FUJITSU SIEMENS COMPUTERS (2007)).

2.3.4 Objektorientiertes Datenmodell

Eine neuere Entwicklung ist das objektorientierte Datenmodell (JOHANNES, H. (2002, S.16)), welches als zentrale Bauelemente Objekte und diese näher beschreibende Attribute verwen- det. Dabei werden die grundlegenden Konzepte der Objektorientierung unterstützt (z.B. Kapse- lung oder Vererbung), um den Datenbankentwurf natürlicher und konsistenter machen. Obwohl derzeit die RDBSe vorherrschen, scheint es, aufgrund der starken Verbreitung von objektori- entierten Programmiersprachen, nur noch eine Frage der Zeit, bis sich objektorientierte DBSe am Markt etabliert haben. Sehr häufig verfügen objektorientierte DBSe auch über einen rela- tionalen Teil, um entsprechende Kompatibilität zu erreichen. Dies ist relativ einfach zu reali- sieren, da zwischen beiden Datenmodellen viele Entsprechungen identifiziert werden können. Beispielsweise entspricht das Objekt der Entität. Diese DBSe werden „Objektrelational“ ge- nannt (ASSFALG, R. u. a. (1998, S.91)).

2.4 Relationales Datenmodell

2.4.1 Klassisches Relationenmodell

Das relationale Datenmodell basiert auf dem Relationenmodell von CODD, E. F. (1970), welcher unter einer Relation eine Anordnung von Daten mit bestimmten Eigenschaften versteht. Der Vorteil dieses Datenmodells ist die mathematisch klare Darstellbarkeit mittels der Relationenalgebra. Datenmodelle, welche die Operationen der Relationenalgebra in Tabelle 2.3 unterstützen, werden als relational vollständig bezeichnet. Durch Implementierung des relationalen Datenmodells werden zu den Operationen der Relationenalgebra noch die Grundoperationen (Einfügen, Ändern, Löschen, etc.) hinzugefügt.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.3: Operationen der Relationenalgebra.

In der Regel werden diese Operationen in Form einer Abfragesprache durch das DBVS zur Verfügung bestellt, deren am weitesten verbreiteter Vertreter SQL ist.

Mengentheoretisch wird eine Relation folgendermaßen definiert (GEHRING, H. u. HOMBERGER, J. (1993, KE2 S.40)):

Eine Relation R ist eine Teilmenge des kartesischen Produkts der nicht zwingend disjunkten Wertebereiche Wi mit n Attributen Ai, i = 1 , . . . , n: R ⊂ W 1 × W 2 × ... × Wn. Die Relation R stellt somit eine Menge von n -Tupeln dar: R = (w 1 ,w 2 ,...,wn) |wi ∈ Wi,i = 1 ,...,n.

Der Begriff „n-Tupel“ repräsentiert dabei eine Anordnung von n Einzelwerten, die den Wertebereichen der n Attribute der Relation entnommen sind. Der Grad der Relation, daß heißt die Anzahl der in der Relation enthaltenen Attribute, wird durch den Wert n bestimmt.

Eine Relation wird im relationalen Datenmodell als zweidimensionale Tabelle dargestellt. Die- se ist die einzige Datenstruktur, so daß sowohl die Informationen als auch die Beziehungen ausschließlich über Tabellenwerte erfolgt. Die Behandlung von Beziehungen wird dadurch sehr einfach, indem Beziehungen durch gleiche Attribute in zwei Tabellen ausgedrückt werden.

Die Zeilen einer Tabelle enthalten genau einen Datensatz, der einem Tupel entspricht. Jede Zeile ist eindeutig innerhalb einer Tabelle und besitzt eine minimale Attributkombination als eindeutigen „Schlüsselkandidaten“. Um zu umfangreiche Attributkombinationen als Schlüssel- kandidaten zu vermeiden, kann ein künstlicher Schlüsselkandidat eingeführt werden (z.B. eine laufenden Nummer pro Datensatz). Die Anordnung von Zeilen und Spalten einer Tabelle ist aufgrund des Relationencharakters beliebig. Häufig werden auch die Begriffe „Satz“ für Zeile und „Feld“ für Spalte verwendet.

2.4.2 Normalisierung

Um Redundanzfreiheit zu erreichen, gibt es für relationale Datenmodelle den Prozeß der Nor- malisierung (GEHRING, H. u. HOMBERGER, J. (1993, KE2 S.46-53); JOHANNES, H. (2002, S.35-38); ZEHNDER, C. A. (2002, S.77-83)). Konkret werden dabei die Attribute einer Relation in Bezug auf ihre Abhängigkeit analysiert und unerwünschte Abhängigkeiten, durch sukzessive Auslagerung von Attributen in neue oder andere bestehende Relationen, entfernt. Die neuen Relationen entstehen, damit bei der Normalisierung kein Informationsverlust auftritt. Neben der Redundanzfreiheit verhalten sich die Relationen nach der Normalisierung inkonsistent ge- genüber dem Auftreten von „Anomalien“ bei Mutationsoperationen wie Einfügen, Ändern oder Löschen. Der Prozeß der Normalisierung erfolgt in mehreren Stufen, die jeweils zur n -ten Nor- malform der Relationen führen. Während von CODD, E. F. (1970) ursprünglich neun Normal- formen beschrieben werden, ist für die Problemstellungen der Wirtschaftsinformatik die dritte Normalform bereits ausreichend. Die höheren Normalformen erzeugen viele kleine Relationen. Um die für die Anwendungen benötigten Informationen zu liefern, müssen dann Verbünde ge- bildet werden, die zu einer unvorteilhaften deutlichen Verminderung der Performance führen.

Die ersten drei Normalformen werden folgendermaßen definiert, wobei generell gilt, daß die n -te Normalform die n − 1-te beinhaltet:

1. Normalform: Die Relation enthält nur atomare Attributwerte.
2. Normalform: Die Relation hat nur Nichtschlüsselattribute, die vollfunktional vom Schlüs- selkandidaten abhängen.
3. Normalform: Die Relation hat nur Nichtschlüsselattribute, die nicht transitiv vom Schlüs- selkandidaten abhängen.

Erst die Normalisierung bis zur dritten Normalform stellt sicher, daß keine konsistenzverletzenden Mutationsanomalien mehr auftreten und nur noch Redundanzen vorhanden sind, die zur inhaltlichen Verknüpfung der Relationen dienen, daß heißt für Beziehungen notwendig sind. Zum besseren Verständnis der Definitionen wird nachfolgend eine Erläuterung der Begriffe der funktionalen, vollfunktionalen und transitiven Abhängigkeit vorgenommen:

Funktionale Abhängigkeit: Ein Attribut (bzw. eine Attributkombination) B ist von einem At- tribut (bzw. einer Attributkombination) A funktional abhängig, wenn in einer Relation zu einem beliebigen Wert von A maximal ein Wert von B existiert.

Vollfunktionale Abhängigkeit: Ein Attribut (bzw. eine Attributkombination) B ist von einem Attribut (bzw. eine Attributkombination) A vollfunktional abhängig, wenn es vom ge- samten Attribut A funktional abhängig ist und nicht nur von einem Teil von A. Transitive Abhängigkeit: Ein Attribut (bzw. eine Attributkombination) C ist von einem Attri- but (bzw. einer Attributkombination) A transitiv abhängig, wenn ein Attribut (bzw. eine Attributkombination) B von A funktional abhängig ist und C von B funktional abhängig ist.

Eine graphische Darstellung eines relationalen Datenmodells kann in expliziter Relationenschreibweise (Beispiel siehe Abbildung 4.7 auf Seite 65) oder als Entity-Relationship- Diagramm, welches im nächsten Abschnitt vorgestellt wird, erfolgen.

2.4.3 Entity-Relationship-Modell

Eine weitere Möglichkeit neben der Normalisierung für den Entwurf eines relationalen Datenmodells, ist das 1975 von CHEN, P. P. (1975, 1976, 1981) vorgestellte Entity-Relationship- Modell (ERM), welches sich in der Folgezeit als Marktstandard etabliert hat. Das ERM wurde unter anderem von dem „Entity Set Model“ von SENKO, M. E. u. a. (1973) und der Beschreibung von Beziehungen durch Abrial ABRIAL, J.-R. (1974) stark beeinflußt. Der Einsatz des ERMs ist für alle Datenmodelle möglich. Der Vorteil bei der Anwendung auf relationale Datenmodelle ist die direkte Interpretation von Entitäten als Relationen.

Unter dem ERM versteht man eine Art formale Sprache für den Entwurf von Datenbanken. Die beiden zentralen Bestandteile sind Entitäten (entity) und Beziehungen (relationship). Das ERM ist im Gegensatz zur Normalisierung, welche ein Bottom-Up-Ansatz ist, ein Top-down- Ansatz (BORTFELD, A. (2001, KE1 S.40f.)) zum Entwurf, daß heißt die Entwicklung erfolgt vom Ganzen zum Detail.

Zur Bildung eines ERMs werden zunächst die „starken“ und die „schwachen“ Entitäten ermit- telt. Vereinfacht ausgedrückt sind starke Entitäten solche, die eigenständig existieren können, während die schwachen Entitäten den starken als Attribute zugeordnet werden. Anschließend muß jeder Entitätsmenge ein eindeutiges Attribut (bzw. eine eindeutige Attributkombination) als Primärschlüssel zugeordnet werden. Der Primärschlüssel entspricht dem Schlüsselkandidat des relationalen Datenmodells.

Beziehungen zwischen zwei Entitäten werden mit Hilfe der Primärschlüssel realisiert. Bei einer 1: mc -Beziehung wird beispielsweise der Primärschlüssel aus der Entitätsmenge 1 als ein Attribut in der Entitätsmenge mc verwendet. Dieses Attribut wird in der Entitätsmenge mc Fremdschlüssel genannt. Visualisiert werden die Beziehungen zwischen den Entitätsmengen mittels eines Entity-Relationship-Diagramms. Eine gebräuchliche Notation ist dabei die aus TEORY, T. J. (1998), welche auf CHEN, P. P. (1976) zurückzuführen ist und beispielhaft für eine Beziehung in Abbildung 2.2 dargestellt wird.

Vorteilhaft ist, daß das ERM nach Elimination nichthierarchischer Beziehungen eine Ta- bellenstruktur erzeugt, welche sich in der dritten Normalform befindet. Deshalb kann beim

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Grafische Darstellung einer Beziehung zwischen zwei Entitätsmengen.

Datenbank-Entwurf beispielsweise zunächst die ERM-Methode benutzt werden, um dann das Ergebnis mit der Normalisierung zu überprüfen. Ausführlichere Darstellungen des ERMs las- sen sich exemplarisch HEUER, A. u. SAAKE, G. (2000, S.55-72) oder JOHANNES, H. (2002, S.23-35) entnehmen.

2.4.4 Erweitertes Relationenmodell

Neben der Normalisierung existieren mit den sogenannten „Strukturregeln“ noch weitere Güte- kriterien für ein Relationenmodell. Diese bauen auf dem klassischen Relationenmodell und dem ERM auf und bilden sogenannte „Erweiterte Relationenmodelle“ (ELMASRI, R. u. a. (1985); ENGELS, G. u.a. (1992); GOGOLLA, M. (1994); HOHENSTEIN, U. (1993); THURNHERR, B. (1980); ZEHNDER, C. A. u. THURNHERR, B. (1979)). Primär wurde der Ansatz entwickelt, um diverse Schwachstellen zu beseitigen, die ein relationales Datenmodell selbst in der drit- ten Normalform noch besitzt. Dazu gehören Redundanzen bei überlappenden Entitätsmengen, fehlende referentielle Integrität und begrenzte Modellierungsgenauigkeit (z.B. bei Ober- und Untermengenbeziehungen) (GEHRING, H. u. HOMBERGER, J. (1993, KE2 S.54); HEUER, A. u. SAAKE, G. (2000, S.73)).

Folgt man den Ausführungen von GEHRING, H. u. HOMBERGER, J. (1993, KE2 S.55-74) lassen sich folgende Strukturregeln anführen:

Strukturregel 1: Jede Relation, die eine Entitätsmenge beschreibt, muß einen Identifikations- schlüssel aufweisen.

Strukturregel 2: Eine Datenbasis muß aus Relationen in der dritten Normalform bestehen, welche ausschließlich aus globalen und lokalen Attributen gebildet werden. Strukturregel 3: Für jedes lokale Attribut ist statischer Wertebereich zu definieren. Jedem glo- balen Attribut darf nur in der Relation ein statischer Wertebereich zugrundeliegen, in der das Attribut Teil des Identifikationsschlüssel ist. In anderen Relationen darf das Attribut nur als Fremdschlüssel mit einem dynamischen Wertebereich eingebracht werden. Strukturregel 4: Rekursive Beziehungen zwischen Relationen sind nicht zulässig. In einer Re- lation R 1 darf ein globales Attribut nur mit einem Fremdschlüssel gebildet werden, des- sen zugehöriger Primärschlüssel aus einer von R 1 unabhängig definierten Relation R 2 stammt.

Strukturregel 5: Ober- und Untermengenbeziehungen zwischen Relationen sind präzise dar- zustellen. Die Zuordnung einer Entität zu disjunkten spezialisierten Untermengen wird durch ein diskriminierendes Attribut in der generalisierten Relation ausgedrückt. Strukturregel 6: Die globalen Attribute einer Relation, die nicht auf statischen Werteberei- chen basieren, sind als Fremdschlüssel aus denjenigen Relationen einzuführen, welche die größtmögliche Einschränkung der zulässigen Werte bewirken.

Unter einem globalen Attribut versteht man ein Attribut, das in mindestens einer Relation im Identifikationsschlüssel auftaucht, während ein lokales Attribut nur in einer Relation auftauchen darf und nicht Teil eines Identifikationsschlüssels sein darf. Ein lokales Attribut kann somit nie Redundanzen hervorrufen.

Zudem ist für das erweiterte Relationenmodell die Einhaltung der referentiellen Integrität bei Beziehungen wichtig, welche zu jedem Wert eines Fremdschlüssels immer den gleichen Wert eines Primärschlüssels garantiert. Diese Art der Realisierung von Beziehungen hat zur Fol- ge, daß alle nichthierarchischen Beziehungstypen mittels Hilfsrelationen in hierarchische 1: x - Beziehungen umgewandelt werden müssen. Eine Datenbasis, welche die Strukturregeln erfüllt wird nach ZEHNDER, C. A. u. THURNHERR, B. (1979) als global normalisiert bezeichnet.

2.4.5 Codd’s Regeln

Trotz des grundlegenden Papiers von CODD, E. F. (1970) über die Relationenstruktur existier- te lange Zeit keine Übereinkunft darüber welche Eigenschaften ein Datenmodell mindestens aufweisen muß, um den relationalen Datenmodellen zugerechnet werden zu können. Daher de- finierte Codd 1985 zwölf Regeln für ein relationales DBVS(CODD, E. F. (1985b, a); DATE, C. J. (1990, S.389ff.)):

Regel 1: Informationsregel (Information Rule) Alle Informationen, die in einer relationalen Datenbank gespeichert sind, werden durch Werte in Tabellen dargestellt. Regel 2: Garantierte Zugriffsregel (Guaranteed Access Rule) Alle Werte einer relationalen Datenbank müssen über Tabellenname, Spaltenname und den Wert des Primärschlüssels, daß heißt auf logischer Ebene, eindeutig identifizierbar sein.

Regel 3: Systematische Behandlung von Null Werten (Systematic Treatment of Null Va- lues) Nullwerte werden datentypunabhängig als unbekannte Daten ohne Wert verarbeitet. Regel 4: Dynamischer relationaler Online-Datenkatalog (Dynamic On-line Catalog Based on the Relational Model) Die Datenbank wird in Bezug auf ihre Struktur und ihren Inhalt als Tabellen in einem Online-Datenkatalog (data dictionary) beschrieben. Regel 5: Umfassende Datensprache (Comprehensive Data Sublanguage Rule) Ein relatio- nales DBVS muß mindestens eine Sprache mit vollständigen Befehlssatz für Autorisie- rung, Datendefinition, Datenmanipulation, Integritätsregeln und Transaktionsverwaltung besitzen.

Regel 6: Aktualisierbare Sichten (View Updating Rule) Die Inhalte von Tabellen müssen sich über Sichten (view) bearbeiten lassen, sofern dies theoretisch möglich ist. Regel 7: Unterstützung High Level Setbasierter oder relationaler Operationen (High- level Insert, Update and Delete) Die grundlegenden Operationen der Relationenalgebra müssen unterstützt werden.

Regel 8: Physische Datenunabhängigkeit (Physical Data Independence) Physische Daten- unabhängigkeit muß gegeben sein.

Regel 9: Logische Datenunabhängigkeit (Logical Data Independence) Logische Datenun- abhängigkeit muß gegeben sein.

Regel 10: Integritätsunabhängigkeit (Integrity Independence) Integritätsbedingungen dür- fen ausschließlich über die Sprache des DBVS definiert werden und müssen zur Laufzeit durch das DBVS geprüft werden.

Regel 11: Verteilungsunabhängigkeit (Distribution Independence) Der logische Zugriff auf die Daten ist unabhängig davon, ob die Datenbank lokal oder in Form einer verteilten Datenbank gespeichert ist.

Regel 12: Nichtgefährdungsregel (Nonsubversion Rule) Die Datenintegrität darf nicht durch Low-Level-Sprachen unterwandert werden.

Zusätzlich hat Codd noch die Regel 0 definiert, welche besagt, daß ein relationales DBVS eine Datenbank vollständig mit seinen relationalen Fähigkeiten verwalten kann. Codd selber mußte bis zu seinem Tod einräumen, daß diese Forderungen so streng sind, daß kein existierendes relationales Datenbanksystem sie vollständig erfüllt. Insbesondere die Regeln 6, 9, 10, 11 und 12 sind schwer zu erfüllen (KALIS, F. (2004)). 1990 hat Codd seine Regeln in 333 Regeln differenziert, die bis heute allgemeine Akzeptanz gefunden haben (CODD, E. F. (1990)).

Es existieren viele Beispiele für moderne DBVSe, die das relationale Datenmodell unterstützen. Am bekanntesten und umsatzstärksten sind die Systeme Oracle, DB2 von IBM oder Microsoft SQL Server (SCHULZE, J. (2006)). Eine umfassende Übersicht von relationalen DBVSen kann JOHANNES, H. (2002, S.104) entnommen werden.

2.5 Datenintegrität

Bereits bei der Beschreibung der Datenmodelle war die Erhaltung der Datenintegrität von großer Bedeutung. Dies gilt insbesondere auch für den Betrieb der Datenbank. Für die weitere Beschreibung sind drei Ebenen der Datenintegrität zu unterscheiden, die jeweils unterschiedliche Probleme aufwerfen:

Datenkonsistenz betrifft die logische Richtigkeit und Widerspruchsfreiheit der Daten. Eine Datenbank ist konsistent, wenn sie den Konsistenzregeln des konzeptionellen Schemas genügt.

Datensicherheit betrifft die physische Sicherung der Daten während des Betriebs der Daten- bank in Bezug auf technische und organisatorische Aspekte. Konkrete Beispiele sind der Schutz vor Verlust, Verfälschung, Beschädigung und unerlaubten Zugriff. Datenschutz betrifft ethische Aspekte, daß heißt den Schutz vor missbräuchlicher Verwendung personenbezogener Daten.

Erschwert wird die Sicherung der Datenintegrität durch eine Reihe von Interessenskonflik- ten und Trade-offs. So erhöhen Archive zwar den Schutz vor Datenverlust, jedoch bieten die Archivdateien ein größeres Angriffspotential (GEHRING, H. u. HOMBERGER, J. (1993, KE4 S.23)).

2.5.1 Datenkonsistenz

Zur Vermeidung von Inkonsistenzen sollen Datenbankoperationen die Datenbank von einem konsistenten Zustand in einen anderen konsistenten Zustand überführen. Eine Datenbankope- ration, die dies gewährleistet, wird Transaktion genannt. Generell festhalten läßt sich, daß von den elementaren Operationen grundsätzlich alle Leseoperationen Transaktionen sind, da diese keine Dateiinhalteändern. Eine Transaktion wird definiert als eine Folge von elementaren Da- tenbankoperationen (Einfügen, Ändern, Löschen) mit folgenden Eigenschaften (JOHANNES, H. (2002, S.87f.)):

Atomarität (atomicity): Es muß sichergestellt werden, daß eine Transaktion, selbst im Fall eines Systemabsturzes, entweder komplett oder gar nicht durchgeführt wird. Eine Mög- lichkeit zur Realisierung ist die Logging-Technik (siehe Abschnitt 2.5.2.2). Konsistenzerhaltung (consistency): Bei negativem Resultat der Konsistenzprüfung muß der Abbruch der Transaktion erzwungen werden.

Isoliertheit (isolation): Gleichzeitig ablaufende Transaktionen dürfen sich nicht gegenseitig beeinflussen (siehe Abschnitt 2.5.2.1).

Dauerhaftigkeit (durability): Die Wirkung einer abgeschlossenen Transaktion ist persistent, das heißt sie bleibt dauerhaft in der Datenbank erhalten, insbesondere auch nach einem Systemabsturz.

Für diese Eigenschaften hat sich der Begriff AKID-Eigenschaften (ACID-properties) etabliert.

Die Regeln die eine Transaktion einhalten muß, werden durch die Konsistenzbedingungen definiert, welche sich in mehrere Arten klassifizieren lassen:

Starke Konsistenzbedingungen sind immer einzuhalten, während schwache Konsistenzbedin- gungen im Falle von fehlenden oder fehlerhaften Daten als Ausnahme gebrochen werden dürfen.

Primäre Konsistenzbedingungen werden durch die elementaren Datenbankoperationen nicht verletzt, während sekundäre von mindestens einer elementaren Datenbankoperation ver- letzt werden. Diese Inkonsistenz kann jedoch durch eine oder mehrere nachgeschaltete elementare Datenbankoperationen behoben werden.

Zustandsbedingungen sind im Gegensatz zu Übergangsbedingungen nicht an Datenbank- operationen gebunden.

Aufgebaut werden Konsistenzbedingungen aus vier Bestandteilen (SCHLAGETER, G. u. STUCKY, W. (1977, S.210)):

- dem Umfang der Daten, auf die sich die Konsistenzbedingung bezieht (kann von einzelnen Attributen bis zu mehreren Relationen reichen),
- der einzuhaltenden Bedingung (Zustandsbedingung) bzw. erlaubten Änderung (Übergangsbedingung),
- der Auslöseregel, die festlegt, wann die Einhaltung der Bedingung zu prüfen ist,
- der Reaktionsregel, die die Reaktion auf eine Verletzung der Bedingung enthält.

Trotz der Wichtigkeit von Konsistenzbedingungen werden diese nicht von allen DBVS unterstützt. Sofern Konsistenzbedingungen direkt mit der Sprache des DBVS formuliert werden, so daß das DBVS automatisch die Einhaltung gewährleistet, werden diese als modellinhärent bezeichnet. Bei einer Formulierung außerhalb des DBVS, beispielsweise durch ein Anwendungsprogramm, liegen modellexterne Konsistenzbedingungen vor.

2.5.2 Datensicherheit

Für die Datensicherheit müssen Maßnahmen in verschiedenen Bereichen ergriffen werden:

- bauliche Maßnahmen (z.B. abschließbare oder feuerfeste Türen),
- technische Maßnahmen (z.B. Klimaanlagen oder Notstromaggregate),
- organisatorische Maßnahmen (z.B. Zugangskontrollen oder Mitarbeiterschulungen),
- programmtechnische Maßnahmen (z.B. Transaktionsverwaltung oder Sicherheitskopien des Datenbestands).

Die für diese Arbeit relevanten programmtechnischen Maßnahmen werden nachfolgend kurz erläutert. Dabei lassen sich zwei Schwerpunkte identifizieren: Die Synchronisation paralleler Datenbankzugriffe und die Datenrekonstruktion.

2.5.2.1 Synchronization

Während die Ausführung einer einzelnen Transaktion oder mehrerer Transaktionen hintereinander (serielle Ausführung) völlig unproblematisch für die Datenkonsistenz ist, kann die parallele Ausführung mehrerer manipulierender Transaktionen zu Problemen führen, wenn diese auf gleichen Daten operieren. Daher muß das DBVS sicherstellen, daß diese parallelen Transaktionen synchronisiert durchgeführt werden.

Grundsätzlich werden dabei zwei Verfahren verwendet. Beim Sperrverfahren werden die Be- reiche einer Datenbank gesperrt, auf die eine Transaktion zugreift. Wenn eine andere auf den Bereich zugreifen möchte, muß sie erst auf das Ende der ersten Transaktion warten. Dagegen werden beim optimistischen Verfahren die Transaktionen parallel im Hilfsspeicher ausgeführt und in die Datenbank übernommen, wenn kein Konflikt auftritt. Bei Konflikten werden die Transaktionen zurückgesetzt.

Das Sperrverfahren eignet sich besonders für eine hohe Transaktionsdichte, da es in diesem Fall beim optimistischen Verfahren häufig zu einem zeitaufwändigen Zurücksetzen von Transaktionen kommen würde. Für weitere Informationen zum Ablauf der beiden Verfahren wird auf GEHRING, H. u. HOMBERGER, J. (1993, KE4 S.35-49) verwiesen.

2.5.2.2 Datenrekonstruktion

Beim Betrieb einer Datenbank kann es zu verschiedenen Arten von Fehlern kommen, die den Datenbestand beschädigen können. Als Beispiele können Transaktionsfehler, Abstürze des Betriebssystem- oder DBVS und Fehler des Festspeichers angeführt werden. Bei Transaktions- fehlern oder Systemabstürzen müssen nicht vollständig abgeschlossene Transaktionen zurück- gesetzt werden. Im Fall von Systemabstürzen werden dazu Log-Dateien verwendet, die alle Operationen an der Datenbank protokollieren und somit die Atomaritäts-Eigenschaft der Trans- aktionen realisieren. Am kritischsten sind Defekte des Festspeichers (z.B. ein Headcrash), da diese in der Regel die Zerstörung von Daten zur Folge haben. Hier hilft nur das regelmäßige Anlegen von Kopien des Datenbestands in Form eines Backups. Unterstützt durch die Log- Dateien können die Daten mit Hilfe eines Backups rekonstruiert werden. Auch an dieser Stelle wird für weitere Informationen auf GEHRING, H. u. HOMBERGER, J. (1993, KE4 S.50-56) und JOHANNES, H. (2002, S.89f.) verwiesen.

2.5.3 Datenschutz

Der Gestaltungsrahmen des Datenschutzes wird in Deutschland durch mehrere Bundes- und Landesgesetze abgesteckt. Diese regeln einerseits den Umfang und andererseits die Verwen- dung der in der Datenbank gespeicherten Daten. So dürfen laut Bundesdatenschutzgesetz (BDSG) nur personenbezogene Daten gespeichert werden, die für Abwicklung offizieller be- trieblicher Aufgaben unerlässlich sind und diese nur autorisierten Personen zweckgebunden bereitgestellt werden (vgl. insbesondere §§1,3,3a,4 BDSG (2006)). Zur Einhaltung der gesetz- lichen Vorschriften sind entsprechende organisatorische und technische Maßnahmen zu ergrei- fen. Von zentraler Bedeutung sind dabei Zugriffskontrollen, sowohl in Bezug auf die gesamte Datenbank im Rahmen einer Identitätskontrolle (z.B. durch Benutzernamen und Passwörter) als auch in Bezug auf einzelne Daten durch entsprechende Benutzerrechte. Diese Funktionen sind in den meisten DBVS integriert. Neben den Zugriffskontrollen existieren zudem noch die Möglichkeiten der Kryptologie, um Daten zu verschlüsseln (DE VRIES, A. (2004, S.74-80)).

2.6 Datenbanken als Teil eines betrieblichen Informations-

Für die Nutzung von PCs unverzichtbar ist eine für die jeweiligen Problemstellungen passende Software. Diese wird in der Wirtschaftsinformatik in die beiden Bereiche Anwendungssoftwa- re, welche die konkreten Aufgaben der Informationsverwaltung lösen soll und Systemsoftware unterteilt. Die Systemsoftware soll die Verbindung zwischen der von der Hardware bereitge- stellten Funktionalität und der Anwendungssoftware herstellen und erweitern. Somit gehören zur Systemsoftware Betriebssysteme, DBVSe, Softwareentwicklungssysteme, Middleware und Übersetzungsprogramme (Assembler und Compiler). Ein aus Anwendungs-, Systemsoftware und Hardware zusammengesetztes System wird als betriebliches Anwendungs- oder Informa- tionssystem bezeichnet. Gerade den Begriff Informationssystem machen verschiedene Defini- tionen in der Literatur besonders deutlich. So definiert SCHEER, A. W. (1995, S.684)) den Begriff als ein System zur „Planung, Steuerung und Überwachung aller informationellen Pro- zesse“ und zur „Bereitstellung von erforderlichen Informationen zur richtigen Zeit im richtigen Format an den richtigen Adressaten“. BALZERT, H. (1996, S. 24) spricht von einem „System, bei dem die Erfassung, Speicherung, Übertragung, Auswertung und/oder Transformation von Informationen durch Computersysteme teilweise automatisiert ist“.

Betrachtet man die verschiedenen Funkti- onsbereiche eines Unternehmens, in denen Anwendungssysteme eingesetzt werden, so lassen sich vier Typen voneinander abgren- Manage- zen: Kontroll- und Planungssysteme für das Controlling und für längerfristige Planun- gen, Management-Informationssysteme bzw. Führungsinformationssysteme zur Unterstüt- zung strategischer Unternehmensentschei- dungen, Administrationssysteme für opera- tive Aufgaben und Dispositionssysteme zur Unterstützung von Entscheidungen im opera- tiven Geschäft (JOHANNES, H. (2002, S.8); GEHRING, H. (1999, KE1 S.7-23); MER- TENS, P. u. GREISE, J. (2002); MERTENS, P.

Abbildung in dieser Leseprobe nicht enthalten

(2005)). Letztere wiederum werden unterteilt Abbildung 2.3: Konzept für integrierte betriebin mengenorientierte und wertorientierte Sy-liche Informationssysteme. steme ((SCHEER, A. W. 1995, S.4-6)). Eine gebräuchliche Darstellungsform für ein solches Informationssystem erfolgt in Form einer Pyramide gemäß dem Grad der Verdichtung der Daten (siehe Abbildung 2.3).

Um Informationen bereitstellen zu können, muß das Anwendungssystem über eine entsprechen- de Datenbasis verfügen. Insbesondere zur Gewährleistung einer hohen Qualität der Informatio- nen, muß die Datenbasis einigen Anforderungen genügen (JOHANNES, H. (2002, S.10f.)):

- Redundanzfreiheit
- Konsistenz (auch nach Systemfehlern)
- Korrektheit (auch bei Fehleingaben des Benutzers))
- Aktualität
- Hohe Verfügbarkeit

Ferner sollte die Datenbasis Mehrbenutzerzugriffe unterstützen und über eine komfortable Zu- griffssprache verfügen. Ein Vergleich zwischen der Datenhaltung mittels eines Dateisystems und eines DBSs, welcher in der Tabelle 2.4 dargestellt wird, macht deutlich, daß im Gegen- satz zu den Dateiverwaltungssystemen die DBSe diese Anforderungen erfüllen. Mit Ausnah- me des Verwaltungsaufwands sind sie den Dateiverwaltungssystemen deutlich überlegen. Die Datenbank-Technologie ist somit die optimale Lösung für die Datenbasis eines betrieblichen Anwendungssystems.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.4: Vergleich von Dateisystem und Datenbanksystem nach JOHANNES, H. (2002, S.10).

Kapitel 3 Verteilte Anwendungen

Datenbanksysteme werden häufig als Teil einer „verteilten Anwendung“ eingesetzt. Prägend für eine verteilte Anwendung ist, daß diese als ein „verteiltes System“ bestehend aus mehreren Computern realisiert wird, diese Verteilung aber für den Anwender des Systems nicht ersichtlich ist. Auch die Lösung des Softwareproblems, mit dem sich diese Arbeit beschäftigt, basiert auf einer verteilten Anwendung. Daher werden verteilte Anwendungen bzw. verteilte Systeme in diesem Kapitel vorgestellt.

Die Ausführungen werden in zwei Abschnitte unterteilt. Der ersten Abschnitt beschäftigt sich mit dem Thema Computernetzwerke, da diese erst die Realisierung eines verteilten Systems ermöglichen. Im Allgemeinen ist dieses Thema sehr komplex und vereint mehrere Wissensge- biete, wie Physik, Nachrichten- und Kommunikationstechnik, Kryptologie und Mathematik. Der Abschnitt kann daher nur einen kurzen Einblick geben. Für weitere Informationen zur Netzwerk-Technologie wird an dieser Stelle auf DE VRIES, A. (2004) verwiesen. Der zwei- te Abschnitt behandelt die verteilten Systeme. Auch dieses Thema ist sehr umfangreich, so daß hier eine Beschränkung auf die wesentlichen Grundlagen erfolgen muß, welche für diese Arbeit relevant sind. Ausführlichere Darstellungen lassen sich beispielsweise PESCHEL-FINDEISEN, T. M. (2006), TANENBAUM, A. S. u. VAN STEEN, M. R. (2003) oder WEDEKIND, H. (1994) entnehmen.

3.1 Computernetzwerke

Mit Ausnahme weniger Heim-PCs existieren kaum noch PCs, die nicht vernetzt sind. Die mei- sten Unternehmen verfügen über ein internes Local Area Network (LAN) (ein begrenztes pri- vates Netz mit einer Ausdehnung von weniger als 500 m) und Zugänge zu einem Wide Area Network (WAN), um beispielsweise auf das Internet zugreifen zu können. Man kann sogar sa- gen, daß in vielen Unternehmen Netzwerke das Rückgrat ihrer Informationsinfrastruktur bilden.

3.1.1 Vorteile und Anforderungen

Aufgrund der hohen Dynamik im Computerbereich mit immer leistungsfähigerer Hard- und Software und der zunehmenden Gefahr durch Computerviren und Hackerangriffe, sind Un- ternehmen bei Nutzung von Netzwerken permanent gezwungen, ihr Netzwerk zu verbessern und zu schützen. Trotz dieses nicht unerheblichen Aufwands überwiegen jedoch die Vorteile der Netzwerk-Technologie. Dieseäußern sich in zentral gespeicherten, redundanzfreien Daten- beständen, hoher Kommunikationsfähigkeit (z.B. durch E-mail- oder Chat-Systeme) und der Bereitstellung beliebig komplexer Dienste auf leistungsschwachen PCs durch leistungsstärkere Computer. Zudem ergeben sich aus der Zentralisierung von Diensten enorme Kostenvorteile, da beispielsweise teure Geräte (z.B. großformatige Farbdrucker) nur einmal angeschafft wer- den müssen und trotzdem allen Anwendern zur Verfügung gestellt werden können. Man kann ein Netzwerk somit als konsequente Weiterführung des Prinzips der Spezialisierung („Taylo- risierung“) ansehen, da jeder Netzteilnehmer sich auf seine notwendigen Anforderungen oder Dienstleistungen spezialisieren kann (DE VRIES, A. (2004, S.6f.)). Die grundsätzlichen An- forderungen an ein Netzwerk sind ausreichende Geschwindigkeiten für kurze Antwortzeiten bei Netzzugriffen, hohe Sicherheit in Bezug auf unerlaubten Zugriff, Skalierbarkeit, einfaches Netzwerkmanagement und möglichst geringe Kosten. Diese müssen wegen auftretender Ziel- konflikte priorisiert werden.

3.1.2 Netzwerk-Technologie

Die gegenwärtigen Netzwerk-Technologien orientieren sich fast ausschließlich an dem 1984 von der International Organization for Standardization (ISO) verabschiedeten OSI-Referenz- modell (Open Systems Interconnection), welches auf abstrakter Ebene die Datenübertragung für die Kommunikation zwischen Computern beschreibt (ISO-OSI (1994)). Es stellt einen offe- nen Standard dar, welcher über Computerarchitektur- und Betriebssystemgrenzen hinweg eine Kommunikation ermöglicht. Das OSI-Referenzmodell beschreibt die Verfahren und Regeln für die Kommunikation in Form eines Schichtenmodells. Eine tabellarische Darstellung des OSI- Referenzmodells und der für diese Arbeit relevanten Netzwerkprotokolle Transmission Control Protocol (TCP), User Datagram Protocol (UDP) und Internet Protocol (IP) erfolgt im Anhang E.

3.2 Verteilte Systeme

3.2.1 Definition und Eigenschaften

Folgt man der Literatur, so lassen sich mehrere Definitionen für den Begriff „verteiltes Sy- stem“ finden. Während TANENBAUM, A. S. u. VAN STEEN, M. R. (2003) von einem Zusam- menschluß unabhängiger Computer spricht, der sich für den Benutzer als einzelnes System prä- sentiert, formuliert es KAASHOEK (1992, S.1) grundlegender als eine Menge autonomer Com- puter, die ihren eigenen Hauptspeicher besitzen und über ein Computernetzwerk mittels Nach- richten miteinander kommunizieren („multiple autonomous machines that do not share primary memory, but cooperate by sending messages over a communication network“). Als wichtigste Aspekte lassen sich die Autonomie der Computer und die Transparenz der Verteilung identifi- zieren. Transparenz bedeutet, daß für einen Benutzer die Verteilung des Systems nicht relevant und idealerweise auch nicht ersichtlich ist. Unterschieden werden mehrere Aspekte der Trans- parenz (DROBNIK, O. (1991); PESCHEL-FINDEISEN, T. M. (2006, S.19-23)), wobei je nach Art und Schwerpunkt des verteilten Systems nicht immer alle Aspekte verwirklicht werden:

Fehlertransparenz: Das Gesamtsystem soll beim Ausfall von Teilen des Gesamtsystems wei- ter funktionieren mit ggf. verminderter Leistung.

Fragmentierungstransparenz: Eine Ressource kann auf mehrere Computer verteilt werden. Konkurrenztransparenz: Ressourcen können gleichzeitig von mehreren Benutzern ohne In- terferenzen benutzt werden.

Leistungstransparenz: Das System verteilt die Leistung automatisch optimal auf die beteilig- ten Computern.

Migrationstransparenz: Ein Verschieben von Objekten im verteilten System soll unbemerkt für die Anwendungen möglich sein.

Namenstransparenz: Ressourcen und Dienste haben global eindeutige Namen, mit dem sie von jedem Ort aus identisch angesprochen werden können.

Ortstransparenz: Dem Benutzer ist der Ort eines Dienstes oder einer Ressource nicht bekannt. Parallelitätstransparenz: Mehrere Teile einer Anwendung können parallel ausgeführt wer- den.

Replikationstransparenz: Sofern mehrere Kopien derselben Ressource vorhanden sind, sorgt das System automatisch für eine Replikation aller Änderungen.

Skalierungstransparenz: Eine Erweiterung soll flexibel und möglichst ohne Ausfallzeiten möglich sein (offene Schnittstellen).

Zugriffstransparenz: Der Zugriff auf entfernte Dienste oder Ressourcen erfolgt wie der Zu- griff auf lokale Dienste oder Ressourcen.

Grundlegend wird bei verteilten Systemen unterschieden zwischen der Verteilung von Daten (bzw. allgemeiner Ressourcen) oder Funktionalität, welche bereits beim Entwurf eines vertei- len Systems vorgenommen werden sollte, und der Verteilung von Last, die ad hoc während des Betriebs erfolgt (DUMKE, R. u. ZBROG, F. (2004, Abs.1 S.1)). Die Vorteile verteilter Syste- me sind hohe Verfügbarkeit, leichte Erweiterbarkeit, hohe Performance und Kostenreduktion. Erkauft werden diese durch eine hohe Komplexität der Software und des benötigten Kommuni- kationssystems mit den damit verbundenen Sicherheitsrisiken und größerem Wartungsaufwand.

3.2.2 Architektur

Die ersten Architekturen waren Großrechner (Mainframe)-Architekturen, bei denen sich die gesamte Anwendungslogik auf einem Zentralcomputer befindet und die Benutzer über einfa- che Terminals mit diesem interagieren, und Filesharing-Architekturen, bei denen Dateien zu einem Zentralcomputer übertragen, dort bearbeitet und anschließend wieder zurückgeschrieben werden. Aufgrund der zunehmenden Leistungsfähigkeit von PCs wurden diese Architekturen seit Anfang der 1990er Jahre durch Architekturen abgelöst, bei denen eine teilweise sogar voll- ständige Abkehr von der absoluten Abhängigkeit von Zentralcomputern vorgenommen wurde. Dabei können mehrere Modelle unterschieden werden (FISCHER, S. (2004, Kap.1 S.14-26)):

- Client/Server (C/S): Aufteilung in Server, die Dienste anbieten und Clients, welche die Dienste in Anspruch nehmen
- Multi-Server: Partition oder Replikation von Diensten auf mehrere Server (wird für World Wide Web (WWW) oder Domain Name System (DNS) eingesetzt)
- Service-Oriented Architecture (SOA): konsequente Weiterführung des C/S-Prinzips mit Services als zentralen Komponenten, welche Software mit formal beschriebener Schnittstelle darstellen, die den Zugang zur Anwendungslogik regelt
- Multi-Tiered: Erweiterung des C/S-Modells auf n Prozeßräume
- Peer-to-Peer: dezentrales System, welches ggf. zur Koordination Server benötigt (häufig für Filesharing im Internet verwendet)
- Grid Computing: Darstellung einer großen Anzahl von Computern als ein System Jedes der Modelle wird in der Praxis verwendet, da die Archi- Präsentation

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3.1: Drei-Schicht-Architektur eines verteilten Systems.

tektur zu dem jeweiligen Anwendungsproblem passen muß. Für die Problemstellung dieser Arbeit wurde eine Lösung basierend auf der C/S- Architektur mit Datenbankserver entwickelt, so daß diese nachfolgend näher betrachtet wird.

Unter der C/S-Architektur versteht man eine kooperative Form der Informationsverarbeitung mit auf verschiedenen Computern verteilten Softwarekomponenten, welche über ein Computernetz- werk verbunden sind. Die Computer in dem Netzwerk, welche Dienste anbieten, werden als Server, und die Computer, welche die Dienste nutzen, als Clients bezeichnet. Vielfach existiert auch eine allgemeinere Definition von Server und Client, welche von der Trennung auf verschiedene Computer abstrahiert und ledig- lich das Anbieten und Nutzen von Diensten als Merkmal beinhal- tet. Server und Client werden dann als einzelne Systeme gesehen,

die auch auf dem gleichen Computer realisiert werden können.

3.2. VERTEILTE SYSTEME 37

Grundlegend für eine C/S-Architektur ist die Unterteilung in drei Schichten, wie in Abbil- dung 3.1 dargestellt. Die Präsentationsschicht stellt die Schnittstelle zum Anwender dar, die Applikations- oder Anwendungsschicht führt die Bearbeitung der Anfragen durch und die Da- tenhaltungsschicht übernimmt die Speicherung der Daten in einer Datenbank. Letztere reprä- sentiert die Daten aus Sicht der Anwendungsdomäne und entspricht daher nur selten dem Da- tenschema der zugrundeliegenden Datenbanken. Da die Unterteilung logischer Natur ist, lassen sich drei Arten von C/S-Architekturen unterscheiden, je nachdem welche Schichten auf den Clients oder Servern realisiert werden:

- Client: Präsentation, Anwendung, dezentrale Datenhaltung ↔ Server: zentrale Datenhal- tung
- Client: Präsentation, Anwendung ↔ Server: Datenhaltung
- Client: Präsentation ↔ Server: Anwendung, Datenhaltung

Aufgrund der zunehmenden Leistungsfähigkeit von PCs herrschen Varianten vor, bei denen der Server lediglich für die Datenhaltung genutzt wird. Ein solches Client-Programm wird als „Fetter Client“ (Fat Client) bezeichnet. Das Gegenteil davon ist die „Schlanker Client“-Variante (Thin Client), bei der sich der Client nur noch auf die Anzeige von Dialogen und die Aufbereitung der Daten zur Anzeige beschränkt (COULOURIS, G. u. a. (2002, S.59)).

Ein bekanntes Beispiel für eine C/S-Architektur ist SAP R/3. Hier liegt die Präsentationsschicht auf dem Client (SAP-GUI), während Anwendungs- und Datenhaltungsschicht auf einem oder mehreren Servern residieren (JOHANNES, H. (2002, S.94)).

3.2.3 Verteilte Anwendungen

Auf einem verteilten System kann eine verteilte Anwendung ablaufen. Intention einer verteilten Anwendung ist es, die Aufgabe des Gesamtsystem auf mehrere Softwarekomponenten aufzuteilen, die zur Erfüllung der Gesamtaufgabe über definierte Schnittstellen miteinander kommunizieren. Für den Benutzer soll die Anwendung dabei transparent erscheinen, daß heißt wie ein System auf einem einzelnen Computer. Formal wird eine verteilte Anwendung nach SCHLICHTER, J. (1997, S.10f.) definiert wird als eine Anwendung A, deren Funktionalität zerlegt ist in eine Menge von kooperierenden Teilkomponenten A 1 , . . . , An mit n ∈ N, n > 1. Jede Teilkomponente hat einen internen Zustand, auf den Daten und Operationen angewendet werden. Die Ai sind autonome Verarbeitungseinheiten, welche auf verschiedene Funktionseinheiten Fi abgebildet werden. Dabei können mehrere Teilkomponenten auf dieselbe Funktionseinheit abgebildet werden. Die Ai tauschen untereinander Informationen mittels eines Computernetzwerks aus.

Neben den einzelnen Teilkomponenten ist daher auch die Integration von Software wichtig, welche die Netzwerk-Kommunikation regelt. Diese wird als „Middleware“ bezeichnet. Ein Beispiel für eine solche Software ist ODBC, welche bei dem vorliegenden Softwareprojekt verwendet wurde und daher im nächsten Abschnitt beschrieben wird.

Da verteilte Anwendungen fast ausschließlich in Mehrbenutzerumgebungen eingesetzt werden, ist eine geeignete Koordination konkurrierender Zugriffe durch Synchronizationsmechanismen unerlässlich. Ferner ist eine entsprechende Fehlerbehandlung notwendig, da auf jedem einzelnen Computer oder bei der Kommunikationsverbindung Fehler auftreten können, die nicht zum Absturz der Gesamtanwendung führen sollen.

3.2.4 ODBC

Für verteilte Anwendungen, die auf der C/S-Architektur basieren, hat sich mit der Middleware ODBC ein Marktstandard für den herstellerunabhängigen Zugriff auf Datenbanken und Datei- systeme durchgesetzt. Der große Vorteil von ODBC ist, daß es SQL als Datenbanksprache ver- wendet. Konkret basiert ODBC auf der Common Language Infrastructure (CLI)-Spezifikation der X/Open SQL Access Group und ist inzwischen ein ISO-Standard (JOHANNES, H. (2002, S.98)).

ODBC sitzt zwischen der Anwendungs- und Datenhaltungsschicht, so daß Präsentations- und Anwendungsschicht auf dem Client und die Datenhaltungsschicht auf dem Server realisiert sind. Damit bietet es eine Programmierschnittstelle (Application Programming Interface (API)), die es erlaubt, eine Anwendung relativ unabhängig vom verwendeten DBVS zu entwickeln, wenn dafür ein ODBC-Treiber existiert. Der Zugriff erfolgt nicht direkt auf eine Tabelle oder eine Datenbank, sondern über die entsprechende ODBC-Komponente. Für ODBC ist es da- bei unerheblich, ob die Datenbank lokal oder entfernt gespeichert ist. Diese Interoperabilität erzeugt eine erhebliche Flexibilität und damit einen enormen Vorteil von ODBC in heteroge- nen Umgebungen. Zudem laufen Client und Server bei Verwendung von ODBC nebenläufig, das heißt parallel zueinander. Dadurch bedingt ist die Performance in Netzwerk grundsätzlich besser als bei synchron arbeitenden Lösungen.

Der ODBC-Funktionsumfang wird durch verschiedene Level ausgedrückt (JOHANNES, H. (2002, S.99f.)). Der Kernlevel der ODBC-API beinhaltet Funktionen zum Verbindungsaufbau und -abbau zur Server-Datenbank, zur Ausführung von SQL-Anweisungen, zur Beschreibung einer Ergebnismenge, zur Entgegennahme von Daten, zum Durchführen von Transaktionen und zum Einsatz eines Cursors. An SQL-Sprachkonzepten sind die referentielle Integrität und der tabellenspezifische Zugriffsschutz vorhanden. Die Erweiterung des Kernlevels durch die ODBC-Extensions sieht zusätzlich noch die Unterstützung für Zugriffsrechte, Indizes, Stored Procedures und Katalogfunktionen vor.

ODBC wird von fast allen DBSen (z.B. Oracle, IBM DB2, Microsoft SQL Server) und den wichtigsten aktuellen Betriebssystemen (Windows, Linux, Unix, MacOS, OS/2) unterstützt und ist in Microsoft Windows Betriebssystemen seit 2000 sogar als Teil der Microsoft Data Access Components (MDAC) ein integraler Betriebssystem-Bestandteil. Im Gegensatz dazu wird die Weiterentwicklung von ODBC, „Object Linking and Embedding Database (OLE DB)“ erst von wenigen DBSen unterstützt (ALBRECHT, R. u. NICOL, N. (2000, S.913)) und ist daher noch nicht weit verbreitet.

Kapitel 4 Analyse

Den ersten Schritt bei der Durchführung eines Projekts zur Entwicklung eines Softwaresystems bildet die Analyse. Diese sollte mit besonderer Sorgfalt durchgeführt werden, da sich Fehler zu Beginn des Entwicklungsprozesses gravierend auf den gesamten Entwicklungsprozeß auswirken und nachträglich nur mit sehr großem Aufwand zu korrigieren sind¹. Allgemein gilt die Regel, daß bei stärkerer Unterstützung der ersten Phasen die Kosten bei den nachfolgenden Phasen geringer bleiben. Ziele der Analyse sind die Beschreibung der Ausgangssituation, die Ressourcenplanung, die fachliche Modellierung der Anwendung und die Definition der Ziele aus Anwendersicht, welche mit dem Projekt verwirklicht werden sollen.

Wie bereits in der Einleitung erwähnt, wird nach dem Konzept der strukturieren Analyse vor- gegangen. Zu beachten ist, daß in der Literatur fast ausschließlich Verfahren für große Soft- wareprojekte beschrieben werden, die von Unternehmen mit mehreren Mitarbeitern und ent- sprechender Erfahrung durchgeführt werden. Aufgrund des vergleichsweise geringen Umfangs und zudem aufgrund des besonderen Charakters einer Diplomarbeit, welcher sich naturgemäß in größerem Arbeitseinsatz und höherer Motivation des Bearbeitersäußert, ist dieses Projekt damit nicht zu vergleichen. Daher müssen an einigen Stellen Modifikationen an den Verfah- rensweisen für Großprojekte vorgenommen werden, auf die jeweils hingewiesen wird.

Unterteilt wird die Analyse analog zu BORTFELD, A. (2001, KE1 S.19-21) in zwei Teilaktivitäten: Die Ermittlung der Anforderungen, welche sich in die Schritte Fachliche Vorstudie, Durchführbarkeitsuntersuchung und Erstellung des Pflichtenhefts aufgliedert, und die Modellierung der Anwendung aus fachlicher Perspektive. Während bis zum Pflichtenheft primär aus Anwendersicht vorgegangen wird, erzeugt erst das fachliche Modell eine vollständige, eindeutige, konsistente und intentionstreue Anforderungsdefinition.

Ausgangspunkt der Analyse ist eine ausführliche Ermittlung der Anforderungen. Für das vorlie- gende Projekt erfolgt diese einerseits mittels mehrerer Gespräche, welche mit dem Auftragge- ber, in Person des Institutsleiters und des Institutssekretärs, dem Mitarbeiter des Instituts Physik, welcher das derzeitige Softwaresystem nutzt und den Mitarbeitern, welche das zu erstellende Softwaresystem benutzen sollen. Diese Personen können als die entscheidenden Wissensträger für die Analyse DE VRIES, A. (2005, S.7) angesehen werden. Weiterhin wird das bisherige Softwaresystem inklusive dessen Bedienungsanleitung zur Anforderungsermittlung verwendet.

4.1 Fachliche Vorstudie

Auf die Ermittlung der Anforderungen folgt die Fachliche Vorstudie. Folgt man beim Aufbau den Ausführungen von BORTFELD, A. (2001, KE2 S.17-19) ist zuerst die allgemeine Zielset- zung des Softwaresystems basierend auf dem vom Auftraggeber geäußerten Bedarf zu formu- lieren. Ferner ist der Anwendungsbereich, daß heißt der Komplex zusammenhängender Auf- gaben, den das System abdecken soll, aus Sicht der betroffenen Mitarbeiter zu beschreiben. Daran schließt sich die Analyse der gegenwärtigen Informationsverarbeitung an, insbesondere in Hinblick auf bestehende Schwachstellen. Abgeschlossen wird die Fachliche Vorstudie durch ein Lösungskonzept, welches die Anforderungen an das neue System grob umreißt.

4.1.1 Allgemeine Zielsetzung und Anwendungsbereich

Die Universität Dortmund untergliedert sich in neben der Universitätsverwaltung und diver- sen zentralen Einrichtungen in mehrere Fachbereiche. Diese bestehen aus einem oder mehreren Instituten. Jedem dieser Fachbereiche wird als sogenannte „Haushaltsmittel“ eine bestimmte Menge Geld zur Deckung der Ausgaben von der Universität zur Verfügung gestellt. Innerhalb des Fachbereichs Physik, welcher nur aus dem Institut Physik besteht, erfolgt eine Aufteilung der Haushaltsmittel auf die verschiedenen Einrichtungen, in die sich der Fachbereich unterglie- dert. Jede dieser Einrichtungen wiederum kann über die ihm zugewiesenen Mittel in gewissen Rahmen verfügen, jedoch nicht die Mittel zur Zahlung anweisen. Dieses übernimmt eine Stelle der Universitätsverwaltung, die sogenannte „Zentrale Rechnungsstelle“ des Dezernats 5 Haus- haltsangelegenheiten.

[...]

---

¹ Teilweise erfolgt in der Literatur eine vereinfachte Darstellung, bei der die im letzten Abschnitt aufgeführten Aktivitäten bereits als Phasen bezeichnet werden (z.B. in BALZERT, H. (1982); PAGEL, B.-U. u. SIX, H.-W. (1994)).

¹ Laut BOEHM, B. W. (1984) wächst der Kostenaufwand für die Fehlerbehebung exponentiell mit dem Zeitpunkt der Fehlererkennung.