Erweiterungskonzepte für das aktive Datenbanksystem ARTA · Rheinische Friedrich – Wilhelms – Universität Bonn Institut für Informatik III Erweiterungskonzepte für das aktive

Rheinische Friedrich – Wilhelms – Universität Bonn Institut für Informatik III

Erweiterungskonzepte für das aktive

Datenbanksystem ARTA

Diplomarbeit von

Vincenzo Calí Kalker-Hauptstr.205

D – 51103 Köln Email:[email protected]

Betreuer

Prof. Dr. Rainer Manthey

April 2004

II

III

Eidesstattliche Erklärung:

Ich erkläre hiermit wahrheitsgemäß, daß ich

- die eingereichte Arbeit selbständig und ohne unerlaubte Hilfsmittel angefertigt,

- nur die im Literaturverzeichnis aufgeführten Hilfsmittel benutzt und fremdes

Gedankengut als solches kenntlich gemacht,

- alle Personen und Institutionen, die mich bei der Vorbereitung und Anfertigung

der Abhandlung unterstützt haben, genannt und

- die Arbeit noch keiner anderen Stelle zur Prüfung vorgelegt habe

Ort, Datum

Unterschrift (Vor – und Zuname)

IV

V

Vorwort

Mein Dank gebührt Herrn Prof. Dr. Rainer Manthey für die Empfehlung, mich mit die-sem interessanten Thema zu beschäftigen und die wissenschaftliche Betreuung der Ar-beit. Seine zahlreichen Anregungen und wertvollen Kommentare haben wesentlich zur Verbesserung der Arbeit beigetragen. Außerdem möchte ich meiner Lebensgefährtin Rebecca, die gerade unser Kind austrägt, für ihre tolle Unterstützung danken. Sie ist der treibende Motor in meinem Leben DANKE!!!! ☺

VI

VII

Inhaltsverzeichnis Einleitung 1

Kapitel 1 Aktive Datenbanken 3 1.1 Motivierende Beispiele...................................................................................4 1.2 Regelparadigma..............................................................................................5 1.3 Regelspezifikation ..........................................................................................6

Kapitel 2 Microsoft Access 11 2.1 Architektur von Microsoft Access ...............................................................11 2.2 Komponenten einer Datenbankanwendung..................................................12 2.3 Datenzugriffsschnittstellen...........................................................................28

Kapitel 3 Microsoft Visual Basic 32 3.1 Visual Basic-Entwicklungsumgebung .........................................................32 3.2 Objekte, Eigenschaften und Module ............................................................34 3.3 Visual Basic-Grundlagen .............................................................................36 3.4 API................................................................................................................37

Kapitel 4 SQL:1999 39 4.1 Grundlagen von SQL....................................................................................39 4.2 SQL-Triggersprache.....................................................................................41 4.3 Syntax der SQL-Triggersprache...................................................................41 4.4 Semantik der SQL-Triggersprache...............................................................44

Kapitel 5 ARTA (Active Real Time Access DBS) 46 5.1 Namenskonvention.......................................................................................46 5.2 GUI von ARTA............................................................................................46 5.3 Erweiterungen in ARTA II...........................................................................48

Kapitel 6 Erweiterungen der SQL-Triggersprache 49 6.1 Steuerungskomponenten ..............................................................................49 6.2 Zeitereignisse................................................................................................51 6.3 Syntax der ARTA II-Trigger........................................................................57 6.4 Semantik der ARTA II-Trigger....................................................................60

Kapitel 7 ARTA II 63 7.1 Schichtenarchitektur.....................................................................................64 7.2 Systemarchitektur.........................................................................................65 7.3 Time Event Manager ....................................................................................66 7.4 Trigger Execution.........................................................................................71

Kapitel 8 GUI 75 8.1 ARTA II-Menüstruktur ................................................................................75 8.2 Triggerübersichtsoberfläche.........................................................................77 8.3 Triggereditor.................................................................................................78 8.4 SQL-Statement Terminal .............................................................................82

Zusammenfassung 83 Literaturverzeichnis 85 Anhang 83

VIII

Erweiterungskonzepte für das aktive DBMS ARTA Einleitung

1

Einleitung

„A Trigger is like a genie that you can place inside the da-tabase, to wake up and do your bidding whenever a certain event takes place“ [DCha98].

In dieser Arbeit wird das System ARTA II vorgestellt, das als Präprozessor für das Datenbankverwaltungssystem (DBMS) Microsoft Access dient. ARTA II wurde in Visual Basic implementiert, basiert auf einem in früheren Diplomarbeiten entwi-ckelten aktiven DBMS namens ARTA und steht für „Active Real Time Access Da-tabase System“. Das Microsoft Access-Datenbanksystem wurde um aktive Regeln erweitert, die das passive in ein aktives Datenbanksystem überführen, um auf ein-tretende Situationen geeignet zu reagieren.

Die aktiven Regeln, die in ARTA II verwendet werden, funktionieren nach dem Grundkonzept der ECA-Regeln und werden auch als Trigger bezeichnet. Als Trig-ger (deutsch: Auslöser) bezeichnet man in SQL eine Anweisungsfolge (eine Abfol-ge von Aktionen), die ausgeführt wird, wenn eine verändernde Anweisung auf ei-ner bestimmten Tabelle ausgeführt werden soll. Sie dienen der automatischen, er-eignisgesteuerten Ausführung von SQL-Befehlen. Diese werden vom DBMS aus-gewertet bzw. überprüft, um dann automatisch zugehörige Aktionen auszuführen. Trigger sind ein mächtiges und flexibles Programmierungskonzept. Durch aktive Regeln, kann die Datenbank auf bestimmt eintretende Ereignisse reagieren. Die Ereignisse, die eine aktive Regel auslösen können, sind z.B. Datenbankänderungen (insert, delete oder update) oder das Eintreten eines bestimmten Zeitpunktes.

In SQL sind Trigger erstmals im SQL:1999-Standard eingeführt worden. Die Trig-ger in SQL werden durch die primitiven Datenmanipulationsereignisse insert, up-date und delete ausgelöst. Die ARTA II-Triggersprache hingegen erlaubt es, auch auf Zeitereignisse zu reagieren. Dazu mußte das SQL-Triggerkonzept von SQL:1999 beträchtlich erweitert werden. Außerdem ist eine Erweiterung der SQL-Triggersprache um Steuerungselemente nötig. Die Steuerungselemente eines Trig-gers dienen z.B. der Angabe über den Zustand eines Triggers, also ob dieser akti-viert oder deaktiviert ist. Es kann ein Gültigkeitsintervall für einen Trigger angege-ben werden, um festzulegen, wie lange dieser gültig ist. Bei Erstellen eines Trig-gers wird eine Priorität vergeben, die auch manuell verändert werden kann. Mit ihr kann eine eindeutige Abarbeitungsreihenfolge festgelegt werden. In SQL:1999 ist die Abarbeitungsreihenfolge durch das Erstellungsdatum des Triggers festgelegt und somit nicht so flexibel zu handhaben wie in ARTA II.

Der Zeitereignisaspekt wurde bereits in verschiedenen Arbeiten untersucht, wie in [Modic00] und [Löhr97] und in einigen objektorientierten Datenbankverwaltungs-systemen wie z.B. HiPAC (High Performance Active Database System) oder SAMOS (Swiß Active Mechanism Besed Object-Oriented Active Database Sys-

DB

..

DB DB

Erweiterungskonzepte für das aktive DBMS ARTA Einleitung

2

tems) realisiert. Die periodischen Zeitereignisse, die in ARTA realisiert wurden beruhten auf diese Studien. In ARTA II hingegen wurde ein neues Konzept zur Realisierung der periodischen Zeitereignisse erstellt und umgesetzt.

Die Entwicklung eines aktiven DBMS stellt auch eine besondere Anforderung an die grafische Benutzerschnittstelle (GUI). Mit der in ARTA II neu gestalteten grafischen Benutzeroberfläche wird dem Anwender ein komfortables Werkzeug zur Verfügung gestellt, um Trigger in der erweiterten SQL-Triggersprache zu er-stellen. Schwerpunkt bei der Gestaltung und Implementierung der GUI war es, dem Anwender bei der Erstellung eines SQL-basierten Triggers so zu helfen, daß dieser keinerlei Fehleingaben bezüglich der Syntax tätigen kann. Ein weiterer Schwer-punkt war die Realisierung der Triggerverwaltung und -aktivierung mittels der GUI, so daß der Anwender den Zustand der ARTA-Trigger abrufen und auch än-dern kann. Der wichtigste Aspekt jedoch beruht auf der grafischen Realisierung für die Eingabe und Anzeige der verschiedenen Ereignistypen.

Möchte man direkt SQL-Statements an die Datenbank absetzen, so kann dies über eine Art Terminal realisiert werden. Auch hier soll eine komfortable Verwaltung bereits gespeicherter SQL-Statements über der GUI das Arbeiten erleichtern.

Aufbau der Arbeit

In Kapitel 1 wird eine Einführung in aktive Datenbanken gegeben. Dieses, sowie die folgenden drei Kapitel bilden den Grundlagenteil dieser Arbeit. In Kapitel 2 wird das Datenbankverwaltungssystem Microsoft Access vorgestellt in das ARTA II implementiert wurde. Kapitel 3 stellt die Programmiersprache Microsoft Visual Basic vor, in der ARTA II vollständig programmiert wurde. Die Entwicklungsum-gebung, sowie wichtige Sprachkonstrukte werden hier behandelt. Anschließend wird in Kapitel 4 SQL:1999 kurz vorgestellt. Die Syntax und die Semantik der SQL-Triggersprache sind hier von relevanter Bedeutung, da diese die Basis der ARTA II-Triggersprache bildet. In Kapitel 5 wird das alte ARTA-System vorge-stellt. Anschließend werden die Erweiterungen zum neuen ARTA-System kurz angesprochen, die dann in den folgenden Kapiteln genauer dargestellt werden. Ka-pitel 6 stellt die Erweiterung der ARTA II-Triggersprache vor. Dabei wird auf die neue Syntax und die damit verbundenen semantischen Änderungen der Sprache eingegangen. Kapitel 7 beschäftigt sich mit der ARTA II-System-architektur und Kapitel 8 schließlich mit der Umsetzung der grafischen Benutzerschnittstelle (GUI).

Erweiterungskonzepte für das aktive DBMS Aktive Datenbanken

3

Kapitel 1 Aktive Datenbanken

Aktive Datenbanken

In diesem Abschnitt wird erläutert, was eine aktive Datenbank ist. Nach einer kur-zen Motivation werden die aktiven (ECA)-Regeln eingeführt, welche das grundle-gende Paradigma einer aktiven Datenbank bilden.

Abbildung 1.1: Architektur eines Datenbanksystems

Datenbanksysteme (engl. Database Systems, abgek. DBS) ermöglichen eine integ-rierte Verwaltung aller Daten in einer Organisation. Ein Datenbanksystem besteht aus einer Datenbank und einem Datenbankverwaltungssystem.

Eine Datenbank (engl. Database, abgek. DB) wird als eine Sammlung von Daten, die aus der Sicht des Benutzers zusammen gehören, bezeichnet. Ein Datenbank-verwaltungssystem (engl. Database Management Systems, abgek. DBMS) hat die Aufgabe, die Daten der Datenbank so zu verwalten, daß logische und physische Datenunabhängigkeit, Datenintegrität, Datensicherheit und weitestgehende Redun-danzfreiheit bestehen. [NiJo92]

Eine Datenbank heißt aktive Datenbank, wenn sie, zusätzlich zu den Leistungen passiver Datenbanksysteme, Ereignisse erkennen und automatisch mit vordefinier-ten Aktionen darauf reagieren kann. Dazu benötigt man aktive Regeln, die bei be-stimmten Ereignissen ausgelöst werden. Die Ereignisse, auf die durch aktive Re-geln reagiert werden kann, sind ein wichtiger Bestandteil dieses Kapitels.

Am folgenden vereinfachten Beispiel einer Sekretärin des Prüfungsamtes, die mit Hilfe eines Datenbanksystems über den aktuellen Stand der Abgabefristen für Dip-lomarbeiten Buch führt, soll das aktive Datenbanksystem motiviert werden.

DBMS (Datenbankverwaltungssystem)

DB 1 (Daten-bank)

DBS (Datenbanksystem)

DB 2 (Daten-bank)

DB n (Daten-bank)

Programm 2 …Programm 1 Programm n


4

1.1 Motivierende Beispiele Meldet ein Student seine Diplomarbeit an, so müssen zunächst eine große Anzahl an Bedingungen überprüft werden, wie z.B.:

• hat dieser Student die Zulassung, um eine Diplomarbeit anzumelden? oder

• hat dieser Student schon eine Diplomarbeit angemeldet?

Das Datenbanksystem sollte solche Situationen erkennen und die passenden Regeln auslösen, um mitzuteilen, ob eine Bedingung verletzt wurde. Dies setzt voraus, daß das System automatisch bestimmte Ereignisse, wie das Anmelden einer Diplomar-beit, erkennen und darauf reagieren kann. Mit einem passiven Datenbanksystem können Situationen dieser Art nicht erkannt werden, da ein solches System nicht über aktive Regeln verfügt. D.h. es enthält keine Mechanismen, mit denen Situati-onen erkannt und entsprechende Reaktionen ausgeführt werden können. Um den-noch ein solches Verhalten realisieren zu können, müssen Programme auf Applika-tionsebene geschrieben werden, die mit dem DBS kommunizieren. Dabei treten die zwei folgenden Nachteile ein:

Jedes Anwendungsprogramm, das die Anmeldung einer Diplomarbeit registriert, muß um zusätzliche Prozeduren erweitert werden, die bei einer Anmeldung sämtli-che Regeln der DPO (Diplomprüfungsordnung) überprüft und bei einer Verletzung eine entsprechende Aktion ausführt. Die Aktualisierungen der DB wird somit von Anwendungsprogrammen übernommen, d.h. daß das die aktiven Regeln nicht im Datenbanksystem, sondern in den Anwendungsprogrammen implementiert wurden. Die Nachteile dieser Arbeitsweise werden bei der Änderung einer Regel bewußt. Es entsteht ein sehr hoher Verwaltungsaufwand, da das Ändern einer Regel in allen Anwendungsprogrammen stattfinden muß, die auf die gleiche Datenbank zugrei-fen. Dies setzt wiederum voraus, daß man alle Regeln für alle Anwendungen kennt, da dem Datenbanksystem selbst diese Regeln nicht bekannt sind und es somit den inkonsistenten Zustand nicht erkennen kann. Ein weiterer Nachteil betrifft die Situ-ationserkennung:

Ein Mitarbeiter des Prüfungsamtes möchte über die Überschreitung der Abgabefrist einer Diplomarbeit informiert werden. Diese Situation kann in einem passiven Da-tenbanksystem nur dann erkannt werden, wenn ein Mitarbeiter eine manuelle An-frage oder wenn ein Anwendungsprogramm regelmäßige Anfragen an die Daten-bank tätigt. Dieses Abfragen des Datenbankzustandes nennt man polling. Bei die-sem Verfahren besteht die Gefahr, daß diese Anfragen entweder zu häufig oder zu selten stattfinden. Finden sie zu häufig statt, führt dies zu einer unnötigen Belas-tung des Systems. Geschehen die Anfragen zu selten, so kann es vorkommen, daß die Situation zu spät bemerkt wird und die erforderliche Aktion dadurch zu lange unterbleibt. [DiGa00]

Da in der Datenbank üblicherweise viele Informationen für die Beschreibung von Situationen, die zur Ausführung von Folgeaktionen führen, vorhanden sind, liegt es nahe, das Erkennen von Situationen durch das Datenbanksystem selbst anzustre-ben. Dafür muß das System um eine aktive Komponente erweitert werden. Eine


5

anerkannte Definition des Begriffes aktives Datenbanksystem existiert nicht. Die folgende grobe Definition stammt aus [DiGa00].

Ein Datenbanksystem heißt aktiv, wenn es, zusätzlich zu den üblichen DBS - Fä-higkeiten, in der Lage ist, interessante Situationen in der Datenbank (und wenn möglich darüber hinaus) zu erkennen und als Folge davon bestimmte (ebenfalls definierbare) Reaktionen auszulösen. [DiGa00]

Aus dieser Definition geht hervor, daß ein aktives Datenbanksystem (Active Da-tabase System, abgek. ADBS) die Funktionalität eines passiven Datenbanksystems enthält, das um aktive Regeln erweitert wurde. Das aktive Datenbankverwaltungssystem (Active

Database Management System, abgek. ADBMS) ist die Software für Verwaltung und Benutzung der aktiven Datenbank (Active Database, abgek. ADB). ADBS ist ein ADBMS samt (mindestens) einer ADB. Für ein Datenbanksystem ist die Ei-genschaft „aktiv“ orthogonal zu seinem zugrunde liegenden Datenmodell; demzu-folge kann man von aktiven relationalen Datenbanksystemen sprechen.

Die Definition des aktiven Verhaltens geschieht mit Hilfe der Situations–, Aktions-regeln, die beschreiben, wie beim Eintreten einer bestimmten Situation reagiert werden muß. Als Beispiel soll die oben erwähnte Überprüfung der Fristen zur Ab-gabe einer Diplomarbeit dienen.

• Situation: Die Abgabefrist wurde überschritten.

• Aktion: Erstellung einer E-Mail für den betreffenden Studenten.

Im folgenden Abschnitt werden die Situations-, Aktionsregeln (ECA-Regeln) vor-gestellt.

1.2 Regelparadigma Konventionelle DBMS, wie z.B. Microsoft Access, sind passive DBMS. Bei diesen passiven Systemen werden Datenbankänderungen nur als Reaktion auf eine ausge-löste Operation eines Anwenders oder einer Anwendung ausgeführt. Soll die Da-tenbank aber automatisch auf bestimmte vordefinierte Ereignisse reagieren kön-nen, so muß das passive Datenbankverwaltungssystem um die Möglichkeit erwei-tert werden, zur Laufzeit selbstständig auf eine bestimmte eintretende Situation mit einer festgelegten Aktion reagieren zu können.

Die Situationsüberwachung kann mittels Ereignis-Bedingung-Aktion-Regeln (engl. Event, Condition, Action, abgek. ECA) realisiert werden. Eine ECA-Regel kann als Tripel (E, C, A) modelliert werden, wobei E, C und A die Regelkomponenten wie folgt bezeichnen:

• E: (event), der Ereignisteil spezifiziert das auslösende Ereignis, bei dessen Auftreten die Regel gefeuert wird.


6

• C: (condition), der Bedingungsteil drückt eine Vorbedingung für das Aus-führen der Regel aus. Ereignis und Bedingung spezifizieren eine Situation.

• A: (action), der Aktionsteil enthält den eigentlichen, auszuführenden Code, der die Reaktion auf die eintretende Situation darstellt.

1.3 Regelspezifikation

Im folgenden Abschnitt geht es um die Abgrenzung der drei Komponenten einer Regel. Diese finden sich im Abschnitt Regelausführung wieder.

Ereignisteil Im Ereignisteil einer ECA-Regel können verschiedene Ereignistypen angegeben werden. In diesem Abschnitt soll eine Übersicht über die verschiedenen Ereignistypen in aktiven Datenbanken gegeben werden. Dazu soll zunächst auf das obige Beispiel „Ein Student meldet seine Diplomarbeit an“ eingegangen werden. Das Ereignis das hier eintritt, ist die Anmeldung der Diplomarbeit und entspricht dem Typ der Änderungsereignisse. Das Ereignis könnte sich aber auch auf einen Zeitpunkt beziehen wenn man die Abgabefrist einer Diplomarbeit in Betracht zieht. Das Ereignis könnte lauten: „die Abgabefrist der Diplomarbeit läuft am 09.04.2004 um 10:00 Uhr ab“. Dieses Ereignis entspricht einem Zeitereignistyp.

Diese Ereignisse beschreiben interessante Situationen. Zudem kann eine interes-sante Situation auch durch die Kombination mehrerer anderer Situationen entste-hen. Kommen wir zunächst zu einer groben Definition von Ereignis:

Unter einem Ereignis versteht man das signalisierte Auftreten eines internen oder externen Zustandes in Form eines Zeitpunktes, einer Datenbankoperation oder eines Anwendungssignals. Man unterscheidet in der Regel zwischen einfachen und den zusammengesetzten Ereignissen. [DiGa00]

Unter einem einfachen Ereignis versteht man ein Datenbank- oder ein Zeitereig-nis. Diese Ereignistypen können wiederum in verschiedene Untertypen unterteilt werden. So können Datenbankereignisse in Änderungs- oder Transaktionsereignis-se unterteilt werden. Bei den Zeitereignissen werden die Untertypen relative, abso-lute und periodische Zeitereignisse unterschieden.


7

Ereignisse

Änderungs-ereignisse

Datenbankereignisse

zusammengesetzteEreignisseeinfache Ereignisse

…Transaktions-

ereignisse

end trans

rollback

begin trans

delete

update

insert

Zeitereignisse

periodische Zeitereignisse

absolute Zeitereignisse

relative Zeitereignisse

Ereignisse

Änderungs-ereignisse

Datenbankereignisse

zusammengesetzteEreignisseeinfache Ereignisse

…Transaktions-

ereignisse

end trans

rollback

begin trans

delete

update

insert

Zeitereignisse

periodische Zeitereignisse

absolute Zeitereignisse

relative Zeitereignisse

Abbildung 1.2: Ereignistypen

Mit Änderungsereignissen läßt sich der Zustand einer Datenbank verändern. Das Löschen, Einfügen und Ändern kann mittels der Änderungsoperatoren insert, delete oder update realisiert werden. Zu den Datenbankereignissen gehören aber auch Transaktionsereignisse, die durch Transaktionsbefehle ausgelöst werden (transaction begin, transaction end), sowie z.B. das An- und Abmelden eines Be-nutzers an einer Datenbank. Weitere Datenbankereignisse, die zur Auslösung einer Regel führen können, sind z.B. Aufrufe einer Prozedur oder einer Funktion in einer Datenbankprogrammiersprache.

Zeitereignisse sind weitere atomare Ereignistypen, die zur Auslösung einer Regel führen können. Sie werden in drei Untertypen unterteilt: In periodische (alle 5 Stunden), absolute (am 20.07.2004 um 09:00 Uhr) oder relative Zeitereignisse (alle 2 Stunden nach dem Löschen einer bestimmten Tabelle),

Die atomaren Ereignistypen zählen zu den einfachen Ereignissen. Neben den bisher beschriebenen einfachen Ereignissen, gibt es die komplexen (zusammengesetz-ten) Ereignisse, die aber in dieser Arbeit nicht weiter behandelt werden und des-halb nur vollständigkeitshalber erwähnt werden. Bei zusammengesetzten Ereignis-sen werden zwei oder mehrere atomare Ereignisse mittels der Kompositionsoperatoren Sequenz, Disjunktion, Konjunktion, Negation und Reduk-tion kombiniert. Diese können wiederum aus der Kombination weiterer zusam-mengesetzter Ereignisse bestehen. [Modic00] Ein interessanter Aspekt, was die zusammengesetzten Ereignisse betrifft, ist die Erkennung des Auftretens eines komplexen Ereignisses. Wichtig dabei ist das Erkennen der Reihenfolge für das Eintreten der atomaren Ereignisse. Dazu könnte eine Protokolldatei geführt werden, in welcher der Eintrittszeitpunkt und weitere Parameter verzeichnet werden. Bei der Erkennung zusammengesetzter Ereignisse treten zudem verschiedene Fragen in Bezug auf den Ereignisverbrauch auf.[Modic00]


