Repräsentation betrieblicher Informationssysteme durch Kombination von Entity-Relationship- und Petrinetztechnik

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Definitionsverzeichnis

Abkürzungsverzeichnis

Symbolverzeichnis

1 Modellierung betrieblicher Informationssysteme als Problem des Informationsmanagements
1.1 Ziele und Aufgaben
1.2 Gliederung und Ziel der Arbeit

2 Petrinetze als Modellierungstechnik für betriebliche Informationssysteme
2.1 Modellierung betrieblicher Informationssysteme
2.2 Das Modellierungspotenzial von Petrinetzen
2.2.1 Allgemeine Potenziale von Petrinetzen
2.2.2 Spezielle Potenziale ausgewählter Petrinetz-Typen
2.2.2.1 K/I-Netze
2.2.2.2 B/E-Netze
2.2.2.3 S/T-Netze
2.2.2.4 Pr/T-Netze
2.3 Modellierungsdefekte von Petrinetzen
2.3.1 Komplex strukturierte Datenobjekte
2.3.2 Unabhängig voneinander ausführbare Arbeitsschritte
2.3.3 Undefinierte Werte
2.4 Ansätze zur Heilung der Modellierungsdefekte

3 Ansätze zur Heilung der Modellierungsdefekte von Petrinetzen mit Hilfe der Entity-Relationship-Technik
3.1 Das Modellierungspotenzial der Entity-Relationship-Technik
3.1.1 Semiformale Datenmodelle
3.1.2 Formale Datenmodelle
3.1.3 Resümee
3.2 Komplexe Datenobjekte in E-R-Modellen
3.2.1 Normalisierung komplexer Datenobjekte
3.2.2 Genestete Relationen zur Modellierung komplexer Datenobjekte
3.2.2.1 Das Modellierungspotenzial genesteter Relationen
3.2.2.2 Genestete Relationen als Erweiterung des Entity-Relationship-Modells
3.2.2.3 Genestete Relationen als Sichten auf das Entity-Relationship-Modell
3.3 Manipulation von Daten in genesteten Relationen
3.3.1 Begründung des Manipulationsbedarfs
3.3.2 Defekte bei der Manipulation von Daten in genesteten Relationen
3.3.3 Ansätze zur Heilung der Manipulationsdefekte
3.3.3.1 Inklusionsordnung
3.3.3.2 Objektordnung
3.3.3.3 Ordnungsdefinition und Ordnungsgleichung
3.3.3.4 GPNF-Instanzen
3.3.3.5 Negativ einer Instanz
3.3.4 Filtertabellen zur semiformalen Beschreibung der erweiterten Ausdrucksmittel
3.3.4.1 Das Modellierungspotenzial von Filtertabellen
3.3.4.2 Operationen auf genesteten Relationen mit Filtertabellen
3.3.4.2.1 Selektion von Daten
3.3.4.2.2 Einfügen und Löschen von Daten
3.4 Resümee

4 Integration von Ausdrucksmitteln der E-R- in die Petrinetz-Technik
4.1 NF²-Relationen/Transitionen-Netze
4.2 Netzkomponenten
4.2.1 Stellen und genestete Relationen
4.2.2 Kanten und Filtertabellen
4.2.3 Transitionen und Schaltregeln

5 Evaluation
5.1 Beurteilungskriterien
5.2 Bewertung der Modellierungstechnik
5.2.1 Modellierungsfähigkeit
5.2.2 Integration
5.2.3 Flexibilität
5.3 Kritische Würdigung

Literaturverzeichnis

Anhang
Petrinetz-Definitionen
Fallstudie

Eidesstattliche Versicherung

Abbildungsverzeichnis

Abbildung 1: Crew-Anforderung als Formular

Abbildung 2: Die drei Konzepte eines Systems

Abbildung 3: Modellierung betrieblicher Informationssysteme

Abbildung 4: Geschäftsvorfall "Flugvorbereitung" als K/I-Netz

Abbildung 5: Flugvorbereitung als B/E-Netz

Abbildung 6: Flugvorbereitung als S/T-Netz

Abbildung 7: Flugzeugzuweisung als Pr/T-Netz (Teil 1)

Abbildung 8: Flugzeugzuweisung als Pr/T-Netz (Teil 2)

Abbildung 9: Sperren eines Datenobjektes

Abbildung 10: E-R-Modell ohne Attribute

Abbildung 11: E-R-Modell mit Attributen

Abbildung 12: Ausschnitt aus einem E-R-Modell

Abbildung 13: Beispiel für ein NR/T-Netz

Tabellenverzeichnis

Tabelle 1: Aufbau der Arbeit

Tabelle 2: Flugzeug mit flachen n -Tupeln dargestellt

Tabelle 3: Aufteilung von Daten über mehrere Tabellen

Tabelle 4: Nullwerte in einem flachen n -Tupel

Tabelle 5: Daten in Non First Normalform

Tabelle 6: Daten in erster Normalform

Tabelle 7: Daten in dritter Normalform

Tabelle 8: Komplexes Datenobjekt als geschachtelte Tabelle

Tabelle 9: Genestete Relation in Tabellenform

Tabelle 10: Hergeleitetes Datenobjekt in Tabellenform (1)

Tabelle 11: Hergeleitetes Datenobjekt in Tabellenform (2)

Tabelle 12: Mehrere Flugzeuge gleicher Bauart

Tabelle 13: Tupel eines komplexen Datenobjekts (Beispiel 1)

Tabelle 14: Mitarbeiter mit veränderlichen Qualifikationen

Tabelle 15: Tupel als komplexes Datenobjekt (Beispiel 2)

Tabelle 16: Zwei Instanzen des Datenmodells "Flugzeug"

Tabelle 17: Vereinigung und Schnittmenge mit der Inklusionsordnung

Tabelle 18: Zwei Instanzen des Datenmodells "Mitarbeiter"

Tabelle 19: Vereinigung und Schnittmenge mit der Objektordnung

Tabelle 20: Nicht antisymmetrische Instanzen

Tabelle 21: Instanzen der Relation „Aufgabe“

Tabelle 22: Verschmelzen von Instanzen mit Ordnungen

Tabelle 23: Negativ einer Instanz i1

Tabelle 24: Datenbestand für die Abfrage von Daten

Tabelle 25: Ergebnis einer Selektion

Tabelle 26: Hinzufügen von Tupeln (1)

Tabelle 27: Hinzufügen von Tupeln (2)

Tabelle 28: Hinzufügen von Tupeln (3)

Tabelle 29: Startmarkierung eines NR/T-Netzes

Tabelle 30: Bewertung der Modellierungsfähigkeit

Tabelle 31: Bewertung der Integration

Tabelle 32: Bewertung der Flexibilität

Tabelle 33: Gesamtbewertung der Modellierungstechnik

Definitionsverzeichnis

Definition 1: Netz

Definition 2: Datenmodell

Definition 3: Entity-Typ

Definition 4: Beziehungs-Typ

Definition 5: Instanz (einzelwertige Attribute)

Definition 6: Instanz (mengenwertige Attribute)

Definition 7: Inklusionsordnung

Definition 8: Objektordnung

Definition 9: PNF-Instanzen

Definition 10: Ordnungsdefinition und Ordnungsgleichung

Definition 11: Generalized Partitioned Normal Form (GPNF-) Instanzen

Definition 12: Negativ einer Instanz

Definition 13: Bewerteter Top-Level-Term, Instanziierung eines Terms

Definition 14: NR/T-Netz

Definition 15: Aktivierte Transition

Definition 16: Schalten einer Transition

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Symbolverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Logisch-mathematische Symbole

Abbildung in dieser Leseprobe nicht enthalten

1 Modellierung betrieblicher Informationssysteme als Problem des Informationsmanagements

1.1 Ziele und Aufgaben

„Alles Leben ist Problemlösen. Alle Organismen sind Erfinder und Techniker, gute oder weniger gute, erfolgreich oder weniger erfolgreich im Lösen von technischen Problemen.“^[1]

