Colowin: Fallorientierte Einführung in die Systementwicklung [Reprint 2018 ed.] 9783486784626, 9783486225389

Citation preview

COLOWIN Fallorientierte Einführung in die Systementwicklung

Von Professor

Dr. Dr. Ulrich Derigs und Diplom-Kaufmann

Gregor L. Grabenbauer

R. Oldenbourg Verlag München Wien

Die Deutsche Bibliothek — CIP-Einheitsaufnahme Derigs, Ulrich: Colowin : fallorientierte E i n f ü h r u n g in die S y s t e m e n t w i c k l u n g / von Ulrich Derigs u n d Gregor L. G r a b e n b a u e r . - München ; Wien : O l d e n b o u r g , 1 9 9 3 ISBN 3 - 4 8 6 - 2 2 5 3 8 - 3 N E : G r a b e n b a u e r , Gregor L.:

© 1993 R . O l d e n b o u r g Verlag G m b H , München Das Werk außerhalb lässig und filmungen

einschließlich aller Abbildungen ist urheberrechtlich geschützt. Jede V e r w e r t u n g der G r e n z e n des Urheberrechtsgesetzes ist o h n e Z u s t i m m u n g des Verlages unzus t r a f b a r . Das gilt insbesondere für Vervielfältigungen, Ü b e r s e t z u n g e n , Mikroverund die Einspcicherung u n d Bearbeitung in e l e k t r o n i s c h e n S y s t e m e n .

D r u c k : G r a f i k + D r u c k , München Bindung: R. O l d e n b o u r g Graphische Betriebe G m b H , München

ISBN 3-486-22538-3

Vorwort Während

in der

Informatikausbildung

heute

noch das

Programmieren

im

Kleinen

(Programming in the small), das Schreiben von einzelnen Programmen mit den Anweisungen einer Programmiersprache, vorherrscht, stellt die Programmierung im Großen (programming in the large) einen wichtigen Bestandteil des Lernprogramms für Wirtschaftsinformatiker dar. An der Schnittstelle zwischen Betriebswirtschaftslehre und Informatik besteht ein außerordentlicher Bedarf an leistungsfähigen Konzepten für die Realisierung fachspezifischer Anforderungen mit informationstechnischen Instrumenten. Das Entwerfen von Informations- und Kommunikationssystemen bietet den Studenten in vielfacher Hinsicht Gelegenheit, betriebswirtschaftliche Kenntnisse anzuwenden und zu vertiefen: Die Planung und die Abwicklung eines Systementwicklungsprojekts folgt organisatorischen Prinzipien, der Entwurf des Fachkonzepts ist ein Test für bereits erworbenes betriebswirtschaftliches Know-How. Die Arbeit in einem Projektteam fordert und schult die Kommunikations- und Organisationsfähigkeiten. Nicht zuletzt kann die Systementwicklung auch faszinieren. Das Design entwerfen, die Module konstruieren, solide Datenstrukturen und effiziente Algorithmen zu einem stabilen und ästhetischen Anwendungssystem verbinden: Diese Gestaltungsprozesse stellen interessante Herausforderungen dar, die je nach Lernmöglichkeit subjektiv zu bewerten sind. Auch die Probleme der Systementwicklung werden am praktischen Anwendungsfall sichtbar: • Die Grenzen der Systementwicklung beruhen auf unserer unzulänglichen Fähigkeit, komplexe Sachverhalte gedanklich vollständig zu durchdringen. • Der Entwurf eines guten Systems erfordert kreative Denkweisen. • Software muß logisch konsequent erdacht und präzise spezifiziert werden. Mit vorgefertigten Musterlösungen, die das Schablonendenken fördern, können diese Fähigkeiten nicht vermittelt werden, sie fungieren nur als Orientierungshilfe bei der selbständigen Bearbeitung eines Problems. Schließlich weist die Systementwicklung noch eine sportliche Komponente auf, die sich in der Anspannung bis zur Erreichung des Ziels ausdrückt, der erfolgreichen Systemabnahme.

U. D. und G. G.

Töricht« moderne viiuclle Erziehung, die in der Tat prächtig« Schliche «rsiimt, UM »ha« Müh« W i n « * keizukringe», womit d u Kind auf di« Roll« eines Formulars reduziert wird und einem 6epaek voller Keinitniss« ausgeliefert wird, statt daß man ihm «in«* S t i l formt - und auf ditse Weis« «in« Seele. Anleint

dt

Siitl-Etupery

Inhaltsverzeichnis

1. Einführung 2. Fallbeschreibung COLOWIN GmbH 2.1. Ausgangssituation 2.2. Fallbeschreibung 3. Grundlagen der Systementwicklung 3.1. Ziele der Systementwicklung 3.2. Vorgehensmodell 3.3. Grundlagen der Datenmodellierung 3.3.1. Datenbanksysteme und Systementwicklung 3.3.2. Abstraktion als Basis der Datenmodellierung 3.3.3. Das Entity-Relationship-Modell (ERM) 3.3.3.1. Das Grundmodell des ERM 3.3.3.2. Spezielle Aspekte und Erweiterungen des ERM 3.3.3.3. Strategien der konzeptionellen Modellierung 3.3.3.4. Semantische Präzision und Normalität als Design-Kriterium 3.3.4. Das Relationenmodell (RM) 3.3.4.1. 3.3.4.2. 3.3.4.3. 3.3.4.4.

Strukturelemente und Integritätsregeln des RM Datenmanipulation im RM Modellierung der Diskurswelt im RM Physischer Datenbank-Entwurf

3.4. Grundlagen der Funktionsmodellierung 3.4.1. Prinzipien des Funktionsentwurfs 3.4.2. Diagrammtechniken 3.4.2.1. Datenflußdiagramme 3.4.2.2. Kybernetische Schaubilder 3.4.2.3. HIPO-Diagramme 3.4.2.4. Struktogramme 3.4.3. Entwurf von Funktionseinheiten 3.4.3.1. Typisierung von Funktionseinheiten 3.4.3.2. Spezifikation abstrakter Funktionstypen 3.4.3.3. Spezifikation der Funktionseinheiten 3.4.4. Funktionsintegration

VIII

4. DV-technische Instrumente 4.1. Datenbankprogrammierung mit dBASE IV

103 103

4.1.1. Grundlegendes zur dBASE-Anwendung

I04

4.1.2. Datenverwaltung: Anlegen einer dBASE-Datei

I05

4.1.3. Datenverwaltung: Anlegen der Indexe

I05

4.1.4. Datenmanipulation

I06

4.1.5. Programmierung mit dBASE

II2

4.1.6. Zusammenfassung der dBASE-Befehle und -Funktionen

119

4.2. Finanzbuchhaltung mit KHK-Fibu 4.2.1. Arbeitsvorbereitungen

133 133

4.2.2. Grundlagen der Buchungserfassung

I40

4.2.3. Die Bearbeitung von Offenen Posten

¡42

4.2.4. Ausgewählte Buchungsfälle

(45

4.2.5. Verarbeitung der erfaßten Buchungen

149

4.2.6. Stapelerfassung und wiederkehrende Buchungen

ISO

4.2.7. Dateistruktur der KHK-Buchungsdateien

151

5. Fallstudie

IS3

5.1. Projektbeschreibung

IS3

5.2. Grobkonzept

iss

5.2.1. Fachkonzept

iss

5.2.1.1. Logistik

I56

5.2.1.2. Rechnungswesen 5.2.2. DV-Konzept

I6I I64

5.2.2.1. Unternehmensdatenmodell

I64

5.2.2.2. Unternehmensfunktionsmodell

167

5.2.2.3. Detailliertes Datenmodell

I72

5.2.2.4. Detailliertes Funktionsmodell

I73

5.3. Feinkonzept

I79

5.3.1. Beschreibung des logischen Datenmodells

I79

5.3.2. Algorithmische Beschreibung der Funktionseinheiten

185

5.4. Programmierung

'97

6. Zusammenfassung und Ausblick

I98

Literaturverzeichnis

203

Einführung

I.Einführung Die steigenden Erwartungen an die Leistungsfähigkeit informationstechnischer Systeme können heute wie in der Vergangenheit nur unzureichend erfüllt werden, obwohl die Leistungsmerkmale der Rechnersysteme und der Entwicklungswerkzeuge rasant verbessert werden. Unter dem klassischen Schlagwort der "Softwarekrise" wurde diese Diskrepanz Gegenstand von zahlreichen kritischen Veröffentlichungen. Selten wird jedoch die Frage nach dem Fortschritt der Grundlagenforschung im Bereich der Systementwicklung 1 ' gestellt, einer Disziplin, die sich mit der Gewinnung von Methoden 2 ' zur Systementwicklung befaßt. Einen knappen Überblick über grundlegende methodische Beiträge und dazu in Beziehung stehende Diagrammtechniken soll die nachfolgende Tabelle geben. Die inhaltliche Strukturierung kann dabei nicht trennscharf erfolgen, da einzelne Methoden zum Teil übergreifende Anwendungsmöglichkeiten aufweisen. Daten Analyse Abstraktion Modellierung

Funktionen Analyse Abstraktion Modellierung

Datenflußplan (1966)

Funktionsbaum Strukturierte Programmierung

Codd (1970): Relationales Datenmodell

Ross (1977): Structured Analysis and Design Technique [SADT]

Chen (1976): Entity-RelationshipModell

De Marco (1979): Structured Analysis [SA]

Mills (1972): HIPO-Diagramm

Liskov/Zilles (1974): Abstrakter Datentyp

Parnas (1972): Software Modul

Datenflußdiagramm

[ADT]

Jackson (1975): Jackson Structured Programming [JSP] SADT SA

Algorithmische Spezifikation

Entscheidungstabellen [ET] (1957) Programmablaufplan (1966) Dijkstra (1968): Strukturierte Programmierung

Zustände Analyse Abstraktion Modellierung

Petri (1962): Petri-Netze

Wirth (1971): Schrittweise Verfeinerung

ADT JSP

Nassi/ Shneidermann(1973): Struktogramm Denert (1977): Interaktionsdiagramme

Parnas (1969): Endlicher Automat ET

Tab. 1: Methodische Grundlagen der Systementwicklung, gegliedert nach Entwicklungsphasen Die folgenden Begriffe werden hier und teilweise in der Literatur synonym für den Begriff Systementwicklung gebraucht: Systemplanung. Systementwurf, Softwareentwicklung, Softwareentwurf, SystemDesign, System-Engineering, Software-Engineering. Methoden sind planvoll-systematische Vorgehensweisen, die den Weg zur Erreichung eines Ziels beschreiben.

- 2 -

Einführung

Hierbei ist zu beachten, daß die Gliederung in Daten-, Funktions- und Zustandsmodellierung ein Strukturkonzept für die Systementwicklung impliziert, die jedoch nur historisch durch die Spezialisierung einzelner Forschungsbereiche entstanden ist. Die Erkenntnisse aus der Programmierung im Kleinen werden unter den Begriff algorithmische Spezifikation eingeordnet. In neueren Ansätzen wird vermehrt versucht, durch die Kombination von elementaren Entwicklungsmethoden den Systementwicklungsprozeß umfassend zu unterstützen. Diese Tendenz wurde von der Verbreitung der Kombinationsmethoden SA und SADT maßgeblich beeinflußt. Im Rahmen der rechnergestützten Systementwicklung dominieren heute zunehmend die technischen Aspekte, vor allem bei der Zielsetzung einer automatischen und industriellen Softwareproduktion. Die Unterscheidung zwischen der Systementwicklungsmethode und der von ihr benutzten Technik erscheint im Hinblick auf den vermehrten Technikeinsatz sehr bedeutsam. Allen Methoden zur Systementwicklung ist gemeinsam, daß technische Hilfsmittel, insbesondere graphische Darstellungsmittel, zur Unterstützung ihrer Anwendung herangezogen werden. Diese Techniken sind keineswegs unabhängig von der methodischen Idee einsetzbar; sie stellen lediglich ein grundsätzlich geeignetes Hilfsmittel für die zielorientierte methodische Systementwicklung dar. Das Paradigma "Objektorientierte Systementwicklung" (Goldberg (1980):SMALLTALK) findet heute durch die Verfügbarkeit objektorientierter Programmiersprachen und Entwicklungswerkzeuge großes Interesse. Die methodischen Grundlagen dieses Ansatzes entstammen zum einen dem Klassenkonzept von SIMULA (1965) und zum anderen dem als abstrakter Datentyp (1974) bekannt gewordenen Konzept der Datenabstraktion. Im Rahmen dieser Fallstudie wird versucht, Studenten der Wirtschaftsinformatik und Interessierte an der Anwendungssystementwicklung In die Problematik der methodischen Systementwicklung einzuführen und an Hand eines praktischen Szenarios deren Komplexität zu veranschaulichen. Einzelne, In der ausführlichen Fallbeschreibung vorgestellte Sachverhalte finden bei der beispielhaften Veranschaulichung von Methoden und Diagrammtechniken Verwendung. Im Abschnitt "Grundlagen der Systementwicklung" werden die in der Fallstudie eingesetzten Methoden und Techniken vorgestellt und in dem Umfang vertieft, der zum Verständnis der gewählten Vorgehensweise und der vorgeschlagenen Lösungskonzepte notwendig erscheint. Im Hinblick auf die praktische Ausrichtung soll die nachhaltige Erklärung methodenspezifischer Grundlagen den zusätzlich angegebenen Beiträgen der Fachliteratur vorbehalten bleiben.

Fallbeschreibung

- 3-

2. Fallbeschreibung COLOWIN GmbH 2.1. Ausgangssituation August-Wilhelm Unruh, Student der Betriebswirtschaftslehre an der Universität zu Köln, macht sich im Sommer 1988 als Einzelhändler für IBM-kompatible Personalcomputer, Hardwarezubehör und Software selbständig. Der rasch wachsende Markt für diese Rechnergattung beschert ihm im ersten Jahr seiner Selbständigkeit einen Umsatz von DM 650.000. Als kluger Unternehmer wandelt er bereits zum 1. Januar 1990 die Rechtsform seiner Handelsgesellschaft in eine GmbH, der COLOWIN GmbH, mit Sitz in Köln, Zülpicher Platz 1; alleiniger Geschäftsführer ist A.-W. Unruh. Das Jahr 1990 verläuft zunächst gemäß den steigenden Umsatz- und Ertragserwartungen. Jedoch zeigt sich zum Ende des Jahres, daß die WIN-Komplettsysteme (AT 286/12) wie Blei im Lager liegen bleiben. Diese Entwicklung setzt sich in Jahr 1991 fort. Die starke Konkurrenz von mächtigen Handelsunternehmen wie TOBIS, ASCOM und NCI drücken die Verkaufspreise schließlich bis unter die Einstandspreise für WIN-Systeme der COLOWIN GmbH. Angesichts dieser katastrophalen Entwicklung sucht Unruh bei seinen inzwischen diplomierten Freunden Marketing-Rat. Diese argumentieren übereinstimmend mit einem Modell "strategischer Erfolgsfaktoren" und schlagen ihm eine Umstellung seiner Produktstrategie vor. Unruh solle die kundenindividuelle Entwicklung und Montage von garantiert leistungsfähigen Personalcomputern anbieten, um den Markt für anspruchsvolle Anwender in den Kriterien Leistung, Ergonomie und Design (LED-Konzept) zu bedienen. Unruh ist von der Marketing-Idee seiner Freunde begeistert, im August '91 startet er die Werbeaktion für die neuen WIN/LED-Systeme, individuell konfigurierte Personalcomputer für hohe Ansprüche. Die LED-Aktion weckt große Nachfragen, die Auftragsbestände können von der neu eingerichteten Werkstattfertigung und Lackiererei nur noch mit einer vierwöchigen Lieferzeit abgewickelt werden. Zum Jahresende zieht Unruh Bilanz und stellt mit großem Erstaunen einen Verlust in Höhe von DM 87.000.- fest. Die betriebswirtschaftliche Auswertung seines integrierten FibuStandardpakets ermittelt für die von Unruh als sehr erfolgreich eingeschätzte zweite Jahreshälfte einen Verlust in Höhe von DM 69.000. Unruh beschwert sich daraufhin bei seinen diplomierten Freunden über deren "katastrophalen Rat". Die anschließend von seinen Freunden hastig durchgeführte Betriebsanalyse fördert zutage, daß Unruh weder eine Vor- noch eine Nachkalkulation für die von ihm montierten Geräte durchgeführt hatte und die Erlöse die direkten Kosten kaum abdecken konnten. Wie er so etwas kontrollieren könne, fragt Unruh, das von ihm vor zwei Jahren angeschaffte KHK-Finanzbuchhaltungspaket sehe solche Kalkulationsfunktionen nicht vor, die Artikel- und Umsatzanalyse sei für die zahlreichen Produktvarianten nicht anwendbar.

-

4 -

Fallbeschreibung

Heinz Sixdorf, ein Kenner des Angebots an integrierten kaufmännischen Systemen, schlägt August-Wilhelm Unruh vor, ein für seine Anforderungen geeignetes System zur Fakturierung und Kalkulation zu entwickeln. Das KHK-System könne die Aufgabe der Finanzbuchhaltung weiterhin übernehmen, über eine Schnittstelle zur Fibu würden die neu entwickelten Komponenten problemlos integriert. So könnten auf effiziente Weise die Fakturierung und die Kalkulation abgewickelt werden. Die Bitte Unruhs, ob Sixdorf dieses System nicht entwickeln möchte, lehnt dieser unter Hinweis, darauf ab, daß ihm notwendige Detailkenntnisse an Programmierwerkzeugen und Datenbanksystemen, die man dafür einsetzen sollte, fehlten. Sixdorf deutet an, es sei illusorisch, zu versuchen, ohne ein gut durchdachtes und solides Basis-Informationssystem Kostenplanungs- und Kontrollsysteme zu implementieren. Er verweist auf Bekannte aus Studentenkreisen, die als Wirtschaftsinformatiker zur Entwicklung eines geeigneten BasisInformationssystems das ideale Know-How hätten, und die ohnehin gefährdete Liquidität der COLOWIN GmbH nicht zu sehr anspannen würden.

-5-

Fallbeschreibung

Seite stehen zwei weitere Schreibtische an der

2.2. Fallbeschreibung

Wand. Der vordere trägt einen zierlichen P C , der

Montagmorgen, kurz vor neun Uhr: Peter Poke

allerdings nicht oft in Gebrauch zu sein scheint,

steigt a m Zülpicher Platz aus der Straßenbahn

denn er ist, wie der restliche Platz a u f dem

einer

Schreibtisch, über und über mit Notizzetteln,

kleinen Computerfinna namens C O L O W I N . Der

Ordnern und Formularen bedeckt. Der hintere

und hält Ausschau nach der Werbetafel

C h e f dieser Firma hatte ihm vor kurzem eine

Schreibtisch,

Praktikantenstelle angeboten und für heute einen

Ledersessel davor, scheint für Unruh reserviert.

tiefschwarz

mit

einem

feinen

Suchen

Seine Schreibfläche ist leer, ein Chromschild-

Haus, die

chen strahlt: " A . - W . Unruh - B o s s " . "Der Chef

C O L O W I N GmbH liegt ein wenig versteckt in

kommt montags meist etwas später. Du kannst

einem Hinterhof. Nur ein neueres Schild mit der

Dich aber schon ein wenig umsehen. Fühl Dich

Aufschrift " C O L O W I N GmbH - Personalcom-

wie zu Hause." Mit diesen Worten drückt Tipp

Termin

ausgemacht.

Nach

entdeckt er schließlich das

einigem richtige

Ge-

Poke eine Tasse mit K a f f e e in die Hand. "Milch

deutet

und Zucker findest Du in der untersten Schubla-

überhaupt auf die Existenz der Firma hin. Nach-

de in meinem Schreibtisch." Sie deutet auf den

puter,

Hardwarezubehör

schäftsführer

und

August-Wilhelm

Software Unruh"

mit

Wust von Papieren. "Ich bin gleich wieder da."

Horden lärmender Kinder gekämpft hat, steht er

Sie nimmt eine Handtasche von dem Kleider-

vor der Eingangstür zu einem Mietshaus mit

ständer, der hinter der Flurtür steht, und verläßt

einem

den Raum. Poke schwingt sich sofort hinter den

dem er sich durch eine Garageneinfahrt

kleinen

Messingschild

der

COLOWIN

P C . Es ist ein teures 4 8 6 e r - S y s t e m mit einigen

GmbH.

Spielereien. So wird Poke etwa beim Booten mit I m ersten Stockwerk angelangt öffnet ihm eine

dem Geräusch

junge D a m e auf sein Klingeln hin die Tür. Für

G T O beglückt. Nach einigem Suchen stellt er

die frühe Stunde fast zu freundlich begrüßt sie

allerdings enttäuscht fest, daß außer einer Daten-

eines

davonbrausenden

Ferrari

Poke: " A h , guten Morgen. Sie sind sicher Herr

bank mit Kochrezepten und einigen unnützen

Poke.

Tools nur eine KHK-Software, mit der anschei-

Der C h e f hat Sie bereits

angekündigt.

Mein N a m e ist Tipp - Sie können ruhig Trude zu

nend

mir sagen; das machen alle hier, wir duzen j a

Word 5.0 nichts auf der Platte zu finden ist.

die

Buchhaltung

gemacht

wird,

sowie

sogar den Chef. Sie werden jetzt einige Zeit hier

Disketten

arbeiten, um unsere Fibu auf Vordermann zu

kann er nirgends entdecken. Die gesamte Post

bringen..."

wird offensichtlich mit dem Textverarbeitungs-

Poke

"Äh j a , guten Morgen", unterbricht

Tipps

Redeschwall

zaghaft.

"Stimmt

system

mit weiteren

erledigt,

denn

Anwenderprogrammen

eine

Schreibmaschine

genau. Herr Unruh, äh - Willi, meinte, ich soll

enthält Tipps Büro nicht. Unter dem Schreibtisch

mir den Betrieb hier einmal anschauen und ein

versteckt entdeckt Poke einen modernen Laser-

System für die Faktura, die Beschaffung und das

drucker. Da Trude noch nicht zurück ist und

Lager entwickeln." "Aber komm doch erst mal

Arbeitsgeräusche über den Flur zu ihm dringen,

rein. Willst Du einen Kaffee?" fallt die quirlige

macht sich Poke auf, auch die anderen Mitarbei-

Person ihm ins Wort. "Ja, vielen Dank!" Poke ist

ter Unruhs kennenzulernen.

froh, daß Trude Tipp so rasch zum " D u " übergegangen ist, denn als Student der Wirtschaftsin-

A l s er das Büro verläßt, sieht er linkerhand die

formatik ist er es nicht gewohnt,

Haustür und rechterhand eine zweite Holztür mit

gesiezt zu

werden. Tipp führt ihn über einen kleinen Flur,

der Aufschrift " W C " . A u f der anderen Flurseite

nach rechts durch eine offen stehende Milchglas-

befindet sich eine weitere Milchglastür, durch

tür, in ein helles, freundliches Büro mit Unmen-

deren Scheibe

gen von Grünpflanzen und offen herumliegenden

schen arbeiten sieht. Entschlossen öffnet Poke

Aktenordnern. V o r dem großen,

vorhanglosen

er schemenhaft

mehrere

Men-

nach kurzem Klopfen die Tür und findet sich in

Fenster thront eine Kaffeemaschine auf einem

einer halogenlichtdurchfluteten

schweren

der. Der Raum mißt gerade etwa 5 mal 6 Meter.

Eichenschreibtisch.

A u f der

linken

Werkstatt

wie-

-

Fallbeschreibung

6 -

Ein g r o ß e s Fenster n i m m t die g e s a m t e gegen-

dosen befinden. E r sucht sich eine g r o ß e D o s e

überliegende W a n d f l ä c h e ein. N a c h rechts führt

roten und w e i ß e n L a c k s heraus und beginnt in

eine M e t a l l t ü r aus d e m R a u m heraus. Direkt vor

der M e t a l l w a n n e eine rosa M i s c h u n g herzustel-

dieser T ü r stapeln sich C o m p u t e r g e h ä u s e ,

len. Als er sichtbar mit dem F a r b t o n z u f r i e d e n

die

einen g r a u oder n e o n f a r b e n b u n t mit Pünktchen,

ist, zieht er aus d e m Z w i s c h e n r a u m eines a n d e -

die a n d e r e n

ren Stahlschranks u n d der W a n d ein Paket mit

marmoriert

oder

chromglänzend.

Das g a n z e Z i m m e r ist m i t t e c h n i s c h e n Geräten,

selbst g e s p r ü h t e n Bildern. Stolz erklärt

K a b e l n u n d C o m p u t e r t e i l e n a u s g e f ü l l t , die in

d e m Gast die B i l d e r hervor. P o k e erfährt, d a ß

den

Ferdi j e d e n Freitag seine Arbeit e i n e

Regalen

ringsum

gestapelt

liegen.

Von

Ferdi Stunde

Platinen, L a u f w e r k e n bis zu M ä u s e n u n d Tasta-

f r ü h e r verlassen darf, u m an einem Kurs

turen, darunter a u c h g l ä n z e n d e aus

Edelholz,

V o l k s h o c h s c h u l e "Die neuen W i l d e n " teilzuneh-

scheint alles w a h l l o s h e r u m z u l i e g e n . A n einer

men. " W i r sollten uns den R e s t noch ansehen",

W e r k b a n k , direkt links v o r d e m großen Fenster,

m e i n t Lutz, u n d Ferdi macht sich w i e d e r a n die

bestückt

munter

Arbeit. Er holt sich a u s dem M o n t a g e r a u m , in

Platinen. A n der d a n e b e n s t e h e n d e n W e r k b a n k ist

dem die beiden a n d e r e n Arbeiter fleißig werkeln,

ein

rundlicher

ein J u g e n d l i c h e r

mit

Mittvierziger

langen

blonden

Haaren

ein T o w e r - u n d ein D e s k t o p - G e h ä u s e und ver-

damit beschäftigt, a n einer Festplatte herumzu-

schwindet

schrauben. D e r M a n n , der an d e r dritten Werk-

Lackierwerkstatt.

bank direkt rechts neben der E i n g a n g s t ü r arbeitet, trägt einen prächtigen B a c k e n b a r t und hat die F ü n f z i g mit Sicherheit schon überschritten. Jetzt k o m m t er a u f P o k e zu und fragt ihn nach seinem Begehr. P o k e stellt sich v o r u n d sofort hellt sich die M i e n e des M a n n e s a u f - z u m i n d e s t vermutet Poke, d a ß sie sich a u f g e h e l l t hätte, w ü r d e der b u s c h i g e Bart nicht so viel v o m Gesicht des M a n n e s verhüllen. A u c h ihn hat sein ehemaliger Studienkollege Willi U n r u h w o h l bereits informiert. Freundlich stellt sich der Bärtige als Lutz L ö t k o l b e n vor, u n d a u f P o k e s Bitten hin erklärt er ihm die A r b e i t s a b l ä u f e in der Werkstatt.

"An

der

wieder

durch

Werkbank

Fenster arbeitet

die

direkt

Metalltüre

vor dem

der

großen

Horst H a m m e r " , erklärt

Lutz

weiter. "Seine A u f g a b e ist es, die Platinen mit S p e i c h e r m o d u l n z u bestücken u n d a n s c h l i e ß e n d die einzelnen K o m p o n e n t e n des C o m p u t e r s nach den W ü n s c h e n d e s K u n d e n z u s a m m e n z u s c h r a u ben: Hauptplatine, Netzteil, F l o p p y - L a u f w e r k e , Harddisk, Graphikadapter, IO-Karte,

Netzkarte

usw.". D a n e b e n arbeitet M a r k M e i ß e l ,

dessen

lange b l o n d e H a a r e bei der Arbeit ständig in Bewegung

sind

und j e d e r energischen

bewegug schwungvoll

Kopf-

folgen. " M a r k ist sieb-

zehn und im zweiten Lehrjahr. Seit zwei W o -

Z u e r s t führt Lutz P o k e durch die Metalltür in den N e b e n r a u m . Dort arbeitet Ferdi

der

Farbecht,

chen macht er a l l e Arbeiten f ü r einen K u n d e nauftrag v o m B e s t ü c k e n bis z u m letzten S c h r a u -

der Lackierer. D e r R a u m ist ü b e r und ü b e r mit

bendreherhandgriff

selbständig."

F a r b s p r e n k e l n bedeckt. A u c h F e r d i s Overall, der

Bestückungsarbeit

noch

ehemals sicher einmal blau war, ist mit vielfarbi-

erkennt

gen F l e c k e n , v o r n e h m l i c h w e i ß e n und grauen,

S I M M - M o d u l n m i t o f f e n b a r g e b r o c h e n e n Plati-

man

an

nicht

seinem

Daß

er

lange

Mülleimer,

die

macht, in

dem

bedeckt. Selbst die Fenster sind gesprenkelt und

nen liegen. An der W a n d v o r ihm hängt

lassen n u r noch einen Teil d e s Sonnenlichts in

überdimensionales

Plakat, das

das Z i m m e r . Ein G e b l ä s e t a u s c h t geräuschvoll

Variantenstückliste

welcher A n z a h l in welche anderen T e i l e einge-

statt mit der A u ß e n l u f t . V o r einer etwa zwei

baut werden m ü s s e n . A n s c h e i n e n d hat j e m a n d

M e t e r breiten L a c k i e r w a n d ,

dieses

U n m e n g e von Poren F a r b d ä m p f e absaugt, steht eine

große

Schläuche

Metallwanne,

an

die

über

eine F a r b p i s t o l e a n g e s c h l o s s e n

Plakat

welche

ein einer

die L ö s u n g s m i t t e l in der L u f t d e r Lackierwerkw e l c h e ü b e r eine

erklärt,

in F o r m

a u f g e h ä n g t , der

nicht

Teile

in

allzuviel

Vertrauen in die Arbeit Meißels legt.

zwei ist.

G e r a d e ö f f n e t Ferdi einen der drei großen Stahlschränke, in denen sich allerlei Färb- und Lack-

L u t z installiert g e w ö h n l i c h das Betriebssystem, nachdem

Horst

oder

Mark

einen

PC

fertig

verschraubt haben. Dabei checkt er a l l e S y s t e m e noch einmal durch, w o f ü r ihm einige elektrische

Fallbeschreibung

Testgeräte zur Verfügung stehen. Anschließend stellt er Maus, Tastatur und Kabelset zusammen und verpackt alles in einem braunen Karton, auf dem in goldenen Lettern strahlt: WIN/LED - You Can't Beat It. Lutz versieht den Karton mit einem grünen Zettelchen, auf dem die Kundennummer und die einzelnen Auftragspositionen stehen. Mit einem gewaltigen Selez-Stöhnen hebt er die Kiste hoch und trägt sie nach unten in den Hof, u m sie in der angemieteten Garage zu verstauen. "Weitere Artikel, wie z.B. der Farbmonitor, werden ungetestet komissioniert", meint Lutz, "die Testerei ist da nur nötig, wenn Ferdi das Gehäuse lackiert hat, sonst nicht." Nachdem er den Monitor und die vom Kunden noch gewünschte Antiionisierungsmatte neben den Karton gestellt hat, hakt er diese Posten auf dem grünen Kärtchen ab. Auf dem Weg nach oben hört man ihn fast immer bis in die Werkstatt fluchen, weil er wieder einmal bestimmte Teile erst nach längerem Suchen in der Garage finden konnte. Er bringt gewöhnlich die Einzelteile mit, die von Mark oder Horst benötigt werden, und ebenfalls in der Garage lagern. M i t der Bemerkung, daß sein Kaffee kalt würde, verläßt Poke nun die Werkstatt, nicht ohne Lutz für die Informationen gedankt zu haben. Als Poke in Trudes Büro kommt, sieht er sie fleißig Briefe schreiben. Als hätte er sie durch sein Eintreten aktiviert, beginnt sie sofort wieder auf ihn einzureden. Neben einigen Informationen über das Verkehrschaos jeden Morgen in der Stadt, ihren Aerobic-Kurs und das aktuelle Kinoprogramm erfahrt Poke etwas über ihre Arbeit: Vor ihr liegen drei Briefe, welche am Freitag angekommen sind und in denen einige Computer bestellt werden. Trude stempelt die Schreiben mit dem Datum und vermerkt dort auch die Kundennummer, nachdem sie die N u m m e r aus ihrem Karteikasten, den Ferdi rosarot lackiert hat, herausgesucht hat. Für einen offensichtlich neuen Kunden legt sie eine neue rosa Karte an und notiert dort Adresse, Telefonund Faxnummer. Dazu vermerkt sie noch die Zahlungsbedingungen: "251020". Sie erklärt Poke, daß allen Kunden zunächst 2,5% Skonto für 10 Tage und 20 Tage netto angeboten würden, allerdings werden auch Sonderkonditionen

-7-

für besonders wichtige Kunden eingeräumt. Für zwei Aufträge schreibt sie daraufhin jeweils ein grünes Zettelchen, das die wichtigsten Informationen für die weitere Bearbeitung enthält: Kundennummer und Datum, Typ, Farbe und Anzahl der bestellten Computer, den vereinbarten Preis und das gewünschte Lieferdatum. "Dieser Auftrag kann nicht stimmen", meint Trude, "ein 486er mit 2 MB R A M geht bei uns so nicht raus, und schon gar nicht als NovellServer mit einer Mylex-Busmasterkarte." Poke, staunt über Trudes Computer-Know-How. Lutz schaut ins Zimmer und teilt Trude mit, die inzwischen mit dem Kunden telefoniert, daß ein bestimmter Computer fertiggestellt wurde und in der Garage auf seine Auslieferung wartet. Dabei reicht er ihr das entsprechende grüne Kärtchen. Die gerade von ihr neu geschriebenen Kärtchen nimmt er rasch an sich. "Außerdem brauchen wir mal wieder Mäuse. Die Garage ist fast mauslos. Die vorhandenen reichen nur noch etwa eine Woche." "Welche braucht Ihr denn?" Trude legt den Telefonhörer auf die Gabel. "Ich könnte gleich die Bestellungen rausgeben." "Wenn möglich 10 Microsoft, 5 Trackballs, 2 Mousepen und 5 Edelnager, am liebsten die bunten von Colani." "Okay, ich laß' das kommen." Tipp hat sich Lutz' Wünsche notiert und holt einen Ordner aus ihrem Schreibtisch, der alle Preise ihrer Lieferanten enthält. Mit Hilfe der Preislisten kann sie die günstigsten Lieferanten für ihre Bestellungen ermitteln, dabei sortiert sie immer die älteren Angebote aus und die günstigsten Angebote im Ordner nach vorne. Kaum hat Lutz das Zimmer verlassen, klingelt das Telefon, so daß Trude ihren Ordner offen auf die übrigen wahllos herumliegenden Ordner stapelt. Ein Grundstücksmakler möchte wissen, welche Netzwerk- und Rechnerkonfiguration für ihn geeignet wäre. Trude stellt ihm wenige, aber sehr präzise Fragen nach Art und Umfang der eingesetzten Anwendungen und den Umfang der zu verarbeitenden Daten. Schließlich kann sie ihren Gesprächspartner von den Vorzügen einer Lite-Konfiguration überzeugen, die aus einem Lite-Netzwerk mit drei jeweils in der Lieblingsfarbe der Benutzer lackierten 386SXern besteht. Da der Kunde noch nicht bei COLOWIN gekauft hat, bittet ihn Tipp um die Adressdaten. "Per Fax

Fallbeschreibung

- 8 -

geht u n s e r A n g e b o t n o c h heute a n Sie

raus.",

A u f d e m W e g ü b e r den H o f erklärt Willi, d a ß er T r u d e hin und w i e d e r unter die A r m e greift,

meint s i e mit s i c h e r b e t o n t e r S t i m m e . T r u d e fahrt m i t der A u s a r b e i t u n g der Bestell-

w e n n sie viel zu t u n hat.

posten f o r t . W e n n sie sich beeilt, s o meint sie,

Im

k ö n n e n d i e B e s t e l l u n g e n n o c h h e u t e per Fax

zunächst einer attraktiven Frau vorgestellt, d e r

Café

Milano

angekommen,

wird

Peter

r a u s g e h e n . Mit lautem S c h l ü s s e l k l a p p e m trifft

Besitzerin, w i e er von U n r u h erfahrt, die g e m e i n -

A u g u s t - W i l h e l m U n r u h ein. W ä h r e n d er elegant

s a m mit U n r u h studiert u n d , w i e er, n a c h d e m

zwei

Briefe auf

Trudes

ohnehin

überfüllten

dritten

Semester

die

akademische

Laufbahn

Schreibtisch s c h l e u d e r t , m u r m e l t er leicht ver-

beendet habe. Willi ordert einen K a f f e e C o r e t t o ,

schlafen:

f ü r P o k e läßt er einen C a f é Latte u n d eine M o k -

" M o r g e n T r u d e , zwei

Bestellungen,

k a m e n g e r a d e m i t der Post!". P o k e sieht er eben

kaschnitte bringen. D a n n erklärt er ihm die N ö t e

erst hinter den G r ü n p f l a n z e n sitzen: "Alte Socke,

seiner

da bist D u endlich." P o k e erwidert ein zaghaftes

Informationen

"Hallo",

oder darüber, w a s die M o n t a g e kostet;

diese

Art

Begrüßung

hätte

er

sich

Firma:

"Zugegeben, über

wir

unsere

haben

keine

Deckungsbeiträge Preise

sparen k ö n n e n , denkt er, auch w e n n er und Willi

m a c h e n w i r aus d e m B a u c h heraus. D a s m a c h t

damals i m B W L - S t u d i u m bei einigen Klausuren

a u c h Anette, die i n z w i s c h e n noch drei a n d e r e

ö f t e r hätten antreten m ü s s e n ; a u ß e r d e m setze er

C a f é s besitzt, nicht anders. W a s fehlt, ist ein f ü r

jetzt noch ein W I N - S t u d i u m drauf, d a s finanziert

unseren L a d e n z u g e s c h n i t t e n e s S y s t e m , das d i e

sein will. D a z w i s c h e n fragt U n r u h s e i n e Sekretä-

Fakturierung, das L a g e r u n d die B e s c h a f f u n g

rin,

ü b e r n i m m t . D a n n k ö n n t e n wir darauf die K o -

ob

etwa

Arbeit

anliegen

würde.

"Diese

R e c h n e r sind f e r t i g g e w o r d e n und m ü s s e n noch

stenrechnung

mit U P S raus, d i e R e c h n u n g e n m u ß ich aber erst

a u f b a u e n . B e g i n n e n wir mit der B e s c h a f f u n g :

noch tippen, ich lege sie gleich

mit zu den

P a k e t e n ! " Sie drückt Willi die g r ü n e n Zettelchen in die H a n d . "Ich m u ß dann noch ein paar Angeb o t e an unsere K u n d e n verschicken, die Preissenkung bitte

für den 486LED.

darum

kümmern?"

K ö n n t e s t Du dich Sie

übergibt

Willi

vorsichtig mit d e n A u g e n k l i m p e r n d den rosa Karteikasten. " O k a y " , sagt U n r u h , "ich laß das erst mal h i e r liegen u n d gehe mit P e t e r rüber ins C a f é M i l a n o - z u m F r ü h s t ü c k . W i r sind wahrscheinlich erst h e u t e n a c h m i t t a g z u r ü c k , da wir die g a n z e n A b l ä u f e w e g e n der S y s t e m p l a n u n g b e s p r e c h e n m ü s s e n . " T r u d e nickt ein wenig und läßt sich z u r ü c k in ihren Bürostuhl fallen.

mit

Vor-

und

Nachkalkulation

L i e f e r a n t e n schicken u n s regelmäßig, das heißt fast j e d e n M o r g e n quillt u n s e r Faxgerät d a v o n über,

oder

mehrere Diese

auf

Anfrage

Lieferangebote,

Lieferpositionen Positionen

umfassen

enthalten

die

können.

gewöhnlich

die

T y p b e z e i c h n u n g , die lieferantenseitige N u m e r i e rung und die Preise j e n a c h Rabattstufe. W i r brauchen

davon

Angaben

bei der B e s t e l l u n g als

immer

nur

die

aktuellsten Lieferkondi-

tionen. C h i c w ä r e es, w e n n wir h e r a u s f i n d e n könnten, w i e lange die Lieferzeit eines L i e f e r a n ten durchschnittlich j e Materialtyp ausfällt, o d e r wie g ü n s t i g seine Preise im Vergleich zu a n d e r e n Anbietern sind - u n d das a u f K n o p f d r u c k . W i r

S i e rückt ihren Stuhl zurecht und tippt hastig in

bestellen

die

Rechnungen

g e w ö h n l i c h m e h r e r e P o s i t i o n e n a u f einmal. D i e

fertig hat, w e r d e n sie auf die P a k e t e in der

A n g a b e n sind a u c h w i e d e r die T y p - N u m m e r d e s

Garage g e k l e b t , " erklärt Willi Peter beim Hin-

Lieferanten, sofern w i r e i n e haben, die B e z e i c h -

Tastatur.

"Wenn

Trude

die

bei

unseren

Lieferanten

Material,

a u s g e h e n , "das heißt, w e n n es ihr gelingt, von

nung, der vereinbarte Preis und die M e n g e j e

L u t z in E r f a h r u n g zu b r i n g e n , w o sich denn in

Materialtyp. W a r e n e i n g ä n g e mit den Einzelposi-

der G a r a g e die richtigen Pakete b e f i n d e n . Da

tionen

m ü s s e n w i r noch b e s s e r werden!" Im H o f ange-

W a r e n e i n g a n g s p o s i t i o n w i r d die B e s t e l l a u f t r a g s -

kommen

position h e r a u s g e s u c h t u n d abgehakt. Es k o m m t

w e r f e n sie n o c h einen B l i c k in die

Garage, d i e c h a o t i s c h

organisiert scheint. Bis

werden

sorgfältig

verbucht.

Zu

jeder

schon mal vor, d a ß Lieferanten Teil- oder S a m -

u n t e r die Decke sind g r o ß e u n d k l e i n e Kartons,

mellieferungen

teilweise offen, t e i l w e i s e z u g e k l e b t ,

schicken; da ist die B e s t e l l u n g s z u o r d n u n g nicht

gestapelt.

oder

nicht

bestelltes

Material

Fallbeschreibung

- 9 -

erste

natürlich vorher erfassen." "O.K., d e r Material-

ersten

verbrauch gibt den Z e i t p u n k t und d i e M e n g e ,

L i e f e r u n g zu. D a s ist eine a u f w e n d i g e Sache,

den Materialtyp u n d den Lagerort a n , von dem

immer

ganz

einfach.

offene Bestellung weil

Trude

Wir

und

dann

nehmen

die

ordnen sie der

auf

ihrem

Schreibtisch

die

das Teil e n t n o m m e n wurde. B e i m A r t i k e l z u g a n g

Ordner d u r c h e i n a n d e r b r i n g t u n d schon mal die

braucht m a n nur den T y p des Artikels,

A u f t r ä g e d e r falschen Lieferanten abhakt. Unver-

Zeitpunkt der Fertigstellung und d i e A n g a b e ,

langte

w o h i n er eingelagert wurde." P o k e schreibt diese

Lieferungen

behalten

wir,

wenn

die

Waren g e r a d e gebraucht werden, sonst - sofern

Angaben

T r u d e d a s ü b e r h a u p t merkt - schicken wir sie

Notizblock

zurück. D i e Positionen der E i n g a n g s r e c h n u n g e n

scheint

k ö n n e n w i r g e n a u s o den Wareneingangspositio-

Unterklasse von T e i l e t y p zu sein. E i n Teiletyp

nen z u o r d n e n . Hier gibt es a u c h Fälle mit Teil-

lagert mit einer b e s t i m m t e n M e n g e an

und unter

unsere

Ausnutzung

und

ebenso

inzwischen

fahrt wie

fort:

verkritzelten

"Der

Materialtyp

Artikeltyp

so

eine

Lagerort: D a s ist dann der L a g e r b e s t a n d ,

Eingangsrechnungen

stets

jeweils

von

Skontoabzügen.

Es

bei

Zugängen

oder

Abgängen

Rechnungen

einen Schluck Kaffee.

einmal

oder

nur

Abschläge

zahlen." " W e r d e n die Z a h l u n g e n nicht in der erfaßt?"

wirft

Poke

ein.

"Richtig, d a r u m m u ß sich das neue S y s t e m nicht k ü m m e r n , a b e r ich sollte wissen, w e l c h e Rechn u n g e n n o c h o f f e n sind!" "Das kann doch bes t i m m t die K H K - F i b u ü b e r o f f e n e Posten verwalten",

m e i n t P o k e salopp.

"Nun,

ich

weiß

nicht, vielleicht kannst D u es j a herausfinden? Jedenfalls b r a u c h e ich diese Funktion."

"Unsere

Artikel,"

Unruh,

Null

nimmt

"werden

in

einer Liste mit den n o t w e n d i g e n A n g a b e n wie V e r k a u f s p r e i s und M e h r w e r t s t e u e r s a t z gefuhrt. Wir bieten diese a u f A n f r a g e unseren K u n d e n in einzelnen A n g e b o t s p o s i t i o n e n

zu j e w e i l s

auch

speziell ausgehandelten Preisen an. W e n n

ein

K u n d e spezielle W ü n s c h e hat, die einen neuen Artikeltyp a u s m a c h e n , Angebotspalette.

" W a s passiert mit den W a r e n e i n g ä n g e n , " fragt

erklärt

der bzw.

V e r b r a u c h e n neu errechnet w e r d e n m u ß . P r o b l e m o ! " fugt P o k e cool hinzu u n d

Finanzbuchhaltung

einem

nach

Wir

k o m m t d a b e i eigentlich nie vor, daß w i r mehrere auf

Art

bezahlen

Sammelrechnungen.

Möglichkeit

a u f seinen

den

vergrößert sich

Unsere

Kunden

unsere

können

von

uns alle P r o d u k t e u n d , a u f W u n s c h , a u c h spe-

P o k e , " w e r d e n die alle w a h l l o s im L a g e r ver-

zielle Materialtypen, z.B. Ersatzteile, beziehen.

staut?" " B i s h e r fuhrt L u t z dort Regie, und ich

T r u d e führt alle K u n d e n nach N u m m e r n sortiert

furchte, d a ß außer Lutz im Lager keiner Be-

im rosa Karteikasten. W i e u n s e r e A u f t r ä g e erfaßt

scheid w e i ß . " Poke schlägt daraufhin ein Lager-

w e r d e n , mit den einzelnen Positionen i m grünen

verwaltungssystem

Karteikasten, hast D u vielleicht schon gesehen.

mit

definierten

Lagerorten

vor, d i e einzelnen Lagerplätzen zugeordnet sind,

D i e R e c h n u n g e n , die g e n a u für j e d e A u f t r a g s p o -

u m das W i e d e r a u f f i n d e n von Material sicherzu-

sition eine R e c h n u n g s p o s i t i o n enthalten,

stellen. Ü b e r die A u f z e i c h n u n g , welche W a r e n -

w i r j e w e i l s bei der A u s l i e f e r u n g bei; m i t Liefer-

eingangspositionen

auf

welche

Lagerorte

in

legen

scheinen haben wir nichts zu t u n . Bei K u n d e n -

w e l c h e r A n z a h l verteilt w u r d e n , kann dann sehr

z a h l u n g e n werden die R e c h n u n g s n u m m e r n

von

schnell

den

sind

ein

Teil

gefunden

und

entnommen

Kunden

angegeben.

Problematisch

w e r d e n , u m es in ein anderes Teil einzubauen

u n s e r e M a h n u n g e n : L e i d e r m ü s s e n wir, das heißt

oder

kommissionieren.

Trude, erst in der Liste der A u s g a n g s r e c h n u n g e n

Dabei m u ß natürlich auch die Z u o r d n u n g von

n a c h s e h e n u n d abhaken, ob eine Z a h l u n g s c h o n

einem

e i n g e g a n g e n ist." P o k e unterbricht ihn: " A b e r

als

Artikel

direkt

Lagerort zu

zu

einer Position einer

Aus-

g a n g s r e c h n u n g verzeichnet werden. " A u s dem

die Z a h l u n g e n und die M a h n u n g e n

Saldo b e i d e r Tabellen läßt sich leicht der Lager-

K H K - F i b u ü b e r n e h m e n , das ist doch

bestand ermitteln. " D a s s t i m m t nicht ganz," wirft

f ü r eine Fibu, die o f f e n e Posten v e r w a l t e n kann.

Unruh

D a sehe ich keine P r o b l e m e ; ü b e r eine Schnitt-

ein.

"Die

Materialentnahmen

für

die

kann

die

Standard

M o n t a g e u n d die Z u g ä n g e aus d e n fertiggestell-

stelle w e r d e n die A u s g a n g s r e c h n u n g e n an

ten Teilen

F i b u gepipt, dann ist der Fall erledigt. P r o b l e m e

mußt

Du

auch hinzunehmen

und

die

-

Fallbeschreibung

10-

gibt

es s c h o n

eher bei

der

Kostenrechnung.

W e n n s p ä t e r e i n e Vorkalkulation

angegangen

werden soll, m u ß doch erst m a l die Erzeugnis-

erschöpft, vor M ü d i g k e i t w ä r e er fast a u s d e m Stuhl

gerutscht.

Er

nickt

zaghaft

"mmmh".

U n r u h winkt lässig hinüber z u m T r e s e n , hinter

struktur d e r T e i l e t y p e n festgehalten werden und

d e m gerade die h ü b s c h e E x - S t u d e n t i n

dazu j e w e i l s die Selbstkosten, a b e r die kennt Ihr

spült. " N o c h zwei C a f é Coretto" u n d f a h r t fort:

Gläser

doch gar nicht in E u r e m Listen- und Ordnersy-

"Beim

s t e m ! " U n r u h runzelt n a c h d e n k l i c h die Stirn und

vergessen, dabei w e r d e n die Istbestände e i n g e g e -

w i r f t ein: "Das m a g sein. D u hast recht, wir

b e n , und das S y s t e m sollte die A b w e i c h u n g e n zu

L a g e r solltest

Du

die

Inventur

nicht

stellen d i e K o s t e n r e c h n u n g b e s s e r erst einmal

den gespeicherten B e s t ä n d e n a n g e b e n u n d als

zurück." " D a s d e n k e ich a u c h " , pflichtet Poke

V e r b r a u c h einbuchen. Für eine frei zu w ä h l e n d e

ihm bei, " m i t d e m b i s h e r beschriebenen System

Periode, v o r allen D i n g e n beim J a h r e s a b s c h l u ß

habe ich s c h o n g e n u g z u tun! Ich benötige jetzt

fflr das F i n a n z a m t , m ü ß t e ich a u c h n o c h die

noch A n g a b e n ü b e r die F u n k t i o n e n des Systems,

V e r b r a u c h e und B e s t a n d s w e r t e , b e w e r t e t

w e n n es m e h r k ö n n e n soll als n u r die elementare

F I F O oder L I F O , ermitteln k ö n n e n .

Verwaltung Eurer Daten."

nach

B e i der Faktura sind zwei V o r g ä n g e wichtig, die

" D i e F u n k t i o n e n sollten sich nach den Vorgän-

K u n d e n a u f t r a g s a n n a h m e und die A u s l i e f e r u n g .

gen in u n s e r e m G e s c h ä f t richten. Dazu gehört

Bei einer t e l e f o n i s c h e n oder schriftlichen Bestel-

a u f der B e s c h a f f u n g s s e i t e das Schreiben

lung

von

sollte m a n falls

sofort K u n d e n

erforderlich,

neu

oder

anlegen

B e s t e l l a u f t r ä g e n , dabei sollte man die Bestell-

können,

Artikel

m e n g e m a n u e l l eingeben oder automatisch alle

erfassen können, falls notwendig, d i e B e s t e l l u n g

neu

notwendigen

können,

d e r entsprechenden Teiletypen m u ß a u c h sofort

a u f K n o p f d r u c k , versteht sich. Der Lieferanten-

m ö g l i c h sein, s o f e r n ein Lieferant d a f ü r in der

vorschlag f ü r ein b e s t i m m t e s Teil wäre chic.

K o n d i t i o n e n l i s t e v e r f u g b a r ist. Der A u s d r u c k des

Bestellungen

rauslassen

M a n c h e T e i l e m ü s s e n j a i m m e r a u f Lager sein,

K u n d e n a u f t r a g s geht dann als B e s t ä t i g u n g - bei

w i e z.B. F l o p p y - L a u f w e r k e u n d Mäuse. Andere

t e l e f o n i s c h e r V e r e i n b a r u n g - an den K u n d e n u n d

Teile w e r d e n erst bestellt, w e n n ein spezieller

e i n e K o p i e an L u t z für die M o n t a g e . " D e r jetzt

Kundenauftrag

dafür

in Fahrt g e k o m m e n e Willi n i m m t hastig einen

Systemplatinen.

Man

vorliegt,

z.B.

EISAKenn-

S c h l u c k Kaffee. "Nach der Fertigstellung wird

z e i c h n u n g festhalten u n d den Meldebestand für

d i e R e c h n u n g mit allen Positionen erfaßt u n d a u f

j e d e n T e i l e t y p f u h r e n k ö n n e n . Über einen Ver-

d i e Kiste geklebt, die ich j a dann g e m ä ß D e i n e m

gleich v o n L a g e r b e s t ä n d e n mit den Meldebestän-

V o r s c h l a g sofort im Lager an einem b e s t i m m t e n

den kann ich - oder besser T r u d e - eine automati-

O r t finden kann. B e i m Versand b r a u c h e ich nur

sollte

dazu eine

sche B e s t e l l u n g der T e i l e veranlassen. Bei der

noch

E r f a s s u n g der K u n d e n a u f t r ä g e sollte man auch

w a h r ? " P o k e wirkt sehr beeindruckt

von

der

die zusätzlichen Teile, die w i r

Vorstellungskraft

Ob

das

normalerweise

die

Lagerbewegung seines

zu

buchen,

Gegenüber.

nicht

die

w o h l mit " m a n a g e m e n t by visión" g e m e i n t war,

B e s t e l l a u f t r ä g e r a u s g e g a n g e n sind, ist die Über-

überlegt er. " U n d noch etwas solltest D u nicht

w a c h u n g o f f e n e r B e s t e l l a u f t r ä g e wichtig, weil

vergessen," unterbricht ihn Willi bei der F o r t f ü h -

m a n c h e Lieferanten d a fürchterlich

r u n g seines G e d a n k e n s : " W e n n m a l ein S y s t e m

nicht f u h r e n , bestellen

können. Nachdem

schlampig

sind. B e i m W a r e n e i n g a n g m u ß auch der Lager-

nicht so läuft, dann g e b e n wir dem

zugang g e b u c h t w e r d e n und die Z u o r d n u n g zur

schon mal eine Gutschrift, die m u ß a u c h wie die

Kunden

Lieferungen

R e c h n u n g erfaßt werden u n d an die Fibu rausge-

verspätet eintreffen, w ä r e das irgendwie anzuzei-

schickt werden." Sichtlich erleichtert ü b e r den

gen. B e i der E r f a s s u n g der

beendeten Redeschwall U n r u h s richtet er noch

Bestellposition

muß

d e r Preis

erfolgen.

gegenüber

Wenn

Eingangsrechnung dem

Bestellauftrag

e i n e F r a g e an seinen E x - K o m m i l i t o n e n

Unruh:

ü b e r p r ü f t w e r d e n . D i e R e c h n u n g wird dann ü b e r

" W a n n soll das S y s t e m laufen?" U n r u h

eine Schnittstelle an d i e Fibu geschickt; das ist

seine linke A u g e n b r a u e

doch

erwidert: "Nach Möglichkeit s c h o n m o r g e n . "

Deine

Überlegung?"

Poke

wirkt

etwas

ein w e n i g

zieht

hoch

und

Ziele der Systementwicklung

- 11 -

3. Grundlagen der Systementwicklung 1) Die Systementwicklung bezeichnet den Prozeß der Gestaltung von Informations- und Kommunikationssystemen. Der Systementwicklungsprozeß umfaßt sowohl die Planung als auch die Implementierung, d.h. die Umsetzung des Systementwurfs in eine durch einen Rechner ausführbare Form. Im Mittelpunkt der folgenden Ausführungen stehen betriebswirtschaftliche Anwendungssysteme, die auch als rechnergestützte betriebliche Informationssysteme, kurz Informationssysteme, bezeichnet werden.

3.1. Ziele der Systementwicklung Ein System besteht aus einer Menge wohldefinierter Elemente, die über bestimmte Eigenschaften verfügen, zur Erreichung eines Systemziels beitragen und durch Beziehungen miteinander verbunden sind. Die Elemente eines Informationssystems bilden Informationen und Aktionen. Aktionen sind zweckgerichtete Handlungsfolgen, die von Menschen oder Maschinen ausgeführt werden. Informationen treten als Input oder Output von Aktionen auf, sie tragen eine Bedeutung und werden als Mitteilungen oder Nachrichten von den Aktionsträgern verstanden. Aus den Beziehungen zwischen den Systemelementen kann man die Struktur des Systems ableiten. Die Struktur eines Systems bezeichnet den Aufbau des Bezugssystems als Ganzes. Die Strukturierung führt die Zerlegung eines komplex erscheinenden Gesamtsystems durch, um ein Verständnis für die Funktionsweise und die Beziehungsgeflechte zwischen den einzelnen Elementen zu gewinnen. Die sukzessive Zerlegung schreitet vom Systemganzen zu seinen Einzeltellen, dieses Verfahren wird auch Top-Down-Vorgehen genannt. Auf die Zerlegung eines Systems folgt die Integration, die Herstellung der Vollständigkeit und Ganzheit des Systems. Die Zusammenführung der Teilsysteme, die auch als Aufgabensynthese bezeichnet wird, vollzieht sich entgegengesetzt zum Strukturierungsprozeß, nämlich bottom-up. Beide Vorgehenswelsen werden bei der Systemanalyse bzw. -entwicklung abwechselnd und je nach Zweckmäßigkeit eingesetzt. Die Systementwicklung Ist mit soziotechnlschen Systemen befaßt, die neu gestaltet oder verbessert werden sollen. Die Ziele der Systementwicklung leiten sich aus den organisatorischen Zielsetzungen des soziotechnischen Systems ab, in dem das Informationssystem eingerichtet werden soll. Das zu planende System soll betriebliche Aufgaben in bestimmten Anwendungsbereichen erfüllen, daher ist das Sachziel der Systementwicklung für jedes Projekt gesondert zu bestimmen. Die Anordnung von Systemelementen zu Teilsystemen und deren Ordnung innerhalb eines Systems folgt Prinzipien, die in der Organisationslehre im Zusammenhang mit der zweckmäßigen Aufgabenstrukturierung weithin Verbreitung gefunden haben. Analog zu den Zielsetzungen des Organisationsmanagements können wir festhalten, daß Aufgaben und

Ausgewählte Literaturhinweise zu diesem Kapitel: Heilmann, H., Heilmann, W „ Strukturierte Systemplanung und Systementwicklung, Stuttgart I979; Balzert, H „ Die Entwicklung von Software-Systemen, Mannheim I982;

-

Ziele der Systementwicklung

12-

Informationen auf die Aktionsträger Mensch und Arbeitsmittel (Maschine) so verteilt werden sollen, daß insgesamt die Erledigung der Aufgaben zur Erreichung der übergeordneten Ziele, z.B. der Unternehmensziele, in höchstem Maße beiträgt. Aus der Organisationstheorie ist bekannt, daß mit zunehmender Zerlegung und Verteilung der Aufgaben auf Teilsysteme

(Strukturierung)

der Aufwand für die

Koordination

dieser

Teilsysteme

(Integration) ansteigt. Dieser Effekt bedingt im Planungsprozeß, daß eventuell mehrere Schritte der Strukturierung und Integration aufeinanderfolgen müssen, bis das konstruierte System eine, je nach Typ und Umfang der Gesamtaufgabe, ideal erscheinende (optimalkomplexe) Struktur aufweist. Das Grundgerüst eines Systems wird mit dem Ziel größtmöglicher Geltungsdauer konzipiert, da eine Reorganisation der Makro-Struktur erhebliche Probleme bereitet. Dieser Zielsetzung entspricht die Forderung nach Stabilität des Systems. Die Stabilität einer Problemlösung hängt grundsätzlich von der Allgemeingültigkeit der Problembeschreibung ab, für die ein Lösungsverfahren konzipiert wird. Daher muß versucht werden, die Problemstellung auf die allgemein gültigen Strukturen hin zu analysieren und diese in einer allgemein gültigen Form zu lösen. Daraus leitet sich ein positiver Effekt für die Wiederverwendbarkeit von Problemlösungen (Algorithmen) ab. Ausgehend von der Zielsetzung der Stabilität läßt sich eine weitere Überlegung entwickeln. Änderungen des Systems, die unabdingbar nach der Implementierung durchgeführt werden müssen, sollen nur diejenigen Teilsysteme betreffen, die unmittelbar Objekte dieser Änderung sind. Andere Teilsysteme sollen nach Möglichkeit stabil bleiben. Wir fordern aus diesem Zusammenhang, daß ein System modular gestaltet werden soll. Die Stabilität eines Systems ergibt sich aus der Stabilität seiner Elemente bzw. Teilsysteme und der notwendigen Koordination zwischen diesen Komponenten. Module sind selbständige Untersysteme, die möglichst wenige Verknüpfungen zu anderen Teilsystemen aufweisen. Durch das Prinzip der minimalen Schnittstelle ermöglicht die Modularisierung eine bessere Überschaubarkeit des Systems. Darüberhinaus werden die Umsetzbarkeit und die Wartungsfähigkeit verbessert. Hierarchisch organisierte Systeme erfüllen die Anforderung der Modularität durch die Verwendung der Baumstruktur am besten. Informationssysteme werden zweckmäßig konzipiert, sodaß sie die Rahmenbedingungen einer aufbauorganisatorischen Grundstruktur erfüllen. Im organisatorischen Gestaltungsprozeß übernehmen Informationssysteme die Funktion eines Instruments zur Erreichung der übergeordneten Leistungsziele. Die Gestaltungsmöglichkeiten (Effektivität) und die Effizienz alternativer Maßnahmen bestimmen als wesentliche Kriterien die Entscheidung über die Einführung eines Informationssystems. Aus diesen Gründen wird nicht nur vom ablauffähigen System, sondern auch vom Prozeß der Systementwicklung selbst, Effizienz gefordert, d.h. ein definiertes Sachziel soll mit minimalem Mitteleinsatz erreicht werden. Der Inhalt und der Umfang eines Informationssystems werden durch die Beschreibung seiner Funktionen festgelegt. Vom lauffähigen System erwartet man, daß alle Funktionen

Ziele der Systementwicklung

- 13-

vollständig und korrekt realisiert sind. Anhand geeigneter Testläufe wird dies abgeprüft. Die Zuverlässigkeit des Systems, die unmittelbar von der Korrektheit aller Teilfunktionen abhängt, kann jedoch weder theoretisch bewiesen noch praktisch vollständig gesichert werden. Daher kann dieses Ziel nur, den jeweiligen Einsatzbedingungen entsprechend, angenähert werden. Die Effektivität eines Informationssystems wird durch die Spezifikation des Funktionsumfangs als Ziel definiert. Ist das Effektivitätsziel im Zeitablauf gewährleistet, spricht man von einer hohen Systemstabilität. Auch bei unterschiedlichen organisatorischen und technischen Anwendungsbedingungen muß ein System zuverlässig und effizient funktionieren. Aus der Sicht des Anwenders stellen zusätzlich die Einfachheit der Steuerung und Handhabung ein wichtiges Akzeptanzkriterium dar. Die genannten Zielsetzungen und deren Zusammenhänge werden in der folgenden Abbildung veranschaulicht.

Die Systementwicklung muß effizient erfolgen, d.h. die Systementwickler sollten eine möglichst hohe Produktivität erreichen und dabei das Subziel verfolgen, ein modulares System zu entwerfen, das als Ganzes oder in Teilen auch für später zu entwickelnde Systeme verwendet werden kann. Daraus leitet sich wiederum ein positiver Effekt für die Produktivität in nachfolgenden Projekten ab. Die Produktivität wird durch die Verwendung von Konzepten zur Dekomposition und zur Modularisierung erhöht, da überschaubare Teilfunktionen unabhängig voneinander und ggf. von Spezialisten bearbeitet werden können. In diesem Zusammenhang darf nicht unbeachtet bleiben, daß die Machbarkeit eines Informationssystems von organisatorischen und technischen Mitteln abhängt, deren Bereitstellung die Effizienz der Systementwicklung steigern kann. Jedoch sind mit derartigen Verbesserungen unter Umständen höhere Kosten während der Entwicklungs- und Einsatzzeit verbunden.

Vorgehensmodell

-14-

3.2. Vorgehensmodelli> Die planvolle, systematische Vorgehensweise zur Entwicklung eines Informationssystems wird als Vorgehensmodell der Systemplanung bezeichnet. Ein Vorgehensmodell unterteilt den Gestaltungsprozeß in überschaubare, zeitlich und inhaltlich begrenzte Schritte, sogenannte Phasen, um ein System, das insgesamt sehr komplex erscheint, schrittweise zu realisieren. Unter dem Begriff "Methodik der Systemplanung" wird der Versuch verstanden, für alle denkbaren Systementwicklungsprojekte eine einheitlich leistungsfähige Vorgehensweise zu entwickeln. Die Konzeption einer solchen, ¡dealtypischen Vorgehensweise erscheint jedoch unter Beachtung empirischer Befunde fragwürdig, wonach die Leistungsfähigkeit eines Vorgehensmodells in Abhängigkeit vom Gestaltungsobjekt stark variiert. Das Vorgehensmodell als verbindliche Beschreibung der Projektaktivitäten ist daher selbst ein erstes Ergebnis der Projektarbeit. Empirische Untersuchungen haben gezeigt, daß die Entwicklungskosten eines typischen Anwendungssystems etwa in doppelter Höhe von den Kosten für Wartung und Pflege übertroffen werden2'. Im Hinblick auf diesen Zusammenhang sind zahlreiche Methodiken mit dem Ziel vorgeschlagen worden, bereits in frühen Phasen der Systementwicklung möglichst präzise Anforderungen zu gewinnen, um spätere Kosten für Systemänderungen bzw. Nachbesserungen zu vermeiden. Zu diesen neueren Ansätzen zählt das explorative Vorgehen, in dessen Mittelpunkt ein schnell verfügbares Anwendungssystem als Prototyp steht, das als Erkenntnisobjekt für Anwender und Entwickler dient. Vielfach werden Prototypen auch entwickelt, um die nicht selten überzogene Erwartungshaltung von Anwendern auf ein realisierbares Maß zurückzuführen. Das Problemfeld der Anforderungsgewinnung (Requirements Engineering) ist zu einem wesentlichen Teil durch Kommunikationsprobleme zwischen Anwendern und Entwicklern gekennzeichnet. Daher wird langfristig bei der Suche nach effizienten Verfahren zur Systementwicklung der Anwender stärkere Beachtung erfahren müssen. Dies könnte dadurch erreicht werden, daß der Anwender seine Anforderungen in einer für ihn und den Entwickler verständlichen, notwendigerweise formalen Sprache verbindlich definiert. Auf diese Weise können der Entwicklungsaufwand und das Fehlerpotential reduziert werden, da der Systementwickler als DV-Experte nicht zusätzlich die relevanten Wissensbereiche des Anwendungsfachgebiets erlernen muß. Bei der Festlegung der funktionalen Anforderungen an ein System, d.h. der Angaben darüber, was es leisten soll, kann ein Funktionsmodell der Unternehmung als Entwicklungsrahmen für notwendige Informationssysteme dienen. Im Unternehmensfunktionsmodell Ausgewählte Literaturhinweise zu diesem Kapitel: Balzert, H., Die Entwicklung v o n Software-Systemen, Mannheim 1982; Chroust, G., Modelle der Software-Entwicklung, München I992; Z u m Vergleich: D i e durchschnittlichen Aufwendungen für W a r t u n g und Pflege eines Automobils, das als abnutzbares Wirtschaftsgut dem Verschleiß unterliegt, betragen ca. 30%-50% der Anschaffungskosten.

Vorgehensmodell

- 15-

werden alle Informationsverarbeitungsaufgaben, die zur Erreichung der Unternehmensziele geleistet werden müssen, nach betriebswirtschaftlichen Kriterien strukturiert und als verbindliche und stabile Basis der strategischen Informationsplanung festgelegt. Unternehmensmodelle, vor allem unternehmensweite Datenmodelle, ermöglichen als bereichsübergreifende Planungsinstrumente die nutzbringende

Integration von Informations-

und

Kommunikationssystemen. Dem theoretischen Potential, der deduktiven Gewinnung von Anforderungen für neu zu entwickelnde Anwendungssysteme, steht dabei jedoch der hohe Aufwand zur Erstellung unternehmensweiter Modelle entgegen. Als neuerer Versuch, die Systementwicklungs- und Folgekosten zu reduzieren, kann der verstärkte Einsatz von Werkzeugen, wie etwa CASE-Tools, zur Unterstützung der Systemplanung angesehen werden. Durch die Automatisierung von selbständigen Teilaufgaben der Systemplanung, die programmierbar sind, kann die Korrektheit eines Systementwurfs besser gesichert und die Effizienz gesteigert werden. Für die Unterstützung durch Entwicklungswerkzeuge gilt jedoch auch dieselbe Einschränkung wie für die Methodiken zur Systementwicklung. Aufgrund der spezifischen Leistungsfähigkeit der Verfahren und Modelle muß zunächst die Verwendbarkeit eines Werkzeugs für das Projekt überprüft und der Einsatz entsprechend geplant werden. Unter verschiedenen Bezeichnungen wie "Phasenkonzept" oder "Wasserfall-Modell" wurde ein allgemeines Vorgehensmodell des Projektmanagements für die Systementwicklung eingeführt. Das Phasenmodell wird vielfach, etwa auch von öffentlichen Verwaltungen, als Methodik für die Systementwicklung vorgeschrieben. Im folgenden werden wir als Vorgehensmodell eine häufig gebrauchte Variante des Phasenmodells beschreiben und im weiteren Verlauf des Projekts anwenden. Der Systementwicklungsprozeß soll sich demnach in folgende Phasen gliedern: (1) Problemanalyse und Projektbegründung, (2) Grobkonzept, (3) Feinkonzept, (4) Programmierung, (5) Betrieb und Wartung. Gemäß den Annahmen des klassischen Phasenmodells sind Rückkopplungen und Rückverzweigungen zwischen den einzelnen Phasen unzulässig. In der Praxis hat sich jedoch gezeigt, daß diese Anforderung nur sehr schwer erfüllt werden kann. Ein Grund hierfür liegt wohl in der Schwierigkeit, auf der Grundlage sehr abstrakter Modelle des Informationssystems weitreichende Entwurfsentscheidungen zu treffen. Die Anlässe für Rückverzweigungen können in folgender Weise kategorisiert werden: • Der Entwurf enthält fehlerhafte bzw. widersprüchliche Vorgaben oder Spezifikationen (Problem-Verlauf). • Zusätzliche Erkenntnisse über Zusammenhänge und Lösungsmöglichkeiten bedingen eine Ergänzung bzw. eine Erweiterung der Anforderungen oder der Spezifikationen (Zusatz-Verlauf).

-16-

Vorgehensmodell

Gelingt es nicht, Rückverzweigungen des Typs "Zusatz-Verlauf auszuschließen bzw. wirksam zu beschränken, verliert das Projekt insgesamt das durch das Phasenmodell kontrollierbare Fortschrittskonzept, ferner besteht die Gefahr, daß die Projektkosten explodieren und das Projekt nicht terminiert.

Abb. 2: Vorgehensmodell

Phase 1: Problemanalyse und Projektbegründung Unter Problemanalyse versteht man die Erfassung und Beschreibung eines Problemzustands, der sich als bewerteter Unterschied zwischen einem Ist- und einem Soli-Zustand zeigt, und die Abgrenzung des Problembereichs. In dieser Phase wird ein Problem diagnostiziert und hinsichtlich seiner Bedeutung für übergeordnete Leistungsziele klassifiziert. Ein Problem kann aus der Sicht des Anwenders bereits dann vorliegen, wenn mit bestehenden Informationssystemen nur ein unzureichender Beitrag zum übergeordneten Leistungsziel realisiert werden kann. Zur Analyse des Problemfeldes werden geeignete Erhebungsmethoden eingesetzt. Diese zum überwiegenden Teil informalen Methoden umfassen die Beobachtung und die Befragung in den jeweils möglichen Gestaltungsformen, sowie die Analyse der bestehenden Informationssysteme und verfügbarer Dokumente. Bei der Ist-Analyse werden u.a. Erkenntnisse aus der Systemforschung, der Kybernetik, der Organisationstheorie und der DVTechnik zweckmäßig eingesetzt. Gegenstand der Analyse sind vor allem Informationsflüsse, Unternehmensfunktionen und -prozesse (Geschäftsvorgänge) sowie Organisationsund Kommunikationsstrukturen.

Vorgehensmodell

-17-

Erst im Anschluß an die Spezifikation des Umfangs und der Struktur eines Problems kann die Projektinitialisierung beginnen. Die Projektbegründung beinhaltet im einzelnen • die Skizzierung der Anforderungen, die im Dialog mit dem Auftraggeber erarbeitet werden, • die Abschätzung des Umfangs und der Wirtschaftlichkeit, • den Projektplan als Vorgehensmodell und • zusätzliche Bedingungen der Projektdurchführung. Da Anforderungswünsche an ein innovatives Informationssystem naturgemäß abstrakt, vage und unvollständig sind, muß hier verstärkt auf die Ergebnisse der Problemanalyse zurückgegriffen werden, um alle Anforderungen daraufhin zu überprüfen, • ob ein Bezug zur Problemdefinition besteht und • ob die Maßnahmen geeignet sind, den Problemzustand zu beheben. Bei der Überprüfung von Anforderungswünschen zeigt sich, daß die Problemdefinition in entscheidendem Maß den Umfang und die Art der Anforderungen determiniert. Aus Gründen der Projekteffizienz wird jedoch häufig auf eine intensive Problemanalyse verzichtet. In späteren Phasen des Projekts wird das Informationssystem gemäß dem Anforderungskatalog konkretisiert, dabei stehen für den Systementwickler die Funktionen des Systems und nicht mehr der auslösende Problemzustand im Vordergrund. Dieser Zusammenhang läßt es ratsam erscheinen, alle Anforderungen mit größtmöglicher Sorgfalt zu sammeln und auf ihre sachliche Zweckmäßigkeit zu prüfen. Aus den Anforderungen werden die Zielsetzung und die Bezeichnung des Projekts definiert. Die Beschreibung des Inhalts skizziert den Bedarf an Systemfunktionen und dient im weiteren Verlauf des Projekts als verbindliches Verzeichnis (Pflichtenheft) der Anforderungen. Die Abschätzung des Projektumfangs, der notwendigen Personal- und Sachmittel, stellt ein sehr schwieriges Problem dar. Obgleich zahlreiche quantitative und deduktive Ansätze in der Literatur vorgeschlagen wurden, finden häufig induktive Schätzverfahren Anwendung. Dies begründet sich aus dem in dieser Projektphase noch sehr ungenauen Kenntnisstand bezüglich des Systemumfangs (charakterisiert durch Lines Qf Code), der Gesamtkomplexität und der Umgebungsbedingungen. Die Berücksichtigung von Qualitätsmerkmalen (z.B. Sicherheitsaspekte, Mehrbenutzerbetrieb, Dialoggestaltung im Graphikmodus) erschwert eine exakte Kalkulation zusätzlich. Daher versucht man, durch Ähnlichkeitsvergleiche mit bereits durchgeführten Projekten, genauere Kostengrundlagen zu entwickeln. Die Kalkulation der ähnlichen Systemkomponenten wird übernommen und gemäß den veränderten Einflußparametern, wie etwa der Mitarbeiterproduktivität und der Entwicklungsumgebung, angepaßt. Durch Variation der relevanten Einflußgrößen, die auf unterschiedlich optimistischen Annahmen beruhen, kann dann versucht werden, eine Bandbreite für die Projektkosten anzugeben. Im Projektplan werden die einzelnen Tätigkeiten der Systementwicklung, unterteilt in einzelne Phasen, terminlich und personell festgelegt. Im einzelnen wird der zeitliche Umfang jeder Phase und das Teilergebnis bestimmt. Hier werden auch Projektzustände definiert, die die

-18-

Vorgehensmodell

generelle Weiterführung des Projekts bzw. eine Verzweigung in eine frühere Phase bedingen. Durch die verbindliche Auflistung von Auflagen in der Form von Vor- und Nachbedingungen für die Projektdurchführung können Fehlinvestitionen vermieden werden.

Phase 2: Grobkonzept Während in der Phase der Projektbegründung geklärt wurde, was zu entwickeln ist, wird in dieser ersten Entwurfsphase festgelegt, wie das System gestaltet werden soll, um die definierten Anforderungen zu erfüllen. Mit der Verwendung neuerer Begriffe wie "Systemarchitektur" oder "Outside-In-Ansatz" wird ausgesagt, daß in dieser Phase ausschließlich die top-down-Vorgehensweise einzusetzen ist. Die Festlegung der Entwicklungsstrategie sollte jedoch getrennt für Funktlons- und Datenmodell vorgenommen und stets begründet werden. Wir unterscheiden die Entwurfsobjekte des Grobkonzepts hinsichtlich ihres inhaltlichen Bezugs in Fachkonzept und DV-technisches Konzept. Zunächst wird das Fachkonzept als Menge von Lösungsmethoden des beteiligten Fachgebiets entwickelt. Im Anschluß prüfen wir die DV-technische Umsetzung und entwerfen ein möglichst zweckmäßiges TechnikKonzept. Da der Grad der Aufgabenverteilung und die Art der Aufgabenerfüllung von verfügbaren technischen Mitteln geprägt werden, muß im Rahmen des Technikentwurfs überprüft werden, ob nicht fachinhaltliche Anforderungen die Verwendung bestimmter Techniken implizieren. Es ist daher zunächst ein von der Technik unabhängiges Fachkonzept zu fordern. Eventuell muß der Zyklus vom Fachentwurf zum Technikentwurf mehrmals durchlaufen werden, um alle geeigneten Wege zur Entwicklung des DV-Konzepts auf ihre Zweckmäßigkeit hin zu untersuchen. Während die Fachkonzepte vorwiegend verbal abgefaßt werden, bevorzugt man beim Entwurf des DV-Konzepts, im Hinblick auf die Eindeutigkeit und die später erforderliche Programmierung, formal orientierte Sprachmittel. In der Wirtschaftsinformatik gilt die Idealvorstellung, daß ein Systementwickler aufgrund übergreifender

betriebswirtschaftlicher

Kenntnisse in der Lage ist, sowohl das fachinhaltliche als auch das DV-technische Konzept zweckmäßig zu entwerfen und präzise zu formulieren. Um die Aufgaben des DV-Konzepts näher zu strukturieren, werden wir das Datenmodell, das Funktionsmodell und das Organisationsmodell einführen. Das Datenmodell stellt die statische Struktur einer Aufgabe, genauer der Bearbeitungsobjekte einer Aufgabe, als Beziehungsnetz zwischen Objekten dar. Darin werden Objekttypen, Beziehungstypen und deren Attribute definiert. Das Funktionsmodell bildet die dynamischen Anforderungen an ein Informationssystem strukturiert ab. Funktionen transformieren eine Menge von Inputdaten in eine Menge von Outputdaten. Im Organisationsmodell wird der organisatorische Rahmen des Systems beschrieben. In einem Prozeß der Strukturierung und fortlaufenden Detaillierung wird die Funktions- und Datenbeschreibung zunehmend formalisiert.

Vorgehensmodell

- 19-

Alle Funktionen, die in der Grobphase entwickelt werden, verwenden als Input und Output ausschließlich Elemente des in dieser Phase konzipierten Datenmodells. Das konzeptionelle Datenmodell strukturiert und übersetzt die Begriffskomplexe des Fachkonzepts in Begriffe zur Beschreibung von Datenstrukturen. Bei diesem Zwischenschritt bleibt die Bedeutung von Fachbegriffen noch vollständig erhalten. Man bezeichnet diese Abbildung auch als semantisches Datenmodell. Während die Funktionsmodellierung nach dem top-down-Ansatz erfolgt, d.h. deduktiv aus den Anforderungen gewonnen wird, entwirft man das Datenmodell meist bottom-up, indem die Bestandteile des Fachkonzepts einzeln abgebildet und zu einer konsistenten Struktur zusammengefügt werden. Datenmodell und Funktionsmodell können zunächst unabhängig voneinander und auch parallel entworfen werden. Keines der beiden Konzepte darf zum organisatorischen Modell Widersprüche aufweisen. Die Abstimmung zwischen Daten- und Funktionsmodell erfolgt auf der Abstraktionsebene der Bearbeitungsobjekte, die aus der Sicht der Funktionen als Datenquellen und Datensenken fungieren. Dabei gelten folgende Regeln: • Datenobjekte, die von keiner Funktion benötigt werden, sind irrelevant für das Informationssystem und können daher aus dem Datenmodell entfernt werden. • Datenobjekte, die in einer Funktion nachgefragt werden, müssen im Datenmodell verfügbar sein. Wir führen den Datenabgleich deshalb aus der Sicht der Funktionen durch, da die Funktionen auf deduktivem Weg entwickelt wurden und den Sollzustand des Informationssystems widerspiegeln. Die Präzisierung des semantischen Datenmodells führt anschließend zu einer genauen Beschreibung der Eigenschaften von Datenobjekten. Die den Eigenschaften zugehörigen Werte bilden als Input und Output die Verarbeitungselemente für die Funktionen. Auf dieser Grundlage können die Funktionen einem weiteren Detaillierungsprozeß unterzogen werden, an dessen Ende wiederum ein Datenabgleich auf der Abstraktionsebene der Objekteigenschaften durchgeführt wird. In der Phase der Grobkonzeption besteht nicht selten beim Entwickler des Fach- wie auch des DV-Konzepts der Wunsch, Einzelheiten der Problemlösung detailliert vorzudenken, um Entwurfsentscheidungen auf einer sicheren Basis zu fällen. Durch diese Vorweglösung (Flucht aus der Abstraktion) sind in späteren Phasen nicht nur Abstimmungsschwierigkeiten zu anderen, nicht konkretisierten Teilbereichen zu erwarten, sondern auch Inkonsistenzen im abstrakten Systemmodell inhärent. In dem vorgeschlagenen Vorgehensmodell wird keine explizite Dokumentationsphase eingeführt. Das Ergebnis jeder Projektphase sollte die Beschreibung des entwickelten Konzepts und die Begründung der Entwurfsentscheidungen beinhalten. Den Abschluß der Grobkonzeption bildet die Prüfung des DV-Konzepts, indem festgestellt wird, ob die geplante Systemfunktionalität dem fachinhaltlichen Konzept entspricht. Vom Ergebnis dieser Prüfung wird die Weiterführung des Projekts (mit eventuell gekürzten Anforderungen) bzw. die Rückverzweigung zu einer früheren Phase abhängig gemacht. Die Einstellung des Projekts am Ende dieser Phase sollte - im Hinblick auf empirische Befunde - stets eine realistische Alternative darstellen.

- 2 0 -

Vorgehensmodell

Phase 3: Feinkonzept In der Feinkonzeptionsphase wird nunmehr das DV-Konzept weiter detailliert und formalisiert. Dabei wird das Daten- und Funktionsmodell im Hinblick auf charakteristische Anforderungen optimiert. Das logische Datenmodell wird in dieser Phase aus dem semantischen Datenmodell unter Anwendung klar erforschter Regeln abgeleitet und an die funktionalen Anforderungen angepaßt. Die Detailnähe des logischen Modells bewirkt nicht selten Korrekturen des konzeptionellen Modells. Dabei ist stets die Abstimmung der Teilmodelle wiederherzustellen und darauf zu achten, daß alle Änderungen dokumentiert werden. Die Beschreibung des Datenmodells soll ebenfalls an den Möglichkeiten des auf dem Datenmodell basierenden Datenbanksystems orientiert werden. Der Detaillierungsgrad für einzelne Funktionen richtet sich nach der Mächtigkeit der vereinbarten Implementationssprache. Um den Beschreibungsaufwand zu reduzieren, sollten zunächst logisch zusammenhängende Teilfunktionen gebildet werden. Die Verfeinerung der Beschreibung wird so lange fortgesetzt, bis jede Anweisung des Modells ohne zusätzlichen Erklärungsaufwand von einem Dritten kodiert werden kann. Dabei sollte in das Kalkül einbezogen werden, daß formale Fehler der Beschreibung bereits durch die Syntaxprüfung des Implementationswerkzeugs aufgedeckt werden, während logische Fehler häufig erst beim Test einer Systemkomponente zu erkennen sind. Die soweit detaillierten Funktionen nehmen nunmehr Bezug auf die Datenobjekte und deren Attribute gemäß dem logischen Datenmodell. Als Ergebnis der Feinkonzeptionsphase erhalten wir die algorithmische Beschreibung der Systemkomponenten und die logische Beschreibung der Datenstrukturen. Dieses Ergebnis muß im Rahmen der Fortgangskontrolle den Vorgaben des Grobkonzeptes gegenübergestellt werden, da die nachfolgende Programmierphase trotz der Verfügbarkeit von mächtigen Entwicklungswerkzeugen (noch) relativ hohe Kosten verursacht.

Phase 4: Programmierung Das in den Entwurfsphasen festgelegte Realisierungskonzept wird nun zu einem auf einem Rechner ablauffähigen Anwendungssystem umgesetzt. In dieser Phase fließen zusätzlich die Anforderungen an die Gestaltung des Front-Ends, der Sicht des Benutzers auf das Anwendungssystem, ein. Da die Benutzersicht prinzipiell von der Kernstruktur des Systems unabhängig ist, kann der Entwurf und die technische Realisierung des Front-Ends vollständig in dieser Phase abgewickelt werden. Die Benutzersichten werden in jüngster Zeit zunehmend vereinheitlicht, etwa durch CUA- (Common User Access) oder Fensteroberflächen, daher besteht für den Entwickler nur geringer Gestaltungsspielraum. In der Programmierphase wird zunächst das Datenmodell implementiert, anschließend erfolgt die Kodierung der Funktionen gemäß dem jeweiligen Rang im Funktionenbaum von unten nach oben. Bei diesem Vorgehen werden zuerst die elementaren Funktionen und später die höheren Funktionen realisiert. Höhere Funktionen nehmen Bezug auf einfache

Vorgehensmodell

- 21 -

Funktionen oder setzen sich gar aus diesen zusammen. Während des Konstruktionsvorgangs wird jede Komponente mit einem vorgegebenen Kranz von Beispieldaten getestet. Erst nach dem erfolgreichen Test kann eine Funktion als "Baustein" für höhere Funktionen freigegeben werden. Auch in dieser Phase finden organisationstheoretische Prinzipien Anwendung. So muß etwa die Programmieraufgabe als Ganzes auf verschiedene Personen möglichst optimal verteilt werden. Dazu können das Verrichtungs- und das Objektprinzip eingesetzt werden. Diejenigen Programmieraufgaben, die große Ähnlichkeiten hinsichtlich der Art der Kodierungstätigkeit aufweisen, werden nach dem Verrichtungsprinzip zusammengefaßt. Als solche Tätigkeit kann z.B. die Gestaltung der Bildschirme für die Ein- und Ausgaben aller Funktionen angesehen werden. Gliedert man die Aufgaben nach dem Objektprinzip, werden die zu bearbeitenden Funktionen als Ganzes auf einzelne Stellen verteilt. Zum Beispiel könnte ein Programmierer die gesamte Datenverwaltung einschließlich der Dialoggestaltung des Moduls "Faktura" übernehmen. Bei der Gliederung der Programmieraufgaben muß auch beachtet werden, daß durch die Nutzung der Spezialisierungsmöglichkeiten zwar eine höhere Effizienz erzielt werden kann, jedoch Probleme der Fertigstellung bei einer Teilaufgabe umso eher zu einer Gesamtverzögerung des Projekts führen können, je stärker diese Aufgabe als Ganzes von einer Stelle abhängig ist. Zu Beginn der Programmierphase wird daher die Zahl der nach dem Verrichtungsprinzip definierten Aufgaben, zum Ende hin die Zahl der nach dem Objektprinzip definierten Aufgaben überwiegen. Bevor eine Systemkomponente freigegeben wird, muß sie eine Reihe von Tests durchlaufen. Die Testdaten werden aus charakteristischen Transaktionen unter Abdeckung der typischen und kritischen Fälle gewonnen. Alle Testdaten sollten zentral von einem Datenbankmanagementsystem zur Verfügung gestellt werden und für jeden Funktionstest exklusiv benutzt werden, um Seiteneffekte auszuschließen, bei denen zwei gleichzeitig auftretende Fehler sich gegenseitig aufheben. Durch eine geeignete Versionsverwaltung ist sicherzustellen, daß stets auf die ursprünglichen Testdaten und nicht etwa auf bereits veränderte Daten zugegriffen wird. Zunächst werden einzelne Funktionen auf ihre Korrektheit geprüft, d.h. nach einem vorgeschriebenen Drehbuch werden die Wirkung von Benutzeraktivitäten und das Zusammenspiel der Module untersucht. Dabei erweist es sich häufig als Vorteil, wenn entweder ein Dritter, nicht der Programmierer selbst, diese Überprüfung vornimmt, oder im Rahmen einer Präsentation Dritte die Möglichkeit zur Kontrolle und Diskussion erhalten. Als Programmierer ist man aus Effizienzgründen geneigt, bestimmte Testmuster wiederholt und verkürzt anzuwenden ohne auf die Vollständigkeit der Testläufe zu achten. Nach bestandenem Funktionstest wird der Lasttest ausgeführt, indem die Effizienz des Systems anhand des Durchsatzes und der Antwortzeiten für eine maximal zu erwartende Transaktionsrate gemessen wird. Dazu werden geübte Anwender gebeten, realistische Szenarien mit dem System durchzuspielen. Um die Überprüfbarkeit eines Systemfehlers zu gewährleisten, muß die Benutzeraktivität jeder Teststation protokolliert werden. Nach dem

-22-

Vorgehensmodell

erfolgreichen Lasttest wird der Probebetrieb parallel zum bestehenden Normalbetrieb aufgenommen, nachdem die Daten aus dem zuvor eingesetzten System übernommen wurden. Im Abnahmetest wird das System endgültig als das den Anforderungen entsprechende Anwendungssystem klassifiziert. Nicht nur aus rechtlichen Gründen wird diese letzte Hürde als kritische Phase der Systementwicklung angesehen. Die Abnahme umfaßt in der Regel neben der Software auch die Benutzer- und Systemdokumentation.

Phase 5: Betrieb und Wartung Nach Abschluß der Testphase wird das Anwendungssystem für den produktiven Betrieb freigegeben. Die Softwarewartung übernimmt dabei die Aufgabe,

Benutzerprobleme

danach zu analysieren, ob ein Fehler des Systems oder des Benutzers vorliegt, und Systemänderungen und -erweiterungen zu initialisieren. Die Änderungswünsche können entweder über einen längeren Zeitraum gesammelt und zu einer generellen Überarbeitung des Systems zusammengefaßt oder jeweils einzeln realisiert werden. Bei der letzteren Variante ist mit relativ hohen Entwicklungs- und Testaufwendungen zu rechnen, gegenüber der ersten Variante muß eine größere Anzahl von Versionen verwaltet werden. Ferner wirkt sich ein permanenter Änderungsprozeß nachteilig auf die Produktivität des Systems und die Sicherheit im Umgang mit dem System aus der Sicht des Benutzers aus.

Datenmodellierung

- 23-

3.3. Grundlagen der Datenmodellierung11 Nach der klassischen Sichtweise der maschinellen Informationsverarbeitung steht das Programm im Mittelpunkt der Verarbeitung und Systementwicklung. Die Daten werden mit den Operationen "Dateneingabe" und "Datenausgabe" als Anhängsel des Programms aufgefaßt und jeweils programmindividuell in Form von Dateien auf Datenträgern abgespeichert. Aus dieser Sicht resultiert eine Vielzahl funktionsorientierter und nicht integrierter Datenbestände, die eine erhebliche Redundanz aufweisen. Redundanz zieht dabei nicht nur einen erhöhten Speicherbedarf nach sich, sondern bereitet Probleme bei der Konsistenzsicherung des Datenbestandes, und bedingt zusätzlichen Aufwand bei der Systemwartung. Für die Anwender von isoliert entwickelten, funktionsorientierten Anwendungsprogrammen stellen sich Synonym- und Homonym-Probleme. Die funktionsorientierte Systementwicklung hat in vielen Unternehmen zu einem sprichwörtlichen "Datenchaos" geführt, das mit neuen, sowohl konzeptionellen als auch DV-technischen Ansätzen bewältigt werden soll. Die Konzepte seien hier schlagwortartig zusammengefaßt: • datenorientierte statt funktionsorientierte Systementwicklung, • unternehmensweite statt aufgabenorientierte Datenmodellierung, • Datenbanken statt Datei-Organisation. Gemeinsamer Ansatzpunkt dieser drei miteinander in Beziehung stehenden Ansätze ist die Erkenntnis, daß Daten als eigenständige, von einzelnen Funktionen und Anwendungsprogrammen unabhängige Komponente von Informationssystemen anzusehen sind.

3.3.1. Datenbanksysteme und Systementwicklung Im sogenannten "Datenbankansatz" werden die gesamten Datenbestände eines Informationssystems programmunabhängig strukturiert und verwaltet. Das

Datenbanksystem,

bestehend aus der Datenbank als Datenpool und dem Datenbankmanagementsystem als einem Softwaresystem zur Datenverwaltung, fungiert als zentrale Basis aller Anwendungssysteme. Jedem Anwendungsprogramm werden die individuell benötigten Daten (Dateien) als virtuelle Dateien, d.h. nicht real gespeicherte Dateien, für Verarbeitungszwecke aufbereitet und zur Verfügung gestellt. Eine entscheidende Einsatzvoraussetzung für die Anwendung des Datenbankansatzes ist dabei die Beschreibung des logischen Aufbaus der Datenbasis und die Festlegung der zugehörigen physischen Datenorganisation auf dem externen Speichermedium. Die Verknüpfung der Datenkomponenten mit den Funktionen wird durch die Beschreibung von (logischen) Teilsichten des Datenbestandes in der Form von Schnittstellen ermöglicht. ''

Literaturhinweise zu diesem Abschnitt: Batini, C., u.a., Conceptual Database Design , Redwood City/Cal. 1992; Date ,C.J., A n Introduction to Database Systems, Reading/Mass. 1990; Elmasri, R., Navathe, S.B., Fundamentals of Database Systems, Redwood City/Cal. I989; Scheer, A.-W., Wirtschaftsinformatik - Informationssysteme im Industriebetrieb, Berlin 1990;

-24-

Datenmodellierung

Anforderungen an Datenbanksysteme sind: • Datenunabhängigkeit, d.h. die Unabhängigkeit zwischen logischer Beschreibung und physischer Datenorganisation einerseits, sowie die Unabhängigkeit der logischen Sicht eines Anwendungsprogramms von Veränderungen der logischen Gesamtsicht andererseits; • Sicherung der Datenkonsistenz, d.h. die Widerspruchsfreiheit der aus Effizienzgründen mehrfach abgespeicherten Fakten; • Sicherung der Datenintegrität, d.h. Vermeidung von fehlerhaften Eingaben und unzulässigen Operationen sowie Synchronisation paralleler Zugriffe; • Gewährleistung der Datensicherheit, d.h. Schutz der Daten vor unberechtigtem Zugriff und Verfälschung. In der Datenkomponente eines Anwendungssystems werden die Bearbeitungsobjekte einer Aufgabe, also z.B. die aus der Vorgangskettenanalyse gewonnenen Strukturen von Ereignissen und Umweltzuständen dargestellt und in einer von einem Datenbankmanagementsystem verwalteten Datenbank abgespeichert. Zur Beschreibung des logischen Aufbaus der Datenbank, d.h. der relevanten Informationsobjekte dienen hierbei standardisierte Datenmodelle, die jeweils spezifische Konzepte - Konstruktionselemente und -regeln - zur Beschreibung der Datenstrukturen bereitstellen. Darüberhinaus können Datenmodelle über eine Menge von Operationen für die Datenwiedergewinnung und -manipulation verfügen. Für das Verständnis der Datenmodellierung ist die Unterscheidung zwischen der Beschreibung der Daten und der Datenbasis selbst grundlegend. Die Beschreibung wird in einem sogenannten Datenbank-Schema festgelegt. Die Daten der Datenbank, die einer permanenten Veränderung unterliegen, werden als Datenbank-Instanz bezeichnet. Die Festlegung eines Datenbank-Schemas, einem konkreten Datenmodell entsprechend, wird als Datenbank-Definition bezeichnet. Durch diese Definition wird die Erkenntnis des relevanten Realitätsauschnittes, häufig als die "Diskurswelt" oder "Miniwelt" bezeichnet, mit Hilfe der Modell-Konzepte beschrieben. Das Schema enthält zudem Regeln für die Integrität eines Datenbestandes und damit Bedingungen an die Gültigkeit einer Datenbank-Instanz. Wir verstehen unter "Datenmodellierung" den Teil der Systementwicklung, der sich mit der Repräsentation der Informationsobjekte der Diskurswelt in einer formalen, der DV-Technik zugänglichen Beschreibungssprache befaßt. Angesichts der Basis- und Zieltechnologie "Datenbanksystem" können wir somit den Begriff Datenmodellierung mit dem konkreteren Begriff "Datenbank-Entwurf' gleichsetzen. Datenbankmanagementsysteme (DBMS) sind Softwaresysteme, die auf einem konkreten Datenmodell basieren. Dies bedeutet, daß die betrachtete Realität als Datenkomponente eines Informationssystems durch die von der Datendefinitionssprache des DBMS vorgegebenen Konzepte dargestellt werden muß. Da die Standardmodelle einerseits einen hohen Formalisierungsgrad und andererseits eine relativ geringe Semantik besitzen, hat sich ein mehrstufiger Datenbank-Entwurfsprozeß als zweckmäßig erwiesen, bei dem das Fachkonzept schrittweise und evtl. unter Verwendung von CASE-Tools in verschiedenen Schemata

Datenmodellierung

-25-

formalisiert wird. Die folgende Abbildung veranschaulicht diese Phasen, wobei sich in der Literatur zur Systementwicklung und zum Datenbank-Entwurf unterschiedliche Begriffe herausgebildet haben.

Abb. 3: Phasen des Datenbank-Entwurfs Im sogenannten konzeptionellen Entwurf werden die durch Abstraktion aus der Vorgangskettenanalyse gewonnenen Konzepte der Diskurswelt, "Ereignis" und "Umweltzustand", in Konzepte zur Beschreibung von Datenstrukturen überführt. Die für die Formulierung des konzeptionellen Schemas verwendete Beschreibungssprache muß hinreichend formal sein, da

das

konzeptionelle

Schema

die Ausgangsbasis

für

die

informationstechnische

Weiterverarbeitung bildet. Sie soll insbesondere die Semantik der dargestellten Information weiter erkennen lassen, so daß dieses Schema als Kommunikationsbasis innerhalb der betrieblichen Fachbereiche und zwischen Fachabteilung und DV-Spezialist dienen kann. Die hier zum Einsatz kommenden Datenmodelle (z.B. das

Entity-Relationship-Modell)

werden im Unterschied zu DBMS-spezifischen Datenmodellen als semantische Datenmodelle bezeichnet.

-26-

Datenmodellierung

Im logischen Entwurf erfolgt die Repräsentierung der im konzeptionellen Entwurf entwickelten Datenstrukturen durch die formalen Konstrukte des Datenmodells (z.B. des Relationenmodells), auf dem das für die Realisierung des Informationssystems zur Verfügung stehende Datenbankmanagementsystem basiert. Im dritten Schritt wird das Schema in die Beschreibungssprache eines DBMS übersetzt und die Datenbank eingerichtet. Dazu werden auch die Speicherstrukturen (Dateien, Cluster etc.) und Zugriffspfade (Indexe, Verkettung etc.) unter dem Ziel der effizienten Verarbeitung festgelegt. Der Entwicklung des konzeptionellen Datenmodells kommt bei der Systementwicklung eine herausragende Bedeutung zu, und sie kann als die kritische Phase des gesamten Datenbank-Entwurfs bezeichnet werden. Der konzeptionelle Entwurf stellt eine Abstraktionsleistung dar, die in erster Linie Fachwissen erfordert und kaum automatisierbar erscheint. Das konzeptionelle Schema bildet eine Schnittstelle zwischen dem Anwendungssystem- bzw. Datenbank-Nutzer und der gespeicherten Information. Je stärker der Anwender in den konzeptionellen Design-Prozeß einbezogen wird, um so mehr kann möglichen Akzeptanzproblemen bei der Nutzung des Anwendungssystems vorgebeugt werden. Das konzeptionelle Schema dient als Dreh- und Angelpunkt für Systemmodifikationen und Systemerweiterungen. Dieses Phasenkonzept reduziert darüberhinaus die Komplexität des gesamten Entwurfsprozesses und ermöglicht zudem eine lose Kopplung zwischen Fachkonzept und der DVtechnischen Realisierungsform, sodaß die Ergebnisse der Datenmodellierung stabil, d.h. bei Veränderungen der Informationstechnologie auch langfristig gültig bleiben.

3.3.2. Abstraktion als Basis der Datenmodellierung Abstraktion als mentaler Prozeß zur Problemlösung wird stets verwendet, um charakteristische und relevante Eigenschaften von Objekten eines Problemfeldes im Hinblick auf eine Komplexionsreduktion herauszuarbeiten. Neben dieser Reduzierung auf das Wesentliche bedeutet Abstraktion "gedachtes Gleichmachen", d.h. die auf zufällige Einzelheiten verzichtende, begrifflich zusammenfassende Darstellung einer durch Erkenntnisleistung empfundenen Realität. Abstraktion als Grundlage der Entwicklung sachlogischer Datenstrukturen im konzeptionellen Entwurf ist dabei ein systematischer Vorgang, der auf drei grundlegenden Konstrukten - Klassifizierung, Aggregation und Generalisierung - beruht. Bei der Klassifizierung werden die Objekte der realen Welt, die durch gemeinsame Eigenschaften (Attribute) charakterisiert sind, als "gleichartig" erkannt und einem benannten "Konzept" oder "Konstrukt" zugeordnet. So bilden etwa alle Personen als Realitätsobjekte, die durch eine Lieferanten-Nummer, einen Namen und eine Adresse beschrieben werden können,

das

Konzept

"Januar","Februar"

"LIEFERANT". Das

Konzept

"MONAT" wird

durch

die

Objekte

"Dezember" gebildet.

Die Aggregation beschreibt die Bildung neuer Konzepte, sogenannter Klassen, als "Vereinigung" anderer Konzepte bzw. Klassen, wobei diese neue Klasse zusätzliche Attribute

Datenmodellierung

- 27-

erhalten kann. Wir wenden diesen Abstraktionsschritt z.B. an, wenn wir das Konzept "AUFTRAG" als Zusammenfassung der Konzepte "KUNDE", "ARTIKEL" und "ZEIT" auffassen und diesem neuen Konzept zusätzlich ein Mengen-Attribut zuordnen. Aggregation und Klassifikation stellen die beiden grundlegenden Abstraktionsformen für die Bildung von konventionellen Datenstrukturen sowohl in Datenbanksystemen als auch in Programmiersprachen dar. In der klassischen Dateiorganisation werden durch die Klassifikation eines Feld-Typs Attribute identifiziert, die dann durch eine Aggregation zu RecordTypen zusammengefaßt werden. Durch die Generalisierung werden ähnliche Objekttypen zu einem übergeordneten, generischen Objekttyp zusammengefaßt, indem eine Teilmenge-Beziehung zwischen den Elementen der jeweiligen Klassen postuliert wird. So ist etwa GESCHÄFTSPARTNER eine Generalisierung von KUNDE und LIEFERANT, und TEIL eine Generalisierung von MATERIAL und ARTIKEL. Der Vorgang der Generalisierung kann dabei auch in der umgekehrten Richtung als sogenannte Spezialisierung interpretiert werden. Die Generalisierung/Spezialisierung beinhaltet die sogenannte Vererbungseigenschaft, d.h. alle Attribute des generischen Objekttyps werden von den Unterklassen geerbt bzw. Attribute, die den Unterklassen gemeinsam sind, werden auf den generischen Typ übertragen. Die generische Klasse überdeckt dabei die Subklassen, wobei diese Überdeckung vollständig ist, wenn jedes Element der generischen Klasse mindestens einem Element der Unterklassen entspricht. Die Überdeckung ist disjunkt, falls jedes Element der generischen Klasse jeweils höchstens einem Element in den Unterklassen entspricht. Die drei angeführten Abstraktions-Konstrukte sind dabei in dem Sinne unabhängig, daß kein einzelnes Konstrukt durch die beiden anderen Konstrukte ausgedrückt werden kann. Sie stellen somit unterschiedliche Mechanismen zur Identifikation und Beschreibung von Beziehungen zwischen Konzepten dar. Die Klassifikation entspricht der Elementbeziehung (is-member-of), die Aggregation der Mengenzusammensetzung (is-part-of) und die Generalisierung der Teilmengenbeziehung (is-a).

3.3.3. Das Entity-Relationship-Modell (ERM) Das Entity-Relationship-Modell (ERM) wurde zuerst von Chen (1976) vorgestellt und ist in der Folge von verschiedenen Autoren erweitert worden. Es hat sich unter den semantischen Datenmodellen wegen seiner strukturellen Einfachheit und "graphischen" Darstellungsmöglichkeit als die Standard-Entwurfssprache für die Erstellung des konzeptionellen Datenmodells durchgesetzt. Das ERM basiert auf dem Konzept, einen Realitätsausschnitt dadurch zu beschreiben, daß abgrenzbare Objekte der Realität und die zwischen diesen Objekten identifizierbaren und relevanten Beziehungen dargestellt werden.

Datenmodellierung

-28-

3.3.3.1. Das Grundmodell des ERM Eine Entität (engl. Entity) oder auch Objekt ist ein individuelles und identifizierbares Exemplar von Dingen, Personen oder Begriffen der realen oder der Vorstellungswelt. Eine Entität kann demzufolge sein: • ein Individuum wie ein Mitarbeiter, ein Kunde, ein Student, • ein reales Objekt wie ein Artikel, eine Maschine, ein Lagerplatz, • ein abstraktes Konzept wie ein Artikeltyp, Maschinentyp oder auch • ein Ereignis wie eine Rechnungsbuchung, ein Vertreterbesuch, eine Lagerentnahme. Das ERM unterscheidet zwischen zwei Konstruktionsebenen. Auf der einfachen, die einzelnen Realitätsobjekte betreffenden Ebene stehen folgende Konstruktionselemente zur Verfügung: Konstrukte der Objektebene Entität

Eigenschaft

Beziehung

Faktum

Auf der höheren Abstraktionsebene, auf der Tatbestände dargestellt werden, welche Mengen von Realitätsobjekten betreffen, sind die entsprechenden Konstruktionselemente: Konstrukte der Objektmengen-Ebene Entitätstyp

Attribut

Beziehungstyp

Domäne

Entitäten sind die elementaren Informationsobjekte, mit deren Hilfe konkrete Umweltzustände oder Ereignisse repräsentiert werden, die jeweils für die Beschreibung der Realität, d.h. im konkreten Fall etwa für die Beschreibung einer Vorgangskette oder eines Unternehmens, unter den Vorstellungen des Modellierers relevant, d.h. von Interesse und Bedeutung sind. Aus der Sicht des Modellierers oder Systementwicklers ist eine Entität somit stets • eine eindeutig identifizierbare Einheit, • eine Einheit, deren Existenz aufgrund eines Identifikationsmerkmais unabhängig von der Existenz anderer Entitäten darstellbar sein muß, sowie • eine Einheit, über die Informationen gesammelt werden sollen. Die jeweilige Sachlage aus der Sicht des Entwicklers entscheidet stets darüber, welche Objekte der Realität als eine Einheit aufzufassen sind. Beispiel: Für eine Anwendung "Hörsaalbelegung" ist die gesamte Hörerschaft der Vorlesung "Datenbanken" als (Einzel-)Objekt von Bedeutung (zur Untersuchung der zeitlichen Kollision mit anderen Vorlesungen). Für eine Anwendung "Prüfungsamt" ist jeder einzelne Hörer der Vorlesung "Datenbanken" ein relevantes Objekt (da etwa die Belegung der Pflichtveranstaltung überprüft werden soll). Eigenschaften und deren Ausprägungen, die Eigenschaftswerte, werden im Modell den Entitäten zugeordnet und ermöglichen deren Charakterisierung, Klassifizierung und - unter

Datenmodellierung

-29-

Umständen - eindeutige Identifizierung. Eine Eigenschaft erhält dabei stets einen Namen und ein Entity besitzt bezüglich einer ihm zugeordneten Eigenschaft einen, ggf. mehrere, Eigenschaftswert(e). Im folgenden wird der Name einer Eigenschaft stets mit STABEN,

GROSSBUCH-

die Eigenschaftswerte hingegen mit Kleinbuchstaben geschrieben.

Das folgende Beispiel zeigt zwei Entitäten mit den zugeordneten Eigenschaftswerten: Kunden-Entity K,

NAME

ANSCHRIFT

TELEFON

Anton Meier

5 Köln 1 Habsburger Ring 5

0221 / 3671-90

Artikel-Entity a,

BEZEICHNUNG

GEBINDE

BaseAT586-450

1 Stück

UMSATZ

87.660

VERKAUFSPREIS

18.933

Ein Faktum (fact) ist eine Feststellung, derzufolge eine Entität (oder auch Beziehung) für eine Eigenschaft einen bestimmten Eigenschaftswert annimmt. Ein Faktum stellt somit eine Zuordnung einer Eigenschaft und eines Eigenschaftswertes zu einer Entität (oder, wie wir noch ausführen werden, einem Beziehungselement) dar. Diese Zuordnung wird festgehalten und in der Datenbank gespeichert, die somit letztendlich Faktenwissen enthält. Ein und derselbe Eigenschaftswert kann dabei durchaus mehreren Entitäten zugeordnet werden, wodurch damit entsprechend viele unterschiedliche Fakten postuliert werden. Um die Komplexität der Realität im Modell zu reduzieren, wird man nach strukturellen Ähnlichkeiten suchen und dann aufgrund gewisser Ähnlichkeitskriterien, die den Entitäten zukommen, sogenannte Klassen von Entitäten bilden, wie z.B. • (alle) Kunden eines Unternehmens, • (alle) Artikel eines Unternehmens, • (alle) Studenten der Universität. Wir sagen dann, Entitäten einer Klasse sind vom selben Typ. Ein Entitytyp ist eine eindeutig benannte Menge von Entitäten, denen jeweils die gleiche Menge von Eigenschaften (nicht Eigenschaftswerten!) zugeordnet ist. Statt Entitätstyp wird auch häufig die Bezeichnung Entitätsmenge verwendet. Auf der Ebene der Entitytypen bezeichnen wir die bei allen Entitäten dieses Typs auftretenden Eigenschaften als Attribute. Eine Beschreibung eines Entitytyps, auch als EntitytypSchema oder Intention bezeichnet, besteht aus der Angabe des Typ-Namens, der Namen der Attribute, sowie eventuell weiterer Bedingungen, welche die zugehörigen Entitäten erfüllen müssen. Die Menge der zu einem bestimmten Zeitpunkt einem Entitytyp zugehörigen Entitäten wird im Gegensatz dazu als Extension, jede einzelne Entität selbst als Instanz des Entitytyps bezeichnet. Während ein Typ-Schema relativ zeitinvariant ist, da hier grundlegende gemeinsame Strukturen von relevanten Objekten beschrieben werden, wird sich die Extension eines EntityTyps während der Lebensdauer des Informationssystems häufig verändern, etwa durch Hinzufügen und Löschen von einzelnen Entitäten.

Datenmodellierung

-30-

Allgemein geben wir ein Entity-Schema für einen Entitytyp E mit den Attributen A „ ... A„ wie folgt wieder: £: < A,,..., A„ >. Ist dann e ein Entity des Entitytyps E, so schreiben wir e e £ und (A^e) A,( e )) für die Attributwertekombination von e. Die folgende Aufstellung gibt das Entity-Schema für die zwei Entitytypen Kunde und Artikel wieder: KUNDE: < NAME, ANSCHRIFT, TELEFON, UMSATZ > ARTIKEL: < BEZEICHNUNG, GEBINDE, VK_PREIS >

Attribute können dabei in Teile aufgespalten werden, die selbst wieder eine eigenständige Bedeutung aufweisen. So kann z.B. das Attribut und

HAUSNUMMER,

wobei

ORT

ANSCHRIFT

aufgeteilt werden in

wiederum unterteilt werden kann in

POSTLEITZAHL

ORT, STRASSE

und

ORTSNAME.

Auf diese Weise ergibt sich eine Hierarchie von Attributen und Eigenschaftswerten. Ein Attribut, das durch eine derartige Kombination mehrerer, elementarer Attribute entsteht, wird als zusammengesetztes Attribut bezeichnet, während Attribute, die nicht weiter zerlegbar sind, als einfach oder atomar bezeichnet werden. Zusammengesetzte Attribute sind etwa dann von Nutzen, wenn man sowohl auf die in dem Attribut liegende gesamte Information zugreifen will, als auch auf Teile davon. Ein Beispiel für ein zusammengesetztes Attribut ist auch das

DATUM,

das sich in die Teilattribute

TAG, MONAT

und

JAHR

zerlegen läßt.

Im Regelfall weist jedes Attribut eines Entitytyps für jedes Entity genau einen Eigenschaftswert auf. Derartige Attribute werden als einwertige Attribute bezeichnet. Ein typisches Beispiel ist hier etwa für ein Personen-Entity das

GEBURTSDATUM.

In anderen Fällen kann

jedoch ein Entity mehrere Werte für ein einzelnes Attribut besitzen. So kann beispielsweise bezüglich

des

Attributes

FREMDSPRACHENKENNTNIS

eine

Person

die

Eigenschaftswerte

"Englisch", "Französisch", und "Italienisch" aufweisen. Derartige Attribute werden als mehrwertige Attribute bezeichnet. In der Schemabeschreibung können wir die Komponenten eines zusammengesetzten Attributes in Klammern eingeschlossen und durch Kommata getrennt anführen. Den Spezialfall des Vorliegens mehrwertiger Attribute verdeutlichen wir durch Angabe des Attributnamens in Mengenklammern {..}. In einigen Fällen wird es für eine gegebene Entität nicht möglich sein, alle im Typ-Schema definierten Attribute durch entsprechende Fakten zu belegen. Ein Grund hierfür kann schlicht die Unwissenheit des Anwenders sein, der z.B. die Faxnummer eines Kunden nicht kennt. Eine weitere Möglichkeit besteht darin, daß dieses Attribut für dieses spezielle Entity grundsätzlich nicht "anwendbar" ist, wenn etwa ein Kunde kein Fax-Gerät besitzt. In beiden Fällen wird für diese Attribute der sogenannte "NULL"-Wert angegeben. Dieser Wert, der vom numerischen Wert "0" unterschieden werden, muß, besagt, daß der betreffende Eigenschaftswert nicht bekannt ist oder daß dieses Entity nicht über diese Eigenschaft verfügt. Eine Domäne stellt eine eindeutig benannte Menge aller zulässigen Eigenschaftswerte eines Attributs dar, d.h. die Menge der möglichen (oder zulässigen) Ausprägungen. Wenn wir davon ausgehen, daß die Mitarbeiter eines Unternehmens alle im Alter zwischen 14 und

Datenmodellierung

65

- 31 -

Jahren sind, so ergibt sich für das Attribut

ALTER

eines Entity-Typs

MITARBEITER

als Domä-

ne der Bereich der ganzen Zahlen zwischen 14 und 65. Eine spezielle Klasse von Attributen bilden die sogenannten abgeleiteten Attribute, bei denen sich für jedes Entity der entsprechende Eigenschaftswert aus den Eigenschaftswerten anderer zugeordneter Attribute ableiten läßt. Ein Beispiel hierfür wäre etwa das Attribut NETTOLOHN, LOHN

und

das sich auf einfache Weise aus den Eigenschaftswerten der Attribute

LOHNABZÜGE

BRUTTO-

berechnen läßt. Das Übernehmen von abgeleiteten Attributen und das

explizite Abspeichern von zugehörigen Fakten ist in gewisser Weise redundant und birgt insofern die Gefahr von Inkonsistenzen in sich. Wir werden die spezielle Problematik der abgeleiteten Attribute auf Seite 68 noch einmal aufgreifen. Bei der Datenmodellierung muß die Zuordnung von Attributen zu Entitytypen sicherstellen, daß eine Eigenschaftswertkombination ein zugehöriges Entity eindeutig charakterisiert und insgesamt die Attributmenge hinreichend ist, um zu jedem Zeitpunkt jedes Entity des Objekttyps eindeutig zu charakterisieren. Entitytypen besitzen häufig ein einwertiges Attribut, das für jedes individuelle Entity einen spezifischen Wert aufweist. Ein solches Attribut wird als Schlüssel bezeichnet, und die Werte dieses Attributs erlauben die eindeutige Identifizierung einzelner Entitäten. Ein Beispiel für einen Schlüssel ist etwa die Sozialversicherungsnummer bei Angestellten, die Personalausweisnummer o.a. Den Attributen dieses Beispiels ist gemeinsam, daß zum Zweck der eindeutigen Identifizierung eine fortlaufende Numerierung der Entitäten durchgeführt wird, und die so gewonnenen "künstlichen" Eigenschaftswerte in der Realität verbindlich an die betreffenden Entitäten geknüpft werden. "Natürliche" Attribute eignen sich nur dann als Schlüssel, wenn die abzubildende Entitätsmenge im Zeitablauf unverändert bleibt und bereits bei der Entwicklung des Typ-Schemas vollständig bekannt ist. Auch mehrere, verschiedene Attribute eines Entitytyps können diese Schlüssel-Eigenschaft aufweisen. Ein Kraftfahrzeug kann z.B. durch die Zulassungsnummer, das Autokennzeichen oder auch durch die Angabe der Fahrgestellnummer identifiziert werden. In manchen Fällen wird jedoch die eindeutige Identifizierung nur über eine Kombination von Attributen möglich. Eine Attributmenge S={A,, A,,...,/\} eines Entitytyps heißt Schlüssel oder Schlüsselkandidatfalls (a) die Attributmenge S identifizierend ist und (b) kein Attribut aus S entfernt werden kann, ohne daß Eigenschaft (a) verlorengeht (sogenannte Minimalitätsforderung). Ein einzelnes Attribut eines Schlüsselkanditaten bezeichnen wir auch als Schlüsselattribut.

-32-

Datenmodellierung

Hier sei noch einmal besonders darauf hingewiesen, daß die Annahme einer (Primär)Schlüsseleigenschaft eines Attributs bzw. einer Attributkombination zwingend voraussetzt, daß für jede mögliche, denkbare Extension je zwei verschiedene Entitäten auch bezüglich des Schlüssels unterschiedliche Werte aufweisen. Die Spezifikation von Schlüsselattributen ist daher nicht durch einfaches Durchsuchen eines bestehenden "Datenbestandes" möglich, sondern erfordert Sachkenntnis und logisch-konzeptionelle Überlegungen. Bei der Datenbank ist dann durch Kontrollmechanismen (des DBMS) sicherzustellen, daß die Primärschlüsseleigenschaft für jede Intention erhalten bleibt und nicht durch fehlerhafte Eingaben bzw. Operationen zerstört wird. Eine Datenbank soll eine möglichst vollständige und korrekte Faktenmenge bezüglich aller relevant erscheinenden Entitäten enthalten. Von großem Interesse sind dabei Beziehungen, die zwischen einzelnen, in der Datenbank zu erfassenden Entitäten bestehen. Eine Beziehung (relationship) assoziiert wechselseitig zwei oder mehr Entitäten. In unserem einfachen Beispiel könnte eine individuelle Bestell-Beziehung zwischen dem Kunden k, und dem Artikel a, vorliegen und durch die Symbolik (k v a,) festgehalten werden. Diese Symbolik repräsentiert ein sogenanntes Beziehungselement und soll hier zum Ausdruck bringen, daß ein bestimmter Kunde einen bestimmten Artikel bestellt, aber auch in umgekehrter Lesart, daß ein bestimmter Artikel von einem bestimmten Kunden bestellt ist. Auch für Beziehungselemente lassen sich Fakten postulieren, wenn z.B. dem Beziehungselement (k v a,) die Eigenschaft ANZAHL mit dem Eigenschaftswert 75 zugeordnet wird. Damit soll ausgedrückt werden, daß der entsprechende K U N D E eine Bestellung über 75 Stück dieses Artikels aufgegeben hat. Derartige Beziehungselemente können nun prinzipiell zwischen allen Artikeln und allen Kunden bestehen. Diese jeweils unterschiedlichen Beziehungselemente, die allesamt Entitäten derselben Entitätstypen assoziieren, und denen jeweils die gleiche Bedeutung zukommt, bezeichnet man wiederum als vom "gleichen Typ". Beispiele: MITARBEITER leitet KUNDE

bestellt

PROFESSOR prüft

PROJEKT. ARTIKEL. STUDENT in RAUM.

Datenmodellierung

-

3 3 -

Der Beziehungstyp bildet die zweite Kategorie von Konstrukten des E-R-Modells. Ein Beziehungstyp (relationship type) ist eine eindeutig benannte Menge von Beziehungselementen gleichen Typs. Die eindeutige Benennung ist notwendig, da auch mehrere Beziehungstypen zwischen jeweils identischen Entitytypen gebildet werden können. Zudem sollte das jeweils vom Entwickler identifizierte Beziehungskonzept eindeutig und prägnant zum Ausdruck kommen. Formal gesehen ist ein Beziehungstyp R zwischen den n Entitytypen EV E2 En eine Relation über den Mengen EV E2 ... E„, d.h. eine Teilmenge des kartesischen Produktes E, x E2 x ... x E„. Jedes einzelne Beziehungslement stellt sich dann als Tupel (e,, e2, ... en) der Relation dar. Die Identifizierung einzelner Beziehungselemente ist offensichtlich stets über die Primärschlüssel der beteiligten Entitytypen möglich. Zur näheren Beschreibung und Charakterisierung werden den Beziehungstypen weitere Attribute zugeordnet. Beispiele: PROJEKTLEITUNG:

Die im Beispiel hervorgehobenen Attribute (Fettdruck) leiten sich jeweils aus den Primärschlüsseln der diese Beziehung bildenden Entitytypen ab. Wir bezeichnen diese Attribute deshalb als derivative Attribute1'. Sie können nur Werte aus der Domäne des betreffenden (referierten) Primärschlüssels annehmen. Da eine konkrete Beziehung nur von existierenden Entitäten gebildet wird, gilt offensichtlich die weitere Bedingung, daß derivative Attribute nur solche Werte annehmen können, die von den in Bezug stehenden Entitytypen zur "Verfügung gestellt" werden. Alle nicht-derivativen Attribute eines Beziehungstyps und alle Attribute eines Entitytyps nennen wir auch originäre Attribute (Normaldruck). Der Bestell-Beziehungstyp ist ein Beispiel für einen binären Beziehungstyp, d.h. einen Beziehungstyp, an dem zwei Entitytypen beteiligt sind. Die Anzahl der an einem Beziehungstyp beteiligten Entitytypen wird als Grad des Beziehungstyps bezeichnet. Ein Beziehungstyp mit Grad 3 ist etwa der zwischen den Entitytypen P R O J E K T , B A U T E I L und L I E F E R A N T bestehende Beziehungstyp: LIEFERANT

l i e f e r t BAUTEIL

für

PROJEKT.

Ein solcher Beziehungstyp repräsentiert in der Regel mehr Information als die drei darin enthaltenen, binären Beziehungstypen: LIEFERAMT

liefert

LIEFERANT

beliefert

PROJEKT

benötigt

BAUTEIL, PROJEKT

und

BAUTEIL.

Das bedeutet, daß derartige Beziehungen zwischen drei und mehr Entitäten im allgemeinen nicht durch mehrere Paar-Beziehungen dargestellt und im Modell ersetzt werden können. In einem solchen Fall gingen durch die Zerlegung wichtige Informationen verloren, d.h. der i)

Der Begriff derivatives Attribut ist sehr genau von dem Begriff abgeleitetes Attribut zu unterscheiden.

Dateri modellierung

-34-

zugrundeliegende Sachverhalt der Realität kann mit dem geänderten Beziehungstyp nicht mehr präzise ausgedrückt werden. Beispiel: In den konkreten Beziehungen (Klöckner, Getriebe, CTO), (Möller, Getriebe, Trabant), (Klöckner, Katalysator,

Trabant)

sind die Paarbeziehungen (Klöckner, Getriebe), (Getriebe, Trabant) und (Klöckner,

Trabant)

enthalten. Allein aus diesen Paarbeziehungen darf jedoch nicht auf die folgende (Klöckner, Getriebe,

Dreierbeziehung

Trabant)

geschlossen werden.

Falls in einem Beziehungstyp ein Entitytyp mehrfach auftritt, so müssen wir diesem im Modell entsprechend viele Bezeichnungen - sogenannte Rollennamen - zuordnen, damit man die Funktion bzw. Rolle der jeweiligen Entitäten in einer Beziehung ersehen kann. Von besonderem Interesse sind in diesem Zusammenhang binäre Beziehungstypen, bei denen beide beteiligten Entitytypen identisch sind. Ein Beispiel für einen solchen Beziehungstyp - den man auch als rekursiven Beziehungstyp bezeichnet - ist der Beziehungstyp "IST SETZTER

VORGE-

VON" über der Menge der MITARBEITER-Entitäten. Bei diesem Beziehungstyp tritt der

Entitytyp

MITARBEITER

zweimal auf, einmal in der Rolle als Vorgesetzter und einmal in der

Rolle als Untergebener. Unter der Komplexität eines Beziehungstyps verstehen wir quantitative Angaben über die Menge der darin auftretenden Beziehungen. Dazu wird für jeden Bezug eines Beziehungstyps zu einem Entitytyp festgehalten, wieviele konkrete Beziehungen jedes Entity dieses Typs eingeht.

Komplexitätsgrade

repräsentieren sachlogische

Integritätsbedingungen,

durch die Beschränkungen an Beziehungstypen und sogenannte Existenzabhängigkeiten an Entitäten gestellt werden. Um diesen Komplexitätsgrad auszudrücken, gibt es mehrere Notationsvorschläge in der Literatur, von denen die (min, max)- Notation den höchsten Informationsgehalt aufweist. Bei dieser Art der Komplexitätsangabe wird für einen Entitytyp E eines Beziehungstyps R angegeben, in wieviel konkret vorhandenen Beziehungen jedes Entity mindestens (min) stehen muß und höchstens (max) vorkommen darf. Die Notation lautet: kgrad (R,E) = (min,max)

mit 0 , > , = etc. zulässig. Damit definieren wir die Selektion auf R bzgl. einer Selektionsbedingung SB SELECT (R) = {tE r(R) | (erfüllt SB} Die Verbundoperation (Join) ist eine binäre Operation und dient dazu, zwei Relationen, die etwa im Rahmen der Normalisierung aus einer Relation entstanden sind, durch gezielte Verkettung von in Beziehung stehenden Paaren von Tupeln (wieder) zu einer Relation zu verbinden. Diese Operation entspricht somit vom Konzept her einem kartesischen Produkt, bei dem nur die Tupelpaare, die eine bestimmte Join-Bedingung, kurz JB, erfüllen, verkettet werden. Wir definieren für eine Relation R=R(A

AJ und eine Relation S=S(S,,...,SJ den

Verbund von R und S bzgl. JB

R JOIN.„. S = {(r,s) | r e r{R),se

r(S), r u n d s erfüllen JB }

Eine Join-Bedingung JB hat dabei die Form JB = and and

. . . and ,

wobei jede Bedingung die Gestalt hat r[AJ « V e r g l e i c h s o p e r a t o r s [BJ. Views kann man nun auf einfache Weise erhalten, indem man mit Hilfe der Operationen der Relationenalgebra neue Relationen bildet, mit einem neuen Namen belegt und die Operationsfolge als sogenannte View-Definition speichert, z.B.: DEFINE VIEW

GROSSKUNDEN

AS

SELECT ,„...„,.„„„„, KUNDEN Die Operationen der Relationenalgebra stellen keine minimale Menge dar, d.h. die Ergebnisse einiger Operationen können durch (eine Folge von) anderen Operationen ebenfalls erhalten werden. So kann offensichtlich eine Verbundoperation stets durch die Konstruktion eines kartesischen Produktes mit anschließenden Selektionen simuliert werden. Es ist einfach, nachzuweisen, daß die Menge mit den fünf Operationen PROJECT,

SELECT,

UNION, MINUS und TIMES minimal und vollständig, d.h. gleich mächtig wie die gesamte Relationenalgebra ist. Von besonderer Bedeutung für das Arbeiten mit relationalen Daten-

- 63-

Datenmodellierung

banken sind jedoch die drei relationenorientierten Operationen, die z.B. auch genau von dem System dBASE IV unterstützt werden. Über diese Operationen hinaus sollte die Datenmanipulationssprache über spezielle Befehle z u m Einfügen ( I N S E R T ) , Aktualisieren ( U P D A T E ) und zur Elimination ( D E L E T E ) einzelner Tupel einer Relation verfügen. Für das Arbeiten mit dem Datenbestand sind darüberhinaus weitere sogenannte Aggregationsfunktionen zweckmäßig, mit denen die in Relationen gespeicherte Information "ausgewertet" werden kann. Beispiele hierfür sind etwa der c o u n t - O p e r a t o r , durch den die Anzahl von Tupeln einer Relation ermittelt werden kann, die eine bestimmte Bedingung erfüllen, und der sum-Operator, mit dem die Werte eines Attributs (mit numerischer Domäne) aufsummiert werden können.

3.3.4.3. Modellierung der Diskurswelt im RM Da es im Relationenmodell nur Relationen als Strukturelemente gibt, müssen sowohl Entitäten als auch Beziehungen der realen Welt durch Relationen dargestellt werden. Jedem Entitytyp E mit nur einfachen Attributen können wir unmittelbar ein identisch aufgebautes Relationen-Schema R E zuordnen. Ist beispielsweise ß ein Beziehungstyp mit zugehöriger Attributmenge AV A2

zwischen den Entitytypen E und E mit Primärschlüsseln

und

A^ , so können wir B zunächst auch als Entitytyp der Form E t B J ^ A o A ' . A,

An >

uminterpretieren und dann diesen Entitytyp als Relation Rg darstellen. Dieses Vorgehen ist in der folgenden Abbildung verdeutlicht:

LIEFERANT(

LNR,NAME,ORT,...)

MATERIAL ( MAINE,MBEZ,GEWICHT,...)

o

o

ü LIEFERKATALOG

( LNR.MATNR.MIND.MENGE.PREIS....)

Abb. 14: Repräsentation eines ER-Schemas im Relationenschema

Datenmodellierung

-64-

Der Benutzer der Datenbank muß nun wissen, daß diese Relation die Fremdschlüssel-Attribute R E , (MATERIAL)

R B (LIEFERKATALOG)

(Lnr) und /^'(Matnr) zu den Relationen

R E (LIEFERANT)

über und

in Beziehung steht.

Wiederholungsgruppen sind bekanntlich eine Kombination von Feldern, die innerhalb eines Datensatzes einer Datei beliebig oft mit Werten belegt werden können, d.h. die zugehörige Datei besitzt keine flache Struktur. Während ein derartiges Konzept im ERM in Form der zusammengesetzten und mehrwertigen Attribute eine Entsprechung findet, ist eine solche flache Struktur jedoch bei Tupeln einer Relation zwingend erforderlich. Beipiel: Der Entitytyp RECHNUNG enthält ein mehrwertiges zusammengesetztes das die "Wiederholungsgruppe" RECHNUNG

der Rechnungspositionen

Attribut,

repräsentiert

:< RNR, RDATUM, {ARTNR,STÜCKPREIS, MENGE},RSUMME

>

Im Relationenmodell sind nur Relationen in erster Normalform zulässig, d.h. der obige Entitytyp kann so nicht unmittelbar in das RM übertragen werden. Um normalisierte Relationen zu erhalten, müssen aus dem obigen Entitytyp zwei Relationen gebildet werden, indem man die Wiederholungsgruppe aus der Attributmenge des Entitytyps

RECHNUNG

entfernt und

daraus eine eigene Relation bildet. In den Primärschlüssel dieser "neuen" Relation wird zusätzlich das Schlüsselattribut der ursprünglichen "Relation" als Fremdschlüssel angefügt, um die Beziehung zwischen den beiden Relationen herzustellen. Man erhält dann im konkreten Beispiel die Relationen: RECHNUNGS-KOPF

(RNR. RDATUM, R.SUMME)

RECHNUNGS-POSTEN(RM,

ARTNR.

und

PREIS,MENGE).

Die Bedeutung normalisierter Relationen ist folgendermaßen herauszustellen: • Durch die regelmäßige Struktur können Aktualisierungsoperationen einfacher konzipiert werden. • Normalisierte Relationen erlauben die Anwendung der Prädikatenlogik erster Stufe auf die Attribute einer Relation als Datenmanipulationssprache. Über die notwendige 1 NF-Bedingung hinaus sind zur Vermeidung von Anomalien bei der Datenmanipulation im Rahmen der Normalisierungstheorie weitere, nicht unbedingt notwendige Normalitätsbedingungen formuliert worden. Da wir das grundlegende Konzept der funktionalen Abhängigkeiten bereits im Rahmen der Design-Kriterien für das ERM eingeführt haben, werden im folgenden die Bedingungen nur kurz in der spezifischen RMNotation angeführt. Der zweiten Normalform kommt dabei nur noch eine historische Bedeutung zu.

o Erste Normalform Eine Relation ist in 1. Normalform (1 NF), wenn alle Attribute atomar sind.

Datenmodellierung

- 65-

o Zweite Normalform Eine Relation ist in 2. Normalform (2NF), wenn sie die 1. Normalform erfüllt und jedes Attribut ausschließlich funktional von jedem Schlüsselkandidat, d.h. nicht schon von einer Teilmenge der Schlüsselattribute abhängt.

o Dritte Normalform Zur Definition der dritten Normalform (3NF) auf der Grundlage der 2NF benötigen wir das Konzept der "transitiven Abhängigkeit". Seien A ,S,und C beliebige, verschiedene Attributmengen einer Relation. Eine funktionale Abhängigkeit A —> C ist transitiv, falls zwei funktionale Abhängigkeiten A ß und B —> C existieren. Eine Relation ist in 3. Normalform, falls sie die 2. Normalform erfüllt und kein Nicht-Schlüsselattribut transitiv von einem Schlüsselkandidat abhängt. Man kann leicht zeigen, daß diese Bedingung äquivalent zu der folgenden Formulierung ist, die nicht auf dem 2NF-Konzept aufbaut und deutlicher die Beziehung zur Boyce-Codd-Normalform aufzeigt: Eine (1) (2) (3)

Relation ist in 3. Normalform, falls für jede funktionale Abhängigkeit A —> S gilt: S c A oder A ist identifizierende Attributmenge oder B ist ein Schlüsselattribut.

o Boyce-Codd-Normalform Eine A -> (1) (2)

Relation ist in Boyce-Codd-Normalform (BCNF), falls für jede funktionale Abhängigkeit B gilt: S c A oder A ist identifizierende Attributmenge.

Jedes Relationenschema kann durch einen Prozeß der sukzessiven Identifizierung von funktionalen Abhängigkeiten zwischen Attributen und anschließender Zerlegung von Relationen in ein Relationenschema mit 3NF-bzw. BCNF-Relationen transformiert werden. Die Zerlegungsregel entspricht den "Normalisierungsregeln", die wir bereits im Zusammenhang mit dem Design von ER-Schemata (Seite 44ff.) eingeführt haben; sie kann formal wie folgt beschrieben werden:

o Zerlegungsregel Sei R=(A,B,C) eine Relation und ß —> C eine für die 3NF- bzw. BCNF-Bedingung "unzulässige" funktionale Abhängigkeit, dann zerlegen wir die Relation R in zwei Relationen R,(AB) und R2(8,C). Man kann unmittelbar sehen, daß durch sukzessive Anwendung dieser Zerlegungsregel jedes Relationenschema in ein 3NF- bzw. BCNF-Schema transformiert werden kann. Im Hinblick auf die Unterstützung einer bestimmten Datensicht - im obigen Beispiel etwa zur Darstellung der Rechnungsinformationen auf einem Rechnungsformular- stellt sich die Frage, ob sich die unnormalisierten Ausgangsrelationen stets "ohne Informationsverlust"

Datenmodellierung

-66-

normalisieren lassen, d.h. ob eine mittels Anwendung dieser Zerlegungsregel durchgeführte Normalisierung rückgängig gemacht werden kann und für jede Instanzierung des transformierten Schemas die jeweils zugehörigen Instanzen der entsprechenden unnormalisierten Ausgangsrelationen durch Join-Operationen (re-) konstruiert werden können. Diese wesentliche Eigenschaft, die man als "Verlustfreiheit" bezeichnet, ist sowohl für die Zerlegung in 3NF- als auch in BCNF-Relationen erfüllt. Eine weitere, wesentliche Eigenschaft, die an das normalisierte Relationenschema gestellt wird, ist die sogenannte "Erhaltung" aller funktionalen Abhängigkeiten des Ausgangsschemas. Dies bedeutet, daß jede funktionale Abhängigkeit, die in einer Relation des Ausgangsschemas formuliert ist, sich wieder in einer Relation des normalisierten Schemas ableiten läßt. Dadurch ist die Kontrolle aller funktionalen Abhängigkeiten durch lokale, d.h. unabhängige Kontrolle der einzelnen Relationen möglich. Diese Eigenschaft ist stets mit der Forderung nach Transformation in 3NF, jedoch in einigen Fällen nicht mit der Forderung nach Transformation in ein BCNF-Schema verträglich, wie das folgende Beispiel zeigt: Sei R(A.B.C) und

bei

jeder

mit

der

funktionalen

Zerlegung

in

ein

Abhängigkeit BCNF-Schema

C —>

muß

8. Diese

3NF-Relation

die Abhängigkeit

AB

ist nicht —>

C

in

BCNF

zwangsläufig

verlorengehen.

Alle Integritätsbedingungen, die durch funktionale Abhängigkeiten ausgedrückt werden, welche nach einer Zerlegung nicht in dieser Weise erhalten werden, können damit nur nach einer aufwendigen Join-Operation mit einigen der Relationen des BCNF-Schemas überprüft werden. Angesichts dieser, im Hinblick auf die Leistungsfähigkeit des Systems kritischen Konsequenz empfiehlt es sich, in diesen Fällen auf die Zerlegung in BCNF zu verzichten und die zugehörigen Relationen nur in 3NF abzubilden. Die dann möglichen Anomalien sind in der Regel wesentlich effizienter zu kontrollieren. Die Transformation eines ER-Schemas in ein äquivalentes Relationenschema ist ein wohlstrukturierter Prozeß, der gewissen einfachen, programmierbaren Regeln folgt und somit im Prinzip automatisierbar ist. Im folgenden geben wir die Schritte dieses "Algorithmus" in knapper Form wieder, wobei wir davon ausgehen, daß ein ER-Schema mit allgemeinen, auch nicht-atomaren Attributen vorliegt. Offensichtlich erzeugt dieser Transformationsprozeß ausschließlich 1 NF-Relationen und erhält weitere Normalitätseigenschaften des ER-Schemas, d.h. ein ER-Schema, dessen Konstrukte alle die BCNF-Bedingung erfüllen, wird "automatisch" in ein Relationen-Schema mit BCNF-Relationen transformiert. Diese Invarianzeigenschaft ist insofern von Bedeutung, als damit alle für die Vermeidung von Anomalien bei der Manipulation relationaler Datenbanken notwendigen Überlegungen und Modellierungsschritte bereits im konzeptionellen Modell, und damit in einer Entwicklungsphase vorgenommen werden können, bei der die Anwender bzw. die Entwickler des Fachkonzepts einbezogen sind. Diese allein verfügen in der Regel über das für die Aufdeckung von funktionalen Abhängigkeiten notwendige Fachwissen.

Datenmodellierung

Abb. 15: Transformation von E R M nach RM

-67-

Datenmodellierung

-68-

3.3.4.4. Physischer Datenbank-Entwurf Auf der internen Ebene wird jede Datenbank als eine Menge von Dateien organisiert, die mit den jeweiligen Verbindungen gemeinsam zu verwalten sind. Im physischen DatenbankEntwurf ist nun festzulegen, wie das vorgegebene logische Schema in einer sogenannten physischen Datenbankstruktur als Menge von Dateien mit zugehörigen Organisationsformen einzurichten ist. Der Ausgangspunkt für die vom Ziel der Verarbeitungseffizienz geleitete physische Entwurfsphase ist somit das Ergebnis der logischen Entwurfsphase, d.h. ein normalisiertes relationales Datenbankschema, das entsprechend dem konzeptionellen Datenmodell anwendungsunabhängig gestaltet wurde. Das Relationenmodell bezieht sich mit seinen Konstruktionselementen und -prinzipien nur auf die konzeptionell-logische

Ebene des Datenbank-Entwurfs und enthält keinerlei Vor-

schriften und Regeln für diese letzte Entwurfsphase. Die Festlegung der Dateistrukturen und Organisationsformen ist dabei auch von den Optionen des einzusetzenden (relationalen) Datenbankmanagementsystems (RDBMS) abhängig. Wegen der Unabhängigkeit des logischen Relationenschemas von den Verarbeitungsprogrammen kommt den physischen Datenstrukturen im Hinblick auf die Leistungsfähigkeit des Datenbanksystems eine wesentliche Bedeutung zu. Der Entwurf der physischen Datenstrukturen behandelt dabei im wesentlichen drei, nicht isoliert voneinander zu betrachtende, Problemstellungen: • Behandlung ableitbarer Datenelemente, • Faktorisierung und Denormalisierung, sowie • Clustering und Definition von Zugriffspfaden. Die ersten beiden Aspekte, die noch unabhängig von der RDBMS - Wahl sind, führen zu einer gegenüber dem logischen Datenbankschema veränderten Datenstrukturierung und erzeugen somit für die Benutzer eine abgewandelte Sicht auf die Datenbasis. Clustering und Zugriffspfade stellen demgegenüber Optionen des RDBMS dar und sind für den Anwender nicht sichtbar, sie werden auch als Methoden der physischen Datenorganisation im engeren Sinn bezeichnet. Ableitbare Datenelemente sind solche Daten, die auf die im logischen Entwurf enthaltene Information zurückgeführt werden können. Es kann sich hierbei um Kopien oder um durch "Berechnung" ermittelte Datenwerte handeln. Beim Datenbank-Design können ableitbare Daten auf zwei Arten behandelt werden: • Ausschließliche Speicherung der Ausgangsdaten und Berechnung der abgeleiteten Datenwerte nur bei Bedarf oder • Ergänzung des Datenbankschemas und Speicherung der abgeleiteten Daten zusätzlich zu den Ausgangsdaten. Diese Alternativen sollen an Beispielen erläutert werden: D e r Nettobetrag

einer Rechnungsposition läßt sich aus den Angaben über Verkaufspreis

Menge ermitteln,

die in der Relation RECHPOS erfaßt sind. Analoges gilt für den

nungsbetrag. Der

Bruttobetrag

läßt sich jeweils aus dem Nettobetrag

und der

und

Gesamtrech-

Umsatzsteuer

Datenmodellierung

- 69-

berechnen.

Zur

sein,

diese

abgeleiteten

Beschleunigung

bute

in das jeweilige

aggregierte,

Datenbasis,

Relationenschema

einzuführen.

im

ersten

Beispiel

oder nach

Umsätze

können

einerseits

nach die

Informationsobjekte

zu definieren

benötigt

Kriterien

gruppiert

Werte

zusätzlich

und in der Datenbasis

zu

von Abfragen

es

sinnvoll

und als zusätzliche

Attri-

kann

das Management

zusammengefaßte

Kunden,

ermittelt

oder

abzuspeichern

für Kontrollzwecke

bestimmten

Berechnungsprogramme

die entsprechenden Relationen

d.h.

wie etwa

zeitaufwendige

Verarbeitungsroutinen als Datenwerte

Als Entscheidungsgrundlage mung

von

Informationen

Artikelgruppen

jeweils

bei

werden,

andererseits

Bedarf

einer

Informationen oder durch

zu den Ausgangsdaten

Unternehaus

Verkäufern. einfache

besteht

die

So aber

der wie evtl.

Möglichkeit,

(Umsatzwerten)

als

speichern.

In allen Fällen erfordert die durch Abspeicherung der ableitbaren Daten entstehende Redundanz spezielle konsistenzerhaltende Maßnahmen. Dazu werden abgeleitete Attribute z.B. für die direkte Manipulation ihrer Werte unzugänglich gemacht, d.h. es können nur Datenausgaben, jedoch keine Eingaben und Änderungen, durchgeführt werden. Das im relationalen Datenmodell realisierte "Sichtenkonzept" erlaubt ferner, Ableitungsregeln in Form von sogenannten View-Definitionen zu beschreiben (virtuelle Relationen). Diese Ableitungsregeln können anstelle der abgeleiteten Datenwerte gespeichert und bei Bedarf ausgeführt werden. Eine gespeicherte Datei entspricht einem oder auch mehreren Konstrukten, d.h. Relationen des logischen Datenbankschemas, und kann neben den eigentlichen Datenfeldern über weitere Informationen wie Zeiger-Felder, Feldlängen-Indikatoren u.a. verfügen. Eine naheliegende Strategie zur Umsetzung des logischen Schemas stellt die 1:1-Transformation des logischen Schemas in das physische Schema dar. Dabei wird jede Basis-Relation des Relationenschemas als eine Datei abgelegt, wobei die Datensätze den Tupeln der Relation entsprechen. Dieses Vorgehen ist jedoch nicht zwangsläufig und nicht immer effizient. So können durch eine sogenannte Faktorisierung bestimmte, häufig in Abfragen oder Auswertungsroutinen verwendete, Attribute einer Relation in einer eigenen Datei abgespeichert werden, während die restlichen Attribute zusammen in einer zweiten Datei abgelegt werden. Die zusammengehörenden Datensätze müssen durch eine Fremdschlüsselbeziehung oder durch Zeiger zwischen den Datensätzen logisch verbunden werden. Beispiel: Die Relation KUNDEN{KNR,

NAME, ADRESSE, UMSATZ, KREDITLIMIT, OPBETRAG)

kann etwa wie folgt faktorisiert werden: KUNDEN

ANSCHRIFTÍKNR.

DEBITOR(KNR,

NAME, ADRESSE) u n d

UMSATZ, KREDITLIMIT, OPBETRAG)

Grund für eine solche Faktorisierung kann dabei nicht nur die erhöhte Effizienz bestimmter Operationen sein, sondern auch die notwendige Sicherung des Zugriffs auf sensible Daten, hier der Finanzdaten, die nur für autorisierte Benutzer zugänglich sein sollen. Neben der vertikalen Aufspaltung einer Relation in mehrere Dateien ist auch eine horizontale Aufspaltung möglich, wenn wie im obigen Beispiel die Kunden ab einem gewissen Umsatz in einer eigenen Datei "Grosskunden" geführt werden. Der Prozeß der Faktorisierung kann als die

Datenmodellierung

-70-

Aufspaltung eines Entitytyps in zwei Objekttypen aufgefaßt werden. Bei der vertikalen Faktorisierung würde zusätzlich ein 1:1-Beziehungstyp gebildet. In umgekehrter Weise können auch mehrere Relationen, die über (Fremdschlüssel-) Beziehungen miteinander verbunden sind, in einer Datei gemeinsam abgebildet und abgespeichert werden. Damit können im Rahmen des physischen Entwurfs bestimmte, im Verlauf der Normalisierung durchgeführte Zerlegungen wieder rückgängig gemacht werden, falls die dadurch gewonnene höhere Zugriffsgeschwindigkeit den zusätzlichen Aufwand rechtfertigt, der bei der Bearbeitung und Kontrolle von Anomalien entsteht. Diesen Vorgang, bei dem das Datenbankschema modifiziert wird, bezeichnet man treffend als Denormalisierung. Er soll an zwei Beispielen veranschaulicht werden. Die beiden Relationen :, ARTNR, MENGE) UND ARTIKEL (ARTNR, ARTBEZ.VKPREIS)

werden im Rahmen der Denormalisierung (wieder) zusammengefügt und in einer Datei mit der folgenden Dateistruktur abgespeichert: R H C H N U N G S P O S ( B N B £ Q 3 N H , A R T N R , ARTBEZ, VKPREIS, MENGE).

Dadurch kann bei on-line Abfragen eine umfassendere Information über einzelne Rechnungspositionen schneller bereitgestellt werden. Einige Datenbankmanagementsysteme unterstützen die Verwaltung von Dateien mit Wiederholungsgruppen. In diesem Fall ist es möglich, die Tupel von zwei Relationen, zwischen denen eine (hierarchische) 1:N Beziehung besteht, in einer Datei abzuspeichern. So können wir die Tupel der Relation nete" Relation

RECHNUNGSPOS

als Wiederholungsgruppe in die "übergeord-

RECHNUNGSKOPF(RNR.RDATUM.KNR)

aufnehmen und eine Datei mit der folgen-

den Struktur definieren: RECHNUNG{RNR.RDATUM,KNR.

KNAME, KANSCHRIFT,{POS_NR,ART_NR, A R T _ B E Z , VK_PREIS, MENGE}).

Diese Datei ist dann eine ideale Basis für die automatisierte Rechnungsschreibung. Diese letzte Option entspricht dabei dem Konzept der nicht-normalisierten Relationen. Daraus entsteht jedoch die Problematik, daß die auf der logischen Ebene verfügbaren relationalen Operationen die Manipulation dieses komplexeren "Informationsobjektes" nicht mehr unterstützen. Es sind dann z.B. zwei verschiedene INSERT-Operationen bereitzustellen, für die Einfügung einer neuen Position in eine bestehende Rechnung und die Einfügung einer vollständig neuen Rechnung. Der Zweck der Faktorisierung und der Denormalisierung besteht in der Unterstützung aufwendiger Abfragen oder Verarbeitungsroutinen durch Vorwegnahme von Operationen. Die Faktorisierung antizipiert eine Projektion oder Selektion, und die Denormalisierung erspart die Ausführung von, in der Regel aufwendigen, JoiN-Operationen zur Laufzeit, indem diese quasi statisch verankert werden. Denormalisierung und Faktorisierung verbessern dabei stets nur die Effizienz bestimmter, rein lesender, Datenbankzugriffe auf Kosten der Effizienz anderer, insbesondere schreibender, Zugriffe. Denormalisierung ermöglicht dem Benutzer und vor allem dem Anwendungsprogrammierer einfachere Zugriffsmöglichkeiten auf komplexe Informationsobjekte. Gleichzeitig schafft

Datenmodellierung

- 71 -

Denormalisierung Redundanz, woraus entweder Inkonsistenzen entstehen können oder ein höherer Update-Aufwand erwächst, da zusätzliche, eigentlich nicht notwendige Operationen und Datentransfers durchgeführt werden müssen, um alle redundanten Kopien gleichermaßen zu ändern. Weiterhin reduziert die Denormalisierung die Semantik des logischen Schemas und die Flexibilität in Bezug auf die Nutzung der Datenbank. Überlegungen zur Denormalisierung erfordern stets die Abwägung von Vor- und Nachteilen. Im Unterschied zur Aufnahme abgeleiteter Daten werden von einer Denormalisierung alle Anwendungen betroffen. Insofern ist hier, bei der Alternative zwischen der Ergänzung und der Denormalisierung des Relationenschemas, die Ergänzung als weniger weitreichende Maßnahme vorzuziehen. Wenn das Datenbanksystem nicht nur für einen fest vorgegebenen, zeitinvarianten Kranz von Anwendungen entwickelt wird, sondern mit dem Zweck der unternehmensweiten zweckneutralen Verwaltung der Ressource "Information", so sollte versucht werden, die notwendige Effizienz und gewünschte Anwendungsnähe nicht durch strukturelle Änderungen des Datenbank-Schemas, sondern durch andere Maßnahmen herzustellen, wie Verbesserung der Hardware-Ausstattung und die Nutzung spezieller Funktionen des Datenbankmanagementsystems, z.B. Views und Zugriffspfadoptionen. In jedem Fall sollte die Denormalisierung erst nach Vorliegen einer korrekten Normalisierung, d.h. auf der Basis eines Relationenschemas mit 3NF-Relationen, erfolgen. Die Abweichung zwischen logischer Datenstruktur, d.h. dem normalisierten Relationenschema und der physischen Realisation, muß dokumentiert werden. Nur so sind die infolge der Redundanzen auftretenden Probleme zu erkennen und durch geeignete Maßnahmen zu lösen, darüberhinaus können die Denormalisierungsschritte zu einem späteren Zeitpunkt wieder revidiert werden. Ausgangspunkt für die physische Datenorganisation ist ein Datenbankschema, bestehend aus sogenannten Basis-Tabellen, die vom Datenbankmanagementsystem in jeweils einer Datei gespeichert werden. Die Dateien der Datenbasis werden dabei auf dem physischen Speichermedium (Festplatte) in zusammenhängenden Speicherbereichen, sogenannten Seiten (pages), abgelegt. Eine Seite stellt die kleinste Einheit dar, die vom RDBMS bei Einund Ausgabeoperationen zwischen dem externen Speicher und Hauptspeicher transferiert wird. Verschiedene RDBMS erlauben es, Tupel aus verschiedenen Basis-Tabellen gezielt in einer Seite zu speichern. Dadurch ist eine effiziente Auswertung von Beziehungen zwischen Relationen bei joiN-Operationen möglich. Betrachten wir hierzu wieder das o.g. Beispiel mit den Basis-Tabellen RECHNUNGSKOPF und RECHNUNGSPOS. Zwischen diesen Relationen besteht eine implizite Beziehung, die jede Rechnung mit ihren zugehörigen Positionen verbindet. Der Zugriff von einer bestimmten Rechnung auf ihre Positionen wird unterstützt, wenn das Tupel des Rechnungskopfes mit den zugehörigen Positions-Tupeln in der gleichen Seite abgespeichert sind. Diese Strategie, logisch zusammengehörige Datensätze auch physisch benachbart abzuspeichern, wird als Clustering bezeichnet. Eine andere Möglichkeit der Unterstützung von Beziehungen zwischen Relationen, die etwa auch im System dBase IV über den Befehl SET RELATION TO verfügbar ist, stellt die Definition von sogenannten Verbindungen oder Link-Zugriffspfaden dar. Ein Link verbin-

-72-

Datenmodellierung

det dabei durch explizite Verkettung über Zeigerfelder jedes Tupel f einer Relation R mit allen zugehörigen Tupeln einer Relation S, wobei die Zugehörigkeit der Tupel in S zu ( durch identische Werte für eine Liste von Attributen definiert ist. Im obigen Beispiel definiert das Attribut RNR eine solche Verbindung. Die am häufigsten verwendete Methode zur Steigerung der Effizienz ist die Definition von Indexen für solche Attribute einer Basis-Tabelle, die am häufigsten, oder bei besonders zeitkritischen Zugriffen, als Qualifizierung verwendet werden. Beim Indexieren einer Datei nach einem Datenfeld wird vom System eine zusätzliche Hilfsdatei, die sogenannte Indexdatei erzeugt, die für jeden Attributwert Verweise auf die Speicherplätze (pages) der zugehörigen Datensätze der indexierten Basis-Datei enthält. Für die Organisation des Index werden dabei in modernen DBMS effiziente Baumstrukturen (B*-Baum o.ä.) verwendet. Indexe, die vom DBMS automatisch verwaltet werden, beschleunigen den Zugriff auf einzelne Datensätze bzw. Tupel oder Gruppen von Datensätzen. Sie unterstützen somit die S E L E C T - und die JOIN-Operation der Relationenalgebra. Bei der Einrichtung von Indexen ist jedoch zu berücksichtigen, daß neben dem zusätzlichen Speicherplatzbedarf auch ein Overhead bei der Aktualisierung der Basis-Tabelle auftritt. In der Sprache SQL dient das Index-Konzept auch zur Spezifizierung des Primärschlüssels bzw. zur Sicherstellung der Entity-Integritätsregel, indem für das (die) Primärschlüsselattribut(e) ein Index mit dem Zusatz U N I Q U E definiert wird.

Funktionsmodellierung

- 73-

3.4. Grundlagen der Funktionsmodellierung11 Unternehmensfunktionen sind kontinuierlich zu erfüllende betriebliche Aufgaben zur Erreichung eines Unternehmensziels. Eine Aufgabe kann sowohl durch das zugeordnete Soll (deskriptiv) als auch mittels der Tätigkeiten zur Verwirklichung des Solls (imperativ) beschrieben werden. Diese betrieblichen Tätigkeiten bestehen in der Abwicklung von Geschäftsvorgängen, welche im Gegensatz zur Unternehmensfunktion eindeutig bestimmbare Start- und Endpunkte aufweisen. Im Organisationsprozeß werden Aufgaben gegliedert und auf Stellen verteilt. Die von einem Informationssystem zu erfüllenden Aufgaben werden im Rahmen der Anforderungsanalyse deskriptiv erfaßt und gegliedert. Im Prozeß der Funktionsmodellierung werden die zur Realisierung der Anforderungen notwendigen Datenverarbeitungsprozesse entworfen und als Programmablauf spezifiziert. Das Funktionsmodell2' definiert die Verarbeitungsroutinen eines Anwendungssystems, ausgehend von den Geschäftsvorgängen, die der Benutzer mit dem System erledigen möchte. Die Geschäftsvorgänge sind bereits im Rahmen der Datenmodellierung als Vorgangsketten Gegenstand der Informationsanalyse. Bei der Bearbeitung der Geschäftsvorgänge löst der Benutzer des Systems Aktionen aus, die einen vom System gespeicherten Zustand in einen neuen Zustand überführen. Dabei ist es für die Konzeption der Funktionseinheit zunächst unerheblich, ob der neue Zustand gespeichert, an eine andere Funktionseinheit oder an den Benutzer weitergegeben wird. Diese Zustandsänderungen, ihre Vorbedingungen und Konsequenzen bilden den Gegenstand der Funktionsmodellierung. Da eine Benutzereingabe in der Regel je nach Zusammenhang mehrere komplexe Folgeaktionen auslöst, muß stets die Korrektheit des Funktionsablaufs, die Ablaufintegrität, sichergestellt werden. Funktionen überprüfen vor Beginn des Ablaufs und während der Ausführung die Systemzustände und reagieren mit entsprechenden Aktionen und Fehlermeldungen.

Literaturhinweise zu diesem Abschnitt: Balzert, H., Die Entwicklung von Software-Systemen, Mannheim 1982; Schulz, A., Software-Entwurf Methoden und Werkzeuge, München 1990; Yourdon, E. N., (Hrsg.). Classics in Software Engineering, Englewood Cliffs/NJers I979; Grupp, B„ EDV-Projekte richtig dokumentieren, Köln I99I; Funktionen sind Datenverarbeitungsaufgaben. Eine komplexe Funktion wird in notwendige Teilfunktionen zerlegt, hinsichtlich aller Verarbeitungsschritte präzisiert und deren Ausführung an selbständige Funktionseinheiten des Systems delegiert. Dieses Konzept entspricht nicht dem Paradigma der funktionalen Programmierung. Funktionale Programmiersprachen, wie z.B. SML, sind eng an mathematische Notationen angelehnt und verfolgen das Konzept, daß Programme deskriptiv und mit ausführbaren Spezifikationen abzufassen sind. Bei der Programmausführung reduziert der Interpreter die Ausdrücke auf bestimmte kanonische Grundformen.

-74-

Funktionsmodellierung

3.4.1. Prinzipien des Funktionsentwurfs Prinzipien sind allgemein gültige Regeln, die aus theoretischen Erkenntnissen und praktischen Erfahrungen entwickelt werden. Wie bereits bei der Einführung des Vorgehensmodells gezeigt wurde, kann die Gesamtkomplexität einer Aufgabe durch Zerlegung in einzelne Bearbeitungsschritte reduziert werden. Bei der Entwicklung der Funktionen des Systems werden wir nun die Gesamtaufgabe sukzessive in Teilaufgaben gliedern und anschließend einzeln spezifizieren. Dieses Vorgehen entspricht dem Prinzip der schrittweisen Verfeinerung. Bei der Anwendung dieser allgemeinen Lösungsstrategie berücksichtigt man zu Beginn der Konzeption nur bestimmte, als relevant anzusehende Sachverhalte und abstrahiert von einzelnen Besonderheiten der Problemstellung. Sind die Teilfunktionen soweit inhaltlich konzipiert, daß die Lösungsmethode sichtbar wird, beginnt die formale Spezifikation des Programms mit den Sprachmitteln des Programmierwerkzeugs. Auf den obersten Abstraktionsstufen kann eine Funktion problemnah beschrieben werden, mit zunehmender Verfeinerung spezifiziert man das Lösungsverfahren maschinennah. Die schrittweise Verfeinerung verfährt nach dem Top-Down-Prinzip. Demgegenüber werden nach dem Bottom-Up-Ansatz Programmkomponenten, die am Anweisungsvorrat einer Programmiersprache oder verfügbarer Routinen ausgerichtet sind, einzeln entwickelt und erst am Ende des Projekts zu einem Gesamtkomplex zusammengefügt. Dieses Vorgehen führt jedoch zu strukturellen Defekten des Systems auf der Ebene der Fachinhalte, da keine Systematik für die Abstimmung der Komponenten verfügbar ist. Weiterhin besteht darüber Unsicherheit, ob die Funktionen redundanzfrei implementiert sind und insgesamt die volle Funktionalität des Systems realisiert werden kann. Im Gegensatz dazu bieten top-down strukturierte Systeme Vorteile bei der Wartung und nachträglichen Änderungen, da stets überschaubare und abgegrenzte Bereiche betroffen sind. Durch die Verwendung von Abstraktionsstufen kann der fachlich qualifizierte, aber softwaretechnisch unbedarfte Projektmitarbeiter Funktionen selbständig entwerfen. Die weitgehende Unabhängigkeit der Teilfunktionen erlaubt die effiziente Verteilung der Programmieraufgaben. Als weiteres wichtiges Prinzip der Funktionsmodellierung gilt die strukturierte Programmierung. Danach wird gefordert, daß Programme unabhängig von der Programmiersprache, in der sie abgefaßt sind, aus drei elementaren Konstrukten zusammengesetzt werden: • der Sequenz als Folge von Anweisungen, • der Selektion, die ein- oder mehrfache Verzweigungen des Programms steuert, und • der Iteration, die einen Programmblock wiederholt durchläuft, bis ein Abbruchkriterium erfüllt ist. Im engeren Sinn verbietet die strukturierte Programmierung die Verwendung der GOTOAnweisung zur Spezifikation eines Algorithmus. Darüberhinaus bildet die Strukturierung ein Prinzip für den Systementwurf, das zu übersichtlichen und verständlichen Programmen führt. Im Gegensatz zum stukturierten Entwurf steht der lineare Programmentwurf, der die Aneinanderreihung von Anweisungen einer Programmiersprache ohne weitergehende formale Einschränkungen vorsieht. Dabei können beliebige Verzweigungen zwischen den

Funktionsmodellierung

-75-

einzelnen Anweisungen auftreten. Dies bedingt eine eingeschränkte Zerlegbarkeit des Programms

in logisch zusammengehörige

Bestandteile.

Strukturierte

Systementwürfe

besitzen demgegenüber die Eigenschaft der Zerlegbarkeit, da sich die Anweisungsblöcke niemals überlappen. Dadurch können die Strukturblöcke unabhängig voneinander schrittweise verfeinert werden. Die Modularisierung und das Geheimnisprinzip bilden weitere Strukturierungsgrundsätze. Ein Modul wird in Anlehnung an technische Systeme als Baustein eines Programms definiert, der folgende Eigenschaften besitzt: • Ein Modul stellt mindestens eine Funktion des Systems bereit. Da der Funktionsumfang in Abhängigkeit von der Abstraktionsstufe definiert und dabei in Unterfunktionen zerlegt wird, entsteht eine hierarchische Modulordnung. • Ein Modul wird durch einen eindeutigen Namen identifiziert und ist ein selbständiger, von anderen Modulen unabängiger Programmbaustein. Die Geschlossenheit steigt mit zunehmendem internen Zusammenhalt des Moduls. • Um die Module zu einem Gesamtsystem zu integrieren, darf es nicht erforderlich sein, das interne Verhalten der Module zu kennen (Geheimnisprinzip). • Module müssen eigenständig auf ihre Korrektheit überpüft werden können. • Alle extern relevanten

Eigenschaften eines

Moduls werden

durch

Import-

und

Exportschnittstellen definiert. Durch die Minimierung der Kopplung zwischen den Schnittstellen wird eine möglichst große Unabhängigkeit von anderen Modulen erreicht. Module können demnach selbständig in Maschinensprache übersetzt und in beliebiger Reihenfolge programmiert werden. Die von einem Modul exportierten Operationen werden von anderen Modulen in Anspruch genommen. Dabei müssen die Auswirkungen der Inanspruchnahme für den aufrufenden Modul vollständig bekannt sein, nicht jedoch der interne Verarbeitungsmechanismus. Die Art und der Umfang der Modulkopplung determinieren die Verwendbarkeit eines Moduls im Hinblick auf unterschiedliche logische Zusammenhänge. Die Kopplungsart der expliziten Parameterangabe wird dem Ziel der kontextunabhängigen Verwendbarkeit am ehesten gerecht, wenn nur wenige und elementare Datenelemente übergeben werden (schmale Datenkopplung). Die erfolgreiche Anwendung des Modularisierungsprinzips ist von der stringenten Verwendung einer einheitlichen Dekompositionsmethode abhängig, die auf verbindlichen Kriterien beruht. Als primäres Kriterium für die Modulbildung können wir aus dem bisher ausgeführten funktionalen Entwurfskonzept den Vorrang der funktionalen Bindung von Modulen ableiten. Danach müssen alle Anweisungselemente eines Moduls gleichermaßen einen einzelnen, abgeschlossenen Zweck erfüllen. Liegt kein einheitlicher Zweck zugrunde, kann eine weitere Strukturierung erfolgen. Das Modul besitzt dann die minimalen Eigenschaften und kann nicht weiter dekomponiert werden, wenn auf keine Anweisung ohne Funktionalitätsverlust

verzichtet

werden

kann.

Da

mit jeder

weiteren

Zerlegung

zusätzlicher

Steuerungs- und Kontrollbedarf entsteht, muß der Vorteil der atomaren Modularität mit dem Aufwand für die Steuerung der Module abgewogen werden. Die Modulzerlegung wird vor allem dann erschwert, wenn verschiedene Funktionen eines Moduls mit der gleichen Menge

-76-

F uriktionsmodellierung

von Datenobjekten arbeiten. Je größer diese Datenmenge ist, desto höher wird der Aufwand für die Datenkopplung bzw. der Aufwand für die getrennte Vor- und Nachbereitung des Datenzugriffs. Als sekundäres Kriterium für den internen Zusammenhalt wird daher die synergetische Verwendung von Datenstrukturen bei der Modulbildung berücksichtigt. Schließlich muß der Einfluß der Modulanordnung auf die Ausführungseffizienz bedacht werden. Nach diesem Kriterium werden Module dann nicht weiter strukturiert, wenn die dadurch bedingte Erhöhung der Ausführungsgeschwindigkeit den Nutzen der Modularität übersteigt. Die Vorteile des Modularisierungsprinzips liegen vor allem in der einfachen Änderbarkeit und der Erweiterungsmöglichkeit des Systems. Dieses Konzept liegt bisher nur in wenigen Programmiersprachen, wie z.B. Modula-2, vollständig implementiert vor, daher stößt die Dekomposition der Funktionen nicht selten an technische Grenzen. Zusätzlich entsteht bei dem Versuch der konsequenten Modularisierung das Problem, daß aus programmiertechnischer Sicht andere Modulstrukturen sinnvoller erscheinen als aus der fachinhaltlichen Sicht. An dieser Stelle muß eine Unterscheidung getroffen werden zwischen solchen Funktionen, die im Querschnitt für alle Funktionseinheiten als anwendungsneutrale Erweiterung des Werkzeugsprachumfangs dienen, wie z.B. Funktionen für die Bildschirmdarstellung und die Datenzugriffe, und den eigentlichen Funktionen zur Lösung des Anwenderproblems. Die erste Gruppe kann in einer Funktionsbibliothek nach programmiertechnischen Kriterien organisiert werden, die anwendungsspezifischen Funktionseinheiten sollten jedoch gemäß den Strukturierungsprinzipien, angewendet auf den gesamten Problembereich, angeordnet werden. Zusätzlich kann durch organisatorische Maßnahmen, wie z.B. die Vorgabe von Regeln als verbindliche Programmierdisziplin, versucht werden, die konzeptionellen Vorteile der Modularisierung zu sichern. Gelingt das nicht, wird die Entwicklung spezieller Strukturierungsregeln erforderlich, um die technischen Möglichkeiten mit den fachinhaltlichen Anforderungen abzustimmen.

3.4.2. Diagrammtechniken Diagrammtechniken dienen zur besseren Nutzung der menschlichen Wahrnehmungsfähigkeiten, indem Objekte mit gleichen oder ähnlichen Eigenschaften zu übergeordneten "Superzeichen" zusammengefaßt werden. Dadurch kann man sich Informationen leichter einprägen und schneller abrufen. Diagramme umfassen im Gegensatz zur natürlichen Sprache nur wenige Worte mit präziser Semantik. Durch diese starke Einschränkung verringert sich die Zahl der kontextabhängigen Mehrdeutigkeiten einer Sprache. Diagramme werden vornehmlich als Hilfsmittel zur Strukturierung kreativer Gedanken beim Entwurf eines Systems eingesetzt. Darüberhinaus dienen Diagrammsprachen der Präzision bei der Kommunikation zwischen Entwicklern und Anwendern und auch innerhalb eines Entwicklerteams. Die Dokumentation des Systems wird durch Diagrammsprachen vereinheitlicht, bei der Wartung und Erweiterung des Anwendungssystems bilden sie eine wichtige Grundlage.

Funktionsmodellierung

-77-

Die Anwender und die Entwickler des Fachkonzepts können umso stärker in den Entwicklungs- und Spezifikationsprozeß einbezogen werden, je mehr allgemein verständliche Diagrammsprachen Venwendung finden.

3.4.2.1. Datenflußdiagramme Als elementares Analyseobjekt der Systemplanung wird der Strom der Daten durch ein informationsverarbeitendes System angesehen. Das Ziel der Analyse ist es, die Steuerungseigenschaften des Systems durch die Beschreibung seiner Datenverarbeitungs- und Datentransportprozesse aufzudecken, um die für einen Verarbeitungsprozeß erforderlichen bzw. von diesem erzeugten Daten zu dokumentieren. Zur Beschreibung der Datenflüsse wurden unterschiedliche Diagrammtechniken vorgeschlagen. Eine Diagrammsprache, der Datenflußplan, ist nach DIN 66001 standardisiert. Datenflußdiagramme (z.B. nach De Marco) hingegen existieren in zahlreichen Varianten. Im Datenflußdiagramm werden Prozesse, im Anwendungsbeispiel entsprechend die Geschäftsvorgänge, und die zwischen den Prozessen ausgetauschten Daten analysiert und abgebildet. Ein Datenflußdiagramm besteht aus vier Grundelementen: • Prozeß, repräsentiert als Rechteck mit abgerundeten Ecken, • Datenfluß, der als Pfeil eingetragen wird, • Datenspeicher, symbolisiert durch ein halboffenes Rechteck und • Datenquellen und Datensenken, welche als Rechteck abgebildet werden.

Abb. 16: Datenflußdiagramm für Bestellvorgang

Die Datenquellen und -senken sind abstrakte Repräsentationen von selbständigen Objekten, die außerhalb des abgebildeten Informationssystems existieren. Jedem Element eines Datenflußdiagramms wird eine eindeutige Bezeichnung zugeordnet. Als wichtigste Regel für

-78-

Funktionsmodellierung

den Bezug zwischen den Elementen gilt, daß jeder Datenfluß entweder von einem Prozeß ausgehen oder in einen Prozeß hineinmünden muß, d.h. Daten werden von Prozessen erzeugt bzw. angefordert. Die direkte Verbindung von Datenquellen bzw. -senken mit Datenspeichern und deren Verbindung untereinander ist demnach als eine Form des "Datenkurzschlusses" unzulässig. Das Diagramm muß mindestens eine Datenquelle und eine Datensenke aufweisen. Datenflußdiagramme eignen sich gut für die Gesamtdarstellung eines Informationssystems, weniger gut für Detailsichten, da mit zunehmender Detaillierung von Untersystemen immer mehr "künstliche" Datenquellen und -senken mit Schnittstellencharakter eingeführt werden müssen. Der Grobentwurf kann durch die schrittweise Zerlegung und die genauere Beschreibung der Prozesse fortentwickelt werden. Wie aus dem Beispiel des Bestellvorgangs deutlich wird, muß eine Unterscheidung zwischen Lieferant als Datensenke und Lieferantendatei als Datenspeicher getroffen werden, um den Zusammenhang zwischen Dokumentenfluß und Datenfluß abzubilden. Die Notwendigkeit zur inhaltlichen Übereinstimmung zwischen Dokument und gespeicherten Daten wird bei dieser Spezifikationsform erst nach Verfeinerung des Bearbeitungsprozesses sichtbar. Um das konzeptionelle Datenmodell bei der Datenflußdarstellung einzubeziehen, kann als Datenspeicher eine Menge von Entitätsbzw. Beziehungstypen des semantischen Datenmodells angeführt werden. Datenflußpläne und -diagramme sind nicht dazu geeignet, Funktionseinheiten und deren Verarbeitungsroutinen zu spezifizieren, da keine Strukturierungsmittel zur Verfügung stehen. Sie werden daher fast ausschließlich zur globalen Beschreibung von Systemen genutzt.

3.4.2.2. Kybernetische Schaubilder Zur optimalen Gestaltung betrieblicher Informationssysteme kann die Analysetätigkeit nicht auf die informatorischen Aspekte des Betriebsgeschehens beschränkt bleiben, vielmehr müssen bei der konzeptionellen Fundierung eines Aufgabengebiets auch die Zusammenhänge zwischen dem Informations- und dem Güter- bzw. Leistungsstrom aufgedeckt werden. Nur dadurch kann es gelingen, die Zweckbestimmung der Informations- und Kommunikationsaktivitäten vollständig zu dokumentieren. Durch die Einführung eines rechnergestützten Informationssystems wird ein Austausch der Technologie beabsichtigt, dessen sich der Fachbereich zur Erfüllung seiner Aufgaben bedient, deshalb sollte möglichst große Klarheit über die bestehenden, technikabhängigen Systemzusammenhänge herrschen. Das kybernetische Schaubild kann im frühen Stadium der Systementwicklung helfen, • die Zusammenhänge zwischen Informationen und betrieblichen Aufgaben aufzudecken und • einen globalen Systembauplan zu entwickeln.

Funktionsmodellierung

-79-

Das kybernetische Modell wird häufig aus dem Organisationsplan einer Unternehmung entworfen. Das Schaubild besteht aus den Elementen • Informationsstrom, dargestellt als gepunkteter Pfeil, • Güterstrom, repräsentiert als durchgezogener Pfeil und • Steuerungseinheiten, die als Quelle und Senke für Informations- und Güterströme fungieren; sie werden als Rechtecke eingezeichnet. Steuerungseinheiten repräsentieren bei betrieblichen Anwendungssystemen die organisatorischen Einheiten (Geschäftsbereiche, Abteilungen, Stellen) gemäß dem Organisationsplan. Das Diagramm soll einen einheitlichen Detaillierungsgrad aufweisen, z.B. nur Abteilungen oder nur Stellen, die dann durch Grenzlinien zu Abteilungen zusammengefaßt werden. Erfüllt etwa eine Abteilung mehrere betriebliche Funktionen, werden Informationsströme innerhalb dieser Steuerungseinheit nicht notwendig gekoppelt sein. Wirken hingegen mehrere Stellen an der Erfüllung derselben Funktion mit, zeigt sich die Notwendigkeit zusätzlicher, koordinierender Informationsströme zwischen diesen Stellen. Die räumliche Verteilung organisatorischer Einheiten ermöglicht weitere Detaillierungen des Schaubilds. Das besondere Interesse der Analysetätigkeit gilt der Kopplung von Güterströmen mit Informationsströmen und den mit Güterströmen fest verbundenen Informationen. Im ersten Schritt werden gerichtete Verbindungen zwischen den eindeutig bezeichneten Steuerungseinheiten eingetragen und in ihrer Bedeutung spezifiziert. Die folgende Abbildung zeigt das kybernetische Schaubild für die in der Fallstudie beschriebenen Austauschprozesse.

Abb. 17: Kybernetisches Schaubild

-

8 0 -

Funktionsmodellierung

Im obigen Schaubild wurde auf die Darstellung der Zahlungsströme, die als eine spezielle Kategorie von Leistungsströmen aufzufassen sind, aus Vereinfachungsgründen verzichtet. Im zweiten Schritt wird versucht, die Art der Kopplung zwischen den einzelnen Strömen aufzudecken und anschließend zu klassifizieren. Jede Kopplung stellt die Abstraktion eines Transformationsprozesses dar, der aus eingehenden Informationen bzw. Gütern ausgehende Informationen erzeugt oder aber ausgehende Güter und weitere materielle Leistungen produziert. Dabei werden drei Kopplungsarten unterschieden, • die zeitliche, • die kausale und • die dispositive Kopplungsart. Kopplungen können ausschließlich innerhalb einer Steuerungseinheit auftreten. Die zeitliche Kopplung liegt vor, wenn ein eingehender Strom unmittelbar, d.h. ohne nennenswerte zeitliche Verzögerung, einen oder mehrere ausgehende Ströme induziert. Die kausale Kopplungsart beschreibt die auslösende Wirkung eines Stroms auf einen oder mehrere andere Ströme und determiniert im Gegensatz zur zeitlichen Kopplung nicht die zeitliche Dimension, d.h. die Folgeaktion kann mit zeitlich unbestimmter Verzögerung erfolgen. So kann etwa ein Stapel von eingehenden Strömen in einer Steuerungseinheit gesammelt und dort auf einmal verarbeitet werden, bevor die entsprechenden Folgeaktionen induziert werden. Die schwächste Art der Kopplung bildet die dispositive Kopplung, welche dann vorliegt, wenn eine Folgeaktion ausgelöst werden kann, dies jedoch nicht zwingend erfolgen muß. Die Entscheidung darüber wird selbständig von der jeweiligen Funktionseinheit getroffen. Die Analyse der Kopplung von Informations- und Güterströmen verfolgt das Ziel, die Zusammenhänge und insbesondere die Abhängigkeiten zwischen den Strömen aufzudecken, um so den Zweck jedes einzelnen Informationsstroms zu bestimmen. Dabei muß als wichtige Bedingung der Steuerungslogik beachtet werden, daß kein Informationsstrom sich selbst direkt oder indirekt über einen Zyklus aus zeitlichen und / oder kausalen Kopplungen auslösen darf. Dadurch wird sichergestellt, daß die abgebildete Systemsteuerung eindeutig ist. Bei der Modellbildung wird gleichzeitig berücksichtigt, daß jeder zusätzliche Informationsstrom höhere Kosten für die Entwicklung und die Steuerung des Informationssystems verursacht. Daher dient ein kybernetisches Schaubild auch dem Fachbereich zur Überprüfung der organisatorischen Effizienz. Nach Analyse und Eintragung der einzelnen Kopplungsarten sollte für jeden Güterstrom mindestens eine Startkopplung vorliegen. Informationsströme ohne Startkopplung bilden Ausgangspunkte für Geschäftsvorgänge. Mindestens ein Informationsstrom muß demnach als Startpunkt vorliegen. Ströme, die keine unmittelbar steuernde Wirkung aufweisen und insofern nur eine relevante Zustandsänderung des Systems repräsentieren, erhalten anstelle einer ausgehenden Kopplung eine entsprechende Abschlußmarkierung.

Funktionsmodellierung

- 8 1

-

Das Fallbeispiel wurde in der nachfolgenden Abbildung um die Kopplung der Informationsund Güterströme erweitert. Die dabei notwendige Detaillierung führt z.B. zu einer genaueren Beschreibung des Versandvorgangs.

I Zeitliche Kopplung ' Kausale Kopplung 1

Angebot

Dispositive Kopplung

Bestellauftrag Lieferschein Bngangsrechnung Kundenangebot

Büro Kundenauftrag

¡rant

Kunde

Versandfreigabe Warenentnahme

Rückmeldung

Montage / Lackierwerkstatt

Warenverteilung Artikelzugang Material entnähme

Lager

! Materialanforderung

Abb. 18: Kybernisches Schaubild mit Kopplungsarten Aus dem kybernetischen Modell kann man demnach die relevanten Geschäftsvorgänge und die notwendigen Datenobjekte der Benutzersicht ableiten. Weiterhin ist es unter Beachtung der zeitlichen Verknüpfungen möglich, die vom Informationssystem zu realisierenden Transaktionen zu bestimmen. Verknüpfungen mit kausalen und dispositiven Kopplungen zeigen die Notwendigkeit an, an diesen Stellen "Gedächtnisse" zu führen, um den jeweiligen Systemzustand zu speichern. Kausale Verknüpfungen erfordern i.d.R. weitere Analysen über die maximal tolerierte zeitliche Verzögerung, um entsprechende Bedingungen für die Auslösung eines steuernden Informationsstroms festzulegen. Im obigen Beispiel kann etwa die mangelnde Verfügbarkeit von Material den Produktionsprozeß verzögern, daher ist die Einführung eines entsprechenden Informationsstroms zur Materialdisposition

("Büro")

sinnvoll. Kausale Verknüpfungen können durch Regeln meist vollständig beschrieben werden, dispositive Verknüpfungen deuten jedoch auf komplexe Verarbeitungsprozesse mit erhöhtem Spezifikationsbedarf hin. Abschließend können die in einer Steuereinheit terminierenden Ströme genauer analysiert und die zusammenhängenden Kopplungen als jeweils eigenständiger Funktionsbereich präziser modelliert werden.

-82-

Funktionsmodellierung

Das kybernetische Modell veranschaulicht somit die Unternehmensprozesse, d.h. die Geschäftsvorgänge, zur Erfüllung der Unternehmensfunktionen unter den räumlichen und organisatorischen Bedingungen (der Aufbau- und Ablauforganistion) des Unternehmens.

3.4.2.3. HIPO-Diagramme Die weit verbreitete HIPO-Diagrammtechnik (Hierarchie plus Input-Process-Output) unterstützt im Gegensatz zum Datenflußdiagramm den Funktionsentwurf vom Konzept bis zum Detail nach dem Top-Down-Prinzip. Die HIPO-Diagrammsprache basiert auf dem grundlegenden EVA-Prinzip von EDV-Anlagen (Eingabe-Verarbeitung-Ausgabe). Sie läßt sich in natürlicher Weise für die Funktionsmodellierung anwenden, denn eine Funktionseinheit kann als abstrakte (virtuelle) Maschine angesehen werden. HIPO stellt für die unterschiedlichen Abstraktionen mehrere Diagrammtypen zur Verfügung. Der Grobentwurf eines Informationssystems wird als Baumdiagramm dargestellt, das als Strukturübersicht bezeichnet wird. Der Feinentwurf erfolgt mit Hilfe des Ebenendiagramms, das für jede Funktion die Menge der Inputdaten, den Funktionsablauf und die Menge der Outputdaten beschreibt. Die Ein- und Ausgabedaten sind durch Symbole aus der Sprache des Datenflußplans als Dokumente, Tastatureingaben, Datenspeicher etc. stilisiert. Ebenendiagramme werden während des Feinentwurfs noch weiter untergliedert in Überblicks- und Detaildiagramme. Die Anwendung der HIPO-Diagrammtechnik unterstützt das Denken in Funktionen, daher kann ein organisatorischer Bereich, der einheitlich nach dem Verrichtungsprinzip strukturiert ist, sehr einfach in die Strukturübersicht umgesetzt werden. An einem von der Fallstudie unabhängig gewählten Beispiel wird im folgenden die HIPODarstellungstechnik veranschaulicht. In einer organisatorischen (a)

Angebote

Einheit "Einkauf' bestehen folgende

von Lieferanten einholen und

Aufgaben:

bewerten,

(b)

Lieferangebote für Bestellungen auswählen und

(c)

Materialbestellungen

durchführen.

Da betriebliche Funktionen bereits im Organisationsprozeß gegliedert und nach unterschiedlichen Kriterien auf Stellen verteilt werden, kann die Funktionsbeschreibung nicht vom organisierten Ist-Zustand eines Unternehmens ausgehen, sondern muß versuchen, einen Funktionsbereich als Ganzes ohne Berücksichtigung der Organisationsstrukturen abzubilden. Zur Klärung der Funktionszusammenhänge kann das kybernetische Schaubild verwendet werden, sofern nicht bereits ein Unternehmensfunktionsmodell vorliegt. Weitere

Geschäftsvorgänge,

etwa in den

die zur Erfüllung der Aufgaben

Organisationsbereichen

"Lager",

der Einkaufsfunktion

"Warenannahme"

finden. Die betriebliche Funktion wird z.B. um folgende Aufgaben (d)

Warenlieferungen

(e)

Eingangsrechnungen

prüfen, d.h. mit Bestellungen (sachlich und rechnerisch)

und

dienen, sind

"Rechnungswesen"

ergänze

vergleichen und erfassen prüfen und erfassen.

sowie

zu

Funktionsmodellierung

- 83-

Die Auflistung dieser zweckgerichteten Aufgaben liefert eine informale Beschreibung der betrieblichen Funktion "Beschaffungsdisposition". Die informal beschriebene Unternehmensfunktion wird nun in ein formales Funktionsmodell transformiert, indem man die zur Erfüllung der Aufgaben erforderlichen Informationsverarbeitungsaktivitäten analysiert und strukturiert. Die hierbei angewendeten Analyseschemata, welche im nachfolgenden Abschnitt zur Funktionsanalyse vorgestellt werden, determinieren in erheblichem Maß die Konstruktion der Funktionseinheiten, die als abstrakte Aufgabenträger für eine Menge von Informationsverarbeitungsaufgaben eingeführt werden.

o Strukturübersicht Die Funktionen werden gemäß ihrer Abhängigkeit von anderen Funktionseinheiten hierarchisch zu einem Funktionsbaum angeordnet. Als Kriterium für die Über- oder Unterordnung verwenden wir den Beitrag einer Funktion zur Erfüllung der Aufgaben anderer Funktionseinheiten. Jedem Element des Funktionsbaums, außer der Wurzel, muß jeweils genau ein anderes Element übergeordnet werden. Die hierarchische Ordnung entspricht der methodischen Idee, daß Aufgaben nur im Kontext einer Funktion eine genaue Bedeutung besitzen können. Umgekehrt heißt das: Jede definierte Aufgabe tritt genau einmal im gesamten Funktionsbaum auf. Eine derartige Funktionsdekomposition berücksichtigt bereits die aufgabensynthetischen Überlegungen, die bei der Integration von Teilsystemen notwendig werden. Die Strukturübersicht beinhaltet als Wurzel eine Unternehmensfunktion und detailliert die Aufgaben bis zur Ebene der notwendigen Informationsverarbeitungen einzelner Geschäftsvorgänge. Die Aspekte der Ablaufsteuerung und der dynamischen Verbindung von Funktionseinheiten finden auf der fachinhaltlichen Abstraktionsebene keine Beachtung. Die Strukturübersicht wird ohne Berücksichtigung von DV-technischen Aspekten entwickelt, d.h. der Fachbereich kann die Strukturübersicht auf der Grundlage sachlogischer Überlegungen selbständig entwerfen. Dabei sollte auch unmittelbar erkennbar sein, daß dieses Diagramm ausschließlich die fachliche Sicht auf die Informationsverarbeitungsaufgaben widergibt. Das zu realisierende Informationssystem erzeugt zwar diese Sicht auf die Funktionen des Systems, enthält jedoch intern eine nach zweckmäßigen Kriterien modularisierie Struktur, die prinzipiell von der Fachsicht unabhängig konzipiert wird.

-84-

Funktionsmodellierung

Beschaffungsdisposition

I

I

Angebot

Lieferung

Bestellauftrag

BA-Bearbeitung

prüfen

Rechung

prüfen

Angebot auswählen

Abb. 19: Strukturübersicht der Informationsverarbeitungsaufgaben einer Beschaffungsdisposition Die HIPO-Diagrammtechnik stellt nur geringe formale Anforderungen und kann mit wenigen Regeln beschrieben werden. Sie bietet daher sehr viele Freiheitsgrade für die strukturierte Abbildung eines Funktionskomplexes. Die Transformation der fachinhaltlichen Funktionsstruktur in eine möglichst effiziente DV-technische Verarbeitungsstruktur fällt dann sehr leicht, wenn alle Funktionen eindeutig abgebildet sind, nicht weiter zerlegt werden können und alle Abhängigkeiten der Funktionen untereinander aus dem Schaubild klar zu entnehmen sind. Auf der untersten Hierarchiestufe sollten nach Möglichkeit einzelne Tätigkeiten abgebildet werden, die aus einem Ausgangszustand einen Endzustand erzeugen, d.h. ein nicht definiertes Zwischenergebnis ist als Endzustand ausgeschlossen, z.B.: Ein Bestellauftrag ist entweder erfaßt oder nicht erfaßt, eine Lieferung ist geprüft oder

ungeprüft.

Die obige Darstellung kann aus der Perspektive des Fachgebiets als ausreichend detailliert angesehen werden, jedoch liefert sie nur wenige Ansatzpunkte für das Wie des DVtechnischen Entwurfs. Bei der Analyse dieser Strukturübersicht wäre unter anderem festzustellen, daß alle Aufgaben objektzentriert gegliedert sind. Verwendet man bei der Analyse des Funktionsbereichs ein einheitliches Modell, das die Bearbeitungsobjekte (z.B. einen Bestellauftrag) und die Vorgänge zur Bearbeitung der Objekte zu trennen versucht, wird eine detaillierte Struktur erzeugt, welche die Ablaufanforderungen genauer zum Ausdruck bringt. Bei der Transformation der fachinhaltlichen Strukturübersicht des obigen Beispiels ersetzen wir gleichzeitig die Fachbegriffe so weit als möglich durch DV-technische Begriffe.

Funktionsmodellierung

- 85-

Abb. 20: DV-technische Strukturübersicht (Ausschnitt) Die Funktionseinheiten "Bestellung" und "Stornierung von Bestellungen" werden hier getrennt von den Funktionseinheiten zur Verwaltung der Angebote und Bestellaufträge entworfen. Zusätzlich zur hierarchischen (statischen) Funktionsgliederung werden die logischen Abhängigkeiten zwischen den Funktionseinheiten mit Pfeilen markiert. Dadurch bleibt das fachinhaltliche Funktionenkonzept sichtbar, während gleichzeitig die für die Funktionsausführung bedeutsamen Zusammenhänge geklärt werden. Die schattiert dargestellten Rechtecke repräsentieren im Gegensatz zu den übrigen, statischen Funktionseinheiten ausschließlich virtuelle Funktionseinheiten. Diese werden durch die Duplizierung bestehender Funktionseinheiten gebildet, die Pfeile markieren die Übertragung einer Teilfunktion an eine dafür spezialisierte Funktionseinheit. Beim Entwurf dieser Strukturübersicht sind durch die Unterscheidung von Bearbeitungsobjekten und Vorgängen implizit bereits Überlegungen zur Konstruktion von Modulen eingeflossen. Funktionen, die jeweils dasselbe Objekt betreffen, wurden gruppiert, und gleichartige Verarbeitungsroutinen wurden durch die Einführung virtueller Funktionseinheiten zusammengefaßt.

o Überblicksdiagramm In der zweiten Stufe des Grobentwurfs wird für jede statische Funktionseinheit der untersten Hierarchiestufe ein Überblicksdiagramm entworfen. Jede Funktionseinheit gehorcht dem Modell O = F(l). Die Funktion F bildet die Menge der Eingangsdaten I auf die Menge der Ausgangsdaten O ab. Die Vorgehensweise der Modellierung vollzieht sich vom Output zum Input. Nach der Bestimmung des Funktionsergebnisses wird eine Verarbeitungsvorschrift ermittelt, die aus verfügbaren Eingangsdaten die gewünschten Ausgangsdaten erzeugt. Im Überblicksdiagramm muß mindestens ein Datenelement als Input und mindestens eines als

-86-

Funktionsmodellierung

Output enthalten sein. Als Datenobjekte sind in der ursprünglichen Fassung dieser Diagrammtechnik ausschließlich Dateien, Geräte zur Dateneingabe und -ausgabe sowie Informationsträger (z.B. Dokumente) vorgesehen. Die in Überblicksdiagrammen verwendeten Datensymbole werden in der folgenden Abbildung vorgestellt.

Daten auf Schriftstück, Beleg

Daten auf Speicher mit nur sequentiellem Zugriff

Daten allgemein

Manuelle optische oder akustische Eingabedaten

BenutzerStation Optische oder akustische Anzeige

Abb. 21: Symbole des Datenflußplans (Ausschnitt)

Zur Spezifikation von Funktionen, die als Input bzw. Output die Tabellen eines RDBMS verwenden, werden anstelle einzelner Dateien dann Basistabellen oder funktionsspezifische Datensichten (Views) angegeben. Bei Verwendung eines RDBMS, wovon wir in den folgenden Ausführungen ausgehen, entfallen die zur Dateiverarbeitung notwendigen Öffnungs- und Schließoperationen. Die Symbolmenge des Datenflußplans, die zur Stilisierung der Bearbeitungsobjekte verwendet wird, enthält keine Symbole für Basistabellen bzw. Views. Basistabellen werden im folgenden mit dem Datei-Symbol gekennzeichnet, die funktionsspezifischen Datensichten werden zusätzlich als View benannt. In der folgenden Abbildung wird das Überblicksdiagramm für vier ausgewählte Funktionseinheiten des obigen Beispiels vorgestellt. Dabei wird in einer Erweiterung gegenüber der ursprünglichen Fassung dieser Diagrammtechnik die Abbildung um die Angabe der von einer Funktionseinheit referierten (virtuellen) Funktionseinheiten ergänzt. Auf diese Weise können die Abhängigkeiten zwischen den Funktionseinheiten vermerkt und Anhaltspunkte für die Bildung von Modulen aufgezeigt werden.

Funktionsmodellierung

Lieferant

Material

- 87-

Angebot

o

Angebot suchen

y Lieferant

Material

Bestellauftrag

BAPos

Lieferant

Material

Bestellauftrag einfügen

BAPos

Besteig auftrag L-

j

^

j

a

Bestellauftrag drucken Bestellauftrag

BAPos

c m

c n

Bestellung (Vorgang)

[11.(5), [7]

Abb. 22: Ebenendiagramm I: Überblicksdiagramm

Die optionale Numerierung der Funktionen dient nicht nur zur vereinfachten Benennung, sondern auch zur Überprüfung der Vollständigkeit eines Funktionsmodells. Die Spezifikation der Funktionen verfährt zweckmäßig in der Rangfolge von den einfachen zu den komplexen Funktionen, da der Entwickler während des Detaillierungsvorgangs Funktionszusammenhänge und -eigenschaften zunehmend durchschaut. Der Steuerfluß der Funktionseinheit ist auf dieser Abstraktionsstufe ohne Belang. Als Vorteil dieser Diagrammtechnik zeigt sich die einfache Darstellungsweise, die sich dadurch gut als Dokumentation eignet. A u s d e m HIPO-Diagramm läßt sich eine Datenverwendungsmatrix ableiten, die angibt, welche Funktionseinheit auf welche Datenbestände lesend oder schreibend zugreift. Da bei der Modellierung der Ressourcen bereits eine relativ hohe Detaillierung erforderlich ist, muß das konzeptionelle Datenmodell diesem Entwurf bereits als stabile Größe zugrunde liegen. Diese Abstraktionsebene bietet jedoch keine ebenso hohe Detaillierung der Funktionsvorschrift an. Die interne Strukturierung der Funktionseinheiten wird im nachfolgenden Detailentwurf durchgeführt.

F unktionsmodellierung

-88-

o Detaildiagramm Das Detaildiagramm nimmt den Steuerfluß und den Datenfluß explizit in die Darstellung auf und ordnet jedem verbal zu beschreibenden Verarbeitungsschritt die erforderlichen Inputsowie die erzeugten Outputdaten zu. Hierbei verläuft der Steuerungsfluß innerhalb einer Funktionseinheit von oben nach unten und der Datenstrom (streng) von der Eingabe zur Ausgabe. Im Detaildiagramm wird erkennbar, welche Verarbeitungen auf die gleichen Inputbzw. Outputelemente zugreifen. Aus der Kenntnis dieser Beziehungen leiten sich Hinweise für die weitere Strukturierung der Funktionseinheit ab. Jedoch stellt die HIPO-Methode -wie man auch aus der nachfolgenden Abbildung ersehen kann- keine weiteren formalen Regeln zur Modularisierung zur Verfügung.

[5] BESTH_LAUFTRAG EINFÜGEN 1. Einlesen Lieferantennummer Lieferant

Ist Lieferant bereits angelegt ? Wenn Nein = > STOP 2. Bnlesen Bestelldatum

Material

Ist Bestellauftrag bereits angelegt ? Wem Ja = > STOP

3. Bnlesen gewünschtes Ueferdatum 4. Speichern Bestellauftrag 5. Bnlesen Materialnummer Ist Materialtyp bereits angelegt ?

Verzweige nach [8] Bestell auftrag

Ist BA-R)sition bereits angelegt ? Wem Ja » > Suche BA-Fbsition heraus

auftrag

6. Bnlesen EW-Fbsitionsdaten (Stückpreis, Menge) BAPos

7. Speichern BA-Fbsitionsdaten

RAFbs

8. Sind alle EA-Fbsitionen erfaßt ? Wem Nein = > Verzweige nach [5], Sonst STOP

Abb. 23: Ebenendiagramm II: Detaildiagramm Aufgrund der fehlenden Übersichtlichkeit dieses Diagrammtyps erscheint es häufig zweckmäßig, auf die Entwicklung des Detaildiagramms zu verzichten und stattdessen ein Struktogramm zu erstellen. Zusammenfassend können die HlPO-Diagramme als einfach zu handhabende und leicht verständliche Entwurfssprache angesehen werden. Sie unterstützen jedoch nur teilweise die Modularisierung und bieten für den Detailentwurf keine ausreichenden Mittel zur strukturierten Programmierung. Andererseits erlaubt diese Diagrammtechnik auch, zusätzliche Analyse- und Konstruktionsschemata einzubeziehen.

Funktionsmodellierung

- 89-

3.4.2.4. Struktogramme Das HIPO-Entwurfsergebnis weist eine Baumstruktur auf. Die zyklenfreie Struktur des Funktionsbaumes liefert eine gute Voraussetzung für den Aufbau einzelner Programmmodule. Die Konstruktion der Module und ihre Verknüpfung unterliegt während der weiteren Verfeinerung den Regeln der strukturierten Programmierung: • Jedes Modul bildet eine abgeschlossene funktionale Einheit, die eine eindeutige Grenze zwischen internen und externen Funktionsbestandteilen besitzt. Andere Module sind entweder vollständig in ihm enthalten oder liegen als Ganzes außerhalb des Moduls. • Jeder Baustein besitzt genau einen Eingang und genau einen Ausgang. • Die Steuerungsdaten durchlaufen den Programmbaustein von oben nach unten. Durch die Anordnung der Bausteine (seriell, parallel oder ineinandergeschachtelt) wird die statische Bindung als Struktur des Bausteins festgelegt. • Für die dynamische Verbindung zwischen den Bausteinen gilt, daß die Steuerung von einem Baustein nur an einen untergeordneten Baustein übergeben werden darf. Dieser kann wiederum untergeordnete Bausteine aufrufen, nach Beendigung der Operation gibt er jedoch die Kontrolle wieder an das übergeordnete Modul zurück. Programme gelten gemäß den Regeln der Strukturierten Programmierung spezifiziert, wenn jeder dynamische Ablauf aus der statischen Notation erkannt werden kann. Der Steuerfluß eines Programms muß im Diagramm selbst begründet werden, indem die Bedeutung einer Steuerflußänderung eindeutig geklärt wird. Dies kann bei Verwendung der GOTOAnweisung nicht gelten, denn damit kann z.B. eine Wiederholung, ein Prozeduraufruf oder das Ende einer Auswahl gemeint sein. Die Strukturierte Programmierung im engeren Sinn versucht nun, durch Einschränkung der Mittel zur Steuerung eines Programms die logischen Anlässe für eine Änderung des Steuerflusses in ihrer Bedeutung aufzuklären. Zur Steuerung eines Programms wären bereits zwei Mittel hinreichend: • die Auswahl, die eine Verzweigung zwischen zwei oder mehreren Programmbausteinen durch Prüfung einer logischen Bedingung regelt, und • die Wiederholung zur Steuerung des wiederholten Durchlaufs einer oder mehrerer Anweisungen. Setzt man als Bedingung für eine Auswahl einen logischen Ausdruck ein, der stets "wahr" ergibt, kann die Abarbeitung mehrerer Anweisungen in einer festen Sequenz erzwungen werden. Dies entspricht dem Steuerkonstrukt Folge, das aus mehreren aufeinanderfolgenden Befehlen besteht. Das Nassi-Shneidermann-Diagramm (Struktogramm) stellt ausschließlich Strukturblock-Symbole für die elementaren Steuerkonstrukte Auswahl, Wiederholung und Folge zur Verfügung. Als eine wichtige Erweiterung dieser Diagrammsprache beziehen wir das Symbol für den Unterprogrammaufruf mit in die Darstellung ein.

-90-

Funktionsmodellierung

o Folge Mehrere Anweisungen, die sequentiell nacheinander ausgeführt werden sollen, repräsentiert man durch untereinander angeordnete Elementarblöcke. Ein Elementarblock, dargestellt durch ein Rechteck, enthält entweder einen Befehl der Programmlersprache oder den Namen eines Unterprogramms oder eine Verzweigung bzw. Wiederholung als selbständigen Block. Jeden einzelnen Befehl durch ein Rechteck zu symbolisieren, erscheint sehr aufwendig, daher ordnet man häufig logisch zusammenhängende Anweisungen innerhalb eines Rechtecks sequentiell an.

o Unterprogramm Eine Folge von Anweisungen, die von einem übergeordneten Strukturblock verwendet wird, kennzeichnen wir durch zwei ineinandergeschachtelte Rechtecke, wobei im äußeren Rechteck der Name des Unterprogramms und im inneren Rechteck die Aufrufparameter angegeben werden. Soll das Unterprogramm nicht gesondert detailliert werden, kann im inneren Rechteck ebenfalls dessen vollständige Struktur aufgeführt werden.

o Auswahl Der Strukturblock der bedingten Verzweigung kennzeichnet die Auswahl durch eine logische Bedingung zwischen zwei einmalig auszuführenden Blöcken. Führt die Auswertung

Funktionsmodellierung

-91 -

der Bedingung zum Ergebnis "wahr", wird der erste Block (THEN-Block), im anderen Fall der zweite Block (ELSE-Block) ausgeführt. Häufig werden Verzweigungen mit nur einem Anweisungsblock erforderlich, der andere, leere Block weist dabei zwei diagonal gekreuzte Linien auf. Die Mehrfachauswahl (CASE-Block) ermöglicht eine bedingte Auswahl für mehr als zwei Alternativen. Der Block zur Berücksichtigung aller sonstigen und einheitlich zu verarbeitenden Fälle (OTHERWISE-Block) sollte dabei ganz rechts angeordnet sein.

o Wiederholung Zu unterscheiden sind köpf- und fußgesteuerte Schleifentypen. Die Zählschleife gilt als spezielle Fassung der kopfgesteuerten Schleife. Die kopfgesteuerte Schleife (WHILESchleife) prüft vor Ausführung des Verarbeitungsteils die Wiederholungsbedingung, während die fußgesteuerte (REPEAT-Schleife) erst nach Verarbeitung des Schleifenrumpfes eine Endebedingung abprüft. Die Zählschleife führt eine fixe, durch den Index und die Schrittweite festgelegte Anzahl von Wiederholungen durch. Prinzipiell genügt zum Entwurf eines beliebigen Programms die Verfügbarkeit des köpf- oder des fußgesteuerten Schleifentyps, wobei die ausschließliche Verwendung der kopfgesteuerten Schleife weniger zusätzlichen Programmcode erfordert als die des fußgesteuerten Typs. Als Sonderform der Wiederholung wird die abbruchgesteuerte Schleife (DO FOREVER) angesehen, die eine Abbruchbedingung innerhalb des Verarbeitungsteils (IF THEN EXIT) abfragt. Das Strukturierungsprinzip wird dabei jedoch durchbrochen, wenn diese Schleife mehr als einen Ausgang aufweist. Die Struktogrammtechnik unterstützt den normativen Programmentwurf, denn sie zwingt den Entwickler, durch die Verwendung der Strukturblöcke als einzig zulässige Konstrukte, ein Programm strukturiert zu erstellen. Darüberhinaus stellen Struktogramme eine gute Programmdokumentation dar. Die schrittweise Verfeinerung eines Programms wird durch das Konzept der Blockbildung und der Unterprogrammbildung ermöglicht. Die Anwendung der Strukturierungsregel, daß ein Block nur einen Ausgang besitzen darf, führt tendenziell zu tief verschachtelten Blöcken, da Steuerungsparameter im Blockausgang zusammengefaßt und im nachfolgenden Block wieder getrennt behandelt werden müssen.

3.4.3. Entwurf von Funktionseinheiten Die Aufgabe des Funktionsentwurfs ist es, aus den im Rahmen der Funktionsanalyse gewonnenen Anforderungen an das Anwendungssystem Funktionen abzuleiten und entsprechende Funktionseinheiten als Module zu konstruieren. Eine Funktionseinheit realisiert den Übergang von einem Ausgangszustand, der durch Wertemengen des Datenmodells repräsentiert ist, in einen Folgezustand, der wiederum als Wertausprägung des Datenmodells abgelegt werden kann oder jedoch an ein aufrufendes Modul bzw. direkt an den Benutzer weitergegeben wird. Funktionseinheiten stellen eine funktionale Abstraktion als Menge abstrakter Operationen auf definierten Datenmengen dar. Allein durch die Verwendung des Funktionsbezeichners ohne zusätzliche Kenntnisse der internen Verarbeitungsschritte ist es möglich, eine funktionale Abstraktion zu benutzen. Durch Funktions-,

-92-

Funktionsmodellierung

Unterprogramm- und Nachrichtenkonzepte werden funktionale Abstraktionen in Programmiersprachen realisiert. Funktionseinheiten werden durch Aktionen des Steuerungssystems aktiviert. Die Steuerung programmieren wir durch die logische Beschreibung des Programmablaufs mit den Konstrukten der strukturierten Programmierung. Funktionseinheiten besitzen für die von einem Datenbankmanagementsystem zur Verfügung gestellten Daten kein exklusives Gedächtnis zur Speicherung von Zwischenzuständen. Alle globalen Zustände werden vom Datenmodell erfaßt und definiert. Demnach kann sich das Geheimnisprinzip nur auf die internen Datenstrukturen und die Verarbeitungslogik beziehen, nicht auf die Struktur und die Werte der von einer Funktionseinheit verwendeten Datenelemente, die auf dem externen Speicher abgelegt werden. Zur Vermeidung von Seiteneffekten, das sind lokal nicht begrenzbare, also Undefinierte Zustandsänderungen, ist es erforderlich, interne Datenstrukturen zu verkapseln, um so den direkten Datenzugriff fremder Module zu unterbinden. Datenbanksysteme stellen in der Form der Transaktionskontrollen einen Schutzmechanismus zur Verfügung, der die Integrität von Datenbeständen operativ sichert. Transaktionskontrollen werden vor allem im Mehrbenutzerbetrieb erforderlich, um zu gewährleisten, daß ein konsistenter Anfangszustand in einen ebenso konsistenten Endzustand überführt wird, dabei ist bei fehlerhaften Ausführungen die Rückabwicklung zum Anfangszustand vorgesehen.

3.4.3.1. Typisierung von Funktionseinheiten Funktionseinheiten für betriebliche Anwendungen lassen sich nach ihrem unterschiedlichen Zweck charakterisieren. Im Hinblick auf den vorliegenden betrieblichen Anwendungsbereich treffen wir eine möglichst zweckmäßige Gliederung in: •

Datenverwaltungsfunktionen,

• Vorgangsfunktionen und • Auswertungsfunktionen. Die Funktionen zur Datenverwaltung realisieren die elementaren Anforderungen des Benutzers an die Bearbeitung einzelner Datenobjekte. Die Datenobjekte der Benutzersicht müssen nicht notwendigerweise genau einem Element (Entitätstyp, Beziehungstyp) des konzeptionellen Datenmodells entsprechen. Die Menge der Benutzerobjekte leiten wir aus der Analyse der Geschäftsvorgänge analog zur Vorgangskettenanalyse ab. Aus der Benutzersicht stellt zum Beispiel ein Auftrag eine Einheit dar, die als Ganzes bearbeitet werden soll. Gemäß dem konzeptionellen Datenmodell setzen wir einen Auftrag aus dem Auftragskopf und den zugehörigen Auftragspositionen zusammen. Die Datenverwaltungsfunktion wird hinsichtlich ihrer Komplexität als einfach charakterisiert. Typische Operationen einer solchen Funktionseinheit sind das Einfügen, Suchen, Löschen und Drucken von Bearbeitungsobjekten. Je nach Mächtigkeit des Datenbanksystems sind diese Funktionen bereits Bestandteil der Datenmanipulationssprache. Wichtiges Merkmal der Datenverwaltungsfunktion ist der lokal begrenzte Schreibzugriff auf Daten eines Objekttyps der Benutzersicht.

Funktionsmodellierung

- 93-

Vorgangsfunktionen dienen der effizienten Abwicklung von Geschäftsvorgängen.

Da

während eines Geschäftsvorgangs ausschließlich Benutzerobjekte, in welcher Auswahl und Reihenfolge auch immer, bearbeitet werden, liegt es nahe, beim Entwurf soweit als möglich die elementaren Datenverwaltungsfunktionen als Bausteine für die Vorgangsfunktionen zu verwenden. Damit erhalten wir zusätzliche Regeln für die modulare Gestaltung des Systems. Jede Operation einer Datenverwaltungsfunktion muß durch eine Schnittstelle definiert und exportiert werden. Als Beispiel für eine Vorgangsfunktion beschreiben wir den Bestellvorgang. Bei diesem fragt,

Geschäftsvorgang

Bestellaufträge

Lagerbestands Ermittlung

werden

ausgefüllt,

kann durch eine Funktion

von Lieferkonditionen

dition" mit der Aktion wird ausgefüllt,

Lagerbestände

ausgedruckt

"Lagerbestand

durch Anfrage

"Suche preisgünstigste

indem die Funktionseinheit

lage" und anschließend

"Drucken"

beauftragt

überprüft,

und an Lieferanten ermitteln

Lieferantenkonditionen verschickt für Teiletyp

an die Funktionseinheit

Lieferkondition "Verwaltung

Bestellauftrag"

Prüfung

des

X"

erfolgen,

die

"Verwaltung

für Teiletyp

abge-

Die

X". Der

LieferkonBestellauftrag

mit der Aktion

"Neuan-

wird.

Wie In diesem Beispiel deutlich wird, tritt bei der Bearbeitung der Benutzerobjekte ein zusätzlicher Bedarf an Operationen auf, der von den elementaren Datenverwaltungsfunktionen noch nicht gedeckt wird. Wir müssen an dieser Stelle analysieren, ob dieser Funktionsbedarf • allgemein bei der Bearbeitung des Benutzerobjekts auftritt oder • nur bei diesem Geschäftsvorgang relevant ist. Im ersten Fall werden wir die Funktionseinheit zur Datenverwaltung entsprechend erweitern, im anderen Fall spezifizieren wir diese Operation zunächst als Bestandteil der Vorgangsfunktion. Nach einer weiteren Analyse kann die Zuordnung zur Datenverwaltungsfunktion dennoch erforderlich werden. Das charakteristische Merkmal der Auswertungsfunktionen ist der große, über mehrere Datenobjekte gestreute Bedarf an Inputdaten, wobei relativ geringe Datenmengen an den Benutzer ausgegeben werden. Selten werden Schreibzugriffe auf Datenbestände durchgeführt. Die Auswertungsergebnisse dienen in erster Linie der Information für das Management und werden meist in größeren zeitlichen Abständen abgefragt. Darüberhinaus werden sie auch in operative Geschäftsvorgänge integriert. Im obigen Beispiel kann etwa die Ermittlung des nach bestimmten Kriterien günstigsten Lieferanten als Auswertungsfunktion konzipiert werden. Nach dieser Klassifizierung der Funktionseinheiten tritt sicherlich die Frage auf, weshalb eine eigenständige Verwaltung der Benutzerobjekte vorgeschlagen wird, obwohl deren Bearbeitung bereits in den Vorgangsfunktionen enthalten ist. Diese scheinbare funktionale Redundanz bietet mehrere Vorteile: Zum einen können die Benutzerobjekte einzeln und außerhalb bestimmter Geschäftsvorgänge bearbeitet werden. Zum zweiten unterliegen Geschäftsvorgänge

im Zeitablauf gewissen Änderungen durch

ablauforganisatorische

Maßnahmen. Zusätzlich variieren organisatorische Abläufe je nach Unternehmenstyp und

-94-

Funktionsmodellierung

vor allem nach subjektiven Präferenzen der Anwender. Durch die Verfügbarkeit von Verwaltungsfunktionen ist das System auf diese Anforderungen konzeptionell vorbereitet. Die aus der Sicht des Benutzers redundant erscheinenden Funktionen liegen bei konsequent durchgeführter Modularisierung nur als einziges Programmodul vor.

3.4.3.2. Spezifikation abstrakter Funktionstypen Bevor im einzelnen die Input-, die Verarbeitungs- und Outputabstraktion dargestellt werden, sollte man versuchen, ein abstraktes Modell des Funktionstyps zu bilden. Aus dem jeder Funktionseinheit zugeordneten Zweck leitet sich ein Funktionstyp ab, der die funktionalen Eigenschaften in abstrakter Form zur Verfügung stellt. Zunächst werden für den Funktionstyp Datenverwaltung die Anforderungen gesammelt und als Operationen des Funktionstyps spezifiziert. Der Funktionstyp Datenverwaltung dient der umfassenden Bearbeitung eines Benutzerobjekts. Aus der Sicht der virtuellen Maschine können die Funktionselemente Eingabe, Speicherung, Wiedergewinnung und Ausgabe unterschieden werden. Aus der Sicht des Anwendungskontexts wird häufig eine Einteilung in Neuanlage, Suchen, Ändern, Löschen und Drucken vorgenommen. Die Löschoperation kann restriktiv oder kaskadiert konzipiert werden. Die restriktive Form beschränkt den Löschvorgang auf solche Tupel einer Tabelle, die in keiner anderen Tabelle als Fremdschlüsselwerte eingetragen sind. Die kaskadierte Form entfernt in jeder Tabelle, welche das zu löschende Tupel mittels Fremdschlüsseleintrag referiert, ebenfalls die betreffenden Tupel. Mit dieser Grundspezifikation kann in vielen praktischen Fällen bereits die volle Funktionalität der Datenverwaltung abgedeckt werden, dies darf nicht verschleiern, daß die Detaillierung der funktionalen Eigenschaften einer Datenverwaltungsfunktion analytisch aus den Anforderungen gewonnen wird. Der Funktionstyp Vorgang dient der effizienten Abwicklung eines Geschäftsvorgangs als Ganzes. Aus der Sicht der virtuellen Maschine ist die Unterscheidung der Prozeßzustände relevant, die sich als eine Kombination der Zustände einzelner Bearbeitungsobjekte ausdrücken. Die Sicht des Anwenders gewinnen wir, indem ein Geschäftsvorgang auf alle zulässigen Vorgangspfade hin untersucht wird, um Bedingungen für die Verzweigung, das vorübergehende Anhalten, den Abbruch oder die Rückabwicklung aufzudecken. Zusätzlich bildet die Möglichkeit zur teil- oder vollautomatischen Abwicklung von Vorgängen einen wichtigen Untersuchungsgegenstand. Elementare Funktionseigenschaften des Vorgangstyps sind die Initialisierung, die Unterbrechung und die Rückführung, die Ausführung kann in einem manuellen oder automatischen Modus erfolgen. Der Funktionstyp Auswertung erzeugt Informationen, die zur Beantwortung komplexer Fragen dienen. Hier mißt der Anwender der adäquaten Darstellung des Auswertungsergebnisses erhebliche Bedeutung bei, während für die Programmierung die effiziente Funktionsausführung im Vordergrund steht. Nicht selten werden Auswertungen wegen ihres enormen Dateninputs und umfangreicher Operationen im Stapelbetrieb durchgeführt. Eine häufig erforderliche Operation dieses Funktionstyps ist der Gruppenwechsel. Eine Gruppe stellt

Funktionsmodellierung

-95-

eine Menge von Einträgen einer Tabelle dar, die aufgrund ihrer Werte in bestimmten Spalten dem gleichen Ordnungskriterium entsprechen. Diese Menge wird nach einer einheitlichen Funktionsvorschrift bearbeitet und daraus eine aggregierte Größe errechnet. Beim sequentiellen Bearbeitungslauf erfolgt ein Gruppenwechsel, wenn der aktuell gelesene Eintrag gemäß seiner durch das Ordnungskriterium festgelegten Wertausprägung einer anderen Menge angehört. Zum Beispiel wird bei der Auflistung des Lagerbestands die Lagermenge eines Teiletyps von verschiedenen Lagerorten zu einem Gesamtbestand summiert und in der Reihenfolge aufsteigender Teilenummern ausgegeben. Alle Einträge in der Tabelle mit identischer Teilenummer bilden dabei eine Gruppe. Weitere typische Auswertungsoperationen sind die Mengenoperationen Vereinigung, Durchschnitt und Differenz.

3.4.3.3. Spezifikation der Funktionseinheiten Die Funktionsspezifikation vollzieht sich in mehreren aufeinanderfolgenden Schritten: Zunächst legen wir das Objekt der Analysetätigkeit fest, indem ein abgegrenzter Funktionsbereich, z.B. die Beschaffungsdisposition selektiert wird. Im Rahmen der Vorgangsanalyse bestimmen wir dann die Bearbeitungsobjekte des Benutzers. Im Anschluß werden die elementaren Funktionen zur Verwaltung der Benutzerobjekte definiert. Daran schließt sich die Spezifikation der Vorgangsfunktionen an. Dabei erweitert man gegebenenfalls die Verwaltungsfunktionen um notwendige Operationen. Zuletzt werden die Auswertungsfunktionen festgelegt, wobei bereits ermittelte Bedarfe für deren Integration entsprechend Berücksichtigung finden. Nach der sukzessiven Spezifikation der Funktionen für jeweils getrennt betrachtete Funktionsbereiche muß die Integration derjenigen Funktionen erfolgen, die an den Grenzstellen angeordnet sind. In unserem Fall muß insbesondere für Vorgangsfunktionen geprüft werden, ob Funktionen eines Bereichs (z.B. der Lagerzugang) in den Vorgang eines benachbarten Funktionsbereichs (z.B. der Lieferung) eingegliedert werden sollten. Am Beispiel der Beschaffungsdisposition wird dieses Vorgehen nun erläutert. Aus der in der Fallstudie gegebenen "Bestellvorgang",

den "Wareneingang"

gänge erkennen.

Aus der Anforderung

konzipieren

Beschreibung

der Beschaffungsvorgänge

und den "Rechnungseingang"

wir den neuen Vorgang

der

Geschäftsführung

können

als wichtige

zur Kontrolle

wir

den

Geschäftsvor-

von

Lieferzeiten

"Bestell-Uberwachung".

Welche Objekte werden in diesen Vorgängen bearbeitet ? Zur

Bestellung

werden

Lieferkonditionen

stands, die gemäß den Anforderungen sollte,

wird

verschickt

herangezogen.

in diesem Beispiel nicht berücksichtigt wird, ist das Ergebnis dieses

Die Prüfung des verfügbaren

in den automatischen

Bestellvorgang

Der Bestellauftrag,

integriert

der an den

Lagerbewerden Lieferanten

Vorgangs.

Für die Objekte "Lieferkondition" und "Bestellauftrag" legen wir zunächst die Standardoperationen der Datenverwaltung wie "Neuanlage", "Suchen" etc. fest. Bei der Bearbeitung "Materialtyp"

eines Bestellauftrags

benötigt

werden

auch die Daten der Entitäten

"Lieferant"

und

Funktionsmodellierung

-96-

Diese Daten müssen auch unabhängig vom Bestellvorgang gepflegt werden, und daher fügen wir dem Modell die Funktionseinheiten zur Datenverwaltung für "Lieferant" und "Materialtyp" hinzu. Beim Lieferungsvorgang

wird der Wareneingang verzeichnet

und der Bestellauftrag

abgehakt

Der Vorgang zur Einlagerung des Materials wird ebenfalls hier ausgelöst

Als weiteres Objekt der Datenverwaltung wird die Lieferung erforderlich. Bei Rechnungseingang sind Lieferantenrechnungen

zu prüfen, ob die in Rechnung

gestellten

Waren bereits in der richtigen Menge geliefert und mit dem im Bestellauftrag vereinbarten

Preis

berechnet wurden. Anschließend soll die Eingangsrechnung als Buchungssatz an die Finanzbuchhaltung weitergereicht

werden. Der Zahlungszeitpunkt

wird dann von der

Finanzbuchhaltung

bestimmt und die Buchung des Geschäftsvorfalls dort durch spezielle Funktionen

realisiert

Als letztes Objekt wird die Eingangsrechnung in das Verzeichnis der Datenverwaltungsobjekte aufgenommen. Die von der Geschäftsführung als "chic" bezeichnete Funktion zur Bewertung von Lieferanten stellt eine typische Auswertungsfunktion dar. Diese Funktionseinheit

erzeugt für verschiedene Lieferanten die Bewertung der

sigkeit, die relative Preisgünstigkeit je Materialtyp und ähnliche

Lieferzuverläs-

Kriterien.

Aufgrund des breit gefächerten Dateninputs erscheint es zweckmäßig, diese Funktion ohne Rückgriff auf Standardoperationen der Datenverwaltung zu konzipieren. Damit sind die Anforderungen an das Funktionsmodell für die Beschaffungsdisposition skizziert. Die Charakterisierung unterschiedlicher Arten von Funktionseinheiten bietet für die anschließende Modularisierung eine anschauliche Hilfestellung.

r

Abb. 25: Anforderungsskizze für den Funktionsbereich "Beschaffungsdisposition"

Funktionsmodellierung

- 97-

Aus der Anforderungsskizze leitet sich nahezu automatisch die nachfolgende HIPOStrukturübersicht ab. Darin werden Funktionseinheiten als Rechtecke und die den Funktionseinheiten gemeinsame Aufgabe als abgerundetes Rechteck dargestellt. Ohne die Diagrammaussage zu verändern, könnte auf die explizite Darstellung der Stukturierungszwecke als Knotenelemente verzichtet und der jeweilige Zweck bei jeder Funktionsbezeichnung einzeln angegeben werden.

Abb. 26: Strukturübersicht der Beschaffungsdisposition Für die vorgestellten Datenverwaltungsfunktionen wird zunächst gemäß der Spezifikation des abstrakten Funktionstyps "Datenverwaltung" unterstellt, daß alle Standardoperationen vorliegen. Die Vorgangsfunktionen werden nun in einer Übersicht so weit spezifiziert, daß die jeweilige Struktur und die virtuellen Funktionseinheiten deutlich werden. Die Ablaufsteuerung bleibt dabei unbeachtet.

Beschaffungsvorgänge Bestellung

Bestell-Überwachung

. lii'forkondüionen

_ ] Fallige Lieferungen auswerten

-I

auto

Neueingat» BesteHauftmg

—|

Mahnschreiben drucken

Andern

_|

BA-Stornierung drucken

Orucfcen BesteHauHrag

Lieferung

manuell

iiiHM;

Abb. 27: DV-technische Strukturüberischt der Beschaffungsvorgänge

_J

Neueingabe Wareftóingang Ändern Wareneingang

Andern Abhaken

Funktionsmodellierung

-98-

Alle hier als virtuell gekennzeichneten Funktionseinheiten werden als Bestandteil anderer Funktionseinheiten von den Vorgangsfunktionen verwendet (importiert). Bei der Spezifikation einer Vorgangsfunktion zeigt sich die Entscheidung darüber als besondere Schwierigkeit, o b eine Teilfunktion als vorgangsspezifisch aufzufassen ist oder bereits im Rahmen einer anderen Funktion zugänglich sein soll. Hier kann im Zweifel die letztere Alternative als allgemeingültige und daher stabilere Lösung angesehen werden, jedoch ist mit der Einführung jeder, noch nicht als virtuell gekennzeichneten Funktionseinheit ein Anstieg des Spezifikations- und Programmieraufwands verbunden. Mit den Mitteln des HIPO-Überblicksdiagramms stellen wir nun die Datenverwaltungsfunktion für den Materialtyp dar. Die Spezifikation der einzelnen Funktionseinheiten erfolgt nach dem folgenden Schema: • Bestimmung der Outputdaten, • Bestimmung der erforderlichen Inputdaten, • Spezifikation der Aktionen zur Steuerung der Funktionseinheit. Diese Schritte werden so lange im Zuge der Verfeinerung wiederholt, bis ein für die Programmierung hinreichend genaues Modell der Funktionseinheit vorliegt. Die Konzeption der Datenverwaltung basiert auf dem semantischen Datenmodell und stellt daraus die Benutzerdatensicht zusammen. Bei der Spezifikation gehen wir davon aus, daß alle Daten in Form von Tabellen vorliegen, zu deren Bearbeitung keine Öffnungs- oder Schließoperationen erforderlich sind. Der Materialtyp

ist als eine Spezialisierung des Teiletyps modelliert worden, daher sind bei

der Bearbeitung eines Materialtyps dessen Eigenschaften als Teiletyp, zeichnung,

relevant.

Bei

der

Neueintragung

eines

Materialtyps

wird

z.B. die Teilebesowohl

in

die

Materialtyp- als auch in die Teiletyptabelle ein Eintrag vorgenommen. Die Aktualisierung der Teiletyptabelle kann auch durch einen entsprechenden Auftrag an die dafür spezialisierte Funktioneinheit zur Datenverwaltung der Teiletypen (DVW Teiletyp) erreicht werden. Dies wird d a n n in der Liste der importierten Funktionen durch "DVW Teiletyp" vermerkt, die Outputseite des Überblicksdiagramms umfaßt somit ausschließlich die Materialtyptabelle. Liegt bereits ein Teiletyp mit dem angegebenen Primärschlüssel vor, und es handelt sich dabei u m einen Artikeltyp, wird dieser von der Funktionseinheit "DVW Teiletyp" nach dem Hinzufügen der "Materialeigenschaft" als Handelsware geführt. Analog sind beim Löschvorgang beide Tabellen betroffen. Dabei wird wiederum die Funktionseinheit "DVW Teiletyp" mit der Prüfung der Löschmöglichkeit und der Durchführung beauftragt. Liegt dabei eine Handelsware vor, wird lediglich von dieser Funktionseinheit das Teiletyp-Kennzeichen in "M" umgesetzt. Für Ausgaben auf den Bildschirm und den Drucker wird die Teiletypbezeichung, der Einstandspreis etc. aus der Teiletyptabelle gelesen, die Inputseite enthält damit zusätzlich diese Tabelle. Um den für einen restriktiv gestalteten Löschvorgang notwendigen Suchlauf zu dokumentieren, m ü s s e n alle mit dem Materialtyp verbundenen Beziehungstypen - dies kann man aus dem konzeptionellen Datenmodell herauslesen - für Lesezwecke in das Diagramm eingetra-

Funktionsmodellierung

- 99-

gen werden. Der Suchlauf dient dazu, herauszufinden, ob das zu löschende Tupel in weiteren Tabellen referiert wird. Auch bei einem kaskadiert durchgeführten Löschvorgang müssen zunächst diese Lese- bzw. Suchoperationen erfolgen. In unserem

Fall werden

Wareneingangspositionen ob ein Eintrag

die

Tabellen

sowie

der

Eingangsrechnungs-,

der Lieferkonditionen

mit den zu löschenden

Materialtyp

der

Bestellauftrags-

und des Materialverbrauchs

und

der

durchsucht,

vorliegt.

Diese Aufzählung deutet bereits die weitreichende Konsequenz einer kaskadierten Löschoperation an, dabei wurde noch nicht berücksichtigt, daß etwa beim kaskadierten Entfernen der einzigen Position eines Auftrags zusätzlich der Auftrag selbst gemäß den semantischen Integritätsbestimmungen zu löschen wäre. Zusätzlich wären wiederum alle von den genannten Einträgen abhängigen Fremdschlüssel (z.B. in der Tabelle Wareneingang)

zu

ermitteln und die betreffenden Tupel müßten ebenfalls eliminiert werden. Wir wenden daher im Hinblick auf die Begrenzung der Systemkomplexität ausschließlich die restriktive Form der Löschoperation an. Als wichtiges Element der Inputseite gelten die Eingabedaten

des

Benutzers, die als Tastatursymbol ohne zusätzliche Benennung repräsentiert werden. Die Bildschirm- und die Druckausgabe

Materialtyp

Teiletyp

auf der Outputseite dürfen nicht vergessen werden.

ERPos Neu Suchen Ändern Löschen Druck

Lieferkonditlonen

BA-Pos

WE-Pos

Materialtyp

Datenverwaltung Materialtyp DVW Te»etyp.[Neu, And, Lösch)

Materialverbrauch

Abb. 28: Überblicksdiagramm Datenverwaltung Materialtyp Anstelle der expliziten Eintragung der Material- und Teiletyp-Tabelle kann hier ebenfalls ein Materialtyp-View eingesetzt werden, der die beiden Tabellen zu einer logischen Einheit verbindet. Dieser View wäre in diesem Fall updatefähig, d.h. Einfüge, Lösch-, und Änderungsoperationen sind durchführbar, da der Primärschlüssel beider Tabellen mit dem des Views übereinstimmt. Das View-Konzept erlaubt - wie später im Rahmen der Fallstudie gezeigt wird - weitere Vereinfachungen. Alle in dieser Funktionseinheit (unterhalb der Nummer) angegeben Teilfunktionen werden von dieser exportiert, d.h. für andere Funktionseinheiten zur Verfügung gestellt. Nach Abschluß der Grobkonzeption liegt für jede Funktionseinheit des Anwendungssystems ein Überblicksdiagramm vor. Durch die Verwendung eines strukturierten, auf den Anwendungsbereich abgestimmten Analyseschemas wurde bereits auf der abstrakten Ebene des Fachkonzepts eine Strukturierung des Anwenderproblems erzielt. Dadurch konnten

wichtige

Aussagen

bezüglich

der Abhängigkeiten

zwischen

verschiedenen

- 100 -

Funkt ionsmodellierung

Funktionseinheiten getroffen werden und bei der Modulkonstruktion entsprechend Berücksichtigung finden. Auf der Ebene einzelner Funktionseinheiten ist ein weiterer Transformationsprozeß notwendig, der aus der HIPO-Beschreibung der Funktionseinheit die Steuerungslogik des Programmablaufs erzeugt. Die Verwendung der Prinzipien strukturierter Programmierung vereinheitlicht die Programmierstile, sodaß für gleichartige Probleme auch gleichartig strukturierte Kontrollflüsse spezifiziert werden. Im Verfeinerungsprozeß werden die Abhängigkeiten von Anweisungsblöcken innerhalb einer Funktionseinheit aufgedeckt und die Menge der Anweisungsblöcke ermittelt, die von mehreren Modulen gemeinsam nutzbar sind (Dienstmodule). Zwischen verschiedenen Modulen wird eine Abstimmung mit dem Ziel getroffen, Dienstmodule einmalig und kontextunabhängig zu entwickeln. Für die Modulkonstruktion können weitere formale Kriterien eingeführt werden, die diesen Abstimmungsprozeß unterstützen. Die einfachste formale Beschränkung richtet sich dabei auf die Begrenzung der Modulgröße, indem eine maximale Anzahl von Anweisungen (z.B. 100) festgelegt wird. Weitere Regeln können bezüglich der maximalen Parameteranzahl für Unterprogramme (etwa 7) eingeführt werden. Das nachfolgende Struktogramm beschreibt die Funktionseinheit "Datenverwaltung Material" unter Verwendung entsprechender dBASE-Sprachmittel.

Die Funktionseinheit zur Datenverwaltung für den Materialtyp muß bei Neueinträgen zunächst den Primärschlüsselwert vom Benutzer erfragen und überprüfen, ob der gewünschte Eintrag bereits vorliegt. In diesem Bearbeitungsmodus ("NEU") wird die doppelte Erfassung

Funktionsmodellierung

- 101 -

des gleichen Primärschlüsselwertes, in allen anderen Modi die Eingabe nicht vorhandener Primarschlüsselwerte zurückgewiesen. Erzeugt der Benutzer keinen Abbruch des Eingabevorgangs, wird der Datensatz im Neuanlagemodus unter Vorlage bestimmter Standardwerte (Default-Angaben) und im Änderungsmodus unter Vorlage der gespeicherten Werte eingelesen. Der Primärschlüsselwert darf dabei nicht mehr verändert werden. Bei allen anderen Bearbeitungen erfolgt eine Ausgabe des Datensatzes auf den Bildschirm. Die durch den Parameter Modus spezifizierte Operation führt bei der Neuanlage ein INSERT, bei der Änderung ein UPDATE und beim Löschen ein DELETE auf die Materialtyp- bzw. Teiletyptabelle durch. Zur Spezifikation der Druckausgabe, die aus Vereinfachungsgründen nicht in das Struktogramm aufgenommen wurde, sind genaue Anforderungen an die Gestaltung von Formularen und Listen zu sammeln.

3.4.4. Funktionsintegration Die Integrierte Informationsverarbeitung ist in jüngster Zeit zum zentralen Begriff der Wirtschaftsinformatik geworden. Gegenstand der Integration sind vornehmlich Daten, Funktionen und Geschäftsprozesse, die jeweils in organisationsunabhängigen Modellen beschrieben werden. Während die Datenintegration in konzeptioneller und technischer Hinsicht hervorragend durch Datenbankmanagementsysteme unterstützt wird, steht für die Realisierung der Funktionsintegration kein ebenso leistungsfähiges Instrument zur Verfügung. Der Entwurf von Informationssystemen wurde lange Zeit durch die Funktionsorientierung geprägt. Die funktionsorientierte Strategie betrachtet die Datenverarbeitungsaufgaben eines Unternehmens isoliert voneinander und dementsprechend werden einzelne Anwendungssysteme mit eigenständiger Datenhaltung konzipiert. Aufgrund der Kostenvorteile für standardisierte Anwendungssysteme fanden in einzelnen Teilbereichen, wie z.B. in der Finanzbuchhaltung, frühzeitig hoch spezialisierte Systeme Verbreitung, die keinen Datenanschluß zu anderen Anwendungssystemen besaßen. Die notwendige Abkehr von dieser Datenverarbeitungsstrategie wurde indirekt durch die Entwicklung von Konzepten zur Datenintegration vollzogen. Allerdings bleibt nach dieser Strategieänderung das Potential der Funktionsintegration weithin unbeachtet. Der Mangel an integrierten Funktionen äußert sich etwa darin, daß ein Sachbearbeiter neben einem Finanzbuchhaltungsprogramm ein Textverarbeitungs- und ein Datenbankmanagementsystem einsetzt, um die Geschäftsvorgänge eines betrieblichen Funktionsbereichs abzuwickeln. Auch innerhalb eines Anwendungssystems können sich Integrationsdefizite zeigen, wenn z.B. der Benutzer häufig über ein tief gegliedertes Menüsystem Spezialfunktionen auswählen muß, welche für die von ihm behandelte Aufgabe nur Teilergebnisse erzeugen. Gemäß dieser Überlegung wären solche Anwendungssysteme als ideal anzusehen, die dem Benutzer die Zusammenstellung von Funktionseinheiten für frei zu definierende Abläufe erlauben. Nicht nur zur Bearbeitung von Geschäftsvorgängen und der daran geknüpften Vorgangsketten scheint die Funktionsintegration wünschenswert. Die Zusammenführung und ganzheitliche Betreuung der Datenverarbeitungsaufgaben einer Unternehmensfunktion bildet

-

102-

Funktionsmodellierung

den wichtigsten Gegenstand der Integrationsbemühungen. Dabei kommt der strategischen Ebene einer Unternehmensfunktion mit den Aufgaben der Planung, Entscheidung, Steuerung und Kontrolle als Entwicklungsrahmen für den Funktionsentwurf große Bedeutung zu. Die Notwendigkeit zur vertikalen Integration, d.h. der Integration der operativen, taktischen und strategischen Funktionen, wird jedoch im allgemeinen als sehr gering eingeschätzt, da die Reaktionszeiten der einzelnen Ebenen deutlich variieren. Zudem werden in höheren Managementebenen hoch aggregierte Informationen benötigt, sodaß einzelne Aktivitäten der operativen Ebene für Aktionen der Führungsebene wenig Bedeutung besitzen. Umgekehrt bilden jedoch Planungen und Entscheidungen der Führungsebene konkrete Handlungsvorgaben für die unteren Managementebenen, daher könnte deren Umsetzung von einem Integrierten Informationssystem gesteuert und kontrolliert werden. Ein Mangel an funktionsintegrierten Systemen äußert sich hierbei z.B., wenn zeitaufwendige Koordinationsmaßnahmen erforderlich sind, um die Aktivitäten eines Funktionsbereichs zu steuern. Liegen für Datenverarbeitungsaufgaben eines Funktionsbereichs bereits spezialisierte Teilsysteme vor, wie etwa in der Finanzbuchhaltung, kann die Funktionsintegration nicht mehr konzeptionell, sondern ausschließlich mit technischen Mitteln realisiert werden. Die dann angestrebte Programmintegration muß die Funktionen und die

Interaktionen

(Austausch von Verarbeitungsdaten, Austausch von Steuerungsdaten) der Teilsysteme abstimmen. Im einfachsten Fall wird die Programmintegration durch Austausch von Steuerungs- und Verarbeitungsdaten und die anschließende Stapelbearbeitung erreicht, sodaß der Steuerfluß eines Programms nicht unterbrochen und an ein fremdes Programm weitergegeben werden muß. Die technische Form der Integration wird heute auch zunehmend von Front-End-Systemen (z.B. Window-Systemen mit Cut-and-Paste-Funktionen, Embedded Links etc.) unterstützt, daher verlieren die technischen Probleme zunehmend an Gewicht. Durch den Austausch von Verarbeitungsdaten treten die Probleme der redundanten Datenhaltung in den Vordergrund, wenn keine auf einem Datenbankkonzept beruhende, integrierte Datenhaltung realisiert werden kann. In unserem Anwendungsbeispiel steht wegen der spezifischen Integritätsforderungen der Finanzbuchhaltung die integrierte Datenhaltung als Gestaltungsalternative nicht zur Verfügung, daher wird mit den Mitteln der Programmintegration eine Schnittstelle zwischen dem Basis-Informationssystem und der Finanzbuchhaltung zu entwickeln sein.

-103-

DV-technische Instrumente

4. DV-technische Instrumente In diesem Abschnitt werden die Instrumente für die DV-technische Realisierung vorgestellt. Die Auswahl der Instrumente wurde maßgeblich von ihrer Verbreitung bestimmt, um das in diesem Projekt entwickelte System einem möglichst großen Leserkreis zugänglich zu machen.

4.1. Datenbankprogrammierung mit dBASE IV1> dBASE hat sich als Datenbankmanagementsystem (DBMS) für Mikrocomputer zum Standard entwickelt. Seit der Einführung von dBASE sind viele Verbesserungen und Erweiterungen vorgenommen worden, jedoch ist die konzeptionelle Grundlage von dBASE seither unverändert geblieben. Obwohl immer wieder von einem DBMS gesprochen wird, fehlt dBASE ein durchgehendes Datenbankkonzept, das die Datenunabhängigkeit gewährleistet. Der dBASE-Benutzer arbeitet mit dem physischen Layout der Daten und nicht ausschließlich mit der logischen Sicht, wie es von einem DBMS gefordert wird. Anwendungen, die mit Hilfe der dBASE-Programmiersprache entwickelt werden, sind von der physischen Datenstruktur abhängig. Dies hat zur Folge, daß Änderungen der Speicherungsform unmittelbar zu Programmänderungen führen. dBASE kann nicht als relationales DBMS angesehen werden, dazu fehlen etwa Sprachkonstrukte zur Deklaration von Primär- und Fremdschlüsseln. Die für das Relationenmodell elementaren Forderungen zur Sicherung der Entitätsund der Referenz-Integrität können in dBASE nicht mit den sprachlichen Mitteln der Datenbeschreibung, sondern ausschließlich durch prozedurale Anweisungen in Programmen erfüllt werden. Die Programmiersprache dBASE IV, deren Sprachumfang unter dem Kürzel xBASE auch frei von Urheberrechten zur Verfügung steht, zählt zu den Programmiersprachen der vierten Generation (4GL). Von der Verbreitung solcher, überwiegend als "nichtprozedural" klassifizierter Werkzeuge erhofft man sich eine Produktivitätssteigerung im Systementwicklungsprozeß und die Beseitigung der als "Anwendungsstau" bezeichneten Übernachfrage nach individuell erstellten Anwendungssystemen. Betrachtet man die Mächtigkeit verschiedener dBASE-Befehle, wie z.B. der CALCULATE-Funktionen, wird das Kriterium der Nichtprozeduralität so weit erfüllt, daß Grund zur Annahme besteht, auch Endbenutzer könnten ohne Systementwicklungskenntnisse selbständig Problemlösungen erarbeiten. Obgleich dieser Effekt in der Praxis für "kleinere" Anwendungsprobleme beobachtet werden kann, sollte daraus nicht geschlossen werden, daß die Analyse-, Abstraktions- und Spezifikationsleistungen eines Systementwicklers

durch 4GL

überflüssig

würden.

Die

bottom-up-

Vorgehensweise des "quick-and-dirty"- bzw. "ad-hoc"-Programmierens kann nur für solche Problemstellungen sinnvoll angewendet werden, die bereits zu Beginn vollständig struktu-

Die folgende Einführung in die dBASE-Programmierung stellt eine knappe, keineswegs vollständige Erläuterung grundlegender dBASE-Konzepte dar. Sie ist für Personen gedacht, die bereits über Programmierkenntnisse in einer prozeduralen Programmiersprache verfügen. Für die grundlegende Einführung in dBASE kann eine der zahlreichen Veröffentlichungen mit dem Thema "dBASE-Programmierung" verwendet werden.

- 104-

DV-technische Instrumente

riert vorliegen. Wie das hier beschriebene Projekt zeigt, kann man durch die Verwendung von 4GL ausschließlich in der Feinkonzeptions- und in der Programmierphase Produktivitätsgewinne erzielen, nicht jedoch bei der Analyse und Grobkonzeption.

4.1.1. Grundlegendes zur dBASE-Anwendung Nach dem Starten von dBASE wird der sogenannte Kommando-Modus

eingeschaltet.

Hinter dem Prompt, der Bereitschaftsanzeige, welche gewöhnlich als Punkt erscheint, kann jeweils ein Befehlswort mit Parametern angegeben werden. Der dBASE-Bildschirm zeigt eine starre Einteilung, die Statuszeile (STATUS) in der drittletzten Bildschirmzeile gibt den aktuell gewählten Arbeitsbereich und die zur Verfügung stehenden Tastenfunktionen an. Die letzte Bildschirmzeile ist für Benutzerhinweise (MESSAGES) reserviert. In der ersten Bildschirmzeile (SCOREBOARD) kann in dem Fall der Tastaturstatus eingesehen werden, wenn die Statuszeile abgeschaltet ist. Gewöhnlich wird die Uhrzeit (CLOCK) rechts oben eingeblendet. Der Prompt-Modus wird durch Eingabe des Befehls ASSIST verlassen und der menügesteuerte Modus des Regiezentrums eingeschaltet. Das Regiezentrum ermöglicht die menügeführte Erstellung von Dateien, Abfragen (guery by example), Berichten, Formatdateien und auch Programmen. Der Programmgenerator stellt keinen Ersatz für die (manuelle) Programmierung dar, er ermöglicht lediglich, eine Abfolge von Ein- und Ausgabeprogrammen, wie z.B. Forms und Queries, zu erstellen. Voreinstellungen des Systems, wie Bildschirmfarben, Druckerauswahl etc. können in der Datei CONFIG.DB eingetragen werden. Auch dBASE-Befehle und Programme zur sofortigen Ausführung werden dort mit "COMMAND=" spezifiziert. SET-Befehle steuern die Werte für eine große Menge globaler Variablen. Dazu zählen auch die Angaben des aktuell verwendeten Laufwerks (SET DEFAULT TO) und des Verzeichnisses (SET DIRECTORY TO) sowie die Angabe des Suchpfads für Programmdateien (SET PATH TO). Mit dem Befehl SET ohne Parameter wird eine menügeführte Auswahl von Status-Parametern zur Änderung angeboten. Im SET-Menü kann man die Funktionsweise und den Aufbau des dBASE-Menüsystems, das auch in der Programmierung Anwendung findet, kennenlernen. Die Taste F10 aktiviert die Menüzeile mit dem ersten Menüpunkt (Päd). Mit der Tastenkombination ALT-PadAnfangsbuchstabe läßt sich eine Option direkt, d.h. ohne zusätzliche Cursor-Tastendrücke anwählen. Einzelne Menüpunkte können mit Spaltenmenüs, sogenannten Popups, kombiniert sein, so daß man mit den Pfeiltasten direkt in vertikaler Richtung eine Auswahl treffen kann. Bestätigt wird eine Auswahl stets mit der Eingabe-Taste. In dBASE steht ein Hilfe-System zur Verfügung, das über F1 aktiviert wird. Über den Kontextbezug kann auch während einer Befehlseingabe entsprechende Hilfe-Information abgerufen werden. Die dBASE-Entwicklungsumgebung wird durch Eingabe des QUIT-Befehls beendet, alle offenen Dateien werden dabei automatisch geschlossen.

DV-technische Instrumente

-105-

4.1.2. Datenverwaltung: Anlegen einer dBASE-Datei Eine dBASE-Datei ist eine Binärdatei, bestehend aus Einzelsätzen, die jeweils eine eindeutige Satznummer tragen. Die Satznummer entspricht stets der (physischen) Reihenfolge eines Datensatzes innerhalb der Datei und jeder Datensatz kann daher nach einer physischen Reorganisation einen anderen Wert zugewiesen erhalten. Ein Satz besteht i.d.R. aus mehreren Feldern. Die Gesamtlänge eines Satzes ist auf 255 Felder und auf 4000 Byte begrenzt. Jedes Feld einer Datei muß einen eindeutigen Namen tragen. Der Feldname darf höchstens 10 Stellen umfassen, das erste Zeichen muß ein Buchstabe, alle weiteren Zeichen können auch Ziffern sein. Leerzeichen und Satzzeichen sind in Feldbezeichnem nicht zugelassen, aus der Menge der Sonderzeichen ist nur der "_"-Strich erlaubt. Für jedes Feld einer Datenbankdatei muß ein dBASE-Datentyp festgelegt werden. Insgesamt stehen folgende Datentypen für die Felddefinition zur Verfügung: Datentyp

Beschreibung

Länge

Zeichen

Jede Zeichenkette (String) mit beliebigen ASCII-Zeichen

1 bis 254

Numerisch

Numerischer Wert, für Berechnungen mit geringen Genauigkeitsanforderungen

1 bis 20

Gleit

Gleitkommazahl für Berechnungen hoher Genauigkeit

1 bis 20

Datum

Jedes zulässige Datum, das Standardformat ist TT.MM.[CC]JJ; CC gibt das Jahrhundert an, falls SET CENTURY = ON gesetzt ist. Boolsche Variable, zulässige Einträge sind: . T . , . t . , J , j , für true und F . , . f . , N, n , für false

8, Speicherungsform ist : CCJJMMTT

Texte bis zu 64 kByte, die separat in . DBT-Dateien gespeichert werden.

10

Logisch Memo

1

Tab. 2: Elementare Datentypen in dBASE IV Die Anlage der Datenbankdatei erfolgt mit dem Befehl CREATE . Die menügesteuerte Eingabe erlaubt die einfache Festlegung des Dateiaufbaus. Als Erweiterung für dBASE-Dateinamen ist .DBF vorgegeben. Änderungen der Dateistrukur können ohne Probleme auch bei Vorhandensein von Datensätzen vorgenommen werden. Der Befehl dazu lautet: MODIFY STRUCTURE. Bei der Angabe der Dateistruktur kann gleichzeitig zu jedem Feld ein Index festgelegt werden. Ein Index besteht aus einer sortierten Liste von Werteinträgen eines oder mehrerer Felder mit Verweisen auf die zugehörigen Datensätze. Indexe werden in einer Mehrfachindexdatei mit der Erweiterung . M D X .

abgelegt und als

B*-Baum dynamisch organisiert. Die bei der Dateianlage automatisch generierte Indexdatei (Arbeitsindex) trägt bis auf die Erweiterung den gleichen Dateinamen wie die Datendatei.

4.1.3. Datenverwaltung: Anlegen der Indexe Um den index-sequentiellen Zugriff, der gegenüber dem sequentiellen Zugriff deutlich weniger Sekundärspeicheroperationen erfordert, nutzen zu können, muß ein Index für einen Suchbegriff erzeugt und bei Änderungen des Datenbestandes stets aktualisiert

DV-technische Instrumente

- 106-

werden. Der Index wird entweder automatisch bei der Anlage der dDASE-Datei oder mit dem expliziten INDEX-Befehl erzeugt. INDEX ON TAG [OF ] [FOR [UNIQUE] [DESCENDING] Unter wird der Schlüsselausdruck angegeben, nach dem der Index sortiert aufgebaut werden soll. Der Schlüsselausdruck enthält häufig nur einen Feldnamen, er kann jedoch auch Funktionen und zusammengesetzte Ausdrücke aufweisen. Der Index kann ebenfalls interaktiv und menügeführt angelegt werden, indem man den Befehl INDEX ohne weiteren Parameter eingibt. Mit der notwendigen TAG-Klausel wird der Name des Index bestimmt, UNIQUE legt fest, daß nur jeweils der (in der Reihenfolge der Datendatei) erste Datensatz mit einem bestimmten Schlüsselwert in den Index aufgenommen wird. Duplikate von Schlüsseln, z.B. Primärschlüsseln, werden damit auf der logischen Ebene vermieden. Die Zuordnung von einem Schlüsselwert zu einem Datensatz ist dabei immer eindeutig, auch wenn mehrere bezüglich des Indexausdrucks gleiche Sätze in einer Datei existieren. FOR erlaubt die Einschränkung des Datenbereichs, der für die Indizierung zugrunde gelegt wird. Für die Aktualisierung von Indexen gilt, daß nur aktive, zugeschaltete Indexe während der Bearbeitung von Dateien (Löschen, Einfügen, Ändern) an den geänderten Datenbestand angepaßt werden. Der Befehl REINDEX ermöglicht die generelle Aktualisierung aller geöffneten Indexdateien. Für den Primärschlüssel einer Datei sollte stets ein Index angelegt werden. Je nach Sortieranforderung bzw. Zugriffshäufigkeit ist es notwendig, weitere Indexe anzulegen, z.B. für Kundenname, um dem Benutzer eine in der alphabetischen Reihenfolge der Namen geordnete Liste für eine Auswahl anzubieten. Beispiel: INDEX

ON Name TAG kname OF KUNDE

UNIQUE

4.1.4. Datenmanipulation Mit dem USE-Befehl wird die Datendatei mit den zugehörigen Indexdateien geöffnet, d.h. für die Datenmanipulation verfügbar gemacht. USE [IN ] [[ INDEX ORDER [TAG] [OF ]] [ALIAS ] [EXCLUSIVE] [AGAIN] [NOUPDATE] dBASE unterscheidet bis zu 40 Arbeitsbereiche, die jeweils eine DBF-Datei und bis zu 47 Indexe, die als TAG einer MDX-Datei angehören, aufnehmen können. Der IN-Zusatz ermöglicht die direkte Zuweisung einer Datei zu einem Arbeitsbereich. Mit ORDER wird der Hauptindex festgelegt, der auch aus einer weiteren MDX-Datei stammen kann. Der Schalter SET

ORDER

TO

[] ermöglicht für bereits geöffnete Dateien die

Wahl des Hauptindex. USE

[[IN] «Arbeitsbereich»] ohne Angabe eines Dateina-

mens schließt die Dateien des Arbeitsbereichs.

-107-

DV-technische Instrumente

Beispiel: USE künde IN I ORDER

kunr ALIAS

ku.

Nach Öffnen der Datei "Kunde" steht der Datensatzzeiger Indexreihenfolge

des Arbeitsindex

"kunr".

Der Arbeitsindex

auf dem ersten Datensatz gemäß der wird automatisch

bei USE

mitge-

öffnet

Mit dem Befehl SELECT wird jeweils nur ein Arbeitsbereich ausgewählt. Auf die Werte des aktuellen Datensatzes in einem nichtselektierten Arbeitsbereich kann mit Hilfe des Verweisoperators " - > " zugegriffen werden. Beispiel (Fortführung):

SELECT

2 (Enter-Taste)

DISPLAY

ku->Name.

Bei der Abfrage von Werten der Datei im aktuellen Arbeitsbereich ist der Verweisoperator nicht erforderlich. Die Struktur der geöffneten Datei läßt sich mit dem Befehl LIST STRUCTURE oder mit DISPLAY STRUCTURE zur Anzeige bringen.

•

Neuerfassung

von

Datensätzen

Nach Eingabe des APPEND-Befehls ohne Parameter wird ein Eingabemenü am Bildschirm angezeigt. Die Datensätze können frei editiert werden, nach dem letzten Feldeintrag wird mit STRG-END die Erfassung abgeschlossen. Das Drücken von ESC ermöglicht den Abbruch der Dateneingabe wie auch den Abbruch jedes anderen dBASE-Befehls. Bei Abbruch einer Dateneingabe wird jedoch nur der zuletzt bearbeitete Datensatz in die Ausgangswerte zurückgeführt. Eine erweiterte Abbruch- bzw. Rückführungsmöglichkeit wird im Rahmen der Transaktionskontrolle

(BEGIN

TRANSACTION,

END

TRANSACTION,

ROLLBACK) angeboten. Im APPEND-Modus steht zusätzlich eine Suchfunktion über eine Menü-Auswahl zur Verfügung. Die Anweisung APPEND BLANK erzeugt einen leeren Satz, d.h. einen Satz, der mit Leerzeichen ausgefüllt ist und in numerischen Feldern Nullwerte aufweist. Durch die Verknüpfung von APPEND

BLANK mit dem REPLACE-Befehl wird

gewöhnlich in Programmen die Einfüge-Operation durchgeführt. Der INSERT-Befehl bewirkt ebenso wie APPEND den Aufruf des interaktiven Eingabemenüs, jedoch wird die Erfassung auf einen Datensatz beschränkt.

•

Ändern

vorhandener

Datensätze

Für die Änderung bestehender Daten stehen mehrere Befehle zur Verfügung. Der APPEND-Modus erlaubt, über die PAGE-UP-Taste vorausgehende Datensätze anzuwählen und zu verändern oder über den Wechsel zur Tabellendarstellung (Taste F2) die Feldinhalte zu editieren. Die Befehle EDIT und CHANGE dienen ebenfalls zur Änderung von Datensätzen. Im Kommandomodus wird mit dem Befehl REPLACE [] WITH [ADDITIVE] [FOR ] [WHILE ] der Wert eines Feldes, falls keine Bereichsangabe vorliegt, oder mehrerer Felder durch den Wert des wira-Ausdrucks ersetzt. Folgende Einträge sind als Bereichsausdruck erlaubt:

DV-technische Instrumente

- 108-

Ausdruck

Bedeutung

RECORD

Der Bereich umfaßt ausschließlich den Datensatz mit Nummer n .

N E X T

Der Bereich umfaßt alle n auf den aktuellen Datensatz folgenden Datensätze. Die Reihenfolge bestimmt sich nach der physischen Datensatzfolge, bei zugeschaltetem Index nach der Sortierfolge des Index.

ALL

Alle Datensätze einer Datei werden spezifiziert.

REST

Der Bereich umfaßt alle Datensätze, die ab dem aktuellen Datensatz bis zum Ende der Datei existieren. Die Reihenfolge bestimmt sich nach der physischen Satzfolge, bei zugeschaltetem Index nach der Sortierfolge des Index.

Tab. 3: Optionen der Bereichsangabe Beispiel:

REPLACE

ALL

Umsatz

WITH

Umsatz* 1.14.

In allen folgenden Befehls-Angaben wird die Bereichsklausel mit , die FOR-Bedingung mit < F B > und die WHILE-Bedingung mit abgekürzt. Logische Bedingungen der FORbzw. WHILE-Klausel folgen dem Schema V e r g l e i c h s o p e r a t o r . Die Verknüpfung mehrerer Bedingungen kann mit den logischen Operatoren .AND. bzw. .OR. erfolgen. Folgende logische Operatoren können in dBASE verwendet werden: Stufe

Operator

Operantentyp

Ergebnistyp

Bedeutung

3

• NOT.

Logisch

Logisch

Negation

2

• AND.

Logisch

Logisch

Konjunktion

1

.OR.

Logisch

Logisch

Disjunktion

0

=

Logisch, Numerisch, Zeichen, Datum

Logisch

gleich

0

#

Logisch, Numerisch, Zeichen, Datum

Logisch

ungleich

Numerisch, Zeichen, Datum

Logisch

kleiner kleiner oder gleich

Numerisch, Zeichen, Datum

Logisch

größer größer oder gleich

Logisch

Teilstring

0

< < =

0

> > =

Zeichen 0 $ Tab. 4: Logische Operatoren

•

Löschen vorhandener

Datensätze

Datensätze werden in dBASE zunächst logisch gelöscht mit dem Befehl DELETE

[]

[]

[] .

Dabei wird eine Löschmarkierung ("*") an die ausgewählten Datensätze angehängt. Die Schaltereinstellung für SET DELETED ON/OFF legt fest, ob die so markierten Sätze bei Datenoperationen berücksichtigt werden. Der RECALL-Befehl erlaubt die Entfernung der Löschmarken, der DELETED-Schalter muß dazu OFF gesetzt sein. Das physische und damit endgültige Löschen von markierten Datensätzen erfolgt mit dem Befehl PACK. Eine

- 109 -

DV-technische Instrumente

S o n d e r f o r m d e s L ö s c h v o r g a n g s stellt d e r Z A P - B e f e h l z u r V e r f ü g u n g , d e r a l l e D a t e n s ä t z e p h y s i s c h in e i n e m Schritt a u s d e r D a t e i e n t f e r n t .

•

Suchoperationen

Nicht n u r b e i S u c h o p e r a t i o n e n sind f ü r a l p h a n u m e r i s c h e K o n s t a n t e n u n d D a t u m s a u s d r ü c k e B e g r e n z e r z e i c h e n n o t w e n d i g . D a t u m s a n g a b e n w e r d e n d u r c h g e s c h w e i f t e K l a m m e r n ({}), a l p h a n u m e r i s c h e A u s d r ü c k e d u r c h H o c h k o m m a t a (" o d e r ' ) e i n g e s c h l o s s e n . In v i e l e n B e f e h l e n k a n n e i n e B e r e i c h s k l a u s e l a n g e w e n d e t w e r d e n , z . B . b e i DELETE,

DISPLAY,

LIST, REPLACE. Die V a r i a n t e n z u r B e r e i c h s a n g a b e w u r d e n o b e n b e r e i t s v o r g e s t e l l t . J e d e r D a t e n s a t z e i n e r d B A S E - D a t e i trägt e i n e e i n d e u t i g e N u m m e r , d i e bei d e r p h y s i s c h e n R e o r g a n i s a t i o n d e r D a t e i (z.B. mit PACK) v e r ä n d e r t w e r d e n k a n n . Bei d e r D a t e n s u c h e k a n n m a n a u f S a t z n u m m e r n z u r ü c k g r e i f e n . D e r B e f e h l GO

p o s i t i o n i e r t d e n

S a t z z e i g e r a u f e i n e m frei w ä h l b a r e n D a t e n s a t z . Der D a t e n s a t z mit d e r N u m m e r 1 e n t s p r i c h t s t e t s d e m p h y s i s c h e n D a t e i a n f a n g . W e n n k e i n I n d e x aktiviert ist, k a n n e b e n f a l l s mit GO TOP a u f d e n D a t e n s a t z Nr. 1 positioniert w e r d e n , im a n d e r e n Fall wird d e r e r s t e D a t e n s a t z g e m ä ß d e r S o r t i e r r e i h e n f o l g e d e s H a u p t i n d e x a u s g e w ä h l t . E n t s p r e c h e n d wird a u f d e n l e t z t e n D a t e n s a t z m i t GO

BOTTOM positioniert. D e r S a t z z e i g e r ( C u r s o r ) k a n n m i t SKIP

[] [IN Arbeitsbereich] u m n D a t e n s ä t z e z u m D a t e i e n d e h i n ( n > 0 ) b z w . zum D a t e i a n f a n g h i n ( n < 0 ) b e w e g t w e r d e n . Die V o r g a b e f ü r n b e t r ä g t 1. D e n h ä u f i g s t e n Fall d e r D a t e n s u c h e stellt die S e l e k t i o n als i n h a l t l i c h e B e s c h r e i b u n g v o n D a t e n w e r t e n dar. S t r i n g v e r g l e i c h e

werden

aufgrund

der S c h a l t e r e i n s t e l l u n g v o n

SET

EXACT ON/OFF e n t w e d e r v o l l s t ä n d i g (ON) o d e r nur b i s z u r L ä n g e d e s r e c h t s v o m O p e r a t o r s t e h e n d e n A u s d r u c k s (OFF) d u r c h g e f ü h r t . D e r $ - O p e r a t o r e r m ö g l i c h t die S u c h e

eines

T e i l s t r i n g s in e i n e m S t r i n g . B e i d e r Ä h n l i c h k e i t s s u c h e f i n d e t h ä u f i g die L I K E - F u n k t i o n z u s a m m e n mit d e n J o k e r z e i c h e n "*" u n d "?" A n w e n d u n g , z . B . : DISPLAY

FOR

( " M ? i e * " , k u n d n a m e ) . Die p h o n e t i s c h e S u c h e w i r d d u r c h d i e s o o N D E X ( ) - F u n k t i o n

LIKE unter-

stützt. Die E f f i z i e n z e i n e r S u c h o p e r a t i o n e n h ä n g t v o n d e r A r t d e s v e r w e n d e t e n Z u g r i f f s v e r f a h r e n s ab. In d B A S E s t e h t n e b e n d e r s e q u e n t i e l l e n a u c h d i e i n d e x - s e q u e n t i e l l e Z u g r i f f s f o r m z u r Verfügung. Der Befehl LOCATE

[]

[]

[]

d i e n t zur s e q u e n t i e l l e n S u c h e e i n e s D a t e n s a t z e s , d e r e i n e a n g e g e b e n e B e d i n g u n g erfüllt. Die S u c h e b e g i n n t s t e t s a m D a t e i a n f a n g , w e n n n i c h t die B e r e i c h s k l a u s e l m i t REST b z w . NEXT

< n > oder d i e WHILE-Klausel spezifiziert w e r d e n . Die P r ü f u n g d e s

Sucherfolgs

ü b e r n e h m e n die F u n k t i o n e n EOF() b z w . F O U N D ( ) , d i e mit d e r v o r a n g e s t e l l t e n A u s g a b e a n w e i s u n g " ? " d i r e k t a u s g e w e r t e t w e r d e n k ö n n e n . D i e e r f o l g r e i c h e S u c h e k a n n mit dem

Befehl

CONTINUE

bis

zum

FOUND () =. F . ) f o r t g e s e t z t w e r d e n .

Erreichen

des

Dateiendes

(EOF() = .T.

bzw.

-

DV-technische Instrumente

110-

Gegenüber dem ineffizienten aber sehr flexiblen Suchverfahren mit LOCATE erlaubt die indexierte Suche via SEEK < A u s d r u c k > einen sehr schnellen Datenzugriff. Zuvor muß jedoch über die Indexierung des Datenbestandes die Wertemenge für alle Suchoperationen beschrieben werden. Der Suchausdruck besitzt stets den gleichen Datentyp wie der Indexausdruck und stimmt exakt (in den Kategorien der Schaltereinstellung SET

EXACT) mit

einem Element des Wertebereichs überein. Die Ähnlichkeitssuche mit Ersetzungszeichen ist demnach mit dem SEEK-Befehl nicht möglich. Der Schalter SET NEAR ON

ermöglicht

im Fall der erfolglosen Suche die Positionierung des Satzzeigers auf dem gemäß der Indexreihenfolge nachfolgenden Datensatz anstelle der sonst üblichen Positionierung am Dateiende. Komplexe Selektionsvorgänge über logisch verbundene Dateien stellen höhere Anforderungen an die Planung der Arbeitsbereiche. Zunächst werden mit SELECT die Arbeitsbereiche ausgewählt und mit USE die erforderlichen Dateien geöffnet. Liegt für die von der Vergleichoperation beachteten Felder kein Index vor, bietet sich die Verbindung der beiden Dateien mit dem JOIN-Befehl und die anschließende sequentielle Suche in der durch JOIN neu erstellten Datei an. Die Syntax des JOiN-Befehls lautet: JOIN WITH TO

[FIELDS

]

Die notwendige FOR-Bedingung schränkt die Kombination der Datensätze beider Dateien auf diejenigen Paare von Sätzen ein, deren Werte bei Auswertung der Vergleichsbedingung den Wert .T. ergeben. Besitzt die FOR-Bedingung für die Satzkombination keine einschränkende Wirkung (z.B. FOR

.T.), kombiniert dBASE jeden Datensatz der ersten mit jedem

Datensatz der zweiten Datei. Über die FIELDS-Klausel wird die erstellte Datei auf die Menge der gewünschten Felder projiziert. Nach dem Öffnen der neuerstellten Datei kann mit dem LOCATE-Befehl die Selektion erfolgen. Mit dem Befehl SET RELATION TO

[ into ] wird eine Verbin-

dung zwischen zwei und mehr Dateien über identisch benannte Felder geknüpft, die es ermöglicht, diese Dateien als logische Einheit zu betrachten. Bei einer Änderung der Datensatzposition in der übergeordneten Datei wird in den verbundenen Dateien ebenfalls der Cursor auf einem Datensatz positioniert, der dem Ausdruckswert entspricht. Die Ausgangsdatei muß über den Ausdruck indexiert sein. Ist die mit dem Aliasnamen angegebene Datei nicht indexiert, muß der Ausdruck als Ergebnis die Satznummer der verbundenen Datei liefern. Eine Abfrage mit der SEEK-Anweisung erlaubt nun mit Hilfe des Verweisoperators ("->") die Datenwerte der verbundenen Datei in die Selektion einzubeziehen. Eine weitere, sehr einfache Variante der Abfrage in logisch verbundenen Dateien stellt der SET FIELDS-Befehl zur Verfügung. Setzt man als Ausdruck für ein neu definiertes Kalkulationsfeld die Funktion SEEK (, ) ein, z.B. SET FIELDS

TO

f1,f2,kfeld=SEEK(kundnr,"Angebot"), kann man logisch verknüpfte Felder einer anderen Datei in eine Abfrage einbeziehen.

DV-technische Instrumente

-111 -

Schließlich kann die SEEK-Funktion auch in der FOR-Bedingung eines Befehls angewendet werden, wodurch ebenfalls die Datenwerte anderer Dateien für eine Abfrage verfügbar gemacht werden.

•

Auswertungen von Datenbeständen

Für statistische Auswertungen, insbesondere zur Summen- und

Mittelwertberechnung

sowie zur Zählung von Dateneinträgen stehen die folgenden Befehle zur Verfügung: SUM [] [TO / TO A R R A Y ] [] [] [] AVERAGE [] [TO / TO ARRAY ] [] [] [] COüNT [TO ] [] [] [] Der Befehl TOTAL ON TO [] []

[]

[FIELDS

erzeugt eine neue Datei mit den Gruppensummen für den mit festgelegten Ordnungsbegriff. Die Summierung der (numerischen) Datenwerte kann für mehrere in spezifizierte Felder erfolgen, dabei muß für den Schlüsselausdruck ein Index verfügbar sein. Mit dem Befehl CALCÜLATE [] [] [] [TO / TO ARRAY ] können mehrere Berechnungen für einen einheitlich ausgewählten Bereich in nur einem Durchlauf durch die Datei ausgeführt werden. Im -Ausdruck des OALCULATEBefehls werden eine oder mehrere der folgenden Funktionen eingesetzt. CALCULATE-Funktionen

Bedeutung

AVG («Numerischer Ausdruck;-)

Mittelwert

SUM(«Numerischer Ausdruck>)

Summe

MIN()

Minimum

MAX()

Maximum

STD(Name). Die Vorgabe für die implizite Variablenvereinbarung ist PRIVATE, d.h. die Variable besitzt nur innerhalb des vereinbarenden Programms und in allen von diesem aufgerufenen Unterprogrammen Gültigkeit. Eine als PUBLIC vereinbarte Variable ist demgegenüber ab dem Zeitpunkt der Vereinbarung in allen Programmteilen definiert. Mit der expliziten PRIVATE-Deklaration werden die in übergeordneten Programmen gegebenenfalls identisch benannten Variablen lokal ersetzt, so daß die Werte der übergeordneten Variablen lokal unzugänglich werden und für das aufrufende Programm erhalten bleiben. Der häufig auftretende Laufzeitfehler "Variable nicht gefunden" resultiert aus einer schlampig geführten Variablendeklaration, der man durch die Anwendung der expliziten Zuweisungsform begegnen kann. Die Typvereinbarung für eine Variable kann in dBASE nur implizit durch die Zuweisung einer Konstanten oder einer anderen Variablen erfolgen. Durch die Zuweisung einer Feldvariablen an eine Speichervariable kann jeder zulässige Feld-Datentyp außer dem MEMO-Typ, der dabei zu einem Zeichentyp umgesetzt wird, durch die Konstantenzuweisung kann nur ein numerischer Datentyp (z.B. 1=1), ein Zeichentyp (z.B. T="

•) oder ein

Logischer Datentyp (z.B. L=.T.) vereinbart werden. Die Wertzuweisung von einer Speichervariablen an eine Feldvariable muß über den REPLACE-Befehl erfolgen. Stufe 2

Operator * * oder ~

1

*

0

+

/ -

Operandentyp Gleit,Numerisch

Ergebnistyp Gleit,Numerisch

Bedeutung

Gleit,Numerisch Gleit,Numerisch

Gleit,Numerisch Gleit,Numerisch

Multiplikation Division

Gleit,Numerisch Gleit,Numerisch

Gleit,Numerisch Gleit,Numerisch

Addition Subtraktion

Potenzierung

Tab. 6: Arithmetische Operatoren Verwendet man bei der Variablenzuweisung arithmetische Operatoren zusammen mit Operanden unterschiedlichen Typs, dann wird damit eine Variable vom Typ Gleit definiert. Funktion ABS() ATAN() CEILINGQ COS() EXP() INT() LOG() LOG1CK) MOD() SIN() SQRT() FLOORO ROUNDQ

Argumenttyp Gleit,Numerisch Gleit,Numerisch Gleit,Numerisch Gleit,Numerisch Gleit,Numerisch Gleit,Numerisch Gleit,Numerisch Gleit,Numerisch Gleit,Numerisch Gleit,Numerisch Gleit,Numerisch Gleit,Numerisch Gleit,Numerisch

Ergebnistyp Gleit,Numerisch Gleit,Numerisch Gleit,Numerisch Gleit,Numerisch Gleit,Numerisch Gleit,Numerisch Gleit,Numerisch Gleit,Numerisch Gleit,Numerisch Gleit,Numerisch Gleit,Numerisch Gleit,Numerisch Gleit,Numerisch

Bedeutung Betrag Arcustangens Nächste ganze Zahl Cosinus Exponentialfunktion Ganze Zahl Natürlicher Logarithmus Logarithmus Basis 10 Modulus Sinus Qaudratwurzel Nächstkleinere Ganzzahl kfm. gerundete Zahl

Tab. 7: Arithmetische Standardfunktionen Die Datumsarithmetik wird von dBASE durch eine große Zahl von Funktionen (z.B. CTOD (), DTOC (), DOW ( ) ) umfassend unterstützt. Datumsangaben können dabei für die Zwecke der arithmetischen Operationen wie numerische Datentypen behandelt werden,

DV-technische Instrumente

-115-

z.B. Frist= D A T E O + 1 0 0 . Für die Stringverarbeitung stehen ebenfalls zahlreiche Funktionen zur Verfügung (z.B. LEFT (), UPPER ()). Der Standardoperator für die Stringverkettung ist das "+"-2eichen. Als dBASE-Besonderheit gilt die Möglichkeit, Variable mit aktuellen Werten auf dem externen Speicher auszulagern und zurückzuladen. Die Befehle SAVE TO [ALL LIKE/EXEPT ] und RESTORE FROM

[ADDITIVE]

werden jedoch selten (z.B. zur Speicherung des aktuellen Systemzustands, vgl. SET) und vor allem bei Hauptspeicherengpässen benötigt.

•

Strukturierte

Datentypen

Die aus den höheren Programmiersprachen bekannten Datenstrukturen finden sich nur teilweise in dBASE wieder. Der Array bezeichnet in allen gängigen Programmiersprachen eine ein- oder mehrdimensionale Liste gleichartiger Datenelemente. In dBASE wird unter ARRAY eine ein- oder zweidimensionale Liste aus Datenelementen beliebigen Typs verstanden. Auch ein typischer PASCAL-Record (bestehend aus einfachen Datentypen) kann als Array in dBASE deklariert werden. Beispiel: DECLARE xarray [Dimension der Zeile, Dimension der Spalte]. Einzelnen Elementen des Arrays können beliebig typisierte Konstanten oder Variablen des einfachen Datentyps (außer Memo-Datentyp) zugewiesen werden. Die Wertzuweisung der Feldvariablen einer Datei an einen ARRAY erfolgt mit COPY TO ARRAY FIELDS

[]

[

[[CASE < B e d i n g u n g > ] [[OTHERWISE] ] ENDCASE Zur Programmierung der Wiederholungsstruktur steht ausschließlich der kopfgesteuerte Schleifentyp zur Verfügung: DO WHILE < B e d i n g u n g >

ENDDO Die EXiT-Anweisung führt eine bedingungslose Programmverzweigung zu der dem Schleifenende folgenden Anweisung durch, die Ausführung der LOOP-Anweisung fährt mit der Programmsteuerung beim Schleifenkopf fort. Zur Bearbeitung einer Menge von Datensätzen in einer Wiederholung steht eine spezielle Kontrollstruktur zur Verfügung: SCAN [ < F B > ] []

ENDSCAN Bei der SCAN-Schleife kann ebenfalls EXIT und LOOP angewendet werden. Neben den Konstrukten der Strukturierten Programmierung werden in dBASE auch Kontrollstrukturen zur ereignisgesteuerten Programmierung angeboten. Zulässige Ereignisse, die zur Steuerung eines Programms definiert werden können, sind Ausführungsfehler des Programms (ON ERROR) und Tastendrücke des Benutzers (ON ESCAPE bzw. ON KEY).

DV-technische Instrumente

- 117 -

Mit Hilfe der Ereignissteuerung wird für jeden Anweisungsblock, innerhalb dessen eine bestimmte Ereignisdefinition gilt, ein zusätzlicher Blockausgang vereinbart. Damit werden (undokumentierte) Änderungen des Steuerflusses vor bzw. nach jeder Anweisung ermöglicht und insofern entspricht die Ereignissteuerung nicht den Prinzipien der Strukturierten Programmierung. Soll dennoch ein ON-Befehl eingesetzt werden, kann als Programmierdisziplin die Regel Beachtung finden, daß die vom ON-Befehl aufgerufene Prozedur selbst keinen weiteren Prozeduraufruf durchführen darf.

•

Prozeduren und Funktionen

Unterprogramme werden über das PROCEDURE-Statement deklariert: PROCEDURE [PARAMETERS ,,..]

RETURN Alle an das Unterprogramm übergebenen Parameter sind in der Parameterliste als erste Anweisung des Unterprogramms aufzuführen. Der Aufruf eines Unterprogramms erfolgt mit: DO

[WITH

,,..]

Der Parameter-Ausdruck im Aufruf einer Prozedur bzw. Funktion, wobei die Parameter in Klammern nach dem Funktionsbezeichner angegeben werden, entscheidet über die Verwertbarkeit dieses Parameters im Unterprogramm. Die Übergabe eines Wertes (call by value) wird durch die Angabe einer Konstanten (z.B. DO xprg WITH 12) oder eines auswertbaren Ausdrucks (z.B. DO xprg WITH 1*1.0) realisiert. Entsprechend liegt eine Referenz-Übergabe (call by reference) mit der Möglichkeit zur Rückgabe eines eventuell geänderten Wertes vor, wenn ausschließlich der Variablenbezeichner (z.B. DO xprg WITH I) angegeben wird. Funktionen (in dBase als User defined Functions bezeichnet) werden folgendermaßen deklariert: FUNCTION

[PARAMETERS

,,..]

RETURN

Die Konventionen für die Übergabe der Parameter stimmen mit der Parameterbehandlung bei Prozeduren überein.

•

Programmierung

der Ein- und Ausgabe

Für die unformatierte Ausgabe, die vor allem bei interaktiven Arbeiten und bei der Druckersteuerung eingesetzt wird, stehen die "?"-Befehle zur Verfügung. Zur formatierten Eingabe dient der GET-Befehl, zur formatierten Ausgabe der SAY-Befehl.

-

DV-technische Instrumente

118-

@ , SAY [PICTURE ] [FUNCTION ] [[GET ] [PICTURE ] [FUNCTION ] [RANGE ,] [VALID ] [ERROR ] [REQUIRED] [WHEN ] [DEFAULT ] [MESSAGE ]] [COLOR [],[] In der SAY-Version dieses Befehls wird der Wert des gemäß der PICTURE-bzw. FUNCTION-Schablone formatiert und an der durch und angegebenen Position auf dem Ausgabegerät (Bildschirm, Drucker) in der durch COLOR spezifizierten Farbgebung angezeigt. Nur bei Leseoperationen mit GET sind die Prüfklauseln VALID, WHEN, ERROR und RANGE verfügbar. Die VALID-Bedingung wird nach erfolgter Eingabe ausgewertet. Werte mit dem Prüfergebnis .F. werden nach Anzeige der mit der ERRORKlausel spezifizierten Meldung zurückgewiesen (Nachbedingung). Die WHEN-Bedingung steuert die Eingabemöglichkeit (Vorbedingung). Wenn die Auswertung der Bedingung vor dem Werteintrag .T. ergibt, kann die Eingabe erfolgen, im anderen Fall wird das Eingabefeld übergangen, RÄNGE prüft nur bei einer Änderung des Variablenwertes die Überschreitung der angegebenen Bereichsgrenzen. Die am häufigsten eingesetzten Schablonenzeichen der PICTURE-Klausel zur Festlegung des Feldinhalts und der Darstellungsform sind "9" für numerische Zeichen und "x" für alphanumerische Zeichen. Wird dem Schablonenzeichen ein "©"-Zeichen vorangestellt, gilt das Zeichenformat für die gesamte Länge (wie bei der Funktionenliste), im anderen Fall nur für jeweils eine Stelle des Eingabefelds. Alle im Programmtext angegebenen GET-Anweisungen werden erst durch den READ-Befehl aktiviert. Beispiel:

•

@ 10,10 GET kundnr PICTURE "999999" RANGE 1, ; MESSAGE "Bitte Kundennummer angeben" COLOR W+/B

Menüprogrammierung

Für die Menüprogrammierung bietet d B A S E leistungsfähige Befehle an. Die verfügbaren Menütypen werden in Zeilenmenüs (MENU) und Spaltenmenüs (POPUP) unterschieden. Die Anbindung der Menüauswahl an die Programmsteuerung erfolgt über Aktionen, die von d B A S E nach einer abgeschlossenen Menü-Auswahl erzeugt werden. Mit dem Befehl DEFINE MENU [MESSAGE ] wird ein Zeilenmenü definiert. Die einzelnen Optionen des Zeilenmenüs werden mit folgendem Befehl festgelegt: DEFINE PÄD OF PROMPT [AT ,] [MESSAGE Nr

@ CLEAR [TO ] Angegebenen Bildschirmauschnitt löschen. @ FILL TO [COLOR ] Farbattribute eines Bildschirmbereichs setzen. @ TO SCROLL [UP/DOWN/LEFT/RIGHT] [BY ] [WRAP] Den Inhalt des Bildschirms nach oben, unten, links oder rechts um angegebene Stellen verschieben. @ TO [DOUBLE/PANEL|] [COLOR ] Rahmen mit angegebenen Koordinaten und Attributen ausgeben. = Wertzuweisung. Siehe STÖRE. ACCEPT [] TO

Einen Text als Eingabeaufforderung anzeigen und die Tastatureingabe in eine Speichervariable vom Datentyp Zeichen zuweisen. Siehe: INPUT. ACCEPT

"Name!

" TO

Kumme

ACTIVATE MENU I POPUP I WINDOW Angegebene(s) Objekt(e) aktivieren. APPEND [BLANK] Datensätze an die aktive Datei anfügen. Mit APPEND BLANK einen Leersatz am Ende der Datei einfügen. APPEND FROM I? [REINDEX] [] [[TYPE] ] [SDF] Datensätze aus einer Datei an die aktive Datei anfügen. Mit dem Zusatz SDF wird eine Textdatei (ASCII) eingelesen. Siehe COPY TO. APPEND FROM ARRAY [] Datensätze aus einem Array an die aktive Datei anhängen. APPEND MEMO FROM [OVERWRITE] Eine Textdatei in ein benanntes Memofeld importieren. ASSIST Regiezentrum als Menüoberfläche einschalten. AVERAGE [] [] [TO I TO ARRAY ] Den Durchschnitt aller genannten Felder ermitteln. Siehe SUM und STORE. BEGIN TRANSACTION [] < B e f e h l s f o l g e > END TRANSACTION Eine Befehlsfolge als Transaktion kennzeichnen. Dateiänderungen werden in der Datei Translog.Log aufgezeichnet. Dateien können während einer Transaktion nicht geschlossen werden.(siehe ROLLBACK). BLANK [FIELDS | LIKE | EXCEPT ] [] [] [] [REINDEX] Felder und Datensätze mit Leerstellen füllen. BROWSE [NOINIT] [NOFOLLOW] [NOAPPEND] [NOMENU] [NOEDIT] [NODELETE] [NOCLEAR] [NOORGANIZE][COMPRESS] [FORMAT] [WIDTH ] [WINDOW ] [LOCK ] [FREEZE ] [FIELDS [/R] [ I ] | = ] BROWSE-Modus aktivieren, um die aktive Datei zum Lesen, Andern, Löschen bzw. Anfügen durchzublättern. Siehe: EDIT.

DV-technische Instrumente

-121 -

CALCULATE [] [] [TO ] [TO ARRAY ] Auswertungen über die Zusatzfunktionen AVG, MAX, MIN, NPV, STD, SUM und VAR durchführen. CALCULATE

SUM(Menge)

TO Bestand

CALL [WITH I] Eine mit LOAD bereits geladene Binärdatei ausführen. CANCEL Ausführung eines Programms beenden, zur dBASE-Befehlsebene zurückkehren. CHANGE [] [FIELDS ] [] Datenfeld(er) editieren. Identisch mit EDIT CLEAR Bildschirm löschen und Cursor links oben positionieren. CLEAR ALL System in den Anfangszustand versetzen: Alle Dateien schließen, Speichervariablen löschen, Arbeitsbereich 1 aktivieren. Siehe CLOSE, USE. CLEAR FIELDS Die mit SET FIELDS TO [ ] erstellte Feldliste zurücksetzen. CLEAR GETS Alle GET-Anweisungen aufheben, die seit dem letzten Einsatz eines der Befehle CLEAR ALL, CLEAR GETS bzw. READ gegeben wurden. Die mit GET angezeigten Felder können danach nicht mehr editiert werden. CLEAR MEMORY Alle Speichervariablen und Arrays löschen. (PRIVATE und PUBLIC). CLEAR MENUS/POPUPS Menüs oder Popups vom Bildschirm und aus dem Speicher löschen. CLEAR TYPEAHEAD Den Tastatur-Eingabepuffer leeren. CLEAR WINDOWS Definierte Fenster aus dem Speicher und vom Bildschirm löschen. CLOSE ALL I ALTERNATE I DATABASES | FORMAT|INDEX I PROCEDURE Alle offenen Dateien des genannten Dateityps schließen. Siehe USE. COMMAND = Eintrag in CONFIG . DB, um Befehle sofort nach dem Start von dBASE auszuführen.

COMPILE [RUNTIME] Erzeugt aus dem Quellcode einen vom dBASESystem ausführbaren Objektcode ( . DBO). CONFIG.DB Konfigurationsdatei von dBASE, Eintragungsbefehle sind u.a.: BUCKET= , COMMAND= , DO= , EEMS=, EXPSIZE=, FASTCRT=, FILES=, GETS=, INDEXBYTES=, PDRIVER=, PRINTER Name=, PROMPT=, RESETCRT=, SQL=, SQL-DATABASE=, SQLHOME=, TEDIT=, WP= CONTINUE Fortführung der letzten LOCATE-Suche. COPY FILE TO

Dateien beliebigen Typs kopieren. COPY TO [] [FIELDS ] [] [TYPE ] Inhalt der aktuellen Quellendatei in eine Zieldatei bestimmten Typs exportieren. COPY INDEXES [TO ] Eine Liste von NDX-Dateien als TAG in eine MDX-Datei kopieren. COPY MEMO TO [ADDITIVE] Inhalt aus einem Memofeld in eine Textdatei kopieren. COPY STRUCTURE TO [FIELDS ] Nur die Dateistruktur kopieren, nicht aber den Dateiinhalt. COPY TO STRUCTURE EXTENDED Erzeugt eine 4-Felder-Datei mit Feldname, Feldtyp, Feldlänge und Anzahl der Dezimalstellen. Mit CREATE FROM kann später daraus eine neue Datei erstellt werden. COPY TAG [OF ] TO Einen TAG-Eintrag aus einer MDX-Datei in eine NDX-Datei kopieren. COPY TO ARRAY [FIELDS ] [] [] Datensätze der aktiven Datei in einen Array kopieren. COUNT [] [] [TO ] Anzahl der Sätze der aktuellen Datei zählen. CREATE Die Struktur einer neuen DBF-Datei definieren. CREATE FROM | ? Eine neue Datei aus einer mit COPY STRUCTURE EXTENDED erzeugten Datei erstellen.

-

122-

CREATE APPLICATION | ? Über den dBASE-Programmgenerator ein Obiekt erzeugen. CREATE LABEL | ? Über zwei Editiermasken zur aktuellen Datei eine Label- bzw. Etikettendatei mit dem Dateityp LBL erzeugen. CREATE QUERY | ? Filterdatei (QBE) für eine Datenbank (DBF) oder View-Datei (VUE) erstellen. CREATE REPORT | ? Über den Reportgenerator einen Bericht als Reportformdatei definieren und als FRM-Datei abspeichern. CREATE SCREEN | ? Eine Maskendatei als SCR-Datei bzw. FMTDatei erstellen. CREATE VIEW FR0M ENVIRONMENT Erzeugt eine VUE-Datei, in der die aktuelle Arbeitsumgebung (geöffnete Dateien, Verknüpfungen, Felderlisten, Formate, Indexe und Auswahlbedingungen) gespeichert wird. Mit SET VIEW wird diese Arbeitsumgebung aktiviert. DEACTIVATE MENU | POPUP | WINDOW Das aktive Menü, Popup oder Fenster deaktivieren. Die Definition selbst wird nicht aus dem Speicher gelöscht. DEBUG | [WITH ] Den Programm-Debugger zwecks Fehlersuche aktivieren. DECLARE [,] Ein- oder zweidimensionalen Array vereinbaren. DEFINE BAR OF PROMPT [MESSAGE ] [SKIP []] Eine Menüzeile für ein POPUP-Menü definieren. DEFINE POPUP dispo FROM S,4 TO 10,24 DEFINE BAR I OF dispo PROMPT "Teiletyp"

DEFINE BOX FROM TO HEIGHT [AT LINE ] [SINGLE|DOUBLE|] Ein Rechteck mit Linien oder beliebigen ASCIIZeichen als Rahmen ausgeben. DEFINE MENU [MESSAGE ] Anfangsbefehl zum Definieren eines Menüs.

DV-technische Instrumente

DEFINE PAD OF PROMPT [AT ,] [MESSAGE ] Eine Option zu einem Zeilenmenü definieren. DEFINE MENU kundmenu DEFINE PAD neu OF kundmenu "Neueingabe" AT 3,5

PROMPT

DEFINE POPUP FROM [TO ] [PROMPT Field | PROMPT FILES | PROMPT STRUCTURE] [MESSAGE ] Ein Popup-Menü als Fenster mit Optionen oder Auswahlfeldern einer Datei definieren. DEFINE WINDOW FROM , TO , [DOUBLE | PANEL I NONE I ][COLOR [] [.Intensiv][,Rahmen]] Definition eines Fensters mit Namen,Koordinaten, Farben und Umrahmung. DELETE [][][] Sätze aus dem angegebenen Bereich mit Löschmarkierung versehen. Siehe PACK, RECALL , ZAP. DELETE FILE Datei beliebigen Typs vom Sekundärspeicher löschen. Vollständiger Dateiname erforderlich. DELETE TAG [OF ] Einen Schlüsseleintrag aus einer Mehrfachindex-Datei entfernen. DEXPORT SCREEN I REPORT|LABEL [TO ] BNL-Datei (Binary Named List) erzeugen. Dateitypen SNL (Maske), FNL (Bericht) und LNL (Etikett) DIR [[ON] ] [LIKE ] [] Inhaltsverzeichnis einer Pfads gemäß der genannten Maske anzeigen. DISPLAY [] [] [OFF] [] [] [TO PRINTER | TO FILE ] Sätze der aktuellen Datei am Bildschirm, auf dem Drucker anzeigen oder in eine Datei ausgeben. Siehe LIST. DISPLAY FIELDS Umsatz,Name; FOR Umsatz>30000

DISPLAY FILES [LIKE ] [TO PRINTER | TO FILE ] Inhaltsverzeichnis des Zugriffspfads anzeigen.

- 123-

DV-technische Instrumente

DISPLAY HISTORY [LAST ] [TO PRINTER I TO FILE] Befehle, die im HisTORY-Modus gespeichert wurden, anzeigen. DISPLAY MEMORY [TO PRINTER I TO FILE ] Namen, Typ, Größe und Status aller Speicherund Systemvariablen im Speicher anzeigen. DISPLAY STATUS [TO PRINTER | TO FILE ] Status bzw. Zustand des Systems anzeigen: Dateinamen, Arbeitsbereiche, Alias-Namen, Datenbankverbindungen, offene Index- und MEMO-Dateien, Arbeitsindex, Name der SETEinstellungen und Belegung von Funktionstasten. DISPLAY STRUCTURE [IN ] [TO PRINTER | TO FILE ] Die Struktur einer geöffneten Datei mit Dateiname, Satzanzahl, Aktualisierung, Datenfelder (Name, Datentyp, Länge) und Datensatzlänge anzeigen. DISPLAY USERS Datenstations-Identifizierung aus der Datei Login.DB lesen. DO WITH ] Ein Programm zur Ausführung bringen und dabei ggf. Parameter übergeben. DO CASE [OTHERWISE] ENDCASE Befehl zur Kontrolle der mehrseitigen Auswah. DO WHILE < . . > ENDDO Befehl zur Kontrolle der Wiederholung. EDIT [Satznummer] [] [FIELDS ] [] [] EDIT-Modus einschalten (Zusätze wie bei BROWSE). EJECT Seitenvorschub an Drucker senden (PROW () und PCOL () auf 0). EJECT PAGE Einen Seitenvorschub erzeugen gemäß der Seitenverwaltung des Druckers. ERASE | ? Datei von Diskette löschen. Mit ? werden die Dateinamen angezeigt. EXIT Schleife verlassen. Ausführung hinter ENDDO bzw. ENDSCAN fortsetzen.

EXPORT TO [TYPE] [FIELD ] [] [] [] Eine DBF-Datei in ein eine Datei mit beliebigem Datenformat exportieren. FIND Im Hauptindex nach dem angegebenen Suchausdruck suchen und den Satzzeiger positionieren. Siehe SEEK, LOCATE. FIND mkundnr (identisch mit SEEK mkundnr) FUNCTION [PARAMETERS] RETURN Eine benutzerdefinierte Funktion festlegen. GO/GOTO [RECORD] I BOTTOM | TOP [IN ] Datensatzzeiger positionieren. HELP [] dBASE-Hilfe aufrufen. IF [ELSE] ENDIF Befehl zur Kontrolle der ein- oder zweiseitigen Auswahl. IMPORT FROM [TYPE] Beliebige Dateien anderer Anwendungsprogramme importieren (vgl. EXPORT). INDEX ON TO I TAG [OF ] [UNIQUE] [DESCENDING] Für die aktive Datenbank einen Index erzeugen. Mit UNIQUE nur den ersten von gleichen Schlüsseln übernehmen. INDEX ON name+vorname TAG kuna INPUT [] TO Text anzeigen und Tastatureingabe einer Variablen vom Typ Z (Eingabe in "" tippen), N oder L zuweisen. Siehe ACCEPT. INSERT [BLANK] [BEFORE] Einen Satz hinter oder vor die aktuelle Satznummer einfügen. JOIN WITH TO [] [FIELDS ] Die aktuelle Datei mit der im Alias-Datei verbinden und in einer neuen Datei speichern. JOIN WITH künde TO k_arpos; FOR knr = kunde->knr KEYBOARD [CLEAR] Ein Ausdruck wird als eine Abfolge von Tastatureingaben verarbeitet. LABEL FORM | ? [] [] [SAMPLE] [TO PRINTER | TO FILE ] Etiketten- bzw. Labeldatei öffnen und die aktive Datei in Form von Etiketten ausdrucken (PRINT) bzw. als Textdatei speichern (FILE).

DV-technische Instrumente

-124-

LIST [OFF] [] [] [] [TO PRINTER I TO FILE ] Inhalt d e r aktiven Datei zeigen. Voreinstellung ALL, sonst wie DISPLAY. LIST HISTORY | MEMORY STRUCTURE S i e h e DISPLAY

| STATUS |

LOAD Eine Binärdatei (Maschinenprogramm) laden und d a n n mit CALL aufrufen. LOCATE [] [] [] Datei beginend mit d e m aktuellen Datensatz durchsuchen, bis die Suchbedingung erfüllt oder das Dateiende erreicht ist, und den Satzzeiger bei F O U N D Q auf .T. positionieren. Siehe CONTINUE, DISPLAY FOR. LOCATE FOR (rdatum >= {31.12.91} LOGOUT D e n aktiven Benutzer im Multiuser-Betrieb abmelden. LOOP In einer Schleife unbedingt z u m Schleifenkopf verzweigen. MODIFY COMMAND [WINDOW ] Eine Programmdatei erstellen bzw. editieren. Siehe TE= bei CONFIG.DB. MODIFY APPLICATION | LABEL I QUERY I REPORT I SCREEN | VIEW Siehe CREATE APPLICATION I LABEL I QUERY I REPORT MODIFY STRUCTURE Struktur der aktuellen Datei ändern, wobei eine D B K - D a t e i als Sicherungskopie gespeichert wird. MOVE WINDOW TO I BY

Ein Fenster a m Bildschirm verschieben. NOTE | * [] Zeilenkommentar in einer Programmdatei angeben.vgl && ON ERROR | ESCAPE I KEY I READERROR Ereignisse für die unbedingte Ausführung festlegen, W e n n die Bedingung ERROR (Fehler), ESCAPE (Esc-Taste gedrückt) bzw. KEY (beliebige Taste gedrückt) ,T. ergibt. ON PAD OF [ACTIVATE POPUP ] Die Auswahl einer Zeilenmenü-Option mit der Aktivierung eines P O P U P s verknüpfen. ON PAGE [AT LINE ] Druckseitenverwaltung ein- bzw. ausschalten.

ON SELECTION PAD OF [] Eine Menüauswahl mit einem bestimmten Befehl verbinden. ON SELECTION PAD neu OF dispo DO prg__ I ON SELECTION POPUP I ALL [] Befehl ausführen, falls eine Option des PopupM e n ü s ausgewählt wird. PACK Logisch gelöschte S ä t z e der aktiven Datei physisch vom Sekundärspeicher löschen und Indexe neu aufbauen. Siehe DELETE, RECALL, ZAP. PARAMETERS Parameter als Variablenwerte aus einem aufrufenden Programm übernehmen (erste Befehlszeile im Programm). Siehe DO, PUBLIC. PLAY MACRO Ein Makro aus einer Makro-Bibliothek ausführen. PRINTJOB ENDPRINTJOB Druckauftrag über Systemvariablen kontrollieren. PRIVATE | ALL [LIKE I EXCEPT ] Anlegen von lokalen Speichervariablen. PROCEDURE

RETURN Programm definieren. PROTECT Das Sicherungssystem (Systemdatei DB System. DB) aktivieren. PUBLIC | [ARRAY ] Variablen global gültig erklären. S i e h e PRIVATE QUIT Alle Dateien schließen und d B A S E verlassen. READ [SAVE] Alle noch nicht aktivierten bzw. mit CLEAR gelöschten GET-Anweisungen aktivieren. RECALL [] [] [] Die mit DELETE gesetzten Löschmarkierungen aufheben. REINDEX Alle aktiven Indexdateien (NDX w i e MDX) neu indizieren. Nicht z u verwechseln mit Befehlswort bei APPEND FROM, BLANK, EDIT, REPLACE, UPDATE. RELEASE | ALL [LIKE/EXCEPT ] Variablenvereinbarung aufheben, Speicher freigeben.

-125-

DV-technische Instrumente

RELEASE MODULE []I MENUS [] IPOPUPS [] I SCREENS [] IWINDOWS [] Binärdateien, Menüs bzw. Fenster aus dem Hauptspeicher entfernen. RENAME TO Eine beliebige, vollständig durch den Namen gekennzeichnete Datei umbenennen. REPLACE [REINDEX] [] WITH [ADDITIVE] [] [] Datenfeldinhalte eines Teilbereichs der aktuellen Datei aktualisieren. REPLACE FOR

preis

artnr>47l

WITH

preis*

1.04;

I

REPLACE FROM ARRAY [FIELDS ] [] [] [] Den Inhalt bestimmter Felder in einer Datei durch Werte aus einem Array ersetzen. REPORT FORM |? [PLAIN][HEADING ] [NOEJECT] [][][][TO PRINTER I TO FILE ] [SUMMARY] Zur aktiven und auszuwertenden Datei die benannte Reportform-Datei erzeugen und ohne Seitenzahlen (PLAIN) bzw. mit zusätzlicher Überschrift (HEADING) ausgeben. RESET [IN ] Markierung für die Überprüfung der Vollständigkeit einer Datei aufheben, nicht innerhalb einer Transaktion auszuführen. RESTORE FROM [ADDITIVE] Daten aus einer MEM-Datei in den Hauptspeicher laden und ggf. (ADDITIVE) zum aktuellen Speicherbereich hinzufügen. RESTORE MACROS FROM Makros aus einer Makrodatei in den Hauptspeicher laden. RESTORE WINDOW | ALL FROM Eine Fensterdefinition aus einer zuvor abgespeicherten Window-Datei in den Arbeitsspeicher laden. RESUME Ein zuvor mit SUSPEND unterbrochenes Programm weiter ausführen. RETRY Befehl, der zu einer Fehlermeldung geführt hat, erneut ausführen.

RETURN [ | TO MASTER I TO ] Programmausführung beenden und die Kontrolle zurückgeben. ROLLBACK [] Datei in Zustand vor BEGIN TRANSACTION bringen. RUN I ! Ausführung eines DOS-Befehls. SAVE TO [ALL LIKE I EXCEPT ] Variablen aus dem aktiven Speicherbereich in einer MEM-Datei ablegen. Gegenstück zum Befehl RESTORE FROM. SAVE

TO globals

ALL

LIKE

s*

SAVE MACROS TO Makrodefinitionen in einer Makro-Datei speichern. SAVE WINDOW | ALL TO Fensterdefinitionen als Window-Datei auf dem Sekundärspeicher ablegen. SCAN [] [] [] [LOOP] [EXIT] ENDSCAN Schleife zur einfachen, satzweisen Dateiverarbeitung. SCAN

FOR kumsatz=

"K"$Name kumsatz

+

Umsatz

ENDSCAN

SEEK In der Arbeitsindexdatei nach dem angegebenen Ausdruck suchen und den Satzzeiger positionieren (FOUND () oder gegebenenfalls EOF () setzen). Wie FIND, jedoch abweichende Schreibweise. SELECT I Einen von 40 möglichen Arbeitsbereichen öffnen (1 ist voreingestellt). SET Einstellung der SET-Schalter anzeigen bzw. ändern. Die SET-Schalter können durch folgende Befehle direkt eingestellt (Defaults angegeben): ALTERNATE OFF, ALTERNATE TO, AUTOSAVE OFF, BELL ON, BELL TO, BLOCKSIZE TO, BORDER TO, CARRY OFF, CARRY TO, CATALOG OFF, CATALOG TO, CENTURY OFF, CLOCK OFF, COLOR OFF, COLOR TO, CONFIRM OFF, CONSOLE ON, CURRENCY TO, CURRENCY LEFT/RIGHT, CURSOR ON, DATE TO, DBTRAB ON, DEBUG OFF, DECIMALS TO 2, DEFAULT TO, DELETED OFF, DELIMITERS OFF, DESIGN ON, DEVELOPMENT ON, DEVICE TO SCREEN,

-

126-

DIRECTORY TO, DISPLAY TO, ECHO OFF, ENCRYPTION ON, ESCAPE ON, EXACT OFF, EXCLUSIVE OFF, FIELDS TO, FIELDS OFF, FILTER TO, FORMAT TO, FULLPATH OFF, FUNCTION TO, HEADINGS ON, HELP ON, HISTORY ON, HISTORY TO, HOURS TO 24, INDEX TO, INSTRUCT ON, INTENSITIY ON, LOCK ON, MARGIN TO 0, MARK TO , MEMOWITDH TO 50, MENU ON, MESSAGE TO, NEAR OFF, ODOMETER TO 1, ORDER TO, PATH TO, PAUSE OFF, POINT TO, PRECISION TO, PRINTER OFF, PRINTER TO, PROCEDURE TO, REFRESH TO 0, RELATION TO, REPROCESS TO, SAFETY ON, SCOREBOARD ON, SEPARATOR TO, SKIP TO, SPACE ON, SQL OFF, STATUS OFF, STEP OFF, TALK ON, TITLE ON, TRAP OFF, TYPEAHEAD TO 20, UNIQUE OFF, VIEW TO, WINDOW OF, MEMO TO. SET ALTERNATE ON I OFF I TO Ergebnisse in eine Protokolldatei (Textdatei) schreiben, die zuvor mit SET ALTERNATE TO geöffnet wurde. SET ALTERNATE TO protokol SET ALTERNATE ON CLOSE ALTERNATE SET BELL ON I OFF I TO [,] Ton bei fehlerhaften Eingaben ein/ausschalten. SET CARRY OFF I ON I TO [ADDITIVE] Bei APPEND Teile des vorherigen Satzinhaltes automatisch in den nächsten Satz kopieren. SET CATALOG OFF I ON | TO Einen Katalog erstellen, ändern, schließen. SET CONFIRM OFF I ON Eingabe eines Datenfeldes muß mit ReturnTaste bestätigt werden (ON). SET CONSOLE ON I OFF Bildschirmanzeige unterdrücken (OFF). SET DEBUG OFF I ON Debugger aktivieren. Druckausgabe bei eingeschaltetem ECHO und STEP für Fehlersuche. SET DECIMALS TO Anzahl der anzuzeigenden Nachkommastellen festlegen (voreingestellt: 2). SET DEFAULT TO Standardlaufwerk festlegen. SET DEFAULT TO D:

DV-technische Instrumente

SET DELETED OFF I ON Mit "*" als gelöscht markierte Sätze werden z.B. von DISPLAY, LIST und COPY ignoriert, von INDEX, NEXT und RECORD nicht. SET DEVELOPMENT ON I OFF Prüft, ob eine kompilierte DBO-Datei bei Ausführung älteren Datums ist als die zugehörige PRG-Datei und veranlaßt ggf. die NeuKompilierung. SET DELIMITERS OFF ION I TO Bei Masken die Datenfeldbegrenzung durch ein Zeichen darstellen, das zuvor mit SET DELIMITERS TO definiert wurde (":" ist voreingestellt). SET DEVICE TO PRINTER | SCREEN | FILE Formatierte Ausgaben (SAY,GET) auf den Drucker leiten. SET ECHO OFF | ON Gerade ausgeführten Befehl anzeigen, z.B. zwecks Fehlersuche. SET ESCAPE ON I OFF Jeder Befehl kann durch Drücken der Esc-Taste abgebrochen werden, wenn ESC ON gesetzt ist. SET EXACT OFF | ON Zu vergleichende Zeichenketten müssen nicht exakt übereinstimmen. SET FIELDS OFF | ON Die mit SET FIELDS TO gewählte Felderliste verwenden bzw. ignorieren. SET FILTER TO [FILE | ?] [] Nur die Sätze, welche die Bedingung erfüllen, werden verarbeitet. Der Filter gilt solange (Vorsicht!), bis er durch SET FILTER TO abgeschaltet wird. SET FILTER TOknr>47ll SET FORMAT TO [ | ?] Eine selbsterstellte Format-Datei bzw. MaskenDatei öffnen. SET FUNCTION TO Funktionstasten 2-10 belegen (";" ersetzt (Return-Tastendruck). SET FUNCTION 5 TO "CLEAR ALL:" SET HEADING ON | OFF Überschriftszeilen z.B. bei LIST oder DISPLAY ggf. unterdrücken. SET HELP ON | OF Die bisweilen lästige Frage "Wünschen Sie Hilfe?" nach Fehlereingabe an- bzw. abschalten.

DV-technische Instrumente

SET HISTORY ON I OFF I TO HISTORY-Einrichtung aktivieren /deaktivieren (zuvor mit SET HISTORY TO Größe festlegen). SET MARGIN TO Druckposition für linken Rand. Auszugeben den Ausdruck mit der Druckposition beginnen. SET MEMOWIDTH TO Länge des MEMO-Ausgabefeldes (Standard 50) ändern. SET ORDER TO [] Den Hauptindexdatei festlegen bzw. Indexverwendung generell abschalten. SET PATH TO [] Zugriffspfad festlegen, in dem gesucht wird. SET PATH

TO

C:\DBASE\COLOWIN

SET PRINT ON I OFF Alle nicht mittels SAY , GET formatierten Ausgaben ausdrucken. SET PROCEDURE TO [] Prozedurdatei öffnen. SET RELATION TO [ INTO ] Aktive Datei mit der ALIAS-Datei über einen identischen Schlüsselausdruck verbinden, SET RELATION TO hebt die Verbindung wieder auf. SET SAFETY ON I OFF Warnung bei drohendem Überschreiben einer Datei ggf. unterdrücken. SET SCOREBOARD ON I OFF In der Statuszeile erscheinende dBASEMeldungen ggf. unterdrücken. SET STATUS ON | OFF Inhalt der Statuszeile ggf. nicht anzeigen. SET TALK ON | OFF Systemmeldungen ggf. nicht am Bildschirm anzeigen. SET TYPEAHEAD TO Eingabepuffer zwischen 0 und 32000 festlegen (Vorgabe: 20 Zeichen). SET UNIQUE OFF I ON Bei doppelten Schlüsselwerten wird ggf. jeweils nur der erste Eintrag in einer Indexdatei berücksichtigt. SHOW MENU [PAD ] Menü zu Testzwecken anzeigen, ohne es zu aktivieren. SHOW POPUP Ein Popup-Menu zum Test anzeigen, ohne es zu aktivieren.

-127-

SKIP [] [IN ] Datensatzzeiger um 1 (Vorgabe) bzw. die angegebene Anzahl von Sätzen verschieben. SORT TO ON [/A] t/c] [/D], [ [/A] [/C] l/D], ...] [] [] Die aktive Datei sortiert in der Zieldatei speichern. SORT

FOR

ON rame/A,umsatz/D

rdatum>{01.01.92}

TO

dummy;

STORE TO

Einer oder mehreren Variablen einen neuen Wert zuweisen. SUM [] [][TO I TO ARRAY ] [] [] Gruppensummen erzeugen und ggf. den Variablen zuweisen. Siehe COUNT. SUSPEND Programmausführung zur Fehlersuche unterbrechen, mit RESUME weiter ausführen. TEXT ENDTEXT Anfang und Ende eines Textblocks in einem Programm markieren. TOTAL ON TO [FIELDS][][] [] Numerische Felder der aktiven Datei (nach Schlüsselfeld indexiert bzw. sortiert) in einer Summendatei zusammenfassen. TYPE [TO PRINTER/TO FILE ] [NUMBER] Inhalt einer Textdatei ggf. mit Zeilennummern anzeigen bzw. ausdrucken. UNLOCK [ALL | IN ] Sperren einer Datei oder einer Menge von Datensätzen aufheben. UPDATE ON FROM REPLACE WITH [,Feld2 WITH Ausdruck2 ,...] [RANDOM] [RE INDEX] Ausgewählte Felder der aktuellen Datei durch Felder einer Bewegungsdatei aktualisieren. Der Schlüssel muß in beiden Dateien übereinstimmen. UPDATE

ON knr FROM

repos;

REPLACE

Umsatz WITH

Umsatz+;

repos->menge*repos->preisa

-

DV-technische Instrumente

128-

USE [ < D a t e i > | ? ] [IN < A r b e i t s b e r e i c h > ] INDEX < N D X / M D X - D a t e i l i s t e > [ORDER /TAG-Name][OF < M D X - D a t e i > ] [ALIAS ][EXCLUSIVE][NOUPDATEJ Eine Datei ggf. mit Indexen öffnen. USE künde ORDER knr ALIAS ku

WAIT [ < E i n g a b e a u f f o r d e r u n g > ] [TO ] Programmausführung bis Tastendruck unterbrechen. ZAP Alle Sätze der aktiven Datei physisch, auch ohne vorherige Löschmarkierung entfernen. Siehe DELETE, PACK.

Verzeichnis der dBASE-Funktionen ABS() Absolutbetrag des Ausdrucks. ACCESS() Zugriffs-Rechte eines Benutzers im Netzwerk. ACOS() Arcus Cosinus eines Winkels in Grad. ALIAS() Alias-Name für die Arbeitsbereichsnummer ermitteln. ASC() Liefert den ASCII-Code des ersten Zeichens. ASIN() Arcus Sinus im Bogenmaß. AT(, | ) Anfangsposition des ersten Ausdrucks im zweiten Ausdruck. AT("ee","Peer

Teer") ergibt 2.

ATAN ( < A u s d r u c k > ) Arcus Tangens im Bogenmaß. BAR () Nummer der zuletzt gewählten Popup-Zeile. BOF([Alias]) Prüfen, ob der Satzzeiger am Dateianfang (Beginning Of File) steht. GO TOP;

> BOF()

&& ergibt. T.

CALL(,, []) Binärdatei ausführen. CATALOG() Liefert den Namen des aktiven Katalogs. CDOW() Wochentag (Day Of Week) eines Datums. > CDOW({22.10.92})

&& ergibt

Donnerstag

CEILING() Kleinste ganze Zahl größer oder gleich dem Ausdruck. CERROR() Nummer der letzten Fehlermeldung des Compilers. CHANGE() .T., falls mindestens ein Satz der Datei seit dem Öffnen geändert wurde. CHR() ASCII-Wert des zugehörigen Zeichens. > CHR(65)

&& ergibt

A

CMONTH() Monatsname für ein Datum. COLO Aktuelle Spaltenposition des Cursors. COMPLETED() Stellt fest, ob ein gültiges ROLLBACK oder END TRANSACTION durchgeführt wurde. COS() Cosinusfunktion CTOD() Zeichenausdruck in einen Datum-Typ umwandeln (Character To Date). STORE CTOD("22.12.92") enspricht

sdatum =

TO

sdatum

{22.12.92}

DATE() Funktion zur Ermittlung des Systemdatums. sdatum = DATEQ

&8t Datum

speichern

DAY() Numerischer Wert des Tages aus einem Datumsausdruck. > DAY(DATEQ)

&& ergibt z.B. 30

DBF([]) Zeichenfolge mit dem Namen der aktiven Datei. DELETED([]) Abfragen, ob der aktive Satz eine Löschmarkierung "*" aufweist. > DELETEDQ

&& ergibt z.B. .T.

DIFFERENCE() SOUNDEX () -Unterschied zweier Strings. DISKSPACE() Freier Speicherplatz in Bytes auf aktuellem Laufwerk. DMY() Datum im Format Day/Month/Year. DOW() Reihenfolge des Wochentags (Day Of Week). Sonntag = 1.

-129-

DV-technische Instrumente

DTOC() Einen Datumsausdruck in einen ZeichenAusdruck umwandeln (Date to Character). > "Rechnung:"; DTOC(DATE()) ergibt z.B. Rechnung: 31.01.93

DTOR() Grad in Bogenmaß (Radian) umwandeln. DTOS () Datum in einen String umwandeln. EOF([]) .T., wenn der Satzzeiger auf das Dateiende (End of File) zeigt, d.h. den letzten Satz überschritten hat. Für EOF()=.T. gilt: RECNO () = RECCOUNT () +1. Siehe BOF () , FOUND() und ERROR() . GOBOTTOM > EOFQ SKIP

&& ergibt .F.

> EOFQ

&& ergibt. T.

ERROR() Interne Nummer des Fehlers, der von einer ON ERROR-Bedingung registriert wurde. ON ERROR DO err_j>rg WITH

ERRORQ

EXP() Exponentialwert eines Zahlenausdrucks. FCLOSE() Eine mit FOPEN () oder FCREATE () geöffnete LLD schließen und . T . bzw. . F . (bei einem Fehler) zurückgeben. FCREATE(,[] Neue LLD einrichten und Handle zurückgeben (0 bei Fehler). Berechtigung: "R", "W", "A", "RW", "AR" HandleNr

= FCREATE("BSTAPEL. TXT', "AR ")

FDATE() Datum der letzten Änderung einer beliebigen Datei. FEOF() .T., wenn Ende der LLD erreicht. FERROR() MS-DOS-Fehlernummer des letzten Zugriffs auf LLD. 0, wenn fehlerfrei. FFLUSH() Pufferinhalt in LLD schreiben. FAT aktualisieren und .T. bzw. .F. (bei Fehler) zurückgeben. FGETS( [ , < B y t e a n z a h l > ] [ , ] Aus LLD eine mit dem EOL-Zeichen abgeschlossene Zeichenkette einlesen. KunDat = Zeile =

FOPEN("Kunden.txt","R")

FGETS(KunDat)

FIELD() Name des Feldes mit der angegebenen Reihenfolgen-Nummer. FILE() Prüfen, ob eine Datei auf externen Speicher existiert > FILE('kunenl.DBF')

&& ergibt z.B. .F.

FIXED() Datentyp F (Gleitkommazahl) in Datentyp Numerisch umwandeln. FKLABEL() Ermittelt die Zeichen, mit denen die Funktionstaste belegt ist. FKMAX () Anzahl der programmierbaren Tasten. FLDCOUNT([]) Liefert die Anzahl der Felder in der Datei. FLOAT() Datentyp Numerisch in Datentyp F (Gleitkommazahl) umwandeln. Siehe FIXED. FLOCK([]) Bei Mehrbenutzerbetrieb testen, ob die Datei gesperrt ist. FLOOR() Größte ganze Zahl kleiner oder gleich Ausdruck. FOPEN( [ , < B e r e c h t i g u n g > ] ) Eine LLD öffnen und Handle zurückgeben. Siehe FCREATE() FOR([[,] [,] Liefert die FB, die bei der Definition eines Index angegeben wurde bzw. einen Leerstring. FOUND([]) .T., wenn der vorangehende FIND-, SEEK-, LOCATE-, CONTINUE-Befehl erfolgreich war. Ein FOUND () je Arbeitsbereich. FPUTS(, < A u s d r u c k > [,] [,]) Einen String ab der aktuellen Position in eine LLD einfügen und die Anzahl der geschriebenen Bytes zurückgeben. FREAD(, ) Angegebene Anzahl von Bytes aus einer LLD lesen und zurückgeben. Name = FREAD

(KunDat,30)

FSEEK(, < A n z a h l > [,] Datei-Zeiger in LLD um Anzahl ab der Startposition verschieben. FSIZE() Liefert die Größe der LLD.

DV-technische Instrumente

- 130-

FTIME() Liefert die Uhrzeit der letzten Änderung der LLD. FV(,,) Zukünftiger Wert (future value), Endwert einer regelmäßigen Zahlung. FWRITE(, < A u s d r u c k > [,]) Angegebene Anzahl Zeichen aus dem Ausdruck in eine LLD übertragen und Anzahl der geschriebenen Zeichen zurückgeben (0 bei Fehler). Siehe FREAD. GETENV() Inhalt einer Umgebungsvariablen (Environment) als String. HOME () Liefert das Ursprungsverzeichnis von dBASE.EXE . ID() Namen des Benutzers bei Mehrbenutzer-Betrieb oder Leerstring. IIF(, , ) Bedingte Zuweisung ohne Notwendigkeit für eine Verzweigung. Ergebnis = IIF(Zahl>0

'positiv', 'negativ')

INKEY([]) ASCIl-Codezahl der zuletzt bzw. in einem Zeitraum gedrückten Taste. Wurde keine Taste gedrückt, wird 0 angegeben. INT() Ganzzahliger Teil einer Zahl. INT(7.999)

&& ergibt 7

KEY([,] [ , < A l i a s > ] ) Hauptindex der MDX-Datei. LASTKEY() ASCII-Wert der zuletzt gedrückten Taste (wie INKEY () ). LEFT(,) Links stehende Anzahl von Zeichen eines Strings. > LEFT('Peer Teer',2)

&& ergibt 'Pe'

L E N ( < A u s d r u c k > | ) Länge (Length) einer Zeichenfolge. > LEN("Kowalski")

&& ergibt 8

LIKE(,) Ähnlichkeit mit den Jokern ? und * testen, ergibt T. bzw. F.. LINENO() Zeilennummer des aktiven Programms zwecks Debugging zurückgeben. LKSYS() Zeit (n=0), Datum (n=1) oder Benutzername (n=2) einer Datensicherung zurückgeben. LOG() Natürlicher Logarithmus einer Zahl. LOGIO() Logarithmus zur Basis 10. LOOKUP(, , ) Felder (z.B. Name) nach einem Eintrag durchsuchen und den Inhalt eines Feldes (z.B. Umsatz) zurückgeben. >. LOOKUP(ku->oposten,47l

l,ku->knr)

ISALPHA() T., wenn der Ausdruck mit einem AlphabetZeichen beginnt.

LOWER() Buchstaben einer Zeichenfolge in Kleinbuchstaben umwandeln.

ISBLANK() .T., wenn Ausdruck leer ist, d.h. den Ausdruck enthält, der bei APPEND BLANK zugewiesen wird.

LTRIM() String ohne führende Leerzeichen. LUPDATE{[]) Datum der letzten Aktualisierung der aktiven Datei.

ISCOLOR() .T., wenn das System in einem Farbmodus arbeitet. ISLOWER() T., wenn der Ausdruck mit einem Kleinbuchstaben beginnt. ISMARKED([]) Prüfen, ob der Merker im Header der Datei (zur Änderung von Daten) gesetzt ist. ISUPPER() .T. liefern, wenn der Ausdruck mit einem Großbuchstaben beginnt.

MAX(,) Maximum von zwei Zahlenwerten. MDX() [,] Name der MDX-Datei gemäß der Index-DateiReihenfolge im durch Alias angegeben (aktuellen) Arbeitsbereich. MDY() Eingabedatum in Format Month-Day-Year umwandeln.

DV-technische Instrumente MEMLINES() Anzahl der Zeilen eines Memofeldes gemäß SET MEMOWIDTH. MEMORY() Freier Arbeitsspeicher in KByte. MENUO Name des mit DEFINE MENU definierten, gerade aktiven Menüs. MESSAGE() Wortlaut der zuletzt aufgetretenen Fehlermeldung. MLINE(,) Eine Zeile aus einem Memofeld entnehmen. M I N ( < A u s d r u c k l > , ) Minimum zweier Zahlen. MOD(, ) Modulo: Rest einer Division (Dezimalstellen werden abgeschnitten). MONTH() Monatsnummer eines Datums. NDX ( < I n d e x d a t e i n u i n m e r > ) [ , A l i a s ] Name der aktiven Indexdatei, 0 := kein Index offen. NETWORK() ,T. bei Betrieb von dBASE im Netzwerk. ORDER([]) Name des Primärindex (NDX) bzw. des 1. TAG (MDX). os() Bestriebssystemversion. PAD() Name des zuletzt gewählten Menüpunktes. PAYMENT(,, ) Annuität ermitteln. PCOL () Aktuelle Spaltenposition für die folgende Druckausgabe bei SET DEVICE TO PRINT (für

SET PRINT ON ist das Ergebnis 0).

PCOUNT() Anzahl der Parameter, die einer Prozedur übergeben wurden. PI()

Wert der Konstanten jt mit 18 Dezimalstellen Genauigkeit. POPUP() Name des aktiven Popup-Menüs. PRINTSTATUS () .T., falls Drucker empfangsbereit. PROGRAM() Namen des ausgeführten Programms nennen.

-131 -

PROMPT ()

Promptmeldung des zuletzt gewählten Menüs. PROW ()

Aktuelle Zeilenposition für die folgende Druckausgabe. Falls PROW()-Wert 255 übersteigt, wird ein Seitenvorschub ausgelöst. PV(,,) Kapitalwert (Present Value) einer regelmäßigen Zahlungsreihe. RAND ( [ ] ) Zufallszahl 0-0,999999; bei N

KUNDE:

< K N R , NAME, NAMEZUSATZ, STRASSE, PLZORT,ZKONDITION.TEL, FAX, FIBUKONTO>

MATERIAL:

TEIL:

< T H B , TEILETYP, DISPOSTUFE, BEZ, M A S S , V O L U M E N , GEWICHT, H ERSTKOST, A H K >

ARTIKEL:

< I N B , BESCH, GEBINDE, V K , U S T S A T Z , V T K O S T >

LAGERORT:

ZEIT:

LBESTAND:

TSTRUKT:

LKONDIT:

< L N R . T N R . PREIS. MINRAB.MAXRAB.LZFIT,

LKGELTUNG:

< L N R . T N R . A N G D A T U M . V F R F A I I OAT>

BAUFTRAG:

BAPOS:

< L N R . D A T U M . T N R . M E N G E , PREIS. LFRIST>

WAREIN:

WEPOS:

< LNR. DATUM .TNR. M E N G E >

TSLIEF: WAVERT:

PNOTE>

< L N R . DATUM ,TNR. LORT, M E N G E >

ERECHNG:

< L N R . DATUM. LRECHNR. BELEGNR, UST, BRUTTO, NKOST, BUDATUM>

ERPOS:

TSRECH:

KANGEBOT:

KANGPOS:

< K N R . DATUM , TNR. PREIS, LDATUM>

KAUFTRAG:

< K N R . D A T U M . K A U F N R . NETTO.

KAUFPOS:

< K N R . DATUM ,TNR. MENGE, PREIS>

PGEWINÜ>

KAUFRZUORD: ARECHG:

< K N R . D A T U M , R E N R . B E L F G N R , U S T , B R U T T O , BLJDATUM>

ARPOS:

< K N R , D A T U M , T N R . MENGE, PREIS>

WAENTN:

< K N R . DATUM. TNR. LORT. M E N G E >

GUTSCH:

< KNR. RDATUM.TNR. DATUM. GSNR. BELEGNR. UST. BRUTTO. BUDATUM.GRUNN>

MATVER:

ARTZUG:

Fallstudie

-173-

5.2.2.4. Detailliertes Funktionsmodell Das detaillierte Funktionsmodell wird im folgenden mit Hilfe der HIPO-Überblicksdiagramme dargestellt. Zu jeder Funktionseinheit wird ein weitgehend selbsterklärendes Überblicksdiagramm mit den Input-, Verarbeitungs- und Outputabstraktionen abgebildet. Bei der Grobkonzeption der Datenverwaltungsfunktionen wird ein einheitlicher, abstrakter Funktionstyp verwendet, der die Grundfunktionen "Neuanlage", "Suchen", "Ändern", "Löschen" und "Druckausgabe" zur Verfügung stellt. Diese Menge von Operationen auf das jeweilige Objekt wird erst in der Feinkonzeption auf den entsprechenden, speziellen Bedarf angepaßt. So kann etwa die Operation "Bearbeiten" als Kombination von "Neuanlage" oder "Ändern" spezifiziert werden, die je nach Existenz eines gesuchten Primärschlüsselwertes automatisch die entsprechende Operation auswählt. Die Druckausgabe kann ebenfalls weiter differenziert werden, etwa in Einzel- und Listendruck. Die Funktionseinheiten Datenverwaltung Material [1] und Artikel [23] wurden unter dem Aspekt der Spezialisierung von Teiletypen so konzipiert, daß alle Verarbeitungsanforderungen unter Angabe des betreffenden Typs ("M","A") an die Datenverwaltung für den Teiletyp [11] weitergeleitet werden. Die von jeder Funktionseinheit zur Verfügung gestellten (exportierten) Teilfunktionen werden in der oberen Leiste, die importierten Funktionen - soweit es die in der Grobkonzeption definierten Funktionseinheiten betrifft - in der unteren Leiste des Funktionsdiagramms mit der jeweiligen Nummer angegeben. Die Vorgangsfunktionen nehmen in der Regel nur über die importierten Funktionen Zugriff auf die betreffenden Datenbestände, so daß als einziges Input- bzw. Outputelement die Benutzerstation eingetragen ist, die dabei zur Steuerung des Vorgangs erforderlich wird. Eine derartige Spezifikation von Funktionseinheiten impliziert, daß alle zur Steuerung der importierten Funktionen notwendigen Operationen auch als Option von diesen zur Verfügung gestellt werden.

- 174-

Fallstudie

Neu

Suctl

And

Lösch

Druck

Datenverwaltung Materialtyp

Lieferant

Lieferkondition

_ Wareneingang

_

Bflstflllauftrag

Neu

Such

And

Lösch

QD

Druck

Datenverwaltung Lieferant

Eingangsrechnung

5Z3 dU Lieferkondition

Material-

typ-View

Neu

Such

And

Lösch

Druck

Datenverwaltung Lieferkondition

Neu

Such

And

Lösch

Druck

Datenverwaltung Bestellauftrag Materialtyp-View

WEPos

Material-

Warerv verteüg

Such

And

Lösch

E3 O

Druck

Datenverwaltung Wareneingang 14.[NÄL]

BAPOS

dQ

BAPos

Warerveingang Neu

typ-View

LieferKon dit ion

o

a

Liefer-

Lieferant

Materialtyp-View

beleo^

Eingangsrechnung

cJ WEPos

ERPos

6 Neu

Such

And

Lösch

Druck

Datenverwaltung Eingangsrechnung

Eingang» rechnung 1

O

ERPos

-175-

Fallstudie

Lager-

Ueíerant

Materiattyp-Vww

Struktur

BA-Pos

cm AuftragsP06

T-S-4.

Automatisch

a

Manuell

Vorgang Bestellung 3.[S] «(.[NAD]

Automatisch

Manuell

I Mahnung I

Vorgang Bestell-Überwachung

cn

4-lA.Ll

a

Vorgang Lieferung

i m

5 . 4 . | Ä )

r

Matertaityp-View

cm cm cm Uslar. Konditon

Tatetyp

Lagerort

Lagerbestand

Warerv vertert

Lieferantenbewertung

11 Neu Such And Lösch Druck

Datenverwaltung Tei le typ

C~\ V.

I

f^ri n Konditon

Tanelyp

&a

12 Neu Such And Lösch Druck

Datenverwaltung Teilestruktur

ü a

13 Neu Such And Lösch Druck

_ Artileizugang

10

cm

Datenverwaltung Lagerort

&

o

—J

Fallstudie

- 176-

14 Matena 1typ-Vww

Warerv verteHmg

L

-J

Neu Such And

Lösch

Datenverwaltung Warenverteilung

Warenverteilung

5.[S1

Lagerbestand

o

15 ArtikelZugang

Artikeltyp-Vi«w

CT]

Lagerb« stand

Lösch

Datenverwaltung Artikelzugang

ArtkelZugang

Materialtyp-View

cn

Neu Such And

Lösch

Datenverwaltung Materialverbrauch

Materialverbrauch

Artikel typ-View

N e u Such And

Lösch

Datenverwaltung Warenentnahme

18 Material

Artikel

Vorgang Einlagerung 1 4 . [ N , S A j 15.1N.S.A)

19 Material

c n

Artikel

Vorgang Auslagerung 16.IN.&A]

17.[N,S.A]

20

cn Lagerort

Lagerbestand

Vorgang Umlagerung 14.IN.SAU

21

Warenentnahme

Materialverbrauch

Statusdatei

13151

a a a Artikelzugang

Vorgang Inventur

r ArtikelZugang

Lagerbestand

a

17 Lagerort

Lagerbestand

Teiletyp

a

16

Materialverbrauch

Warenentnahme

Neu Such And

"

Lagerbestand

o

Materialverbrauch

!

Lagerbestand

Fallstudie

Teiletyp

- 1 7 7 -

Lagerbestand

ER-Po« 22

o

Auswertung Lagerbestand

Warenverteilung

cm

Eingangsrechnung

23 Neu

Such

And

Lösch

Druck

Datenverwaltung Artikeltyp

24 Kundenangebot

Neu

cm

Ausgangsrechnung

Kundenangebot

KAPOS

Such

And

Lösch

DO

Druck

Datenverwaltung Kunde

25 Neu

Such

And

Lösch

Druck

Datenverwaltung Angebot

angebot

^ÄngeböTJ

26 Auftrag

AuftragsPos-View

CT]

Artikeltyp

AuftragsPos-View

Neu

Such

Lösch

27 Neu

Such

And

AuftragsPos-View

Druck

Datenverwaltung Auftrag

Ausgrechnung

Fibudatei

And

•

a

Ausä " rechnung

Lösch

Datenverwaltung Ausgangsrechnung 17.IN.S.A1

ABO« AK-ros

Fibuda|e)

Druck

Rechnung

f

1

AuftragsPos-View

Fallstudie

- 1 7 8 -

Kunde

28

Gutschrift

AR-Pos

Neu

Such

And

Lösch

Gutschrift

Druck

Fibudstei

Datenverwaltung Gutschrift Fibudatei

Artikeltyp

a

29 Einzel

TextDatei

Mailing

Vorgang Angebote 25.IN.AJ1

a

30 Struktur

Auftrag

TeiletypView

en

AuftragsPos

Vorgang Auftragserfassung 24.IN.Al 23.rN.Al 2 6 . I N . A D l 7.[A]

V

x

31 Einzel

Mailing

Vorgang Auslieferung c = n

2 7 . l N . A D l 14.IN A l

32 Artikeltyp-View

Kunde

AuftragsPos-View

L

en

Auswertung Auftragsbestand

a a

-179-

Fallstudie

5.3. Feinkonzept Die Aufgaben der Feinkonzeptionsphase umfassen die Entwicklung des logischen Datenmodells aus dem konzeptionellen Modell und die detaillierte Spezifikation der Funktionseinheiten. Erst auf der Grundlage des vollständigen logischen Datenmodells kann mit der Detaillierung der Funktionseinheiten begonnen werden.

5.3.1. Beschreibung des logischen Datenmodells Im folgenden wird in Tabellenform das logische Datenmodell vollständig dokumentiert. Zu jedem Attribut einer Relation, das hier, der dBASE-Konvention gemäß, als Feld bezeichnet ist, wird die Typcharakteristik mit Feldname, -typ, -länge und den Dezimalstellen angegeben. Primärschlüsselattribute werden mit P, Fremdschlüsselattribute mit F in der Spalte "Index" gekennzeichnet. Besteht für ein Primärschlüsselattribut gleichzeitig eine Fremdschlüsselabhängigkeit, wird P F eingetragen. Für eindeutige Fremdschlüssel, die aufgrund der Modellgrenzen nicht als solche kontrolliert werden können, wird ein U (unique) vermerkt. Die Relation DATUM wird in diesem Modell nicht als Tabelle implementiert, sondern als Funktion aufgefaßt, die nur jeweils gültige Datumsangaben im Format Tag/Monat/Jahr liefert. Die explizite Fassung als Tabelle wäre jedoch insofern vorteilhaft, als damit eine periodengetreue Kontrolle aller Bewegungsdaten ermöglicht würde. So können zum Beispiel alle Datumseingaben auf die Werktage des Zeitraums beschränkt werden, den das aktuelle Geschäftsjahr umfaßt. Der Beziehungstyp KAUFRZUORD (Zuordnung einer Kundenauftragsposition zu einer Rechnungsposition) wurde bei der Transformation des ER-Modells in das Relationenmodell aufgelöst. Dazu wurde lediglich das Attribut RDATUM (Rechnungsdatum) an die Relation

KAUFPOS

übertragen, die Attribute KNR (Kundennummer) und ADATUM (Auftragsdatum)

waren zuvor bereits Bestandteil von KAUFPOS

und hatten dabei eine jeweils identische

Bedeutung. Der Beziehungstyp LKGELTUNG, der die zeitliche Verfügbarkeit einer Lieferkondition zum Ausdruck bringt, wurde ebenfalls bei der Transformation des ER-Schemas aufgelöst. Da jede Lieferkondition nur einen Zeitbezug aufweisen kann, enthält nunmehr die Relation LKONDIT alle Attribute dieses Beziehungstyps. Aus Vereinfachungsgründen werden in der logischen Datenbeschreibung auch diejenigen Attribute aufgeführt, die erst nach der algorithmischen Beschreibung der Funktionseinheiten neu hinzutreten. Die Werte dieser Attribute (VOLL in BAPOS, VOLL in WEPOS, EDATUM in

KAUFTFIAG) leiten sich jeweils aus anderen, bereits bestehenden Daten ab und sind primär zur effizienten Programmausführung notwendig. Sie können nicht durch den Benutzer direkt manipuliert werden.

Fallstudie

- 180 -

LIEFERAN.DBF Feld 1 2

Feldname LNR

3 4

NAME2 STRASSE PLZORT

5 6 7 8 9

NAME1

BKONTO BLEITZAHL BNAME ZKONDITION

Lieferantenstamm Typ

5 30

Zeichen Zeichen Zeichen Numerisch

30

Numerisch Zeichen Numerisch

10 11

TEL FAX

Zeichen Zeichen

12

FIBUKONTO

Zeichen

KUNDE.DBF Feld 1 2 3 4 5 6 7 8 9

Feldname KNR NAME1 NAME2 STRASSE PLZORT ZKONDITION TEL FAX FIBUKONTO

MATERIAL.DBF Feld Feldname 1 TNR 2 DISPOART 3 4 5 6 7 8

MELDEBEST MINBMENGE MAXBMENGE AKTBMENGE GEBINDE KLASSE

TEIL.DBF Feld Feldname 1 TNR

Länge Dez

Numerisch Zeichen

0

Index

Erklärung

P

Lieferantennummer Firmenname Ansprechpartner

30 30 15 10

Adresse 0 0

Bank-Konto Bankleitzahl

30 6

0

Name der Bank Zahlungskondition Telefon

20 20 6

U

Typ Numerisch Zeichen Zeichen Zeichen Zeichen Numerisch Zeichen Zeichen Zeichen

Kundenstamm Länge Dez Index 5 0 P 30 30 30 30 6 0 20 20 6 U

Typ Numerisch Zeichen

Materialstamm Länge Dez Index 5 0 P 1

Numerisch Numerisch Numerisch Numerisch Numerisch Zeichen Typ Numerisch

2

TEILETYP

Zeichen

3 4

DISPOSTUFE

Numerisch

BEZ

5 6 7

MASS VOLUMEN GEWICHT

Zeichen Zeichen

5 5 5 5 4 1

0 0 0 0 0

Nummer des Kreditorenkontos

Erklärung Kundennummer Firmenname Ansprechpartner Adresse Zahlungskondition Telefon Nummer des Debitorenkontos

Erklärung Material-Nummer Dispositionsart: P:=programm-, V:= verbrauchsgesteuert Meldebestand Kleinste Bestellmenge Größte Bestellmenge Aktuell gültige Bestellmenge Umfang einer Bestelleinheit A,B, oder C-Teil

Teilestamm Länge Dez Index Erklärung P Teiletyp-Nummer 5 0 1 M:=Material, A:=Artikel, H:=Handelsware, G:=Gleichteil; 1 0 Dispositionsstufe Bezeichnung 50 2

Numerisch Numerisch

3 5

Maßeinheit, ST:=Stück 0 2

Größe des Teils in 1000 cm3 Gewicht in kg

8

HERSTKOST

Numerisch

8

2

Einstandspreis oder Herstellkosten

9

AHK

Numerisch

8

2

Anschaffungs- oder Herstellungskosten

Fallstudie

- 181 -

ARTIKEL.DBF

Artikelstamm Länge

Typ

TNR

Numerisch

2

BESCH

Zeichen

3

GEBINDE

Numerisch

3

4

VK

Numerisch

5 7

USTSATZ VTKOST

Numerisch

8 4

2

Verkaufspreis Umsatzsteuersatz

Numerisch

7

2

Vertriebskosten je Einheit

5

Dez

Index Erklärung

Feldname

Feld 1

0

P

160

Artikel-Nummer Angebotstext Verkaufseinheit

2

LAGERORT.DBF Feld Feldname LORT 1 2 BESCHR VKAP 3 4 G KAP

Typ Zeichen Zeichen Numerisch Numerisch

Verzeichnis der Laaerorte Länge Dez Index Erklärung P Kurzbezeichnung 5 Beschreibung 30 5 0 Kapazität in 1000 cm3 3 0 Kapazität in kg

LBESTAND.DBF Feld Feldname 1 LORT 2 TNR 3 MENGE

Typ Zeichen Numerisch Numerisch

Lagerbestand Länge Dez Index Erklärung Lagerort-Kurzbezeichnung 5 PF Teiletyp-Nummer 5 0 PF 0 Bestandsmenge 5

TSTRUKT.DBF Feld Feldname 1 TNR ETNR 2 POEFF 3

Typ Numerisch Numerisch Numerisch

Erzeugnisstrukturdaten (Stückliste) Länge Dez Index Erklärung 5 0 Teiletyp-Nummer Oberteil PF PF 0 Teiletyp-Nummer Unterteil 5 2 0 Produktionskoeffizient

LKONDIT.DBF Feld Feldname 1 LNR 2 TNR PREIS 3 4 MINRAB MAXRAB 5

Typ Numerisch Numerisch Numerisch Numerisch Numerisch

Lieferkonditionen Länge Dez Index 5 0 PF 5 0 PF 2 8 4 0 4 0

6 7 8 9

AKTDATUM GUELTIG LZEIT PNOTE

Datum Datum

8 8

Numerisch Numerisch

4 2

BAUFTRAG.DBF Feld

Erklärung Lieferanten-Nummer Material-Nummer Aktueller Preis Untere Rabattstufe Obere Rabattstufe Datum letzte Aktualisierung Gültig bis

0 0

Durchschnittliche Lieferzeit Relativer Preis ( zu and. Lieferanten)

Bestellaufträge (View auf BAPOS)

Feldname

Typ

Länge

1

LNR

Numerisch

5

2

DATUM

Datum

8

3

GESAMT

Numerisch

9

Dez 0 2

Index Erklärung PF P

Lieferanten-Nummer Bestelldatum Gesamter Bestellwert

Fallstudie

- 182-

BAPOS.DBF Feld Feldname 1 LNR 2 3 4 5 6 7

DATUM TNR MENGE PREIS LFRIST

VOLL

Typ Numerisch Datum

Bestellauftrags-Positionen Länge Dez Index Erklärung 5 0 Lieferanten-Nummer PF 8 Bestelldatum PF

Numerisch Numerisch

5 5

0 0

Numerisch

8 2 1

0 0

Numerisch Numerisch

Pr

2

Material-Nummer Bestellmenge Preis gemäß Angebot / Verhandlung Gewünschte Lieferfrist 1, falls vollständig geliefert

WAREIN.DBF Feld Feldname 1 LNR 2 DATUM LSNR 3

Zeichen

WEPOS.DBF Feld Feldname 1 LNR 2 DATUM 3 TNR 4 MENGE VOLL 5

Typ Numerisch Datum Numerisch Numerisch Numerisch

Wareneingangspositionen Länge Dez Index Erklärung 5 Lieferanten-Nummer 0 Pr Lieferdatum 8 PF 5 0 Material-Nummer Pf 5 0 Liefermenge 1 0 1, falls vollständig berechnet

TSLIEF.DBF Feld Feldname 1 LNR TNR 2 3 BDATUM 4 LDATUM 5 ZMENGE

Typ Numerisch Numerisch Datum Datum Numerisch

Teil-Sammel-Lieferung (Zuordnung BAPOS-WEPOS) Länge Dez Index Erklärung Lieferanten-Nummer 5 0 PF 5 0 Material-Nummer PF Bestelldatum 8 PF Lieferdatum 8 PF 5 0 Zugeordnete Menge

WAVERT.DBF Feld Feldname 1 LNR 2 DATUM 3 TNR 4 LORT 5 MENGE

Typ Numerisch Datum Numerisch Zeichen Numerisch

Warenverteilung auf Lagerplätze Länge Dez Index Erklärung Lieferanten-Nummer 5 0 PF Lieferdatum 8 PF 5 Material-Nummer 0 PF Lagerplatz 5 Pf Verteilte Menge 5 0

ERECHNG.DBF Feld Feldname 1 LNR 2 DATUM 3 LRECHNR 4 BELEGNR

Typ Numerisch Datum Zeichen Numerisch

5 6 7 8

UST BRUTTO NKOST BUDATUM

Typ Numerisch Datum

Numerisch Numerisch Numerisch Datum

Wareneingänge Länge Dez Index Erklärung Lieferanten-Nummer 5 0 PF P Lieferdatum 8 8

Eingangsrechnungen Länge Dez Index 5 0 Pf P 8 8 0 8 0 7 2 2 9 2 8 8

Nummer des Lieferscheins

Erklärung Lieferanten-Nummer Rechnungsdatum Rechnungsnummer des Lieferanten Beleg-Nummer In Brutto enthaltene Vorsteuer Brutto-Betrag In Brutto enthaltene Nebenkosten Kennzeichen für erfolgte Verbuchung

-183-

Fallstudie ERPOS.DBF Feld Feldname 1 LNR 2 DATUM 3 TNR 4 MENGE 5 PREIS

Typ Numerisch Datum Numerisch Numerisch Numerisch

Eingangsrechnungspositionen Länge Dez Index Erklärung Lieferanten-Nummer 5 0 PF Rechnungsdatum 8 PF Material-Nummer 5 0 PF 5 0 Berechnete Menge 2 Preis je Einheit 8

TSRECH.DBF Feld Feldname 1 LNR 2 TNR 3 LDATUM 4 RDATUM 5 ZMENGE

Typ Numerisch Numerisch Datum Datum Numerisch

Teil-Sammel-Rechnung (Zuordnung WEPOS-ERPOS) Länge Dez Index Erklärung Lieferanten-Nummer 5 0 PF Material-Nummer 5 0 PF Lieferdatum 8 PF Rechnungsdatum 8 PF 5 0 Zugeordnete Menge

KANGEBOT.DBF Feld Feldname 1 KNR 2 DATUM 3 KANGNR 4 GDATUM

Typ Numerisch Datum Numerisch Datum

Kundenangebote Länge Dez Index 5 0 PF P 8 6 0 8

KANGPOS.DBF Feld Feldname 1 KNR 2 DATUM 3 TNR 4 PREIS 5 LDATUM

Typ Numerisch Datum Numerisch Numerisch Datum

Kundenangebots-Positionen Länge Dez Index Erklärung Kunden-Nummer 5 0 PF Angebotsdatum 8 PF Artikel-Nummer 5 0 PF 2 Preis 8 Mögliches Lieferdatum 8

KAUFTRAG.DBF Feld Feldname 1 KNR 2 DATUM 3 KAUFNR 4 NETTO 5 PGEWINN 6 EDATUM

Typ Numerisch Datum Numerisch Numerisch Numerisch Datum

Kundenauftrag Länge Dez Index 5 0 PF p 8 0 6 9 2 2 9 8

KAUFPOS.DBF Feld Feldname 1 KNR 2 DATUM 3 TNR 4 MENGE 5 PREIS 6 RDATUM

Typ Numerisch Datum Numerisch Numerisch Numerisch Datum

Kundenauftrags-Positionen Länge Dez Index Erklärung Kunden-Nummer 5 0 PF Auftragsdatum 8 PF Artikel-Nummer 5 PF 5 0 Anzahl 2 Preis je Einheit 8 F Rechnungsdatum- Zuordnung 8

Erklärung Kunden-Nummer Angebotsdatum Kundenangebots-Nummer Gültig bis

Erklärung Kunden-Nummer Auftragsdatum Auftrags-Nummer Netto-Gesamtbetrag Plangewinn Kennzeichen, wann erledigt

Fallstudie

-184-

ARECHG.DBF Feld Feldname KNR 1 2 DATUM RENR 3 BELEGNR 4 5 UST 6 BRUTTO BUDATUM 8

Typ Numerisch Datum Zeichen Numerisch Numerisch Numerisch Datum

ARPOS.DBF Feld

Ausgangsrechnungen Länge Dez Index 5 0 PF P 8 8 8 0 8 2 2 9 8

Erklärung Kunden-Nummer Rechnungsdatum Rechnungs-Nummer Beleg-Nummer (optional für Fibu) MwSt-Betrag Brutto-Betrag Kennzeichen, ob an Fibu übergeben

Ausgangsrechnungs-Positionen Index

Erklärung

PF

Kunden-Nummer

Typ

KNR

Numerisch

2

DATUM

Datum

8

3

TNR

Numerisch

5

4

MENGE

Numerisch

5

0

Anzahl

5

PREIS

Numerisch

8

2

Preis je Einheit

1

WAENTN.DBF Feld Feldname 1 KNR

Typ Numerisch

Länge

Dez

Feldname

5

0

0

PF

Rechnungsdatum

PF

Artikel-Nummer

Waren-Entnahmen Länge Dez Index 5 0 PF

2

DATUM

Datum

8

3

TNR

Numerisch

5

4

LORT

Zeichen

5

5

MENGE

Numerisch

5

0

Erklärung Kunden-Nummer

PF

Rechnungsdatum

PF

Artikel-Nummer

PF

0

Lagerplatz Anzahl entnommener Artikel

GUTSCH.DBF Feld Feldname 1 KNR 2 RDATUM TNR 3 4 DATUM GSNR 5 BELEGNR 6 7 UST BRUTTO 8 BUDATUM 9 GRUND 10

Typ Numerisch Datum Numerisch Datum Zeichen Numerisch Numerisch Numerisch Datum Zeichen

Gutschriften Länge Dez 5 0 8 5 0 8 8 8 0 7 2 2 8 8 120

MATVER.DBF Feld Feldname 1 TNR LORT 2 DATUM 3 4 MENGE WERT 5

Typ Numerisch Zeichen Datum Numerisch Numerisch

Materialverbrauch Länge Dez Index Erklärung Material-Nummer 5 0 PF 5 Lagerort PF P Datum der Entnahme 8 Anzahl 0 5 2 Kosten:= bewerteter Verbrauch 7

ARTZUG.DBF Feld Feldname 1 TNR LORT 2 DATUM 3 4 MENGE

Typ Zeichen Zeichen Datum Numerisch

Artikelzugänge Länge Dez Index Erklärung 5 0 Artikel-Nummer PF Lagerort 5 PF P Datum des Zugangs 8 Anzahl 5 0

Index PF PF PF

Erklärung Kunden-Nummer Gutschrifts-Datum Artikelnummer der Rechnungsposition Rechnungsdatum Gutschriftsnummer Belegnummer (optional für Fibu) MwSt-Betrag (zu korrigieren) Brutto-Betrag Kennzeichen, ob an Fibu übergeben Begründung der Gutschrift

Fallstudie

-185-

5.3.2. Algorithmische Beschreibung der Funktionseinheiten Die Beschreibung des Funktionsmodells kann an dieser Stelle nur zum Teil ausgeführt werden, da die Abbildung der Gesamtdokumentation den hier vorgesehenen Rahmen sprengen würde. Wir stellen im folgenden solche Funktionseinheiten vor, die als exemplarisch für den jeweiligen Typ angesehen werden können und jene Funktionseinheiten, denen eine wesentliche Bedeutung für die Funktionsfähigkeit von IBIS zukommt. Die Spezifikationen wurden an die dBASE-Sprachmittel angelehnt und Befehlsworte werden dementsprechend abgekürzt. Die Datenverwaltungsfunktionen für Material-, Artikel-, und Teiletypen werden vollständig von der Funktionseinheit [11] durchgeführt, lediglich aus der Sicht des Anwenders besteht eine, dem jeweiligen Funktionsbereich angepaßte Funktionseinheit. Die notwendige Differenzierung der Verarbeitungsobjekte innerhalb der Funktionseinheit [11] wird durch das Teiletyp-Kennzeichen ("A","H","M","G") ermöglicht. Die Einheit zur Datenverwaltung der Lieferanten [2] kann als Vorlage für die Datenverwaltungsfunktion "Kunde" [24] eingesetzt werden. Sie weist ebenfalls die allen Datenverwaltungsfunktionen gemeinsame Makrostruktur auf, insofern können bereits an dieser Stelle Überlegungen eingebracht werden, um diese Makrostruktur automatisch zu generieren. Als exemplarisch für solche Funktionseinheiten, die jeweils Datenobjekte, bestehend aus Objektkopf und einer Menge von Einzelpositionen, verwalten, wird die Funktionseinheit [5] vorgestellt. In dem darin verwendeten Unterprogramm

GET_ALL_WEPOS

wird die Transaktions-

kontrolle in untypischer, jedoch effektiver Weise genutzt, um im Bedarfsfall die vollständige Rückabwicklung der Datenerfassung und -änderung zu ermöglichen. Die Vorgangsfunktionen zur Abwicklung der Inventur [21] und der Auftragserfassung [30] sollen hier auch verdeutlichen, daß dem Funktionstyp "Vorgang" keine einheitliche Makrostruktur zugeordnet und die Programmierung insofern nicht standardisiert werden kann. Die Funktionseinheit [22] zur Bestandsbewertung realisiert das FIFO-Verfahren auf der Grundlage der zeitlich geordneten Wareneingänge. Die Funktionseinheit [32] zur Auswertung des Auftragsbestands kann hier als Beispiel dafür angesehen werden, auf welche Weise der Benutzer individuelle Auswertungen mit wenigen, einfachen Befehlen im dBASE-Dialog selbständig durchführen kann. Das Unterprogramm zur Datenübergabe an die Finanzbuchhaltung wird aufgeführt, da diese Funktion hohen Integritätsanforderungen genügen muß. Die Datenübergabe erfolgt an die Datei für wiederkehrende Buchungen der KHK-Fibu, da bei der Verarbeitung wiederkehrender Buchungen eine Auswahlmöglichkeit bezüglich der Buchungsgruppen ( T - I B I S ) und einzelner Buchungsmonate besteht und der Anwender bei Fehlern stets eine Korrektur der Buchungssätze durchführen kann. Der Umsatzsteuer-Schlüssel kann als programmspezifischer Vorgabeparameter geführt werden, da alle Umsätze im Regelfall mit Steuerschlüssel "11" (voller Steuersatz) verbucht werden, und dabei das Finanzbuchhaltungssystem den von IBIS berechneten Steuerbetrag ohne zusätzliche Berechnung übernimmt.

Fallstudie

- 186-

[1] D A T E N V E R W A L T U N G M A T E R I A L T Y P

[2.1] GET_LIEFERANT

Para MODUS,EXIST,mTNR,TASTE

P a r a mLNR.EXlST.TASTE

[11] D A T E N V E R W A L T U N G

TEILETYP

[ P A R A MODUS,EXIST,mTNR.'M'. T A S T E

GET mLNR REAO

|

JA WAHL 1 P A R A SRO.SEO."LNR*NAMEV',"MSG" |

EXIST= S E E K I m L N R / H E F " ) REPEAT bis T A S T E in |.I RETURN mLNR.EXlST.TASTE

(2] DATENVERWALTUNG LIEFERANT Para MODUS,EXIST.mLNR.TASTE

/ • MODUS < ("NEU"."AND":BEAR8".TDSCH". , EDRUCK"; , LIST£")

[2.3] U P D J J E F

[2,21 G E T _ A L L _ L I E F

P a r a mLNR

Para mLNR.EXlST.TASTE

STORE Oe f a u l t s TO mNao\e1.mName2...

•/

STORE NAME1 TO m N a m e l . ; NAME2 TO mName2...

GET m N a m e 1 , m N a m e 2 , m S t r a s s e , m P L Z . mZKO.mTEL.mf AX.mFKTO REAO

REPLA N a m e l with mName1,Name2 w i t h m N a m e 2 , S t r a s s e w i t h m S t r a s s e . P L Z w i t h M P L Z , : ZKO w i t h mZKO.TEL with m T E L . F A X w i t h m F A X . F B U K O N T O w i t h mFKTO

SET ORDER TO FIBUNR

OK = .not. SEEKImFKTO."LIEF"!

OK = n o t . SEEK(mFKTÛ."LIEF"| .or. LIEF->LNRsmLNR

SET ORDER TO PK REPEAT UNTIL OK .and. TASTE= .or. TASTE=

(2.41 DEL _LIEF P a r a mLNR.EXlST

Fallstudie

[5] D A T E N V E R W A L T U N G WARENEINGANG Pira MODUS.EXIST.mlNR.mOATUM.TASTE

[5.1] G E T _ W E I N Para mLNR.mDATUM.EXIST.TASTE

- 187-

- 1 8 8 -

[5.2] G E T _ A L L _ W E P O S Para mLNRjnDATUM,EXIST.TASTE

Fallstudie

Fallstudie

[5.2.1] G E T _ W E P O S Para mlNR.mDATUM.T'ASTE.PosCount

-189-

-190-

[5.3] DEL_WEIN Para mLNR.nBATUM.EXISTJASTE

11! D A T E N V E R W A L T U N G T E I L E T Y P

PARA MODUS.EXISÏ.mTNR.ntlTYP.TASTE /• OEFAULT fyr mTTYP =

Fallstudie

-191 -

Fallstudie

[11.1] G E T _ T E I L Para mTNi.mnYP.EXIST,TASTE

[11.2] GET_ALL_TEIL Parí mTNR.mTTYP.EXIST mTTYP ?

M

H G "**" EXIST' — ^ _ iA NEIN JA NEIN SEEK lmTNR."MAT") SEEK lmTNR."MAn SEEK lmTNR."AfiT"l STORE MAT->Dispoart STORE ART-»Besch STORE KAT->Dispoart TO mÛspoArt.. TO mBesch... TO mOispoArt, .. STORE DefadH TO STORE Defaults TO STORE Oefaul* TO STORE BEZ TO mBEZ,.. STORE spateISO) m8e2,m0ispojrl.... m6ez.mCieb"vJe.... mBez.mOispoart... TO mBez SEEK (raTNR."ART") STORE 0EZ TO m06Z,.. STORE BEZ TD mflEZ, .. STORE ART->Besth TO mBesch... A

NEIN

EXIST"»

JA NEW

EXIST'

mTTYP?

M

H A G mBez.mOispoai't.mHeldebesi. GET mOeMiiDispoari.mMeldebesi. GET m6esch.mGetiinde.mVK, GETmttnBMen ge. mMa « 0M e r»ge, mMinBMefìge.mMaxBMeflge, mUSTSatz.ffiVTKost, m Ak te M e rrçe .m Ge bnde, mAk1BHerige,mGet»n(}e, mflez.mDispostuie. mKlas se.mO is pos tu f e. GET mBei mKlas s e.mOis p os lu f e. mMass. m'V o 1, mGew. Ma s s. m Vrt ,mGe w. mHers 1k o s RE 1. AO mMass, m V o l, mGe v. mHersHiosl.mAHK m AHK .m Bes ( h .m A Getxn de, mHerslVost.ffiAHK READ mVK .mils lsat7.mVtkos 1 READ READ REPEAT bis TASTE in (.I RETURN TASTE

EXIST' ___—•

STORE BEZ TO mBEZ

" JA

Fallstudie

- 1 9 2 -

[11.3] U P D J E I L Para mTNR.mTTYP SEEKImTH»."T£X")? JA

~~

•

NCIN

rnTYP = miTYP'TElETYP«-'." mTYP = tf(mTYP»"AM.MA.".'W',niTTYP)

APPE BLANK mTTYPf

M

A

"\^SEQCImTNR;i1AT7> JA

/

/

ISELE MAT — ^ [ APPE BLANK

H SE EK{f» T NR." ART " )?

NEW JA

/

/

^

G

^

S£EK(«TNR/'ART")?

NEW JA

ISELE APT | APPE BLAMC

—

— — _ _

1 SELE ART |APPEBIAM
p with mTYP,; Ospastufe with «Oispostute.; Dispostile vitti mOispcutuf*.; Mass with mMass.; Mass with mMass.Vol with mVol,. Vol with iVol.ßew with mGew.: Gew with roQew,: Herstkost with mHerstliost.; Herslkost with Vterstkost; AhK with mAHK AHK Witti mAHK

[1U] DELJEIL Pva nTW.aTTYPixcr

JA

^

— «W

-

—

—

1 SELf MAT |appeblam
TEILETYP*"MH" f

JA

^ ^ ^ ^

SELE MATVER

SELE ARTZUG

NEIN

F SEEK|mLNR*DATED*mTNR*fnLOI>K) IF SEEK |mLNR*OATE|K.) REPLA MENGE WITH MENGE-Oiff ELSE REPLA MENGE WITH MENGE-0 APPE BLANK ELSE REPLA TNR with lB->mTNR, REPLA TNR with LB->mTNR. LONR with LB->mLONR.: LONR wilh LB->mLONR.: OATUmwith DATED.DATUM with OATEO.; MENGE wilh-Oift.; MENGE with Diff; WERT with TEIL->SKOST»MENGE ENDIF ENDIF

SELE L6ESTAN0 REPLA MENGE with mMENGE

PRINT LONR,TNR,MENGE,Oiff JA mTNR = TNR rrt-ONR = LONR DATUM = DATEI) SAVE mTNR.mlNR.iOATUM TO FIE "INVENT"

?

_____—-—

"

OELE FILE "INVENT"

NEIN

- 194-

Fallstudie

[22] A U S W E R T U N G L A G E R B E S T A N D

[23] D A T E N V E R W A L T U N G A R T I K E L T Y P Para MOOUS.EXIST.mTNRJASTE

|[11| D A T E N V E R W A L T U N G TEILETYP I P A R A MODUS.EXIST.mrNR.'A'.TASTE

|

- 195-

Fallstudie

[30! A U F T R A G S E R F A S S U N G

[32] A U S W E R T U N G A U F T R A G S B E S T A N D SELE APOS /INDEX ON P K * / DRUCKEN'

—

LIST KNR.LOOKUPIKU >NAME1.KNR.KU->KNR).OATUM,TNR. OISP KNR.LOOKUP(KU->NAME1.KNR.KU->KNR).OATUM.TNR. LOOKUP{TNR->BEZ.TNR.TEIL->TNR). MENGE L00KUP(TNR->BE2.TNR.TEIL->TNR). MENGE IF(TEIL-> TEILET YP="A"."BETRIE6"."HAN0EL") TO PRINT IIF|TEIL-> TEILE TYPs"A","6ETRlEB","MANDEL") FOR RDATUM=Ü FOR RDATUM=0 CALC SUM(MENGE»PREIS) TO GESAMT. SUmilF(TEIL->TEILETYP.rNR.TEIL->TNR)-"A",O.KNGE)«PREIS TO HANDEL FOR RDATUM=I) BETRIEB= GESAMT-HANDEl ? "Handelsanteil ••.HANDEL," = ". RDUNO(HAN0EL/GESAMT.2}»100/'%" ? "Betriebsanteil: ".BETREB." = ROUNOfflETRC B / G E S A M U ) « 100."%" ? "Gesamtwert ".GESAMT

Fallstudie

- 1 9 6 -

[S.1] RECHNUNG_AN_FIBU PARA BuOahjm,BelNummer,RDatifn,Konto.Brutto,Ust,ZKD

BTEXT = "Ausgangsrechnung"

BTEXT = "Eingangsrechnung" GKONTO = Konto KONTO = "S50000" / • Materialeinkauf • /

GKONTO = "S4.1000" GKONTO = •540000" / • Erlose aus Leistungen 0V. UST • / / * Erlöse aus Leistungen Volle UST «

GET ZKD / • Zahlungskonditionen einlesen * /

SAV "SOLLKONTO: ".Konto SAY "HABENKONTO: ".GKonto ERRORLEVEL = 0 USTKEY = "11" GET USTKEY PICTURE " 9 9 " VALID IUSTKEY»"."H"0.11.12.13" RE AO

FIBUOAT = FOPENr013000"}

FIBUOAT s FCREATEC013000") FPUTS|FIBUOAT,space|12fl),126)

FRECS = FREADIFIBUDAT.6) SCOUNT *vaKFRECSl

SCOUNT = 1

FSEEK|FlBUOAT,SCOUNT*t2ß)

ERRORLEVEL=1

FSTRING = K0AT|BuDatumhBelNummer*KDAT(ROatum)*KontO'Str(Brutto«100.l1 •T*GKonto*USTKEY*str(UST*1QQ,11,0hBtext*BelNuinmer»" M -ZKD-"0' •space|1lhstr(MONTH(BuDatijm,2,0)*substr(Year[BuOatum>,3.2) •strlMONTH(BuDatum.2,0)-substr(YearlBuOatum).3.2) / * UST-ART und Skonto-Betrag werden von FIBU automatisch berechnet * OK = FPUTS|FIBUDAT,FSTRING,12B) JA

~~

_____

—•—_____

OKB12B?

NEIN

FCLOSE(FIBUOAT) ERRORLEVEL >0' JA BuOATUM = {) WAIT FEHLERTEXT(ERRORLEVEL) RE TURN BuDATUM

NEIN

-197-

Fallstudie

5.4. Programmierung In der Programmierphase wird zunächst das logische Datenmodell mit Hilfe der Datendefinitionssprache des Datenbankmanagementsystems in die physische Datenstruktur umgesetzt. Dabei sind die allgemein notwendigen Indexe für die Primär- und Fremdschlüssel und die speziell von einzelnen Funktionseinheiten benötigten Indexe festzulegen. Die einheitliche Benennung von Primärschlüssel-Indexen ("PK") erlaubt eine Standardisierung bei der Programmierung der Funktionseinheiten. In dBASE können die Dateien unter Zuhilfenahme der Befehle COPY STRUCTURE und CREATE FROM weitgehend automatisch erstellt werden. Die Entwicklung eines entsprechenden Programms sollte unter dem Aspekt erfolgen, daß aufgrund der automatischen Generierung die Korrektheit und Vollständigkeit der Datenstrukturen besser gesichert werden können als bei einer dialoggeführten Erfassung. Die automatisierte Erzeugung von Programmcode stellt vor allem bei der detaillierten Kenntnis aller Funktionseinheiten eine relevante Alternative für die manuelle Programmiertätigkeit dar. Struktogrammeditoren (CASE-Tools) stellen in der Regel eine Funktion zur Generierung von Quelltext-Skeletten zur Verfügung. Auf diese Weise werden die Kontrollstrukturen der Funktionseinheiten automatisch erzeugt. Bei der vorliegenden Strukturierung nach Funktionstypen kann auch ein speziell entwickeltes Programm, das häufig wiederkehrende Befehlssequenzen generiert, eine insgesamt höhere Produktivität bei der Systementwicklung bewirken. In unserem Fall sind nahezu alle Teilfunktionen der Datenverwaltung standardisiert und können daher automatisch als Programmbausteine erzeugt werden. Als Input für dieses Programm dient die Beschreibung der Datenobjekte gemäß dem logischen Datenmodell, als Output werden z.B. die folgenden Prozeduren generiert: SAY_ALL, DEL_, UPD_, DRUCK..

GET_ GET_ALL,

Dabei werden standardisierte und vereinfachte Quellcodes er-

stellt, die u.a. auch Anweisungen für Bildschirmmasken und Druckformate beinhalten. Das in den Begleitunterlagen verfügbare Programm

DBFTOOL.EXE

erzeugt für alle DBF-Dateien

eines Verzeichnisses die genannten Programmbausteine im dBASE-Quelltext. Die Dialogsteuerung kann mit dem dBASE-Befehlsvorrat zur Menüprogrammierung in kurzer Zeit eingerichtet werden. Eine naheliegende Strategie für die Gestaltung der Menüstruktur besteht darin, das Unternehmensfunktionsmodell (Seite168) in einen Menübaum zu transformieren. Das Hauptmenü würde dann die Bezeichner der drei Funktionsbereiche enthalten und die Untermenüs entsprechende Auswahlmöglichkeiten für einzelne Funktionseinheiten bereitstellen. In vielen Fällen wird eine nach Funktionsbereich und Status des Anwenders (Bereichsleitung, Sachbearbeiter etc.) zugeschnittene Benutzerführung gefordert, um • eine für die jeweiligen Arbeitsabläufe effiziente Auswahlstruktur bereitzustellen und • ausgewählte (sensible) Funktionen nur den für den Zugriff autorisierten Anwendern zur Verfügung zu stellen. Im Anwendungsfall erscheint eine derartige Differenzierung nicht erforderlich.

- 198-

Fallstudie

Im IBIS-Hauptprogramm ist auch ein Zugriff auf allgemeine Funktionen (Dienstmodule) bereitzustellen, die von der bisherigen Spezifikation ausgeklammert wurden. • Zur allgemeinen Verwaltung der Tabellen (Öffnen, Reindexieren, "Packen", Schließen) wird eine Funktion eingeführt, womit in anderen Funktionseinheiten die entsprechende Kontrolle der Tabellen entfallen kann. • Für die Zwecke der allgemeinen Datensicherung sollte eine Funktion vorgesehen werden, sofern die entsprechende Betriebssystemfunktion nicht zweckmäßig erscheint. • Zur Periodisierung der Datenbestände wird eine Funktion benötigt, um Daten für abgeschlossene Geschäftsperioden aus dem aktuellen Bestand herauszulösen und gesondert als Einheit zu sichern. Einerseits besitzen diese Daten dokumentarischen Wert und sollen nicht mehr verändert werden können, andererseits wird dadurch die Effizienz bestimmter Datenzugriffe merklich gesteigert. • Zur Integration weiterer Programme, etwa der KHK-Fibu und des Textverarbeitungssystems, können Menüoptionen für den direkten Aufruf eingeführt werden. Die Programmierung der Funktionseinheiten beginnt mit den Datenverwaltungsfunktionen, die nach erfolgreichem Test als Module für weitere Funktionseinheiten, insbesondere für die Vorgangsfunktionen, zur Verfügung gestellt werden. Beim abschließenden Lasttest sollten die Leistungsmerkmale der eingesetzten Rechnerkonfiguration berücksichtigt und die eventuell notwendige Optimierung von Teilfunktionen auch unter dem Aspekt betrachtet werden, daß die Hardware und die Systemsoftware kontinuierlichen Verbesserungen unterzogen werden, die im Vergleich zu individuellen Programmlösungen relativ kostengünstig ausfallen. In den Begleitunterlagen ist das hier konzipierte IBIS mit allen wichtigen Funktionseinheiten als Quellcode abgelegt. Da ein bis zum Detail vorgedachter Systementwurf die Motivation für die selbständige Beschäftigung mit der Systementwicklung eher zu hemmen als zu fördern geeignet ist, wurden verschiedene Funktioneinheiten für den Fall ausgespart, daß Leser selbständig an der hier vorgetragenen Problemstellung arbeiten möchten.

Zusammenfassung

- 199-

6. Zusammenfassung und Ausblick Die vorgestellte Fallstudie muß als Versuch angesehen werden, die zahlreichen Designund Implementierungsprobleme

innerhalb des Systementwicklungsprozesses

in einer

Übung "auf dem Trockenen" vorzustellen und geeignete Lösungswege aufzuzeigen. Dabei wurde der Gestaltungsprozeß - vom Konzept bis zum Detail - mit dem Ziel aufbereitet, einen Einblick in die Vielfalt der Teilprobleme zu geben. Eine Fallstudie bietet naturgemäß nur unzureichende Analyse- und Erhebungsmöglichkeiten für die Feststellung der Anforderungen. Dieser Problematik wurde dadurch zu begegnen versucht, daß ein in der Praxis häufig unzutreffender Betriebstyp in einer für die Systementwicklung naheliegenden Branche ausgewählt wurde. In der Phase der Grobkonzeption findet ein Konzept für die präzise semantische Datenmodellierung Anwendung, das die Aufdeckung und Darstellung der im zugrundeliegenden Sachverhalt existierenden Informationszusammenhänge ermöglicht. Auf diese Weise kann die in der Feinkonzeptionsphase übliche Normalisierung ganz oder teilweise entfallen. Darüberhinaus wird bereits in der Grobkonzeptionsphase eine stabile Grundlage für den Funktionsentwurf geschaffen. Durch diese Vorverlagerung wird der Entwurfsprozeß insgesamt beschleunigt, so daß bereits zum Ende der Grobkonzeption der Systembauplan verbindlich feststeht. Die

gesicherte Erkenntnis über die Art und den Umfang der von

einem betrieblichen Informationssystem zu bearbeitenden Datenelemente ermöglicht zudem eine fundierte Abwägung über den Fortgang des Projekts. Der Funktionsentwurf kann im Gegensatz zur Datenmodellierung nicht auf durchgängig anwendbare und den Datenmodellen an theoretischer Fundierung und Mächtigkeit vergleichbare Modelle zurückgreifen. Darauf kann u.a. der insgesamt unbefriedigende Forschungs- und Entwicklungsstand der Systementwicklung zurückgeführt werden. Aufgrund dieses Defizits besteht ein dominierendes Problem darin, zweckmäßige und zugleich einfach anwendbare Basistransformationen (Unternehmensfunktionsmodell => Detailliertes Funktionsmodell => Algorithmisches Modell => Programmcode) zu entwickeln. Das Datenmodell wurde zum Teil für die Anforderungen der Kostenrechnung vorbereitet, jedoch sind vor der Entwicklung des Systems zur Kostenträgerrechnung entsprechende Erweiterungen notwendig. Die Vorkalkulation berechnet auf der Grundlage der Materialund Fertigungseinzelkosten die Teilkosten und den geplanten Deckungsbeitrag je Artikel, unter Hinzunahme der Zuschlagssätze können auch die Selbstkosten ermittelt werden. Die zur Betriebsabrechnung notwendigen Gemeinkosten werden dabei aus den Salden verschiedener Kostenkonten der Finanzbuchhaltung übernommen. Unter Berücksichtigung dieser Anforderung und der bestehenden Problematik, daß die Stammdaten für Kreditoren und

Debitoren

redundant

geführt

werden

müssen,

sollte

eine

Erweiterung

des

Finanzbuchhaltungssystems um eine Schnittstelle für den Datenim- und -export (nach Möglichkeit durch den Hersteller dieses Systems) die Voraussetzung für ein entsprechendes Folgeprojekt bilden.

Wir lernen also e i l Problem verstehen, ¡•den wir es tu lösen versuchen und scheitern. Und wenn wir kundertmal gescheitert sind, werden wir vielleicht sogar Spezialisten für dieses Problem. Sir Ktrl

Pepptr

Literaturverzeichnis

203

Literaturverzeichnis: Balzert, H.

Die Entwicklung von Software-Systemen

Mannheim u.a. 1982

Batini, C., Ceri, S., Navathe, S.B.

Conceptual Database Design

Redwood City/Cal u.a. 1992

Chen, P.P.

The Entity-Relationship Model: Toward a Unified View of Data Modelle der Software-Entwicklung

in: ACM TODS, Vol. 1 (1977), No.1, S.9-36

Codd, E.F.

A Relational Model for Large Shared Data Banks

München u.a. 1992 in: CACM, Vol. 13(1970), No.6, S. 377-387;

Dahl, B., Nygaard, K.

SIMULA, an ALGOL-based simulation language

in: CACM Vol. 9 (1988), No.9, S.671-678

Date ,C.J.

An Introduction to Data Base Systems Specification and Design of Dialoque Systems with State Diagrams

Reading/Mass u.a.1990

Chroust, G.

Denert, E.

in: Proceed. ICS (1977) S.417-424

De Marco, T.

Structured Analysis and Systems Specification Englewood Cliffs/NJers 1978

Dijkstra, E.

Structured Programming

Reprint in: Yourdon, E.N.(Hrsg.) 1979, S.43-48

Elmasri, R. , Navathe, S.B.

Fundamentals of Database Systems

Redwood City/Cal u.a. 1989

Goldberg, A.

Introducing the Smalltalk-80 System

in: Byte, Vol. 6 (1981), No.8, S. 14-26

Grupp, B.

EDV-Projekte richtig dokumentieren

Köln 1991

Heilmann, H., Heilmann, W.

Strukturierte Systemplanung und Systementwicklung

Stuttgart u.a. 1979

Jackson, M.A.

Principles of Program Design

London 1975

Liskov, B., Zilles, S.

Programming with Abstract Data Types

in: ACM SIGPLAN (1974), No.9, S. 50-59

Structured Programming in Large Systems Mills, H.D. Nassi, I., Flowchart Techniques for Structured Shneiderman, B. Programming Parnas, D.L. On the Use of Transition Programs in the Design of a User Interface for an Interactive Computer System Parnas, D.L. Petri, C.A.

Gaithersburg[IBM Corp.] 1970 in: ACM SIGPLAN (1973), No.8, S. 12-26 in: Proceed. ACM Conf. (1969), S.379-385

A Technique for Software Module Specification in: CACM Vol. 15 (1972), No.5 with Examples S.330-336 Kommunikation mit Automaten Bonn 1962 (Dissertation)

Ross, D.T.

Structured Analysis: A Language for Communicating Ideas

in: IEEE TOS (1977), No.3, S.16-34

Scheer, A.-W.

Wirtschaftsinformatik - Informationssysteme im Industriebetrieb

Berlin u.a.1990

Schulz, A.

Software-Entwurf - Methoden und Werkzeuge

München u.a. 1990

Sinz, E.J.

Das Strukturierte Entity-Relationship-Modell (SER-Modell)

in: Angewandte Informatik (1988), No.4, S.191-202

Wirth, N.

in: CACM Vol. 14 (1971), No.4, Program Development by Stepwise Refinement S.221-227

Yourdon, E. N. (Hrsg.)

Classics in Software Engineering

Englewood Cliffs/NJers 1979

204

Bezugsmöglichkeiten für die Unterlagen zur COLOWIN-Fallstudie Die Unterlagen zur Fallstudie werden kostenlos zur Verfügung gesteilt. Diesem Buch sind keine Disketten beigelegt, da die Vervielfältigung von Daten und der Vertrieb von Datenträgern keine ökonomisch vertretbare Alternative gegenüber dem Datentransport über öffentliche, zum Teil kostenlos nutzbare Netzwerke darstellt. Aus ökologischer Sicht ist der bedarfsorientierte Abruf von Daten über öffentlich zugängliche Netzwerke ebenfalls vorzuziehen. Die Unterlagen können über das INTERNET-Netz, an dem weltweit die meisten Hochschulen angeschlossen sind, kostenlos abgerufen werden. Die Daten liegen auf dem FTP-Server (FTP: File Transfer Protocol) der Universität zu Köln im Verzeichnis / m s d o s / m i s c a p p s für den Abruf bereit. Als Zugangsvoraussetzung benötigt man einen am INTERNET angeschlossenen Rechner. Die INTERNET-Adresse des Kölner FTP-Servers ist f t p . u n i - k o e l n . d e bzw. [ 1 3 4 . 9 5 . 80 . 1 ] . Von einem am INTERNET angeschlossenen Rechner aus benötigt man lediglich das Kommando ftp ftp.uni-koeln.de, der LOGIN-Vorgang verläuft dann folgendermaßen: Geben Sie bei der Eingabeaufforderung als Benutzerkennung " f t p " an und als Passwort Ihre E-Mail-Adresse, z.B. [email protected]. Das entsprechende Unterverzeichnis wird mit cd /msdos/miscapps ausgewählt. Das Übertragungsprotokoll muß mit dem Befehl " b i n " auf den binären Typ umgestellt werden, anschließend können Sie mit den Befehlen g e t k h k d e m o . z i p und get i b i s . z i p die gewünschten Daten auf Ihren Rechner übertragen. Die Daten sind gepackt, d.h. mit dem Shareware-Programm PKZIP komprimiert, daher muß nach der Übertragung das Programm PKUNZIP zum Dekomprimierung eingesetzt werden, das ebenfalls auf dem angegebenen FTPServer zu finden ist. "BYE" schließt die FTP-Verbindung.

KHK-Finanzbuchhaltung D E M O Nfersion

I B I S Integriertes Basis-InformationiSystem für COLOWIN GmbH

Auf Wunsch senden wir Ihnen die Disketten auch gerne zu. Richten Sie Ihre Bestellung an folgende Adresse: Universität zu Köln, Lehrstuhl für Wirtschaftinformatik, Prof. Dr. Dr. U. Derigs, Kennwort "COLOWIN",Albertus-Magnus-Platz, 5000 Köln 41. Je Bestellung wird jedoch ein im Voraus zu entrichtender Betrag von DM 5.- (gerne auch in Briefmarken) erhoben.