8

Bedingungsteil Durch die Angabe einer Bedingung kann der aktuelle Datenbankzustand auf be-stimmte Eigenschaften hin überprüft werden. Die Bedingung wird dann ausgewer-tet, wenn die Regel ausgelöst wurde, d.h. wenn das Ereignis eingetreten ist. In eini-gen Systemen ist das Weglassen des Bedingungsteils erlaubt, was zur Folge hätte, daß eine Regel nach Eintritt des auslösenden Ereignisses immer gefeuert würde.

Eine Bedingung kann z.B. eine Datenbankanfrage, ein Datenbankprädikat oder eine Anwendungsprozedur sein.

• Bei einer Datenbankanfrage handelt es sich um eine Anfrage in der zuge-hörigen Anfragesprache, die entweder eine leere oder nicht leere Antwort liefert.

• Bei einem Datenbankprädikat wird ein Datenbankzustand überprüft (z.B. eine WHERE Klausel in SQL). Die am schwersten zu kontrollierenden aber auch ausdrucksstärksten Beschreibungsarten in der Bedingung sind die An-wendungsprozeduren, die analog zu den Datenbankprädikaten einen Bo-ole’schen Wert (TRUE oder FALSE) oder analog zu den Datenbankanfragen leere oder nicht leere Datenmengen zurückgeben.

• Die Anwendungsprozeduren werden in der Anwendungsprogrammier-sprache des zugrundeliegenden Systems in Form von Prozeduren oder Mo-dulen geschrieben.

Aktionsteil Im Aktionsteil wird definiert, wie auf eine bestimmte Situation (Ereignis und Be-dingung) reagiert werden soll. Der Aktionsteil kann aus mehreren Anweisungen bestehen, wie z.B. Datenmanipulationsoperationen, Datenbankbefehlen und An-wendungsprozeduren. Der Aktionsteil wird nach Eintreten eines Ereignisses und nach Erfüllung einer Bedingung ausgeführt.

1.3.1 Regelausführung Bei der Regeldefinition können gewisse Semantiken spezifiziert werden, die bei der Aktionsverarbeitung zu berücksichtigen sind. Beispiele dafür sind, Prioritäten, mit denen eine Verarbeitungsreihenfolge festgelegt werden kann, sowie auch Kopplungsmodi, welche die Ausführung in Bezug auf Transaktionen1 beschreiben. Daneben muß das Ausführungsmodell auch Mechanismen beinhalten, mit denen Probleme, wie die Terminierung und die Reihenfolge der Regelverarbeitung (conflict resolution), behandelt werden. Ein Überblick über solche Konstrukte wird in den folgenden Abschnitten gegeben.

1 Bezeichnung für eine Folge von Datenbankoperationen, die einen bezüglich bestimmter Bedin-gungen zulässigen Übergang von einem zulässigen DB-Zustand wieder in einen zulässigen DB-Zustand bewirkt und nur als Einheit wirksam werden kann.


9

Auslösungszeitpunkte Wird der Aktionsteil einer Regel gefeuert, so kann man in der Datenbank zwei Zeitpunkte beobachten Einmal den Zeitpunkt vor (Pre-Zeitpunkt) und einmal den nach (Post-Zeitpunkt) der Änderung des Datenbankzustandes. Es ist daher bei ei-nem aktiven Datenbanksystem sinnvoll auf beide Auslösezeitpunkte reagieren zu können.

Auslösungsgranularität Da bei der Ausführung von Befehlen häufig auf mehrere Datensätze zugegriffen wird, kann es sinnvoll sein, zwischen zwei verschiedenen Auslösegranularitäten unterscheiden zu können. Instanzorientierte Regeln (instance-oriented) werden für jeden betroffenen Datensatz einmal ausgeführt, während mengenorientierte Regeln (set-oriented) einmal pro Befehl ausgeführt werden, egal auf wie viele Da-tensätze der Befehl zugreift.

Prioritäten Bei der Ausführung einer Regel kann es vorkommen, daß durch ein Ereignis meh-rere Regeln gleichzeitig gefeuert werden. Mit der Angabe einer Priorität für jede Regel, kann eine Konfliktsituation, was die Reihenfolge der Abarbeitung betrifft, vermieden werden.

Reihenfolge Natürlich wäre es schön bei einer Konfliktsituation die Reihenfolge der Verarbei-tung mit anzugeben. Es stellt sich die Frage, ob die gleichzeitig gefeuerten Trigger nacheinander (sequentiell) oder vielleicht sogar nebeneinander (parallel) abgearbei-tet werden sollen. Die sequentielle Lösung könnte mittels Datensperren verwirk-licht werden, während die parallele Lösung entsprechende Funktionalität an das ADBS fordert.

Kopplungsmodi [Mos85] In einem aktiven Datenbanksystem werden Regeln nach Eintritt eines auslösenden Ereignisses gefeuert. Der Zeitpunkt, zu dem diese Regel gefeuert wurde, muß je-doch nicht dem Zeitpunkt der Abarbeitung der Regel entsprechen. Manchmal ist es sinnvoll, die Regelverarbeitung erst am Ende der regelauslösenden Transaktion durchzuführen. Beim Anlegen einer Regel können zwei Arten von Kopplungen angegeben werden. Diese kann entweder zwischen Ereignis und Bedingung (EC-Kopplung) oder zwischen Bedingung und Aktion (CA-Kopplung) angegeben werden. Mit EC-Kopplung wird die zeitliche Beziehung zwischen dem Auftreten eines regelauslösendem Ereignisses (E) und der Auswertung ihrer Bedingung (C) beschrieben. Mit CA-Kopplung wird die zeitliche Beziehung zwischen der Auswer-tung der Bedingung (C) und der Ausführung der Aktion (A) beschrieben. Bei bei-den Kopplungsarten können drei verschiedene Modi angegeben werden. Anhand einer EC-Kopplung sind hier exemplarisch drei Möglichkeiten dargestellt.


10

• Immediate (sofort): die Bedingungsauswertung erfolgt in der gleichen Transaktion unmittelbar nach dem Eintritt des Ereignisses.

• Deferred (verzögert): Die Bedingungsauswertung erfolgt in der gleichen Transaktion, jedoch nach dem letzten Befehl und bevor die Transaktion in die Datenbank festgeschrieben wird.

• Decoupled (getrennt): Die Bedingung wird in einer separaten Transaktion ausgewertet. Es besteht keine Abhängigkeit zwischen den beiden Transakti-onen.

Terminierung In aktiven Datenbanksystemen können Regeln spezifiziert sein, die sich gegensei-tig auslösen. Die Verarbeitung kann daher zu Regelkaskaden führen, da eine Regel eine oder mehrere andere Regeln auslöst und jede dieser Regeln wiederum eine oder mehrere Regeln auslöst usw. Einen Spezialfall dieser Kaskaden stellen Zyklen dar, die eine Regel enthalten, die entweder direkt oder indirekt immer wieder aus-gelöst wird. Ein solches Verhalten kann von den Benutzern gewollt sein. Jedoch muß sichergestellt sein, daß Zyklen immer terminieren. Dieses Problem kann in aktiven Datenbanksystemen auf verschiedene Arten gelöst werden. Eine triviale Lösung besteht darin, daß keine Regeln definiert werden dürfen, die einen Zyklus bilden.

Reihenfolge der Regelverarbeitung (conflict resolution) Mit diesem Begriff wird das Problem der Verarbeitungsreihenfolge bezeichnet. Durch

das Eintreten eines Ereignisses können mehrere Regeln ausgelöst werden, die zu verarbeiten sind. Es stellt sich daher die Frage: „Welche Regel soll zuerst, welche Regel danach usw. ausgeführt werden?“ Dieses Problem muß in aktiven Daten-banksystemen behandelt werden. Eine Möglichkeit besteht darin, daß das System die Regeln in einer willkürlich festgelegten Reihenfolge verarbeitet.

Verbrauch von Ereignissen Wenn eine Regel bearbeitet wird, d.h. ihre Bedingung ausgewertet und/oder ihre Aktion ausgeführt wird, werden die sie auslösenden Ereignisse auf verschiedene Arten behandelt, die als Ereignisverbrauchsmodi (event consumption modes) be-zeichnet werden. Dabei sind zwei Aspekte von Bedeutung. Zum einen, ob die be-arbeiteten Ereignisse ihre auslösende Wirkung auf Regeln beibehalten und zum anderen, falls sie diese verlieren, wann die Wirkung erlischt, d.h. sozusagen das Ereignis verbraucht wird. [ToPy98]

Erweiterungskonzepte für das aktive DBMS Microsoft Access

11

Kapitel 2 Microsoft Access

Microsoft Access - ein relationales DBMS

Microsoft Access (abgek. MS-Access) [MS-A00] ist ein Vertreter der sogenannten relationalen Datenbankverwaltungssysteme (Relational Database Management System, abgek. RDBMS). In einem relationalen Datenbankverwaltungssystem werden Daten als eine Menge von zweidimensionalen Tabellen gespeichert. Die Tabellen bestehen aus einer festen Anzahl von Spalten und einer beliebigen Anzahl von Zeilen. Jede Spalte einer Tabelle repräsentiert ein Attribut des Relationssche-mas und jede Zeile entspricht einer spezifischen Instanz dieses Schemas, also ei-nem Datensatz. Die Daten in diesen Tabellen werden mit Hilfe der strukturierten Anfragesprache SQL (engl. Structured Query Language) manipuliert. SQL ist eine standardisierte Sprache zur Definition und Manipulation von Daten in einer relati-onalen Datenbank.

MS-Access ist für die Verwaltung großer Datenbestände entwickelt worden. Neben dieser Eigenschaft zeichnet sich MS-Access jedoch besonders durch die sehr leicht zu bedienenden Oberflächen aus, die die Bearbeitung und Repräsentation von Da-ten gegenüber den klassischen RDBMS deutlich vereinfacht.

2.1 Architektur von Microsoft Access Das Datenbanksystems Microsoft Access besteht aus drei funktionellen Kompo-nenten:

• Dem Datenbankverwaltungssystem, das die Datenbestände auf der Fest-platte verwaltet.

• Der Benutzeroberfläche, die als Schnittstelle zwischen Anwender und Da-tenbankverwaltungssystem den Zugriff auf die Daten und deren Präsentati-on erlaubt.

• Das VBA-System (Visual Basic for Application), welche die Programmie-rung von eigenen Anwendungen mit eigenen Benutzeroberflächen ermög-licht.

Darüber hinaus wird mit dem Datenbanksystem eine JET-Datenbank-Engine (siehe Unterkapitel 2.2.2) zur Verfügung gestellt, um eine Verbindung zwischen den Da-tenbanken herzustellen. Dieser Datenmanager kommuniziert mit Objektschnittstel-len wie DAO (Data Access Object), ADO (ActiveX Data Objects) und ODBC (Object Database Connectivity). Die JET-Datenbank-Engine ist ein Teil des Microsoft Access Datenbanksystems und liegt in Form von Systemdateien vor, welche über ihre DAO-Objektschnittstelle angesprochen werden. Neben der DAO-Schnittstelle werden ODBC, OLE-DB und in der neuesten Version auch ADO un-terstützt. Die JET-Datenbank-Engine ist somit der Teil des Microsoft Access Da-


12

tenbanksystems, der Daten aus Benutzer- und Systemdatenbanken abruft bzw. dar-in speichert. Sie kann als Datenmanager aufgefaßt werden.

2.2 Komponenten einer Datenbankanwendung Nach dem Start einer neuen MS-Access-Anwendung wird das Datenbankfenster eingeblendet. Es ist das Hauptfenster dieses Systems und stellt die Schaltzentrale dar. Das Datenbankfenster dient der Übersicht über die Anwendungskomponenten. In MS-Access bezeichnet man alles, was benannt werden kann, als Objekt. So be-steht eine Microsoft Accessdatenbank aus verschiedenen Objekten, die man einem bestimmten Objekttyp zuordnen kann. Aus dem Zusammenspiel dieser Objekte wird aus einer Datenbank eine Anwendung erstellt. Die Hauptobjekte einer Access-Datenbank sind Tabellen, Abfragen, Formulare, Berichte, Datenzugriffsseiten, Makros und Module. Im folgenden werden diese Komponenten in einfacher Form vorgestellt, da eine detaillierte Erläuterung den Rahmen der Arbeit sprengen wür-de.

Abbildung 2.1: Datenbankfenster

Alle Daten werden in Tabellen gespeichert. Alle anderen Objekte der Datenbank greifen auf diese Tabellen zu, um die dort gespeicherten Daten bearbeiten, ergänzen, löschen oder anzeigen zu können. Ein Datensatz dieser Tabellen bildet dabei ein Ob-jekt aus der Wirklichkeit ab. Die dazugehörigen Datenfelder enthalten die relevan-ten Eigenschaften des Objekts. Für jede Tabelle kann ein Primärschlüssel (beste-hend aus einem oder mehreren Feldern einer Tabelle) und einem Index (oder meh-

Datenbankkomponenten ausgewählte Registerkarte

Liste der Tabellen in der Datenbank


13

reren Indizes) definiert werden. Der Primärschlüssel dient der eindeutigen Identifi-zierung des Datensatzes und der Index (oder mehrere Indizes) dem schnelleren Zugriff auf diesen.

Abfragen sind Objekte, mit denen eine individuelle Auswahl der Daten aus einer oder mehreren Tabellen ermöglicht wird. Eine Abfrage kann unter Microsoft Ac-cess auf zwei Weisen realisiert werden. Entweder mit SQL-Befehlen in einem spe-ziellen SQL-Ansichtsfenster oder in einem Entwurfsansichtsfenster. In der Ent-wurfsansicht bedient man sich der QBE-Funktion (Query By Example). Die Ab-fragen werden hier mit den Möglichkeiten der graphischen Benutzeroberfläche entworfen. Beim Wechsel in die SQL-Ansicht werden die QBE-Funktionen auto-matisch in SQL-Befehle übersetzt, so daß man beide Möglichkeiten gemeinsam bei der Entwicklung einer Abfrage nutzen kann.

Formulare sind mit die interessantesten Objekte die Microsoft Access zu bieten hat. Sie dienen im wesentlichen der Dateneingabe und Datenanzeige, sowie der Steuerung von Programmausführungen. Ein Formular kann an einer Datenbank-quelle (z.B. an eine Tabelle oder eine Abfrage) gebunden werden, um die Daten benutzergerecht darzustellen und um die Dateneingabe zu kontrollieren. Formulare können als Reaktion auf ein beliebiges Ereignis aufgerufen werden und bieten die Möglichkeit Grafiken und OLE-Objekte (Objekt Linking and Embedding) in ei-nem Formular anzuzeigen (Kapitel 2.2.2).

Berichte ähneln Formularen. Sie dienen jedoch nicht der Datenbearbeitung, son-dern der Datenanzeige. Berichte sind für die Ausgabe auf dem Medium Papier zu-geschnitten. Formulare hingegen sind zugeschnitten auf die Ausgabe der Daten auf Monitoren. Auf Berichte wird hier nicht weiter eingegangen, da sie in ARTA II nicht verwendet werden.

Möchte man die Daten einer Access-Datenbank im Internet oder Intranet anzeigen oder bearbeiten, so kann dies mit Hilfe der Datenzugriffsseiten verwirklicht wer-den. Sie sind in ihrer Zweckbestimmung mit den Formularen und Berichten ver-wandt. Im Gegensatz zu Formularen und Berichten werden Datenzugriffsseiten aber nicht direkt in der Datenbank gespeichert. Wenn in Access eine Daten-zugriffsseite erstellt wird, wird die entsprechende Seite außerhalb der Datenbank-datei gespeichert und in der Datenbankdatei eine Verknüpfung zu dieser externen Datei erstellt. Im Verlauf der Arbeit wird auf diesen Punkt nicht weiter eingegan-gen. [JeRe02]

In einer Datenbank werden unter Umständen bestimmte Aktionen immer wieder ausgeführt. Um diese Vorgänge zu automatisieren, können Makros verwendet werden. Sie dienen der Steigerung der Benutzerfreundlichkeit und stellen im Grun-de eine Liste von Aktionen dar, die nacheinander ausgeführt werden sollen. Prinzi-piell könnten die Aktionen eines Makros auch über Menubefehle in Access ausge-führt werden. Über Makros und Module wird die Intelligenz der Datenbank ent-worfen. Sie sind das fehlende Glied zwischen den einzelnen Objekten der Daten-bank und verbinden diese zu einer leistungsstarken Anwendung. [JeRe02]


14

Ein Modul besteht aus selbstdefinierten Prozeduren oder Funktionen, die in VBA erstellt wurden. Mit Hilfe der Module können Aktionen in mehrere Einzelschritte zerlegt werden. Zudem besteht die Möglichkeit der Fehlerbehandlung, was den wesentlichen Unterschied zu Makros darstellt. Module sind entweder eigenständige Objekte, die von jedem Punkt der Anwendung aus aufgerufen werden können oder Objekte, die unmittelbar mit Formularen oder Berichten verknüpft sind. Der Vor-teil ist, daß sie auf Ereignisse antworten, die im Formular oder Bericht auftreten können. [JeRe02] Der Vollständigkeit halber seien hier die Gruppen in der Gruppenleiste erwähnt (siehe Abbildung 2.1). Bei Gruppen handelt es sich nicht um Datenbankobjekte im strengen Sinne. Verknüpfungen zu Datenbankobjekten können hier angelegt wer-den, um einen schnelleren Zugriff auf diese zu bekommen. Oft benutzte Formulare können in Gruppen hinzugefügt werden, so daß sie stets schnell verfügbar sind. [JeRe02]

Die folgende Abbildung verdeutlicht die Beziehungen zwischen den Objekten von Microsoft Access. Es wurde mit Absicht auf die Datenblattansicht verzichtet, um das Diagramm zu vereinfachen.

Module Funktionen Subroutinen

Makros

Abfragen

Tabellen

Formulare Berichte

Ausführen/Aufrufen

Definieren Formulare, Berichte Abfragen, Tabellen

Öffnen, Format, Filter, Formulare,

Abfragen, Berichte


Abfragen, Berichte

Ausführen (Funktionen)


Öffnen/ Filter

Druck Ansicht Filter

Auslöser Auslöser

Auslöser Auslöser

Datenfluß

Aktion

Module Funktionen Subroutinen

Makros

Abfragen

Tabellen

Formulare Berichte

Ausführen/Aufrufen

Definieren Formulare, Berichte Abfragen, Tabellen


Abfragen, Berichte


Abfragen, Berichte



Öffnen/ Filter

Druck Ansicht Filter

Auslöser Auslöser

Auslöser Auslöser

Datenfluß

Aktion

Datenfluß

Aktion

Abbildung 2.2: Die Hauptobjekte von Microsoft Access und ihre Beziehungen [JoVi96]

Jede Microsoft Access-Anwendung (-Datenbank) speichert die zuvor erwähnten Anwendungskomponenten (Tabellen, Formulare, Abfragen, Berichte, Makros und Module) in einer monolithischen .mdb-Datei (Microsoft Access Database) ab. Es


15

ist allerdings möglich die Tabellendefinitionen (Data Dictionary) und den Datenbe-stand, sowie die Oberfläche in zwei verschiedenen Dateien zu halten. Dies ge-schieht durch eine Funktion, die zur Verknüpfung von Tabellen dient. Bei der Ent-wicklung von ARTA II wurden die Datenbanktabellen und das ARTA II-Datenbanksystem voneinander getrennt, was viele Vorteile mit sich bringt. Mehr dazu in Kapitel 7.

In den folgenden Abschnitten werden die einzelnen zuvor erwähnten Anwen-dungskomponenten vorgestellt. Dabei werden nur die in Bezug auf das ARTA-System relevanten Komponenten erwähnt.

2.2.1 Tabellen Eine Tabelle ist eine Auflistung von Daten zu einem bestimmten Thema, wie z.B. Angaben zu einem Student: Name, Matrikelnummer, Semester. Wie zuvor erwähnt repräsentiert jede Spalte einer Tabelle ein Attribut des Relationsschemas und jede Zeile der Tabelle entspricht einem Tupel der Relation. Ein Datensatz entspricht einem Datenbankzustand.

Entwurfs- und Datenblattansicht Wenn die Struktur oder die Gestaltung der Tabelle verändert werden soll, so ge-schieht dies in der Entwurfsansicht der Tabelle. In dieser Ansicht bezeichnet jede Zeile im oberen Teil des Tabellenfensters ein anderes Feld der Tabelle. Beim Mar-kieren eines Feldes erscheinen im unteren Bereich die Eigenschaften zu diesem Feld. Diese sind unterteilt in „Allgemein“ und „Nachschlagen“.

Abbildung 2.3: Entwurfsansicht einer Tabelle

Liste der Eigenschaften für das aktuelle Feld

Jede Zeile definiert ein Feld der Tabelle

Einstellungen für die Eigenschaften

Schlüsselvergabe


16

In den allgemeinen Feldeigenschaften können Gültigkeitsregeln für die einzelnen Felder angegeben werden. So ist es z.B. möglich bei einem Textfeld die Feldgröße anzugeben. Bei der Verletzung einer Gültigkeitsregel kann eine vordefinierte Mel-dung, die unter Gültigkeitsmeldung formuliert wird, ausgegeben werden. Mit dem Eingabeformat lassen sich Eingabehilfen erstellen. Dazu das Beispiel der Eingabe eines Datums. Wünschenswert wäre, die Eingabe eines Datums ohne Trennpunkte und mit Platzhaltern für Tag, Monat und Jahr (_ _. _ _ . _ _ _ _). Eine weitere hilf-reiche Eigenschaft ist die Formulierung von Gültigkeitsregeln. Diese geben an, welche Anforderungen die Eingabedaten in einem Datensatz, Feld oder Steuerele-ment erfüllen müssen Dazu kann ein Ausdrucksgenerator aufgerufen werden, mit dessen Hilfe sich komplexe Ausdrücke mittels Funktionen, Konstanten und Opera-toren erstellen lassen.

Interessant ist auch die zweite Seite der Feldeigenschaften „Nachschlagen“. Hier kann angegeben werden, wie sich ein Steuerelement verhalten soll, wenn es an die-ses Tabellenfeld gebunden wird. In der folgenden Abbildung sind die Einstellungen für das Tabellenfeld Student_Hauptfach zu sehen. Ein Steuerelement, das mit die-sem Feld in Verbindung steht, bekommt eine Werteliste als Datenherkunft zuge-wiesen. Die Werte der Liste werden durch Semikolon getrennt. In der Datenblatt-ansicht in Abbildung 2.5 wird diese Einstellung sichtbar. Bei der Eingabe eines Hauptfaches wird die Werteliste eingeblendet, um aus ihr einen Eintrag auswählen zu können.

