Zusammenfassung
In diesem Kapitel werden auf Basis der entwickelten Modellarchitektur die Metamodelle zur Beschreibung betrieblicher Anwendungssysteme inhaltlich präzisiert. Die einzelnen Metamodelle der fachlichen Sichten und der dv-technischen Komponenten werden hier sukzessive entwickelt.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Preview
Unable to display preview. Download preview PDF.
Literatur
Vgl. Kapitel 2.2.2.2.
Auf das Repository als Werkzeug zur Verwaltung von Metadaten und die existierenden Repository-Standards wird in Kapitel 5.2 eingegangen.
Unter dem Begriff Entity-Relationship-Ansatz (E-R-Ansatz) sollen alle Modellierungsansätze zusammengefaßt werden, die auf dem Vorschlag von CHEN (vgl. Chen, 1976, S. 9 ff.) zur einheitlichen Beschreibung von Daten, dem Entity-Relationship-Modell (E-R-Modell), basieren.
Vgl. Habermann/Leymann, 1993, S. 27. Vgl. 224 Eicker, 1991, S. 175.
Vgl. McClure, 1993, S. 177.
Vgl. Kapitel 3.4.1.
Vgl. McClure, 1993, S. 179–180.
Heutige Implementierungen objektorientierter Repositories basieren allerdings immer noch auf relationalen Datenbanken, es erfolgt eine Transformation der objektorientierten Modelle in relationale Strukturen (vgl. McClure, 1993, S. 177). Damit wird zwar die strukturelle Komponente einer objektorientierten Datenbank simuliert, die verhaltensorientierte Komponente fehlt aber weiterhin. Dieses Vorgehen ermöglicht allerdings einen Übergang zu objektorientierten Datenbanksystemen, sobald diese verfügbar sind.
Auf funktionale Anforderungen an ein Repository wird erst in Kapitel 5.2.4 eingegangen.
Vgl. Schäfer, 1993, S. 49 f.
Auf die verschiedenen Varianten des E-R-Modells wird bei der Darstellung der fachlichen Datensicht in Kapitel 3.2.1.1 eingegangen.
Vgl. Kapitel 3.2.1.
Würden alle Konstrukte, die später zur fachlichen Datenmodellierung verwendet werden, auch im Meta-Metamodell eingesetzt, dann würde die Komplexität der graphischen Metamodelle erhöht und dadurch die Übersichtlichkeit und Lesbarkeit der Modelle verringert werden. Deshalb wird die Gesamtzahl der verschiedenen Konstrukte im Meta-Metamodell gegenüber dem Metamodell der Datensicht eingeschränkt.
Vgl. Zehrader, 1989, S. 41 ff. In Abweichung zu ZEHNDER wurden hier für die Beziehungskardinalitäten und die Generalisierungs-/Spezialisierungshierarchien andere Symbole gewählt und die Darstellung der identifikatorischen Abhängigkeiten mit aufgenommen.
Zur detaillierteren Beschreibung der einzelnen Modellierungskonstrukte wird auf das Metamodell der Datensicht in Kapitel 3.2.1 verwiesen.
In Analogie zur Auflösung von Beziehungen im relationalen Datenmodell durch Beziehungsrelationen (vgl. Kapitel 3.4.1) kann auch im Entity-Relationship Modell eine Beziehung über einen zusätzlichen Objekttyp modelliert werden.
Diese werden auch als Komplexität der Beziehung bezeichnet (vgl. Schlageter/Stucky, 1983, S. 50).
Die (1,c,m)-Notation erweitert die von CHEN gewählten Beziehungskardinalitäten 1 und N, um die Konditionalität von Beziehungen darstellen zu können (vgl. Zehrader, 1989, S. 44 f). Ein c (=conditional) drückt aus, daß ein Objekt an der Beziehung beteiligt sein kann, aber nicht sein muß.
In Anlehnung an Dogac/Chen, 1983, S. 360.
Eine Generalisierungs-/Spezialisierungshierarchie ist disjunkt, wenn kein Objekt in mehr als einem spezialisierten Objekttyp vorkommt, andernfalls ist sie überlappend. Sie ist vollständig, wenn jedes Objekt des übergeordneten Objekttyps in mindestens einem untergeordneten Objekttyp enthalten ist. (siehe auch Kapitel 3.2.1.2.1).
Dies ist notwendig, urn das Entity-Relationship-Modell als Meta-Metamodell von dem Entity-Relationship Modell, das als Metamodell zur fachlichen Beschreibung von Daten verwendet wird, begrifflich abzugrenzen. Andernfalls hätten Extension und Intension in diesem Fall dieselbe Bezeichnung: Das Metamodell des Entity-Relationship-Modells zur fachlichen Beschreibung von Daten enthält das Informationsobjekt Objekttyp, nicht
Die Verwendung des E-R-Ansatzes als Meta-Metamodell und als Metamodell der Datensicht führt dazu, daß Intension und Extension der Beschreibung identisch sind. Ein E-R-Modell wird mit Hilfe eines E-R-Modells beschrieben.
In Anlehnung an Chen, 1983, S. 20–22 und Scheer, 1991, S. 102.
Der Grad eines Beziehungtyps bezeichnet die Anzahl der an dem Beziehungstyp beteiligten Objekttypen (vgl. Schlageter/Stucky, 1983, S. 49).
Mögliche Formen sind die 1,N-Notation von CHEN, die (l,c,m)-Notation (vgl. Kapitel 3.1.1) sowie die Min/Max-Notation (s. u.).
Existieren von einem Objekttyp zwei oder mehr Beziehungstypen zu anderen Objekttypen, so wird mit dem Konstrukt der Exlusivität dargestellt, daß ein Objekt zu einem Zeitpunkt immer nur eine dieser Beziehungen eingehen kann (Vgl. Barker, 1989, S. 7–8 ff.)
Vgl. Kapitel 3.1.1.
Vgl. Scheer, 1991, S. 97–105. Das hier dargestellte Modell wählt SCHEER zur Modellierung der fachlichen Datensicht im Architekturmodell ARIS. Es weicht von seinem E-R-Modell früherer Arbeiten in Beziehungskardinalitäten und Erweiterungen ab (vgl. Scheer, 1988a, S. 20–28).
Vgl. Zehnder, 1989, S. 41 ff.
Ähnlich auch die Ansätze von ORACLE (vgl. Barker, 1989, S. 3–1 ff.), LEHNER et al. (vgl. Lehner et al., 1991, S. 438–441) sowie Gutzwiller, 1994a, S. 128 ff.
Vgl. Sinz, 1993, S. 81–90.
Vgl. Wiborny, 1991, S. 82 ff.
CHEN hat 1977 in Erweiterung seines Grundmodells die Unterscheidung zwischen identifikatorischer und existenzieller Abhängigkeit eingeführt (vgl. Chen/Knöll, 1991, S. 42–46). Durch die existenzielle Abhängigkeit läßt sich zumindest auf der 1-Seite einer 1:N-Beziehung wie bei der (1,c,m)-Notation die Unterscheidung zwischen einer „kann“ und einer „muß”-Beziehung machen.
SINZ und WIBORNY verwenden zwar eine Min/Max-Notation, unterscheiden aber nur die 4 Beziehungsarten der 1,c,m-Notation (vgl. Sinz, 1993, S. 82 und Wibomy, 1991, S. 85).
Vgl. Schlageter/Stucky, 1983, S. 50. In Abweichung zu SCHLAGETER/STUCKY wird die Notation hier objekt-und nicht beziehungszählend verwendet. In einer beziehungszählenden Notation wird für jeden Objekttyp angegeben, in wievielen Beziehungen ein Objekt vorkommen kann. In binären Beziehungen sind die Kardinalitäten der objekt-und beziehungszählenden Notation vertauscht.
Vgl. Rauh/Stickel, 1992, S. 349 f.
In Anlehung an Barker, 1989, S. 7–15. Vgl. 258 Chen, 1976, S. 18.
Durch Angabe von (1,1) als Beziehungskardinalität des starken Objekttyps wird ausgedrückt, daß jeder schwache Objekttyp genau einem starken zugeordnet sein muß.
Bei einer 1:1-Beziehung sind die Primärschlüssel des starken und schwachen Objekttyps identisch, bei einer 1:N-Beziehung wird der Primärschlüssel des starken Objekttyps in dem schwachen Objekttyp um ein oder mehrere Attribute ergänzt.
Bei der Modellierung der identifikatorischen Abhängigkeit sind die an dem Beziehungstyp beteiligten Objekttypen in einer bestimmten Ordnung anzugeben. Der Beziehungstyp ist immer von dem starken zum schwachen Objekttyp gerichtet. Die Kardinalität des starken Objekttyps ist mit (1,1) vorbestimmt.
Siehe Kapitel 3.4.1.
Zur Modellverdichtung siehe Kapitel 3.2.1.2.4.
Vgl. Kapitel 3.2.1.1.
Diese Bezeichnung wurde aus Gründen der Vereinfachung gewählt. Gemeint ist damit das Konstrukt der Generalisierungs-/Spezialisierungshierarchie. Als Spezialisierung werden häufig auch die spezialisierten Objekttypen bezeichnet. Diese werden hier untergeordnete Objekttypen oder Subtypen genannt.
Netzstrukturen in der Hierarchie sind somit ausgeschlossen (vgl. Coad/Yourdon, 1994, S. 112). Das hier dargestellte Metamodell schießt einen Zyklus in der Hierarchie nicht aus, d. h., ein übergeordneter Objekttyp könnte der eigenen Spezialisierung untergeordnet werden. Zyklen sind unzulässig, auch wenn diese Bedingung mit den Konstrukten des Meta-Metamodells nicht dargestellt werden kann.
Vgl. Sinz, 1988, S. 201, Zehnder, 1989, S. 69 f. und Kung, 1990, S. 119.
Vollständige und disjunkte Spezialisierungen werden auch als Generalisierungshierarchien bezeichnet, während in den anderen Fällen von Subtypenhierarchien gesprochen wird (vgl. Sinz, 1988, S. 201 f.). Möglich wäre noch eine zusätzliche Unterscheidung zwischen permanent und temporär disjunkten Spezialisierungen. Temporär disjunkt ist eine Spezialisierung, wenn ein Objekt im Laufe der Zeit zu verschiedenen Subtypen gehören kann, zu einem bestimmten Zeitpunkt jedoch immer nur zu einem Subtypen. Bei einer permanent disjunkten Spezialisierung ist die Zugehörigkeit dagegen unveränderlich (vgl. Ploenzke, 1989, S. 31 f.). Im ersten Fall werden mit Hilfe der Spezialisierung mögliche Zustände eines Objekttyps modelliert. Auf diese Problematik wird im Rahmen der Modellierung von Zuständen eines Objekttyps in Kapitel 3.2.3.2.1 noch eingegangen.
In Anlehnung an Spitta, 1989, S. 112 f.
Vgl. Meyer, 1991, S. 760.
Dies schließt nicht aus, daß Vorgangsobjekttypen aus Gründen der Revisionsfähigkeit oder Archivierungspflicht längerfristig im System verweilen.
Vgl. Spitta, 1989, S. 113 sowie Wedekind, 1976, S. 180. Vgl. 273 Kapitel 4.2.1.1.
Diese Angabe ist durch die Kardinalität des Beziehungstyps u. U. vorgegeben: Ist der Beziehungstyp nicht optional, d. h., ist die minimale Kardinalität größer als Null, so muß jedes Objekt eine Beziehung eingehen. Der Anteil ist dann 100 Prozent.
Minimal-und Maximalwert sind durch die Beziehungskardinalität bestimmt. Über den Durchschnittswert läßt sich auf die Gesamtzahl der vorkommenden Beziehungen schließen.
Siehe Kapitel 3.4.1.
Große Datenvolumina können bei Verarbeitungsfunktionen zu einer langen Verarbeitungsdauer führen. Um solche Funktionen im Dialogbetrieb zu realisieren, sind dann effiziente Algorithmen erforderlich.
So ist die Wahl der Darstellungsform von Objekttypen auf der Benutzeroberfläche u. a. vom Men gengerüst abhängig. Existieren zu einem Objekttyp nur wenige Objekte und ist kein starkes Wachsturn zu erwarten, dann ist eine Darstellung einzelner Objekte des Objekttyps in Form von Sinnbildern (Icons) möglich. Gibt es in einer Objektmenge dagegen viele Objekte, dann scheidet diese Darstellungsform aus. Die einzelnen Objekte sind nicht mehr durch unterschiedliche Sinnbilder darstellbar (vgl. Kapitel 4.2.1.2.2).
So bilden z. B. die Attribute Straße, Plz und Ort die Adresse des Objekttyps Kunde. Eine spätere Verwendung dieser Information ist u. a. bei der Gestaltung von Bildschirmmasken durch entsprechende Gruppierung der Eingabefelder möglich.
Der Primärschlüssel wird durch ein Attribut des Informationsobjekts Schlüssel identifiziert.
Die Auswahl der Datentypen im fachlichen Datenmodell erfolgt bei der Modellierung der dv-technischen Ebene in Kapitel 3.3.1.2.1.
Vgl. Schlageter/Stucky, 1983, S. 288.
Vgl. Münzenberger, 1989, S. 59. ZEHNDER spricht von modellinhärenten und modellexternen Konsistenzbedingungen (vgl. Zehnder, 1989, S. 72).
Vgl. Ploenzke, 1989, S. 40 f
Vgl. Münzenberger, 1989, S. 59.
In diesem Fall muß die Redundanz durch das Datenbanksystem kontrolliert werden (vgl. Kapitel 3.3.1.2.4).
Auch als Komplexität bezeichnet (vgl. Schlageter/Stucky, 1983, S. 291). Das Merkmal der Reichweite kann auch für Ableitungen definiert werden.
Vgl. Ploenzke, 1989, S. 41 ff. sowie Schlageter/Stucky, 1983, S. 290 f.
Ihre Zuordnung zu dem Informationsobjekt Projekt wird im nächsten Kapitel dargestellt.
Vgl. Lipeck, 1989, S. 1 ff. Diese werden auch als Zustands-und Übergangsbedingungen bezeichnet (vgl. Schlageter/Stucky, 1983, S. 291).
Vgl. Kapitel 3.3.1.2.3 und 3.3.1.2.4.
Vgl. Oren, 1985, S. 289.
Siehe dazu u. a. Mistelbauer, 1993, S.129 ff., Wibomy, 1991, S. 289 ff. und Teorey et al., 1989, S. 975 ff.
Vgl. Mistelbauer, 1991, S. 290.
Diese werden von einigen Autoren auch als Cluster bezeichnet (vgl. Mistelbauer, 1991, S. 294), sind aber nicht mit den hier im Metamodell dargestellten Clustem zu verwechseln (s. o.).
Vielfach wird auch ein Objekttyp aus der Gruppe als Führungsobjekttyp ausgewählt, um die Gruppe auf der nächst höheren Aggregationsstufe darzustellen (vgl. Mistelbauer, 1991, S. 295.) Dies steht nicht im Widerspruch zu der hier gewählten Modellierung. Da eine freie Begriffswahl für den aggregierten Objekttyp besteht, kann dieser auch mit dem Namen eines ausgewählten Objekttyps der Gruppe bezeichnet werden.
Vgl. Mistelbauer, 1993, S. 166–167.
In Abhängigkeit vom verwendeten Verdichtungsverfahren werden verschiedene Regeln zur Ableitung von Beziehungen benutzt. Bei den einzelnen Verfahren ergeben sich dadurch Unterschiede in der Anzahl und den Kardinalitäten der resultierenden Beziehungen zwischen den aggregierten Objekttypen.
Vgl. Kosiol, 1962, S. 32 f. sowie Nordsieck, 1955, S. 23 ff. Vgl. 300 Kosiol, 1962, S. 43.
Vgl. Kosiol, 1962, S. 46 sowie Bühner, 1989, S. 21. Vgl. 302 Klein, 1990, S. 9.
Vgl. Ortner/Söllner, 1989, S. 88.
Vgl. Gutzwiller, 1994b, S. 104 sowie Färberböck/Gutzwiller/Heym, 1991, S. 45 f.
Vgl. Barker, 1990, S. G1–1 sowie Thoma, 1993, S. 230.
Vgl. Zimmermann et al., 1993, S. 69.
Vgl. Kapitel 3.3.2.
So bei Klein, 1990, S. 9, Scheer, 1991, S. 75 und Färberböck/Gutzwiller/Heym, 1991, S. 45 f.
Vgl. Kapitel 2.3.1.
Vgl. Spitta, 1989, S. 107 f., Kargl, 1989, S. 164 ff. sowie ESPRIT-AMICE, 1993, S. 136 ff.
Vgl. Scheer, 1991, S. 66. Als Beispiel nennt SCHEER die allgemeine Funktion „Verfiigbarkeitsprüfung“, die in die Funktion „Freigabe Fertigungsauftrag” und in die Funktion „Freigabe Arbeitsgang“ eingeht.
Vgl. Scheer, 1991, S. 65.
Vgl. Scheer, 1991, S. 62.
Nur die Funktionen auf oberster Ebene eines Funktionsbaums werden nicht spezialisiert.
In Analogie zu der Zuordnung von Objekttyp und Projekt in Kapitel 3.2.1.2.4.
Diese Frage spielt nicht nur für das Vorgehen bei der Entwicklung des fachlichen Funktionsmodells eine Rolle, sondern bereits hier, weil die Auswahl der Modellierungskonstrukte für die Elementarfunktionen von ihrer Beantwortung abhängig ist.
In Anlehnung an Scheer, 1991, S. 65. Vgl. 318 Scheer, 1991, S. 65.
Als Beispiel sei hier die Elementarfunktion „Auftrag erfassen“ genannt. Die Funktion wird i. d. R. durch mehrere Arbeitsschritte realisiert: Auswahl des Kunden, Erfassen des Auftragskopfs und wiederholtes Erfassen von Auftragspositionen. Aus fachlicher Sicht ist es nicht sinnvoll, den Auftragskopf ohne Positionen zu erfassen, datenbanktechnisch wird man diese Funktion aber nicht als Transaktion realisieren, da zwischen den einzelnen Arbeitsschritten Unterbrechnungen möglich sind. Während man auf dv-technischer Ebene aus Gründen des Parallelbetriebs bestrebt ist, die Transaktionsdauer zu minimieren, spielt die Dauer einer Funktion als Kriterium der fachlichen Aufgabengliederung nur eine untergeordnete Rolle.
Vgl. Ziegler, 1988, S. 233.
Vgl. Spitta, 1989, S. 164.
Vgl. Spitta, 1989, S. 164.
Die Selektionsfunktion „Liste offene Debitorenrechnungen“ kann z. B. Ausgangspunkt für die Objektfunktion „Mahnung erstellen” sein.
Vgl. Spitta, 1989, S. 167.
Vgl. Derigs/Grabenbauer, 1993, S. 92–94.
Als Beispiel wird die Vorgangsfunktion Bestellung genannt, die sich aus den Datenverwaltungsfunktionen „Lieferkonditionen suchen“, „Bestellauftrag anlegen”, „Bestellauftrag ändern“ und „Bestellauftrag drucken” zusammensetzt.
Vgl. Scheer, 1991, S. 63.
Mit der rekursiven N:M-Beziehung Zielstruktur könnten beliebige Graphen dargestellt werden. Die Zielstruktur ist jedoch eine Hierarchie. Deshalb wird jedes Ziel einer Hierarchiestufe zugeordnet. Von der Beziehung wird gefordert, daß Ziele nur durch Ziele niedrigerer Hierarchiestufen unterstützt werden dürfen.
Jede Funktion unterstützt zumindest ein Ziel, da sie sonst sinnlos wäre (vgl. Scheer, 1991, S. 67).
Vgl. Kapitel 4.2.3.
Vgl. Kosiol, 1962, S. 89 ff. sowie Gabler 1984, S. 583.
Rollen werden in Anlehnung an RUPIETTA als Mengen von Stellen mit gleichen Kompetenzen aufgefaßt. Der Begriff versteht sich deshalb hier als Definition organisatorischer Funktionen. (vgl. Rupietta, 1992, S. 29).
Im Metamodell gelten deshalb die folgenden Integritätsbedingungen: Organisatorische Einheiten, die Stellen sind, dürfen keiner anderen organisatorischen Einheit übergeordnet werden, und organisatorische Einheiten, die Rollen sind, dürfen nur Stellen untergeordnet werden und sind selbst keinen anderen organisatorischen Einheiten untergeordnet.
Vgl. Rupietta, 1992, S. 29.
Die Leitungseigenschaft wird in der rekursiven Beziehung Struktur zwischen einer Organisationseinheit und einer Stelle über ein Attribut modelliert.
Die N:M-Beziehung zwischen Akteur und Stelle ergibt sich, da sowohl Stelleninhaber als auch Vertreter über diese Beziehung modelliert werden. Jede Stelle besitzt zwar nur einen Akteur als Stelleninhaber, hat aber u. U. mehrere Akteure als Vertreter.
Zur Vergabe von Zugriffsrechten vgl. Kapitel 3.4.2.
Siehe dazu u.a. Schönthaler/Németh, 1992, S. 43–53 und 200–223.
Modelliert werden hier nur Vor-und Nachbedingungen, die nicht durch die Zustandsmodellierung eines Objekttyps in der Prozeßsicht abgebildet werden (vgl. Kapitel 3.2.3.2.1).
Vgl. Ploenzke, 1989, S. 34 und Beck/Ziegler, 1991, S. 84.
Vgl. Steinbauer, 1990, S. 63.
Vgl. Spina, 1989, S. 166.
Vgl. Österle, 1995, S. 85 ff.
Siehe hierzu Ward/Mellor, 1991 sowie Hatley/Pirbhai, 1993.
Siehe hierzu u. a. Harel, 1987, S. 231 ff. und Shlaer/Mellor, 1992, S. 34 ff.
Vgl. Färberböck/Gutzwiller/Heym, 1991, S. 45.
Ein Charterauftrag meint hier die Anmietung eines Flugzeugs mit Besatzung zur Durchführung einer Flugreise.
Dieses trifft zumindest auf Grundobjekttypen im betrieblichen Anwendungsbereich zu. Für Aufgaben der Prozeßsteuerung ist die Modellierung von zustandsabhängigen Funktionen für Grundobjekttypen dagegen von großer Bedeutung (z. B. bei der Steuerung einer Ampel). Die Darstellung der Zustände erfolgt dort in Form von State-Transition-Diagrammen (vgl. Shlaer/Mellor, 1992, S. 34 ff.).
Objekttypen, die über diese Beziehung einem Zustand zugeordnet sind, müssen ein Subtyp der Spezialisierung des Objekttyps sein, dem dieser Zustand über die Beziehung besitzt zugeordnet ist Es kann sich dabei auch um eine mehrstufige Spezialisierung handeln.
So bietet es sich im obigen Beispiel des Charterauftrags an, die Zustände „erfaßt“ und „angenommen” in einer Spezialisierung des Objekttyps Auftrags abzubilden, da der Objekttyp in beiden Zuständen annähernd die gleichen Attribute besitzt. Im Zustand „zugeteilt“ besitzt der Objekttyp dagegen zusätzliche Beziehungen zu einem zugeteilten Flugzeug und zu der eingeteilten Besatzung.
Ist eine ausgelöste Elementarfunktion interaktiv, so wird die Funktion nur angestoßen, die Ausführung der Funktion obliegt dem Benutzer.
Die Modellierung von Ereignissen dient hier nicht zur Darstellung externer Auslöser, wie z. B. der einer Kundenanfrage, die eine Angebotserstellung auslöst.
Vgl. Scheer, 1991, S. 114.
Vgl. Ploenzke, 1989, S. 30.
Vgl. ANSI/X3/SPARC, 1975. Eine detaillierte Beschreibung dieses Architekturmodells findet sich u. a. bei Schlageter/Stucky, 1983, S. 26–43 und Lockemann/Dittrich, 1987, S. 141–146.
Vgl. Kapitel 2.1.2.2.
Siehe hierzu u. a. Cattell, 1991, Sinz/Amberg, 1992, Kemper/Moerkotte, 1993, und Böhm, 1994.
In einer Marktübersicht aus dem Jahr 1993 waren von 66 Datenbanksystemen nur 8 objektorientiert (vgl. Computerwoche, 1993).
Structured Query Language. Eine Diskussion dieser Sprache und der dazu existierenden Standards erfolgt im nächsten Kapitel.
Die fiinf größten Datenbankhersteller Gupta, Informix, Ingres, Sybase und Oracle beziehen sich bei ihrer Abfragesprache auf SQL-Normen der ISO. Während Informix Konformität zur aktuellen Norm garantiert, beziehen sich die übrigen Hersteller allerdings auf eine ältere Norm (vgl. Backer, 1994, S. 12).
Vgl. Sinz/Amberg, 1992, S. 440.
Zur Diskussion möglicher Datenbankmodelle für Repositories siehe Kapitel 5.2.2.
Irn Gegensatz zum objektorientierten Ansatz dürfen aber aus einer Kapsel heraus keine Beziehungen zu anderen Datenobjekten bestehen, Beziehungen werden weiterhin nur über Primär-und Fremdschlüsselbeziehungen realisiert.
Siehe hierzu Kapitel 3.3.2.2.5.
Unter einem voll objektorientierten Datenbanksystem wird ein System verstanden, das alle Eigenschaften des objektorientierten Paradigmas (Kapselung, Vererbung, Polymorphismus und Nachrichtenorientierung) besitzt. Davon abgegrenzt werden verhaltensmäßig objektorientierte und strukturell objektorientierte Datenbanksysteme. Während letztere komplexe Objekte und Generalisierungs-/Spezialisierungshierarchien unterstützen, werden in verhaltensmäßig objektorientierten Systemen nur die Kapselung von Daten und Funktionen zu Objekten realisiert (vgl. Lockemann, 1991, 179 f.).
Vgl. Lockemann, 1993, S. 81.
Zur Definition des relationalen Modells siehe Codd, 1970, S. 379–382 sowie Date/Darwin, 1992, S. 215–284.
CODD unterscheidet zwischen R-table (Relational table) und table. Nur R-table besitzen die Eigenschaften von Relationen im Sinne des relationalen Modells (vgl. Codd, 1990, S. 17–20). Diese Unterscheidung wird hier nicht übernommen.
Die Entwicklung dieser Sprache erfolgte zwischen 1974 und 1975 (vgl. Melton/Simon, 1993, S. 9).
ANSI X3.135–1986 (vgl. ANSI-SQL86, 1986), von der ISO in der Norm ISO/IEC 9075:1987 übernommen (vgl. ISO-9075, 1987).
Diese Ergänzungen werden als “Integrity Enhancement Feature” (IEF) bezeichnet und finden in den Normen ANSI X3.135–1989 (vgl. ANSI-SQL89, 1989) bzw. ISO/IEC 9075:1989 (vgl. ISO-9075, 1989) ihren Niederschlag. Der 89er Standard differenziert zwischen SQL Level 1 und Level 2, wobei der Level 1 dem Standard von 1986 entspricht und erst Level 2 die Erweiterungen aus 1989 beinhaltet. Im folgenden wird dieser erweiterte Standard kurz als SQL/89 bezeichnet.
ANSI X3.168–1989 (vgl. ANSI-Embedded SQL, 1989).
Verabschiedet als ANSI X3.135–1992 (vgl. ANSI-SQL92, 1992) bzw. ISO/IEC 9075:1992 (vgl. ISO-9075, 1992). Der Standard wird in der Literatur uneinheitlich als SQL2 oder als SQL/92 bezeichnet, beide Bezeichnungen sind jedoch nicht offiziell. Hier wird in Analogie zu den älteren Standards die Bezeichnung SQL/92 gewählt.
Die Einstufung der verschiedenen Befehle in die einzelnen Conformance Level wurde unter anderem nach dem Gesichtspunkt vorgenommen, wie schwer deren Implementierung ist (vgl. Melton/Simon, 1993, S. 13).
Vgl. ISO-ANSI, 1994b. Auf die verschiedenen Formen der Einbettung von SQL in Programmiersprachen wird in Kapitel 3.3.2.1.2 näher eingegangen.
Für Spalten bzw. Tabellen können Rechte für das Einfügen, Ändern und Löschen vergeben werden. Eine Möglichkeit zur Einschränkung von Zugriffsrechten auf bestimmte Datensätze einer Tabelle besteht durch die Definition von Datensichten (vgl. Kapitel 3.3.1.2.2). In diesen können Datensätze der ursprünglichen Basistabelle über Selektionen verborgen werden. Der Benutzer erhält in diesem Fall keine Zugriffsrechte auf die Basistabelle, sondern nur für die Datensicht.
Zur Modellierung der Kompetenzen für Anwendungsfunktionen vgl. Kapitel 3.2.2.2.3. Auf die Realisierung der Zugriffskontrolle wird in Kapitel 3.4.2 eingegangen.
Das Metamodell abstrahiert von einer Datenbankbeschreibung nach dem SQL-Standard, andernfalls käme es dem Systemkatalog einer SQL-Datenbank gleich. Im Systemkatalog (engl.: Information Schema) werden die Datendefinitionen einer Datenbank wiederum selbst in Tabellen beschrieben. Der Systemkatalog stellt damit das Metamodell einer SQL-Datenbank dar. (Die im deutschen übliche Bezeichnung „Systemkatalog“ ist in der Terminologie des SQL-Standards irreführend, da es sich hierbei um ein Schema und nicht um einen Katalog handelt.) Der SQL-Standard definiert auch das Metamodell einer SQL-Datenbank. Er spezifiziert allerdings nur die Tabellen und nicht die einzelnen Attribute des Metamodells (vgl. Date/Darwin, 1993, S. 329–332 sowie Melton/Simon, 1993, S. 371–385).
Diese zweistufige Strukturierung ist historisch gewachsen. Schemata wurden in SQL eingefiihrt, um Namenskonflikte bei der Erstellung von Tabellen durch verschiedene Benutzer zu vermeiden.Der Schemaname war in früheren SQL-Implementierungen mit der Benutzeridentifikation identisch.
Bei der späteren Implementierung in einer relationalen Datenbanksystem ist es dann möglich, eine Datenbank auf genau ein Schema eines bestimmten Katalogs abzubilden.
Die Beschreibung von Datensichten erfolgt im nächsten Kapitel.
Diese Spezialisierung erfolgt im Metamodell attributiv, ist deshalb nicht der graphischen Darstellung zu entnehmen. Der SQL-Standard unterscheidet drei Typen von temporären Tabellen. DATE/DARWIN bezeichnen diese als „declared local“, „created local”, „created global“. Lokal deklarierte Tabellen werden innerhalb eines Moduls deklariert und können nur dort verwendet werden. Die Defintion dieser Tabellen gehört zwar nicht zum Systemkatalog der Datenbank, wird aber trotzdem in den hier modellierten Strukturen beschrieben. Lokal deklarierte temporäre Tabellen sind keiner Datenbank, sondern einem Modul zugeordnet (vgl. Kapitel 3.3.2.2.2). Die anderen temporären Tabellen gehören zu einer Datenbank, da sie von beliebigen Modulen verwendet werden können. Die Unterscheidung zwischen lokal und global dient zur Festlegung der Reichweite. Bei lokalen Tabellen erhält jedes Modul eine eigene Kopie, bei globalen nur jede SQL-Session. Bei letzteren können folglich Module untereinander Daten austauschen (vgl. Date/Darwi, 1993, S. 265–269).
Unter einer SQL-Session wird eine mit dem CONNECT-Befehl hergestellte Verbindung zu der Datenbank verstanden, die so lange bestehen bleibt, bis sie mit dem Befehl DISCONNECT wieder gelöst wird. Von einem Anwendungsprogramm können mehrere Sessions zu derselben Datenbank aufgebaut werden (vgl. Date/Darwin, 1993, S. 47–49).
Die Eigenschaft wird durch ein Attribut des Informationsobjekts Tabelle dargestellt.
Die Regel, nach denen die Spalte abgeleitet wird, wird über Trigger modelliert (vgl. Kapitel 3.3.1.2.4).
Spalten dieses Typs werden im Datenbanksystem nicht erzeugt. Werden sie in anderen Komponenten der Anwendung referenziert, so muß ihr Wert unmittelbar aus einer Ableitungsregel, die zu der Spalte gespeichert wird, erzeugt werden.
Der SQL-Standard sieht die Verwendung der Domänen lediglich optional vor, eine Spalte kann dort direkt einem Datentypen zugeordnet werden. Die hier gewählte Lösung hat den Vorteil, daß man bei der Datendefinition zur konsequenten Verwendung von Domänen gezwungen wird und eine Umgehung dieses Konzeptes nicht möglich ist.
Andernfalls wäre es zweckmäßig, die Werte des Aufzählungstyps als eigenständige Tabelle im Datenbankschema zu modellieren.
Aufzählungstypen sind im SQL-Standard nicht vorgesehen, SQL 3 wird uncodierte Aufzählungstypen als Datentypen unterstützen (vgl. Date/Darwin, 1993, S. 393).
Der Datentyp BOOLEAN wird im SQL/92-Standard noch nicht berücksichtigt. Da dieser Datentyp aber bereits in vielen Datenbanksystemen implementiert ist, wird er hier vorgesehen. Der SQL 3-Standard wird diesen Datentyp unterstützen (vgl. Date/Darwin, 1993, S. 393).
Eine Spalte vom Datentyp BOOLEAN kann im Gegensatz zu der üblichen Verwendung dieses Datentyps in der Programmierung nicht nur zwei, sondern drei Werte annehmen. Der Nullwert repräsentiert den unbekannten Wert. Der Datentyp BOOLEAN unterstützt damit die dreiwertige Logik des relationalen Modells Version 1 (RMNI). Das relationale Modell Version 2 (RM/V2) von CODD unterscheidet sogar vier logische Werte. Beim unbekannten Wert wird zwischen einem z. Zt. unbekannten, aber prinzipiell zuweisbaren Wert (missing-but-applicable) und dem Leerwert bei einem für ein Tupel generell nicht verwendbaren Attribut (missing-and-inapplicable) unterschieden (vgl. Codd, 1990, S. 180–183).
Vgl. Witt/Schwarzer, 1988, S. 331.
Engl.: Updatable. Zu den Bedingungen unter SQL/92 siehe Date/Darwin, 1993, S. 174. Eine ausführliche Darstellung, wann Views aktualisierbar sind, findet sich bei Codd, 1990, S. 293–324.
Hierbei handelt es sich um die nach dem Statement „CREATE VIEW viewname AS“ folgende Defmition.
Ein Werkzeug, das Eingaben in diese Metastrukturen unterstützt, muß in der Lage sein, durch Parsen des SQL-Statements diese Beziehungen abzuleiten.
Vgl. Schlageter/Stucky, 1983, S. 166.
Vgl. Date, 1990, S. 276. Indirekt modellieren Fremdschlüsselbeziehungen aber Beziehungen der realen Welt. Deshalb stellt die Definition von Fremdschlüsseln und insbesondere der referentiellen Aktion (s. u.) auch fachliche Inhalte dar. So z. B. bei der Definition der Handlungsalternative„action an delete“: Darf eine Abteilung gelöscht werden, wenn ihr noch Mitarbeiter zugeordnet sind?
Die Primärschlüsseleigenschaft wird im Metamodell attributiv dargestellt. Im Gegensatz zum relationalen Modell nach CODD schreibt der SQL-Standard die Definition eines Primärschlüssels nicht zwingend vor. Dies erscheint aber für Tabellen, die fachliche Inhalte darstellen, keinesfalls sinnvoll. Nur bei temporären Tabellen und persistenten Tabellen mit rein dv-technischem Inhalt sind Fälle vorstellbar, in denen auf die Definition eines Primärschlüssels verzichtet werden kann. Tabellen ohne Primärschlüssel sind im Sinne des relationalen Modells keine Relationen.
Da die Einhaltung der referentiellen Integrität ohne Programmierung erfolgt, wird diese Art der Integritätssicherung als deklarative RI bezeichnet. Bei einigen Datenbanksystemen müssen die referentiellen Aktionen über Trigger programmiert werden. Dadurch lassen sich zwar auch individuelle Handlungsalternativen realisieren, allerdings werden im Regelfall die oben dargestellten Aktionen benötigt, die dann für jeden Fremdschlüssel einzeln programmiert werden müssen (vgl. Albers, 1994a, S. 296–297).
Diese Handlungsalternative ist erst in SQL 3 vorgesehen.
Eine Darstellung dieser Fälle ist bei Date/Darwin, 1993, S. 399–401 zu finden.
Diese Option ist im SQL-Standard nicht vorgesehen. Es ist aber zweckmäßig, sie in die Datendefinition mit aufzunehmen, da sie sich unmittelbar aus der Beziehungskardinalität des zugrunde liegenden Datenmodells ableiten läßt (vgl. Kapitel 3.4.1).
Zu den Problemen von zusammengesetzten Fremdschlüsseln und partiellen Referenzen siehe u. a. Date/Darwin, 1992, S. 475–482. Die Wirkung der referentiellen Aktionen bei partiellen Fremdschlüsselreferenzen ist bei Date/Darwin, 1993, S. 241–243 dargestellt.
Diese Option ist erst in SQL 3 vorgesehen. Im Gegensatz zu den referentiellen Aktionen besteht hier genau die umgekehrte Kausalität für das auslösende Ereignis: Bei den referentiellen Aktionen löst eine Operation auf der referenzierten Tabelle eine Aktion in der referenzierenden Tabelle aus, bei Pendant ist eine Operation auf der referenzierenden Tabelle Auslöser für die Löschoperation auf der referenzierten Tabelle.
Vgl. Codd, 1990, S. 246.
Wie bereits dargestellt, ist zu beachten, daß im SQL-Standard eine dreiwertige Logik mit den Werten „wahr“, „falsch” und „unbekannt“ verwendet wird. Um eine Integritätsregel zu erfüllen, muß der Ausdruck nicht unbedingt „wahr” sein.
Dies erscheint zweckmäßig, da sonst im Informationsobjekt Schlüsselkandidat die Schlüsselkandidaten nicht vollständig abgebildet werden.
Die betreffende Spalte wird deshalb bei Wertebereich-und Spaltenbedingungen im SQL-Ausdruck nicht über ihren Namen, sondern über das Schlüsselwort VALUE referenziert (vgl. Tabelle 10).
Vgl. Kapitel 3.3.1.2.2.
Diese Bedingung kann mit der zur Verfügung stehenden graphischen Notation nicht im Metamodell dargestellt werden.
Vgl. Reuter, 1987, S. 381 f.
Mit dem SQL-Statement SET CONSTRAINT kann der Status jeder einzelnen Integritätsbedingung geändert werden.
Schlüsselkandidaten, auf die durch einen Fremdschlüssel eine Referenz definiert ist, sind nicht verzögerbar (vgl. Date/Darwin, 1993, S. 203).
Vgl. Reuter, 1987, S. 386.
Dies ist in SQL 3 durch die Optionen BEFORE, AFTER und INSTEAD realisiert. Die letzte Option ist bisher nur von dem ANSI und nicht von der ISO im SQL 3-Standard vorgesehen (vgl. ISO-ANSI, 1994a, S. 533).
Vgl. Date/Darwin, 1993, S. 401–402 sowie ISO-ANSI, 1994a, S. 532–549.
Das folgende Beispiel soll dies veranschaulichen: Der Wert einer abgeleiteten Spalte Rechnungssumme in der Tabelle Rechnung ergibt sich aus der Summe der Werte der Rechnungspositionen dieser Rechnung. Die Berechnung muß immer dann ausgeführt werden, wenn eine Rechnungsposition zu der Rechnung eingefügt (INSERT), gelöscht (DELETE) oder der Wert der Rechnungsposition geändert (UPDATE) wird. In diesem Fall gibt es drei Ereignisse, zu denen die Triggeraktion ausgelöst werden muß.
In diesem Fall wird für die referentielle Aktion im Fremdschlüssel die Handlungsalternative „no action“ definiert. Bei der Änderung bzw. Löschung des Primärschlüssels der referenzierten Tabelle wird ein Trigger ausgelöst, der die Einhaltung der referentiellen Integrität auf eine frei definierbare Art und Weise realisiert.
Siehe Kapitel 3.4.3.
Diese wird auch als „Funktionaler Kern“ (Schönthaler/Németh, 1992, S. 184) oder als „line-ofbusiness (LOB) functions” (Rofrano, 1992, S. 573) bezeichnet.
Vgl. Kapitel 2.3.4.2.
Hierunter fallen imperative Programmiersprachen wie z. B. Pascal, Cobol, Fortran und C, deren Konzept an der Architektur des von-Neumann-Rechners orientiert ist. (vgl. Ludewig, 1993, S. 291). Zur Klassifikation von Programmiersprachen siehe u. a. Zilahi-Szabó, 1988, S. 329 ff.
Vgl. Balzert, 1982, S. 44 ff.
Vgl. Pagel/Six, 1994, S. 156.
Vgl. Parnas, 1972, S. 1056.
Als Maß für die Größe eines Moduls wird häufig eine maximale Anzahl von Programmzeilen oder Statements genannt. Ein Modul soll von einer Person entwickelt werden können (vgl. Pomberger/Blaschek, 1993, S. 52 f.). Die in einem Modul realisierten Teilaufgaben sollten einen starken logischen Zusammenhang (Kohäsion) besitzen. Die Komplexität der Beziehungen zwischen Modulen (Kopplung) soll dagegen möglichst gering sein. Beide Maße konkurrieren miteinander, mit abnehmender Modulgröße steigt die Kohäsion, aber zugleich auch die Kopplung. Als Maß für die Qualität eines Entwurfs kann deshalb die „Differenz“ von Kohäsion und Kopplung gewählt werden (vgl. Pagel/Six, 1994, S. 175–176).
Vgl. Kapitel 2.3.4.1.
Vgl. Balzert, 1982, S. 227.
Vgl. Balzert, 1982, S. 388.
Vgl. Kurbel, 1985, S. 14.
Im SQL/92 ist dazu der JOIN-Operator in den Standard aufgenommen worden. Vorher wurde der Verbund im SELECT-Statement durch die Angabe mehrerer Tabellen in der FROM-Klausel und einer Verknüpfungsbedingung in der WHERE-Klausel realisiert. Es werden verschiedene Join-Typen unterschieden (siehe hierzu Albers, 1994a, S. 298–299).
Für die Mengenoperationen müssen beide Tabellen vom gleichen Grad (Anzahl der Spalten einer Tabelle) sein. Korrespondieren zwei Tabellen nicht vollständig miteinander, so ist auch die Verknüpfung über eine Projektion der Tabellen möglich (vgl. Date/Darwin, 1993, S. 134–138).
I. d. R. ein SELECT-Statement.
Als Navigationsoperationen sind das Positionieren auf den nächsten, vorhergehenden, ersten und letzten Satz sowie der relative und absolute Sprung zu einer angegebenen Satznummer der Ergebnismenge möglich.
Vgl. Kapitel 3.3.1.1.2.
Diese wird als Wirtssprache (host language) bezeichnet. Der SQL/92 Standard sieht als Wirtssprachen ADA, C, COBOL, FORTRAN, MUMPS, PASCAL und PL/1 vor.
Vgl. Kapitel 3.3.2.2.3.
Als Erweiterung des SQL/92 Standards sind in SQL 3 Kontrollstrukturen für SQL-Module vor gesehen. Auf die Möglichkeiten, die sich daraus ergeben, wird in Kapitel 3.3.2.2.5 eingegangen.
Vgl. ODBC, 1992 und ODBC, 1993.
Nach eigenen Angaben repräsentieren die Mitglieder der SAG rund 70 Prozent des Marktes für relationale Datenbanksysteme. Zu den Mitgliedern zählen u.a. Microsoft, DEC, Apple, Sun, Ashton-Tate, Lotus, Oracle, Informix, Sybase und die Software AG (Angaben zum Zeitpunkt der Verabschiedung des Standards, vgl. Gfaller, 1992, S. 7).
Vgl. X/OPEN-SQL, 1991. Diese Spezifikation wurde bei der ISO als Erweiterung von SQL vorgeschlagen und wird wohl weitestgehend als SQL/CLI-Norm übernommen werden. Siehe hierzu auch die Übersicht über die SQL-Standards in Kapitel 3.3.1.1.2.
Vgl. IDAPI, 1993, S. 10. Zu dem Konsortium gehören u. a. IBM, Novell, Borland und Word-perfect.
Vgl. Eisele, 1995, S. 26.
Vgl. Albers, 1994a, S. 302.
Vgl. Neumann, 1992, S. 187.
Als Export werden alle Funktionen, Datentypen und Konstanten eines Moduls bezeichnet, die von anderen Modulen benutzbar sind (vgl. Pagel/Six, 1994, S. 156).
Nach PombergerBlaschek, 1993, S. 57.
Zur Intermodulstruktur zählen nur Aufrufe von Funktionen, die von anderen Modulen exportiert werden. Aufrufe von Funktionen des eigenen Moduls zählen nicht dazu. Die hier dargestellte Beziehung stellt nur eine Verwendungsbeziehung dar. Der konkrete Aufruf in einer Funktion wird in der Intramodulstruktur modelliert (vgl. Kapitel 3.3.2.2.3). Die hier dargestellte Beziehung ist dazu redundant und entfällt deshalb bei der Integration beider Teilmodelle (vgl. Abbildung 49).
Wird z. B. das Hilfsmodul „Fehlerbehandlung“ eines anderen Anwendungssystems wiederverwendet, ist die Intramodulstruktur zwar bekannt, bei der Wiederverwendung im zu entwickelnden Anwendungssystem aber nur die funktionale Schnittstelle des Moduls von Interesse.
Vgl. Kapitel 3.3.2.2.4.
Vgl. Kurbel, 1985, S. 13.
Funktionen ohne Rückgabewert werden im folgenden wie Prozeduren behandelt: ihre Verwendung in Ausdrücken ist nicht möglich, der Aufruf erfolgt durch einen expliziten Befehl.
Die Beschreibung dieser Informationsobjekte folgt im nächsten Kapitel.
Vgl. Pagel/Six, 1994, 205–210.
Vgl. Kurbel, 1985, S. 19.
Vgl. Balzert, 1982, S. 191 sowie Kurbel, 1985, S. 19.
Vgl. Kurbel, 1985, S. 19 f.
Vgl. Horowitz, 1984, S. 118 f. Vgl. 459 Kurbel, 1985, S. 20 f.
Vgl. Kurbel, 1985, S. 22–23 sowie Heuer, 1992, S. 279.
Die Schemadefinition einer Tabelle im relationalen Modell läßt sich in einer Programmiersprache durch den Datentyp TUPEL OF (Attribut 1: Typ 1, Attribut 2: Typ2,Chrw(133), Attribut n: Typ n) und die Relation durch den Typ SET OF(TUPEL OF (Attribut 1: Typ 1, Attribut 2: Typ 2,Chrw(133), Attribut n: Typ n)) darstellen. Als Datentypen der Attribute sind dabei nur elementare Basisdatentypen und keine zusammengesetzten Strukturen zulässig (vgl. Heuer, 1992, S. 277–278). Damit ist das relationale Modell bezüglich der Typkonstruktoren gegenüber Programmiersprachen erheblich eingeschränkt.
Die mengenorientierten Abfrage-und Änderungsoperationen realisieren den Zugriff auf Relationen, nur Attribute, die immer einem Basisdatentyp zugeordnet sind, müssen in Variablen übertragen werden.
Als Beispiel sei die Speicherung einer Rechnung genannt: In einer Datenbank erfolgt die Speicherung üblicherweise durch eine Tabelle Rechnung für die Daten des Rechnungskopfs und eine Tabelle Rechnungsposition fuir die einzelnen Artikelpositionen der Rechnung. Trotz dieser Modellierung handelt es sich bei den Rechnungspositionen nicht um eine Menge, sondern um eine Liste. Eine Verarbeitungsfunktion zur Erfassung einer neuen Rechnung wird die Positionen aus diesem Grund zweckmäßigerweise in einer Liste (Array) zwischenspeichem.
Wie bereits in Kapitel 3.3.1.2.1 dargestellt, sind Tabellen vom Typ „lokal deklariert“, kein Bestandteil des Systemkatalogs der Datenbank, sondern Bestandteil einer Moduldefinition.
Diese Restriktion entfällt in SQL 3 (vgl. Kapitel 3.3.2.1.2).
Unter der Sichtbarkeit einer Variablen versteht man die Möglichkeit, auf die Variable außerhalb ihres direkten Definitionsbereichs (Funktion oder Modul) zuzugreifen und sie zu manipulieren.
Diese Eigenschaft des Informationsobjekts Variable wird im Metamodell attributiv modelliert.
In Programmiersprachen werden für Parameter die Übergabe des Datenwertes (call by value), Übergabe des Namens (call by name) und die Übergabe der Speicheradresse (call by reference) unterschieden (vgl. Horowitz, 1984, S. 202–207). „Call by Value“ entspricht dem Parametertyp INPUT, „Call by reference” dem Parametertyp INPUT/OUTPUT. Der Parametertyp OUTPUT kann in einer Progranuniersprache realisiert werden, indem der Parameter per Referenz übergeben wird. Wird dieser Parameter zu Beginn der Funktion mit dem Nullwert initialisiert, ist gewährleistet, daß ein möglicher Eingabewert sofort überschrieben wird und die Wirkung der Funktion nicht beeinflußt.
Vgl. Balzert, 1982, S. 371–372.
Vgl. Kurbel, 1985, S. 15–18 und Balzert, 1982, S. 372.
Vgl. Nassi/Shneiderman, 1973, S. 16–25.
Struktogramme wurden in der DIN 66 261 genormt (DIN 66 261, 1985). Gegenüber Programmablaufplänen (PAP) besitzen Struktogramme den Vorteil, daß dort die Darstellung von Sprungbefehlen nicht möglich ist (vgl. Schulz, 1988, S. 24 und Denert, 1991, S. 352).
Vgl. Kurbel, 1985, S. 16–17. Vgl. 474 Kurbel, 1985, S. 18.
Könnte ein Block mehreren Blöcken untergeordnet sein, würden die Blöcke keine Baumstruktur, sondern einen gerichteten Graphen darstellen. In diesem Fall könnte ein Block von mehreren Funktionen verwendet werden. Die Wiederverwendung derselben Blöcke in verschiedenen Funktionen ist aber nicht zweckmäßig, da aus Gründen der Übersichtlichkeit die Funktion die kleinste Komponente der Wiederverwendung darstellen soll. Besitzt ein Block die Eigenschaft, daß er von mehreren Funktionen verwendet werden kann, so wird dieser Block als eigenständige Funktion definiert, die dann von den anderen Funktionen aufgerufen werden kann.
Die erste Alternative wird durch die Beziehung zwischen Einfachauswahl und Block, die zweite Alternative durch die optionale Beziehung zwischen Auswahl und Block modelliert (vgl. Abbildung 46).
Zur Modellierung von Ausdrücken vgl. 3.3.2.2.4. Aus Gründen der Übersichtlichkeit wurde im Metamodell auf die graphische Darstellung von Beziehungen zu den Informationsobjekten Ausdruck und Bedingung verzichtet. Auf diese Beziehungen wird nur in der textuellen Beschreibung hingewiesen.
als So z. B. Clipper mit dem CASE-Befehl und PL/I durch die allgemeine Select-Anweisung (vgl. Kurbel, 1985, S. 98).
Die allgemeine Form besitzt zwei Vorteile: Zum einen ist man zur Unterscheidung der einzelnen Fälle nicht auf den Wert eines einzigen Audrucks beschränkt, zum anderen können neben der Gleichheitsoperation auch andere Operatoren verwendet werden (insbesondere die Operationen kleiner/größer). Allerdings besteht damit auch die Gefahr, redundante oder voneinander unabhängige Bedingungen für einzelne Auswahlzweige zu formulieren. Die Ausführung eines Zweiges ist dann abhängig von der Reihenfolge. Nur der erste Auswahlzweig, der die Bedingung erfüllt, wird ausgeführt, unabhängig davon, ob auch noch nachfolgende Zweige ihre Bedingung erfüllen würden.
Diese Form der Mehrfachauswahl ist eine vereinfachte Darstellung von mehrfach geschachtelten Einfachauswahlen (IF Bedingung I THEN Alternative 1 ELSE IF Bedingung 2 THEN Alternative 2 ELSE IF Bedingung 3 THEN Alternative 3Chrw(133)).
Z. B. ein Aufruf in der Form: ReturnCode:= BuchaufKonto(KtoNr, Soll, Haben).
Z. B. die erfolgreiche Ausführung der Funktion bzw. den aufgetretenen Fehler durch Rückgabe eines Fehlercodes.
Aktuelle Parameter, die sich auf einen formalen Parameter vom Typ OUTPUT oder INPUT/OUTPUT beziehen, müssen Variablen sein.
Sogenannter „Inline-Code“. Gründe können u.a. Vereinfachung oder Performancesteigerung durch spezielle Befehle einer Programmiersprache sein.
Vgl. Kapitel 3.3.1.2.2.
Die linke Seite ist dabei optional, da sie für unäre Operatoren nicht benötigt wird.
Siehe hierzu Kapitel 5.3.2.2.
Zur Beschreibung der Datenbankschnittstelle wird jeder SQL-Befehl eindeutig auf eine Funktion abgebildet. Damit unterscheiden sich die hier gewählten Funktionen von denen der SQL-Aufrufschnittstelle, lassen sich aber zur Implementierung auf diese abbilden.
Vgl. Abbildung 46.
Das Modellierungskonzept entspricht dem bei der Abbildung von Datensichten und Integritätsbedingungen in der Datenbankkomponente (vgl. Kapitel 3.3.1.2.2 und 3.3.1.2.3). Das SQL-Statement wird nicht vollständig in den Strukturen des Meta-Metamodells beschrieben, sondern nur die darin enthaltenen Verwendungsbeziehungen. Bei der Verwendung von dynamischem SQL ist dies allerdings nicht möglich, wenn das SQL-Statement erst zur Laufzeit dynamisch aus Variablen zusammengesetzt wird.
Diese Tabelle muß eine Basistabelle oder eine aktualisierbare Datensicht sein.
Vgl. Kapitel 5.3.2.5.
Vgl. Pistor, 1993, S. 90.
Vgl. Jenz, 1993, S. 45.
Zur Beschreibung der Werkzeuge siehe Kapitel 5.3.2.5.
Anwendungssysteme verwenden heute zum Teil mehr als 80% der Rechnerleistung für das Darstellen und die Funktionalität der Benutzerschnittstelle (vgl. Bullinger/Fähnrich/[hines, 1994, S. 5).
Vgl. Kreibohm, 1993, S. 207.
Vgl. Schmitt, 1993, S. 52.
Siehe dazu Ziegler/11g, 1991.
Vgl. Kühme, 1991, S. 77.
Zur begrifflichen Abgrenzung von Benutzer und Anwender siehe Kapitel 4.1.1.
Vgl. Riekert, 1993, S. 13.
Als zulässige Antwortzeiten auf Benutzeraktionen wird hier eine Dauer zwischen 0,1 und 0,3 Sekunden genannt (vgl. Batz/Krömker/Subel, 1991, S. 154).
Vgl. Bullinger/Wagner, 1994, S. B. Dieses Entwurfsprinzip ist Voraussetzung fir die direkte Manipulation. Häufig wird unter dem WYSIWYG-Prinzip nur die weitgehende Übereinstimmung von angezeigten und gedruckten Dokumenten verstanden (vgl. Ziegler/Ilg, 1991, S. 48).
Vgl. Röhrich, 1991, S. 18.
Vgl. Dzida, 1983.
Vgl. Green, 1985.
Vgl. Kühme, 1991, S. 77.
Schmitt, 1993, S. 56.
Schmitt, 1993, S. 56.
Vgl. Simon/Heihnann/Gebauer, 1991, S. 8 f.
Vgl. Röhrich, 1991, 17 f.
Das „Anwendungsprogramm“ in der Terminologie des Seeheim-Modells kann hier mit der Komponente der Verarbeitungsfunktionen gleichgesetzt werden.
Vgl. Röhrich, 1991, S. 18.
Vgl. Greutmann, 1992, S. 56 sowie Schmitt, 1993, S. 57 f.
Vgl. Rauterberg et al., 1994, S. 12 f.
Beispiele hierfür sind das Öffnen, Verschieben, Vergrößern oder Schließen von Fenstern sowie das Positionieren der Eingabemarke auf ein bestimmtes Feld innerhalb einer Eingabemaske durch Maus-Click oder durch Betätigen einer Mnemonic-Taste.
Diese Unterscheidung entspricht der Dreiteilung in dem von BUDDE et al. dargestellten „ModelView-Controller“-Paradigma für Benutzerschnittstellen interaktiver Systeme (vgl. Budde et al., 1992, S. 75 ff.). Der „View” entspricht der Präsentationskomponente, der „Controller“ den Dialogoperatoren und das „Model” den Anwendungsoperatoren.
Der CUA-Standard von IBM wurde 1987 (vgl. CUA, 1987) veröffentlicht und später geändert und erweitert (vgl. CUA, 1989a, 19896 und 1992). Es existieren mehrere Standards für textuelle und graphische Oberflächen. Einen Überblick geben Mainka, 1991 sowie Berry/Reeves, 1992. Im weiteren wird hier nur auf das CUA Workplace Model aus dem Jahre 1991 eingegangen (siehe hierzu auch Berry, 1992).
Vgl. OSF/Motif, 1992, siehe auch Mauri, 1991.
Vgl. OPEN LOOK, 1990, siehe auch Mauri, 1991.
Vgl. Microsoft, 1992.
Einheitliches Aussehen (Look) und Handhabung (Feel) verschiedener Benutzerschnittstellen werden auch als „Look-and-feel“ bezeichnet (vgl. Bullinger/Fähnrich/Thines, 1994, S. 6 sowie Mauri, 1991, S. 65).
So werden im CUA-Standard FEVH- (File, Edit, View, Help) und WOSH-Menübalken (Window, Object, Selected, Help) vorgeschlagen (vgl. Berry, 1992, S. 455–457).
Vgl. Berry, 1992, S. 449.
Z. B. bewirkt das Fallenlassen eines Dokuments auf den Drucker, daß das Dokument gedruckt wird oder das Fallenlassen auf den Papierkorb das Löschen des Dokuments. Der durch ein Sinnbild dargestellte Drucker bzw. Papierkorb stellt in diesem Fall das Werkzeug dar.
Um einen Kunden einer Rechnung zuzuordnen, kann z. B. das Icon des Kunden auf die Eingabemaske für die Rechnung fallen gelassen werden.
Vgl. Bullinger/Fähnrich/Thines, 1994, S. 6.
Vgl. Fähnrich/Ilg/Görner, 1993, S. 89–90.
Vgl. DIN 66 234, 1988.
Vgl. ISO-9241, 1991.
Vgl. Bullinger/Fähnrich/Thines, 1994, S. 6.
Vgl. Fähnrich/Ilg/Görner, 1994, S. 34 f.
Es muß folglich nur festgelegt werden, daß es für jedes Objekt ein Pop-Up Menü gibt, aber nicht, wie es aussieht und wie es aktiviert bzw. bedient wird.
Dies bedeutet nicht, daß solche Funktionen für alle Objekttypen die gleiche Verarbeitungslogik besitzen. Die Verarbeitungslogik, die sich hinter der Funktion verbirgt, kann für jeden Objekttyp unterschiedlich sein.
So kann es in einer Anwendung z. B. beim Erfassen einer Rechnung notwendig sein, die Stammdaten des Kunden oder eine Übersicht über seine bisherigen Umsätze abzurufen. Diese Aktionen sollten parallel zu der begonnenen Aktion ausführbar sein, ohne die begonnene Aktion abbrechen zu müssen (wie es bei Systemen mit interner Kontrolle über einen Menüwechsel üblich ist).
Der CUA-Standard von 1991 löst sich von diesem anwendungsorientierten Konzept der Benutzerschnittstelle. Die Benutzerschnittstelle stellt nur noch einzelne Anwendungsobjekte dar, die beliebig in Container-Objekten zusammengefaßt werden können (vgl. Berry/Reeves, 1992, S. 418–421).
Vgl. Beck, 1993b, S. 88.
Siehe hierzu auch Kapitel 3.4.1.
Vgl. Ziegler/Ilg, 1991, S. 57.
Wird die Funktionsauslösung über das Menü der Anwendung realisert, so gibt es zwei Alternativen: Entweder ändern sich die Menüelemente in Abhängigkeit vom gerade bearbeiteten Anwendungsobjekt, oder die nicht verwendbaren Elemente werden graphisch gekennzeichnet (z. B. grau dargestellt).
Vgl. Kieras/Polson, 1983, Wasserman, 1985, Oberquelle, 1987, S. 96 f. sowie Schönthaler/Németh, 1992, S. 196 f.
Vgl. Budde et al., 1992, S. 74 f.
Die durch diese beide Arten von Interaktionen ausgelösten Abläufe werden als grobe bzw. feine Dialogabläufe bezeichnet. Feine Dialogabläufe beschreiben nur die Zustandswechsel innerhalb eines Dialogbausteins (vgl. Beck/Janssen, 1993, S. 215).
Vgl. Shneiderman, 1992, S. 514 f
In Anlehnung an Janssen, 1993, S. 69–73.
Siehe hierzu Reisig, 1985, S. 5 ff.
Die eingehenden Stellen einer Transition werden zu diesem Zweck attributiv in eine Ordnung gebracht.
Bei Benutzerschnittstellen mit interner Kontrolle sind solche Wechsel nur möglich, wenn diese im Interaktionsgraphen „fest verdrahtet“ sind, d. h. bereits beim Entwurf des Anwendungssystems geplant worden sind. Bei Systemen mit externer Kontrolle können alle möglichen Benutzerinteraktionen, die zum Wechsel eines Interaktionspunkts führen, gar nicht mehr im voraus festgelegt werden.
Die eingehende Stelle ist gleichzeitig auch ausgehende Stelle, beide Pfeile werden zur Vereinfachung zusammengefaßt.
Von JANSSEN als Inkarnation bezeichnet (vgl. Janssen, 1993, S. 70).
Vgl. Jansen, 1993, S. 71 f Es lassen sich anwendungs-und systemmodale Dialoge unterscheiden. In anwendungsmodalen Dialogen ist das Wechseln zu anderen Anwendungen möglich, in systemmodalen nicht.
Diese Bezeichnung erfolgt zur Abgrenzung von den auf fachlicher Prozeßsicht modellierten Ereignissen. Beide stehen in keinem Zusammenhang.
Für jedes Werkzeug bzw. Menüelement ist durch diese Modellierung feststellbar, ob das ihnen zugeordnete Ereignis in einem bestimmten Zustand das Schalten einer Transition bewirkt. Dies ist genau dann der Fall, wenn es sich um ein zulässiges Ereignis handelt und wenn die dem zugehörigen Interaktionsübergang zugeordnete Bedingung erfüllt ist. Nur dann ist das Auslösen dieser Interaktionselemente zweckmäßig. Andernfalls kann das Interaktionselement als inaktiv (grau) dargestellt werden.
Ein Entwicklungswerkzeug muß in der Lage sein, einen Dialogbaustein auf Basis der im Metamodell gespeicherten Beschreibung ausführen zu können (vgl. Kapitel 5.3.2.4).
In Anlehnung an die Unterscheidung zwischen Contents View und Setting View im CUA-Standard (vgl. Berry, 1992, S. 443 f.).
Vgl. Kapitel 3.3.1.2.2.
Die Realisierung von mehreren Maskenseiten in einem Fenster ist mit Hilfe von Registerkarten möglich, über die dann die verschiedenen Seiten angewählt werden können.
Die deutschen Bezeichnungen der Kontrollelemente wurden in Anlehung an POMBERGERBLASCHEK gewählt (PombergerBlaschek, 1993, S. 74 f.).
Zusätzlich muß das Entwicklungswerkzeug um Komponenten zur Ausführung dieser neuen Bausteine ergänzt werden (vgl. Kapitel 5.3.2.3).
Vgl. Kapitel 3.3.2.2.1.
Siehe u. a. Shlaer/Mellor, 1988, S. 47 ff., Markowitz/Shoshani, 1992, Raasch, 1993, S. 288 ff.
Z. B., wenn ein spezialisierter Subtyp attributiv in der Tabelle des Supertypen modelliert wird oder wenn zwei in einer 1:1-Beziehung stehenden Objekttypen in einer Tabelle zusammengefaßt werden.
Wird während der Entwicklung das dv-technische Datenmodell ergänzt, so müssen folglich nur die Tabellen und Spalten in das fachliche Modell abgebildet werden, die vom Typ „fachlich“ sind.
Vgl. u. a. Shlaer/Mellor, 1988, S. 65–69, Kung, 1990 und Sinz, 1993, S. 88–90.
Siehe hierzu Kung, 1990, S. 119 ff.
Vgl. Shlaer/Mellor, 1988, S. 61.
Vgl. Kapitel 3.2.1.2.1.
Dies sei zur Veranschaulichung an einem Beispiel dargestellt: Wird eine N:M-Beziehung durch eine Beziehungsrelation dargestellt, so werden in die Beziehungsrelation zwei Fremdschlüssel aufgenommen. Diese referenzieren die Tabellen, die die an der Beziehung beteiligten Objekttypen darstellen. Die Verhaltensregeln,disallow deletion“ und „disassociate each occurence” des fachlichen Datenmodells lassen sich auf die referentielle Aktion „action an delete=restrict“ bzw. „action an delete=cascades” abbilden. Die Verhaltensregel „delete each occurrence“ kann dagegen nicht durch die Definition einer referentiellen Aktion realisiert werden. Hierzu ist ein Trigger zu definieren, der beim Löschen eines Datensatzes der einen Tabelle alle dazu in Beziehung stehenden Datensätze der zweiten Tabelle löscht.
Das Anwendungssystem setzt sich dann aus mehreren dv-technischen Anwendungen zusammen.
Vgl. Kapitel 3.2.2.2.4.
Bei einer benutzerdefinierten Funktion sind dabei auch alle Operationen der von ihr gerufenen Funktionen zu berücksichtigen. Besitzt die Elementarfunktion einen Dialog, so sind ferner die Verwendungsbeziehungen in Bildschirmmasken und -listen mit einzubeziehen.
Dies kann nur realisiert werden, wenn die Trigger der Datenbank den Aufruf einer Verarbeitungsfunktion erlauben.
Die Ausführung der Funktionen wird dann einem Benutzer übertragen. Unterstützt kann dieser werden, indem alle Elementarfunktionen, die zu demselben Termin ausgeführt werden müssen, über dasselbe Menü aufgerufen werden können.
Author information
Authors and Affiliations
Rights and permissions
Copyright information
© 1995 Springer Fachmedien Wiesbaden
About this chapter
Cite this chapter
Albers, S. (1995). Metamodelle für betriebliche Anwendungssysteme. In: Modellbasiertes Prototyping. DUV: Wirtschaftsinformatik. Deutscher Universitätsverlag, Wiesbaden. https://doi.org/10.1007/978-3-663-12473-3_3
Download citation
DOI: https://doi.org/10.1007/978-3-663-12473-3_3
Publisher Name: Deutscher Universitätsverlag, Wiesbaden
Print ISBN: 978-3-8244-0266-3
Online ISBN: 978-3-663-12473-3
eBook Packages: Springer Book Archive