Betriebswirtschaftliche Probleme^[2] entstehen aus unternehmerischen Zielen sowie den daraus resultierenden Aufgabenstellungen. Sie werden auf der Basis von Informationen^[3] gelöst. Informationen dienen der Problembeschreibung, der Formulierung einer Frage und der Problemlösung: Die Problembeschrei­bung wird durch gegebene Informationen, eine Frage durch gesuchte Informa­tionen repräsentiert. Eine Frage zu beantworten bedeutet, eine Problemlösung vorzuschlagen^[4]. Die Möglichkeiten der Problemlösung hängen von den vorhan­denen Informationen zur Problembeschreibung und den realisierbaren Lösungsalternativen ab. Deshalb müssen Informationen über das Problem und seine Lösungsmöglichkeiten beschafft werden^[5].

Betriebliche Informationssysteme (im folgenden auch kurz: BIS) bestehen aus Menschen und Maschinen, die durch den Austausch und die Verarbeitung von Informationen innerhalb eines organisatorischen Rahmens miteinander kom­munizieren^[6]. Diese Kommunikation kann von Mensch zu Mensch, Mensch zu Maschine, Maschine zu Mensch und Maschine zu Maschine erfolgen. Der Schwerpunkt dieser Arbeit richtet sich auf technikgestützte BIS. Diese weisen mindestens eine technische –i.d.R. computergestützte– Komponente auf.

Ziel des Einsatzes von BIS ist es, die Wirtschaftlichkeit der betrieblichen Sys­teme, aber auch der Informationssysteme selbst zu gewährleisten. Dieses Ziel setzt sich aus der Reduzierung der Kosten und der Erhöhung des Nutzens für die BIS, vor allem aber aus den Nutzensteigerungen in indirekten Bereichen zusammen^[7]. Nutzensteigerungen in indirekten Bereichen können z.B. durch die Beschleunigung zentraler Geschäftsprozesse erreicht werden^[8].

Weitere relevante operationale Teilziele der BIS sind Flexibilitätssteigerun­gen, Reduzierung der Durchlaufzeiten bei den Informationsprozessen, eine möglichst große Aufgabenbezogenheit, Qualitätssteigerungen der Informa­tionen und der Informationsprozesse, die Beherrschung der Systemkomplexität bei gleichzeitig hohem Integrationsgrad sowie die sich daraus ergebenden, auf den Markt gerichteten Ziele indirekter Bereiche^[9].

Unternehmen stehen daher vor der Aufgabe, den Einsatz der Ressource Infor­mation^[10] und die damit verbundenen Geschäftsprozesse zu planen, zu steuern und zu kontrollieren. Aufgrund dieser Aufgaben empfiehlt es sich, den Infor­mationsbedarf und die Geschäftsprozesse eines Unternehmens zu modellieren. Dabei wird die Hypothese vertreten, dass die Komplexität der aus den o.g. Aufgaben resultierenden Probleme mit Hilfe von Modellen besser handhabbar ist. Zweck dieser Modelle ist es, BIS zu repräsentieren, d.h. sprachlich zu re­konstruieren und zu implementieren^[11]. Auf Basis dieser Informationssystem-Modelle können Geschäftsprozesse und der damit verbundene Informationsbe­darf eines Unternehmens geplant, analysiert, modifiziert, dokumentiert und in das BIS implementiert werden. Es wird die Hypothese vertreten, dass damit eine Senkung der Prozesskosten und/oder eine qualitative Verbesserung der Prozesse erreicht wird.

Die in der Betriebswirtschaftslehre häufig verwendete natürliche Sprache be­sitzt jedoch bestimmte Eigenschaften, die für die Modellierung von BIS nachteilig sind^[12]. Dies betrifft ihre fehlende Eindeutigkeit und mögliche Wider­sprüche. Verbale Beschreibungen sind deshalb für die Modellierung von BIS nur bedingt geeignet. Die für Entscheidungs- und Planungsprobleme in der Betriebswirtschaftslehre verwendete mathematische Sprache ist zwar exakter und verifizierbar, aber für den Adressaten in der Unternehmenspraxis häufig nicht oder nur schwer verständlich^[13]. Formale Sprachen allgemein können je­doch helfen, Begriffe und Zusammenhänge zu klären oder zu präzisieren^[14]. Mitunter kann eine formale Beschreibungssprache zur Realisierbarkeit innova­tiver strategischer Ansätze beitragen, da entsprechend formal beschreibbare Konzepte in ein EDV-System implementierbar sind^[15].

Um diesen unterschiedlichen Anforderungen an Beschreibungssprachen ge­recht zu werden, könnten für die Modellierung von BIS eine oder mehrere Mo­dellierungssprachen verwendet werden, die stufenweise Transformationen von einer verbalen zu einer formalen Beschreibung ermöglichen. So könnten natür­lich sprachliche Beschreibungen als Grundlage für die Modellierung von BIS verwendet und durch eine stufenweise Formalisierung die o.g. Probleme ver­baler Beschreibungen reduziert werden. Die Konzeption einer solchen Model­lierungssprache ist das Thema dieser Arbeit.

1.2 Gliederung und Ziel der Arbeit

In dieser Arbeit wird ein Konzept zur Repräsentation betrieblicher Informa­tionssysteme durch Kombination von Entity-Relationship- (E-R-) und Petri­netz-Technik^[16] erstellt. Ausgehend von Petrinetzen als Modellierungstechnik für BIS werden in Kapitel 2 die Potenziale und die Defekte dieser Technik aufge­zeigt. In Kapitel 3 werden die Potenziale der E-R-Technik beschrieben. Dabei wird aufgezeigt, wie die Potenziale der E-R-Technik die zuvor beschrie­benen Defekte der Petrinetz-Technik heilen können.

Die verfügbaren Publikationen^[17], die sich mit einer solchen Kombination befas­sen, sind für Informatik-Laien i.d.R. nicht oder nur schwer verständlich. Das ist u.a. darin begründet, dass unterschiedliche Ansätze auf verschiedenen Abstraktionsebenen mit unterschiedlichen, teilweise schwer nachvollziehbaren Beispielen überwiegend formal-mathematisch beschrieben werden.

Daher werden in den Kapiteln 3 und 4 Elemente unterschiedlicher Ansätze zusammengefügt und anhand eines einheitlichen, praxisrelevanten Beispiels erklärt. Dieses Beispiel wird verbal, und anschließend mit Hilfe der Modellie­rungstechniken sowohl semiformal als auch formal beschrieben. Die semifor­male Beschreibung wird dabei in Form einer grafischen Beschreibung als Schnittstelle zwischen verbaler und formaler Beschreibung verwendet^[18].

In Kapitel 4 werden die erarbeiteten Ausdrucksmittel der E-R-Technik mit den erarbeiteten Ausdrucksmitteln der Petrinetz-Technik kombiniert.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Aufbau der Arbeit

In Kapitel 5 wird abschließend evaluiert, welchen Beitrag dieser Ansatz für die Repräsentation von BIS leistet. Dabei wird angenommen, dass aus einem posi­tiven Beitrag zur Repräsentation von BIS ein positiver Beitrag für das Infor­mationsmanagement folgt.

Zur Veranschaulichung der Modellierungstechniken wird das Problem des sog. „Crew-Scheduling“ verwendet^[19]. Es handelt sich dabei um ein Problem, das im Rahmen des operativen Managements von Fluggesellschaften auftritt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Crew-Anforderung als Formular