Abbildung 2.4: Zweite Seite der Feldeigenschaften

Schlüsselvergabe Jede Tabelle einer relationalen Datenbank sollte mit einem Schlüsseln versehen werden, um im Regelfall den Zugriff auf die in den Tabellen gespeicherten Daten zu beschleunigen und eindeutig zu machen. Einmal definierte Schlüssel werden von MS-Access automatisch verwendet, sofern es die Anwendung erlaubt. MS-Access ermöglicht es zwei Arten von Schlüsseln in Tabellen zu vergeben:

• Der Primärschlüssel beschleunigt den Zugriff auf die Daten in der Tabelle. Für jede Tabelle sollte ein Primärschlüssel vergeben werden, der eine ein-


17

deutige Identifikation eines jeden Datensatzes in der Tabelle ermöglicht. Unter MS-Access kann der Primärschlüssel aus einem oder mehreren Fel-dern bestehen. Es kann jedoch nur einen Primärschlüssel oder zusammenge-setzten Primärschlüssel in einer Tabelle geben.

• Fremdschlüssel werden von MS-Access automatisch bei der Suche oder bei der Abfrage von Datenbeständen verwendet und können diese Prozesse er-heblich beschleunigen. Unter MS-Access können Fremdschlüssel definiert werden, die aus einem oder bis zu zehn Datenfeldern bestehen.

Bei der Vergabe von Schlüsseln unter MS-Access ist zu beachten, daß deren Pflege während der Bearbeitung von Daten Rechenzeit, Arbeits- und Festplattenspeicher erfordert. Schlüssel sollten daher hauptsächlich für die Felder definiert werden, die häufig bei der Datensuche oder der Sortierung verwendet werden. Für weniger häu-fig auftretende Sortierreihenfolgen sollten Abfragen definiert werden. Zwar benöti-gen diese mehr Zeit als ein Zugriff über Schlüssel, der Zeitbedarf ist jedoch auf einen Zeitpunkt beschränkt. Abfragen werden von MS-Access nicht ständig ge-pflegt und belasten somit den normalen Ablauf weniger als Schlüssel.

In der Datenblattansicht können die Daten einer Tabelle hinzugefügt, gelöscht oder geändert werden. Jeder Datensatz, der erfaßt oder geändert wird, wird automa-tisch gespeichert, sobald der Cursor aus diesem Datensatz herausgenommen wird.

Abbildung 2.5: Datenblattansicht einer Tabelle

Beziehungen Microsoft Access bietet mit dem Beziehungsfenster die Möglichkeit, Beziehungen zwischen einzelnen Tabellen anzugeben. Interessant ist der Aspekt, daß Beziehun-gen ein separates Konzept und nicht Teil des Tabellenentwurfs sind. Das Bezie-hungsfenster kann von der Menüleiste aus geöffnet werden.

Nachdem verschiedene Tabellen zu den einzelnen Themen in der Microsoft Ac-cess-Datenbank angelegt wurden, muß Microsoft Access mitgeteilt werden, wie


18

diese Informationen wieder zusammengeführt werden. Der erste Schritt in diesem Prozeß besteht darin, Beziehungen zwischen ihren Tabellen zu definieren. An-schließend können Abfragen, Formulare und Berichte erstellt werden, um die In-formationen aus verschiedenen Tabellen gleichzeitig anzuzeigen.

Eine Beziehung bezeichnet die Ein- oder Mehrdeutigkeit einer sinnvollen Verknüp-fung von Attributen (Datenfeldern) innerhalb einer oder mehrerer Datentabellen. Eine wichtige Rolle spielen solche Beziehungen vor allem bei der Verknüpfung mehrerer Tabellen zu einem umfassenden Informationspool. Eine solche Verknüp-fung wird in Microsoft Access durch das Einfügen eines eindeutigen Attributes (Datenfeld) aus der Primärtabelle ermöglicht.

Abbildung 2.6: ARTA II-Anwendungsdaten in der Beziehungsansicht

Beziehungstypen Microsoft Access kennt drei Typen von Beziehungen. Die 1:1 (eins zu eins), 1:n (eins zu n) und die n:m (n zu m)Beziehungen.

In der 1:1 Beziehung entspricht ein Attributwert der Primärtabelle genau einem einzigen anderen Attributwert aus der Fremdtabelle. Dies ist die einfachste und klarste Datenbeziehung.

Eine 1:n Beziehung kennt für einen eindeutigen Ausgangswert mehrere andere zugeordnete Werte. Sie gehört zu den häufigsten Typen von Datenbeziehungen. Das wichtigste bei diesem Beziehungstyp ist die klare Identifizierung des eindeuti-gen Ausgangswertes.

Bei einer m:n Beziehung lassen sich mehrere Attributwerte mehreren Werten ei-nes anderen Attributes zuordnen. Diese Art der Beziehung sollte nach Möglichkeit vermieden werden, da bei einer derartig unklaren Beziehungsdefinition kaum ver-


19

nünftige Auswertungen mit den Daten durchgeführt werden können. Häufig kön-nen solche Beziehungen durch zusätzliche Tabellen weiter aufgegliedert und ver-einfacht werden.


20

Referentielle Integrität Microsoft Access bietet die Möglichkeit referentielle Integrität in Tabellen festzu-legen. Dadurch wird sichergestellt, das Beziehungen zwischen Datensätzen gültig sind und die verknüpften Daten nicht versehentlich geändert oder gelöscht werden. Dies dient unter anderem der Aktualisierungsweitergabe und der Löschweitergabe bei Tabellen.

Bei der Löschweitergabe werden beim Löschen eines Datensatzes in der Primär-tabelle ebenfalls alle Detaildatensätze in der Detailtabelle gelöscht.

Bei der Aktualisierungsabfrage wird beim Ändern eines Primärschlüsselwertes in der Primärtabelle der damit übereinstimmende Wert in allen Detaildatensätzen au-tomatisch aktualisiert.

Abbildung 2.7: Fenster zum Einstellen der referentiellen Integrität

Mit der Definition der referentiellen Integrität werden gleichzeitig eine Beziehung und eine Eingabeprüfung definiert. Ist sie erst einmal definiert, so erkennt MS-Access die relationale Verknüpfung dieser Tabellen bei der Neuanlage von Abfra-gen, Formularen und Berichten automatisch. Weiterhin gewährleistet MS-Access die referentielle Integrität nun überall dort, wo Daten bearbeitet werden können. Dies betrifft sowohl Dateneingaben in das Tabellen- und Formularfenster, als auch beispielsweise Aktualisierungsabfragen.

2.2.2 Abfragen Eine Abfrage dient dazu, aus den Tabellen einer Datenbank ausgewählte Felder anzuzeigen und ggf. zu ändern. Man kann also Spalten angeben, die in die Abfrage aufgenommen werden sollen. Außerdem können Kriterien angegeben werden, nach denen die anzuzeigenden Datensätze ausgewählt werden. Dies erzeugt also eine Auswahl unter den Zeilen der Tabellen. Eine Abfrage stellt somit einen Ausschnitt aus der Datenbank dar, der entweder direkt als Datenblatt betrachtet oder als Grundlage für einen Bericht oder ein Formular benutzt werden kann.


21

Der für ARTA II wichtigste Abfragetyp ist die Auswahlabfrage, die der gebräuch-lichste Abfragetyp ist. Sie ruft Daten aus einer oder mehrerer Tabellen ab und zeigt die Ergebnisse in einem Datenblatt an. Dort können die Datensätze nach einer Än-derung direkt aktualisiert werden. Mit einer Auswahlabfrage können auch Daten-sätze gruppiert und Summen, Anzahl, Durchschnittswerte und andere Werte be-rechnet werden. Für die Auswahlabfrage stehen verschiedene Ansichten zur Aus-wahl. Die wichtigsten sind die Entwurfs-, Datenblatt- und SQL-Ansicht.

In der Entwurfsansicht werden mit Hilfe der Tabellen oder abgespeicherten Ab-fragen neue Abfragen formuliert. Im oberen Bereich des Abfragefensters werden die Feldlisten der Tabelle oder anderer Abfragen angezeigt, die in die Abfrage ein-gehen.

Abbildung 2.8: Auswahlabfrage mit Hilfe einer Tabelle (tbl_Student)

Im unteren Bereich des Abfragefensters sieht man das Entwurfsraster. Hier werden alle für die Abfrage verwendeten Felder angezeigt. Hier können Sortier- und Aus-wahlkriterien eingestellt werden.

In der Datenblattansicht wird die Auswertung der Abfrage in Form eines Daten-blattes angezeigt. Es werden alle Daten angezeigt, die aus der Abfrage hervorge-hen. Diese Sicht dient vor allem der Überprüfung der Richtigkeit. So können einfa-che Fehler bei der Erstellung einer Abfrage direkt entdeckt werden. Die Datenblatt-ansicht ähnelt sehr der Tabellenansicht mit dem Unterschied, daß der Anwender nicht unterscheiden kann, ob die Daten aus einer oder mehrerer Tabellen stammen. Auch hier können Daten eingegeben, geändert und gelöscht werden.


22

Abbildung 2.9: Datenblattansicht einer Abfrage

In der SQL-Ansicht wird die SQL-Anweisung, die in der aktuellen Abfrage ver-wendet wird, angezeigt. Wenn eine Abfrage in der Entwurfsansicht formuliert wurde, erstellt MS-Access im Hintergrund die entsprechende SQL-Anweisung. Die meisten Abfrageeigenschaften im Eigenschaftsfenster der Entwurfsansicht besitzen äquivalente Klauseln und Optionen in der SQL-Ansicht. SQL-Anweisungen kön-nen in der SQL-Ansicht bearbeitet und anzeigt werden.

Abbildung 2.10: SQL-Ansichtsfenster

Außer der Auswahlabfrage existieren noch eine Aktualisierungs-, Einfüge-, und Löschabfrage, auf die hier nicht weiter eingegangen wird.

2.2.3 Formulare Ein Formular ist ein Typ von Datenbankobjekt, der hauptsächlich zur Eingabe oder Anzeige von Daten in einer Datenbank verwendet wird. Die meisten Formulare sind an eine Datenquelle gebunden.

Die Datenquelle eines Formulars bezieht sich auf die Felder in den zugrunde lie-genden Tabellen oder Abfragen. Als Datenquelle kann auch eine SQL-Anweisung dienen. Ein Formular muß nicht alle Felder der Datenquelle enthalten, sondern kann auch gefilterte Daten anzeigen.

Wie zuvor erwähnt werden in einem gebundenen Formular alle Daten aus der zugrunde liegenden Datenquelle zur Verfügung gestellt. Zusätzliche Informationen zum Formular, wie z. B. Titel, Datum oder grafische Elemente, sind in dem Ent-wurf des Formulars gespeichert.


23

Entwurfsansicht eines Formulars Möchte man das Design, die Datenquelle oder andere Objekte bezüglich des For-mulars ändern, so muß das Formular in der Entwurfsansicht geöffnet werden, siehe folgende Abbildung.

Eigenschaftsfenster Feldlistenfenster Symbolleiste Toolbox

Schaltfläche Eigenschaft

Schaltfläche Toolbox Formular in EntwurfsansichtSchaltfläche Feldliste

Abbildung 2.11: Das Formular Usys_frm_Trigger_CreateModify in der Enwurfsansicht

Die Toolbox ist das Kontrollzentrum der Formulargestaltung. Mit diesem Werk-zeug werden bei der Erstellung des Formulars alle notwendigen Steuerelemente zur Verfügung gestellt.

Steuerelemente sind Objekte, die im Formular eingebunden werden können, um Daten anzuzeigen, zu verändern oder sogar zu löschen. Außerdem kann man mit Steuerelementen, wie Linien oder Rechtecke, die Formulare grafisch aufbereiten, um z.B. Daten strukturierter darstellen zu können.

Die Feldliste ist ein Fenster, in welchem alle verfügbaren Felder einer zuvor mit dem Formular gebundenen Datenquelle, angezeigt werden können. Per Drag & Drop kann man ein Feldelement in das Formular integrieren. Beim Wechsel von der Entwurfs- in die Formularansicht erscheint dann an dieser Stelle der Inhalt des Feldes der Tabelle.


24

Um die Eigenschaften eines Steuerelementes zu ändern, ruft man das Eigen-schaftsfenster auf. Das Eigenschaftsfenster zeigt immer die Werte für das aktuell ausgewählte Steuerelement im Formularfenster an. Allein durch die immensen Ein-stellungsmöglichkeiten für jedes Steuerelement kann man eine Anwendung erstel-len, ohne auch nur eine einzige Zeile Programmiercode zu schreiben. Über das Ei-genschaftsfenster können sogar Gültigkeitsregeln festgelegt werden, so daß Daten bei der Eingabe direkt auf ihre Richtigkeit hin überprüft werden können. Im Eigen-schaftsfenster findet man den Reiter „Ereignis“, hier können Makros oder Ereig-nisprozeduren hinterlegt werden.

In Formularen und Berichten stellt Microsoft Access über 40 Ereignisse zur Verfü-gung, die Makros oder Ereignisprozeduren2 auslösen können. Ein Ereignistyp für ein Steuerelement könnte z.B. On_Click (bei Mausklick) lauten. Eine entsprechen-de Reaktion auf den Mausklick könnte das Schließen des aktiven Fensters sein. Wichtig zu wissen ist auch die Reihenfolge, mit der Ereignisse abgearbeitet wer-den. Im folgenden ist die Ereignisreihenfolge für ein Formular, vom Öffnen bis zum Schließen, dargestellt.

Open ⇒ Load ⇒ Resize ⇒ Activate ⇒ Current.

So können, z.B. beim Öffnen eines Formulars, VBA-Prozeduren oder Makros aus-geführt werden, bevor das Formular aktiviert und mit Daten gefüllt wird.

Steuerelemente Steuerelemente sind ein wichtiges Hilfsmittel, um z.B. eine Verknüpfung zwischen einem Formular und seiner Datenquelle herzustellen. Der am häufigsten zur Anzei-ge und Eingabe von Daten verwendete Steuerelementtyp ist das Textfeld. Steuer-elemente sind Objekte der grafischen Benutzeroberfläche. Es gibt in MS-Access eine große Anzahl an Steuerelementen, wie z.B. das Textfeld, das Kontrollkäst-chen, die Bildlaufleiste oder die Befehlsschaltfläche. Sie dienen der Steuerung des Programms durch den Benutzer. Mit Hilfe von Steuerelementen können Daten bzw. eine Auswahl von Daten, angezeigt und verändert werden. Ein großer Vorteil ist zudem die Möglichkeit Aktionen im Hintergrund auszulösen. So kann auf be-stimmte Situationen reagiert werden, ohne daß der Benutzer etwas davon erfährt. Ein weiterer Vorteil für die Benutzung von Steuerelementen ist, daß die Lesbarkeit der Benutzeroberfläche deutlich vereinfacht wird.

Microsoft Access enthält folgende Steuerelementtypen, auf die in der Entwurfsan-sicht eines Formulars zugegriffen werden kann: Textfeld, Bezeichnungsfeld, Opti-onsgruppe, Optionsfeld, Kontrollkästchen, Listenfeld, Befehlsschaltfläche, Regis-tersteuerelement, Bild-Steuerelement, Linie, Rechteck sowie benutzerdefinierte

2 Eine Prozedur ist eine Einheit von Microsoft Visual Basic-Code. Sie enthält eine Reihe von Anweisungen und Methoden, die eine Operation durchführen oder einen Wert berechnen.


25

ActiveX-Steuerelemente. Hier werden nur kurz die Text-, Listen-, Kombinations-felder und das Registersteuerelement vorgestellt.


26

Textfelder

Textfelder dienen der Anzeige und Eingabe von Daten einer Datenquelle in einem Formular. Dieser Textfeldtyp wird als gebundenes Textfeld bezeichnet, da es an Daten eines Feldes gebunden ist. Textfelder können auch ungebunden sein. Bei-spielsweise kann ein ungebundenes Textfeld erstellt werden, um das Ergebnis einer Berechnung anzuzeigen oder Benutzereingaben aufzunehmen. Daten in einem un-gebundenen Textfeld werden nicht in einer Tabelle gespeichert.

Listenfelder

Es ist oftmals leichter und schneller einen Wert aus einer Liste auszuwählen, als ihn einzugeben. Dies kann mit Hilfe einer Auswahlliste realisiert werden, die au-ßerdem sicherstellt, daß der Wert, der in ein Feld eingegeben wurde, korrekt ist. Falls auf dem Formular genügend Platz vorhanden ist, um die Liste ständig anzu-zeigen, kann ein Listenfeld verwendet werden. Wenn ein Steuerelement erstellen werden soll, welches eine Liste anzeigen und wenig Platz einnehmen soll, so ver-wendet man ein Kombinationsfeld.

Abbildung 2.12: Listenfeld

Die Liste eines Listenfeldes besteht aus Datenzeilen. In einem Formular kann ein Listenfeld aus einer oder mehreren Spalten bestehen, die mit oder ohne Überschrif-ten angezeigt werden können. Wenn ein mehrspaltiges Listenfeld gebunden ist, speichert MS-Access die Werte aus einer der Spalten in die Datenquelle.

Kombinationsfelder

Ein Kombinationsfeld ist eine Kombination aus Textfeld und Listenfeld und nimmt folglich wenig Platz ein. Neue Werte können über das Kombinationsfeld eingege-ben werden und Werte können aus einer Liste ausgewählt werden. Die Liste eines Kombinationsfeldes besteht aus Datenzeilen. Diese Zeilen wiederum können aus einer oder mehreren Spalten bestehen, die mit oder ohne Überschriften angezeigt werden können.


27

Abbildung 2.13: Kombinationsfeld, das mit allen verfügbaren Tabellen verbunden ist

Registersteuerelemente

Mit diesem Steuerelement kann ein Formular oder ein Dialogfeld erstellen werden, das mehrere Seiten mit je einer Registerkarte enthält. Jede Registerkarte weist da-bei ähnliche Steuerelemente auf, wie z. B. Textfelder oder Optionsfelder. Sobald ein Benutzer auf eine Registerkarte klickt, wird die zugehörige Seite zur aktiven Seite.

Abbildung 2.14: Registerkartensteuerelement

2.2.4 Makros Makros bezeichnen eine Reihe von Aktionen, die zur Automatisierung von häufig vorkommenden Aufgaben erstellt werden. Mit Hilfe von Makrogruppen können mehrere Aufgaben gleichzeitig ausführt werden. Gegenüber Lösungen die mittels VBA erstellt werden, haben Makros mehrere Nachteile. So ist z.B. ein vernünftiges Zusammenspiel der Abfrage genausowenig möglich, wie auf Fehler zu reagieren. Makros sind in ihrer Gestaltung unübersichtlich und lassen sich nicht im nötigen Umfang mit Anmerkungen und Dokumentationen für den Entwickler versehen.

Alle Makrobefehle lassen sich auch mit Visual Basic erstellen, mit dem Unter-schied, daß hier die zuvor erwähnten Einschränkungen nicht vorhanden sind.

Allerdings gibt es zwei Makros, die sinnvoll sein können:

• Ein Autoexec-Makro kann beim Starten der Anwendung einen einzelnen „ÖffnenFormular“-Befehl ausführen. Alles weitere erledigt danach eine Prozedur, die „BeimÖffnen“ des Formulars gestartet wird. Allerdings ist selbst dafür ein Makro nicht unbedingt notwendig; man kann ebenso im Menü 'Extras/Start' ein Formular auswählen, das automatisch gestartet wer-den soll.


28

• Ein Tastaturbelegungs-Makro kann zur individuellen Tastenbelegung ge-nutzt werden. Dazu muß das Makro 'Autokeys' genannt werden.

2.2.5 Module Module [JeRe02] enthalten eine Auflistung von VBA-Deklarationen und -Prozeduren. Mit VBA steht ein wirkungsvolles Instrument zur Verfügung, mit des-sen Hilfe sich komplexe Datenbankanwendungen entwickeln lassen. Generell kann man eine Einteilung der Prozeduren in Subprozeduren und Funktionen vornehmen.

Funktionen geben Werte zurück und können in Ausdrücken verwendet werden. Sie werden mittels der Schlüsselwörter Function und End Function deklariert.

Sub-Prozeduren führen Aktionen aus und liefern keine Werte zurück. Sie werden mittels der Schlüsselwörter Sub und End Sub deklariert.

Funktionen und Sub-Prozeduren werden in Einheiten zusammengefaßt gespeichert. Diese Einheiten werden als Module bezeichnet. Module können aber nicht aufge-rufen oder ausgeführt werden. Vielmehr werden die in diesen Modulen gespei-cherten Sub-Prozeduren und Funktionen aufgerufen. VBA-Code kann in MS-Access auf verschiedene Arten ausgeführt werden. Von besonderer Bedeutung sind dabei die Ereignisprozeduren.

Mittels Ereignisprozeduren kann auf Aktionen, die durch den Benutzer der Da-tenbank ausgeführt werden, reagiert werden. Aufgrund dieser Aktionen treten be-stimmte Ereignisse ein, in denen so genannte Ereignisprozeduren ausgeführt wer-den können. Wenn in Formularen, Berichten oder Steuerelementen eine Ereignis-prozedur erstellt wurde, stellt MS-Access Vorlagen für die Ereignisprozeduren zur Verfügung, die auf etwaige Besonderheiten der einzelnen Ereignisse eingehen. So können zum Beispiel bestimmte Ereignisse rückgängig gemacht werden, jedoch nicht alle Ereignisse. Es muß lediglich der Code hinzugefügt werden, der als Reak-tion auf ein bestimmtes Ereignis ausgeführt werden soll.

Der wesentliche Vorteil der Nutzung von VBA in Modulen gegenüber der Ver-wendung von Makros besteht in der größeren Flexibilität und den weitreichenden Möglichkeiten, die diese Programmiersprache bietet.

2.3 Datenzugriffsschnittstellen Datenzugriffsschnittstellen werden für den Zugriff auf Tabellen und Abfragen be-nötigt. In den folgenden Abschnitten wird eine Übersicht über die verschiedenen Schnittstellen vorgestellt die von Microsoft Access benutzt werden.

2.3.1 Microsoft JET-Datenbank-Engine Die JET-Datenbank-Engine ist ein Teil des MS-Access-DBMS und liegt in Form von Systemdateien vor, welche über ihre Objektschnittstelle DAO (Data Access Object) angesprochen werden. Neben der DAO-Schnittstelle werden ODBC, OLE-DB und in der neuesten Version auch ADO unterstützt. Die JET-Datenbank-Engine ist somit der Teil des MS-Access-DBMS, der Daten aus Benutzer- und Systemda-


29

tenbanken abruft bzw. darin speichert. Sie kann als Datenmanager aufgefaßt wer-den.

2.3.2 ODBC (Object Database Connectivity) ODBC [WiPe] ist ein so genanntes Application Programming Interface (API), also eine Programmierschnittstelle, die einem Programmierer erlaubt, seine Anwendung unabhängig von der verwendeten Datenbank zu entwickeln. Microsoft bietet dazu einen ODBC-Treiber an, welcher die Kommunikation zwischen Programm und Datenbank übernimmt.

Wird Quellcode geschrieben, der auf eine Datenbank zugreifen soll, muß gewöhn-lich eine Sprache verwendet werden, die nur bei dieser speziellen Datenbank funk-tioniert. Wenn zum Beispiel Microsoft Access, MySQL und Oracle Datenbanken unterstützt werden soll, so muß derselbe Programmteil dreimal programmiert wer-den. Wird hingegen ODBC verwendet, so muß nur die ODBC-Sprache anwendet werden, welche eine Kombination aus ODBC-API Funktionsaufrufen und der SQL-Sprache ist.

Der ODBC-Manager findet automatisch heraus, wie er mit der verwendeten Daten-bank kommunizieren muß. Unabhängig vom Datenbanktyp übersetzt er die Anwei-sungen in die Sprache, die der SQL-Server erwartet. Es muß lediglich ein ODBC-Treiber für die Datenbank, die verwendet werden soll, installiert sein.

2.3.3 OLE–DB (Object Linking and Embedding) OLE-DB [AbIt] ist eine Erweiterung von Dynamic Data Exchange (DDE) durch Microsoft und dient ebenfalls zur Verknüpfung von Elementen, wie Text, Bilder, Tabellen oder Sound, in verschiedenen Programmen. Man unterscheidet zwischen zwei Methoden zur Referenzierung von Daten in Dokumenten: Embedding und Linking. Bei Embedding werden die Daten und Programme fest miteinander ver-bunden und in einer einzelnen Datei abgespeichert. Änderungen der externen Daten werden im Gesamtdokument nicht aktualisiert. Die Methode Linking speichert nur eine Referenz auf die entsprechenden Daten, so daß eine Änderung der Daten so-fort im Dokument aktualisiert wird. Wird die Daten-Datei allerdings gelöscht, so fehlen die Informationen im Dokument.

2.3.4 Database Access Objects (DAO) DAO ist ein von Microsoft definiertes Datenbankzugriffsobjekt für den Zugriff auf Datenbanken. Diese Schnittstelle greift auf MS-Access-Datenbanken direkt und schnell über die sogenannte JET-Engine zu. Alle anderen Datenbanken werden über die bekannten ODBC-Treiber angesprochen. Die DAO-Bibliothek ist objekt-orientiert als C++ Klasse implementiert und nur für die 32-Bit-Plattformen Win-dows 9x/2000 und Windows NT, sowie Nachfolger verfügbar. Zum DAO-Toolkit werden aber auch alle notwendigen Systembibliotheken mitgeliefert, so daß diese Schnittstelle auch ohne installiertes Datenbankprodukt genutzt werden kann.


30

Microsoft Access-Datenbanken lassen sich auf einem Rechner, auf dem kein Microsoft Office-Paket installiert ist, erstellen, lesen und schreiben.


31

Die DAO- Features sind

• Zugriff auf Microsoft Access Datenbanken über die schnelle JET-Engine

• Zugriff auf andere DB über ODBC-Treiber

• 32-Bit Applikation

2.3.5 ActiveX Data Objects (ADO)

ADO ist eine Datenzugriffsschnittstelle, die zur Herstellung einer Verbindung, so-wie zum Abfragen, Verändern und Aktualisieren von Daten mit OLE-DB-kompatiblen Datenquellen dient. Diese Datenzugriffsschnittstelle ist ein weiterent-wickelter Nachfolger der Microsoft DAO-Datenbank-Schnittstelle. Im Unterschied zu dieser ist ADO nicht so sehr auf MS-Access-Datenbanken beschränkt (oder auch optimiert). ADO arbeitet für den Zugriff auf Datenbanken mittels eines OLE-DB-Providers. Durch diesen Mechanismus sind Verbindungen zu sehr verschiede-nen Datenbanken möglich, die unter DAO etwa nur mit verknüpften Tabellen in-nerhalb MS-Access realisiert werden können. Jede Datenbank kann, wenn es einen entsprechenden Treiber gibt, nativ, d.h. schnell, und effizient angesprochen wer-den.

Erweiterungskonzepte für das aktive DBMS Microsoft Visual Basic

32

Kapitel 3 Microsoft Visual Basic

Microsoft Visual Basic

Visual Basic, (abgek. VB) ist eine, seit Office 97, in allen Microsoft Office-Anwendungen eingesetzte objektorienterte Programmiersprache, in der auch SQL eingebettet ist. Bei den visuellen Sprachen, wie VB es ist, steht nicht mehr die Ver-arbeitung von Daten im Vordergrund, sondern das Hantieren mit Objekten auf dem Bildschirm. Voraussetzung für die Arbeit mit Objekten ist immer das Vorhanden-sein einer Oberfläche. Visuelle Sprachen manipulieren Objekte, um dem Anwender ein Ergebnis auf dem Bildschirm zu präsentieren, z.B. ein Dialogfeld zur Eingabe von Werten oder Texten. Objekte werden durch Eigenschaften und Aktionen (Me-thoden) gesteuert. Bildschirmaktionen, wie z.B. Mausklick, können Ereignisse aus-lösen. Alle Aktionen mit Objekten werden in die Techniken der klassischen Spra-chen eingebettet. Dazu gehören Variablendeklarationen, Steueranweisungen wie Bedingungsabfragen, Schleifen und Sprünge, Subroutines usw.

3.1 Visual Basic-Entwicklungsumgebung Visual Basic-Programme werden in einer VBA-Entwicklungsumgebung geschrie-ben. Zur Erstellung von Programmen ist eine Programmierumgebung notwendig. Für VBA ist dies der Visual Basic-Editor. Mit den Tastenkombination ALT + F11 gelangt man aus dem Datenbankfenster direkt in die Entwicklungsumgebung. Die Komponenten dieser Umgebung sind der Project Explorer, Visual Basic-Editor, das Eigenschafts- und das Direktfenster (siehe Abbildung 3.1).

Project Explorer Dieses Fenster zeigt alle in einem Projekt verwendeten Module. Microsoft Access unterscheidet zwei Grundtypen von Modulen: Standardmodule und Klassenmodu-le.

Ein Standardmodul ist ein Modul, in das Sub- und Funktionsprozeduren ein-gefügt werden können. Diese Prozeduren sind dann für andere Prozeduren der Datenbank verfügbar. Standardmodule enthalten allgemeine Prozeduren, die nicht mit einem anderen Objekt verbunden sind, sowie häufig verwendete Prozeduren, die von jeder beliebigen Stelle innerhalb ihrer Datenbank aus, ausgeführt werden können. Der wesentliche Unterschied zwischen einem Standardmodul und einem Klassenmodul, das nicht mit einem bestimmten Objekt verbunden ist, liegt im Gül-tigkeitsbereich und in der Lebensdauer. Die Werte von Variablen oder Konstanten, die deklariert sind oder ohne zugeordnetes Objekt in einem Klassenmodul enthal-ten sind, stehen nur dann zur Verfügung, wenn dieser Code ausgeführt wird bzw. sind ausschließlich von diesem Objekt verfügbar. Standardmodule werden auch in Formularen benutzt. Der Unterschied zu den Standardmodulen besteht in ihrem Gültigkeitsbereich. Eine Prozedur oder eine Funktion, die in einem Formularmodul


33

geschrieben wurde, ist auch nur dort bekannt. Formularmodule werden als Microsoft Access-Klassenobjekte bezeichnet.

Ein Klassenmodul ist ein Modul, das die Definition für ein neues Objekt ent-halten kann. Jede Instanz einer Klasse erstellt ein neues Objekt. Jede Prozedur, die in dem Modul definiert wurde, erhält die Eigenschaften und Methoden des Objekts. Klassenmodule können eigenständig oder mit Formularen und Berichten verwendet werden. Diese Funktionalität gibt den Entwicklern eine bessere Kontrolle über den Code der Applikation und macht es einfacher, widerverwendbare Komponenten zu erstellen.

Abbildung 3.1: Die Visual Basic-Entwicklungsumgebung

Eigenschafts-, Direkt- und Überwachungsfenster Das Eigenschaftsfenster hat in der VB-Entwicklungsumgebung eigentlich nichts zu suchen. Es kann lediglich der Modulname vergeben oder geändert werden. Das Direkt- und Überwachungsfenster hingegen sind zwei wichtige Werkzeuge bei der Entwicklung einer Anwendung.

Im Überwachungsfenster kann der eigene Programmcode überwacht werden. Dies geschieht mittels der Ausgabe der aktuellen Werte von ausgewählten Variab-len. Im Menü unter Ansicht kann das Überwachungsfenster geöffnet werden.

Projekt-Explorer Visual Basic-Editor

Direktfenster Eigenschaftsfenster


34

Das Direktfenster zeigt Informationen an, resultierend aus Anweisungen zur Feh-lerbeseitigung im Code oder aus Befehlen, die direkt in dieses Fenster eingegeben wurden. Sowohl das Direktfenster, wie auch das Überwachungsfenster sind ein wichtiges Hilfsmittel bei der Fehlersuche.

Visual Basic-Editor Im Visual Basic-Editor wird der Programmcode geschrieben. Es stehen eine Ob-jekt- und eine Ereignisliste in der Kopfleiste des Editors zur Verfügung. In der Fußleiste kann zwischen Prozedur- und Modulansicht umgeschaltet werden.

Abbildung 3.2: Visual Basic-Editor

3.2 Objekte, Eigenschaften und Module Microsoft Access ist keine vollständige objektorientierte Sprache. Obwohl MS-Access von Objekten „lebt“, fehlt z.B. die Vererbung. Die Vererbung ist ein we-sentliches Merkmal der objektorientierte Programmierung, bei dem ein neues Ob-jekt, durch Änderung oder Verfeinerung des Verhaltens eines vorhandenen Ob-jekts, definiert wird. Leider ist dieses Konzept in Microsoft Visual Basic nicht um-gesetzt worden. So ist die objektorientierte Programmierung in Visual Basic nur beschränkt möglich.

Objektliste Ereignisliste

ModulansichtProzeduransicht


35

Alle MS-Access Objekte verfügen über Eigenschaften und Methoden. Eigen-schaften beschreiben physische Charakteristika eines Objekts. So verfügt das Ob-jekt Formular über die Eigenschaften Namen, Hintergrundfarbe, Höhe, Breite, Rahmen, Beweglichkeit, Sichtbarkeit usw. Methoden sind Dinge, die ein Objekt tun kann. So kann das Objekt Formular geöffnet, geschlossen, vergrößert oder ver-kleinert werden.

Die wesentliche Eigenschaft eines Objektes ist die Einheit von Daten und Metho-den. Nur mit den Methoden, die der allgemeinen Benutzung freigegeben sind, kann man die Daten manipulieren. Man spricht von Datenkapselung. Auf diese Weise kann der Datenzugriff, insbesondere bei großen Projekten, geregelt und weitgehend fehlerfrei gestaltet werden.

Die Definition eines Objektes erfolgt in einer sogenannten Objektklasse, die eine Definition für ein Objekt, einschließlich seines Namens, seiner Eigenschaften und seiner Methoden, sowie aller zugehörigen Ereignisse ist. Meist beinhaltet eine Ob-jektklasse innere, man sagt private oder versteckte, Daten und Prozeduren, auf die der Anwender keinen Zugriff hat, die aber für die Ausführung der Methoden wich-tig sind. VBA sieht verschiedene Möglichkeiten vor, eigene Objekte zu definieren oder objektorientierte Arbeitsweisen zu entwickeln.

Wenn eine Instanz einer Klasse erstellt wird, entsteht ein neues Objekt mit allen durch diese Klasse definierten Merkmalen. Jede innerhalb der Objektklasse defi-nierte öffentliche Prozedur wird eine Methode des benutzerdefinierten Objekts. Die Anweisung Sub definiert eine Methode, die keinen Wert zurückgibt. Die Anwei-sung Function definiert dagegen eine Methode, die einen Wert eines festgelegten Typs zurückgeben kann. Alle Property Let-, Property Get- und Property Set-Prozeduren, die definiert werden, werden zu einer Eigenschaft des neuen Objekts. Property Get-Prozeduren rufen den Wert einer Eigenschaft ab. Property Let-Prozeduren stellen den Wert einer Nicht-Objekteigenschaft ein. Property Set-Prozeduren stellen den Wert einer Objekteigenschaft ein. [MS-Ac00]

Einen weiteren Vorteil bringt das Collection Object. Es stellt ein Objekt dar, mit dessen Hilfe eigene Listenobjekte oder Auflistungen erzeugt werden können. Man kann Objekte hinzufügen, herausnehmen oder ein einzelnes Objekt bearbeiten. Ge-genüber der Anordnung der Daten in einem Datenfeld (Array) haben Collection Objects den Vorteil, die Arraygrößen vorher nicht festlegen zu müssen. Beim Lö-schen von Werten entstehen keine leeren Felder und die Listen können mit einer For-Next-Schleife durchlaufen werden. Außerdem ermöglicht das Collection Ob-ject den Zugriff auf die Listenelemente, sowohl über einen Namen als auch über einen Index.


36

Abbildung 3.3: Definition einer Collection

3.3 Visual Basic-Grundlagen In diesem Abschnitt werden einige Sprachkonstrukte vorgestellt. Dieser Abschnitt soll kein Einstigerkurs in VBA sein, vielmehr soll ein grober Überblick über Pro-zeduren, Bedingungen, Funktionen, Variablen, Datentypen und Konstanten gege-ben werden.

Variablen sind Programmelemente, die während eines Programmablaufes unter-schiedliche Werte annehmen können. Für jede Variable wird Speicherplatz im Ar-beitsspeicher des Computers reserviert. Die Größe des Speicherplatzes wird vom vereinbarten Datentyp der Variablen bestimmt. Variablen werden mit einem Na-men angesprochen. Sie werden mit dem Schlüsselwort Dim eingeleitet, gefolgt von einem Variablennamen und einem Datentyp. Die Standarddatentypen die in MS-Access angegeben werden können sind aus der Abbildung 3.3 zu entnehmen.

Abbildung 3.4: Definition einer Collection

Feste Zahlenwerte im Programmcode sollte man durch Konstanten ersetzen. Bei Änderungen muß dann nur die Konstantenzuweisung geändert werden und nicht die vielen Stellen, wo der Wert auftritt. Konstanten werden in den Deklarationstei-len von Modul und Prozedur vereinbart. Der Wert einer Konstanten läßt sich wäh-rend des Programmablaufes nicht ändern. Er bleibt während des gesamten Pro-grammablaufes erhalten. Eine Konstante wird mit dem Schlüsselwort Const einge-leitet, gefolgt von einem Name für die Konstante und der Zuweisung zu einem Wert.

Typ KZ Erläuterung, Wertebereich Speicher [Byte]

Byte Ganzzahl, 0…255 1 Boolean Wahrheitswert, TRUE=1, False=0 2 Integer % Ganzzahl, -32768 … 32767 2

Name des Kollektionobjektes Zuweisung einer neuen Instanz schon bei der Definition

Objekttyp Collection Dim colTrigger As New Collection

Variable bekommt den Datentyp Zeichenkette zu-gewiesen

Dim sText As String

Deklariert die Variablen und reserviert Speicherplatz dafür

Name der Variable


37

Long & Ganzzahl lang: -2 147 483 648 … 2 147 483 647 4 Single ! Gleitkommazahl, einfachgenau (7 Ziffern) 10E-38 … 10E+38 4 Double # Gleitkommazahl, doppeltgenau (16 Ziffern) 10E-308 … 10E+308 8 Currency @ Währung: (15 Stellen), (Dezimalpunkt), (4Stellen) 8 String $ Zeichenfolge, max. ca. 2 Mrd. Zeichen (2^31) 10+LängeDate 1. Januar 100 … 31.Dezember 9999 8 Object Verweis auf ein Objekt 4 Variant universeller Datentyp ≥16

Abbildung 3.5: Datentypen und Wertebereiche

Der Gültigkeitsbereich einer Variablen wird bei ihrer Deklaration bestimmt. Mit dem Gültigkeitsbereich wird die Verfügbarkeit von Variablen, Konstanten oder Prozeduren zur Verwendung durch eine andere Prozedur bezeichnet. Es gibt drei Gültigkeitsbereichebenen: Prozedurebene, private Modulebene und öffentliche Modulebene [MS-Ac00]. Innerhalb einer Prozedur definierte Variablen oder Kon-stanten sind außerhalb dieser Prozedur nicht verfügbar. Variablen und Konstanten können auch auf Modulebene privat oder öffentlich deklariert werden. Öffentliche Variablen sind für alle Prozeduren in allen Modulen eines Projektes verfügbar, pri-vate Variablen sind nur für die Prozeduren in diesem Modul verfügbar.

3.3.1 Kontrollstrukturen Ein Programm besteht aus einer Folge von Anweisungen. In seiner einfachsten Form enthält ein Programm Anweisungen, die der Reihe nach ausgeführt werden (Folge). Anweisungen können jedoch auch mehrmals wiederholt, als Folge einer Auswahl, ausgeführt werden. Die Kontrollstrukturen Folge, Wiederholung und Auswahl sind die Hauptbestandteile eines Programms.

Anweisungen, die nacheinander und jede genau einmal abgearbeitet werden, nennt man Folge. Ein rein sequentieller Programmablauf ist die einfachste Struktur eines Programms. Als Auswahl bezeichnet man eine oder mehrere abhängige Bedingun-gen. Man unterscheidet zwischen einseitige, zweiseitige, mehrstufige und mehrsei-tige Auswahl.

3.4 API API ist die Abkürzung für Application Programmer's Interface" und bedeutet Pro-grammier- und Anwendungsschnittstelle. Wo Microsoft Access nicht weiterhilft, kann in vielen Fällen die vorhandene Funktionalität durch den Einsatz von API-Funktionen erweitert werden. Nicht zuletzt diese Flexibilität macht den Erfolg von Microsoft Access als Datenbankentwicklungssystem für anspruchsvolle Lösungen aus.


38

Abbildung 3.6: Verweisfenster

In ARTA II wird mit Hilfe dieser Technik die Timer- und Kalenderfunktionalität realisiert. Dazu werden .dll-Dateien (Dynamic Link Library) in Microsoft Access über ein Verweisfenster (siehe Abbildung 3.6) eingebunden. Das Verweisfenster läßt sich über das Menü unter Extras/Verweise öffnen. Da in Visual Basic nicht auf alle Objektbibliotheken über das Verweisfenster zugegriffen werden kann, muß das Einbinden der Objektbibliotheken über den Visual Basic-Programmiercode ge-schehen. Dazu werden die .dll-Dateien vor der Benutzung mit einem DECLARE-Befehl dem System bekannt gemacht. Diese Deklaration sollte in einem Modul stattfinden, um den Gültigkeitsbereich zu vergrößern. Anschließend stehen dem Benutzer die Methoden zur Verfügung. In ARTA II wird vor allem die SetTimer-Funktion der User32.dll genutzt um die Timerfunktionalität zu realisieren.

Erweiterungskonzepte für das aktive DBMS SQL:1999

39

Kapitel 4 SQL:1999

SQL:1999

Ende der siebziger Jahre entwickelte die Firma IBM für die relationale DBMS DB2 eine Computersprache speziell für Datenbankanfragen. Die erste Sprachversion hieß SEQUEL, als Abkürzung für Structured English Query Language (deutsch: strukturierte englische Abfragesprache). Der Name dieser Sprache wurde später aus rechtlichen Gründen geändert und lautet nun SQL (Structured Query Language oder deutsch: strukturierte Abfragesprache). 1983 begann das American National Standards Institute (ANSI) mit der Ausarbeitung eines Standards für relationale Datenbanksprachen. Der Abschlußbericht wurde als American National Standard Database Language-SQL (ANSI X3.135-1986) verabschiedet. Dieser Standard wurde 1987 auch von der International Standards Organisation (ISO) als ISO-Standard übernommen (ISO 9075 Database Language SQL). In den Jahren 1986 bzw. 1989 gab es weitere Standarddokumente, für die sich die Begriffe SQL:1986, SQL:1989 und SQL-1 als Überbegriffe entwickelt haben. 1992 kam eine überarbei-tete Version als SQL:1992 bzw. SQL-2 heraus. Das SQL-2-Standarddokument umfaßt bereits mehr als 600 Seiten gegenüber den 120 Seiten des SQL:1989-Dokuments. SQL-3 wurde 1999 verabschiedet und ist deshalb auch unter SQL:1999 bekannt. SQL:1999 wurde mit Konzepten wie Rekursion und objektorientierten Ansätzen erweitert. Im Laufe der Jahre sind verschiedene Erweiterungen hinzugekommen, so daß sich mit dieser Sprache nicht nur Abfragen ausführen, sondern auch Datenbanken erstellen und die Sicherheitsaspekte des Datenbanksystems verwalten lassen.

4.1 Grundlagen von SQL SQL kann eingebettet in eine Programmiersprache als embedded-SQL oder auch als stand alone-Sprache benutzt werden. Heute ist SQL eine „vollständige“ DB-Sprache, die sich in drei Teilsprachen gliedert:

• DDL (Data Definition Language),

• DML (Data Manipulation Language)

• DCL (Data Control Language).

Mit dem Begriff Data Definition Language DDL sind Anweisungen gemeint, mit denen man Daten definieren kann. Es geht dabei um Löschung, Änderung und Ein-richtung von Datenbankobjekten, wie z.B. Datenbanken (databases), Tabellen (tables) oder Sichten (views). Diese Anweisungen werden mit den folgenden Schlüsselbegriffen eingeleitet:


40

Schlüsselwort Bedeutung CREATE Erzeugen neuer Objekte ALTER Verändern der Eigenschaften existierender Objekte DROP Löschen existierender Objekte

Tabelle 4.1: DDL-Anweisungen

Ergänzt werden diese Schlüsselwörter in der Regel um das Schlüsselwort für das zu bearbeitende Datenbankobjekt, wie beispielsweise TABLE, VIEW, usw.

Der Begriff „Data Manipulation Language“ faßt alle SQL-Anweisungen zur An-frage und zur Datenmanipulation, wie Einfügen, Löschen und Ändern, zusammen. Zur Datenmanipulation verwendet SQL folgende Anweisungen:

Tabelle 4.2: DML-Anweisungen

Das SELECT-Statement erlaubt das Abfragen und Finden von Informationen in der Datenbank. Dies ist vermutlich der wichtigste, mächtigste und komplizierteste aller SQL-Befehle. Mit diesem Befehl können die Daten verschiedener Tabellen der Datenbank gesammelt und ausgewertet werden. Dies erlaubt eine von der tat-sächlichen Tabellenstruktur unabhängige Sicht auf die Daten. Mit einem DDL-Befehl (CREATE VIEW Sichtname) können darüber hinaus häufig benutze Anfra-gebefehle und Strategien als so genannte Sichten in der Datenbank gespeichert werden. Auf diese Art kann durch einen einfachen SELECT-Befehl (SELECT * FROM Sichtname) ein weitaus komplexerer SELECT-Befehl abgekürzt werden.