Anhand dieses, in Abbildung 1 angedeuteten Beispiels wird schrittweise erläu­tert, wie durch die kombinierte Modellierung mit E-R- und Petrinetz-Technik ein BIS repräsentiert werden kann. Abbildung 1 zeigt ein Formular, mit dem eine Cockpit-Crew für einen Flug von Düsseldorf nach Rom angefordert wird. Der Flug wird mit einem Airbus-320 durchgeführt, für den als Crew-Mitglieder ein Pilot und ein Copilot benötigt werden. Von den mathematischen Modellen zur Lösung des Crew-Scheduling-Problems wird abstrahiert und auf die in Fußnote 19 aufgeführte Literatur verwiesen. Das hier verwendete Beispiel fokus­siert die Repräsentation eines BIS, mit dem sichergestellt werden soll, dass die zur Lösung des Crew-Scheduling-Problems benötigten Informationen bereit gestellt werden.

2 Petrinetze als Modellierungstechnik für betriebliche Informationssysteme

2.1 Modellierung betrieblicher Informationssysteme

Die theoretische Grundlage zur Strukturierung von Problemen bildet in dieser Arbeit die Systemtheorie^[20]. Für das Verständnis von Systemen sind das struktu­rale, das funktionale und das hierarchische Systemkonzept zu unterscheiden^[21] (vgl. Abbildung 2). Dabei fokussiert das Strukturkonzept die Elemente und de­ren Beziehungen untereinander, es soll zeitlich unabhängig gültige Aussagen über das System wiedergeben. Das funktionale Konzept^[22], teilweise auch als Systemverhalten bezeichnet, betrachtet, wie sich etwas verhält. Zum funktio­nalen Konzept gehört auch das logische Verknüpfungsmuster der im System ablaufenden Prozesse sowie die Beziehungen zur Umwelt. Die tatsächlichen zeitlichen Prozessverläufe werden als das dynamische Verhalten des Systems bezeichnet. Unter dem hierarchischen Aspekt wird der Umstand verstanden, dass die Elemente eines Systems sowohl Sub-Systeme repräsentieren und zugleich Teil eines Super-Systems sein können. Von Sub-Systemen abzugren­zen sind Teil-Systeme, bei denen Elemente und Beziehungen einer System­ebene nach einem Kriterium zusammengefasst werden. Ein Element kann so­mit zu mehreren Teil-Systemen gehören, jedoch nur zu einem Super-System. Die Hierarchisierung von Systemen ist insbesondere von Bedeutung, um Kom­plexität, wie sie realen Systemen eigen ist, zu beherrschen^[23].

Abbildung in dieser Leseprobe nicht enthalten

Ähnlich: Ropohl (1978), S.15.

Abbildung 2: Die drei Konzepte eines Systems

Ein Modell wird verstanden als „das Ergebnis einer Konstruktion eines Model­lierers, der für Modellnutzer eine Repräsentation eines Originals zu einer Zeit als relevant mit Hilfe einer Sprache deklariert [...]. Ein Modell setzt sich somit aus der Konstruktion des Modellierers, dem Modellnutzer, einem Original, der Zeit und einer Sprache zusammen“^[24]. Ein Informationssystem-Modell stellt eine spezifische Modellart dar, die Informationen in einem betrieblichen Sys­tem fokussiert^[25]. In Anlehnung an die zuvor zitierte allgemeine Definition ei­nes Modells kann ein Informationssystem-Modell, das betriebliche Informa­tionssysteme fokussiert, wie folgt als spezielles Modell definiert werden: „Ein Informationsmodell ist das Ergebnis einer Konstruktion eines Modellierers, der für Anwendungssystem- und Organisationsgestalter Informationen über zu modellierende Elemente eines Systems zu einer Zeit als relevant mit Hilfe ei­ner Sprache deklariert“^[26].

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Modellierung betrieblicher Informationssysteme

Abbildung 3 verdeutlicht, wie bereits Anfangs erläutert, dass sich aus unterneh­merischen Zielen und Aufgaben die Notwendigkeit des Managements der Res­source Information ergibt. Daraus ergibt sich als Aufgabe des Informations­managements die Modellierung von BIS.

Auf dieser Basis sollte vor dem Prozess der Modellierung der notwendige Detaillierungsgrad eines Modells bestimmt werden, damit eine ökonomisch sinnvolle Relation zwischen den Kosten der Erstellung und dem späteren Nut­zen des Modells erzielt wird^[27].

Weiter verdeutlicht Abbildung 3, dass BIS in Prozess-, Daten- und Organisa­tionsstruktur^[28] unterteilt werden können. Die Prozessstruktur bezieht sich insofern auf die funktionale Komponente des Systems, als dass sie anzeigt, wie sich das System verhält. Sie wird als „strukturale Beschreibung des Ver­haltensaspektes eines Systems“^[29] interpretiert. Die Daten- und Organisations­struktur^[30] wird dagegen als statische und strukturale Komponente eines BIS interpretiert^[31].

Der Fokus dieser Arbeit ist ein Konzept zur kombinierten Modellierung von Prozess- und Datenstrukturen. Dabei fokussiert die Petrinetz-Technik die Pro­zess- und die E-R-Technik die Datenstrukturen. Von der expliziten Behandlung der Organisationsstruktur, genauer: der Struktur der Aufbau organisation, wird damit abgesehen. Diese ist jedoch implizit in der Prozessstruktur enthalten, da einzelne Funktionen bestimmten Organisationseinheiten zuzuordnen sind. Die Prozessstruktur fokussiert damit die Ablauf organisation eines Unternehmens. Eine Zuordnung bestimmter Organisationseinheiten zu einzelnen Funktionen der Prozesse kann so bspw. durch eine zusätzliche informale Beschriftung der Funktionssymbole, oder formal über die Integration in Datenobjekte erfolgen^[32].

2.2 Das Modellierungspotenzial von Petrinetzen

2.2.1 Allgemeine Potenziale von Petrinetzen

Die Grundlage für Petrinetze^[33] wurde von PETRI 1962 im Rahmen einer Disserta­tion mit dem zweideutigen Titel^[34] „Kommunikation mit Automaten“^[35] gelegt. Eine in dieser Dissertation beschriebene Theorie wurde in den darauf folgenden Jahren unter der Bezeichnung „Petrinetze“ weltweit bekannt^[36].

Petrinetze können als grafischer Formalismus zur Beschreibung von Prozess­strukturen verwendet werden. Sie ermöglichen die Beschreibung sequenzieller, sich gegenseitig ausschließender sowie nebenläufiger Aktivitäten^[37], die nicht determiniert sein müssen. Mit Petrinetzen können Zustände eines Geschäfts­prozesses explizit modelliert werden, und es sind Analysetechniken zum Vali­dieren und Verifizieren der konstruierten Modelle verfügbar^[38]. Petrinetze besit­zen ein „solides“ theoretisches Fundament und es ist möglich, „Petri-Netz-artige Darstellungen mit speziellen, anwendungsnahen graphischen Symbolen“^[39] zu verwenden, wodurch eine semantisch gehaltvolle Darstellung erreicht werden kann.

Auf Petrinetzen basierende Modellierungsansätze haben sich als „tragfähig für die Modellierung, die Analyse und die Durchführung realer Geschäftsprozesse herausgestellt“^[40]. Der erfolgreiche Einsatz von Petrinetzen für die Model­lierung von Prozessstrukturen im akademischen Bereich^[41] ermutigte Unterneh­men, auf der Petrinetz-Technik basierende kommerzielle Modellierungssoft­ware anzubieten^[42]. Die verfügbare Modellierungssoftware unterstützt z.T. auch die automatisierte Implementierung der Prozessmodelle in EDV-Systeme, bspw. in Workflow-Management-Systeme (WfMS)^[43].

Petrinetze unterstützen die Komplexitätsreduzierung u.a. durch die Möglichkeit der Vergröberung und Verfeinerung der Netzelemente^[44]. Ein Petrinetz wird verfeinert, indem ein Netzelement durch ein weiteres Netz ersetzt wird. Umge­kehrt wird ein Petrinetz vergröbert, indem ein bestehendes Netz zu einem Netzelement zusammengefasst wird.

2.2.2 Spezielle Potenziale ausgewählter Petrinetz-Typen