Mit dem Begriff „Data Control Language“ werden alle SQL-Anweisungen zur Rollen- und Rechtevergabe zusammengefaßt, die festlegen, wer welche Anweisun-gen zur Datenänderung bei einem Datenbanksystem anwenden kann. Zur Rollen- und Rechtevergabe verwendet SQL folgende Anweisungen:

Schlüsselwort Bedeutung

GRANT Erteilt Berechtigungen, um entweder mit Daten zu arbeiten oder andere Transact-SQL-Anweisungen auszuführen

DENY Verweigert Berechtigungen und verhindert, daß der angegebene Benutzer, die Gruppe oder Rolle, die Berechtigung über Gruppen- und Rollenmitgliedschaften erbt

REVOKE Entfernt zuvor erteilte oder verweigerte Berechtigungen

Tabelle 4.3: DLC-Anweisungen

Schlüsselwort Bedeutung DELETE Löschen einer oder mehrerer Zeilen aus einer Tabelle INSERT Erzeugen einer oder mehrerer neuer Zeilen in einer Tabelle UPDATE Verändern einer oder mehrerer Zeilen einer Tabelle


41

4.2 SQL-Triggersprache Der SQL-Standard wurde 1999 unter anderem um ein Triggerkonzept erweitert, welches den Schwerpunkt dieses Kapitels bilden soll. Im Laufe des Kapitels ist mit SQL immer der SQL:1999 Standard gemeint.

Trigger in SQL sind spezielle Formen aktiver (ECA)-Regeln. Aus der Syntax in Abbildung 4.4 ist zu ersehen, daß die Trigger durch die primitiven Datenmanipula-tionsereignisse insert, update und delete ausgelöst werden. In der WHEN-Klausel wird die Regelbedingung definiert, die ein (beliebiges) Prädikat ist. Die Aktions-komponente setzt sich aus einer Sequenz von SQL-Befehlen zusammen, wobei u.a. Transaktionsbefehle nicht zulässig sind. Wenn das triggerauslösende Ereignis (E) eintritt und die Bedingung (C) erfüllt ist, werden die SQL-Befehle des Aktionsteils (A) verarbeitet.

4.3 Syntax der SQL-Triggersprache Trigger in SQL haben die folgende zunächst vereinfacht dargestellte Form

CREATE TRIGGER Triggername

BEFORE | AFTER Ereignistyp ON Tabellenname

REFERENCING NEW AS correlation_name OLD AS correlation_name FOR EACH ROW | STATEMENT WHEN Bedingung Triggerbody BEGIN END

Abbildung 4.4: Einfache Syntax eines Triggers

Triggername Die Erstellung eines Triggers wird immer mit dem Schlüsselwort create trigger eingeleitet. Anschließend folgt die Vergabe eines eindeutigen Namens, um den abgespeicherten Trigger identifizieren zu können. Der Triggername besteht aus einer Zeichenfolge.

trigger nameCREATE TRIGGER trigger nameCREATE TRIGGER Abbildung 4.5: Triggername


42

Triggerndes Ereignis Mit der trigger action time setzt man den Auslösungszeitpunkt des Triggers fest. Hier wird der Zeitpunkt spezifiziert, zu dem die Regel ausgelöst werden soll. Dabei wird zwischen zwei Zeiten unterschieden: Ein Trigger kann entweder vor (BEFO-RE) oder nach (AFTER) des auslösenden Befehls ausgelöst werden. Anschließend wird das triggernde Ereignis (trigger event) angegeben. Die trig-gernden Operationen auf die ein SQL-Trigger reagieren kann sind INSERT, DE-LETE oder UPDATE. Dieser Parameter wird gefolgt vom Schlüsselwort ON und der Angabe einer betroffenen Tabelle, auf der die Änderungsoperation ausgeführt werden soll. Diese Syntaxstruktur ist in der folgenden Abbildung zu sehen.

trigger eventtrigger action time INSERT

DELETE

UPDATE

ON table nameBEFORE

AFTER

trigger eventtrigger action time INSERT

DELETE

UPDATE

ON table nameBEFORE

AFTER

Abbildung 4.6: Triggerndes Ereignis

Durch die Vergabe eines Aktivierungszeitpunktes und eines Triggertyps können sechs verschiedene Ausführungskombinationen angegeben werden.

Transitionsvariablen und Triggergranularität Nachdem das zu triggernde Ereignis festgelegt wurde, kann zudem angegeben werden, mit welchem Namen man auf die Transitionstabellen zugreifen möchte. Dies wird durch die Angabe einer Referencing-Klausel ermöglicht. Die alten Attri-butwerte werden über OLD und die neuen Attributwerte über NEW referenziert. So kann während der Abarbeitung des Triggers auf die alten und die neuen Werte der Transitionstabelle zugegriffen werden.

REFERENCINGNEW

OLD

AS

TABLE AS

tupel name

FOR EACH STATEMENT

FOR EACH ROW

ROW

relation nameREFERENCING

NEW

OLD

AS

TABLE AS

tupel name

FOR EACH STATEMENT

FOR EACH ROW

ROW

relation name

Abbildung 4.7: Triggergranularität


43

Durch die Angabe von ROW oder STATEMENT wird die Granularität, mit der der Trigger arbeiten soll, angegeben. FOR EACH ROW wird als tupelorientiertes Ver-arbeitungsmodell bezeichnet, da die folgende Aktion bei jedem zu ändernden Tupel auszuführen ist. FOR EACH STATEMENT wird als mengenorientiertes Verarbei-tungsmodell bezeichnet, da die folgende Aktion nur einmal für die gesamte SQL-Anweisung ausgeführt wird. In der folgenden Tabelle sind die gültigen Kombinati-onen für die Trigger, Granularität und Transitionsvariablen zu ersehen.

Granularität Auslösezeit-punkt

triggernde Operation

Transitions-variablen Übergangstabellen

INSERT NEW

UPDATE OLD, NEW BEFORE

DELETE OLD NONE

INSERT NEW NEW_TABLE

UPDATE OLD, NEW OLD_TABLE, NEW TABLE

ROW

AFTER

DELETE OLD OLD_TABLE

INSERT

UPDATE BEFORE

DELETE

NONE NONE

INSERT NEW_TABLE

UPDATE OLD_TABLE, NEW TABLE

STATEMENT

AFTER

DELETE

NONE

OLD_TABLE

Tabelle 4.8: Kombinationsmöglichkeiten

Triggerbedingung

Die Ausführung des Triggeraktionsteils kann durch Angabe einer Triggerbedin-gung eingeschränkt werden. Die Bedingung wird mit dem Schlüsselwort WHEN eingeleitet. Die Angabe einer Triggerbedingung ist optional, d.h. wenn die Bedin-gung nicht angegeben wird, wird der Aktionsteil bei jedem Auslösen des Triggers ausgeführt.

WHEN ( condition )WHEN ( condition )

Abbildung 4.9: Triggerbedingung


44

Triggeraktionsteil

Der Triggeraktionsteil wird durch BEGIN ATOMIC und END eingeschlossen. Der Aktionsteil kann in Form eines SQL-Statements oder einer Anweisungsfolge, die in einer Programmiersprache des zugrunde liegenden Systems geschrieben wurde, angegeben werden. Natürlich ist es möglich, daß im Aktionsteil weitere Trigger gefeuert werden können. Doch auch hier ist es nicht erlaubt, SQL-Statements zu formulieren, welche Änderungen an der Tabelle, die gerade vom Trigger bearbeitet wird, vornehmen. Denn solch eine Aktivierung könnte zyklisch sein (rekursive Trigger) und die Terminierung der Aktivierungskette wäre nicht sichergestellt. Ein weiteres Problem entsteht, wenn mehrere Trigger zum gleichen Zeitpunkt und mit identischer Granularität definiert werden. Da in SQL:1999 keine Priorität existiert, kann eine Ausführungsreihenfolge nur durch das Erstellungsda-tum des Triggers festgelegt werden.

BEGIN ATOMIC command END

;

BEGIN ATOMIC command END

; Abbildung 4.10: Triggeraktionsteil

4.4 Semantik der SQL-Triggersprache Ausführungsreihenfolge: In SQL:1999 können mehrere Trigger für eine Tabelle definiert werden, die durch dasselbe Ereignis ausgelöst werden. Diese Trigger wer-den in einer bestimmten Reihenfolge verarbeitet. Bei Triggern mit dem Auslö-sungszeitpunkt BEFORE werden die mengenbasierten Trigger vor den instanzba-sierten Regeln verarbeitet. Bei Triggern mit dem Auslösungszeitpunkt AFTER werden die instanzbasierten Regeln vor den mengenbasierten ausgeführt. Dadurch ergibt sich die folgende Ausführungsreihenfolge:

• Alle Before-Statement-Trigger werden gesammelt und rekursiv abgearbeitet.

• Alle Before-Row-Trigger werden gesammelt und rekursiv abgearbeitet.

• Ausführung der triggernden Operationen

• Überprüfung der Integritätsbedingung

• Alle After-Row-Trigger werden gesammelt und rekursiv abgearbeitet.

• Alle After-Statement-Trigger werden gesammelt und rekursiv abgearbeitet.

Nach dem Sammeln der Trigger werden diese nach ihrem Erstellungsdatum sor-tiert, um somit eine Abarbeitungsreihenfolge festzulegen. Als Defaultwert werden alle Trigger sofort (immediate) ausgeführt. Jedoch gibt es auch Möglichkeiten, die Verarbeitung der Trigger bis zum Ende einer Transaktion zu verzögern (deferred).


45

In SQL:1999 können durch die Ausführung einer triggernden Aktion Ereignisse eintreten und somit weitere Trigger ausgelöst werden. Diese Triggerkaskaden können zyklisch verlaufen und dazu führen, daß die Abarbeitung nicht terminiert. SQL:1999 bietet kein Konzept an, um Zyklen zu erkennen und nicht-endende Re-gelausführungen zu verhindern. Da Before-Trigger keine weiteren Trigger auslösen dürfen, gilt das Problem der Triggerkaskade nur für die After-Trigger.

Die Bedingungsüberprüfung und die Aktionsausführung eines SQL:1999-Triggers erfolgen innerhalb der Transaktion, die den Trigger anstößt. Kommt es bei der Ak-tionsausführung zu einem Fehler, so werden alle Aktionen (einschließlich des aus-lösenden Statements) zurückgesetzt (ROLLBACK).

Erweiterungskonzepte für das aktive DBMS ARTA (Active Real Time Access DBS)

46

Kapitel 5 ARTA (Active Real Time Access DBS)

ARTA

ARTA II basiert auf einem in früheren Diplomarbeiten entwickelten aktiven Da-tenbankverwaltungssystem. In diesem Kapitel wird das „alte“ ARTA-System vor-gestellt und die Unterschiede zum neuen System aufgeführt.

5.1 Namenskonvention ARTA setzt sich aus vier Initialen zusammen, die für Active Real Time Access Database System stehen. Das vierte Initial steht für Microsoft Access, was das zugrundeliegende DBMS repräsentiert. Da MS-Access kein aktives DBMS ist und demzufolge nicht die Möglichkeit bietet aktive Regeln (Trigger) anzugeben, wurde dieses System um diese Erweitert. So wurde aus einem passiven ein aktives DBMS, wofür das erste Initial in ARTA steht. Um die Initialen R und T in der Namensgebung zu erklären, muß zunächst der folgende Begriff eingeführt werden.

Ein Echtzeitsystem (engl. Real Time System, abgek. RTS) ist ein System, daß ein korrektes Ergebnis innerhalb einer vorgegebenen Zeitspanne liefert.

Die ARTA-Trigger wurden um die Möglichkeit erweitert, auf vordefinierte Zeiter-eignisse reagieren zu können. Dazu wurde die Timerfunktionalität des Betriebssys-tems genutzt, die über die API-Schnittstelle angesprochen wird. Zudem wurde durch die Angabe einer Zeitspanne, die angibt bis zu welchem Zeitpunkt ein Trig-ger spätestens gefeuert werden muß, ein wichtiger Aspekt eines Echtzeitsystems geliefert. Aufgrund dieser neuen Funktionalitäten wurde aus dem aktiven DMBS ein aktives Echtzeit-DBMS.

5.2 GUI von ARTA

In ARTA werden Formulare als Benutzeroberflächen eingesetzt, um Anwendern die Möglichkeit der Verwaltung von Triggern und Ereignismustern zu geben. Zur Ereigniserkennung werden alle Datenbankänderungen unter dem direkten Einsatz von ARTA vorgenommen. ARTA-II wurde mit einer komplett neuen GUI verse-hen, siehe Kapitel 8, so daß eine weitgehend übersichtliche Arbeit ermöglicht wird. Dies betrifft nicht nur den Anwender, sondern auch den Entwickler. In der Ent-wicklungsansicht der Formulare wurde sehr großen Wert darauf gelegt, jedes be-nutzte Objekt vernünftig zu benennen und es so anzuordnen, das eine Änderung nicht gleich eine komplette Umgestaltung mit sich zieht. Oft werden Steuerelemen-te, wie z.B. Textfelder übereinander gelegt und nach Bedarf sichtbar geschaltet. Werden jedoch in einer Benutzeroberfläche sehr viele dieser Objekte unterge-bracht, ist es dem Entwickler fast unmöglich eines dieser Objekte vernünftig modi-fizieren zu können, ohne gleich darüberliegende Objekte bewegen zu müssen. Nach einer Modifizierung eines Objektes, müssen dann all diejenigen Objekte die provisorisch „zur Seite gelegt wurden“, wieder in ihrer ursprünglichen Position


47

angebracht werden. In ARTA-II wurden bei der Gestaltung Lösungen gefunden, um die Verschiebung der Objekte bei einer Änderung im Rahmen zu halten. Eine dieser Lösungen war die Verwendung von Registersteuerungselementen, um zu-sammengehörige Objekte gruppiert auf einer Registerkarte anzuordnen.

Abbildung 5.2: ARTA II-Triggerübersicht

Abbildung 5.1:

ARTA-

Triggerübersicht


48

5.3 Erweiterungen in ARTA II

Um den Unterschied kurz anzudeuten, ist in den obigen zwei Abbildungen eine Gegenüberstellung einer ARTA- und einer ARTA II-Benutzeroberflächen gegeben.

Weitere Unterschiede zum ARTA-System werden hier Stichpunktartig aufgezählt.

• Die Deadline in ARTA wurde nur für Zeitereignisse implementiert. In AR-TA-II werden auch Änderungsereignisse mit einer Deadline versehen.

• In ARTA II wird für jeden Trigger ein Gültigkeitsintervall angegeben, um festzulegen, wie lange dieser überhaupt gültig ist. Das Gültigkeitsintervall spielt auch bei der Erstellung von Triggern vom Typ periodisches Zeitereig-nis eine große Rolle.

• In ARTA-II wurde das Konzept der Priorität erweitert, so daß komfortabel und übersichtlich die Priorität eines Triggers geändert werden kann. Dabei hat man stets die Priorität der anderen Trigger im Überblick.

• In der Syntax der ARTA-Trigger wurde ein Flag (activity) angegeben, das den Aktivierungszustand des Triggers angibt. Dieses Flag wurde aus der Syntax entfernt. Die Notation, ob ein Trigger aktiviert oder deaktiviert ist, erfolgt in der Datenbank.

• Die Syntax eines periodischen Zeitereignistyps wurde wesentlich erweitert, siehe Kapitel 6.2 und 6.3.

• Der Ereignistyp eines ARTA-Triggers wird bei der Erstellung in einer eige-nen Tabellen in der Datenbank gespeichert. Jeder Ereignistyp wird mit ei-nem eindeutigen Namen versehen und kann später als „Ereignismuster“ wiederbenutzt werden. Die Wartung ist sehr aufwendig und das Löschen ei-nes Ereignismusters, das von mehreren Triggern benutzt wird, kann zu fata-len Fehlern führen. In ARTA II wird ein Trigger komplett in einer Tabelle in der Datenbank gespeichert. Überdies besteht die Möglichkeit, oft benutz-te Ereignistypen als Ereignismuster zu definieren, die dann in einer geson-derten Tabelle gespeichert werden. Ereignismuster sind eine Kopie eines vorher erstellten Ereignistyps, gekennzeichnet durch einen eindeutigen Na-men. Bei der Erstellung eines Triggers werden die Ereignismuster in einer Auswahlliste angeboten, um die Eingabe zu erleichtern. Um diese Änderun-gen an ARTA vorzunehmen, mußten sehr große Teile der Struktur geändert werden. Ganze Klassen mußten modifiziert und ihre Routinen angepaßt werden.

• Wie in Kapitel 4.4 erwähnt, existiert in der SQL:1999-Triggersprache kein Konzept um mit Zyklen umzugehen. In ARTA-II wurde eine Beschränkung der Kaskadentiefe implementiert, um zu verhindern, daß Regelausführungen nicht terminieren. Wird die Kaskadentiefe erreicht, so werden alle Transak-tionen zurückgerollt.

Erweiterungskonzepte für das aktive DBMS Erweiterungen der SQL-Triggersprache

49

Kapitel 6 Erweiterungen der SQL-Triggersprache

Erweiterungen der SQL-Triggersprache

Ein wesentliches Merkmal von ARTA II ist es, auf Ereignistypen reagieren zu kön-nen, auf die, mittels der SQL:1999 Triggersprache, nicht reagiert werden kann. Ein in SQL:1999 erstellter Trigger kann nur auf das Eintreten eines Änderungser-eignisses mit einer Aktion reagieren. Interessant war die Überlegung SQL:1999 so zu erweitern, das Trigger auch auf zeitliche Ereignisse mit einer Aktion reagieren konnten. Dazu mußte natürlich die Syntax der SQL:1999 Triggersprache um neue Konzepte erweitert werden. Zum einen benötigt man neue Ereignistypen und zum anderen neue Steuerungskomponenten, mit der das neue Unterfangen gelingen soll-te. In den folgenden Abschnitten wird das neue Konzept vorgestellt. Es wird auf die einzelnen Komponenten eingegangen und die Problematik nahegebracht.

Die Erweiterung der Triggersprache von SQL:1999 wurde erweitert um:

• Steuerungskomponenten (Deadline, Gültigkeitsintervall, Priorität, Aktivierungszustand)

• Zeitereignisse (absolute und periodische ZE)

6.1 Steuerungskomponenten Ein wichtiger Bestandteil eines Triggers sind seine Steuerungskomponenten ohne die die Umsetzung der Zeitereignistypen nicht möglich wäre. Die Steuerungskom-ponenten dienen, wie der Name schon sagt, der Steuerung eines Triggers. Mit ih-nen kann beim Erstellen eines Triggers angegeben werden, ob dieser aktiviert oder deaktiviert ist oder durch die Angabe eines Gültigkeitsintervall sichergestellt wer-den, in welche Zeitspanne ein Trigger gefeuert werden darf. Weitere Komponenten werden in folgenden Abschnitten erläutert.

6.1.1 Gültigkeitsintervalle Will man Zeit darstellen, geschieht dies meistens mittels eines Zeitstrahls, wie in Abbildung 6.2 zu sehen ist. Es gilt eine totale Anordnung der Zeitpunkte, d.h. für jeweils zwei verschiedene Zeitpunkte t1 und t2 gilt: t1 < t2. Die Zeitachse des Zeit-strahls ist in beiden Richtungen unendlich. Für jeden beliebigen Punkt auf dieser Zeitachse gilt, daß sich alle Punkte, die links des ausgewählten Punktes liegen, in der Vergangenheit und alle Punkte, die rechts des ausgewählten Punktes liegen, in seiner Zukunft befinden. Der Punkt selbst spiegelt dabei die Gegenwart wieder. Eine wichtige Steuerungskomponente eines ARTA-Triggers ist die Angabe eines Gültigkeitsintervalls. Mit start on date und start at time werden der Start des In-tervalls, mit end on date und end at time das Intervallende angegeben. Nur inner-halb dieses Intervalls darf der Trigger gefeuert werden. Wird das Intervall über-schritten, so wird der Trigger gelöscht, bzw. als abgearbeitet markiert und es er-folgt ein Eintrag in eine Protokolldatei. Im Zusammenhang mit einer Deadline


50

können verschiedene Grenzfälle auftreten, auf die in Abschnitt 6.1.3 eingegangen wird.

Abbildung 6.1: Das Gültigkeitsintervall

6.1.2 Deadlines Die Deadline ist eine der wichtigsten Steuerkomponenten der ARTA-II Trigger. Bei der Abarbeitung eines Triggers kann nie genau der Zeitpunkt angegeben wer-den, wann dieser seiner Arbeit beendet hat. Während dieser Abarbeitung können weitere Trigger gefeuert werden, die aber warten müssen, da die Trigger in ARTA sequentiell, also nacheinander abgearbeitet werden. So kann es vorkommen, daß der Zeitpunkt für die Abarbeitung des Triggers verpaßt wird. Um dennoch diesen Trigger behandeln zu können wird eine gewisse Zeittoleranz einkalkuliert, in der der Trigger doch noch gefeuert werden darf. Diese Zeittoleranz wird berechnet aus Ausführungszeitpunkt + (angegebenen) Deadline. Die Granularität der Deadline wird in Minuten angegeben und ist standardmäßig auf 5 Minuten eingestellt. Trig-ger, die nicht innerhalb dieser Zeittoleranz ausgeführt wurden, werden nicht bear-beitet. Damit der Anwender dies auch mitbekommt, wird ein Protokolleintrag in die Datenbank erstellt. Die Deadline ist auch eine wichtige Komponente in Bezug auf das folgende Problem:

Das ARTA-DBMS wird in der Regel nicht ununterbrochen eingesetzt. In diesen Ruhephasen, kann das System nicht auf bestimmt eintretende Zeitereignisse reagie-ren. Darum ist es wichtig für solche Trigger eine längere Deadline anzugeben. So können nach Einschalten des Systems all diejenigen Trigger mit einer gültigen Ak-tivierungszeit (Ausführungszeitpunkt + Deadline) ausgeführt werden.

Grenzfälle für das Feuern eines Triggers Was passiert mit den Triggern, die zwar eine gültige Zeittoleranz (Ausführungs-zeitpunkt + Deadline) haben, aber außerhalb der Gültigkeitsintervalls gefeuert werden sollen? Darf ein solcher Trigger gefeuert werden? Was passiert mit einem Trigger der innerhalb eines Gültigkeitsintervalls gefeuert wurde, aber die Abarbei-tung so viel Zeit in Anspruch nimmt, daß der Beendigungszeitpunkt außerhalb des Intervalls liegt? In beiden Fällen muß festgelegt werden, wie ARTA II mit solchen Situationen umgehen soll. Wird ein Trigger innerhalb des Gültigkeitsintervalls ge-feuert, so darf dieser auch bis zum Ende ausgeführt werden. Ein Trigger der warten muß bis ein zuvor gefeuerter Trigger abgearbeitet ist und dabei trotz einer gültigen Zeittoleranz außerhalb des Intervallendes liegt, wird nicht gefeuert.

t

start on date: 21.01.2004 start at time: 09:00

end on date: 03.04.2004 end at time: 10:30

t1 t2 … tn


51

Abbildung 6.2: Die Deadline

6.1.3 Prioritäten Während der Abarbeitung eines Triggers kann es vorkommen, daß zwei Trigger zum selben Zeitpunkt gefeuert werden. An dieser Stelle muß klar unterschieden werden, welcher Trigger zuerst abgearbeitet werden darf und welcher Trigger war-ten muß. In SQL:1999 werden die Trigger nach ihrem Erstellungsdatum (Times-tamp) sortiert. Nachdem ein SQL:1999-Trigger erstellt wurde, kann seine Ausfüh-rungsreihenfolge nicht mehr verändert werden. Um diese Situation in den Griff zu bekommen, wurde in ARTA eine weitere Steuerungskomponente entwickelt und zwar die Triggerpriorität. Diese legt eindeutig fest, welcher Trigger zuerst abgear-beitet werden darf. Zwei Trigger dürfen nicht dieselbe Priorität besitzen. So kann sichergestellt werden, daß bei der Abarbeitung stets eine eindeutige Reihenfolge eingehalten werden kann. Die Priorität wird erstmals beim Erstellen eines Triggers automatisch gesetzt. Es wird die bereits höchste vergebene Priorität ermittelt und um 1 erhöht. Man kann die Priorität eines Triggers jederzeit manuell über den Prio-ritätenmanager verändern, um auch nach Erstellung des Triggers zu bestimmen, wie sich dieser in Bezug auf andere Trigger, was die Abarbeitungsreihenfolge be-trifft, zu verhalten hat.

6.2 Zeitereignisse In diesem Abschnitt wird die Syntax für Zeitregeln in ARTA II vorgestellt. Wie schon zuvor erwähnt, wurde die SQL-Triggersprache um neue Zeitereignistypen erweitert, d.h. die Trigger von ARTA II können, außer auf das Eintreten eines Än-derungsereignisses, auch auf das Eintreten eines Zeitereignisses reagieren. Es wer-den zwei Arten von Zeitereignissen unterschieden. Die absoluten Zeitereignisse, die durch einen absoluten Zeitpunkt angegeben werden und die periodischen Zeit-ereignisse, die durch eine Regel, wie jeden Sonntag um 23:59 Uhr beschrieben werden. Beim Entwurf der periodischen Zeitereignisse wurde sorgsam eine Syntax erstellt, mit der alle gängigen periodischen Zeitereignistypen abgedeckt werden. Was sind gängige periodischen Zeitereignistypen? Im normalen Sprachgebrauch werden oft Zeitangaben formuliert, die sich auf den ersten Blick nicht ohne weite-res Formulieren lassen, wie z.B.

t



t1 t2 … tn

deadline

execute time of trigger

trigger react begin


52

• jeden dritten Tag um 11:00 Uhr

• alle zweieinhalb Stunden

• alle 20 Minuten

• jeden Sonntag jeder dritte Woche um 9:00 Uhr

• jeden ersten Januar des Jahres um 9:00

• jedes zweite Jahre am jeweils zweiten Samstag im Monat Januar um 09:00 Uhr.

• alle zwei Monate jeden Montag um 09:00 Uhr.

• alle zwei Monate an jedem ersten Sonntag um 09:00 Uhr.

• alle zwei Monate am 25.Tag des Monats um 09:00 Uhr.

Es sollte eine möglichst einheitliche Formulierung gewählt werden, die für sich selbstsprechend ist, so daß der Anwender schon an der Syntax erkennen kann, wie der Ausdruck zu formulieren ist. In den folgenden Abschnitten werden die Zeiter-eignistypen und ihre Syntax anhand von Beispielen vorgestellt.

6.2.1 Absolute Zeitereignistypen Die einfachsten Zeitereignistypen, die in ARTA II existieren, sind die absoluten Zeitereignisse. Dies sind einmalig eintretende Ereignisse, die mittels eines Datums und einer Zeitangabe angegeben werden können. Ein absolutes Zeitereignismuster wird mit dem Schlüsselwort ON eingeleitet, gefolgt vom Datum. Anschließend wird die Zeitangabe mit dem Schlüsselwort AT eingeleitet.

Abbildung 6.3: Absolutes Zeitereignis

6.2.2 Periodische Zeitereignistypen Periodische Zeitereignisse in ARTA II werden in sechs verschiedene Perioden un-terteilt. Diese, wie in der folgenden Abbildung zu sehen ist, unterteilen sich in die Perioden Minute, Stunde, Tag, Woche, Monat und Jahr. Die Perioden Monat und Jahr können wiederum unterteilt werden.

absolute time event type

ATON date time


53

periodic time event type

minutes event type

hours event type

days event type

weeks event type

months event type

years event type

periodic time event type

minutes event type

hours event type

days event type

weeks event type

months event type

years event type

Abbildung 6.4: Verschiedene Perioden eines Zeitereignisses

Die periodischen Zeitereignistypen unterscheiden sich von den absoluten Zeiter-eignistypen dadurch, daß sie mehrmals zu eintretenden Zeitpunkten passen können. Periodische Zeitereignistypen beginnen immer mit dem Schlüsselwort EVERY, um den Unterschied zu den absoluten Zeitereignissen deutlich zu machen.

Bei einem Zeitereignis vom Typ Minute muß nur eine Minutenzahl angegeben werden. Anhand des Startdatums des Gültigkeitsintervalls wird der nächste Aus-führungstermin, der in der Zukunft liegt, berechnet. Liegt der berechnete Ausfüh-rungszeitpunkt außerhalb des Gültigkeitsintervalls, so wird dieser Trigger als abge-arbeitet markiert und gelöscht.

minutes

minutes event type

EVERY MINUTESminutes

minutes event type

EVERY MINUTES

Abbildung 6.5: Zeitereignis der Periode Minute

Angenommen die Periode Minute wird mit 30 Minuten und das Gültigkeitsintervall mit start at: 9:35 und end at: 11: 30 angegeben, dann wären die nächsten Ausfüh-rungstermine: 9:35 Uhr, 10:05 Uhr und 10:35 Uhr.

Abbildung 6.6: Wiederkehrende Minutenperiode

t



09:35 10:05 10:35 11:05


54

Auch beim Periodentyp Stunde wird anhand der Start- und Endzeit des Gültigkeitsintervalls des nächsten Ausführungszeittermins berechnet. Mit dem folgenden Konstrukt kann ein periodisches Zeitereignis der Form „alle 02 Stunden um 30 Minuten nach“ angegeben werden. Für das folgende Beispiel ist das Gültigkeitsintervall wie folgt angegeben: start at 9:35, end at 14:30. Nächster Ausführungstermin wäre um 12:05 Uhr. Der anschließende Termin um 14:35 Uhr liegt nicht mehr im Gültigkeitsbereich.

2digit

hours event type

EVERY HOURS AT minutes MINUTES PAST2digit

hours event type

EVERY HOURS AT minutes MINUTES PAST

Abbildung 6.7: Zeitereignis der Periode Stunde

Mit dem Periodentyp Tag kann man einen Ausdruck in der folgenden Form formu-lieren: „alle 3 Tage um 9:00 Uhr“, was im normalen Sprachgebrauch „jeden dritten Tag um 09:00 Uhr“ entspricht.

3digitdays event type

EVERY DAYS AT time3digitdays event type

EVERY DAYS AT time

Abbildung 6.8: Zeitereignis der Periode Tag

Dieses Konstrukt erlaubt die Angabe eines Ereignisses, mit der Periode Woche. Ein möglicher Ausdruck durch dieses Syntax wäre „alle 02 Wochen am Sonntag um 09:00 Uhr“, was im normalen Sprachgebrauch „jede zweite Woche am Sonntag um 9:00 Uhr“ entspricht.

2digit

weeks event type

EVERY WEEKS ON day of week AT time2digit

weeks event type

EVERY WEEKS ON day of week AT time

Abbildung 6.9: Zeitereignis der Periode Woche

Interessant sind die Konstrukte vom Periodentyp Monat und Jahr. Diese werden in weitere Untertypen unterteilt, um die verschiedenartigen und noch sinnige periodi-sche Zeitereignistypen abzudecken. Der Periodentyp Monat läßt sich in drei und der des Jahres in zwei Untertypen einteilen.

months event type

2digitEVERY AT time

DAY

EVERY

ordined 1stTo5th

ordined digit day

day of week

day of weekMONTHS ON2digitEVERY AT time

DAY

EVERY

ordined 1stTo5th

ordined digit day

day of week

day of week AT time

DAY

EVERY

ordined 1stTo5th

ordined digit day

day of week

day of weekMONTHS ON

Abbildung 6.10: Zeitereignis der Periode Monat


55

Für die Periode Monat können folgende Ausdrücke formuliert werden:

• alle 02 Monate an jedem Montag um 09:00 Uhr.

• alle 02 Monate an jedem ersten Sonntag um 09:00 Uhr.

• alle 02 Monate am 25.Tag um 09:00 Uhr.

Der letzte Periodentyp der angegeben werden kann, ist der des Jahres. Auch hier wird zu jedem Konstrukt ein Beispiel angegeben.

years event type

2digitEVERY YEARS ONordined day

ordined number day of week IN month of year

month of yearAT time

years event type

2digitEVERY YEARS ONordined day


month of yearAT time

ordined day


month of yearAT timeAT time

Abbildung 6.11: Zeitereignis der Periode Jahr

Für die Periode Jahr können folgende Ausdrücke formuliert werden:

• alle 02 Jahre am ersten Januar um 09:00 Uhr oder

• alle 02 Jahre am zweiten Samstag im Januar um 09:00 Uhr.

6.2.3 Korrektheit Die Angabe einer so großen Anzahl an Konstrukten verschafft dem Anwender eine optimale Übersicht bei der Formulierung eines Triggers. Die Syntaxüberprüfung bei der Eingabe eines Triggers, wird teils von den Steuerelementen selbst und teils mit Hilfe von Routinen realisiert, die in die Eingabemaske implementiert wurden.

Abbildung 6.12: Steuerelement für die Vergabe einer Priorität

In Abbildung 6.12 ist ein Textfeld dargestellt, das bei der Erstellung dafür sorgt, daß die Triggerpriorität automatisch gesetzt wird. Im Feld „Standardwert“ wird eine Routine (siehe Abbildung 6.13) aufgerufen, die aus der Datenbank die höchst-vergebene Triggerpriorität ermittelt. Dieser ermittelte Wert wird dann um 1 erhöht


56

und als Steuerelementinhalt des Attributes „priority“ in der Datenbank abgespei-chert.

Abbildung 6.13: Routine zur Ermittlung der höchstvergebenen Priorität

Um zu überprüfen, ob die getätigte Eingabe in einem Textfeld korrekt ist, kann nach der Eingabe (nach der Aktualisierung des Textfeldes) eine Ereignisprozedur ausgelöst werden, die die falsche Eingabe zurücksetzt. Diese Routine ist in Abbil-dung 6.14 mit abgebildet. Der Undo-Befehl macht die Eingabe rückgängig, wenn der eingegebene Wert kleiner oder gleich 0 ist. An dieser Stelle könnte noch ein Dialogfenster geöffnet werden, um den Anwender mitzuteilen, was er falsch ge-macht hat. Da aber die Priorität automatisch gesetzt werden soll, erübrigt sich eine Meldung.

Abbildung 6.14: Eingabeüberprüfung über eine Ereignisprozedur

Aufruf einer Ereignisprozedur

Ereignisprozedur:


57

6.3 Syntax der ARTA II-Trigger In diesem Kapitel wird die komplette Syntax der ARTA II-Trigger vorgestellt. Die Syntax wurde aufgrund der Übersichtlichkeit farbig dargestellt.

<trigger definition> :: = CREATE TRIGGER <trigger name><priority><interval><deadline>

ON <event type> REFERENCING <old or new values alias list>

IF <condition>

DO <action>.

<trigger name> ::= <identifier–name>.

<priority> ::=<integer>.

<interval>::= <begin validity interval> <end validity interval>.

<deadline>::= <integer>.

<event type> :: = <modification event type> |<absolute time event type > |<periodic time event type>.

<old or new values alias list> :: = OLD ROW AS <old values correlation name> OLD TABLE AS <old values table alias> NEW ROW AS <new values correlation name> NEW TABLE AS <new values table alias>.

<condition> :: = [ WHEN [<left parent><search condition><right parent>] <triggered SQL Statement> ].

<action> :: =

FOR EACH {ROW | STATEMENT}. <triggered SQL Statement> | <VBA expression>.


58

<begin validity interval> ::= <date> <time>.

<end validity interval> ::= <date> <time>.

<modification event type> :: = <trigger action time><modification type>ON<table name>

<trigger action time> :: = BEFORE |AFTER.

<modification type> :: = INSERT |DELETE |UPDATE.

<table name> ::= <identifier-name>.

<absolute time event type> ::= ON<date>AT<time>.

periodic time event type > ::= <minutes event type>

|<hours event type>

|<days event type>

|<weeks event type>

|<months event type>

|<years event type>.

<minutes event type> ::= EVERY<minutes>MINUTES.

<hours event type> ::= EVERY<2digit>HOURS AT<minutes>PAST.

<days event type> ::= EVERY<3digit>DAYS AT<time>.

<weeks event type> ::= EVERY<2digit>WEEKS ON <list day of week>AT<time>.

<months event type > ::=

EVERY<2digit>MONTHS ON EVERY<day of week>AT<time>.

|<EVERY<2digit>MONTHS ON<ordined>< day of week>AT<time>.

| EVERY<2digit>MONTHS ON<ordined digit day>DAY<time>.

<years event type > ::=


59

EVERY<2digit>YEARS ON<ordined day><month>AT<time> |EVERY<2digit>YEARS ON<ordined number><day of week>IN<month>AT<time>.

<old values correlation name> ::= <identifier-name>. <old values table alias> ::= <identifier-name>. <new values correlation name> ::= <identifier-name>. <new values table alias> ::= <identifier-name>.

<left paren> <search condition><right paren> : Ja/Nein-Abfragen an die DB.

<triggered SQL Statement>: Ein SQL-Ausdruck.

<VBA expression>: Eine Routine in Visual Basic Appication.

<identifier-name> ::= <letter> | <identifier-name> <letter> |<identifier-name> <digit0>.

<day of week> ::= monday | ... | sunday.

<month> ::= january | ... | december.

<3digit> ::= <digit0><digit0><digit>.

<2digit> ::= <digit0><digit>.

<date> ::= <digit days>.<digit months>.<digit years>.

<time> ::= <hours>:<minutes>.

<ordined> :: = 1st | ... | 5th.

<ordined digit day> ::= 1st | ... | 31th .

<minutes> ::= 00 | ... | 59.

<digit hours> ::= 01 | ... | 23.

<digit days> ::= 01 | ... | 31.

<digit months> ::= 01 | ... | 12.

<digit years> ::= 1900 | ... | 2100.

<digit0> ::= 0 | ... | 9.

<digit> ::= 1 | ... | 9.

<letter> ::= a | ... | z | A | ... | Z.

<integer> ::= <digit> | <integer> <digit>.

<boolean> ::= TRUE | FALSE.


60

6.4 Semantik der ARTA II-Trigger Die Abarbeitungsreihenfolge der ARTA-II Trigger entspricht der, der SQL:1999 Trigger, die in Kapitel 4.4 vorgestellt wurde. Hier eine kurze Zusammenfassung.

1.Ermittlung aller Before-Statement-Trigger

2.Ermittlung aller Before-Row-Trigger

3. Ausführen des Aktionsteils

4. Überprüfung der IB (constrains)

5. Ermittlung aller After-Row-Trigger

6. Ermittlung aller After-Statement-Trigger

6.4.1 Ausführungsreihenfolge von simultan ausgelösten Triggern Nach der Ermittlung der Before- und After-Trigger, muß eine Reihenfolge für die Abarbeitung der Trigger festgelegt werden. SQL:1999-Trigger werden nach ihrem Erstellungsdatum und -uhrzeit sortiert und anschließend in dieser Reihenfolge ab-gearbeitet. Eine Änderung der Abarbeitungsreihenfolge ist nach Erstellen eines Triggers nicht mehr möglich, es sei denn alle Trigger würden, unter Berücksichti-gung des Erstellungsdatums, neu definiert werden. Dies setzt wiederum voraus, daß schon am Anfang bekannt ist, welche Trigger benötigt werden. Bei der Erstellung eines ARTA II-Triggers hingegen wird, bei der Erstellung eines neuen Triggers, eine eindeutige Priorität vergeben, die später manuell verändert werden kann. Die Trigger werden bei der Abarbeitung nach ihrer Priorität sortiert, so daß ein Ablaufsreihenfolgenkonflikt vermieden werden kann. Der neue Aspekt in ARTA II beruht auf der Möglichkeit, die Priorität nach Erstellung des Triggers ändern zu können. Diese erleichtert die Arbeit mit den ARTA II-Triggern wesent-lich, da sich nicht schon bei Erstellung des Triggers darum gekümmert werden muß, in welchem Abarbeitungsreihenfolgenbezug dieser Trigger zu anderen Trig-gern steht.

6.4.2 Realisierung der Triggerkaskaden In ARTA II können Regeln zu unterschiedlichen Zeitpunkten definiert werden. Das Verhalten der so definierten Triggermenge und die Abhängigkeiten zwischen den einzelnen Triggern sind schwer voraussehbar. So können z.B. innerhalb der Trig-germenge Kaskaden entstehen, wenn durch die Ausführung einer triggernden Akti-on Ereignisse eintreten und somit weitere Trigger ausgelöst werden. Diese Kaska-den können auch zyklisch verlaufen, wenn sich ein Trigger selbst direkt oder indi-rekt über andere Trigger auslöst. Durch die Existenz einer zyklischen Regelkaskade besteht die Gefahr, daß die Regelverarbeitung nicht abbricht, d.h. daß während der Verarbeitung immer wieder neue Regeln ausgelöst werden. Es bedarf einer guten Planung und Übersicht bei der Erstellung eines Triggers, die dank der gut strukturierten grafischen Benutzeroberflächen wesentlich erleichtert wird. Trotzdem mußte eine Lösung gefunden werden, um mit Triggerkaskaden


61

umgehen zu können. ARTA-II kann solche Zyklen nicht erkennen. Um dennoch zu ver-hindern, daß die Regelverarbeitung nicht abbricht, wurde in ARTA-II die Tiefe der Re-gelkaskaden beschränkt.

6.4.3 Beschränkte Kaskadentiefe Die Regelmenge wird in diesem Fall nicht analysiert. Statt dessen wird eine feste Zahl vorgegeben, die festlegt, wie tief sich Trigger gegenseitig auslösen dürfen, d.h. wie tief die Triggerkaskade sein darf. Beim Erreichen dieser Schranke wird die Verarbeitung abgebrochen. Dabei können zwei Varianten unterschieden werden:

1. Der letzte Befehl wird zurückgesetzt.

2. Die ganze Transaktion wird zurückgesetzt.

Falls eine zyklische Regelkaskade existiert, so wird mit der Beschränkung garantiert, daß die Verarbeitung terminiert. Die Festlegung einer Kaskadentiefe hat jedoch einige Nachteile. So kann es z.B. vorkommen, daß eine gewünschte Regelverarbeitung eine Kaskadentiefe von 10 aufweist, die festgelegte Grenze aber nur bei 5 liegt. Die ge-wünschte Kaskade könnte in diesem Fall nicht verarbeitet werden, obwohl diese nicht zu einer Endlosverarbeitung geführt hätte.

6.4.4 Transaktionskonzept

Set wks = DBEngine.WorkSpace.(0)

Set TEC AS New clsTExecute

TE.doActionTE.doAction

TEC.executeSQL-Statement (TE.action)TEC.executeSQL-Statement (TE.action)

wks.CommitTrans

wks.BeginTrans

ControlSystemClose!chkEnableClose = FALSE

ControlSystemClose!chkEnableClose = TRUE

Error

wks.Rollback

TRUE FALSE

Abbildung 6.15: Transaktionskonzept

Ausgelöste SQL-Statements und Triggeraktion laufen in unabhängigen Transaktionen ab. Die Bedingungsprüfung und die Aktionsausführung erfolgen innerhalb der Transak-tion, die den Trigger anstößt. Kommt es bei der Aktionsausführung zu einem Fehler, so


62

werden alle Aktionen, einschließlich des auszulösenden Statements, zurückgesetzt (Rollback). Im folgenden Programmablauf wird, vereinfacht dargestellt, der Ablauf ei-ner Transaktion verdeutlicht. Mit Begin Trans wird die Transaktion eingeleitet. Nach erfolgreicher Ausführung eines SQL-Statements werden mit Commit Trans, die Ände-rungen in der Datenbank festgeschrieben. Bei einem Fehler hingegen, wird die komplet-te Transaktion mit Rollback zurückgesetzt. Die Rekursion für die Triggerverarbeitung findet in Execute.SQL-Statement statt.

Erweiterungskonzepte für das aktive DBMS ARTA II

63

Kapitel 7 ARTA II

ARTA II

Ein gängiges Konzept beim Aufbau von Access-DB ist es, die Tabellen in Datenbank A (Back-End genannt) zu speichern und die anderen Objekte einer Datenbank in der Da-tenbank B (Front-End) zu verwalten. Man spricht hier von geteilten Datenbanken. Die-ses Konzept bietet folgende Vorteile: Bei der Entwicklung von ARTA II wurden die Anwendungsdaten und das neue aktive Datenbankverwaltungssystem voneinander getrennt. Die Anwendungsdaten und ARTA II wurden in zwei separaten .mdb-Dateien gespeichert, siehe Abbildung 7.1. Grundsätz-lich ist es besser Daten und Anwendungssystem zu trennen, so ist es z.B. bei einem Versionswechsel einfacher, eine gezielte Datensicherung vorzunehmen ohne gleich das ganze System mit abzuspeichern. Zudem ist es einfacher das alte System durch ein neu-es zu ersetzen, ohne gleich alle Anwendungsdaten zu verlieren. Die Datenbank, in der die Anwendungsdaten liegen, nennt man in einer geteilten Datenbank Back-End und die Datenbank, die das Anwendungssystem beinhaltet Front-End.

ARTA II soll anhand eines Diplomprüfungsamtsystems vorgestellt werden. Folglich befinden sich in der Data-Application.mdb die Daten zu den Studenten und deren Ab-gabefristen für eine angemeldete Diplomarbeit. Zusätzlich werden die angelegten Trig-ger, Ereignismuster, vordefinierten SQL-Statements, sowie eine Ereignisprotokollierung abgespeichert. Diese Tabellen sind mit dem ARTA II-System verknüpft, so daß eine Verbindung zwischen dem System und den Daten besteht. Bei einer Verknüpfung wird eine Kopie der Tabellen in der Datenbank gespeichert.

Abbildung 7.1: ARTA II-Dateistruktur

Möchte man einen neuen Studenten oder zu einem bestehenden Studenten die Abgabe-fristen für die Anmeldung einer Diplomarbeit in die Datenbank eintragen, so geschieht dies über das ARTA II-System. Dort können mit Hilfe eines Terminals SQL-Anweisungen formuliert werden, die dann vom ARTA II-System ausgeführt werden. Nur so können Datenbankänderungen vom System erkannt bzw. abgefangen und darauf reagiert werden. In der folgenden Abbildung wird die ARTA II-Systemarchitektur mit ihren Komponenten vorgestellt. In den darauf folgenden Abschnitten werden die einzel-nen Komponenten in ihrer Arbeitsweise, zum Teil durch Programmablaufpläne (PAP), dargestellt.