Für die Modellierung mit Petrinetzen werden von der Theorie verschiedene Petrinetz-Typen angeboten, die sich durch ihre unterschiedlichen Netzkompo­nenten klassifizieren lassen. Dazu gehören^[45] Petrinetze mit Kanälen und Instan­zen (K/I-Netze)^[46], Bedingungen und Ereignissen (B/E-Netze)^[47], Stellen und Transitionen (S/T-Netze)^[48] sowie Prädikaten und Transitionen (Pr/T-Netze)^[49]. Im folgenden wird die Anwendung dieser vier Netz-Typen anhand des Bei­spiels der Fluggesellschaft für die semiformale und formale Beschreibung von BIS erläutert. Dabei wird aufgezeigt, dass Unterschiede hinsichtlich der Eig­nung dieser Netztypen für eine kombinierte Modellierung von Prozess- und Datenstrukturen bestehen.

2.2.2.1 K/I-Netze

Abbildung 4 (s.u.) zeigt ein K/I-Netz, mit dem der Geschäftsvorfall „Flugvorbe­reitung“ vereinfacht modelliert wurde. Mit dem in dieser Abbildung dargestellten Netz wird semiformal beschrieben, dass Informationen über das verfügbare Flugpersonal und die vorhandenen Crewanforderungen für eine Crewzusammenstellung benötigt werden. Informationen über Crewanforderun­gen ergeben sich aus einer Flugzeugzuweisung, für die wiederum Informatio­nen über durchzuführende Flüge und verfügbare Flugzeuge benötigt werden. Nach der Crewzusammenstellung findet eine Vollständigkeitsprüfung statt, mit der überprüft wird, ob für alle Aufgaben (Pilot, Copilot, usw.) entsprechendes Personal zugeordnet wurde. Das Ergebnis des hier beschriebenen Geschäfts­vorfalls ist ein Einsatzplan.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Geschäftsvorfall "Flugvorbereitung" als K/I-Netz

An dieser Stelle wird ein Vorteil der semiformalen Beschreibung in Abbildung 4 gegenüber der verbalen Beschreibung deutlich: Bereits dieser stark verein­fachte Zusammenhang kann nur verhältnismäßig schlecht verständlich verbal beschrieben werden. Eine weitere Stärke der Petrinetze ist die Formalisierbar­keit dieser semiformalen Beschreibung. Dadurch ist es möglich, eine verbale Beschreibung in eine leichter kommunizierbare semiformale Beschreibung zu überführen, diese semiformale Beschreibung wiederum in eine formale Be­schreibung zu überführen und umgekehrt. Es wird nun erläutert, wie aus der semiformalen Beschreibung in Abbildung 4 eine solche formale Beschreibung hergeleitet werden kann.

In einem Netz mit Kanälen und Instanzen^[50] stellt jeder Kanal (Kreis) eine pas­sive Systemkomponente dar, die lagern, speichern, Zustände annehmen und Objekte sichtbar machen kann. Jede Instanz (Rechteck) stellt eine aktive Sys­temkomponente dar, die für die Erzeugung, den Transport und die Verände­rung von Objekten verantwortlich ist. Ein Pfeil zeigt einen logischen Zusam­menhang, räumliche Nähe, Zugriffsrechte oder unmittelbare Kopplung an. Mit einem Pfeil wird keine „reale“ Systemkomponente repräsentiert, sondern im­mer eine abstrakte, gedankliche Beziehung (Relation). Zeigt ein Pfeil von einer Instanz auf einen Kanal, gehört die Instanz zum Vorbereich des Kanals. Zeigt umgekehrt ein Pfeil von einem Kanal auf eine Instanz, gehört die Instanz zum Nachbereich des Kanals. Ein K/I-Netz wird i.d.R. mit natürlichsprachlichen Anschriften versehen, präzise Schaltregeln existieren dagegen nicht.

Für die folgende formale Definition wurde zur Vereinfachung –zusätzlich zur natürlich sprachlichen Beschriftung– jeder Kanal mit si, i = 1,..., m, jede Instanz mit tj, j = 1,..., n beschriftet (vgl. Abbildung 4).

Das Beispiel aus Abbildung 4 zeigt ein Netz N = (S, T, F) mit S = { s1, s2, s3, s4, s5 }, T = { t1, t2, t3 } und F = {(s1, t2), (s2, t1), (s3, t1), (t1, s4), (t2, s4), (s4, t2), (s4, t3), (t3, s5)}. Die Elemente aus S werden allgemein Stellen und die Elemente aus T werden allgemein Transitionen genannt. F ist die Flussrelation^[51] von N.

In K/I-Netzen stellen die S -Elemente Kanäle, die T -Elemente Instanzen dar. Diese Mengen müssen bestimmten Bedingungen genügen, damit sie ein Netz im Sinne eines K/I-Netzes beschreiben. Alle in den folgenden Kapiteln erläu­terten Netze können als Erweiterungen dieses Petrinetz-Typs aufgefasst wer­den. Sie müssen daher auch den nun folgenden Bedingungen genügen^[52].

Definition 1: Netz

Ein Tripel N = (S, T, F) heißt Netz, falls gilt:

(i) S, T sind endliche Mengen
(ii) S Ç T = Æ
(iii) S È T ¹ Æ
(iv) F Í (S ´ T) È (T ´ S)

Es lässt sich festhalten, dass mit der Petrinetz-Technik Prozessstrukturen durch Kreise, Rechtecke und Pfeile semiformal beschrieben werden können. Weiter können Prozessstrukturen durch Mengen, die bestimmten Bedingungen genü­gen, formal beschrieben werden.

2.2.2.2 B/E-Netze

Abbildung 5 (s.u.) zeigt ein B/E-Netz. Es wurde ein Ausschnitt des Netzes aus Abbildung 4 gewählt, um die Größe des Modells auf ein Mindestmaß zu reduzie­ren und das Problem der kombinierten Modellierung von Prozess- und Datenstrukturen zu fokussieren.

In einem B/E-Netz stellen die Kreise Bedingungen dar, die erfüllt (wahr) sein müssen, damit das nachfolgende Ereignis eintreten kann. Eine erfüllte Bedin­gung wird durch eine Marke (schwarzer Punkt im Kreis, auch als „Token“ be­zeichnet) repräsentiert. In dem hier konstruierten Systemzustand sind die Be­dingungen „Flugdurchführung“ (s2) und „Verfügbare Flugzeuge“ (s3) wahr^[53]. Daher kann das Ereignis „Flugzeugzuweisung“ (t1) eintreten. Nach dem Ein­treten des Ereignisses „Flugzeugzuweisung“ werden die Stellen s2 und s3 nicht wahr, und die Stelle s4 wird wahr. Solange mindestens eine Bedingung im Vorbereich nicht wahr ist, kann das nachfolgende Ereignis nicht eintreten. Ein B/E-Netz wird formal wie ein K/I-Netz definiert, jedoch um sog. Startmar­kierungen und Schaltbedingungen erweitert (vgl. Anhang: Petrinetz-Definitio­nen).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Flugvorbereitung als B/E-Netz

Im Gegensatz zu K/I-Netzen können mit B/E-Netzen Bedingungen, z.B. für die Ausführung eines Arbeitsschritts, repräsentiert werden. Eine erfüllte Bedin­gung kann alternativ auch als das Vorhandensein eines Objekts interpretiert werden. Mit dieser Interpretation lässt sich aber in jeder Stelle lediglich ein Objekt repräsentieren. Auch wird von der Struktur des zu repräsentierenden Objekts abstrahiert, das Objekt kann nur „sein“ oder „nicht sein“. Für die Mo­dellierung von BIS sind B/E-Netze daher nur auf einem hohen Abstraktions­niveau anwendbar. Mitunter werden B/E-Netze schnell groß und unübersicht­lich, z.B. müsste bereits bei der Möglichkeit, dass drei Flugzeuge gleichzeitig verfügbar sind, jeweils eine Bedingung für jedes Flugzeug modelliert werden.

Für B/E-Netze lässt sich daher festhalten, dass zusätzlich Bedingungen und das Vorhandensein von Objekten repräsentiert werden können bzw. kann. Das ist jedoch im Kontext von BIS nur auf einem hohen Abstraktionsniveau mit gro­ßen, unübersichtlichen Netzen und daher sehr schlecht möglich.

2.2.2.3 S/T-Netze

In Stellen/Transitionen- (S/T-) Netzen (vgl. Abbildung 6) werden die Kreise als Objektbehälter interpretiert. Eine Kapazitätsbeschränkung (k) legt für jede Stelle eine maximale (möglicherweise unendliche) Anzahl von Objekten fest, die in der Stelle zu einem Zeitpunkt vorkommen darf. Die Objekte werden als „anonyme“ Marken repräsentiert, die keine Eigenschaften (Werte) besitzen. Transitionen können schalten, d.h. sie sind aktiviert, wenn in jeder Stelle im Vorbereich genügend Marken entsprechend einer für jede Kante angegebenen Kantengewichtung w vorhanden sind und wenn in jeder Stelle im Nachbereich eine ausreichende Kapazität für zusätzliche Marken entsprechend der jeweili­gen Kantenbeschriftung w ist. Wenn eine aktivierte Transition schaltet, wird die an den Eingangskanten angegebene Anzahl von Marken aus den jeweiligen Stellen im Vorbereich entfernt und die an den Ausgangskanten angegebene Anzahl von Marken in die jeweiligen Stellen im Nachbereich eingefügt. For­mal werden S/T-Netze gegenüber B/E-Netzen um Kapazitäten der Stellen und Kantenbeschriftungen erweitert. Die Schaltregel muss entsprechend angepasst werden (siehe Anhang: Petrinetz-Defintionen).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Flugvorbereitung als S/T-Netz

Im Vergleich zu B/E-Netzen kann in S/T-Netzen den Stellen eine Anzahl vor­handener Objekte zugeordnet werden. Zusätzlich können für die Stellen Kapa­zitätsbeschränkungen und durch Kantengewichtungen der Verbrauch an Ob­jekten pro Arbeitsschritt angegeben werden. Von Objektstrukturen wird in S/T-Netzen jedoch ebenfalls abstrahiert. Für die Modellierung von BIS impliziert diese Beschränkung, dass von den Eigenschaften eines Objekts abstrahiert werden muss.

Damit lässt sich festhalten, dass S/T-Netze Kapazitäten und den Verbrauch von Objekten repräsentieren können. Das stellt eine Verbesserung gegenüber B/E-Netzen dar. Da jedoch weiterhin von Objektstrukturen abstrahiert werden muss, lassen sich Objekte nur schlecht modellieren.

2.2.2.4 Pr/T-Netze