Data-Application.mdb

(DBMS)

DB

ARTA II.mdb

(ADBMS)


64

7.1 Schichtenarchitektur

TimerTimer ARTA II – DBMS

GUI

Event TypeManager

TriggerManager

SQL-StatementManager

EventManager

DataTrigger

EventLog

SQL-Statements

Time EventManager

TriggerExecutionData Application

Abbildung 7.2: Architekturdiagramm von ARTA II

Die Komponenten von ARTA II, die das passive DBS in ein aktives überführen, werden wie eine aktive Schicht über das Datenbanksystem gelegt. Sämtliche Befehle eines Be-nutzers gelangen durch die aktive Schicht an die darunterliegende Datenbank und alle Daten aus der Datenbank werden durch die Schicht hindurch an den Benutzer weiterge-reicht. Somit sind sämtliche Informationen in der Schicht verfügbar, die für die Re-gelausführung notwendig sind. Dieser Ansatz wird auch layered architecture genannt.

• Vorteile: Ein DBS kann ohne Modifikation in ein ADBS umgewandelt werden.

• Nachteile: Es besteht die Gefahr von geringer Performance, da der Kommunika-tionsaufwand zwischen der aktiven Schicht und der Datenbank hoch sein kann.

ARTA II besteht im wesentlichen aus zwei Subsystemen, die miteinander kommunizie-ren. Diese Systeme sind die grafische Benutzerschnittstelle (Graphic User Interface, abgek. GUI), mit welchem die Benutzer arbeiten, und das Verarbeitungssystem (Processing System), in dem die Regeln modelliert, analysiert, abgelegt und verarbeitet werden. Das Verarbeitungssystem ist mit dem zugrundeliegenden DBS verbunden. Je-der Benutzerbefehl gelangt durch die grafische Benutzerschnittstelle in das Verarbei-tungssystem, in dem Regeln, die durch die Benutzerbefehle ausgelöst werden, in die Verarbeitung mit einfließen. Die notwendigen Regelaktionen sowie die Benutzerbefehle selbst, werden sodann auf der darunterliegenden Datenbank ausgeführt.


65

7.2 Systemarchitektur

Event LogEvent Types

GUI

Event TypeManager

TriggerManager Trigger

Event Log

SQL-Statements

SQL-StatementManager

Timer

EventManager

Time EventManager

TriggerExecution

Abbildung 7.3: ARTA II: Systemkomponenten

ARTA II besteht aus einer grafischen-, vier Schema- und zwei Ausführungskomponen-ten, die untereinander in Verbindung stehen. Die GUI ist die grafische Komponente und die Schnittstelle zur Kommunikation zwischen Anwender und ARTA-System. Die Hauptaufgabe der GUI ist die grafische Aufbereitung, sowie die Unterstützung der Da-ten beim Erstellen, Ändern und Löschen. Die Erstellung der grafischen Benutzerober-flächen verlangt viel Fingerspitzengefühl, um komplizierte Zusammenhänge einfach und verständlich darzustellen.

Die ARTA II-Schemakomponenten dienen hauptsächlich der Verwaltung, also der Er-stellung, Modifizierung und Löschung von Daten. Im folgenden werden die vier Sche-makomponenten kurz vorgestellt.

Der SQL-Statement Manager, der zusammen mit dem Event Type Manager und dem Trigger Manager zur Schemakomponente gehört, dient hauptsächlich der Verwaltung manuell eingegebener SQL-Statements. Möchte ein Anwender einen Datensatz manipu-lieren, so geschieht dies über eine Art Terminal, mit welchem SQL-Statements formu-liert und ausgeführt werden können. Darüber hinaus können formulierte SQL-Statements in die Datenbank abgespeichert werden und stehen dann dem Anwender bei der Formulierung neuer Statements zu Verfügung. Dieser Manager dient somit zum einen der Verwaltung von SQL-Statements und zum anderen besteht seine Aufgabe darin, eingegebene Befehle abzufangen, sie auf ihre Richtigkeit hin zu überprüfen und, falls diese Korrekt sind, an die Trigger Execution weiter zu reichen. Falls die Trigger Execution mit einem anderen Befehl beschäftigt ist, so wird der auszuführende Befehl


66

als nicht ausgeführt protokolliert und zurückgewiesen. Der Benutzer kann sofort die Protokolldatei einsehen, um entsprechende Gegenmaßnahmen durchzuführen.

Der Event Type Manager verwaltet Ereignismuster. Bei der Erstellung eines Triggers können die auslösenden Ereignisse für einen Trigger als Muster gesondert abgespeichert werden. Diese stehen später bei der Erstellung eines neuen Triggers als Auswahlliste zur Verfügung. So können in der Ereignismusterübersicht alle Trigger, die ein gemein-sames Ereignismuster besitzen, gruppiert angezeigt werden.

Der Event Manager verwaltet eine Protokolldatei, in der alle abgearbeiteten oder nicht abgearbeiteten Trigger protokolliert werden. Zu einem Eintrag werden Triggername, Ausführungszeitpunkt, Erfolgs-, bzw. Mißerfolgsmeldung und ein Timestamp eingetra-gen. Dieses Protokoll kann ausgedruckt werden.

Der Trigger Manager ist eine der wichtigsten Komponenten, mit dem die ARTA II-Trigger verwaltet werden. Der Trigger Manager sorgt bei der Erstellung eines Triggers von Typ Zeitereignis (TE-Trigger) dafür, daß dieser vom Time Event Manager bei der Verarbeitung mit berücksichtigt wird. Bei der Erstellung eines TE-Triggers wird vom Trigger Manager der nächste Ausführungszeitpunkt berechnet und zusammen mit dem Trigger in die Datenbank gespeichert. Weitere Aufgaben dieser Komponente sind die Überprüfung auf Korrektheit bei der Erstellung, Modifizierung sowie der Löschung eines Triggers.

Die ARTA II-Ausführungskomponenten (Time Event Manager und Execution Mana-ger) werden in den folgenden zwei Abschnitten genauer betrachtet, da sie das Kernstück des Systems bilden.

7.3 Time Event Manager

Event Log

TIME EVENT MANAGER

TimerTimer

TriggerExecution

TriggerManager Time Event

Trigger

ProcessNewTimeEvents

ProcessOldTimeEvents

ProcessNewTimeEventsProcessNewTimeEvents

ProcessOldTimeEventsProcessOldTimeEvents

Abbildung 7.4: Der Time Event Manager und seine interagierenden Komponenten


67

Der Time Event Manager dient der Zeitereigniserkennung und Verarbeitung von Trig-gern vom Typ Zeitereignis (TE-Trigger). Die Komponenten, die mit diesem Verwal-tungssystem interagieren sind der Trigger Manager und die Trigger Execution. Wird der Time Event Manager gestartet, so werden zunächst alle „alten“ TE-Trigger und an-schließend alle in der Zukunft liegenden TE-Trigger verarbeitet. Genaueres dazu in den folgenden Routinen.

Bei der Erstellung eines Triggers vom Typ periodisches Zeitereignis, wird durch den Trigger Manager automatisch, anhand eines Gültigkeitsintervalls und einer Periode, der nächste Ausführungszeitpunkt berechnet und mit dem Trigger zusammen in der Daten-bank abgespeichert. Bei der Abarbeitung der Trigger durch den Time Event Manager, werden diese Informationen und zusätzliche Steuerelemente der Trigger aus der DB geladen, um eine Abarbeitungsreihenfolge zu berechnen. Über alle Aktionen die ausge-führt werden, wird Protokoll geführt, so daß der Anwender die Ausführungsschritte überprüfen kann. Der Zeitereignismanager selbst benutzt die Timer-Funktion des Be-triebssystems, die über die API-Schnittstelle bereit gestellt wird, um Aufgaben in der Zukunft zu planen. Nachdem ein TE-Trigger verarbeitet wurde, wird sein Status geän-dert. Dies geschieht in einer Routine namens Change Status, die im folgenden vorge-stellt wird.

TE.ChangeStatus

TE.isAbsolute

FALSE

TRUE

TE.beDone = TRUE

TE.computeNextExecution

TE.isPeriodic

FALSE

TRUE

t2 := Date(TE.EndOnDate, TE.EndOnTime)

t1 > t2

t1:= TE.nextExecution

FALSETE.beDone = FALSE

TRUE

TE.ChangeStatusTE.ChangeStatus

TE.isAbsolute

FALSE

TRUE

TE.beDone = TRUE

TE.computeNextExecution

TE.isPeriodic

FALSE

TRUE

t2 := Date(TE.EndOnDate, TE.EndOnTime)

t1 > t2

t1:= TE.nextExecution

FALSETE.beDone = FALSE

TRUE

Abbildung 7.5: PAP Change Status

Change Status: Die Zeitereignisse, auf welche ARTA II-Trigger reagieren können, sind absolute und periodische Zeitereignisse. Der Time Event Manager verarbeitet die Trigger vom Typ periodisches Zeitereignis (PTE-Trigger) und die vom Typ absolutes Zeitereignis (ATE-Trigger) bis auf einen Unterschied in gleicher Weise. Der Unter-schied besteht darin, daß nach Abarbeitung eines PTE-Triggers sein nächster Ausfüh-


68

rungstermin berechnet wird, während ATE-Trigger nach der Abarbeitung sofort als ab-gearbeitet (beDone=TRUE) markiert werden. Nach der Berechnung des nächsten Aus-führungstermins, wird für einen PTE-Trigger überprüft, ob sein berechneter Ausfüh-rungstermin innerhalb des angegebenen Gültigkeitsintervalls liegt. Zur Ermittlung wird das Intervallende mit dem Ausführungszeitpunkt verglichen. Ist der Ausführungstermin echt kleiner, so wird dieser noch ausgeführt, ansonsten wird der Trigger als abgearbeitet markiert.

ProcessNewTimeEvents: Diese Routine führt zunächst eine Initialisierung durch. Da-bei wird unter anderem der Timer initialisiert, auch wenn zuvor bereits einer gesetzt wurde. Anschließend wird eine Anfrage (getNextTE) an die DB gestellt, um anhand der Priorität und dem Ausführungstermin, den nächsten TE-Trigger zu ermitteln. Falls es keinen Trigger gibt, der ausgeführt werden soll, wird ein interner Timer (auf 24 Stun-den) gesetzt, so daß nach Ablauf des Timers erneut mit der Ermittlung begonnen wird. Wird jedoch ein Trigger gefunden, so wird für diesen ein Timer zum nächsten Ausfüh-rungstermin gesetzt. Sobald sich der Timer meldet, was unter Umständen eine Weile dauern kann, muß festgestellt werden, ob es sich beim zuvor gesetzten Timer um einen internen oder normalen Timer gehandelt hat. Handelte es sich um einen normalen Ti-mer, so wird dieser an die Ausführungskomponente (TE.doAction) weitergereicht. Nach der Abarbeitung des Triggers durch die Ausführungskomponente, wird ein Eintrag in die Protokolltabelle geschrieben, der Status des Triggers geändert (ChangeStatus) und dieser anschließend aus der Datenbank gelöscht, falls er zuvor als abgearbeitet markier-ten wurde. Anschließend wird der Time Event Manager neu gestartet, um den nächsten TE-Trigger zu ermitteln.

TE:= (SELECT TimeEventTrigger FROM tbl_TriggerWHERE Trigger.nextExecution + Trigger.Deadline > Now()AND Trigger.beDone = FALSEAND Trigger.activated = TRUE

ORDER BY Max (Trigger.priority))

TRUE

processNewTimEventprocessNewTimEvent

TE:= getNextTE

wait until Timer bells

FALSE

TE = ØFALSE

TRUETE.doActionTE.doAction


TE = Ø

initAllTE

processOldTimeEventsprocessOldTimeEvents

writeLog (TE)writeLog (TE)

setTimer (TE.nextExecution)

deleteBeDoneTriggerdeleteBeDoneTrigger

setTimer (one Day)

Abbildung 7.6: PAP ProccesNewTimeEvent


69

Bei der Erstellung eines neuen TE-Triggers durch den Anwender, kann es vorkommen, daß der neue TE-Trigger vor dem TE-Trigger ausgeführt werden soll, für den schon ein Timer gesetzt wurde. Um dieses Problem in den Griff zu bekommen, muß nach der Er-stellung oder Modifizierung eines TE-Triggers der Time Event Manager vom Trigger Manager neu gestartet werden. Dabei wird der Timer neu initialisiert. Da die Trigger in der Datenbank immer aktuell sind (z.B. nach dem Erstellen oder Modifizieren eines Triggers durch den Trigger Manager), stehen beim Start dieser Komponente immer die aktuellen Trigger zur Verfügung. Die abgespeicherten Trigger in der Datenbank dienen dem Time Event Manager als aktuelle Ausführungsliste, da bei jedem TE-Trigger der nächste Ausführungstermin und seine Priorität bekannt sind.

Bei der Abarbeitung eines TE-Triggers kann die folgende Situation eintreten: Zum Zeit-punkt 13.04.2005 um 9:00 sollen drei TE-Trigger gefeuert werden. Dieser Zeitpunkt wird als Soll-Ausführungszeitpunkt bezeichnet. Die Ausführungsreihenfolge ist auf-grund der eindeutigen Priorität für jeden Trigger gegeben. Es darf immer nur ein Trig-ger gleichzeitig ausgeführt werden. Die Abarbeitungsreihenfolge ist durch die Priorität der Trigger gegeben. So sollen Tr1 vor Tr2 und Tr2 vor T3 ausgeführt werden. Da im-mer nur ein Trigger gleichzeitig abgearbeitet werden darf und erst mit Beendung der Abarbeitungszeit eines Triggers der nächste zum Zuge kommt, kann es zum folgenden Problem kommen.

Angenommen der erste Trigger habe eine Deadline von 60, der zweite eine von 120 und der dritte eine von 180 Minuten. Da die Bearbeitungszeit eines Triggers nach dessen Feuern unterschiedlich lang ausfallen kann, ist nie genau vorhersagbar, wann dieser seine Arbeit beendet.

Abbildung 7.7: Ausführungszeitpunkt

Wenn der erste Trigger seine Arbeit um 9:00 Uhr beginnt und sie erst um 11:05 been-det, findet die Routine getNextTE den dritten Trigger, während der zweite ignoriert wird, da dieser nur bis 11:00 Uhr ausgeführt werden durfte. Da der ignorierte Trigger nicht gefunden wurde, wurde sein Zustand durch die Routine ChangeStatus auch nicht geändert. D.h. er wurde nicht als abgearbeitet markiert, es fand kein Protokolleintrag statt und der Trigger wurde nicht aus der Datenbank gelöscht. Eine Lösung des Prob-lems liegt nahe. Nach Abarbeitung der Trigger müssen eventuell nicht abgearbeitete

Tr1

Tr1 Tr2 Tr3

09:00 10:00 11:00 12:00

Deadline

Tr2

Tr3 tt

Tr1.priorität = 1

Tr2.priorität = 2

Tr3.priorität = 3

Abarbeitungszeit benötigte

t

Soll-Ausführungszeitpunkt aller drei Trigger

Ist-Ausführungszeitpunkt aller drei Trigger


70

allTE = List of Time EventWHERE Trigger.nextExecution < NowAND Trigger.beDone = FALSEAND Trigger.activated = TRUE

und noch aktive Trigger gesammelt und behandelt werden. Dies geschieht mit einer Routine namens processOldTimeEvents, die im folgenden Abschnitt vorgestellt wird. Ein weiterer Grund für die Erstellung dieser Routine wird klar, wenn folgende Situation betrachtet wird:

Das ARTA-System kann in seiner Ruhepause, d.h. zu den Zeiten, zu denen das System ausgeschaltet ist, nicht auf eintretende vordefinierte Zeitereignisse reagieren. Diese Re-aktion sollte nach dem Start des Systems erfolgen. Dafür benötigt man eine Routine, die die „alten“ TE-Trigger sammelt und gegebenenfalls ausführt.

ProcessOldTimeEvents: Mit getAllOldTimeEvents werden alle TE-Trigger aus der Datenbank geladen, dessen Ausführungszeitpunkte in der Vergangenheit liegen. Außer-dem müssen diese Trigger aktiviert und der Bearbeitungsstatus (BeDone) auf FALSE gesetzt sein. Nach der Ermittlung dieser Liste wird überprüft ob diese leer ist. Falls ja, so gibt es keine „alten“ TE-Trigger und die Routine ist beendet. Falls die Liste nicht leer ist, so wird der erste TE-Trigger aus der Liste genommen und bearbeitet. Liegt der Zeit-raum, in dem der Trigger ausgeführt werden soll in der Vergangenheit, so wird dieser Trigger als abgearbeitet markiert, protokolliert und aus der Datenbank gelöscht. Liegt der Zeitraum in der Zukunft, so wird der Aktionsteil des Triggers, nach erfolgreicher Auswertung der Triggerbedingung, ausgeführt und sein Status anschließend geändert. Nachdem ein Trigger abgearbeitet wurde, wird der nächste aus der Liste genommen, bis diese komplett leer ist.

nextT > Now

TRUE

TRUE

processOldTimeEvents

allTE:= getAllOldTimeEvents

TE := allTE.first

nextT := TE.nextExecution + TE.deadLine

FALSE

allTE = Ø

FALSE

TE.condis OK

TRUE

FALSE

TE.doAction

TE.ChangeStatus

processNewTimEvent

deleteBeDoneTrigger(TE)

TE:= allTE.MoveNext

writeLog (TE)

nextT > Now

TRUE

TRUE

processOldTimeEventsprocessOldTimeEvents

allTE:= getAllOldTimeEvents

TE := allTE.first

nextT := TE.nextExecution + TE.deadLine

FALSE

allTE = Ø

FALSE

TE.condis OK

TRUE

FALSE

TE.doActionTE.doAction


processNewTimEventprocessNewTimEvent

deleteBeDoneTrigger(TE)deleteBeDoneTrigger(TE)

TE:= allTE.MoveNext

writeLog (TE)writeLog (TE)

Abbildung 7.8: Process old time events


71

Die doAction-Routine (siehe Abbildung 6.15) sorgt dafür, daß die Ausführung des Triggers nicht durch den Benutzer unterbrochen wird. Dafür wird im Hintergrund ein Formular geöffnet, das ein Schließen von ARTA II verhindert. Nach Beendigung des Prozesses wird das Formular wieder geschlossen. Mit BeginTrans wird eine neue Transaktion gestartet. Anschließend wird der Trigger an die Ausführungskomponente weitergereicht. Tritt bei der Abarbeitung ein Fehler auf, so wird die komplette Transak-tion mit Rollback zurückgesetzt. Mit CommtTrans wird nach einer erfolgreichen Aus-führung des Triggers, die Änderungen in die Datenbank geschrieben. Im folgenden Ab-schnitt wird die Ausführungskomponente genauer beschrieben, die in dieser Routine durch TEC.executeSQL-Statement(TE.action) gestartet wird. Diese Routine gehört zur Trigger Execution-Komponente.

7.4 Trigger Execution Diese Komponente dient der Verarbeitung eines SQL-Statements, das entweder vom Time Event Manager oder aus einer manuellen Eingabe über den SQL-Statement Ter-minal an die Triggerausführungskomponente weitergereicht wurde. Die Abarbeitung des SQL-Statements kann, wie zuvor erwähnt, zu Triggerkaskaden führen. Eine Abar-beitungsstrategie ist hier von relevanter Bedeutung.

Trigger

SQLSQL-Statement

ManagerTime Event Manager

Log

TEC.initTEC(SQL)TEC.initTEC(SQL)

ExecuteBeforeOrAfterTrigger(Before,SQL)ExecuteBeforeOrAfterTrigger(Before,SQL)

executeAction (SQL)

ExecuteBeforeOrAfterTrigger(After, SQL)ExecuteBeforeOrAfterTrigger(After, SQL)

TRIGGER EXECUTION

Abbildung 7.9: Triggerausführungskomponente

Als erstes werden alle Before-Trigger, die vom SQL-Befehl gefeuert werden, gesam-melt, nach ihrer Priorität sortiert und anschließend ausgeführt. ARTA II-Before-Trigger dürfen keine weiteren Trigger feuern, so daß das Problem der Triggerkaskade nur bei der Bearbeitung der After-Trigger aufkommen kann. Nachdem alle Before-Trigger aus-geführt wurden, wird das eigentliche SQL-Statement ausgeführt. Letztlich werden alle After-Trigger, die nach ihrer Priorität sortiert werden, gesammelt und verarbeitet. Das Ausführen eines After-Triggers kann ein weiteres Auslösen von Triggern zur Folge ha-ben. Die Abarbeitung erfolgt rekursiv, so daß die Verarbeitung zuerst in die Tiefe geht.


72

allTrs = Ø

allTrs := allModifyEvent.getTriggers & _(ActionTime,modificationType,tablename)

TRUE

FALSE

FALSETRUE

ExecuteBeforeOrAfterTrigger(ActionTime, SQL)ExecuteBeforeOrAfterTrigger(ActionTime, SQL)

Tr := allTrs.First

Tr isRow

allTrs.Remove(Tr)

TEV:= ATEVs.MoveNextallTrs= Ø

TRUE FALSE

ExecuteStatementLevelTrigger(Tr)ExecuteStatementLevelTrigger(Tr)

ExecuteRowLevelTrigger(Tr)ExecuteRowLevelTrigger(Tr)

TEC. executeSQL_Statement (SQL)TEC. executeSQL_Statement (SQL)

TEC.initTEC(SQL)TEC.initTEC(SQL)

ExecuteBeforeOrAfterTrigger(Before, SQL)ExecuteBeforeOrAfterTrigger(Before, SQL)

executeAction (SQL)executeAction (SQL)

ExecuteBeforeOrAfterTrigger(After, SQL)ExecuteBeforeOrAfterTrigger(After, SQL)

Sind alle Trigger einer Ebene abgearbeitet, so erfolgt die Bearbeitung der Trigger der darüberliegenden Ebene. Die Routine TEC.executeSQL_Statement, (Abbilung 7.10), ist die Routine die rekursiv bei der Abarbeitung der Trigger ausgelöst wird.

Abbildung 7.10: executeSQL-Statement-Routine

Abbildung 7.11 zeigt die Routine, mit der alle Before- und After-Trigger bearbeitet werden. Abbildung 7.12 und Abbildung 7.13 zeigt die Bearbeitung der Row- und Sta-tement Lever-Trigger.

Abbildung 7.11: ExecuteBeforeOrAfterTrigger-Routine


73

tec.EOLTRUE

FALSE