Abbildung 7 und Abbildung 8 (s.u.) zeigen ein Pr/T-Netz mit einer Startmar­kierung bzw. einer Folgemarkierung. Pr/T-Netze ermöglichen die Integration objektbezogener Aspekte. Jeder Stelle des Netzes wird, vereinfacht ausge­drückt, eine „Tabelle“ (genauer: eine Menge an Prädikaten mit veränderlichen Ausprägungen) zugeordnet, die diese objektbezogenen Aspekte in Form von Attributen (z.B. Flug#, Start, Ziel, ...) repräsentiert. Der Aufbau einer solchen Tabelle wird im folgenden als Datenstruktur bezeichnet, die damit bezweckten Repräsentationen von Objekten werden Datenobjekte genannt.

Den Transitionen werden Schaltbedingungen und Schaltwirkungen in Form prädikatenlogischer Ausdrücke zugeordnet. Die Schaltbedingung muss erfüllt sein, damit eine Transition schalten und die Schaltwirkung eintreten kann. Die Kanten werden mit Mengen von Variablentupeln beschriftet, deren Stelligkeit gleich der Stelligkeit der dazugehörigen (adjazenten) Prädikaten-Menge der Stelle ist. Das Ergebnis dieser Schaltwirkung wird an die nachfolgende „Ta­belle“ der Stelle „weitergereicht“, die Startmarkierung wird in eine Folgemar­kierung transformiert.

Als Schaltbedingung könnte z.B. definiert werden, dass ein Flugzeug min­destens über so viele Sitze verfügen muss, wie Plätze für den durchzuführen­den Flug benötigt werden. Als Schaltwirkung könnte z.B. bei einer Flugbu­chung (hier nicht dargestellt) definiert werden, dass die Anzahl der verfügbaren Plätze für einen bestimmten Flug um die Anzahl x reduziert wird (für die for­malen Definitionen der Pr/T-Netze siehe Anhang: Petrinetz-Definitionen).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Flugzeugzuweisung als Pr/T-Netz (Teil 1)

Abbildung 8 (s.u.) stellt das Schalten der Transition Flugzeugzuweisung (t1) in bezug auf die Startmarkierung von Abbildung 7 dar. Für den Flug# 455 wird ein Flugzeug mit mindestens 150 Plätzen benötigt. Das Flugzeug# 12 erfüllt mit 155 Sitzen diese Bedingung. Da das Flugzeug# 12 einen Piloten und einen Copiloten („Aufgaben“) benötigt, wurde der Stelle Crewanforderung (s2) für jede zu erfüllende Aufgabe jeweils ein n -Tupel (d.h. insgesamt zwei n -Tupel) zugeordnet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Flugzeugzuweisung als Pr/T-Netz (Teil 2)

Pr/T-Netze heben einen Teil der Restriktionen von B/E- und S/T-Netzen hin­sichtlich der Repräsentation von Objekten durch die Möglichkeit der Verwen­dung von Datenobjekten auf. Sie sind damit –scheinbar– gut geeignet zur Be­schreibung von Prozess- und den zugehörigen Datenstrukturen. Wie im folgen­den noch zu zeigen ist, bestehen jedoch auch bei Pr/T-Netzen Restriktionen, durch die eine Repräsentation von BIS erschwert wird.

2.3 Modellierungsdefekte von Petrinetzen

2.3.1 Komplex strukturierte Datenobjekte

Wie in Kapitel 2.2.2.4 bereits angedeutet wurde, sind Pr/T-Netze hinsichtlich der Datenobjekte auf „flache“ Tabellen (d.h. unstrukturierte n -Tupel) be­schränkt^[54]. Komplex strukturierte Datenobjekte (im folgenden auch kurz: kom­plexe Datenobjekte), wie z.B. das Formular aus Abbildung 1 (S. 6), lassen sich dagegen nicht unmittelbar mit Pr/T-Netzen modellieren.

Die Beschränkung auf unstrukturierte n -Tupel führt dazu, dass zusammenge­hörige Aspekte eines komplexen Datenobjekts in mehreren Zeilen einer Ta­belle –oder alternativ über mehrere Tabellen verteilt– beschrieben werden müssen. Um z.B. den in Abbildung 1 dargestellten Flug durchführen zu kön­nen, wird genau ein Flugzeug benötigt. Für dieses eine Flugzeug ist jedoch eine Cockpit-Crew erforderlich, die aus mehreren Personen besteht, nämlich aus Pilot und Copilot. Da unstrukturierte n -Tupel nur einzelwertige Ausprägungen der Attribute enthalten dürfen^[55], besteht ein Zwang, das Formular aus Abbildung 1 relativ umständlich zu modellieren. Bereits der triviale Zusammen­hang „Flugzeug-Crew“ würde das in Tabelle 2 dargestellte künstli­che Konstrukt erzwingen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2: Flugzeug mit flachen n -Tupeln dargestellt

Künstlich ist an Tabelle 2, dass die Ausprägungen der Attribute Flugzeug#, Typ und Sitze doppelt angegeben werden müssen, damit beide Aufgaben er­fasst werden können. Die Verwendung von mehreren Attributen (z.B. „Auf­gabe1“, „Aufgabe2“ usw.) ist unbefriedigend, weil so für jede potenzielle Auf­gabe ein einzelnes Attribut verwendet werden müsste, wodurch das Modell unübersichtlich würde. Alternativ könnten diese redundanten Daten durch eine Aufteilung über zwei Tabellen weitgehend vermieden werden (vgl. Tabelle 3)^[56]. Dann müsste die Beschreibung der verfügbaren Flugzeuge aber zugleich auf zwei Stellen im Netz verteilt werden, was ebenfalls eine künstliche und unübersichtliche Beschreibung wäre. Mitunter könnte dadurch in komplexen Modellen der Fall eintreten, dass durch einen Fehler des Modellierers zwar das Löschen des Flugzeugs modelliert, das Löschen der zugehörigen Aufgaben jedoch vergessen wird. In einem solchen Fall spricht man von Inkonsistenzen hinsichtlich des Modells und damit später auch der Datenbestände^[57].

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3: Aufteilung von Daten über mehrere Tabellen

Es lässt sich festhalten, dass Pr/T-Netze für die Modellierung von komplexen Datenobjekten lediglich mittelmäßig geeignet sind. Das ist darin begründet, dass komplexe Strukturen, wie sie Datenobjekten i.d.R. eigen sind, zu kompli­zierten und künstlichen Netzkonstruktionen führen, da der Zugriff einer Tran­sition auf alle zu einem Datenobjekt gehörigen Tupel nur umständlich model­liert werden kann.

2.3.2 Unabhängig voneinander ausführbare Arbeitsschritte

Das Problem der Modellierung von Nebenläufigkeit^[58], d.h. unabhängig voneinan­der ausführbarer Arbeitsschritte, folgt aus dem Problem, dass kom­plexe Datenobjekte in Pr/T-Netzen nur umständlich modelliert werden können. So könnte dasselbe Formular –falls in digitalisierter Form vorliegend– gleich­zeitig für mehrere Arbeitsschritte und unterschiedliche Mitarbeiter im Zustand „in Bearbeitung“ sein. Wenn aber ausgeschlossen werden soll, dass ein Sach­bearbeiter gleichzeitig mehrere Arbeitsschritte ausführt, d.h. mehrere Formu­lare gleichzeitig am Bildschirm geöffnet hat, dann ist die Einführung einer „künstlichen“ Prädikat-Stelle „Formular-gesperrt“ nötig.

Abbildung in dieser Leseprobe nicht enthalten

Ähnlich: Oberweis (1996a), S. 108.

Abbildung 9: Sperren eines Datenobjektes

Angenommen, es soll beschrieben werden, dass dasselbe Datenobjekt „Flug­zeug“ an unterschiedlichen Arbeitsplätzen unabhängig voneinander bearbeitet wird. So ist es bspw. denkbar, dass an bestimmten Arbeitsplätzen den Flugzeu­gen Crews zugewiesen werden und an anderen Arbeitsplätzen für dieselben Flugzeuge Eintragungen für erforderliche Inspektionen vorgenommen werden.

Wenn aber ausgeschlossen werden soll, dass ein Sachbearbeiter in einem EDV-System z.B. gleichzeitig für mehrere Flugzeuge Crew-Zuweisungen vor­nimmt, dann ist die Einführung der oben erwähnten künstlichen Prädikat-Stelle „Formular-gesperrt“ notwendig. Da in Pr/T-Netzen keine komplexen Daten­objekte zugelassen sind, kann ein Formular mit dem Status „Formular-ge­sperrt“ in anderen Arbeitsschritten nicht mehr bearbeitet werden.

Es lässt sich das Fazit ziehen, dass Restriktionen hinsichtlich der Nebenläufig­keit von Schaltvorgängen auf unterschiedlichen Komponenten desselben kom­plexen Datenobjekts nur sehr umständlich modellierbar sind. Daher kann fest­gehalten werden, dass Pr/T-Netze für die Modellierung von Nebenläufigkeit lediglich mittelmäßig geeignet sind.

2.3.3 Undefinierte Werte

Das Problem der undefinierten Werte^[59] betrifft in dem hier verwendeten Bei­spiel das Einfügen von Fluganforderungen, für die noch nicht bekannt ist, wie viele Sitzplätze benötigt werden. In einem solchen Fall müssten vordefinierte Nullwerte eingeführt werden, die angeben, dass für den betreffenden Flug noch nicht feststeht, wie viele Sitzplätze benötigt werden. Um eine konsistente Be­handlung von Nullwerten sicherzustellen, müssten zusätzliche Integritätsbe­dingungen eingeführt werden, die eine konsistente Behandlung solcher Null­werte sicherstellen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 4: Nullwerte in einem flachen n -Tupel

Würde bspw. der Fall eintreten, dass die Anzahl der benötigten Plätze für einen einzutragenden Flug noch nicht bekannt ist, so ließe sich dies nicht durch die Zahl „0“ darstellen. Zeile 1 in Tabelle 4 könnte nämlich interpretiert werden derart, dass für den Flug# 455 keine Plätze benötigt werden. Daher müsste für ein betroffenes Pr/T-Netz vereinbart werden, dass bspw. der Wert „N.B.“ da­hingehend zu interpretieren ist, dass nicht bekannt ist, wie viele Plätze benötigt für den Flug benötigt werden.

Es lässt sich festhalten, dass in Pr/T-Netzen eine umständliche Einführung von Nullwerten notwendig ist, um leere Mengen repräsentieren zu können. Wün­schenswert ist dagegen, leere Mengen explizit repräsentieren zu können.

2.4 Ansätze zur Heilung der Modellierungsdefekte

(1) Abstraktion von Datenstrukturen

Durch die Verwendung von B/E- und S/T-Netzen kann generell von Daten­strukturen abstrahiert werden^[60], d.h. Objekte werden als Marken ohne weitere Eigenschaften (Attribute) modelliert. Auch kann das Systemverhalten dann nicht explizit in Abhängigkeit von bestimmten Objekteigenschaften beschrie­ben werden, sondern nur in Abhängigkeit von dem Vorhandensein eines Ob­jektes. Alternativ könnte zwar jede Objekteigenschaft in B/E-Netzen durch eine Bedingung und in S/T-Netzen durch eine Marke repräsentiert werden. Das bedeutet jedoch eine Aufblähung des Netzes und ist bei im Umfang über Trivi­albeispiele hinausgehenden Anwendungen kaum praktikabel.

(2) Verwendung eines einfachen Datenmodells

Aufgrund der fehlenden Schnittstelle zwischen komplexen Datenobjekten und Pr/T-Netzen kann zur Datenmodellierung ein (Meta-)Datenmodell eingesetzt werden, das keine komplexen Datenobjekte zulässt^[61]. Damit wird jedoch nur das Schnittstellenproblem zwischen Pr/T-Netzen und Datenstrukturen gelöst, nicht jedoch die Probleme der Beschreibung komplexer Datenobjekte, der Ne­benläufigkeit und der undefinierten Werte.

(3) Zulassen komplexer Datenobjekte

Die zuvor genannten Ansätze heilen die Modellierungsdefekte von Petrinetzen durch eine Reduzierung des Modellierungspotenzials, lösen aber nicht die zu­vor beschriebenen Defekte der Pr/T-Netze. Um diese Defekte zu heilen, ohne das Modellierungspotenzial zu reduzieren, müssten komplexe Datenobjekte und die Möglichkeit zur Manipulation dieser (d.h. hinzufügen, ändern und lö­schen) in Petrinetze integriert werden, idealerweise mit der Möglichkeit der Heilung des Nebenläufigkeit-Defekts und der Repräsentation undefinierter Werte von Attributen. Aus diesen Anforderungen folgt jedoch, dass man dafür in einem ersten Schritt die Restriktion Datenobjekte müssten als flache n -Tupel konstruiert sein fallen lassen muss. Denn wie bereits z.T. erläutert wurde, re­sultieren die Probleme aus dem Zwang zur Modellierung der Datenobjekte als flache n -Tupel.

3 Ansätze zur Heilung der Modellierungsdefekte von Petrinetzen mit Hilfe der Entity-Relationship-Technik

Im diesem Kapitel wird eine zusätzliche Modellierungstech­nik für die Model­lierung von Datenstrukturen eingeführt. Dabei wird von dem für die Datenmo­dellierung verbreiteten Entity-Relationship- (E-R-) Ansatz ausgegangen, da dieser unabhängig von EDV-technischen Implementierungs­aspekten, intuitiv verständlich^[62] und formalisierbar^[63] ist. Dieser E-R-Ansatz wird anschließend derart erweitert und formal definiert, dass daraus abgeleitete komplexe Daten­objekte mit Petrinetzen kombiniert werden können. Durch eine solche Kombi­nation sollen dann sowohl Prozess- als auch Datenstrukturen eines BIS Model­liert werden können.

3.1 Das Modellierungspotenzial der Entity-Relationship-Technik

Der Entity-Relationship- Ansatz wurde 1976 von Chen als konzeptuelles Da­tenmodell vorgestellt^[64]. Die Entity-Relationship- Technik (E-R-Technik) be­zieht sich auf dieses konzeptuelle Datenmodell, das im folgenden um die für die hier behandelte Problematik relevanten Aspekte erweitert wird.

Chen definiert „Entity“ als ein „Ding“, das deutlich („distinctly“) identifi­ziert werden kann und nimmt an, dass zwischen Entities Beziehungen (Rela­tionen) existieren^[65]. Auf der Grundlage dieses Ansatzes wurden verschiedene Varianten und Erweiterungen entwickelt^[66], die in der betrieblichen Praxis z.T. Verbreitung gefunden haben^[67].

[...]

---

^[1] Popper (2002), S. 257.

^[2] Probleme werden verstanden als Abweichungen eines Ist- Zustands vom Soll-Zustand.

^[3] Informationen werden verstanden als das, was vielfältige pragmatische Komponenten auf­weist, Wissen (d.h. die für wahr erachteten Sätze) voraussetzt, Neuigkeitsgrad besitzt, zeit­punktbezogen ist und beliebige mit menschlichem Handeln verbundene Träger besitzt. In­formationen weisen enge Beziehungen zum Wissen auf, weil sie einerseits Wissen voraus­setzen und andererseits zu einer Veränderung des Wissenstandes führen können. Daten werden nicht als „inhaltsfrei“ verstanden, da auch Rohdaten Informationen darstellen kön­nen. Sie werden statt dessen als spezifische Informationen betrachtet, die Aussagen über die Realität vor dem Hintergrund einer bestimmten Vorstrukturierung treffen. Daten setzen damit eine Strukturierung der Welt voraus, zu der es Daten geben kann, vgl. Schütte (1998), S. 1-5, Fußnote 5.

^[4] Vgl. Schmidt (1999), S. 1.

^[5] Vgl. Schmidt (1999), S. 11.

^[6] Vgl. Antweiler (1995), S. 12 f.

^[7] Vgl. Antweiler (1995), S. 42.

^[8] Vgl. Österle (1996), S. 1. Danach ist ein Geschäftsprozess dann besser, wenn er mit niedrige­ren Kosten und/oder in höherer Qualität als zuvor abgewickelt werden kann.

^[9] Vgl. Antweiler (1995), S. 43.

^[10] Während Information als Gestaltungsobjekt früher oftmals nur in Form dispositiver Tätigkei­ten Berücksichtigung fand, wird sie heute zum einen als Produkt und zum anderen als Produktionsfaktor explizit wahrgenommen, vgl. Antweiler (1995), S. 4 f. sowie S. 4, Fußnoten 13 und 14.

^[11] Die Repräsentation umfasst die Beziehung eines Begriffs zu dessen semanti­scher/pragmatischer Bedeutung als Objekt in der Realität oder Fiktion.

^[12] Für eine weitergehende untersuchende Darstellung verschiedener Spracharten siehe Ditt­mann (2002).

^[13] Die schwere Verständlichkeit formal-mathematischer Beschreibungen für Adressaten in der Unternehmenspraxis stellt insb. einen Nachteil in bezug auf die Kommunikation zwischen Informatikern/Mathematikern und Informatik-/Mathematik-Laien dar. Abweichend Scheer (1998), S. 1 f. Scheer nimmt an, dass „die in der Betriebswirtschaftslehre verwendete ma­thematische Sprache“ nicht für alle betriebswirtschaftlichen Problembeschreibungen an­wendbar ist. Jedoch erläutert Scheer nicht, was genau unter „der“ mathematischen Sprache zu verstehen ist und für welche betriebswirtschaftlichen Problembeschreibungen eine sol­che Sprache anwendbar wäre. Für mögliche Anwendungen siehe z.B. Zelewski et al. (2001), insb. S. 196-200.

^[14] Eine Folge begrifflicher Defizite können methodische Defizite sein, unter denen u.a. die Wirtschaftsinformatik leidet, vgl. Lehner (1996), S. 68-72.

^[15] Beispiele der Vergangenheit haben gezeigt, dass innovative strategische Ansätze zur Gestal­tung von Unternehmen scheitern, wenn sie sich nicht durch geeignete Informations- und Kommunikationstechnologien realisieren lassen. Dies gilt bspw. für die Ideen zu Ma­nagement-Informationssystemen in den 70er genauso wie für den CIM-Gedanken in den 80er Jahren, vgl. Scheer (1996), S. 255.

^[16] Techniken werden als Teilmenge wissenschaftlicher Methoden verstanden.

^[17] Wie z.B. Bancilhon/Khoshafian (1989); Jaeschke (1996); Jaeschke et al. (1993); Jaeschke et al. (1994); Lamersdorf/Schmidt (1983); Oberweis (1996a); Oberweis (1996b); Oberweis et al. (1997a); Oberweis et al. (1997b); Oberweis/Sander (1996); Roth et al. (1988); Sander (1992); Sander (1993); Schek/Scholl (1983); Schek/Scholl (1986); Stucky et al. (1993); Thalheim (2000).

^[18] Die formale Beschreibung wird dabei als Basis für eine Implementierung in ein EDV-Sys­tem betrachtet. Sie ist jedoch unabhängig von einer maschinenorientierten Programmier­sprache, vgl. Oberweis (1996a), S. 173-178.

^[19] Ziel des Crew-Scheduling ist es, die Kosten von Flugzeug-Crews durch Optimierung der Einsatzpläne zu minimieren. Dieses Problem wird in der Fachliteratur mit Hilfe unter­schiedlicher Ansätze behandelt. Murray (1961) präsentierte bereits 1961 einen Lösungsan­satz; Levine (1996) diskutierte die Entwicklung eines genetischen Algorithmus als Lö­sungsansatz; Chu et al. (1997) behandelten das Problem als ganzzahliges Teilmengen­problem; Beasley/Cao (1998) versuchten das Crew Scheduling-Problem mit einem auf dy­namischer Programmierung basierenden Algorithmus zu lösen; Lagerholm et al. (2000) präsentierten einen auf neuronalen Netzwerken basierenden Lösungsansatz; Ozde­mir/Mohan (2001) entwickelten einen genetischen Algorithmus als Lösungsansatz; Yan/Chang (2002) sowie Yan/Tu (2002) favorisieren ein Netzwerk-Modell, das sie anhand von Flugdaten einer taiwanesischen Fluggesellschaft insb. für das Scheduling der Cockpit -Crew testeten.

^[20] Für eine detailliertere Einführung in die allgemeine Systemtheorie siehe z.B. Krieger (1998). Die Systemtheorie wird in dieser Arbeit als Konzeptualisierungsmuster betrachtet, übereinstimmend Zelewski et al. (2001), S. 212.

^[21] Vgl. Schütte (1998), S. 37-40.

^[22] Das funktionale Konzept der Systemtheorie ist abzugrenzen von der funktionalen Organisa­tion eines Unternehmens („Taylorismus“), die sich von der prozessorientierten Organisa­tion dadurch unterscheidet, dass bei der funktionalen Organisation primär die Strukturen der Aufbauorganisation und Funktionshierarchien, bei der prozessorientierten Organisation dagegen primär die Prozessstrukturen betrachtet werden.

^[23] Vgl. Krieger (1998), S. 14-17.

^[24] Schütte (1998), S. 59. Vgl. auch Schütte (1997), S. 1. Dieser Arbeit liegt damit insb. die Annahme zugrunde, dass es keine reale Problemsituation gibt, die ohne das erkennende Subjekt das Ergebnis des Modellbildungsprozesses determiniert. Damit wird das Verständ­nis von Modellen als Abbilder der Realität explizit abgelehnt und Modelle statt dessen als Konstruktionen des Modellierers aufgefasst. Davon abweichend z.B. Sinz (1996), S. 125 f.

^[25] Vgl. Schütte (1998), S. 63.

^[26] Schütte (1998), S. 63. Schütte verwendet die Bezeichnung „Informationsmodell“. In dieser Arbeit wird der Begriff „Informationssystem-Modell“ synonym verwendet, da es sich um Informationsmodelle handelt, deren theoretische Grundlage die Systemtheorie ist.

^[27] Vgl. Jaeschke (1996), S. 4.

^[28] Jaeschke (1996), insb. S. 3, unterscheidet zwischen Ablaufschema, Informationsschema und Organisationsschema. In der hier verwendeten Terminologie ist dies mit Prozess-, Da­ten- und Organisationsstruktur gleichzusetzen, vgl. auch Abbildung 3. Ähnlich Scheer (1998), S. S. 32-38; Scheer trennt jedoch Funktions- und Steuerungssicht, die in dieser Arbeit als „Prozessstruktur“ zusammengefasst sind.

^[29] Schütte (1998), S. 99.

^[30] Die Organisationsstruktur bezieht sich auf die Struktur der Aufbauorganisation.

^[31] Vgl. Schütte (1998), S. 99.

^[32] Vgl. Oberweis (1996a), S. 178-186.

^[33] Für eine informale Einführung in Petrinetze siehe Reisig (1985), für eine formale Ein­füh­rung siehe Reisig (1991); für eine anwendungsorientierte Einführung siehe Baumgarten (1990). Für die Dissertation von Petri siehe Petri (1962). Diese Dissertation ist z.B. in der Universitäts-Bibliothek Bonn archiviert und kann dort eingesehen werden.

^[34] Der Titel kann als Kommunikation von Menschen mit Automaten oder als Kommunikation zwischen Menschen mit Hilfe von Automaten verstanden werden.

^[35] Vgl. Petri (1962).

^[36] Vgl. Rozenberg (1991).

^[37] Vgl. Oberweis (1996a), S. 98.

^[38] Vgl. Aalst (1996), insb. S. 188 f.

^[39] Oberweis (1996a), S. 176.

^[40] Gruhn/Kampmann (1996), S. 383.

^[41] Für einen Überblick über den Einsatz von Petrinetzen für die Modellierung von Prozessstruk­turen im akademischen Bereich siehe Janssens et al. (2000), insb. S. 3 f. Für ein detailliertes Stärken/Schwächen-Profil für Petrinetze siehe Zelewski (1996), insb. S. 373.

^[42] Für einen ausführlichen Überblick über auf Petrinetzen basierende Software für die Model­lierung von Prozessstrukturen siehe Salimifard/Wright (2001), S. 669-673. Als Beispiele können das niederländische Unternehmen Pallas Athena BV mit der Software „Protos“, vgl. Protos (o.D.), das deutsche Unternehmen Promatis AG mit der Software „INCOME Processdesigner“, vgl. Income (o.D.), und das deutsche Unternehmen Software-Ley GmbH mit der Software „COSA“, vgl. Cosa (o.D.), genannt werden. In einer weiten Definition können auch ereignisgesteuerte Prozessketten als vereinfachte Form eines Petrinetzes ver­standen werden, vgl. Schütte (1998), S. 99; Langner et al. (1997), S. 480-485. Für Details zu ereignisgesteuerten Prozessketten siehe Scheer (1998), S. 20.

^[43] Vgl. bspw. Income (o.D.).

^[44] Vgl. Reisig (1985), S. 67-75.

^[45] Weiter werden u.a. zeitbehaftete, gefärbte, stochastische und synthetische Petrinetze angebo­ten. Diese Erweiterungen lassen sich jedoch z.T. mit den hier beschriebenen Netzty­pen konstruieren, vgl. Richter (1993), S. 73 f.

^[46] Vgl. Baumgarten (1990), S. 49-76; Reisig (1985), S. 63-65.

^[47] Vgl. Baumgarten (1990), S. 111-116; Reisig (1985), S. 11-25; Reisig (1991), S. 19-33.

^[48] Vgl. Baumgarten (1990), S. 77-110; Reisig (1985), S. 27-35; Reisig (1991), S. 70-85.

^[49] Vgl. Baumgarten (1990), S. 193-222; Reisig (1985), S. 37-61; Reisig (1991), S. 132-145.

^[50] Vgl. Reisig (1985), S. 63-65.

^[51] (S ´ T) und (T ´ S) bezeichnen jeweils das kartesische Produkt aus S und T bzw. T und S.

^[52] Für weitere, allgemein bekannte Petrinetz-Definitionen siehe Anhang: Petrinetz-Definitio­nen (S. 85-90). Diese Definitionen wurden Reisig (1985), Reisig (1986), Baumgarten (1990) und Oberweis (1996a) entnommen und an die hier verwendete Notation angepasst.

^[53] Präziser wäre hier an den Stellen des Netzes die Verwendung der Beschriftungen „Informatio­nen über Flugdurchführung vorhanden“, „Informationen über verfügbare Flug­zeuge vorhanden“ und „Crewanforderung vorhanden“. Zur besseren Vergleichbarkeit wur­den aber die Beschriftungen aus Abbildung 4 beibehalten.

^[54] Vgl. Oberweis (1996a), S. 105-109.

^[55] Ein Attribut darf nur die Ausprägung „Pilot“ oder „Copilot“ annehmen, nicht jedoch die Ausprägung „Pilot, Copilot“.

^[56] Das entspräche dem Vorgehen bei der Normalisierung, wie sie Codd vorschlägt, vgl. Codd (1970), S. 381 f.

^[57] Mit einer Modellierungssoftware könnten solche Inkonsistenzen zwar automatisch erkannt und damit verhindert werden, das Problem künstlicher und unübersichtlicher Modelle wäre damit jedoch nicht gelöst.

^[58] Vgl. Oberweis (1996a), S. 107 f.

^[59] Vgl. Oberweis (1996a), S. 108 f.

^[60] Vgl. Oberweis (1996a), S. 110.

^[61] Vgl. Oberweis (1996a), S. 109 f.

^[62] Vgl. Chen (1977), S. 9 f.

^[63] Vgl. Thalheim (2000), S. 29-54.

^[64] Für die Originalarbeit von Chen siehe Chen (1976) und Chen (1977). Für eine Einführung in die E-R-Modellierung siehe z.B. Rauh/Stickel (1997), S. 37-110, und Thalheim (2000), S. 29-54. Für erweiterte E-R-Techniken siehe Thalheim (2000), S. 55-424. Im Rahmen die­ser Arbeit werden nur für die Thematik relevante Aspekte erläutert.

^[65] Vgl. Chen (1977), S. 17.

^[66] Vgl. Rauh/Stickel (1997), S. 87-101.

^[67] Vgl. Jaeschke (1996), S. 196 f.