Call ExecuteAction(tec.makeAction(Tr)

tec.MoveNextRow

ExecuteRowLevelTrigger(Tr)ExecuteRowLevelTrigger(Tr)

tec.cond(Tr)

TRUE

FALSE

tec.MoveFirstRow

Abbildung 7.12: ExecuteRowLevelTrigger-Routine

Call ExecuteAction(tec.makeAction(Tr)

ExecuteStatementLevelTrigger(Tr)ExecuteStatementLevelTrigger(Tr)

TRUE

FALSE tec.cond(Tr)

Abbildung 7.13: ExecuteStatementLevelTrigger-Routine


74

Die letzte Routine die hier vorgestellt wird ist Routine, mit der der Aktionsteil ausge-führt wird. Vor der Ausführung, wird das Statement auf seine Korrektheit hin überprüft.

Abbildung 7.14: ExecuteAction-Routine

executeAction (action)executeAction (action)

isNull(action)

isValid(action)

LOGFILE:„Aktionsteil ist leer“

CurrentDB.Execute action

FALSE

TRUE

TRUE

FALSE

LOGFILE:„Ausführung des Aktionsteils“

LOGFILE:„Aktionsteil ist ungültig “

Erweiterungskonzepte für das aktive DBMS GUI

75

Kapitel 8 GUI

GUI

Die grafische Benutzeroberfläche ist eine der wesentlichen Erweiterungen des ARTA II-Systems. Ziel war es, übersichtliche Benutzeroberflächen zu implementieren, so daß der Benutzer sich ohne großen Aufwand schnell zurecht finden kann. Der Benutzer soll interaktiv mit den Masken agieren. Dazu wurden alle Oberflächenobjekte möglichst selbstsprechend eingesetzt um eine einfache und fehlerfreie Generierung eines Triggers zu ermöglichen. Benutzerfreundlichkeit und einfache Bedienung standen bei der Imp-lementierung der grafischen Benutzeroberflächen an höchster Stelle.

Die Schemakomponenten, die den logischen Teil der Benutzeroberflächen bilden, sind der Trigger-, Event Log-, Event Type- und SQL-Statement Manager. Diese liegen in Form von Ereignis- und Anwendungsprozeduren vor. Mit ihrer Hilfe werden Eingabe-überprüfungen, interne Berechnungen, Meldungen, Protokollierungen sowie Datensatz-operationen durchgeführt.

Ein Beispiel für eine Berechnung, die der Trigger Manager ausführt, ist die Kalkulation des nächsten Ausführungstermins eines Triggers, anhand der eingestellten Periode (gilt nur für Trigger vom Typ periodisches Zeitereignis) oder die Gültigkeitsüberprüfung des eingestellten Gültigkeitsintervalls (siehe Trigger Editor). Einfache Eingabeüberprü-fungen werden über die Gültigkeitsüberprüfung realisiert, die die Steuerelemente selbst anbieten.

8.1 ARTA II-Menüstruktur Für ARTA II wurden verschiedene grafische Benutzeroberflächen implementiert, die die Arbeit mit den ARTA II-Triggern erleichtern sollen. In diesem Abschnitt wird eine kurze Übersicht über die ARTA II- Menüstruktur gegeben und ihre Aufrufstruktur ge-zeigt. In den folgenden Abschnitten werden die einzelnen Benutzeroberflächen vorge-stellt.

Beim Start von ARTA II gelangt man zum ARTA II-Hauptfenster. Dieses Fenster wird erst mit der Beendung von ARTA II geschlossen. Vom Hauptfenster aus gelangt man zur Trigger- und Ereignismusterübersicht, sowie zum SQL-Statement Terminal.

Die Triggerübersichtsoberfläche dient der Anzeige aller vorhandenen Trigger. Es kann ein speziell ausgewählter Trigger betrachtet werden. Ist dieser vom Typ Zeitereig-nis, so wird auch der nächste Ausführungszeitpunkt angezeigt, da diese im voraus be-rechnet werden. Aus dieser Maske heraus ist es auch möglich einen Trigger zu löschen. Möchte man einen Trigger neu anlegen oder einen existierenden bearbeiten, so kann von hier aus der Triggereditor aufgerufen werden.


76

SQL-Statement-TerminalSQL-Statement-TerminalEreignismusterübersichtEreignismusterübersichtTriggerübersichtTriggerübersicht

SQL-StatementeditorTriggereditor EreignismustereditorEreignismustereditor

Hauptfenster

Abbildung 8.1: ARTA II-Menüstruktur

Der Triggereditor ist die wichtigste Benutzeroberfläche von ARTA II. Aus dieser O-berfläche heraus können Trigger auf eine recht einfache Art und Weise erstellt werden ohne daß der Benutzer die genaue Syntax eines Triggers kennen muß. Dazu mehr in den folgenden Abschnitten.

Wie erwähnt gelangt man aus dem ARTA II-Hauptfenster in die Ereignismusterüber-sicht. Sie dient der Anzeige aller Trigger gruppiert nach ihrem Ereignistyp. So erhält man z.B. eine Übersicht über alle Trigger, die am ersten Sonntag des Monats gefeuert werden sollen. Oft benutze Ereignistypen sollten als Ereignismuster definiert werden, was der Übersichtlichkeit zu Gute kommt.

Über einen Ereignismustereditor können Ereignismuster geändert, neue erstellt oder gelöscht werden. Das Anlegen eines Ereignismusters kann auch beim Anlegen eines Triggers erfolgen.

Die SQL-Statementoberfläche, die auch aus dem ARTA II-Hauptfenster heraus aufge-rufen werden kann, bietet dem Benutzer die Möglichkeit, Befehle in Form von SQL-Statements „direkt“ an die Datenbank abzusetzen. Dieses Fenster bietet eine Art Termi-nal an, um SQL-Befehle einzugeben und auszuführen. Jeder Befehl, der über das Ter-minal eingegeben wurde, wird vom ARTA-System zur Ereigniserkennung abgefangen. Nur so kann eine korrekte Triggerverarbeitung sichergestellt werden. Um die Eingabe


77

eines SQL-Befehls zu erleichtern, können SQL-Befehle abgespeichert werden so daß sie bei der Eingabe als Auswahlliste zur Verfügung stehen. Die Erstellung, Modifizie-rung und Löschung eines SQL-Statements erfolgt über den SQL-Statement Editor, der von der SQL-Statementoberfläche aus aufgerufen werden kann.

8.2 Triggerübersichtsoberfläche

Abbildung 8.2: Triggerübersicht

Dieses Fenster ist in zwei Bereiche unterteilt. Im oberen Bereich ist eine Übersichtsliste aller vorhandenen Trigger implementiert worden. Die wichtigsten Angaben dieser Liste sind der Triggername, Triggertyp und der nächste Ausführungszeitpunkt bei einem Trigger vom Typ Zeitereignis. Wird ein Trigger aus der Liste markiert, so erscheinen seine Einstellungen im unteren Bereich des Fensters. Hier werden detaillierte Informati-onen zum ausgewählten Trigger angezeigt. Wichtig ist dabei, daß der Aufbau der An-zeige, der Triggersyntax nahezu entspricht. Dieser Teil des Fensters wurde wiederum in vier Teilbereiche unterteilt. Bereich 1 stellt das triggernde Ereignis, Bereich 2 die Aus-lösebedingung, Bereich 3 die zu triggernde Aktion und Bereich 4 die Steuerelemente dar. Im unteren Rand der Oberfläche wurde ein Kommentarfeld integriert, in das Be-merkungen zum Trigger angezeigt werden.

1

2

3

4


78

8.3 Triggereditor

Abbildung 8.3: Triggereditor

Der Triggereditor ist wie bereits erwähnt die wichtigste Benutzeroberfläche des ARTA II-Systems. Mit ihm lassen sich Trigger erstellen und modifizieren. Darüber hinaus läßt sich das zu triggernde Ereignis, einmal eingegeben, als Ereignismuster speichern.

Der Triggereditor ist in fünf Bereiche unterteilt. In Bereich 1 kann ein Triggername vergeben und das Gültigkeitsintervall eingestellt werden. Bei der Eingabe des Gültig-keitsintervalls wird, mit Hilfe einer Kalenderfunktion, die Eingabe wesentlich erleich-tert. Der Trigger Manager prüft das eingegebene Gültigkeitsintervall auf seine Richtig-keit. Es ist z.B. nicht möglich ein Intervallende anzugeben, das vor dem Intervallstart liegt.

Abbildung 8.4: Bereich 1

1 2

4

3

5


79

In Bereich 2 wird der Triggertyp ausgewählt. Hier kann aus einer Auswahlliste auf be-reits vorhandene Ereignismuster zurückgegriffen werden.


In Bereich 3 wird das zu triggernde Ereignis eingestellt. Abhängig vom gewählten Er-eignistypen ergeben sich verschiedene Einstellungsmöglichkeiten. In den folgenden zwei Abbildungen sind ein Änderungsereignis und ein periodisches Zeitereignis vom Typ Jahr dargestellt.

Abbildung 8.6: Bereich 3: Änderungsereignis

Abbildung 8.7: Bereich 3: periodisches Zeitereignis vom Typ Jahr

Bereich 3 ist der wohl wichtigste, was die Gestaltung der Oberfläche betrifft. Bei der Gestaltung wurde der Aspekt der Benutzerfreundlichkeit nicht nur für den Anwender, sondern auch für den Entwickler in Betracht gezogen. Es müssen eine große Anzahl an Steuerelementen, abhängig vom ausgewählten Ereignistyp oder der Periode, ein- bzw. ausgeblendet werden. In den folgenden Abbildungen soll verdeutlicht werden wie groß

die Anzahl an Steuerelementen ist, die verwendet werden. Bei so einer großen Anzahl an Steuerelementen taucht das folgende Problem auf. Wie legt man diese Anzahl an Objekten so an, daß sie für einen Benutzer in der Formularansicht eine benutzerfreund-


80

liche Eingabe erlauben und im Formularentwurf dem Entwickler ein einfaches Ändern der Objekte ermöglichen. Es mußte für den Entwickler eine Möglichkeit gefunden wer-den die Steuerelemente auf dem Formular so anzubringen, daß diese nicht übereinander liegen. So müssen bei einer Änderung an einem Steuerelement nicht alle darüberliegen-den verschoben werden, was die Übersichtlichkeit beim Formularentwurf sehr beein-trächtigen würde.

Abbildung 8.8: verschieden Einstellungen für Bereich 3

Die Lösung dieses Problems war die Benutzung eines Registersteuerelementes, was hierfür zweckentfremdet wurde. Der Anwender bekommt davon nichts mit, da es für ihn stets unsichtbar geschaltet ist. Der Entwickler hingegen benutzt dieses Registersteuer-element, um die verschiedenen Steuerelemente, die zu einem Ereignistyp und gegebe-nenfalls zu einer Periode gehören, zusammenzuhalten. Die Reiter des Registersteuer-elementes sind nach Typ bzw. Periode bezeichnet, was in der folgenden Abbildung ver-deutlicht wird.


81

Abbildung 8.9: Registersteuerungselement, Seite Jahr

In Bereich 4 wurden aus Platzgründen die Ausführungsbedingung, die zu triggernde Aktion sowie ein Kommentarfeld in ein Registersteuerelement untergebracht. An den Reitern kann zwischen den dreien ausgewählt werden. Um eine komfortablere Eingabe zu ermöglichen, kann über eine Befehlsschaltfläche (Button) ein Editierfenster geöffnet werden, was wesentlich mehr Platz und Übersicht bei der Erstellung einer Bedingung oder auch eines Kommentars bietet.


Bereich 5 ermöglicht die Modifikation der Deadline, die beim Erstellen eines Triggers automatisch auf fünf Minuten gesetzt wird. Des weiteren kann eine Priorität für den Trigger, sowie sein Aktivierungszustand verändert werden. Der Defaultwert für die Pri-orität ist die nächst höher verfügbare Priorität und der Default-Aktivierungszustand ist auf aktiviert gesetzt.


Befehlsschaltfläche

Eingabefenster


82

8.4 SQL-Statement Terminal Mit Hilfe dieser Benutzeroberfläche können SQL-Befehle direkt an die Datenbank ge-stellt werden. Das mittlere Fenster zeigt das Eingabefenster für die SQL-Befehle. Im oberen Bereiche des Fensters ist eine Auswahlliste integriert, aus der vordefinierte SQL-Statements ausgewählt werden können. Über einen Editor, der sich von diesem Fenster aus öffnen läßt, können SQL-Statements vordefiniert oder geändert werden.

Abbildung 8.12: SQL-Statement Terminal


83

Zusammenfassung

In dieser Arbeit wurde das bestehende ARTA-System weiterentwickelt. Die Trigger-sprache von ARTA II basiert auf der SQL-3-Triggersprache mit dem Unterschied, daß in ARTA II nicht nur Änderungsereignisse, sondern auch Zeitereignisse unterstützt werden. Dazu wurde die Syntax der SQL-3-Triggersprache um Zeitereignisse und Steu-erungselemente erweitert. ARTA II kann auf absolute und auf periodisch eintretende Zeitereignisse reagieren. Die Synchronisation der Abarbeitungsmechanismen von Ände-rungs- und Zeitereignissen ist dabei von relevanter Bedeutung.

Zeitereignisse sind im Gegensatz zu Änderungsereignissen prä-aktiv, d.h. sie werden im voraus anhand der berechneten Ausführungszeitpunkte geplant. Für den jeweils nächs-ten Ausführungstermin eines Triggers vom Typ Zeitereignis wird ein Timer gesetzt. In ARTA II wird die Timerfunktionalität des Betriebssystems genutzt, die über eine API-Schnittstelle mit ARTA II kommuniziert, da Microsoft Access keine Timerfunktionali-tät besitzt. Datenbankänderungen hingegen sind post-aktiv, d.h. daß der nächste Ausfüh-rungszeitpunkt einer Änderungsanweisung nicht bekannt ist und somit eine Ereigniser-kennung nur über ein „pollendes“ System zu erkennen ist. Die Nachteile dieses Vorge-hens liegen in der Ereigniserkennung. Ein zu häufiges Anfragen der Datenbank kann zur Systemüberlastung führen, während ein zu seltenes Anfragen dazu führen kann, daß der Zeitpunkt, zu dem eine Datenbankänderung stattfindet, nicht erkannt wird. Dieses Problem wurde gelöst, indem das ARTA-System als Präprozessor implementiert wurde. Alle Eingaben des Benutzers gehen über die ARTA II-Benutzeroberflächen, wo sie vom System erkannt, ausgewertet und verarbeitet werden.

ARTA-II wurde, vor allem was die Benutzeroberflächen anbetrifft, enorm erweitert. Der Benutzer wird beim Umgang mit Triggern aktiv unterstützt. Die grafisch aufbereite-ten Eingabemasken erlauben den sicheren Umgang mit Triggern. Mittels des Trigger-, Ereignismuster-, Ereignisprotokoll- und SQL-Statementmanagers, werden die Verwal-tungsaufgaben des Systems realisiert. Diese Schemakomponenten sind die Logik, die sich hinter den Benutzeroberflächen verbirgt. So führt der Trigger Manager bei Eingabe oder Änderung eines Triggers Syntaxüberprüfungen durch, so daß Fehleingaben vom Benutzer direkt abgefangen und korrigiert werden können. Eine Triggerübersicht gibt Auskunft über anstehende Ausführungstermine, was den Umgang mit den angelegten Triggern sehr erleichtert. Über einen Protokollmanager, der die Ereignisprotokollierung verwaltet, kann zu jeder Zeit nachvollzogen werden, welche Trigger ausgeführt wurden und welche nicht. Ein Event Type Manager verwaltet vordefinierte Ereignismuster und zeigt überdies alle Trigger an, die ein solches Muster besitzen. Oft benutzte Ereignisde-klarationen beim Anlegen eines Triggers können gesondert als Ereignismuster in die Datenbank gespeichert werden, um bei Neuerstellung eines Triggers auf eben diese vor-definierten Ereignismuster zurückgreifen zu können. Der SQL-Statement Manager dient der Verwaltung vordefinierter SQL-Statements. Um SQL-Statements nicht immer wie-der neu angeben zu müssen, können diese in die Datenbank gespeichert werden. Möchte man ein SQL-Statement ausführen, das einem bestehenden Statement ähnelt, so genügt es, ein bestehendes zu modifizieren.


84

Ausblick auf mögliche Erweiterungen

ARTA II unterstützt zwei primitive Ereignisse. Die absoluten und die periodischen Zeitereignisse. Es gibt noch einen dritten Ereignistyp und zwar den der relativen Zeit-ereignisse. Diese wurden leider aus zeitlichen Gründen nicht in ARTA II implemen-tiert.

Eine interessante Erweiterung des ARTA II-Systems wäre die Implementierung von zusammengesetzten Ereignissen, bei denen zwei oder mehrere Ereignisse kombiniert werden. Zusammengesetzte Ereignisse können wiederum mit anderen primitiven oder zusammengesetzten Ereignissen kombiniert werden. Um diese Aufgabe zu lösen ist es wichtig, ein Ereignisprotokoll zu führen, um festzustellen, welche Ereignisse bereits eingetroffen sind. So kann berechnet werden, welche Ereignisse noch fehlen, um ein zusammengesetztes Ereignis auszulösen. Ein weiterer wichtiger Aspekt ist der Ereignis-verbrauch. Diese Problematik wird in den Arbeiten von [Modic00] und [Löhr97] aus-führlich behandelt.

In Microsoft Access ist es möglich, gewisse Integritätsbedingungen anzugeben. Bei der Erstellung einer Tabelle können Schlüssel vergeben und Gültigkeitsregeln für einzelne Attribute einer Tabelle angegeben werden, was den CHECK CONTRAINTS in SQL entspricht. Über das Beziehungskonzept von MS-Access kann eine referenzielle Integri-tät gesetzt werden, wodurch Änderungen an Tabellen kaskadenförmig weitergereicht werden können. Man hat jedoch keine Möglichkeit SQL-artige Integritätsbedingungen auszudrücken, da die Integritätsprüfung in MS-Access unmittelbar nach einer Änderung (immediate) stattfindet. Es gibt jedoch Transaktionsänderungen, bei denen man nicht sofort eine Integritätsprüfung vornehmen möchte. Bei einer Einfügung zum Beispiel, die zunächst einen Zustand verletzt, aber durch eine folgende Transaktion diesen wieder repariert. Würde die Überprüfung nach dem Einfügen stattfinden und nicht am Ende der kompletten Transaktion, so würde das System einen Fehler melden. Will man in MS-Access deferred ausdrücken, so muß dies mit Triggern erfolgen. Es muß ein Transakti-onskonzept für die ARTA-Trigger implementiert werden.


85

Literaturverzeichnis

[Löhr97] Torsten Löhr. „Eine Erweiterung der aktiven Regelsprache Phoenix um temporale Ereignisse, Deadlines und Alternativen.“ Rheinische Friedrich – Wilhelms – Universität Bonn, 1997

[Modic00] Jürgen Modic. „Eine Erweiterung des Triggerkonzeptes von Phönix um temporale Ereignisse.“ Rheinische Friedrich – Wilhelms – Universität Bonn, 2000

[Fortier99] Dr.Paul J. Fortier. „SQL – 3 Implementing the Object – Relational Data-base.” Chapter 10 (Triggers). McGraw – Hill 1999

[MeSi02] Jim Melton and Alan R.Simon. „SQL:1999 Understanding Relational Lan-guage Components.” Chapter 11 (Active Databases and Triggers). Morgan Kaufmann Publishers. 2002

[Fadaei02] Kazem Fadaei. „Entwurf und Implementierung einer Triggersprache mit Zeitereignissen für Access – Datenbanken.” Rheinische Friedrich – Wil-helms – Universität Bonn, 2002

[DiGa00] Dittrich, Klaus R. / Gatziu, Stella: Aktive Datenbanksysteme – Konzepte und Mechanismen, ISBN 3-932588-19-3, 2.Auflage, April 2000, dpunkt-Verlag.

[Mos85] J.B.E. Moss. Nested Tranactions: An approach to Reliable Destributed Computing. MIT Press, Cambridge, Mass. , 1985

[ToPy98] Thomas Pydde. Semantik von Regelsystemen für aktive Datenbanken In-stitut für Informatik Fachgebiet Datenbanken und Informationssysteme, Dezember 1998

[NiJo92] Niedereichholz, Joachim.: Datenbanksysteme - Konzepte und Manage-ment. 5.Auflage. Physica-Verlag Heidelberg, 30. März 1992

[DCha98] D. Chamberlin: A Complete Guide to DB2 Universal Database, Morgan Kaufmann, 1998

[HoSP] Hoffbauer, N./Spielmann Chr., Das Access 97 Buch (1997) umfaßt 1462 Seiten, inkl. CD-Rom>>Sybex-Verlag GmbH, Düsseldorf

[HoCo99] C. Horstmann, G. Cornell: Core Java Volume II-Advanced Features, Pren-tice-Hall, 1999

[JoVi96] Übersetzt von John Viescas: Microsoft Access für Windows 95. ISBN 3-86063-121-7, 1996, Microsoft Press.

[JeRe02] Egbert Jeschke / Helmut Reinke : ACCESS 2002 EINFÜHRUNG, ISBN: 3-902062-33-9, Redmonds Anwendertraining

[WiPe] http://wikipedia.t-st.de/

[AbIt] http://www.aboutit.de/index.html

[MS-Ac00] Microsoft Access 2002 Hilfe (10.2616.2625)


86

Anhang

Erweiterungskonzepte für das aktive DMS ARTA Anhang

Seite A 87

trigger event type

periodic time event type (period)SEE NEXT PAGE

modification event type

FOR EACH STATEMENT

FOR EACH ROW

trigger action time

BEFORE

AFTER

CREATE TRIGGER trigger name priority

trigger interval

START ON ATEND ONATdate datetime time

deadline

table nameON

modification type

UPDATE

INSERT

DELETE


ATON date time

NEW

OLD STATEMENT

AS

ASREFERENCING

tupel name

(DO)WHEN condition action

ROW

relation name

Erweiterungskonzepte für das aktive DMS ARTA Anhang

Seite A 88

trigger event type

periodic time event type (period)



(DO)WHEN condition action

hours event type

2digitEVERY HOURS AT

minutes event type

minutesEVERY MINUTES

minutes MINUTES PAST

days event type

3digitEVERY AT

weeks event type

2digitEVERY WEEKS ON day of week AT time

years event type

2digitEVERY YEARS ON

ordined dayAT time


month of year

months event type

2digitEVERY MONTHS ON

AT time

DAY

EVERY

ordined 1stTo5th

ordined digit day

day of week

day of week

time

trigger event type

periodic time event type (period)



(DO)WHEN condition action(DO)WHEN condition action

hours event type

2digitEVERY HOURS AT

minutes event type

minutesEVERY MINUTES

minutes MINUTES PAST

days event type

3digitEVERY AT

weeks event type

2digitEVERY WEEKS ON day of week AT time

years event type

2digitEVERY YEARS ON2digitEVERY YEARS ON

ordined dayAT time


month of year

months event type

2digitEVERY MONTHS ON2digitEVERY MONTHS ON

AT time

DAY

EVERY

ordined 1stTo5th

ordined digit day

day of week

day of week

time

Documents

Erweiterungskonzepte für das aktive Datenbanksystem ARTA · Rheinische Friedrich – Wilhelms – Universität Bonn Institut für Informatik III Erweiterungskonzepte für das aktive