ARTA Entwurf und Implementierung einer Triggersprache mit ... · Rheinische...

Rheinische Friedrich-Wilhelms-Universitat BonnInstitut fur Informatik III

ARTAEntwurf und Implementierung einer Triggersprache mit

Zeitereignissen fur Access-Datenbanken

Diplomarbeit vonKazem Fadaei

August 2002

Betreuer: Prof. Dr. Rainer Manthey

Inhaltsverzeichnis

1 Einleitung 1

2 Grundlagen von Datenbanken 52.1 Aktive Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Trigger in SQL3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.1 Syntax von SQL3-Triggersprache . . . . . . . . . . . . . 112.2.2 Semantik von SQL3-Triggersprache . . . . . . . . . . . . 13

3 Visual Basic for Applications 173.1 Sprachgrundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2 Module, Klassenmodule und Objekte . . . . . . . . . . . . . . . 203.3 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.4 Fehlerbehandlung in VBA . . . . . . . . . . . . . . . . . . . . . 263.5 Transaktionen in VBA . . . . . . . . . . . . . . . . . . . . . . . 29

4 MS-Access 314.1 Tabellen und Beziehungen . . . . . . . . . . . . . . . . . . . . . 314.2 Formulare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.3 Datenzugriffsobjekte . . . . . . . . . . . . . . . . . . . . . . . . 364.4 Sicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5 Konzept 395.1 Das Konzept eines Praprozessors . . . . . . . . . . . . . . . . . 395.2 Syntax von ARTA-Triggersprache . . . . . . . . . . . . . . . . . 47

5.2.1 Syntax eines Triggers . . . . . . . . . . . . . . . . . . . . 495.2.2 Syntax eines Eventmusters . . . . . . . . . . . . . . . . . 51

5.3 Semantik der ARTA-Triggerbearbeitung . . . . . . . . . . . . . 535.4 Verwaltung von Zeitereignissen . . . . . . . . . . . . . . . . . . 58

6 Implementierung 636.1 Architektur von ARTA . . . . . . . . . . . . . . . . . . . . . . 63

I

6.2 Benutzeroberflache . . . . . . . . . . . . . . . . . . . . . . . . . 656.2.1 Verwaltung von Triggern . . . . . . . . . . . . . . . . . . 676.2.2 Verwaltung von Ereignismustern . . . . . . . . . . . . . . 68

6.3 Speichern von Regeln . . . . . . . . . . . . . . . . . . . . . . . . 706.4 Klassen, Module und Objekte von ARTA . . . . . . . . . . . . 72

6.4.1 Klassenmodule . . . . . . . . . . . . . . . . . . . . . . . 726.4.2 Module und Objekte . . . . . . . . . . . . . . . . . . . . 75

6.5 Befehlsausfuhrungssystem . . . . . . . . . . . . . . . . . . . . . 776.6 Fehlerbehandlung . . . . . . . . . . . . . . . . . . . . . . . . . . 796.7 Besondere Aspekte . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.7.1 Trigger Execution Context . . . . . . . . . . . . . . . . . 816.7.2 Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 846.7.3 Behandlung vergangener Zeitereignisse . . . . . . . . . . 86

7 Zusammenfassung und Ausblick 89

II

Kapitel 1

Einleitung

Das MSr1Access-Datenbankmanagementsystem ist ein relationales und passi-ves Datenbankmanagementsystem. In einem passiven Datenbankmanagement-system werden Operationen ausgefuhrt, die unmittelbar von Anwendern odereinem Programm angefordert werden. In einem aktiven Datenbankmanagement-system konnen aber auch Situationen beschrieben werden, bei denen das Daten-bankmanagementsystem automatisch reagiert. Eine Situation in einer Daten-bank ist eine Kombination aus einem Datenbankzustand und einem Ereignis.In einem aktiven Datenbankmanagementsystem werden in diesem Sinne inter-essante Situationen mit Hilfe von aktiven Regeln beschrieben. Aktive Regelnwerden auch als ,,Trigger” bezeichnet. Eine aktive Regel besteht aus drei Tei-len: Ereignisteil (Event), Bedingungsteil (Condition) und Aktionsteil (Action).Aktive Regeln werden deswegen auch als ECA-Regeln bezeichnet. Ereignisse tre-ten entweder bei Datenbankanderungen (Anderungsereignis) oder bei Erreicheneines bestimmten Zeitpunktes (Zeitereignis) ein. Ein aktives Datenbankmanage-mentsystem soll Anwendern Werkzeuge anbieten, mit deren Hilfe sie Triggerdefinieren konnen. Trigger ist eine andere Bezeichnung zu aktiven Regeln. Dazusoll ein aktives Datenbankmanagementsystem auch Ereignisse erkennen und dieTrigger bearbeiten, die durch diese Ereignisse gefeuert werden.

In der vorliegenden Arbeit wird es darum gehen, das Access-Datenbank-managementsystem um eine Triggersprache zu erweitern und diese Erweite-rung zu implementieren. Die Erweiterung von Access um eine Triggersprachewird in Form einer Access-Anwendung realisiert. Eine Access-Anwendung isteine Software, die in der Programmiersprache VBA2 unter Einsatz von Access-Komponenten programmiert wird. Eine Access-Anwendung ist auf das Access-

1MS ist die Abkurzung fur Microsoft. Im weiteren Verlauf der Arbeit wurde auf das Co-pyright Symbol von Microsoft verzichtet.

2Visual Basic for Applications

1

2 KAPITEL 1. EINLEITUNG

Programm angewiesen und kann nur unter diesem Programm ausgefuhrt wer-den.

Das Konzept der in dieser Arbeit vorgestellten und implementierten Trigger-sprache basiert auf SQL3-Standard. In SQL3 sind Trigger aktive ECA-Regeln,die alle eindeutig benannt sind. In SQL3 wird nur das Auftreten von Ande-rungsereignissen (ON DELETE, ON INSERT und ON UPDATE) erkannt. Mitder hier vorgestellten und implementierten Triggersprache werden zusatzlichauch Zeitereignisse (absolute und periodische) berucksichtigt. Ein absolutes Zei-tereignis tritt nur einmal durch Erreichen eine bestimmten Zeitpunktes ein. Einperiodisches Zeitereignis tritt wiederholt und regelmaßig in gleichen Zeitabstan-den ein.

Zusatzlich zu absoluten und periodischen Zeitereignissen existiert noch einweiterer Zeitereignistyp: relative Zeitereignisse. Ein relatives Zeitereignis wirddurch eine Kombination aus einem absoluten bzw. periodischen Zeitereignismit einer Zeitdauer spezifiziert, z.B. ,,am zweiten Tag der Schulferien” oder,,letzten Montag jedes Monats”. Zeitereignisse sind vor allem in objektorien-tierten Datenbanksystemen realisiert worden, z.B. HiPAC3 (High Performan-ce Active Database System), Ode4, SAMOS5(Swiss Active Mechanism BasedObject-Oriented Database Systems). In den meisten dieser Systeme werden alleZeitereignistypen, ,,absolut”, ,,periodisch” und auch relativ spezifiziert.

Fur jedes Zeitereignismuster soll in dieser Arbeit eine Deadline mit der Ein-heit ,,Minute” definiert werden. Mit Zuordnung einer Deadline zu einem Zeiter-eignis(muster) wird angegeben, dass die Bearbeitung von (durch dieses Zeiter-eignis gefeuerten) Triggern innerhalb dieser deadline angefangen werden muss.Nach Ablauf dieser Deadline wird das Auftreten dieses Zeitereignisses ignoriertund dessen Trigger werden nicht mehr bearbeitet. Um das Konzept von Zei-tereignissen in dieser Arbeit zu implementieren, werden Prozeduren der API6-Schnittstelle eingesetzt. Mit Hilfe von API-Schnittstelle werden Timer gesetzt,die in separaten Prozessen im Betriebsystem laufen und deswegen die Daten-verarbeitung (in Access) und deren Geschwindigkeit nicht beeintrachtigen.

Fur das in dieser Arbeit implementierte System wurde der Name ARTA(Active Real Time Access Database system) ausgewahlt. Bei einem ARTA-Trigger wird eine Parameterubergabe vom Bedingungsteil an den Aktionsteil

3Vgl. [AKHaWi]4Vgl. [AKHaWi]5Vgl. [AKPat12]6Application Programming Interface

3

moglich sein, nachdem Parameter eindeutig fur den Trigger definiert (deklariert)wurden. Diese Parameter durfen nur bei Anderungsereignismustern eingesetztwerden.

Im Kapitel 2 geht es um die Grundlagen von Datenbanken und im Besonde-ren von aktiven Datenbanken. Anschließend wird ein kurzer Exkurs zu Echtzeit-systemen (Real Time Systems) und aktiven Echtzeitdatenbanksystemen (AktiveReal Time Database systems) gegeben. In Kapitel 3 wird die Programmierspra-che VBA und deren Einsatz in Access dargestellt. Access und seine Komponen-ten werden im Kapitel 4 untersucht. Formularklassenmodule und Formularereig-nisse, die bei der Implementierung von ARTA eine wichtige Rolle spielen, werdenbesonders beschrieben. Das Konzept fur ein aktives Access-Datenbankmanage-mentsystem ist Thema von Kapitel 5. Dort wird gezeigt, dass aufgrund derEreigniserkennungsproblematik, besonders bei Anderungsereignissen, der Ent-wurf eines Praprozessors in Form einer Access-Anwendung unvermeidbar ist. ImKapitel 6 werden die bei der Implementierung von ARTA angewandten Metho-den beschrieben. Im weiteren werden die ARTA-Klassen(module) und die ausdiesen Klassen initiierten Objekte beschrieben, die bei der Implementierung vonARTA eingesetzt werden. Das Kapitel 7 gibt eine Zusammenfassung, der einigeVorschlage zur Weiterentwicklung der Arbeit folgen.

4 KAPITEL 1. EINLEITUNG

Kapitel 2

Grundlagen von Datenbanken

In diesem Kapitel werden Grundbegriffe von Datenbanken beschrieben. Indu-strie und Forschung sehen sich heute mit gewaltigen Mengen von Informationenkonfrontiert und werden von der sogenannten Informationsflut uberrollt. Dabeilasst sich in jeder Hinsicht daruber streiten, wie der Begriff ,,Information” zudefinieren ist. Fur diese Arbeit soll die folgende Erklarung genugen: ,,Informa-tion” ist jede Art von Wissen, das fur eine Gruppe von Menschen von Interesseist und verwaltet werden kann. Beispielsweise sind diese Informationen uber Te-lefonkunden einer Telefongesellschaft, Informationen uber genetische Merkmalevon Menschen (eines Landes), Informationen uber Diplomanden an der Univer-sitat Bonn.

Informationen dieser Menge konnen nicht mehr ausschließlich mit traditio-nellen Methoden verwaltet werden. Diese konnen z.B. nicht mehr nur als Doku-mente irgendwo archiviert werden, da sie spater - nicht zuletzt aufgrund ihresUmfanges - nur mit großem Aufwand wieder auffindbar sind. Heutzutage bietenComputer die Moglichkeit Informationen platzsparender zu bewahren und siemit hoher Geschwindigkeit wieder aufzufinden; An dieser Stelle kommen Begriffewie ,,Datenbank”, ,,Datenbanksystem” und ,,Datenbank Mangement System”ins Spiel.

Eine Datenbank ist eine Sammlung von zusammengehorenden Informatio-nen, z.B. Informationen uber Kontoinhaber einer Bankfiliale oder Informationenuber die eingeschriebenen Informatikstudenten an der Universitat Bonn. Ei-ne Datenbank wird indirekt von einem Mensch verwaltet. ,,Indirekt” bedeutet,dass der Datenbankbenutzer einem System seine Anforderungen angibt. Danachwerden diese Anforderungen in dem System uberpruft und ausgefuhrt. DiesesSystem ist eine Software, die ,,Datenbank Management System” (DBMS) ge-nannt wird. Das Datenbankmanagementsystem darf nicht von Daten (Informa-

5

6 KAPITEL 2. GRUNDLAGEN VON DATENBANKEN

tionen) abhangig sein, d.h. ein Datenbankmanagementsystem muss in der Lagesein jede Art von Daten zu speichern, und soll dem Benutzer die notwendigenMechanismen anbieten, um diese Daten verwalten zu konnen. Die Kombinationeines Datenbankmanagementsystems mit mehreren Datenbanken nennt sich einDatenbanksystem. Das Bild 2.1 stellt ein Datenbanksystem (DBS) dar, dasaus einem Datenbankmanagementsystem (DBMS) und mehreren Datenbanken(DBn) besteht.

DB 1 DB n DB 2

DBMS

. . .

DBS

Benutzer

Abbildung 2.1: Datenbankmanagementsystem und Datenbanksystem

Außer Anwendungsunabhangigkeit bzw. Datenunabhagigkeit zeichnet sichein Datenbankmanagementsystem besonders durch die folgenden Eigenschaftenaus:

• Dauerhaftigkeit:Ein Datenbankmanagementsystem hat die Aufgabe, die Daten solangeaufzubewahren, bis sie von einem Benutzer absichtlich geloscht werden.Die Daten in einer Datenbank durfen nicht ohne direkte oder indirekteBenutzeranforderung geloscht werden bzw. verloren gehen.

• Integritat:Eine Datenbank darf keine unsinnigen (inkonsistenten) Daten beinhalten,d.h. die Daten mussen der Realitat entsprechen. Ein Datenbankmanage-mentsystem soll dem Benutzer Werkzeuge anbieten, mit deren Hilfe erIntegritatsregeln aufstellen kann. Nach der Definition der Integritatsre-geln wird ein Datenbankmanagementsystem beachten, dass keine Datenentstehen konnen, die diesen Regeln widersprechen.

7

• Benutzerfreundlichkeit:Ein Datenbankmanagementsystem sollte so einfach wie moglich zu bedie-nen sein. Das bedeutet, dass dem Endbenutzer eine Sprachschnittstellezur Verfugung gestellt wird. Dabei soll ein Datenbankmanagementsystemauch in der Lage sein, die Nutzung der Datenbank von mehreren Benut-zern zu ermoglichen.

Das relationale Model ist das in heutigen Datenbankmanagementsystemenam weitesten verbreitete Datenmodel. Eine Datenbank im relationalen Modelbezeichnet man als eine relationale Datenbank. Im Falle einer relationalen Da-tenbank besteht diese aus einer Anzahl von ,,Relationen”. Eine Relation be-zeichnet auch eine ,,Datenbasis” einer relationalen Datenbank. Jede Relationist eine Menge von Tupeln. Ein Tupel ist ein Datensatz, der aus Attributenbesteht. Ein Datensatz ist ein atomares Element einer Relation. Jede Relationerfullt die Bedingung, keine zwei gleichen Tupeln besitzen zu durfen. Jede Re-lation hat einen eindeutigen Namen innerhalb einer Datenbank. Jedes Attributder Tupel einer Relation hat einen eindeutigen Namen innerhalb der Relation.Die Reihenfolge von Tupeln in einer Relation sind nicht zu beachten. Eine Rela-tion kann als eine Tabelle angesehen werden, deren Zeilen die Tupeln und derenSpalten die Attribute reprasentieren.

Student

Name Vorname Mtr.Nr Email

Fadaei Kazem 658698 [email protected] Joachim 19911000 [email protected] Michael 19951000 [email protected] Beate 21869458 [email protected]... ... ... ...

Beispiel 2.1: Die Studenten-Tabelle

In dem Beispiel 2.1 ist eine Relation in Form einer Tabelle gegeben. Die Tabelleenthalt Informationen uber eine Anzahl von Studenten. Jede Zeile reprasentiertInformationen uber eine Studentin bzw. einen Studenten. Die Informationen je-der Zeile teilen sich in vier Teile, die verschiedene Attribute zu jedem Datensatzbeinhalten.


2.1 Aktive Datenbanken

In der Regeln verhalten sich die traditionellen Datenbanken passiv. In einerpassiven Datenbank wird jede Operation (vor allem delete, insert bzw. upda-te) nur dann ausgefuhrt, wenn sie unmittelbar von einem Benutzer oder einemProgramm angefordert wird. Von aktiven Datenbanken wird erwartet, auf be-stimmte Situationen in einer Datenbank automatisch zu reagieren und bestimm-te Aufgaben zu erledigen.

,,Ein Datenbanksystem heißt aktiv, wenn es zusatzlich zu den ubli-chen (passiven) DBS-Fahigkeiten in der Lage ist, definierbare Si-tuationen in der Datenbank (und wenn moglich daruber hinaus) zuerkennen und als Folge davon bestimmte (ebenfalls definierbare) Re-aktionen auszulosen.”1

Ein aktives Datenbankmanagementsystem soll dem Benutzer einen Mecha-nismus anbieten, um dem Datenbankmanagementsystem mitteilen zu konnen,in welcher Situation welche Operation auszufuhren ist. Es stellt dazu eine Re-gelsprache zur Verfugung, mit deren Hilfe sogenannte aktiven Regeln definiertund in einer bestimmten Form (Wissensmodel) gespeichert werden konnen.Eine aktive Regel besteht aus drei Teilen: Ereignisteil (Event), Bedingungs-teil (Condition) und Aktionsteil (Action). Die aktiven Regeln heißen deswegenECA-Regeln. Eine andere Bezeichnung fur aktive Regeln ist das Wort ,,Trig-ger”. Die Menge aller aktiven Regeln in einer Datenbank heißt Regelbasis.

Mit der Definition einer Regel wird das Datenbanksystem aufgefordert, beimEintreffen des Ereignisses E die Aktion A auszufuhren, wenn die Bedingung Cerfullt ist. Die Kombination aus Ereignis und Bedingung eines Triggers be-zeichnet eine fur den Trigger ,,interessante Situation”, bei der die Triggeraktionausgefuhrt werden soll. Trifft das Ereignis E ein, so ist die Regel (der Trigger)mit dem Ereignisteil E zu feuern (bzw. auszulosen oder zu triggern).

Ereignis: Ein Ereignis ist ein Geschehen in einer Datenbank an einem be-stimmten Zeitpunkt2: ein punktuelles Geschehen. Ein Ereignis kann primitivoder zusammengesetzt sein.

• Primitive Ereignisse sind einfache bzw. atomare Ereignisse, z.B. ,,ONDELETE FROM tablename”.

1[AKDiGa], S.7.2[AKPaDi]

2.1. AKTIVE DATENBANKEN 9

• Zusammengesetzte Ereignisse sind Ereignisse, die sich aus mehrerenprimitiven Ereignisse unter Benutzung von Verknupfungsoperationen3 bil-den, z.B. ,,ON INSERT TO table1 AND ON UPDATE OF table2”.

Ein primitives Ereignis kann wiederum entweder ein Datenbankereignis (Ande-rungsereignis) oder ein Zeitereignis sein. Ein Datenbankereignis tritt bei Ande-rung an einer Tabelle bzw. an einem Feld dieser Tabelle ein, d.h. beim Loschen(delete), Hinzufugen (insert) und Modifizieren (update).

ZeitereignisseEin Zeitereignis tritt bei Erreichen eines Zeitpunktes ein. Zeitereignissse kon-

nen in drei Formen spezifiziert werden:

• Ein absolutes Zeitereignis tritt nur einmal an einem eindeutig definier-ten Zeitpunkt ein, z.B. ,,Am 31.08.2002 um 14:55 Uhr”.

• Ein periodisches Zeitereignis tritt in regelmaßigen Zeitabstanden wie-derholt ein, z.B. ,,Jeden Mittwoch um 10:00 Uhr”.

• Ein relatives Zeitereignis ist eine Kombination aus einem absolutenbzw. periodischen Zeitereignis mit einer Zeitdauer, z.B. ,,Ein Tag vor demSemesterende” oder ,,Am dritten Arbeitstag jedes Monats”.

Bei der Beschreibung von Zeitereignissen stoßt man unweigerlich auf den Begriff,,Aktives Echzeit-Datenbanksystem (Aktive Real Time DBS)”, das unten kurzbeschrieben wird.

Ein Computersystem heißt Echtzeitsystem (Real Time System, RTS), wenndas System ein korrektes Ergebnis nur innerhalb eines bestimmten Zeitinter-valls produziert. Außerhalb dieses Zeitintervalls gibt das RTS bestenfalls keinErgebnis zuruck. Ein aktives Datenbanksystem, das die ,,Echtzeit”-Eigenschafterweist, wird aktives Echtzeit-Datenbanksystem (Aktive Real Time DatabaseSystem, ARTDBS) genannt. Zeitereignisse sind die wichtigsten Aspekte einesARTDBS. In einem ARTDBS soll genau beobachtet werden, wann ein Zeiter-eignis eintritt und wie lange dessen Bearbeitung dauert. Die Genauigkeit (dieGranularitat) der Zeitmessung hangt von dem jeweiligen System (Computerbzw. Netz) ab. Als Granularitat, der kleinsten Zeiteinheit in einem ARTDBS,wird normalerweise eine ,,Minute” genommen.

Die Syntax einer aktiven Regel in einem ARTDBS kann wie folgt aussehen4:

3Operationen aus Ereignisalgebra: OR, AND, NOT, Sequenz4Vgl. [AKPat21], S410


ON event E

IF condition C

DO <COMPLETE> action A <WITHIN t seconds>

Es gibt noch Fragen, die durch die Semantik beantwortet werden mussen.Eine Regel R1 in einem ARTDBS konnte z.B. wie folgt aussehen:

ON 31.08.2002 14:55

IF Bedingung C1

DO Aktion A1 innerhalb von 5 Minuten.

Die erlaubte Zeitdauer ist bei diesem Beispiel (R1) im Aktionsteil festgeschrie-ben. Die Semantik einer derartigen Regel konnte z.B. folgendermaßen lauten:Falls die Bedingung C1 am 31.08.2002 um 14:55 Uhr (t:=31.08.2002 14:55) gilt(erfullt ist), soll die Aktion A1 ausgefuhrt werden und muss innerhalb von 5Minuten (bis zum 31.08.2002 um 15:00 Uhr [oder bis t+5 Minute]) abgearbeitetsein. Im Bild 2.2 wurde die Bearbeitung dieser Regel bezuglich einer Zeitachsegeschildert.

Zeit / Minute

31.08.2002 14:55

Bearbeitungsanfang

31.08.2002 15:00

Obergrenze für die Bearbeitung

Abbildung 2.2: Zeitgrenze von 5 Minute

Betrachten wir nun die Regel R2 mit einer anderen Syntax:

ON t in [31.08.2002 14:55, 31.08.2002 15:30]

IF Bedingung C2

DO Aktion A2.

Die Ausfuhrung von A2 wird angefangen, wenn die Bedingung C2 innerhalbdes Zeitintervalls ,,[31.08.2002 14:55, 31.08.2002 15:30]” erfullt ist. Der Unter-schied zwischen R1 und R2 zeigt sich, wenn das System den Eintritt des Zei-tereignisses nicht direkt am 31.08.2002 um 14:55 Uhr, sondern (Sekunden bzw.Minuten) spater meldet. In einer solchen Situation beginnt das System beide

2.2. TRIGGER IN SQL3 11

Aktionen auszufuhren (unter Annahme, dass beide Bedingungen erfullt sind).Die Ausfuhrung der Aktion der ersten Regel (R1.A1) gibt kein (korrektes) Er-gebnis, falls die Ausfuhrung uber die (Zeit-) Obergrenze hinaus geht. Die Aktionder zweiten Regel (R2.A2) wird vollstandig ausgefuhrt, ohne die (Zeit-) Ober-grenze zu beachten.

Wenn diese Regeln (R1, R2) direkt am ,,[31.08.2002 14:55, 31.08.2002 14:55]”gefeuert werden und das System mit der Bearbeitung bis ,,[31.08.2002 14:55,31.08.2002 15:30]” fertig ist, so haben beide Regeln dieselbe Wirkung. Das fol-gende Beispiel, Regel R3, kombiniert die jeweilige Syntax der beiden oben an-gegebenen Regeln:

ON t in [31.08.2002 14:55, 31.08.2002 15:30]

IF Bedingung C3

DO Aktion A3 innerhalb von 5 Minuten.

Diese Regel darf innerhalb des Zeitintervalls [31.08.2002 14:55, 31.08.2002 15:30]gefeuert werden. Wenn C3 erfullt ist, soll die Bearbeitung von A3 innerhalb 5Minuten (t+5 Minute) fertig sein5.

2.2 Trigger in SQL3

SQL, Structure Query Language, ist eine weit verbreitete Sprache zur Defini-tion und Manipulation von relationalen Datenbanken. Die erste standardisierteVersion (SQL-86) wurde im Jahre 1986 realisiert und die aktuellste standardi-sierte Version von SQL ist SQL3. Der Einsatz der Spracherweiterung um dieTriggerfunktionalitat wurde zum ersten Mal in SQL3 vorgesehen, obwohl dieTriggerfunktionalitat bei manchen SQL2-Implementierungen schon bereits un-terstutzt wurde. Ein Trigger ist in SQL3 eine (mit einem eindeutigen Namen)gekennzeichnete ECA-Regel. Ein SQL3-Trigger besteht aus folgenden Kompo-nenten: einer Tabelle, dem Datenmanipulationsbefehl (DML-Operation), einerBedingung und einer Aktion. Ein Trigger wird in SQL3 explizit durch den Befehl,,CREATE TRIGGER” definiert.

2.2.1 Syntax von SQL3-Triggersprache

Die Syntax fur die Trigger-Definition in SQL3 sieht wie folgt aus:

<trigger definition> ::=

CREATE TRIGGER <trigger name>

5In der vorliegenden Arbeit werden Zeitereignisse der Form von R2 unterstutzt.


<trigger action time> <trigger event>

ON <table name> [ REFERENCING <old new values alias list>]

<triggered action>

<trigger action time> ::=

BEFORE

| AFTER

<trigger event> ::=

INSERT

| DELETE

| UPDATE [ OF <trigger column list> ]

<trigger column list> ::= <column name list>

<triggered action> ::=

[ FOR EACH { ROW | STATEMENT }]

[ WHEN <left paren> <search condition> <right paren>]

<triggered SQL statement>

<triggered SQL statement> ::=

<SQL procedure statement>

| BEGIN ATOMIC

{ <SQL procedure statement> <semicolon> }...

END

<old or new values alias list> ::=

<old or new values alias>...

<old new values alias> ::=

OLD [ROW] [AS] <old values correlation name>

| NEW [ROW] [AS] <new values correlation name>

| OLD TABLE [AS] <old values table alias>

| NEW TABLE [AS] <new values table alias>

<old values table alias> ::=<identifier>

<new values table alias> ::=<identifier>

<old values correlation name> ::= <correlation name>


<new values correlation name> ::= <correlation name>

Dabei bedeuten die Parameter wie folgt:<column name list> ist eine Liste bestehend aus Spaltennamen der betroffenenTabelle. In der Liste darf keine Spalte doppelt oder gar mehrfach vorkommen.<left paren> <search condition> <right paren>: Mit Diesem Ausdruck wirdeine Bedingung formuliert. Der linke und rechte Teil konnen Parameter oderKonstanten sein, die durch den Vergleichsoperator (<search condition>) mit-einander verglichen werden.<SQL procedure statement> ist ein SQL-Ausdruck.<identifier>’s sind eindeutige Namen fur den alten bzw. neuen Zustand derbetroffene Tabelle.<correlation name> sind eindeutige Namen fur den alten bzw. neuen Zustandder betroffene Zeilen.

2.2.2 Semantik von SQL3-Triggersprache

Ein SQL-Ausdruck kann mehrere Trigger feuern. Die gefeuerten Trigger sindentweder Before- oder Aftertrigger. Zusatzlich kann ein Trigger ein ROW-Level(FOR EACH ROW) oder ein STATEMENT-Level (FOR EACH STATEMENT)sein. Als ein wichtiger Punkt ist bei der Triggerbearbeitung zu beachten:

Ein Beforetrigger darf keine weiteren Trigger feuern, d.h. wenn dieBedingung eines gefeuerten Beforetriggers erfullt ist, soll die Aktiondes Triggers direkt ausgefuhrt werden, ohne darauf zu achten, obdurch die Ausfuhrung weitere Trigger gefeuert werden konnten.

Die Semantik der Triggerbearbeitung in SQL3 ist wie folgt:

1. Der SQL-Ausdruck ,,Si” soll ausgefuhrt werden. Tritt ein Datenbankereig-nis E aufgrund der Ausfuhrung dieses SQL-Ausdruck ,,Si” ein , so werdenan dieser Stelle drei Parameter berechnet:

(a) die Menge der Beforetrigger BTrs, die durch E gefeuert werden,

(b) die Menge der Aftertrigger ATrs, die durch E gefeuert werden,

(c) den sogenannten ,,Trigger Execution Context” (TECi), der aus fol-genden Teilen besteht :

• dem Namen der betroffenen Tabelle,

• dem Datenmanipulationsbefehl (DELETE, INSERT oder UP-DATE),

• einer Menge von Transitionen bestehend aus zwei temporarenTabellen:


i. OLD TABLE beinhaltet die alten Werte der Betroffenen Zei-len (vor der Ausfuhrung des SQL-Befehls),

ii. NEW TABLE beinhaltet die neuen Werte der BetroffenenZeilen (nach der Ausfuhrung des SQL-Befehls).

2. Ist die Menge der Transitionen leer (keine Datenanderung), sollen alleROW-level Trigger aus der Menge der Beforetrigger ,,BTrs” entfernt wer-den.

3. Die Trigger in der Menge BTrs werden nach dem Erzeugungsdatum sor-tiert. Nach dem Sortieren der ,,BTrs” wird jeder Trigger ,,Tr” aus dieserMenge wie folgt bearbeitet:

• Ist ,,Tr” ein STATEMENT-Level Trigger, so wird die Tr.Conditionausgewertet. Ist das Ergebnis = ,,True”, wird jedes STATEMENTder Tr.Action ausgefuhrt.

• Ist ,,Tr” ein LOW-Level Trigger, so wird fur jede Transition:die Tr.Condition ausgewertet. Gibt die Auswertung ,,True” zuruck,wird jedes STATEMENT von Tr.Action ausgefuhrt.

4. An dieser Stelle wird der SQL Ausdruck ,,Si” ausgefuhrt.

5. Die Integritat der Datenbank wird hier getestet und ggf. die Folgeande-rungen vorgenommen6.

6. Ist die Menge der Transitionen leer (keine Datenanderung), werden alleROW-level Trigger aus der Menge Aftertrigger ,,ATrs” entfernt.

7. Trigger in der Menge ATrs werden nach dem Erzeugungsdatum sortiert.Nach dem Sortieren der ,,ATrs” wird jeder Trigger ,,Tr” aus dieser Mengewie folgt bearbeitet:

• Ist ,,Tr” ein STATEMENT-Level Trigger, so wird die Tr.Conditionausgewertet. Ist das Ergebnis der Auswertung = ,,True”, wird jedesSTATEMENT der Tr.Action als neue Eingabe ,,Sj” an den Schritt(1.) weitergegeben.

• Ist ,,Tr” ein LOW-Level Trigger, so wird fur jede Transition:die Tr.Condition ausgewertet. Gibt die Auswertung ,,True” zuruck,wird die Ausfuhrung jedes STATEMENTs ,,Sj” von Tr.Action andem Schritt (1.) weiter durchgefuhrt.

6Vgl. [AKPat10], [SQLMeSi], [SQLStnd], [SQLTrKo]


Vor der Auswertung einer Triggerbedingung sowie vor der Bestimmung einesneuen SQL-Befehls aus der Triggeraktion sollen die Parameter (OLD TABLE,NEW TABLE, OLD ROW und NEW ROW) aus der Menge der Transitionenberechnet und in Triggerbedingungen bzw. in Triggeraktionen eingesetzt wer-den.

Kapitel 3

Visual Basic for Applications

In diesem Kapitel wird die Programmiersprache ,,Visual Basic for Applications”(VBA) beschrieben. VBA ist wie jede andere gut entwickelte Programmier-sprache sehr umfangreich und deswegen in einem Kapitel dieser Arbeit nichtvollstandig darzustellen. In diesem Kapitel wird eine kurze Einfuhrung in dieseProgrammiersprache gegeben. VBA wird in dem Umfang beschrieben, wie eszum Verstandnis der Arbeit erforderlich ist1. VBA ist ein Dialekt der Program-miersprache Basic und hat viele Gemeinsamkeiten mit der ProgrammierspracheVisual Basic(VB), die selbst ein Dialekt von Basic ist. VBA ist keine eigenstandi-ge Programmiersprache, d.h. ein VBA-Programm ist an das Anwendungspro-gramm gebunden, in dem es entwickelt wurde. Ursprunglich wurde VBA da-zu konzipiert, als Makroprogrammiersprache in MS-Office-Komponenten einge-setzt zu werden. Anwendungen werden unter MS-Office-Komponenten vor allemin MS-Access und MS-Excel mit VBA programmiert. Es existieren keine grund-legenden Unterschiede zwischen VB und VBA. Jedoch liegt ein wesentlicher Un-terschied darin, dass die VBA-Programme direkt an MS-Office-Komponentengebunden sind und alleine nicht existieren konnen. Wenn auch VBA eine weitausgroßere Anwendungslandschaft innehat, wird an dieser Stelle nur von VBA inVerbindung mit Access die Rede sein, da in dieser Arbeit der Einsatz der VBAin Access im Vordergrund steht. Mit Hilfe der VBA-Befehle konnen AccessKomponenten und ihr Verhalten kontrolliert werden. Dies kommt vor allem beiFormularereignissen in Form der ,,Code behind Forms” vor, in denen der VBA-Code vollstandig mit dem Formular verbunden ist.

1Ausfuhrlich wurde VBA vor allem in [A00AN], [A00BK], [A97AN], [A0SQLBB] und[VB6Ko] beschrieben.

17

18 KAPITEL 3. VISUAL BASIC FOR APPLICATIONS

3.1 Sprachgrundlagen

Variablen sind die Elemente, die in einem Programm vorubergehend Inhaltebekommen und genutzt werden, um Berechnungen in dem Programm durch-zufuhren. Variablen sollen vor ihrer Verwendung deklariert werden, d.h. derKompiler soll uber ihrer Existenz informiert werden. In VBA konnen die Va-riablen auf zwei verschiedene Arten deklariert werden: die implizite und dieexplizite Art der Deklaration. Bei der impliziten Deklaration werden die Va-riablen direkt und automatisch durch deren erste Anwendung im Programmdeklariert. Bei expliziten Deklarationen mussen Variablen zusatzlich vor derenersten Anwendung deklariert werden.

Mit dem Befehl ,,Dim Variablename [As typ]” erfolgt die Deklarati-on einer Variablen mit dem Namen Variblename vom Datentyp typ. Im Buch[A00AN] wird empfohlen, die Variablen bereits vor der ersten Anwendung zudeklarieren. Indem der Ausdruck ,,option Explicit” am Anfang des Codeseingesetzt wird, kann der Programmierer zur Deklaration der Variablen vor de-ren ersten Anwendung gezwungen werden. Wird dieser Befehl am Anfang einesjeden Codes hinzugefugt, so wird der VBA-Kompiler benachrichtigt: Jede Va-riable muss vor dem ersten Gebrauch in diesem Code deklariert werden. BeimErzeugen neuer Codes, wird dann der Befehl Option Explicit am Anfang desCodes automatisch hinzugefugt, wenn der dafur vorgesehene Eintrag im VBA-Fenster [Extras → Optionen → Editor → Code-Einstellung (Variablendekla-ration erforderlich)] markiert wird.

Der Datentyp einer Variablen gibt an, welche Art von Inhalten dieser Varia-ble zugewiesen werden durfen. Der Datentyp kann eine Zahl, eine Zeichenfolge,ein Datum, etc. bezeichnen. Wird bei der Deklaration einer Variable kein Daten-typ angegeben, so ist der Datentyp standardmaßig Variant. Variant kann jedeArt von Inhalten speichern. Folgende Datentypen konnen zur Deklaration einerVariablen verwendet werden: Byte, Boolean, Integer, Long, Single, Double, Cur-rency, Decimal, Date, Object, String, Variant(mit Zahlen), benutzerdefinierterDatentyp.

Konstanten sind Variablen, deren Inhalte nicht veranderbar sind. Die Inhal-te von Konstanten werden in einem Programm nur bei der Deklaration zuge-wiesen. Konstanten beinhalten in der Regel bestimmte globale Großen. SolcheGroßen werden haufig im Programm und zwar in verschiedenen Modulen undKlassenmodulen gebraucht und verwendet. Die manuellen Anderungen einer

3.1. SPRACHGRUNDLAGEN 19

Konstanten, d.h. die Anderung der Zeile, in der diese Konstante deklariert wur-de, kann eine Anderung an allen Stellen verursachen, in denen diese Konstanteangewendet wurde.

Der Gultigkeitsbereich von Variablen wird durch die SchlusselworterPrivate, Public und Static definiert, z.B. ,,Private strPrivaterText As String”,,,Public strGlobalerText As String”, ,,Static strStatistigerText As String”. Einein einer Prozedur deklarierte Variable ist nur innerhalb dieser Prozedur gultig.Eine Variable darf nur innerhalb einer Prozedur als Static deklariert werden,und sie behalt ihren Inhalt auch nach dem Ende der Prozedurausfuhrung. EineVariable darf nur am Anfang eines Moduls bzw. Klassenmoduls als Private oderPublic deklariert werden. Als Private deklarierte Variablen haben ihre Gultig-keit nur innerhalb eines Moduls bzw. innerhalb eines Klassenmoduls. Sie durfenvon jeder Prozedur in diesem Modul bzw. in diesem Klassenmodul angewendetwerden. Die als Public deklarierten Variablen sind von jeder Komponente inAccess nutzbar.

In VBA existieren zwei Arten von Prozeduren, Sub und Function. Beidekonnen als Public, Private oder/und Static deklariert werden. Diese Prozedurenlassen sich wie folgt definieren:

[Private | Public] [Static] Sub name([Argumentliste])

[Anweisungen]

[Exit Sub]

[Anweisungen]

End Sub

[Private | Public][Static]Function name([Argumentliste])[As Typ]

[Anweisungen]

[name=Ausdruck]

[Exit Function]

[Anweisungen]

[name=Ausdruck]

End Funktion

Die Argumentliste beinhaltet Variablen, die an die Prozedur ubergeben wer-den. Die Variablen der Argumentliste werden genauso deklariert, wie sie in ei-nem Modul oder Klassenmodul deklariert werden. Diese Variablen werden mitKommata voneinander getrennt. In dem folgenden Beispiel wurde eine Sub-Prozedur ,,Test” mit vier Eingabe-Parametern definiert.


public Sub Test(ByVal dbl als Double, _

ByRef str as Sting, _

int as Integer_

var)

Anweisungen

End Sub

Im Beispiel wurden auch neue Begriffe verwendet: ByVal und ByRef. Inner-halb der Prozedur ,,Test” konnen die Variablen dbl, str, int und var verwendetwerden, dabei durfen auch die Inhalte dieser Variablen geandert werden. Wenndie Variablen als ByRef deklariert sind, werden die Variablenanderungen nachder vollstandigen Prozedurausfuhrung an das aufrufenden Programm weiterge-leitet. Alle Variablen, die als ByVal deklariert sind, behalten ihre ursprungli-chen Inhalte. Die Standardeinstellung bei der Deklaration einer Variablen in derArgumentliste ist ByRef. Im Beispiel werden die Variablen int und var stan-dardmaßig als Reference an die Prozedur ubergeben. Es wird empfohlen dieUbergabevariablen immer als ByVal zu deklarieren, damit die Werte nicht ver-sehentlich geandert werden. Die Zeilen werden in VBA mit einem Hochkommaam Anfang jeder Zeile als Kommentar bezeichnet, und werden vom Kompi-ler ignoriert. Weitere Ausfuhrungen zu den grundlegenden Sprachelementen vonVBA, z.B. IF-Anweisungen, Schleifen, Sprungbefehle, etc. finden sich in der o.a.Literatur.

3.2 Module, Klassenmodule und Objekte

Es lasst sich daruber streiten, ob VBA eine Objektorientierte Programmierspra-che ist oder nicht. Aus der Sicht einer traditionellen, rein prozeduralen Sprachewie c ist VBA als eine objektorientierte Programmiersprache einzustufen. Ausder Sicht einer objektorientierten Sprache wie c++ oder Java ist VBA als einenicht vollstandig objektorientierte Programmiersprache anzusehen, da beispiels-weise die Vererbung in VBA nicht existiert. In VBA sind Objekte wie in jederobjektorientierten Programmiersprache beteiligt.

Objekte:Im allgemeinen ist ein Objekt in VBA ein programmierbares Element. Formu-

lare, Tabellen, Berichte und sogar auch die in Formularen vorhandenen Kontroll-elemente, werden in VBA als Objekte bezeichnet. Ein Objekt ist eine Sammlungvon Eigenschaften und Methoden. Eigenschaften sind in diesem Sinne die Attri-bute eines Objektes, die das Verhalten dieses Objektes beeinflussen. Zum Bei-spiel ist die Hintergrundfarbe eines Formulars eine Eigenschaft dieses Objektes.

3.2. MODULE, KLASSENMODULE UND OBJEKTE 21

Eine (Objekt)Methode ist eine Funktion, die im Objekt eingebaut ist und einebestimmte Aufgabe erledigt, z.B. die Prozedur ,,Private Sub Form Open(CancelAs Integer)” wird innerhalb eines Formular-Klassenmoduls eingesetzt und pro-grammiert. Diese Prozedur wird spater beim Offnen des Formulars ausgefuhrt.Die Eigenschaften und Methoden konnen als Private oder Public definiert sein.Die als Private deklarierten Eigenschaften bzw. Methoden durfen nur von Me-thoden benutzt werden, die in demselben Objekt definiert sind. Die hingegenals Public definierten Methoden konnen uberall dort aufgerufen werden, wo dasObjekt angewendet wird. Es gibt in VBA unter Access zwei verschiedene Ob-jektarten. Zum einen gibt es die Access-Objekte (die Access-Komponenten),zum anderen Objekte, die vom Programmierer erzeugt werden konnen. DieAccess-Objekte stehen in einer Hierarchie auf verschiedenen Stufen: Die Access-Objekthierarchie wurde in dem Buch [A00AN] im Kapitel 9 geschildert undausfuhrlich beschrieben.

Was aber in ARTA eine wichtige Rolle spielt, ist der Begriff ,,Auflistung”. Ei-ne Auflistung in der Access-Hierarchie ist eine Menge von Objekten des gleichenTyps. Diese Objekte sind in der Auflistung in einer vorbestimmten Reihenfolgezusammengefasst. Eine Auflistung kann in einer Schleife ,,durchlaufen” werden.Beim ,,Durchlaufen einer Auflistung” wird auf jedes Objekt und dessen Eigen-schaften und Methoden zugegriffen. Zum Beispiel enthalt die Auflistung Formsalle Formulare, die in einer Access-Datenbank vorhanden sind. Die AuflistungControls enthalt alle Steuerelemente eines Formulars oder eines Berichts. In demfolgenden Beispiel2 durchlauft eine Prozedur (,,AlleOffenenFormulare”) die Auf-listung ,,Forms” und gibt die Namen aller Formulare in dieser Auflistung aus.Dann wird die Auflistung Controls jedes Formulars durchlaufen und die Namenaller auf dem Formular befindlichen Steuerelemente ausgegeben.

In dem Beispiel sind auch Teile der Objekthierarchie angegeben:Forms → {Form1, Form2, . . . } und Formn → {Control1, Control2, . . . } mitn∈ {1, 2, . . . }. Außer der in Access existierenden Auflistungen konnen auchbenutzerdefinierte Auflistungen erzeugt und programmiert werden, die Access-Komponenten bzw. benutzerdefinierte Objekte beinhalten konnen. In VBA be-steht ebenfalls die Moglichkeit, Objekte zu programmieren, die in solchen Aufli-stungen zusammengefasst werden. Klassenmodule spielen in diesem Zusammen-hang eine wichtige Rolle. Aus diesem Grund werden im folgenden Klassenmodu-le und deren enge Verwandte ,,Module” gesondert beschrieben. Eine Prozedurwird in VBA innerhalb einer Umgebung definiert. Diese Umgebung kann einModul oder ein Klassenmodul sein.

2Das Beispiel ist aus der Online-Hilfe von Access 2000 ubernommen.


Sub AlleOffenenFormulare()

Dim frm As Form, ctl As Control

’ Forms-Auflistung durchlaufen.

For Each frm In Forms

’ Name des Formulars ausgeben.

Debug.Print frm.Name

’ Controls-Auflistung jedes Formulars durchlaufen.

For Each ctl In frm.Controls

’ Namen der Steuerelemente ausgeben.

Debug.Print ">>>"; ctl.Name

Next ctl

Next frm

End Sub

Ein Modul ist eine Sammlung von Prozeduren. Module lassen sich als Werk-zeug von anderen Objekten nutzen. In einem Modul durfen Prozeduren als Pri-vat oder Public definiert werden. Die als Private definierten Prozeduren konnennur den im selben Modul existierenden Prozeduren als Hilfsfunktionen dienen.Die in einem Modul als Public definierten Prozeduren konnen von Funktionenin anderen Modulen oder Objekten aufgerufen werden. Ein Modul erzeugt man,indem man mit der Maus im VBA-Fenster (auf Einfugen → Modul) anklickt.Ein Modul muss unter einem eindeutigen Namen in der Access-Datenbank ge-speichert werden.

Klassenmodule sind im Gegensatz zu Modulen umfangreicher, da sie mehrFunktionalitaten beinhalten. Ein Klassenmodul wird durch Mausklick (auf Ein-fugen → Klassenmodul) erzeugt und muss unter einen eindeutigen Namen ge-speichert werden. Klassenmodule sind die eigenstandigen Objektklassen, aus de-nen Objekte instantiieren konnen. Objektorientiertes Programmieren in VBAsetzt den Einsatz von Klassenmodulen zugrunde. In einem Klassenmodul wer-den Eigenschaften, Methoden und Variablen definiert, bzw. programmiert. Diein einem Klassenmodul definierten Variablen dienen dem Programmierer spaterals Speicherbehalter. Die Datenkapselung in VBA wird unterstutzt, indem Ob-jektvariablen nur durch Methoden verandert werden. In einer Auflistung konnenauf Methoden und Eigenschaften jedes Elementes zugegriffen werden. Dadurchwerden die Methoden der Unterklasse (Objekte dieser Auflistung) in der Ober-klasse (Auflistung) zur Verfugung gestellt.

Auf Eigenschaften eines Objektes wird in der Regel nicht direkt zugegrif-fen, wenn dies auch fur globale Variablen prinzipiell moglich ist, sondern mit

3.3. API 23

Hilfe der als Public definierten Methoden. VBA stellt dafur eine Methode zurVerfugung: den Einsatz der Property-Routinen3 (Property Get, PropertyLet und Property Set) in Klassenmodulen. Die Eigenschaften (Variablen)eines Klassenmoduls werden als ,,Private” deklariert; Mit Hilfe von Property-Routinen werden Inhalte dieser Eigenschaften modifiziert oder abgelesen.Property-Routinen haben zwei grundlegende Vorteile.

1. Es kann programmiert werden, welcher Inhalt einer Eigenschaft zugewie-sen werden darf.

2. Gleichzeitig konnen bei der Zuweisung bestimmte Aufgaben erledigt wer-den. (Diese Konnen z.B. direkten Einfluss auf andere Variablen nehmen.)

Angenommen, ein Klassenmodul wird mit dem Namen ,,clsTest” definiert, sowird mit dem Befehl ,,Dim objTest As New clsTest” eine Instanz (ein neuesObjekt) zu dieser Klasse erzeugt. Auf die Eigenschaften und Methoden diesesObjektes wird mitobjTest< .|! >EigenschaftOderMethodezugegriffen. Auflistungen werden in Form von Klassenmodul programmiert.Eine Auflistung soll die notwendigen Methoden und Eigenschaften beinhalten.Zusatzlich braucht eine Auflistung eine Variable vom Typ ,,Collection”, in dieObjekte gespeichert werden konnen. Mit Hilfe der Methode ,,Add” konnen Ele-mente in die Auflistung aufgenommen werden. Die Methode ,,Remove” hilftElemente aus der Auflistung zu entfernen. Mit Hilfe der Befehle, Item, Count,BOL, EOL, MoveFirst, MoveLast, MoveNext, MovePrev kann die Auflistungdurchlaufen und auf Elemente der Auflistung zugegriffen werden. Diese Metho-den konnen beliebige Namen tragen und o.a. Namen sind nur als Vorschlagegedacht. Vorausgesetzt, es wurde eine Auflistung objColl von Objekten derKlasse clsTest definiert, so konnen auf die Eigenschaften bzw. Methoden desersten Elements dieser Auflistung mitobjColl.Item(0).EigenschaftOderMethodezugeriffen werden. Durch das ”Durchlaufen” einer Auflistung sind alle ihre Ob-jekte erreichbar. Das Durchlaufen einer Auflistung kann mittels verschiedenerMethoden durchgefuhrt werden. In [A00AN] sind diese und weitere Hinweisebereits ausfuhrlich erlautert worden.

3.3 API

In diesem Abschnitt soll eine Technik vorgestellt werden, die im ARTA fur dieRealisierung von Timern benutzt wird.

3Ausfuhrliche Erlauterungen dazu enthalt [A00AN].


API (Application Programming Interface) ist eine Software-Schnittstelle, diedem Programmierer ermoglicht Windows Funktionalitaten in seinem Programmzu nutzen. Diese Funktionalitaten konnen praktisch alles darstellen, was in ei-nem Windows Betriebsystem ablauft, z.B. Fensterverwaltung, Zeitverwaltung,Hardwareverwaltung, . . . . Jede Funktion von API ist in einer DLL Datei (,,Dy-namic Link Library”), die die Endung ,,.dll’ hat, eingebunden. DLL Dateien sindin der Regel im Windows Stammverzeichnis gespeichert. Eine DLL-Datei wirderst dann in den Arbeitsspeicher transportiert, wenn sie tatsachlich benotigtwird. Die Funktionen einer DLL-Datei konnen in jedem Programm, das unterWindows lauft, benutzt werden.

In VBA mussen die Funktionen von API erst deklariert werden, damit sieaufgerufen werden konnen. Durch die Deklaration einer API-Funktion wird demProgramm mitgeteilt, in welcher DLL-Datei diese Funktion zu finden ist, welcheParameter an diese Funktion ubergeben werden und wie die Ruckgabe dieserFunktion aussieht. Die Deklaration einer API-Funktion wird wie folgt durch-gefuhrt:[Private | Public] Declare [Function | Sub] name Lib filename.dll Aliasnewname (ParameterListe) [As Datentyp]Die Funktionen sind unter dem Windows Betriebsystem je nach Thema undFunktionalitat in verschiedenen DLL-Dateien zusammengefasst. In der Tabel-le 3.1 sind die wichtigsten bzw. die am haufigst genutzten DLL-Dateien so-wie die in diesen DLL-Dateien behandelten Themenschwerpunkte aufgelistet.Informationen uber eine API-Funktion, wie Funktionsname, Ubergabeparame-

DLL-Datei Die Themen der Funktionen

User32.dll Allgemeine Benutzerfunktionen, Nachrichtenverwal-tung, Windowselemente, Timer.

Kernel32.dll Betriebsystembezogene Funktionen wie Speicherhand-ling, Systeminformationen.

Gdi32.dll Zeichenwerkzeuge, Geratekontext bezogene Operatio-nen.

Advapi32.dll Nutzung der Windows Registry, Nutzerrechte, Sicher-heit und EventLogging.

Wininet.dll Internet-Funktionen des Internet Explorers.Wsock32.dll Netzwerk und rechnerubergreifende Kommunikation.Shell32.dll Dateifunktionen, Dateiicons, starten von Anwendun-

gen, Dateidialoge.

Tabelle 3.1: DLLs und ihre Funktionalitaten

3.3. API 25

ter, Ruckgabetyp und Format der Callback-Funktion4 konnen nicht unmittel-bar herausgefunden werden, aber z.B. mittels des Hilfsprogramms ,,WinAPI-Viewer”. Das Programm wird mit den Microsoft Office 2000 Developer (MOD)mitgeliefert und kann im VBA-Editor-Fenster uber MOD-Add-Ins aufgerufenwerden.

Callback-Funtion:Manche API-Funktionen setzten die Adresse einer sogenannten Callback-

bzw. Ruckruf-Funktion als einen ihrer Eingabeparameter voraus. Diese Funktionwird von der API-Funktion bzw. vom Betriebsystem spater automatisch aufge-rufen. Die Adresse dieser Funktion wird mit dem Schlusselwort AddressOf,gefolgt von dem Ruckruf-Funktionsnamen, an die API-Funktion angegeben.Im folgenden Beispiel ist der Einsatz dieses Schlusselwortes in der Funkti-on ,,SetTimer” zu sehen. SetTimer ist eine API-Funktion, die in der Datei,,User32.dll” abgelegt ist. SetTimer setzt die Adresse einer Ruckruf-Funktionals ihren vierten Parameter voraus. Angenommen, diese Ruckruf-Funktion heißtTimerProc: SetTimer soll dann wie folgt aufgerufen werdenSetTimer hwnd, 12345, 5000, AdressOf TimerProc,wodurch dann die Funktion TimerProc nach 5000 Millisekunden automatischaufgerufen wird. Auf die Funktion ,,SetTimer” und deren Einsatz wird in Ka-pitel 6 erneut eingegangen.

Ruckruf-Funktionen mussen in einem Modul definiert werden, da sie di-rekt aufgerufen werden; Deswegen konnen Funktionen in Klassenmodulen undin Formularen nicht als Ruckruf-Funktionen benutzt werden. Bei Ruckruf -Funktionen muss die Parameterliste exakt mit denen ubereinstimmen, die dieHauptfunktion voraussetzt. Die meisten Ruckruf-Funktionen sollten schnellst-moglich ausgefuhrt werden, da sonst Access unvorhergesehen absturzt.

Die Arbeit mit API-Funktionen und besonders mit denen, die eineRuckruf-Funktionsadresse als Parameter voraussetzten, erfordert ge-naue Aufmerksamkeit. Access wird bei einer Anomalie sehr schnellzum Absturz gebracht, auch wenn es sich um eine harmlose Anoma-lie bei der Anwendung einer API-Funktion handelt.

Weiterfuhrende Literatur zu diesem Thema: [VB6Ko] und [APIHnd].

4Der Begriff ,,Callback-Funktion” wird gesondert beschrieben


3.4 Fehlerbehandlung in VBA

Fur ein erfolgreiches Programmieren ist es erforderlich, Fehler am laufendenProgramm zu suchen und zu behandeln. Es gibt grundsatzlich drei verschiedenenArten von Fehlern:

Fehler beim Kompilieren treten auf, wenn im Code Befehle falsch geschrie-ben oder Funktionen falsche Eingabeparameter zugewiesen werden. Diese Funk-tionen konnen entweder in VBA vordefiniert oder vom Benutzer vorprogram-miert sein. Beim Kompilieren werden solche Fehler entdeckt und dementspre-chend gemeldet. Damit das Programm lauffahig ist, mussen diese Fehler be-hoben werden. Das Endergebnis wird also nicht fehlerhaft sein, weil die Fehlerbereits vorher entfernt worden sind. In Access existiert eine ,,automatische Syn-taxprufung”, durch die der Programmierer wahrend der Programmeingabe aufoffensichtliche Schreibfehler sofort hingewiesen wird. Die automatische Syntax-prufung kann im Microsoft Visual Basic Fenster unter [Extras → Optionen →Editor (Code-Einstellungen)] ein- oder ausgeschaltet werden. Es empfiehlt sich,die automatische Syntaxprufung immer einzuschalten, um somit Schreibfehlerzu vermeiden bzw. direkt aufzuspuren und zu beseitigen.

Logische Fehler werden nicht vom Compiler erkannt und daher erst sicht-bar, wenn das Programm vollstandig ausgefuhrt wurde. In einer Testphase sollteein Programm nach solchen Fehlern durchsucht und gegebenenfalls vor seinemeigentlichen Einsatz korrigiert werden. VBA stellt Mechanismen sowie Befehlezur Verfugung, um nach logischen Fehlern zu suchen. Ein in VBA eingesetztesWerkzeug, das sich fur die Fehlersuche als nutzlich erweist, ist der ,,Debug-ger”. Um solche Fehler zu vermeiden ist beim Programmieren ein optimalerUberblick uber den Code notwendig. Dies ist gegeben, wenn Empfehlungen hin-sichtlich der Gestaltung eines Programmcodes berucksichtigt werden: Z.B. sollteein Programmcode gut kommentiert sein und aus mehreren kleinen Prozedurenbestehen.5

Laufzeitfehler treten wahrend der Ausfuhrung eines Programms auf. Ac-cess meldet solche Fehler durch eine entsprechende Fehlermeldung und be-endet das Programm standardmaßig. Laufzeitfehler lassen sich im Code be-handeln, wenn Access-VBA entsprechend eingestellt ist. Im Registerdialogfeldvon VBA kann eingestellt werden, wie VBA auf Laufzeitfehler reagieren soll(Extras → Optionen → Allgemein → Unterbrechen bei Fehlern). Wird derEintrag Bei nicht verarbeiteten Fehlern markiert, so reagiert Access nicht auf

5Vgl. [A00AN], [A00BK], [A97AN].

3.4. FEHLERBEHANDLUNG IN VBA 27

,,behandelte Fehler” und uberlasst die Behandlung solcher Fehler den VBA-Befehlen. Jeder aufgetretene Fehler wird von Access in einem Err-Objekt abge-legt. Von diesem Err-Objekt konnen anschließend die Eigenschaften des Fehlersabgelesen werden. Das Err-Objekt beinhaltet Methoden, die zur Fehlerbehand-lung eingesetzt werden konnen.6

Die Behandlung von Laufzeitfehlern wird im Code mit On Error GotoLabel aktiviert. Dadurch wird jeder Laufzeitfehler zwischen On Error GotoLabel und der mit Label markierten Zeile abgefangen. Wie dieser Fehler behan-delt werden soll, ist erst ab der Zeile Label vorgegeben. In der Tabelle 3.2 sinddie Befehle aufgelistet, mit deren Hilfe die Fehler in (Access-)VBA behandeltwerden:

Die Fehler in einer Funktion werden an die aufrufende Funktion weitergelei-tet. Eine On Error -Fehlerbehandlung gilt fur die Prozeduren bzw. Funktionen,fur die sie vereinbart wurden und fur alle Unterprogramme, d.h. fur alle Proze-duren und Funktionen, die in dem Programm mit der Fehlerbehandlung aufge-rufen werden. Das gilt nicht fur Programmteile oder Unterprogramme, fur dieeine eigene Fehlerbehandlung programmiert wurde. Diese Methode der Fehler-behandlung wird vorwiegend bei Programmen eingesetzt, in denen Fehler auchin Unterfunktionen vorkommen konnen, die dann jedoch die gleiche Wirkungauf das Gesamtergebnis des Programms haben. Im folgenden ist als Beispieleine einfache Fehlerbehandlung in einer Sub-Funktion dargestellt:

Sub Fehlerbehandlung()

On Error GoTo FB_Error

Anweisungen

FB_Exit:

Exit Sub

FB_Error:

Die Fehlerbehandlung passiert hier!

Resume FB_Exit

End Sub

Bei Eintritt eines Laufzeitfehlers wird die Ausfuhrung des Programms an dieZeile FB Error weitergeleitet, in der die eigentliche Fehlerbehandlung durch-gefuhrt wird. Nach der Fehlerbehandlung wird die Ausfuhrung des Programm

6Vgl. [A00AN], S.233


Fehlerbehandlung wei-terleiten

Beschreibung

On Error Goto Label Die Fehlerbehandlung wird mit diesem Be-fehl an die Zeile mit der Sprungmarke bzw.mit der Zeilennummer Label weitergeleitet.

On Error Resume Next Beim Eintritt eines Fehlers ignoriert dasProgramm die Ausfuhrung der fehlerhaf-ten Zeile und macht mit der nachsten Zeileweiter. Deswegen wird das Programm beimEintritt eines Fehlers nicht angehalten!

On Error Goto 0 Mit diesem Befehl wird die Fehlerbehand-lung wieder an Access zuruckgegeben, d.h.nach diesem Befehl halt das Auftreten ei-nes Fehlers die Programmausfuhrung an.

Verhalten nach derFehlerbehandlung

Beschreibung

Resume Nach der Fehlerbehandlung beginnt dieAusfuhrung des Programms von der Zeilean, in der der Fehler aufgetreten ist.

Resume Next Nach der Fehlerbehandlung wird das Pro-gramm von der Zeile weiter ausgefuhrt, dieder fehlerhaften Zeile unmittelbar folgt.

Resume Label Nachdem der Fehler behandelt wurde, wirddas Programm von der Zeile Label weiterausgefuhrt.

Tabelle 3.2: Befehle zur Fehlerbehandlung in VBA

3.5. TRANSAKTIONEN IN VBA 29

an die Zeile FB Exit weitergeleitet, in der eine ordnungsgemaße Beendigung desProgramms mit dem Befehl Exit Sub gewahrleistet ist.7

3.5 Transaktionen in VBA

Mehrere Datenbankoperationen konnen in Access zu einer Transaktion zusam-mengefasst werden. Das Zusammenfassen einer Anzahl von Datenbankanderun-gen zu einer Transaktion gewahrleistet, dass entweder alle Anderungen vorge-nommen werden oder uberhaupt keine. Bei der Ausfuhrung von Datenbankande-rungen in einer Transaktion muss die Einhaltung der ACID8-Eigenschaften vomDatenbankmanagementsystem garantiert werden. Bei einer Aktionsabfrage kanneingestellt werden, ob die Anderungen, die von dieser Abfrage vorgenommenwerden, in einer Transaktion zusammengefasst werden sollen. Im VBA-Codewird allerdings eine andere Methode angewendet, um Transaktionen zu erzeugenund zu verwalten. In VBA steht das DAO9-Workspace-Objekt mit seinen Me-thoden fur die Transaktionsverwaltung zur Verfugung. Das Workspace-Objektenthalt drei Methoden zur Transaktionsverwaltung:

• BeginTrans informiert Access, dass eine Transaktion begonnen wurde.Von da an werden alle Anderungen zwischengespeichert.

• ComitTrans schließt die Transaktion ab, dabei werden alle Anderungenfestgeschrieben.

• Rollback setzt alle Anderungen zuruck, die innerhalb dieser Transaktionvorgenommen wurden.

In einem Access-VBA-Code konnen bis zu funf Transaktionen ineinander ver-schachtelt werden. Abschließend wird im folgenden Beispiel dargestellt, wie eineTransaktion im Code verwaltet wird.10

7Vgl. [A00AN], [A00BK], [A97AN].8Atomicity Consistency Isolation Durability: s. [ISKeEi], [ISVrl],[ISVos]9Vgl. Abschnitt 4.3

10Vgl. [A00AN], [A00BK] und [A97AN]


Sub TransAktion()

Dim wksp As DAO.Workspace

Set wksp = DBEngine.Workspaces(0)

wksp.BeginTrans

If (Erfolgreiches Datenbank-Update) THEN

wksp.CommitTrans

Else

wksp.Rollback

End If

End Sub

Kapitel 4

MS-Access

,,Access” ist in der ersten Version 1.0 im Jahre 1993 auf den Markt gekommen.Diese Version hatte wenige Assistenten und erfullte trotzdem grundlegende An-forderungen eines Datenbankmanagmentsystems fur PC’s. Diese Version unddie nachfolgenden Versionen 1.1 und 2.0 waren 16-Bit Anwendungen und wur-den vor allem mit den Betriebsystemen Windows 3.1 und 3.11 eingesetzt. Mitder nachsten Version ,,7.0” wurde die neue Generation von MS Access, d.h.32-Bit Anwendung, ins Leben gerufen wurde. Nacheinander wurden mit denneuen Versionen Mangel und Schwachpunkte beseitigt und neue Komponentenhinzugefugt, wie z.B. bessere Assistenten.

4.1 Tabellen und Beziehungen

Access ist ein relationales Datenbankmanagementsystem und daher werden ineiner Access-Datenbank die Informationen in Relationen bzw. Tabellen gespei-chert. Jede Tabelle besteht aus Spalten, die innerhalb der Tabelle eindeutigeNamen haben. Jede Zeile einer nicht leeren Tabelle ist ein Datensatz. Die Ta-bellen, Spalten und Zeilen in Access reprasentieren jeweils Relationen, Attributeund Tupel. Jede Tabelle darf bis zu 255 Spalten (bzw. Felder) haben. Die Felder-namen durfen aus bis zu 64 Zeichen bestehen. Jeder Spalte kann ein Datentypzugeordnet werden und das bedeutet, dass die Eintrage in dieser Spalte nur denangegebenen Datentyp haben durfen.

Fur jede Tabelle kann ein Primarschlussel bestimmt werden. Der Primar-schlussel ist eine Spalte, in der kein Wert mehrfach vorkommen darf. Da-mit werden die Datensatze (Informationen in Zeilen) eindeutig bestimmt. DerPrimarschlussel kann entweder manuell erzeugt werden oder automatisch durchAnweisung an Access. Der automatisch erzeugte Schlussel ist ein Autowert-

31

32 KAPITEL 4. MS-ACCESS

Feld, das den Datentyp ,,Long Integer” hat. Ein Feld mit dem Typ ,,Autowert”erhalt bei jedem neuen Datensatz automatisch einen neuen eindeutigen Wert.Als Primarschlussel kann auch eine Gruppe von Feldern einer Tabelle gewahltwerden, wobei die Kombination dieser Felder Eindeutigkeit des Datensatzesgewahrleistet.

Beziehungen und IntegritatBeziehungen werden zwischen der Tabellen aufgebaut. Eine Beziehung wird

zwischen zwei Tabellen aufgebaut, indem der Primarschlussel einer Tabelle miteinem Feld bzw. einer Menge von Feldern einer anderen Tabelle verbunden wird.Das Feld bzw. die Menge von Feldern der anderen Tabelle heißen in diesem Falle,,Fremdschlussel”. In Access gibt es drei Beziehungstypen:

• 1:1-Beziehung ist die einfachste Art. Dabei existiert fur jeden Datensatzder Quelltabelle genau einen Datensatz in der Zieltabelle.

• 1:n-Beziehung ist die am haufigst eingesetzte Beziehung in Access. Dabeikonnen zu einem Datensatz in der Quelltabelle mehrere (n) Datensatzein der Zieltabelle existieren.

• n:m-Beziehung ist eine Beziehung, die angibt, dass ein Datensatz in derTabelle 1 n Gegenstucke in der Tabelle 2 hat und ein Datensatz in Tabelle2 m Gegenstucke in der Tabelle 1 hat. Der Aufbau dieser Beziehung istnur mit Hilfe einer Zwischentabelle moglich.

Integritat wird in Access mit Hilfe von zwei Mechanismen unterstutzt. Durchden ersten Mechanismus wird die Gultigkeit eines Datensatzes gepruft, und imFalle eines Verstoßes gegen die Gultigkeitsregeln wird eine Fehlermeldung aus-gegeben und die Datensatzanderung zuruckgesetzt. Diese Regeln lassen sichfur eine Tabelle, sowie fur einzelne Spalten aufstellen. Der zweite Mechanismuskommt erst mit dem Aufbau einer Beziehung zustande. Jede Beziehung hatbestimmte Eigenschaften, die eingestellt werden konnen. Im Eigenschaftfenstereiner Beziehung werden mehrere Moglichkeiten angeboten, Eigenschaften spe-zifisch fur die Beziehung zu bestimmen. Als eine Eigenschaft einer Beziehungkann ,,Mit referentieller Integritat” angegeben werden. Dadurch darf einneuer Datensatz in einer Tabelle mit einem Fremdschlussel nicht eingefugt wer-den, wenn kein entsprechender Wert in der referenzierten Tabelle existiert. Diereferenzierte Tabelle ist die Tabelle, deren Primarschlussel an der Beziehungbeteiligt ist. Als weitere Eigenschaft einer Beziehung kann auch eingegeben wer-den, was mit den Datensatzen in einer Tabelle mit Fremdschlussel passieren soll,wenn die Werte in der referenzierten Tabelle geandert oder geloscht werden.

4.2. FORMULARE 33

Abfragen und SQL-Befehle:Eine Abfrage (View in Access) ist eine Access-Komponente, mit deren Hil-

fe bestimmte Datensatze aus einer oder mehreren Tabellen ausgewahlt werdenkonnen. Mit einer Abfrage ist es auch moglich, die Anzahl einer Datenauswahl,den Durchschnitt einer Datenauswahl und weitere Details zu bestimmen. EineAbfrage in Access ist nicht nur eine Oberflache, die dem Benutzer bestimmteInformationen zeigt, die ausgewahlten Datensatze einer Abfrage konnen auchgeandert werden. Je nach Abfragetyp kann die Ausfuhrung der Abfrage be-stimmte Aufgaben erledigen. Es existieren in Access verschiedene Abfragetypen:Auswahlabfrage, Kreuztabellenabfrage, Tabellenerstellungsabfrage, Aktualisie-rungsabfrage, Anfugeabfrage und Loschabfrage. Welche Aufgaben mit Hilfe wel-cher Abfragen erledigt werden konnen, ist aus dem Namen ersichtlich1. Deswei-teren ist noch die Beziehung zwischen Access-Abfragen und SQL zu beleuchten.Im Hintergrund jeder Abfrage versteckt sich ein SQL-Ausdruck. Bei einer Aus-wahlabfrage fangt der SQL-Ausdruck z.B. mit ,,SELECT . . . ” an.

QBE steht fur Query By Example. Die Abfragen-Entwurfansicht, die Benut-zerschittstelle zur Herstellung von Abfragen, wird als QBE bezeichnet. In derEntwurfansicht einer Abfrage lassen sich jede Art von Abfragen, auch kompli-zierte, formulieren. Diese Methode hilft vor allem Anfangern, SQL-Ausdrucke zuformulieren. Auch die Profis werden davon profitieren, weil die SQL-Ausdruckesich mit Hilfe von QBE einfach und ohne Schreibfehler formulieren lassen.

4.2 Formulare

Formulare sind Access Komponenten, die als Benutzeroberflache benutzt wer-den. Formulare konnen gebunden oder ungebunden sein. Ein gebundenes For-mular unterscheidet sich von einem ungebundenen Formular in der Datenquelle.Ein Formular kann mit einer Tabelle oder einer Gruppe von Tabellen verknupftwerden. Die Datensatze der Tabelle konnen innerhalb des gebundenen Formu-lars direkt bearbeitet werden. Die Anderungen an Datensatzen innerhalb einesgebundenen Formulars werden sofort in der Tabelle sichtbar.

Ein ungebundenes Formulars ist mit keiner Tabelle verknupft, und wird nurals Oberflache genutzt. Mit den dafur vorgesehenen Assistenten konnen Formu-lare im Access-Hauptfenster erstellt werden. Wie oben bereits erwahnt, ist einFormular ein Access-Objekt, das aus mehreren Kontrolelementen (Steuerele-menten) bestehen kann. Ein Steuerelement ist selbst ein Access-Objekt, undkann wiederum aus Unterobjekten bestehen. Bezeichnungsfelder, Textfelder,Kombinationsfelder, Listenfelder, Optionsfelder, Buttons (Befehlsschaltflachen)

1Weitere Details uber Abfragen in [A00AN], [A00BK] und [A97AN].


und etc. sind Steuerelemente, die in ein Formular eingebaut werden konnen.Jedes dieser Steuerelemente hat eigene spezielle Funktionalitaten, die in einemFormular benutzt werden. Z.B. konnen Buttons dafur eingesetzt werden, umper Mausklick VBA-Funktionen auszufuhren.

Formular-Klassenmodule: Hinter jedem Formular versteckt sich ein Klas-senmodul. Dieses Klassenmodul wird gleichzeitig mit dem Formular erstellt undist somit ein Teil des Formulars. Was mit dem Formular passiert, wird auch seinKlassemmodul beeinflussen. Wird z.B. ein Formular geloscht, wird auch seinKlassenmudol geloscht. In einem Formular-Klassenmodul konnen Funktionenund Variablen definiert werden. Aus einem Formular kann ein Objekt (eine In-stanz) instantiiert werden. Dieses Objekt kann aber nur dann weiter angewendetwerden, wenn erst das zugehorige Formular geoffnet wird. Das Formular kannentweder einfach per Mausklick geoffnet werden oder innerhalb einer Prozedurbei der ein Objket vom Formular intantiiert und dessen Eigenschaft Visible aufTrue gesetzt wird.

Formular-Ereignisse sind die wichtigsten Eigenschaften von Formularen, diein einer Access-Anwendung benutzt werden. Auf dem Bild 4.1 ist das Registerdes Eigenschaftfensters eines Formulars dargestellt. In einem Formular ist esmoglich einzustellen, dass beim Vorkommen eines bestimmten Ereignisses einebestimmte Prozedur ausgefuhrt wird. Diese Prozedur wird im Klassenmoduldefiniert, deren Programmierung dem Benutzer uberlassen wird. Die Ereignis-Prozeduren haben vordefinierte Namen. In folgendem Beispiel ist die Prozedur,die beim Loschen eines Datensatzes ausgefuhrt wird gezeigt.

Private Sub Form_Delete(Cancel As Integer)

Anweisungen

End Sub.

Nicht nur fur ein Formular konnen Ereignisse definiert und programmiert wer-den, sonder auch fur seine Steurelemente, z.B. die Ausfuhrung einer Prozedurbeim Eintritt des Ereignisses. Die Prozedur im folgenden Beispiel wird beimAuftritt des Ereignisses ,,Der Mausklick auf dem Button btn EditAction” aus-gefuhrt.

Private Sub btn_EditAction_Click()

Anweisungen

End Sub

4.2. FORMULARE 35

Abbildung 4.1: Formular-Ereignisse


4.3 Datenzugriffsobjekte

Jet Database Engine ist der Kern einer Access-Datenbank. Auf alle Da-ten einer Access-Datenbank konnen nur mit Hilfe von Jet DB Engine zugegrif-fen werden. Anforderungen an eine Access-Datenbank muss uber diesen Kerngehen. Dieser Kern steht zwischen den Daten und den ubrigen Teilen einerAccess-Datenbank. Im Grunde genommen hat ein Access-Datenbankmanage-mentsystem alle Funktionalitaten, um eine Datenbank zu verwalten, insbeson-dere die entsprechende Benutzeroberflache und die Jet Database Engine. AlsBenutzeroberflachen sind z.B. Formulare, Berichte und Abfragen zu nennen.Die Aufgabe von Jet DB Engine ist es, die Anderungen, die uber eine Benut-zeroberflache vorgenommen werden, an die Datenbank weiterzuleiten. Im Bild4.2 ist gezeigt, wie die Access-Komponente mit dem Jet DB Engine verbundensind. In Access besitzen die Datenzugriffsobjekte eine Hierarchie, deren Spitze

Microsoft Access

MS Acces Datenbank

Jet Database Engine

MS Access Benutzeroberfläche

MS Access Applikation

Abbildung 4.2: Access un Jet DB Engine

das Objekt DBEngine ist. DBEngine ist eine Datenbankmaschine und bezeich-net den Jet Database Engine in Access. DBEngine ist keine Auflistung sondernein Einzelobjekt. Die Hierarchie wurde im Buch [A00AN] auf Seite 322 geschil-dert.

DAO oder ADO:In Access 2000 existieren zwei Datenzugriffsschnitstellen. Die Klassische Da-

tenzugriffsschnitstelle ist DAO (Data Access Objekts). Diese Schnittstelle stellt

4.3. DATENZUGRIFFSOBJEKTE 37

viele Objekte und Methoden zur Verfugung, um auf Daten einer Access Daten-bank zuzugreifen. DAO ist fur den Zugriff auf relationale Datenbanken vorgese-hen. Die zweite Schnittstelle ist ADO (AktiveX Data Objekts). ADO wurde soentwickelt, um nicht nur auf relationale Datenbanken sondern auch auf ande-ren Datenquellen zuzugreifen. Mit Access 2000 sollte DAO durch ADO abgelostwerden. Es ist der Firma Microsoft aber nicht gelungen, alle ADO-Komponenterechtzeitig fertig zu stellen. Deswegen ist der Einsatz von DAO in einer Access2000 Datenbank-Anwendung unvermeidbar. DAO ist beim Einsatz in lokalenAccess Datenbanken sehr stabil.

Recordset ist ein haufig eingesetztes Datenzugriffsobjekt. Mit Hilfe von Re-cordset konnen die Datensatze einer Tabelle oder einer Abfrage verwaltet wer-den. In einem Recodset werden die Datensatze einer Tabelle getrennt voneinan-der zwischengespeichert. Um auf einen Datensatz in einem Recordset zuzugrei-fen, soll das Objekt ,,Recordset” in einer Schleife durchlaufen werden. Daherkann zu einem Zeitpunkt nur ein Datensatz zu modifiziert werden. Execute istein Befehl, unter den ein SQL-Ausdruck in VBA ausgefuhrt wird. Execute isteine Methode des Objektes Database. Das folgende Beispiel zeigt den Einsatzvon Recordset in einer Prozedur. Im Beispiel werden alle Datensatze der Tabel-le Angestellte so modifiziert, dass der Lohn jedes Angestellten um 20% erhohtwird.

Public Sub MehrLohnMitRecordset()

Dim rstAng As DAO.Recordset

Set rstAng = CurrentDb().OpenRecordset("Angestellte")

With rstAng

Do While rstAng.EOF = False

.Edit

!Lohn = !Lohn * 1.2

.Update

rstAng.MoveNext

Loop

End With

End Sub

Dieses Ziel konnte auch mit dem Einsatz von Execute und einem SQL-Ausdruckwie im folgenden Beispiel erreicht werden.

Public Sub MehrLohnMitExecute()

CurrentDb().Execute "UPDATEAngestellte SET Angestellte.Lohn =" _

& "Angestellte.Lohn * 1.2;"

End Sub


Im allgemeinen ist eine Ausfuhrung eines SQL-Ausdrucks schneller als die Da-tenmanipulation mit Hilfe von Recordset.

4.4 Sicherheit

Fur die Sicherheit sind in Access verschiedene Mechanismen vorgesehen. DieseMechanismen sind wie folgt:

• Datensicherheit: Die Access Datenbank kann mit einem Passwort geschutztwerden. In diesem Fall wird jeder Benutzer beim Offnen der Datenbankaufgefordert, ein Passwort einzugeben. Diejenigen Benutzer, die das Pass-wort kennen, erhalten Zugriff auf die Datenbank und konnen (alle) Datenin der Datenbank bearbeiten.

• Datensicherheit: In einer Access Datenbank existiert ein Mechanismus,mit dessen Hilfe Benutzer und Gruppen definiert werden konnen. DenBenutzern und Gruppen konnen so Zugriffsrechte exakt erteilt werdenund es wird definiert, wer welche Access-Komponente und darin enthalteneDaten sehen, andern oder loschen darf. Das ist die hochste Datensicherheitin Access.

• Codesicherheit: Die Codes in einer Access Datenbank konnen mit einemPasswort geschutzt werden. Kennt ein Benutzer das Passwort, so darf erCodes bearbeiten.

• Codesicherheit: Codes konnen auch gesichert werden, indem von der Da-tenbank eine MDE-Datei erstellt wird. In der MDE-Datei konnen keineCodes bzw. keine Access-Komponenten mit Codes (Formulare, Berichte,etc.) bearbeiten werden.

Jede Komponente in Access muss einen Namen haben. Die Komponenten, de-ren Name mit MSys oder USys anfangen sind als Systemkomponenten zu in-terpretieren. MSys steht fur die Access-Systemkomponente und USys fur dieKomponente, die der Benutzer als Systemkomponente bezeichnen mochte. Je-de Access Komponente kann zusatzlich als ausgeblendet gekennzeichnet wer-den. Im Access-Hauptfenster (unter Extras → Optionen → Ansicht) kann ein-gestellt werden, ob die jeweilige Systemkomponente und/oder ausgeblendeteKomponente angezeigt werden durfen. Dieser Mechanismus kann genutzt wer-den, um bestimmte Access-Komponente vor der direkten Sicht der Benutzer zuverstecken. Trotzdem stellt dieser Vorgang keine dieser Komponenten richtigsicher.

Kapitel 5

Ein Konzept fur eine aktiveErweiterung von Access

Access ist kein aktives Datenbankmanagementsystem und bietet demzufolgeAnwendern keine Moglichkeit an, um Trigger und Ereignismuster definieren zukonnen. In diesem Kapitel wird untersucht, ob eine Trigger-Funktionalitat inAccess realisiert werden kann. Im weiteren wird ein Konzept vorgestellt, wieeine Erweiterung von Access um eine Regelsprache aussehen kann. Access kannum eine Triggersprache erweitert werden, ohne dass ernsthafte Einschrankungenzu erwarten sind. Da in Access und Jet Engine die Sourcecodes nicht verander-bar sind, lassen sich die notwendigen Anforderungen, die ein aktives Daten-bankmanagementsystem erfullen muss, nicht direkt im Access-Sourcecode pro-grammieren. Diese Anforderungen betreffen vor allem Triggerverwaltung undEreigniserkennung. Damit Trigger und Ereignismuster definiert und Ereignisseerkannt werden konnen, mussen diese Systeme in einem aktiven Datenbankma-nagementsystem existieren.

5.1 Das Konzept eines Praprozessors

Eine Access-Anwendung ist eine Kombination von Access-Komponenten, derenZweck die Erledigung einer bestimmten Aufgabe ist. Die Trigger-Funktionalitatkann in Form einer Access-Anwendung unter Benutzung der Programmierspra-che VBA programmiert werden. Diese Anwendung hilft zunachst dem Benutzer,Trigger zu definieren. Weitere Aufgabe der Anwendung ist die Ereigniserken-nung und die Bearbeitung der durch dieses Ereignis gefeuerten Trigger. AlleDatenbankanderungen werden in Access mit Hilfe der Jet Database Engineerledigt. Die Jet Engine ist eine Schnittstelle zwischen den Daten und der Be-nutzeroberflache in Access. Die Oberflachen sind Access-Komponenten, durch

39

40 KAPITEL 5. KONZEPT

die Daten einer Access-Datenbank manipuliert werden konnen. Insbesondere we-gen der Ereigniserkennung muss diese Anwendung zwischen Benutzerobeflachenund der Jet Engine stehen. Bei diesem Konzept ist die Access-Anwendung eineSchnittstelle zwischen Datenanderungsanforderungen und der Jet Engine (bzw.den Daten). Die Anwendung funktioniert hier also wie ein Praprozessor zwi-schen Anwendern und dem Access(-Prozessor). Diesen Praprozessor nennen ichARTA. ARTA steht fur ,,Active Real Time Access Database System”.Das Bild 5.1 schildert die Beziehung zwischen ARTA und Access.

Daten

Benutuzer

Jet DB Engine ARTA

Abbildung 5.1: ARTA in Access

Wie der Name ARTA sagt, wird mit diesem Praprozessor versucht, dieAspekte ,,Aktivitat” und ,,Zeitabhangigkeit” zu berucksichtigen. Durch ARTAwird das Access-Datenbankmanagementsystem in ein aktives Access-Daten-bankmanagementsystem uberfuhrt, in dem auch Zeitereignisse definiert undwahrgenommen werden konnen. Dabei werden verschiedenen Typen von Ereig-nismustern definiert und die entsprechenden Ereignisse aufgefangen und bear-beitet. In ARTA existieren zwei Ereignistypen, Zeitereignisse und Anderungser-eignisse. Anderungsereignisse treten bei Datensatzmanipulationen (an AccessTabellen) auf, d.h. bei Loschen (DELETE), Hinzufugen (INSERT) oder beiAnderung an Datensatzen (UPDATE). Zeitereignisse werden in zwei Unterty-pen aufgeteilt, absolute und periodische Zeitereignisse.

Die Kombination der Programmiersprache VBA mit dem Access-Daten-bankmanagementsystem und der unter Access verwendeten SQL-Anfragespracheergibt ein potentes Werkzeug, mit dessen Hilfe man verschiedene Anwendungenfur Access programmieren kann. Dieses Werkzeug reicht fur die Erweiterungvon Access um eine Triggersprache vollig aus. Das Access-Datenbankmanage-mentsystem bietet dem Programmierer seine Komponenten, z.B. Tabellen undFormulare an, mit deren Hilfe die Trigger-Informationen verwaltet und gespei-

5.1. DAS KONZEPT EINES PRAPROZESSORS 41

chert werden konnen. In VBA kann auf alle Access-Komponenten zugegriffenwerden und mit Hilfe von VBA-Methoden konnen Datenbankanderungen auto-matisch durchgefuhrt und beobachtet werden.

Die Anfragesprache SQL wird in Access in einem speziellen Dialekt un-terstutzt. Dieser Dialekt ist keine Einschrankung fur die Formulierung der not-wendigen SQL-Ausdrucke und erfullt alle Anforderungen, die bei der Manipu-lation der Daten gestellt werden. Mit Access-SQL ist auch die Formulierungvon DDL1-Befehlen z.B. ,,Create Table ...” moglich. SQL-Ausdrucke lassen sichals Datenquelle fur Formulare und Abfragen formulieren. Um die Einfachheitvon Access bezuglich der Datendefinition beizubehalten, werden als Eingabe inARTA nur die drei DML-Befehle DELETE, INSERT, UPDATE erlaubt sein.In ARTA wird es z.B. nicht moglich sein, Tabellen zu definieren, oder Tabellen-definitionen (Evolution) zu andern. Dazu stehen dem Benutzer alle Funktiona-litaten von Access wie gewohnt zur Verfugung. SQL-Ausdrucke konnen auch ineinem VBA-Code ausgefuhrt werden (database.Execute(SQL)). Das ist beson-ders interessant, da auch die Folgeanderungen in Form eines SQL-Ausdruckseingegeben und im Code automatisch ausgefuhrt werden konnen. Diese Fol-geanderungen sind insbesondere die Anderungen, die durch die Ausfuhrung desAktionsteils eines gefeuerten Triggers zustande kommen konnen.

Die Benutzung von ARTA lauft unter einer Einschrankung. Diese Einschran-kung hat ihre Ursache in der Ereigniserkennungsproblematik. In einer herkomm-lichen Access-Datenbank werden Daten einer Tabelle wie folgt geandert:

• Die Anderung kann direkt an der Tabelle durchgefuhrt werden, nachdemdie Tabelle geoffnet wurde.

• Die Anderung kann indirekt durch ein Formular, das mit der Tabelle ver-knupft ist, durchgefuhrt werden.

• Daten einer Tabelle konnen auch in einer Abfrage, deren Datenquelle dieseTabelle ist, manipuliert werden.

Keine dieser Methoden eignet sich fur die Erweiterung um eine Triggerspra-che, weil Datenanderungen bei diesen Methoden nicht als Ereignisse aufzu-fangen sind. Das wird noch problematischer, wenn andere Trigger durch denAktionsteil eines aktuell gefeuerten Triggers gefeuert werden sollen. Diese soge-nannten Folgeanderungen mussen automatisch durchgefuhrt werden. Die in Ac-cess ublichen Datenbankanderungesarten sollten durch ARTA ubergangen wer-den, d.h. alle Datenbankanderungsbefehle sollten in ARTA eingegeben werden.

1Data Definition Language


Die Ausfuhrung dieser Befehle wird dann von ARTA kontrolliert durchgefuhrt.Dafur wird in ARTA eine Oberflache vorgesehen, in der alle Anderungsbefehleder Form ,,DELETE, INSERT, UPDATE” eingegeben werden sollen.

Ein Mechanismus in Access sorgt hier fur Missverstandnisse. Die Frage stelltsich, warum die Formular-Ereignisse nicht benutzt werden konnen, um Er-eignisse aufzufangen. Ereignisse konnten doch ,,innerhalb” eines Formulars au-tomatisch erkannt werden. Trigger konnten so in dem Formular-Klassenmodulmit Hilfe von Funktionen und Subs formuliert werden. Ein Formular muss miteiner bestimmten Tabelle verknupft sein, damit der Benutzer Datenanderungenan der Tabelle uber dieses Formular vornehmen kann. Daten der jeweiligen Ta-belle mussen deshalb nur uber dieses Formular modifiziert werden, um sie alsEreignisse wahrgenommen zu werden. Trigger mussen deswegen einzeln zu jederTabelle in einem separaten Formular mit Hilfe der Programmiersprache VBA,,programmiert” werden. Hier fehlt jedoch ein Zentralsystem fur die Triggerbe-arbeitung.

Im ubrigen konnen die vom Aktionsteil eines Triggers angeforderten Da-tenanderungen an einer anderen Tabelle nicht durchgefuhrt werden, es sei dennaus einem Formular werden andere Formulare geoffnet und die Folge-Anderun-gen werden in neu geoffneten Formularen durchgefuhrt. Dabei ist zu beachten,dass alle beteiligten Formulare mit geeigneten Tabellen verknupft sein mussen.Diese Art von Triggerdefinition und Triggerbearbeitung ist nicht realistisch. Zu-sammengefasst sind die Formular-Ereignisse nicht geeignet, um ein automati-sches Triggerbearbeitungssystem zu realisieren. Formular-Ereignisse eignen sich,die Definition und Anderung von Triggern zu uberwachen. Dafur wird einzig dieSyntaxprufung durch die Formular-Ereignisse mit Hilfe von VBA programmiert.

Ein Trigger in ARTA besteht aus allgemeinen Informationen uber den Trig-ger und aus drei weiteren Grundteilen: Ereignismusterteil (Event), Bedingungs-teil (Condition) und Aktionsteil(Action). Die allgemeinen Informationen einesTriggers sind vor allem der Name und die Prioritat des Triggers. Im Falle ei-nes Anderungsereignisses konnen auch Parameter vordefiniert werden, die In-formationen uber die betroffenen Datensatze (Zeilen) der Tabelle enthalten.Die betroffenen Zeilen sind die Datensatze, die durch die Ausfuhrung einesSQL-Datenbankanderungsbefehls geandert werden. Die Anzahl der betroffenenZeilen konnen auch Null sein, d.h. trotz der SQL-Ausfuhrung werden keine Da-tensatze eingefugt, geloscht oder geandert. Der Ereignismusterteil eines Triggershat einen eindeutigen Namen. Mit diesem Namen sind die weiteren Informatio-nen des Ereignismusters verknupft. Die weiteren Informationen sind vor allemdas Erzeugungsdatum, das Datum der letzten Anderung des Ereignismusters


und der Ereignismustertyp. Je nach Ereignismustertyp gehoren dem Ereignis-muster spezifische Eigenschaften an.

Zum Ereignismuster vom Typ ,,Anderungsereignis” gehoren der Tabellen-name und der DML2-Befehl. Einem Ereignismuster vom Typ ,,Zeit-Ereignis-atOnce” gehoren date, time und deadLine an. Begin-date, Begin-time, deadLi-ne und die Periode gehoren zu einem Ereignismuster vom Typ ,,Zeit-Ereignis-periodic”. Zeitereignisse werden in einem gesonderten Abschnitt beschrieben.Anderungsereignismuster in ARTA sind dem SQL3-Standard3 sehr ahnlich, daARTA auf dem SQL3 basiert. Im Unterschied zum SQL3-Standard werden inARTA Anderungsereignisse nur auf der Ebene von Tabellen definiert. Eine Da-tenanderung auf einem bestimmten Feld einer Tabelle kann ja als eine Da-tenanderung auf der Tabelle interpretiert werden.

In SQL existiert keine ja/nein Abfrage, mit SELECT formulierte Abfragengeben eventuell ausgewahlte Datensatze zuruck. Fur den Bedingungsteil einesTriggers in ARTA konnen ja/nein Abfragen durch die Definition bestimmterFunktionen realisiert werden. Eingabeparameter einer solchen Funktion konn-te z.B. ein SQL-Ausdruck sein und die Funktion gibt zuruck, ob durch diesenSQL-Ausdruck Datensatze ausgewahlt werden (z.B. ExistElement(SQL)). Ei-ne mogliche Triggerbedingung ist auch ein Vergleich vordefinierter Parameter,Konstanten oder der aktuellen Zeit miteinander, z.B.NewRowPar.Verlaengerung um > 42. Standardmaßig wird eine leere Trigger-bedingung als ,,ja(True)” interpretiert. Der Aktionsteil eines Trigger ist einausfuhrbarer Ausdruck. Als Triggeraktion ist in ARTA im Unterschied zu SQL3ein einziger zusammengehorender Ausdruck erlaubt. Dieser Ausdruck kann einein VBA vorhandene oder vom Benutzer neu eingebaute Funktion sein. In einervom Benutzer eingebauten Funktion kann programmiert werden, dass mehr alsein Befehl ausgefuhrt wird.

Durch diese Methode kann der Aktionsteil eines Triggers eine Funktiona-litat aufweisen, die auch in SQL3 vorgesehen ist. Diese Funktionen sollten alsglobale Funktionen und in Modulen (nicht in Klassenmodulen) definiert sein,da die in einem Klassenmodul definierten Funktionen nur durch initiierte Ob-jekte aufrufbar sind. Aber die in einem Modul als global definierte Funktionist uberall in VBA und sogar in Access-Komponenten ausfuhrbar. Dabei isthinzuzufugen, dass diese Methode nicht fur jeden Benutzer geeignet ist. DieseMethode ist eher fur die Benutzer geeignet, die die Programmiersprache VBA

2Data Manipulation Language3Vgl. 2.2


beherrschen. In der Implementierung von ARTA werden Funktionen vorgestellt,die auch nicht VBA-Programmierer anwenden konnen.

Unterschiede zwischen den Triggersprachen in ARTA und SQL3:Eine Zusammenfassung der Unterschiede zwischen der SQL3- und ARTA-

Triggerfunktionalitat wurde in der Tabelle 5.1 gegeben. Im Vergleich zu SQL3ist die Behandlung von Zeitereignissen in ARTA als eine Erweiterung zu be-trachten. In SQL3 werden nur Anderungsereignisse spezifiziert, die im Ereignis-teil von Triggern beschrieben werden. Zusatzlich dazu werden in ARTA auchZeitereignisse behandelt, die im Ereignisteil von ARTA-Triggern beschriebenwerden.

ZeitereignisseFur die Realisierung von Zeitereignissen bzw. Timern existieren folgende

Moglichkeiten in Access und VBA:

• Formularereignis: (Bei Zeitgeber)Uber das Formularereignis ,,Bei Zeitgeber” kann in einem Formular ein-gestellt werden, dass eine Prozedur in seinem Klassenmodul periodisch ingleichen Zeitabstanden (in Millisekunden) ausgefuhrt wird.

• Durch Benutzung des Befehls ,,DoEvents” in einer Prozedur kann einebestimmte Funktion in gleichen Zeitabstanden aufgerufen werden. In derfolgenden Prozedur wird alle 4 Sekunden die aktuelle Zeit ausgegeben:

Public Sub Timer()

Dim dte As Date

Do While True

Debug.Print Now()

dte = Now()

Do While (4 > DateDiff("s", dte, Now()))

DoEvents

Loop

Loop

End Sub

• Mit Hilfe von API-Schnittstelle.

Fur die Realisierung von Timern in ARTA wurde die Methode von API-Schnittstelle ausgewahlt. Die Methoden und die Benutzung von API-Funktionenwurden im Kapitel 6 ausfuhrlich beschrieben. Die API-Schnittstelle wurde aus


SQL3 ARTA

Art derEreignisse

In SQL3 werden Zeitereig-nisse uberhaupt nicht un-terstutzt.

In ARTA besteht dieMoglichkeit, Zeitereignisnu-ster zu definieren.

Definitionvon Triggernund Ereignis-

mustern:

Ereignismuster haben kei-ne Namen (Bezeichnungen),so muss fur jeden Triggerein Ereignismuster angege-ben werden.

Jedes Ereignismuster hateinen Namen (Bezeichnung),so kann ein schon definier-tes Ereignismuster bei meh-reren Triggern benutzt wer-den.

Ereignismuster konnen biszu der Felderebene spezifi-ziert werden

Ereignismuster konnen nurbis zu der Tabellenebenespezifiziert werden

Im Aktionsteil eines Trig-gers, zwischen ,,BEGINATOMIC” und ,,END”konnen mehrere SQL-Ausdrucke eingesetzt wer-den. Das funktioniert wieeine Prozedur, in der auchz.B. Schleifen vorkommendurfen.

Im Aktionsteil eines Triggerskann nur ein einziger Befehlstehen. Dieser Befehl kannein Funktionsaufruf oder einSQL-Ausdruck sein.

Trigger-bearbeitung

Integritatanforderungenwerden bei der Triggerbear-beitung berucksichtigt

Integritatanforderungenwerden bei der Triggerbear-beitung nicht berucksichtigt.

Zeitereignisse werden nichtabgefangen.

Zeitereignisse, die durch ge-eignete Ereignismuster spe-zifiziert sind, werden abge-fangen und deren Triggerwerden bearbeitet.

Tabelle 5.1: Unterschiede zwischen der SQL3- und ARTA-Triggersprache


folgenden Grunden ausgewahlt. Jeder API-Timer lauft in einem eigenen Pro-zess im Betriebsystem parallel zu Access. Deswegen braucht ein API-Timer imVergleich zur Methode ,,Formularereignis” kein Access-Objekt. Ein API-Timerwird direkt vom Betriebsystem verwaltet. So braucht er keine großen Resour-cen, dagegen beschaftigt die Methode mit dem Befehl ,,DoEvents” standig denRechnerprozessor.

Ein Nachteil - oder besser formuliert: eine Eigenschaft - von API ist die ho-he Sensibilitat, die im Abschnitt 3.3 genauer beschrieben wurde. Das ist beson-ders bei API-Timern problematisch, weil diese Funktionen eine Ruckruffunktionbenotigen. Die Ruckruffunktionen durfen nicht lange warten mussen und soll-ten schnell bearbeitet werden. Es gibt Konfliktzustande, bei denen Access ohneVorwarnung absturzt: z.B. beim mehrmaligen Aufruf derselben Ruckruffunktiondurch mehrere Timer. Um dieses Problem zu losen wird vereinbart, dass gleich-zeitig nur ein einziger Timer eingesetzt werden darf. Konflikte kommen nachdieser Methode uberhaupt nicht zustande, weil eine Ausfuhrung der Ruckruf-funktion zu Ende gehen soll, bevor die Ruckruffunktion erneut aufgerufen wird.

Die sichere Ausfuhrung eines (SQL-)BefehlsWas passiert mit der Bearbeitung eines SQL-Befehls bzw. von Triggern (die

durch ein Ereignis gefeuert wurden) wenn Access vorher geschlossen wird? Eskann moglicherweise vorkommen, dass ein Benutzer versucht Access zu schlie-ßen, obwohl die Datenbankanderungen nicht vollstandig abgeschlossen sind.solche Datenbankanderungen werden erst dann einen Sinn machen, wenn al-le zusammengehorenden Trigger vollstandig bearbeitet werden. Bei folgendemBeispiel darf Access erst nach dem Schritt ,,n)” geschlossen werden.0)Anfang der Bearbeitung von SQL S1)S erzeugt das Ereignis E und E feuert {T1,T2,T3},2)T1.Aktion erzeugt das Ereignis E1 und E1 feuert {T11 ,T12 ,. . . },3)T2.Aktion erzeugt das Ereignis E2 und E2 feuert {T21 ,T22 ,. . . },. . .n)Ende der Bearbeitung von SQL S.

Zur Losung dieses Problems wird wieder ein Formularereignis benutzt. DieProzedur ,,Private Sub Form Unload(Cancel As Integer)” wird beim Schließendes Formulars (Formular-Ereignis: ,,Bei Entladen”) aufgerufen. Wenn die Va-riable ,,Cancel=True” ist, darf (kann) das Formular nicht geschlossen werden,und demzufolge kann Access auch nicht geschlossen werden. Bei Beginn einerTriggerbearbeitung wird in einem (unsichtbar) geoffneten Formular die Varia-ble ,,Cancel” auf ,,True” gesetzt. Nach der Beendigung der Triggerbearbeitung

5.2. SYNTAX VON ARTA-TRIGGERSPRACHE 47

wird wieder die Variable ,,Cancel” auf ,,False” zuruckgesetzt.

Private Sub Form_Unload(Cancel As Integer)

If Not Me.chk_EnableClose Then

Cancel = True

End If

End Sub

,,chk EnableClos” ist ein Kontrollkastchen, das im Formular eingebaut wurde.Mit der Inhaltsanderung dieses Kontrollkastchens wird indirekt der Variablen-inhalt ,,Cancel” wie folgt kontrolliert:

Forms("USys_frm_ControlSystemClose")!chk_EnableClose = False/True

Damit wird gewahrleistet, dass die Bearbeitung vollstandig durchgefuhrt werdenkann.

5.2 Syntax von ARTA-Triggersprache

Die Syntax eines triggers in ARTA-Triggersprache sieht bis auf ein paar Ein-schrankungen fast genauso aus wie die Syntax eins Triggers bei SQL3. EinTrigger wird unter ARTA nicht in Form eines Textes definiert. Er wird in ei-nem Formular definiert, in dem bestimmte Felder fur Eintrage vorgesehen sind.Bei der Syntax-Beschreibung von ARTA in BNF4-Form existieren deswegenAusdrucke, die bei einer Triggerdefinition nicht eingegeben werden. Diese Aus-drucke werden zum besseren Verstandnis der Grammatik benutzt. Die Syntaxeines Triggers in BNF-Form sieht wie folgt aus:

<trigger definition> ::=

CREATE TRIGGER

<trigger name> <trigger priority> <trigger activity>

<trigger event>

<trigger condition>

<trigger action>

<trigger condition> ::=

WHEN {<left paren> <search condition> <right paren>

|<function>}

<trigger action> ::= <SQL Statement> | <VBA function>

4Backus-Naur-Form: Vgl. [AutoHoUl]


<trigger event> ::=

<modify>

| <atOnce>

| <periodic>

<modify>::=

<event name> <trigger action time> <trigger DML>

ON <table name> [ REFERENCING <old new values alias list>]

FOR EACH {ROW | STATEMENT}

<trigger action time> ::=

BEFORE

| AFTER

<trigger DML> ::=

INSERT

| DELETE

| UPDATE

<old or new values alias list> ::=

<old or new values alias>...

<old new values alias> ::=

OLD ROW AS <old values correlation name>

| NEW ROW AS <new values correlation name>

| OLD TABLE AS <old values table alias>

| NEW TABLE AS <new values table alias>

<old values table alias> ::=<identifier>

<new values table alias> ::=<identifier>

<old values correlation name> ::= <correlation name>

<new values correlation name> ::= <correlation name>

<atOnce> ::=

<date> <time>

<deadLine>


<periodic> ::=

BEGIN

<date> <time> <deadLine>

EVERY

{<number> <period>

|<number> <period> + <number> <period>}

<number> ::= 1,2,3,...

<period> ::=

minutes

| hours

| days

| weeks

| months

| years

Dabei bedeuten die Parameter wie folgt:<trigger name>: Eindeutiger Name fur den Trigger.<trigger priority>: Eine eindeutige naturliche Zahl<trigger activity>: ja/nein-Eintrag.<left paren><search condition> <right paren>: An dieser Stelle konnen ja/nein-Abfragen an die Datenbank formuliert werden.<function>: Globale Funktionen, die entweder in VBA oder von Benutzern de-finiert wurden.<SQL Statement>: Ein SQL-Ausdruck.<event name>: Ein eindeutiger Name fur das Ereignismuster.<identifier>: Eindeutige Namen fur die Parameter.<correlation name>: Eindeutige Namen fur die Parameter.<date>: Das Datum des Tages, an dem ein Ereignis auftritt.<time>: Die Tageszeit.<deadLine>: Eine naturliche Zahl ≥ 5 Minuten.

Wie schon erwahnt, werden die Trigger in ARTA formularbasiert verwal-tet. Die Syntax von ARTA-Regeln muss in zwei voneinander abhangigen Teilenbeschreiben werden.

5.2.1 Syntax eines Triggers

Trigger werden in einem Formular definiert, in dem folgende Felder vorgesehensind:


• Ein eindeutiger Triggername:Ein Trigger wird in einer ARTA-Datenbank eindeutig bestimmt und defi-niert. Der Name darf 1 bis 64 Zeichen aus der Menge der ,,legalen Zeichen”,,{a,b,. . . ,z,A,B,. . . ,Z,0,1,. . . ,9, }” enthalten. Triggernamen sollten aussa-gefahig ausgewahlt werden, damit die Unterschiede zwischen Triggern ausihren Name ersichtlich werden.

• Eine eindeutige Trigger-Priority:Trigger-Priority ist eine Zahl aus der Menge der naturlichen Zahlen{1,2,3,4. . . }. Durch Trigger-Priority wird die eindeutige Reihenfolge derBearbeitung der betroffenen Trigger an den Konfliktstellen bestimmt.

• Ist aktiv:Die Aktivitat eines Triggers gibt an, ob dieser Trigger beim Auftreteneines Ereignisses berucksichtigt werden darf.

• Created und Modified Dates:Das Datum des Erzeugens und das Datum der letzten Anderung einesTriggers werden automatisch hier eingesetzt.

• Event: Das Ereignismuster beschreibt das Ereignis, dessen Eintritt die-ser Trigger feuert. Die Syntax von Ereignismusterdefinitionen wird weiterunten in 5.2.2 beschrieben.

• REFERENCING: An dieser Stelle ist die Definition von bis zu vier Pa-rametern moglich. Je nach Art des Ereignismusters konnen Parameter furNEW TABLE, OLD TABLE, NEW ROW, OLD ROW eingegeben wer-den. Bei den Zeitereignissen werden keine Parameter definiert.

Bei einem Anderungsereignis durfen je nach DML-Befehl folgende Pa-rameter definiert werden:

– Bei dem Befehl DELETE durfen OLD TABLE und OLD ROW de-finiert werden.

– Bei dem Befehl INSERT durfen NEW TABLE und NEW ROW de-finiert werden.

– Bei dem Befehl UPDATE durfen OLD TABLE, OLD ROW,NEW TABLE und NEW ROW definiert werden.

• Action-Time:Ob der Trigger vor oder nach der SQL-Ausfuhrung bearbeitet werden soll,


wird durch diesen Eintrag bestimmt. Action-Time ist bei einem Ande-rungsereignismuster entweder BEFORE oder AFTER. Standardeintragist ,,BEFORE”.

• FOR EACH ist bei einem Anderungsereignismuster entweder ROW oderSTATEMENT, wobei der Standardeintrag ,,STATEMENT” ist.

• Condition:Unter diesem Eintrag wird eine ja/nein Anfrage formuliert. Diese Anfragekann aus einem Funktionsaufruf oder einem logischen Vergleichsausdruckbestehen. Konstanten und Parameter, die mit dem Trigger definiert wur-den, konnen in Funktionen als Eingabeparameter und in logischen Aus-drucken als Variablen benutzt werden. In logischen Ausdrucken sind dieVergleichsoperatoren {<,<=, >, >=, =, <>} erlaubt.

• Action:Unter diesem Eintrag wird ein Befehl formuliert, der nach dem Feuern desTriggers ausgefuhrt wird, wenn die Triggerbedingung (Condition) erfulltist. Die vom Benutzer eingebauten globalen Funktionen, die Access Funk-tionen und SQL-Ausdrucke konnen hier eingegeben werden. Auch im Trig-geraktionsteil konnen Triggerparameter vorkommen.

5.2.2 Syntax eines Eventmusters

Ereignismuster mussen gesondert (aber gleichzeitig mit Triggern) definiertwerden. Ein vorher gleichzeitig mit einem Trigger definiertes Ereignismu-ster kann als Ereignisteil eines anderen Triggers benutzt werden. Ein Er-eignismuster darf nur dann geandert werden, wenn das Ereignismuster ent-weder als Eventteil eines einzigen Triggers benutzt worden ist, oder wenndas Ereignismuster falsch eingegeben wurde. Ein Ereignismuster wird ineinem Formular mit den folgenden Textfeldern definiert.

• Name ist eine eindeutige Bezeichnung des Ereignismusters.

• Created und Modified Date sind die Erzeugungs- bzw. Anderungsda-ten, die automatisch eingesetzt werden.

• Je dem Event-Typ mussen gezwungener Massen andere Eigenschaftenfur das Ereignismuster definiert werden:

– Bei modify event mussen der Datenbankmanipulationstyp, DML-Typ und der Tabellenname eingegeben werden.


Ein DML-Befehl kann vom Typ DELETE, INSERT oder UPDATEsein. Bei dem Feld, in das auf diesem Formular dieser DML-Befehleingegeben wird, ist nur einer der o.g. Befehle als Eingabe moglich.

Der Tabellenname darf nur von der Liste der vorhandenen Tabellenin der Datenbank gewahlt werden.

– Bei time event atOnce sind folgende Informationen relevant:date: der Tag, an dem das Zeitereignis erwartet wird.time: die Uhrzeit im unter date eingegebenen Tag.deadLine: Beim Eintreffen des Zeitereignisses darf der Trigger nur vordem Ablauf dieser Deadline gefeuert werden. Wenn ein Zeitereignisnach dem Ablauf der Deadline eintritt, werden seine Trigger ignoriert.Die Deadline wird in Minuten eingegeben und darf nicht kleiner als5 Minute sein. Wenn keine Zahl eingegeben wird, wird die Deadlineals unendlich(∞) angenommen.

– Bei time event periodic muss eingegeben werden, ab wann und inwelchen Zeitabstanden solche Zeitereignisse bemerkt werden. Nacheiner erfolgreichen Eingabe solcher Ereignismuster wird der nachsteTermin automatisch berechnet und als informativer Eintrag ange-zeigt. Die periodischen Zeitereignisse durfen nicht mehr geandertwerden, sobald sie richtig eingegeben und die nachsten Termine be-rechnet wurden. Die Eintrage sind Begin-date, Begin-time, deadLineund Periode. Die Periode ist die Summe von zwei Teilperioden. DieDeadline hat hier genau die gleiche Funktionalitat wie bei dem obengenannten time event atOnce Ereignismuster.

Ein Ereignismustertyp hat direkten Einfluss auf folgende Parameter vonTriggern.

• Die Auswahl eines Ereignismusters vom Typ modify event veranlasst,dass die folgende Felder sichtbar werden: Action-Time und FOR EACH,die oben bereits beschrieben wurden. Wenn der Ereignismustertyp ,,mo-dify event” gewahlt wird, so mussen der DML-Befehl und der Tabellen-Name eingegeben werden. Nach der Eingabe des DML-Befehls werdenFelder fur folgende Triggerparameter sichtbar.

– Ist der DML-Befehl DELETE, dann sind OLD TABLE undOLD ROW sichtbar.

– Ist der DML-Befehl INSERT, dann sind NEW TABLE undNEW ROW sichtbar.

5.3. SEMANTIK DER ARTA-TRIGGERBEARBEITUNG 53

– Ist der DML-Befehl UPDATE, dann sind alle ParameterNEW TABLE , NEW ROW , OLD TABLE und OLD ROW sicht-bar.

In sichtbare Felder konnen Eintrage eingegeben werden. Diese Felder mus-sen aber nicht ausgefullt werden, es sei denn der Benutzer hat vor, diese inanderen Triggerteilen (Triggercondition oder Triggeraction) zu benutzen.

• Bei Ereignismustern vom Typ atOnce oder periodic sind keine der o.g.Triggerparameter erlaubt und deswegen bleiben die entsprechenden Felderunsichtbar.

5.3 Semantik der ARTA-Triggerbearbeitung

S Nein

Benutzeroberfläche

Feuert S Trigger? S Ausführen

Bearbeitung von Beforetriggern

BvB

Bearbeitung von Aftertriggern

BvA

Feuert S Aftertrigger?

Ende der Bearbeitung

Verwaltung von Zeitereignissen

VvZE

7 5 6

12 11 10

8 4

2 1

9 3

Nein

Ja

S

Nein

Befehlsausführungssystem

BAS

Abbildung 5.2: Triggerbearbeitung in ARTA

Im Bild 5.2 wurde der Flussdiagramm der Triggerbearbeitung in ARTA ge-schildert. S ist ein (SQL-)Befehl, der entweder von einem Benutzer aus demARTA-Hauptfenster (Benutzeroberflache) eingegeben wird oder die Ausgabevon VvZE5 ist. Tritt ein Anderungsereingis wegen Ausfuhrung des Befehls S

5Verwaltung von Zeitereignissen wird in 5.4 beschrieben.


ein, wird die Menge von gefeuerten Beforetriggern berechnet, in der diese Befo-retrigger nach ihren Prioritaten sortiert werden. Nach dem Sortieren werden dieBeforetrigger in einer Schleife bearbeitet. Nach der Bearbeitung von Beforetrig-ger soll der Befehl S ausgefuhrt werden. Als nachstes wird die Mange von Aftert-riggern bestimmt, die an dieser Stelle nach ihren Prioritaten sortiert werden. Ineiner Schleife werden Aftertrigger bearbeitet, indem Aktionsteile von Aftertrig-gern als neuer S-Befehl in BAS eingegeben werden und BAS(Aftertrigger.action)ausgefuhrt wird.

Fur die Bearbeitung von Before- und Aftertriggern sollen zuerst die vor-definierten Parameterinhalte berechnet werden, weil vor Bedingungsuswertungsowie vor der Ausfuhrung von BAS(Aftertrigger.action) diese Parameter in Trig-gerbedingungsteil und Triggeraktionsteil durch ihre Inhalte ersetzt werden sol-len. Die Parameter werden zu jedem Befehl berechnet und fur die Bearbeitungvon Before- und Aftertriggern eingesetzt. Die Bearbeitung von einem Befehlwird vollstandig in BAS durchgefuhrt, indem auch die internen Variablen be-schrieben werden.

Eintritt von AnderungsereignissenDer SQL-Ausdruck ,,S” wird als Eingabe ins Befehlsausfuhrungssystem (BAS)

hinzugefugt. In BAS wird zuerst getestet, ob durch Ausfuhrung von S ein defi-niertes Ereignis eintritt und dieses Ereignis Trigger feuert. Ist das nicht der Fall,so wird S ausgefuhrt, ohne ein Triggerbearbeitung durchzufuhren. Feuert dieAusfuhrung von S Trigger (Tritt ein Anderungsereignis ein), werden die gefeu-erten Trigger bearbeitet. Die Semantik der Triggerbearbeitung im ARTA ist bisauf einige Unterschiede auf die im SQL3 vorgestellte Semantik aufgebaut. Imfolgenden wird die Prozedur ,,Befehlsausfuhrungssystem (BAS)” beschrieben,die Ausfuhrung eines SQL-Befehls beobachtet und gefeuerte Trigger bearbeitet:

Anfang von BAS(S)Nach der Eingabe des SQL-Befehls wird ein so genannter Trigger ExecutionContext (TEC) erzeugt, der besteht aus

• einer Menge von Transitionen TRN,

• dem Namen der betroffenen Tabelle,

• dem Typ des Ereignisses (DELETE | INSERT | UPDATE).

Die Menge der Transitionen besteht aus zwei Transitionstabellen. Die Tran-sitionstabellen beinhalten Datensatze, die durch Korrelationen zwischen zwei


Zustanden der Originaltabelle vor der SQL-Ausfuhrung und nach der SQL-Ausfuhrung enstehen konnen. Die betroffenen Datensatze werden in zwei tem-poraren Tabellen gespeichert. Die Ausfuhrung eines SQL-Ausdrucks und die Be-arbeitung der von ihm betroffenen Trigger werden in einer Transaktion durch-gefuhrt. Die temporaren Tabellen sollen bis Ende der aktuellen Transaktionexistieren. Weil die temporaren Tabellen nur wahrend der aktuellen Transitionbenotigt werden, sollen sie dann nach der Beendigung der Transaktion geloschtwerden.

Die alten Datensatze werden in der ,,OLD Transitionstabelle” und die neuenDatensatze in der ,,NEW Transitionstabelle” zwischengespeichert. Die Tran-sitionstabellen konnen Daten enthalten, wenn uberhaupt Datensatze von derOriginaltabelle betroffen sind. Dabei ist nicht unwahrscheinlich, dass Anwen-dung eines SQL-Befehls Datenbank nicht andert. Das WHERE-Teil eines SQL-Ausdrucks kann so formuliert werden, dass durch den SQL-Ausdruck keine Da-tensatze ausgewahlt werden. Auch der Zustand von Tabellen spielt eine großeRolle, ob Datensatze betroffen werden, wie z.B. aus einer leeren Tabelle konnenkeine Datensatze ausgewahlt werden. Je nach DML-Befehl konnen beide odernur eine der Transitionstabellen Daten beinhalten:

• Bei DELETE kann nur die OLD Transitionstabelle Daten enthalten.

• Bei INSERT kann nur die NEW Transitionstabelle Daten enthalten.

• Bei UPDATE konnen beide OLD Transitionstabelle undNEW Transitionstabelle Daten enthalten.

Nachdem TEC berechnet und bereitgestellt wurde, soll die Menge BTrsbestimmt werden. BTrs besteht aus Beforetriggern, die durch das Ereignis(Ausfuhrung von S) gefeuert werden. Falls die Menge der Transitionen leer ist,werden alle ROW-Level-Beforetrigger aus der Menge BTrs entfernt, weil ROW-Level-Trigger nur fur jede betroffene Zeile gefeuert werden durfen. Betrifft derSQL-Ausdruck keine Zeile der Tabelle, so wird kein ROW-Level-Trigger bear-beitet.

An dieser Stelle werden die Beforetrigger nach ihren Erzeugungsdatum sor-tiert. Alle (bzw. ubrige) Beforetrigger werden in einer Schleife abgearbeitet.Dabei werden die Statement-Level-Trigger nur einmal und ROW-Level-Triggerfur jede betroffene Zeile einmal wie folgt bearbeitet. Fur jeden Trigger T inBTrs:

• T ist ein STATEMENT-Level Trigger:


1. Die Inhalte von Triggerparametern sollen aus den Transitionstabellenberechnet werden.

2. Nach dem Ersetzen die Parameter durch deren Inhalte in den Trigger-bedingungs- bzw. in den Triggeraktionsteil von T, wird die Bedin-gungsauswertung durchgefuhrt.

3. Ist das Ergebnis der Bedingungsauswertung = True, dann wird Trig-geraktion ausgefuhrt, ohne weitere Trigger zu feuern.

• T ist ein ROW-Level Trigger:Hier soll fur jede betroffene Zeile:

1. Die Parameterinhalte werden aus den Transitionen berechnet.

2. Die Parameter werden durch ihre Inhalte in Bedingungsteil und Ak-tionsteil von T ersetzt und die Bedingungsauswertung wird durch-gefuhrt.

3. Gibt Bedingungsauswertung ,,True” zuruck, wird Triggeraktion aus-gefuhrt (wieder ohne Trigger zu feuern).

Alle Beforetrigger wurden bis hierhin abgearbeitet. An dieser Stelle wird derSQL-Ausdruck S ausgefuhrt. Nach der S-Ausfuhrung wird die Menge ATrs be-stimmt, die aus Aftertriggern besteht, die das Ereignis ,,S-Ausfuhrung” feuert.Ist TRN (die Menge der Transitionen) leer, werden alle ROW-Level-Triggeraus der Menge ATrs entfernt. Fur jeden Trigger T in ATrs gilt:

• T ist ein STATEMENT-Level Trigger:

1. Die Parameterinhalte sollen aus der Transitionstabellen berechnetwerden.

2. Nach dem Ersetzen die Parameter durch ihre Inhalte in Conditi-on und Actionateil von T, wird die Bedingungsauswertung durch-gefuhrt.

3. Ist das Ergebnis der Bedingungsauswertung = True, soll Triggerak-tion als eine neue Eingabe S in das Befehlsausfuhrungssystem ein-gegeben werden und BAS(S:=Triggeraction) ausgefuhrt werden(Rekursion).

• T ist ein ROW-Level Trigger:Fur jede betroffene Zeile:

1. Die Parameterinhalte werden aus den Transitionen berechnet.


2. Die Parameter werden durch ihre Inhalte in Bedingungsteil und Ak-tionsteil von T ersetzt und die Bedingungsauswertung wird durch-gefuhrt.

3. Gibt Bedingungsauswertung ,,True” zuruck, soll Triggeraktion alseine neue Eingabe S in das Befehlsausfuhrungssystem eingegebenwerden, d.h. BAS(S:=Triggeraction) (Rekursion.

Wie es aus der Semantikbeschreibung ersichtlich ist, wird die Bearbeitung vonTriggern durch Einsatz der Rekursion erledigt. Durch den rekursiven Aufruf derProzedur werden voneinander unabhangigen Instanzen von dieser Prozedur er-zeugt. Jeder Prozeduraufruf deklariert seine eigenen Variablen (vor allem TEC)und lauft erst dann zu Ende, nachdem alle durch sie aufgerufene Instanzen zuEnde durchgefuhrt sind.

... E i1 E ij E i 2

. . . . . .

... E 1 E n E 2

E

... E 11 E 1 m E 1 2

Ereignis

Bearbeitung von Beforetriggern

SQL-Ausführung

Bearbeitung von Aftertriggern

Abbildung 5.3: Instanzorientierte Triggerbearbeitungssemantik

Instanzorientierte RegelbearbeitungDurch Rekursion wird die Triggerbearbeitungssemantik in ARTA instanz-

orientiert. Mit der instanzorienterten Semantik wird die Triggerbearbeitung in


Tiefe durchgefuhrt, durch die die Bearbeitung von Triggern insoweit in die Tiefeweitergeleitet wird, bis keine Aftertrigger mehr gefeuert werden. Danach wirddie Bearbeitung in einer Stufe hoher weiter durchgefuhrt. Im Bild 5.3 wurde dieInstanzorientierung der Triggerbearbeitung von ARTA geschildert.

5.4 Verwaltung von Zeitereignissen

Zeitereignisse sind in ARTA in zwei Untertypen aufgeteilt: absolute und peri-odische Zeitereignisse. Absolute Zeitereignisse treten nur einmal an einem be-stimmten Zeitpunkt auf. Periodische Zeitereignisse treten wiederholt in gleichenZeitabstanden auf. Ein periodisches Zeitereignismuster wird nach jedem Eintre-ten seines Zeitereignisses modifiziert, indem fur das Zeitereignismuster ein neu-er Termin berechnet wird. Dieser neue Termin wird zum ersten Mal nach dererfolgreichen Ereignismusterdefinition berechnet. Der neue Termin, d.h. wanndas periodische Zeitereignis nochmal eintritt, ergibt sich sich aus der Additi-on des Anfangstermins bzw. des aktuellen Termins mit der Periode. Wie schonin diesem Kapitel erwahnt wurde, wird in ARTA immer nur maximal ein Ti-mer gesetzt. Im Bild 5.4 wird die Arbeitsweise der Zeitereignisbearbeitung und

Nein

Ja / t

ZE

Nein

Inerres Zeitereignis

Ja / ZE

System anschalten (Datenbank öffnen)

Wurde ein Zeit-Ereignis ( ZE ) in der Vergangenheit geschehen

und darf noch Trigger feuern(deadLine)?

Warten bis alle durch ZE gefeuerten Trigger bis zum Ende abgearbeitet sind.

7 5 6

12 11 10

8 4

2 1

9 3

Timer setzen zum t

ZE an Zeitereignisbearbeitungssytem schicken.

7 5 6

12 11 10

8 4

2 1

9 3

Timer setzen für einen Tag

Ist ein Ereignis in weniger als einer Woche zum

Zeitpunkt t zu erwarten?

Abbildung 5.4: Flußdiagram zu der Zeitereignisbearbeitung

Timerverwaltung geschildert. Immer beim Einschalten des System sowie nacheiner durch ein Zeitereignis veranlasste Datenbankanderung wird nach den in

5.4. VERWALTUNG VON ZEITEREIGNISSEN 59

Vergangenheit aufgetretenen Zeitereignissen gesucht. Solche (alten) Zeitereig-nisse werden bearbeitet, falls deren Deadlines noch nicht um sind. Wenn keineZeitereignisse aus der Vergangenheit zu bearbeiten sind, wird ein Timer wiefolgt gesetzt:

Der Timer wird zu den nachsten Zeitpunkt gesetzt, wenn ein Zeitereignisinnerhalb einer Woche in der Zukunft erwartet wird. Tritt aber kein Zeitereignisin einer Woche ein bzw. liegen alle erwarteten Zeitereignisse an Daten ubereiner Woche in der Zukunft hinaus, so wird ein Timer fur einen Tag gesetzt.Ablauf jedes Timers wird als das Eintreten eines Zeitereignisses interpretiert.Wurde sein Timer fur ein bestimmtes Datum eingesetzt, das innerhalb einerWoche eintreten sollte, so werden Trigger gefeuert und bearbeitet. Bei Eintreteneines inneren Zeitereignisses, d.h. beim Ablauf des fur einen Tag eingesetztenTimers, wird wieder nach einem erwarteten Zeitereignis innerhalb einer Wochegesucht. wird eins gefunden, so wird ein Timer fur das Datum dieses Ereignissesgesetzt, sonst wird wieder ein Timer fur einen weiteren Tag gesetzt.

deadLine:Zu jedem Zeitereignismuster gibt es eine Deadline , deren Einheit Minute

ist. Das Bild 5.5 zeigt eine Deadline auf der Zeitachse bezuglich eines Zeitpunkte

Zeit/Min

t1

dead

Line

Abbildung 5.5: Allgemeine Deadline-Darstellung

,,t1”. Am Zeitpunkt t1 wird das Zeitereignis E erwartet. Zeitpunkt des Bearbei-tungsanfangs der durch E gefeuerten Trigger darf nur innerhalb des Zeitinter-valls [t1, t1+Deadline] liegen. Der Zweck der Deadline ist, dass beim Ausfuhrenvorher geforderten Datenanderungen eine gewisse Zeit gebraucht wird. DieseBearbeitungszeitadauer spielt bei manchen Regeln eine große Rolle (Echtzeit-Problem). Es kann vorkommen, dass Bearbeitung eines Triggers innerhalb 10Minuten nach dem Eintreten eines Zeitereignisses beginnen soll und nach dem


Ablauf dieser 10-Minuten darf der Trigger nicht mehr bearbeitet werden. Die 5minutige Mindestgrenze ist zur Sicherheit vorgesehen. Vorsichtshalber soll derTrigger-Entwickler großere Deadlines einplanen.

Die Deadline ist beschrankt auf dem Interval [5 Minute , ∞).

Deadline wird auch noch fur die Erledigung einer weiteren wichtigen Aufga-be eingesetzt. Eine ARTA-Datenbank wird normalerweise nicht ununterbrocheneingesetzt. Der Einsatz des Systems kann abgebrochen und in einem in unbe-kannter Zukunft liegenden Zeitpunkt wieder in Anspruch genommen werden,z.B. eine Datenbank fur die Verwaltung der Informationen uber die eingeschrie-benen Informatik-Studenten an der Universitat Bonn. Diese Datenbank wirdnur an Werktagen und zwar nur wahrend der Arbeitszeiten eingesetzt außer-halb dieser Zeiten ist diese Datenbank abgeschaltet. Im Bild 5.6 wurde Einsatzund der Ruhezustand einer Datenbank im Zusammenhang mit den Zeitereig-nissen auf einer Zeitachse geschildert.

Zeit

t1 t2 t3 tn t4

. . .

Pau

se

Ein

satz

Pau

se

Ein

satz

Abbildung 5.6: Systemeinsatz und Ereignisse

Die Zeitereignissen, die in dem Ruhezustand des System Trigger hatten feu-ern mussen, werden wie folgt behandelt: Die Ereignisse, deren Deadline nochnicht vorbei ist, werden berucksichtigt und der Rest wird ignoriert. Ein Trigger,dessen Ereignismuter ein Zeitereignismuster mit einer Deadline ist, ahnelt derRegel R2, die als Beispiel im Abschnitt 2.1 gegeben wurde.

Triggerbearbeitung nach Eintreten eines Zeitereignisses:Die Trigger, die durch Eintritt von Zeitereignissen gefeuert werden, besitzen

5.4. VERWALTUNG VON ZEITEREIGNISSEN 61

keine Parameter. Deswegen hangt das Ergebnis der Triggerbedingungsauswer-tung von dem aktuellen Datenbankzustand und von der aktuellen Zeit ab. InBedingungen solcher Trigger konnen z.B. Zeitstempel bestimmter Datensatzebenutzt werden. Durch Vergleichen von Zeitstempeln mit der aktuellen Zeit inder Bedingungsteil eines Triggers konnen bestimmte Situationen abgefragt wer-den. Ist ZTrs die Menge von Triggern, die ein Zeitereignis gefeuert hat, werdendiese Trigger wie folgt bearbeitet:

• Konfliktsituation: Wurden mehrere (mehr als ein) Trigger gefeuret, werdensie nach ihren Prioritaten sortiert. (#ZTrs > 1)

• Fur jeden Trigger T von ZTrsBedingung von T auswerten. Ist die Auswertung = ,,True”, setze Aktionvon T als eine Eingabe fur den Aufruf von BAS6 ein: BAS(T.action).

6Vgl. 5.3

Kapitel 6

Implementierung

Im folgenden Kapitel wird die Implementierung von ARTA beschrieben. Dazuwurde die Programmiersprache VBA benutzt. Bei der Realisierung von Benut-zeroberflachen wurden Formulare und deren Ereignisse eingesetzt.

Triggerdaten und Ereignisdaten werden im Laufe des Programms in inter-nen Variablen in Form von Objekten bereitgestellt. Dafur wurden verschiedeneKlassenmodule programmiert, die entweder als einzelne Objekte oder als Aufli-stungen eingesetzt wurden.

Zunachst werden die Architektur und die Komponenten von ARTA vor-gestellt. Danach wird jede Komponente detailliert beschrieben. Anschließendwerden besondere Aspekte erlautert, die in manchen Stellen zur Losung vonImplementierungsproblemen benutzt wurden.

6.1 Architektur von ARTA

Bei der Architekturplanung wurde auf folgende Punkte geachtet:

• Datenbankanderungen durfen nicht direkt mit Hilfe von Access Standard-komponenten vorgenommen werden, weil die Ereignisse dabei nicht be-merkt werden konnen. Fur die Kommunikation mit ARTA wurde eine spe-zielle Oberflache vorgesehen, die durch den Einsatz eines Formulars reali-siert ist. Diese Oberflache (bzw. Fenster) nennt sich ARTA-Haupfenster.

• Die Existenz eines Werkzeuges, mit dessen Hilfe Trigger bzw. Ereignis-muster definiert werden, ist unverzichtbar. Mit diesem Werkzeug sollteauch die Anderung von Triggern und Ereignismustern moglich sein. InARTA werden Trigger bzw. Ereignismuster formularbasiert verwaltet, d.h.Formulare wurden als Oberflachen so programmiert, dass alle Teile vonTriggern bzw. Ereignismustern eingegeben und geandert werden konnen.

63

64 KAPITEL 6. IMPLEMENTIERUNG

Regelbasis

Jet DB Engine

Standard-Komponente von MS-Access

Timerverwaltungssystem

7 5 6

12 11 10

8 4

2 1

9 3

TVS

Benutzeroberflächen

Trigger und Eventmuster

Definitionsformular

ARTA

BAS Befehlsausführungssytem

MS-Access

SQL Eingabeformular

Datenbank

Abbildung 6.1: ARTA und Access

6.2. BENUTZEROBERFLACHE 65

• Die Triggerdaten sowie Ereignismusterdaten sollen gesichert werden, es istfolglich eine Regelbasis notwendig. Die Regelbasis wird in ARTA in AccessTabellen gespeichert.

• Zur Verwaltung von Zeitereignissen ist eine Uhr bzw. ein darauf aufge-bauter Timer notwendig.

• Ein internes System, um Ereignisse zu registrieren und gefeuerte Triggerzu bearbeiten, ist eine Basis fur die Triggerfunktionalitat eines aktivenDatenbankmanagementsystems. Ein solches System ist der Kern jedes ak-tiven Datenbankmanagementsystems und damit auch von ARTA .

ARTA besteht aus Komponenten, die im Bild 6.1 dargestellt sind. Fur die Rea-lisierung von ARTA wurden Access Objekte (Komponenten) benutzt, die inARTA als Systemkomponenten gekennzeichnet sind. Die Namen dieser Objek-te fangen daher alle mit der Vorsilbe ,,USys ” an. Zusatzlich ist deren Eigen-schaft ,,ausgeblendet” aktiviert. ARTA-Objekte konnen dadurch unsichtbar und,,nicht mehr direkt modifizierbar” werden.1 ARTA-Komponenten werden in denfolgenden Abschnitten detailliert beschrieben.

6.2 Benutzeroberflache

Die Implementierung von Benutzeroberflachen wurde mit Hilfe von Access-Formularen und deren Eigenschaften realisiert. Zur Realisierung von Ober-flachen wurden Formularereignisse eingesetzt, die besonders geeignet sind, Ein-gaben zu uberprufen. Mit Hilfe von Formularereignissen wird z.B. die Syntaxeiner Triggerdefinition uberpruft. Bei einem Syntaxfehler wird eine entsprechen-de Fehlermeldung ausgegeben. Mit dem Offnen einer ARTA-Datenbank wirddirekt ein Formular geoffnet, das im Bild 6.3 gezeigt wird. Dieses Formularheißt ARTA-Hauptfenster. Im ARTA-Hauptfenster sind Buttons (Befehlsschalt-flachen) vorgesehen, die dem Benutzer helfen andere Fenster zu offnen oder denSQL-Befehl auszufuhren. Mit Hilfe des ARTA-Hauptfensters und die daraufeingebauten Buttons und Tools werden die folgenden Anforderungen erfullt:

• Durch ,,SQL ausfuhren” wird ein SQL-Befehl, der in einen dafur vorge-sehenen Textfeld eingegeben wurde, an das Befehlausfuhrungssystem ge-sendet. Wird jede Datenbank-Anderung durch dieses Formular ausgefuhrt,so wird das auftretende Ereignis erkannt und die gefeuerten Trigger be-arbeitet. Eine Tabelle ist in ARTA dafur vorgesehen, in der SQL-Befehle(und gegebenenfalls deren Bemerkungen) gespeichert werden. Ein neuer

1Vgl. Abschnitt 4.4


Abbildung 6.2: ARTA-Hauptfenster

Datensatz im ARTA-Hauptfenster bedeutet einen Eintrag in dieser Tabel-le. Das Speichern von SQL-Befehlen macht nur Sinn, wenn diese Befehlewiederholend angewendet werden. Das kommt besonders beim Testen vonARTA in Einsatz.

• Durch ,,SQL loschen” wird der SQL-Befehl und die dazu gehorige Bemer-kung geloscht.

• Durch Mausklick auf dem Button ,,Events” wird ein Fenster geoffnet, indem Ereignismuster angezeigt werden. Loschbare Ereignismuster durfen indiesem Fenster geloscht werden. Loschbar sind diejenigen Ereignismuster,die mit keinem Trigger verknupft sind.

• Durch ,,Trigger bearbeiten” wird ein Fenster zur Triggerverwaltung geoff-net.

• Durch ,,Show Messages” sieht man die wichtigsten Informationen uberden Triggerbearbeitungsvorgang in einem Fenster.

• Durch ,,Show Logfile” wird ein ausfuhrliches Protokoll vom Einsatz desARTA-Systems angezeigt.

Das Fenster, das durch Mausklick auf ,,Trigger bearbeiten” aufgeht, ist ei-ne in ARTA eingebaute Moglichkeit, Trigger und zugehorige Ereignismuster zuverwalten. Im Bild 6.3 sind zwei Versionen eines Access-Hauptfensters vorge-stellt. Eine zeigt das originale Access-Hauptfenster, das z.Z. in Access vorliegt.


In diesem Access-Hauptfenster sind Moglichkeiten angeboten, neue Access Ob-jekte und Komponente von bestimmter Art zu definieren und zu verwalten. Dieandere Darstellung ist eine Wunschsform. Das Access-Hauptfenster konnte soaussehen, wenn Trigger als eine Access-Komponente unterstutzt waren. Weilin Access keine Moglichkeit existiert, Trigger und Ereignismuster zu verwalten,wird die Trigger- und Ereignismusterverwaltung formularbasiert durchgefuhrt.

Formulare werden als Benutzeroberflachen (Fenster bzw. Windows) pro-grammiert. In ARTA-Fenstern konnen Trigger und Ereignismuster definiert,angezeigt, geloscht oder modifiziert werden konnen.

Die gewünschte Änderung

Trigger

Abbildung 6.3: Hauptfenster von Access

6.2.1 Verwaltung von Triggern

Das Formular zur Verwaltung von Triggern wird ARTA-Triggerfenster genannt.In Access gibt es die Moglichkeit auszuwahlen, in welchem Status (Modus) einFormular aufgemacht wird. Die Eigenschaften eines Formulars bestimmen, obein neuer Datensatz eingegeben, der aktuelle Datensatz geloscht oder geandertwerden darf. Diese Eigenschaften konnen auch mit Hilfe von VBA-Befehlenim Formular-Klassenmodul eingestellt werden. Im folgenden Beispiel wird beimOffnen eines Formulars eingestellt, dass die Fensterbeschriftung zu ,,Triggeranschauen!” geandert wird und keine Daten eingegeben, geloscht sowie geandertwerden durfen.


Private Sub Form_Open(Cancel As Integer)

Me.Caption = "Trigger anschauen!"

Me.AllowAdditions = False

Me.AllowDeletions = False

Me.AllowEdits = False

End Sub

Beim Offnen des Triggerfensters sind die Eigenschaften so eingestellt, dasskeine neuen Trigger eingegeben werden durfen, und der aktuelle Trigger nicht zuandern ist (Modus ,,Trigger anschauen”). Das Triggerfenster wurde im Bild 6.4in diesem Modus (,,Trigger anschauen”) gezeigt. Mit dem aktuellen Trigger istder Trigger gemeint, der im Fenster zu sehen ist. Nach einem Mausklick auf denentsprechenden Button im Triggerfenster werden Einstellungen des Formularsso geandert, dass ein neuer Trigger eingegeben bzw. der aktuelle Trigger geloschtoder geandert werden kann. Mausklicks auf Buttons haben dieselben Funtiona-litaten wie die entsprechenden Befehle, die in SQL3 benutzt werden, z.B. CreateTrigger, Delete Trigger, Modify Trigger. Ob ein Trigger aktiv oder nicht aktivist, wird durch Markierung des hierzu vorgesehenen Feldes eingestellt. Aktivsind diejenigen Trigger, die beim Auftritt eines Ereignisses berucksichtigt wer-den. Nicht aktive Trigger (passive Trigger) werden ignoriert und sind nur interngespeichert. Trigger, die fehlerhaft sind, werden als passiv gespeichert, wodurcheine korrekte Triggerbearbeitung garantiert wird.

Bei Textfeldern mit langen Texten kann der Text mittels speziell dafur vor-gesehenen Buttons oder Maus-Doppelklick in einem großeren Fenster angesehenund bearbeitet werden. Dies ist sehr wichtig bei Triggerbedingung und Trigge-raktion, die im Triggerfenster nur begrenzten Platz haben und manchmal (beilangen Texten) nicht vollstandig angezeigt werden. Diese Technik, lange Tex-te in einem separaten Fenster zu bearbeiten, ist in jedem Fenster von ARTAvorgesehen, bei dem Textfelder fur lange Texte existieren.

6.2.2 Verwaltung von Ereignismustern

Ereignismuster werden gleichzeitig mit Triggern erzeugt und modifiziert. DasLoschen eines Ereignismusters wird in einem separaten Fenster durchgefuhrt,das durch Maus-Klick auf dem entsprechende Button im ARTA-Hauptfenster(Events) geoffnet wird. Das Bild 6.5 zeigt dieses Fenster, in dem die Ereignis-muster angeschaut und geloscht werden konnen. Das Fenster heißt das ARTA-


Abbildung 6.4: Das Trigger-Fenster im Modus ,,Trigger anschauen”


Ereignismusterfenster. Im Ereignismusterfenster konnen vorhandene Ereignis-

Abbildung 6.5: ARTA-Ereignis-Muster-Fenster

muster nur angeschaut und geloscht werden. Dieses Fenster hat nur diese Funk-tionalitat und sonst keine.

Beim Loschen eines Triggers wird das Ereignismuster dieses Trig-gers ,,nicht mitgeloscht”.

Das Loschen eines Triggers wird im Triggerfenster durchgefuhrt und dasLoschen eines Ereignismusters muss extra im Ereignismusterfenster durchgefuhrtwerden. Das mag vielleicht ein bisschen lastig erscheinen, macht aber Sinn, wennman beachtet, dass ein Ereignismuster mit mehreren Triggern verknupft seindarf. Ein Ereignismuster darf nur dann geloscht werden, wenn mit ihm keinTrigger mehr verknupft ist. Im Ereignismusterfenster wird beim Anzeigen je-des Ereignismusters seine Loschbarkeit automatisch gepruft und (informativ)angezeigt. Im Ereignismusterfenster sind bestimmte Buttons eingebracht wor-den, mit deren Hilfe das aktuelle Ereignismuster (wenn es loschbar ist) bzw. alleloschbaren Ereignismuster geloscht werden konnen.

6.3 Speichern von Regeln

Die Menge aller Trigger heißt Regelbasis, deren Daten gesichert werden mussen.Dafur sind zwei Tabellen in ARTA vorgesehen: In der Tabelle ,,USys trigger”werden Daten von Triggern gespeichert, in der Anderen ,,USys event” werdenDaten von Ereignismustern gespeichert. Weil die Name dieser Tabellen mit

6.3. SPEICHERN VON REGELN 71

,,USys” anfangen, werden diese Tabellen als Access Systemkomponente inter-pretiert und konnen unsichtbar werden2. Diese Tabellen sind miteinander durcheine Access-Beziehung verknupft. Die Eigenschaften dieser Beziehung sind soeingestellt worden, dass ein Ereignismuster mit mehreren Triggern verbundenwerden darf.

Abbildung 6.6: Beziehung zwischen der Tabelle von Triggern mit der Tabellevon Ereignismutern

USys triggerDer Primarschlussel besteht in dieser Tabelle aus zwei Felder: ,,trigger id”

und ,,trigger name”, wobei ersteres ,,trigger id” nur als eine interne Indentifi-katiosnummer einzusehen ist. Dagegen sorgt ,,trigger name” dafur, dass keinezwei Trigger mit dem gleichen Namen versehen werden. Damit wird die Eindeu-tigkeit von Triggernamen gewahrleistet. Die Prioritat eines Triggers wird unterdem Feld ,,trigger priority gespeichert. Damit eine sichere Prioritat garantiertwird, wurde das Feld so eingestellt, dass

1. sein Inhalt nur eine naturliche Zahl großer als ,,0” sein darf,

2. keine zwei Datensatze mit gleichem Inhalt erlaubt sind,

2s. Unterabschnitt: 4.4


3. und das Feld nicht leer sein darf.

Das Feld ,,trigger event name” ist in dieser Tabelle ein Fremdschlussel, des-sen Inhalt nur ein Element aus der Menge der vorhandenen Ereignismuster-namen sein darf. Doppelte Daten durfen bei diesem Feld vorkommen, damitmehrere Trigger mit einem Ereignismuster verbunden werden konnen. WeitereFelder in dieser Tabelle beinhalten Teilinformationen eines Triggers. z.B. Bedin-gung, Aktion, Aktivitat, . . . .

USys eventMit ,,event name” werden Ereignismuster in dieser Tabelle eindeutig bestimmt.

Der Primarschlussel besteht auch in dieser Tabelle aus zwei Feldern: ,,event id”und ,,event name”. Alle drei Ereignismustertypen werden in dieser Tabelle zu-sammen gespeichert. Der Typ eines Ereignismusters wird durch den Inhalt desFeldes ,,event type” gegeben. In diesem Feld ist dementsprechend nur ein Ein-trag aus {time event atOnce, time event periodic und modify event} moglich.Nachdem der Ereignismustertyp bestimmt worden ist, werden die fur diesenTyp relevante Daten berucksichtigt.

6.4 Klassen, Module und Objekte von ARTA

In ARTA wurden Module und Klassenmodule programmiert, um die Informa-tionen von Triggern und Ereignismustern fur die Erledigung von weiteren Auf-gaben bereitzustellen. Diese Aufgaben sind Ereigniserkennung, die Bearbeitungvon Triggern eines aufgetretenen Ereignisses, die Berechnung des nachsten Ter-mins fur den Timer und das Setzen des Timers.

6.4.1 Klassenmodule

In ARTA wurden folgende Klassenmodule programmiert:

USys clsTrigger:Unter einem Objekt dieser Klasse werden Daten eines Triggers gespeichert.

USys clsTriggers:Ein Objekt dieser Klasse ist eine Auflistung von Triggern. Ein neuer Triggerwird an der richtigen Stelle der Auflistung so hinzugefugt, dass Trigger auto-matisch nach Prioritaten sortiert sind. So hat das erste Element eines Objektsdieser Klassen immer die hochste Prioritat (niedrigste Prioritatszahl).

6.4. KLASSEN, MODULE UND OBJEKTE VON ARTA 73

USys clsModifyEvent:Ein Objekt dieser Klasse beinhaltet alle Trigger (ein Objekt der Klasse,,USys clsTriggers”), die beim Auftritt eines bestimmten Anderungsereignissesgefeuert werden. Das Ereignis wird durch eine interne Variable dieser Klasse,,mstr eventKey” identifiziert, die aus DML-Befehl und Tabellenname (<DML><table name>) besteht. Dieser Schlussel wird erst in einer Auflistung von derKlasse USys clsModifyEvents benutzt.

USys clsModifyEvents:Ein Objekt dieser Klasse ist eine Auflistung, deren Elemente Objekte der Klas-se ,,USys clsModifyEvent” sind. In der Auflistung sind die Ereignismuster unddie mit ihnen verbundenen Trigger so eingefugt, dass alle Trigger mit gleichem,,mstr eventKey” ((<DML><table name>)) unter einem Element zusammen-gefasst sind. Mit dem Aufruf der folgenden Prozeduren dieser Klasse werdenalle Trigger (bzw. alle Beforetrigger und Aftertrigger) zuruck gegeben, die beimAuftritt eines Anderungsereignisses ,,strDMLCommon” auf die Tabelle ,,strTa-blename” gefeuert werden mussen:

Public Function getTriggers( _

ByVal strDMLCommon As String, _

ByVal strTablename As String) As USys_clsTriggers

Public Function getBeforeTriggers( _



Public Function getAfterTriggers( _



USys clsTimeEvent:Ein Objekt dieser Klasse beinhaltet Informationen uber ein Zeitereignismuster.Der Typ des Zeitereignisses wird in die interne Variable ,,mstr event type” ein-gesetzt, und je nach Zeitereignistyp werden spezielle Informationen in andereVariablen eingesetzt.

USys clsTimeEvents:Aus dieser Klasse werden Objekte instantiiert, die als Auflistung von Zeitereig-nisobjekten benutzt werden. Jedes Element einer solchen Auflistung besteht ausInformationen uber ein Zeitereignismuster und den Triggern, die beim Auftre-ten dieses Zeitereignisses gefeuert werden mussen. Wie erwahnt konnen mehrere


Trigger ein gemeinsames Ereignismuster besitzen.

USys clsSetOfTimeEvents:Ein Objekt dieser Klasse ist eine Auflistung von Objekten der KlasseUSys clsTimeEvents. Jedes Objekt der Klasse USys clsSetOfTimeEvents be-steht aus Triggern, die an einem bestimmten Zeitpunkt gefeuert werden mussen.Diese Trigger konnen verschiedenen Ereignismuster angehoren, die aber alleein gemeinsames (,,absolutes”) Zeitereignis beschreiben. Mit Hilfe dieser Klassewerden die zwei verschiedenen Zeitereignistypen ,,periodisch und absolut” untereinem Objekt bereitgestellt. Die Prozedur ,,ChangeStatus()” ist in der KlasseUSys clsTimeEvent programmiert. Eine Ausfuhrung dieser Prozedur andert dieEigenschaften des Zeitereignismusters entsprechend dem Typ: Ein absolutes Zei-tereignismuster wird als erledigt ,,beDone” vermerkt und fur ein periodischesZeitereignismuster wird der nachste Termin berechnet.

USys clsExecute:Diese Klasse beinhaltet die Prozedur ,,Public Sub ExecuteSQL Statement (By-Val strAction As String)”. Diese Prozedur ist sozusagen das Herz des Befehls-ausfuhrungssystems (BAS). ,,strAction” ist der Eingabeparameter, der entwederein direkter SQL-Befehl aus dem ARTA-Hauptfenster oder der Aktionsteil einesTriggers sein kann. Diese Prozedur wird im Abschnitt 6.5 genauer untersucht.

USys clsTriggerExecutionContext:Eine Instanz dieser Klasse beinhaltet der sogenannte Trigger execution Context(TEC). In TEC werden bezuglich eines SQL-Ausdruckes folgende Informatio-nen gespeichert: die betroffene Tabelle, der Eereinistyp (DELETE, INSERToder UPDATE), die Transition. Die Transition besteht aus zwei temporarenTabellen NEW TABLE und OLD TABLE. Die Daten der Transitionstabellenwerden in zwei internen Variablen vom Typ ,,Recordset” gespeichert (PrivaterstOld As DAO.Recordset und Private rstNew As DAO.Recordset). Mit Hilfevon Methoden ,,MoveNextRow, MovePrevRow, MoveFirstRow, MoveLastRow”konnen diese Variablen durchlaufen werden.

USys clsParser:Diese Klasse ist hauptsachlich dafur gedacht, einen SQL-Ausdruck zu analy-sieren (parsern). Ein SQL-Ausdruck kann sehr kompliziert werden. Es ist sehraufwendig, einen Parser fur die SQL-Standard-Ausdrucke zu programmieren.Die Programmierung eines richtigen SQL-Parsers geht uber den Rahmen dieserArbeit hinaus. Deswegen sind hier nur eingeschrankte SQL-Ausdrucke erlaubt.Prozeduren in dieser Klasse setzten folgende Syntax fur SQL-Ausdrucke voraus:INSERT INTO Table . . . ,

6.4. KLASSEN, MODULE UND OBJEKTE VON ARTA 75

DELETE [Table.*] FROM Table . . . ,UPDATE Table . . . .Zusatzlich sollen diese Ausdrucke mit dem Access SQL-Dialekt ubereinstimmen.Deswegen ist es zu empfehlen, SQL-Ausdrucke in einer Access Abfrage (QBE-Methode3) herzustellen. Eine weitere Einschrankung besteht in der Benennungder Tabellen. Obwohl in Access selbst fast jedes Zeichen fur die Benennung derAccess-Komponenten erlaubt ist, sollen die Access-Namen in ARTA nur ausZeichen der Menge {a,b,. . . ,z,A,B,. . . , } bestehen.

USys clsTimer und USys clsTimers:Mit Hilfen dieser Klassen wird die Moglichkeit geboten, mehrere Timer zu setzenund zu verwalten.

6.4.2 Module und Objekte

Module beinhalten als ,,Global” deklarierte Prozeduren, die direkt aufgerufenwerden konnen. Es ist also fur den Aufruf von globalen Prozeduren in einemModul kein Objekt notwendig. Deswegen konnen sie an jeder Stelle in VBAbzw. Access vorkommen, wie z.B. in Modulen, Klassenmodulen, Abfragen, For-mularen, Makros. In ARTA wurden zwei Module definiert:

Das Modul: USys FreeFunctionsARTAIn diesem Modul sind einige Funktionen programmiert, die vor allem fur dieNutzung in Triggerteilen (Triggerbedingung und Triggeraktion ) vorgesehensind. Sollten weitere Funktionen zur Erledigung bestimmter Aufgaben notwen-dig sein, konnen sie hier einprogrammiert werden.

Der Befehl AbortEvent() bricht die Ausfuhrung des aktuellen SQL-Ausdrucksab. Dieser Befehl sollte in der Aktion eines Beforetriggers eingegeben werden,wenn ein SQL-Ausdruck unter einer bestimmten Bedingung nicht ausgefuhrtwerden darf. AbortAll() bricht die Ausfuhrung von Anderungsbefehle in der ak-tuellen Transaktion ab und setzt alle Anderungen zuruck.

WarningByEmail(SQL, changeCommand) funktioniert wie folgt:

• Durch die SQL-Abfrage ,,SQL” werden Email-Adressen aus einer geeigne-ten Tabelle ausgewahlt. Dabei ist zu beachten, dass jeweils das erste Feldin der SQL-Abfrage als Email-Adresse auszuwahlen ist.

3Vgl. Abschnitt 4.1, Paragraph ,,Abfragen und SQL-Befehle”


• In einem Warnungsfenster wird der Benutzer darauf hingewiesen, Nach-richten an diese Email-Adressen zu schicken.

• Durch ,,changeCommand” wird eine Anderung an einem bestimmten Feldder ausgewahlten Datensatze dieser Tabelle angezeigt. ,,changeCommand”hat die Syntax ,,<feldname>=<value>”.

Mit einer geeigneten Modifikation (Umprogrammierung) kann diese Prozedur soverwendet werden, dass das Email-Programm vom Betriebsystem automatischausgefuhrt wird und Emails verschickt werden.

DatumAdd(number, Interval, date) addiert ,,nummber”-viele ,,Intervale” zu,,date” und gibt das Ergebnis zuruck. ,,nummber” ist eine naturliche Zahl, ,,In-tervale” ist ein Element aus der Menge {’Minute’, ’Stunde’, ’Tag’, ’Woche’,’Monat’, ’Quartal’, ’Jahr’} und ,,date” ist eine Datumangabe.

DatumAb(dtefrom, Interval, dteuntil) gibt der Zeitabstand zwischen ,,dtef-rom” und , ,,dteuntil” in der Einheit ,,Interval” zuruck.

Das Modul: USys ToolsAndPublicsARTAAuf diesem Modul wurden die globale Variablen (Objekte) und Funktionen ab-gelegt, die zur Triggerbearbeitung benutzt werden. Im folgenden sind die wich-tigsten Objekte aufgelistet:

Unter der Auflistung allTimeEvents (As USys clsSetOfTimeEvents) sind al-le Zeitereignismuster abgelegt. Die Zeitereignismuster sind in der Auflistungnach Datum, an dem das zugehorige Zeitereignis erwartet wird, sortiert. Dabeientspricht das erste erwartete Zeitereignis dem erste Zeitereignismuster in derAuflistung.

Unter der Auflistung allModifyEvents (As USys clsModifyEvents) sind al-le Anderungsereignismuster abgelegt. Jedes Objekt dieser Auflistung ist eineGruppe von Triggern, die beim Auftreten eines bestimmten Anderungsereignis-ses an einer bestimmten Tabelle gefeuert werden mussen.

allTimers (As USys clsTimers) beinhaltet alle gesetzten Timer in ARTA.

Sollte in einer Access-Anwendung ein Makro mit dem Namen ,,Autoexec”erstellt worden sein, wird dieses Makro beim Start der Anwendung (beim Off-nen dieser Datenbank unter Access) automatisch ausgefuhrt. Diese Eigenschaftwurde in ARTA benutzt, um beim Start interne Variablen (Objekte) zu initiali-sieren. Im Makro ,,Autoexec” wird die Prozedur ,,Public Function initSystem()”

6.5. BEFEHLSAUSFUHRUNGSSYSTEM 77

ausgefuhrt. In der Prozedur ,,initSystem()” werden o.g. Objekte (Variablen bzw.Auflistungen) deklariert und bereit gestellt.

6.5 Befehlsausfuhrungssystem

Der Einsatz der ,,Rekursion” ist nach der in Abschnitt 5.3 beschriebenen Trig-gerbearbeitungssemantik unvermeidbar. Nach dem Aufruf einer rekursiven Pro-zedur ruft sie sich wieder auf und stellt der neuen Instanz die neuen Ergebnissezur Verfugung. Zusatzlich soll ein bestimmtes Ergebnis existieren, nach dem dieProzedur sich nicht mehr aufrufen soll. Durch dieses Ergebnis wird das Termi-nieren der Prozedur garantiert.

Die Rekursion fur die Triggerbearbeitung findet in der Prozedur ,,ExecuteS-QL Statement” statt. Im folgenden wird eine stark vereinfachte Version dieserProzedur angezeigt. Viele Zwischenschritte und Anweisungen wurden nicht an-gezeigt, damit der Aspekt der Rekursion besser sichtbar wird.

01)Public Sub ExecuteSQL_Statement(ByVal strAction As String)

02)

03) \\Fuer jeden Trigger von Beforetriggern

04) For Each Tr In beforeTrs

05) Tr.Condition = True => Call ExecuteAction(T.Action)

06) Next Tr

07)

08) \\Die Befortrigger sind bis hierhin alle abgearbeitet,

09) \\und die "eigentliche Ausfuehrung des SQL"-Ausdruckes

10) \\findet hier statt.

11) Call ExecuteAction(strAction)

12)

13) \\Fuer jeden Trigger in Aftertriggern

14) For Each Tr In afterTrs

15) If Tr.Condition = True Then

16) Call ExecuteSQL_Statement(T.Action)

17) End If

18) Next Tr

19)End Sub

Die Beforetrigger werden zwischen den Zeilen ,,03)” und ,,06)” abgearbei-tet. Fur jeden Beforetrigger gilt: Ist dessen Bedingung erfullt, wird die Funktion,,ExecuteAction(Triggeraktion)” aufgerufen. An der Zeile ,,11)” wird der SQL-Ausdruck aufgerufen. Die Aktion jedes Aftertriggers, dessen Bedingung erfullt


ist, wird als Eingabeparameter fur den Aufruf der selben Prozedur in der Zeile,,16)” benutzt und damit ausgefuhrt. Zu jeden Aftertrigger wird die Prozeduralso nochmal aufgerufen. Jede aufgerufene Prozedur muss warten, bis alle Un-terprozeduren mit der Bearbeitung fertig sind.

Die Terminierung dieser Prozedur ist aus der Sicht der Rekursion garantiert,d.h. die Bedingung fur die Beendigung der Rekursion sind in der ,,For Each”-Anweisung (Zeile ,,14)”) gegeben. Wenn alle Aftertrigger abgearbeitet sind, istdie Rekursion zu Ende. Die Tiefe der Rekursion ist jedoch unbekannt. Die Ter-minierung der Prozedur ist allerdings aus Sicht der Triggerbearbeitung nichtgarantiert. Wenn z.B. der SQL-Ausdruck S Aftertrigger {T1, T2, . . . , Tn} feuertund der Aktionsteil des Triggers Ti ∈{T1, T2, . . . , Tn} derselbe SQL-AusdruckS ist, kommt eine endlose Schleife zustande.4

Die endgultige Ausfuhrung eines Befehls findet in der Funktion ,,Execute-Action” statt. Diese Funktion sieht wie folgt aus:

Private Sub ExecuteAction(ByVal strCommand As String)

If strCommand = "" Then

LogFileOutput strCommand & "Keine Aktion!!!!!!!"

ElseIf isSQL(strCommand) Then

’ SQL-Ausdruck

CurrentDb.Execute strCommand

Else

Eval (strCommand)

End If

End Sub

Mit dem Befehl ,,CurrentDb.Execute” konnen nur SQL-Ausdrucke ausgefuhrtwerden. Deswegen wird die Ausfuhrung von ,,nicht SQL-Ausdrucken”, z.B. derAufruf von Funktionen, dem VBA-Befehl ,,Eval” uberlassen.

Ein Trigger mit leerem Aktionsteil wird zwar jedes Mal beim Eintrittseines Ereignisses gefeuert, fuhrt jedoch keine Aktionen aus und ver-ursacht deswegen keine Laufzeitfehler.

Die rekursive Funktion ,,ExecuteSQL Statement” wird aus der Prozedur,,doAction(str)” gestartet. Im folgenden wird ,,doAction(str)” angezeigt. In die-ser Prozedur beginnt erst durch ,,wks.BeginTrans” eine Transaktion und danach

4Vgl. [?], S51-67

6.6. FEHLERBEHANDLUNG 79

wird die rekursive Funktion ,,ExecuteSQL Statement” aufgerufen. Ein Fehler,der in ,,ExecuteSQL Statement” bzw. ,,ExecuteAction” eintritt, wird an ,,doAc-tion” weitergeleitet und die Transaktion wird hier mit ,,wks.Rollback” zuruckge-rollt. Tritt kein Fehler ein, so werden die Anderungen mit ,,wks.CommitTrans”festgeschrieben.

Public Sub doAction(ByVal str As String)

Dim wks As DAO.Workspace

Set wks = DBEngine.Workspaces(0)

wks.BeginTrans

On Error GoTo Err_doAction

Dim clsTExecute As New USys_clsExecute

clsTExecute.ExecuteSQL_Statement (str)

wks.CommitTrans

Exit_doAction:

Exit Sub

Err_doAction:

wks.Rollback

Resume Exit_doAction

End Sub

Die Prozedur ,,doAction(str)” wird an folgenden Stellen aufgerufen:

1. doAction(SQL S) wird im ARTA-Hauptfenster aufgerufen, wenn ein SQL-Ausdruck S an der Datenbank anzuwenden ist.

2. Beim Eintritt eines Zeitereignisses werden alle Trigger separat nacheinan-der in einer Schleife uberpruft. Ist die Bedingung eines Triggers erfullt, sowird die Prozedur doAction(Triggeraktion) aufgerufen.

Die Auswertung von Bedingungen und die Parameterubergabe an Trigge-raktionen werden extra in Unterabschnitt 6.7.1 beschrieben.

6.6 Fehlerbehandlung

In der ARTA-Triggerbearbeitung gibt es keine Kompilierungsfehler. Bei ARTAwurde versucht, die Syntax eines Triggers und des dazugehorigen Ereignismu-


sters bei der Definition zu uberprufen. Am Ende durfen nur die Trigger ak-tiviert sein und spater gefeuert werden, die syntaktisch korrekt definiert sind.Die Sytaxprufung wird in dem Fenster durchgefuhrt, in dem der Trigger unddas Ereignismuster verwaltet werden. Deswegen ist eine korrekte Syntax jedesTriggers garantiert, bevor er zum Einsatz kommt. Logische Fehler sind in derARTA-Triggerbearbeitung wie bei jeder Programmiersprache nicht ohne weite-res zu finden. Sie haben negative Auswirkungen auf das Endergebnis. In ARTAist kein Debugger eingebaut, da der Bau eines Debuggers sehr aufwendig istund uber den Umfang dieser Arbeit hinausgeht. Deshalb sollten Trigger sehraufmerksam definiert bzw. geandert werden.

Ein Laufzeitfehler kann bei der ARTA-Triggerbearbeitung in folgenden Si-tuationen vorkommen:

• Auswertungsfehler konnen bei der Auswertung einer Triggerbedingungeintreten.

• Befehlsausfuhrungsfehler treten bei der Ausfuhrung eines Befehls auf.Diese Fehler sind selbst in zwei Untergruppen zu teilen:

– SQL-Eingabefehler tritt bei der Ausfuhrung der SQL-Eingabe in derAnfangsphase im ARTA-Hauptfenster auf.

– Innen-Befehlsfehler haben sich in den Aktionsteil eines Triggers ein-geschlichen und treten erst dann auf, wenn der Trigger gefeuert wirdund die Auswertung seiner Bedingung ”True” zuruck gibt und seineAktion ausgefuhrt wird.

Auswertungsfehler werden so behandelt, als ob die Auswertung einer Trig-gerbedingung ”False” zuruckgibt. Eine falsche (unsinnige) Bedingung fur einenTrigger bewirkt, dass der Aktionsteil dieses Triggers nie ausgefuhrt werden kann.Deswegen ist es sehr wichtig Triggerbedingungen mit großer Aufmerksamkeit zuformulieren.

Eine leere Trigger-Bedingung ist eine sinnvolle Bedingung und wirdimmer als True interpretiert.

Die SQL-Eingabefehler ist am einfachsten zu behandeln. Solche Fehler wer-den sofort nach dem Maus-Klick auf den entsprechenden Button im ARTA-Hauptfenster erkannt. Es wird direkt eine Access-Fehlermeldung ausgegeben,die dem Benutzer auf den Fehler hinweist. Dabei ist zu beachten, dass im ARTA-Haptfenster nur die SQL-Befehle der Form DELETE . . . , INSERT . . . und UP-DATE . . . erlaubt sind.

6.7. BESONDERE ASPEKTE 81

Innen-Befehlsfehler treten erst im Laufe einer Ausfuhrung ein. Diese Fehlerwerden durch die Ausfuhrung einer Triggeraktion verursacht.

beim Eintreten eines Innen-Befehlsfehlers wird die SQL-Bearbeitungabgebrochen und alle Datenbankanderungen werden zuruckgesetzt.

Ein SQl-Befehl kann eine Kette von voneinander abhangigen Datenbankande-rungen zur Folge haben. Alle Datenbankanderungen dieser Kette mussen vorge-nommen werden, damit das Ziel der Definitionen der daran beteiligten Triggererreicht wird. Datenbankanderungen, die durch einen SQL-Befehl vorgenom-men werden, werden in einer Transaktion zusammengefasst. Dadurch werdenalle Anderungen als eine Einheit (alle oder keine) durchgefuhrt. Die Innen-Befehlsfehler konnen auch aufgrund von Integritatsverletzungen auftreten. Diereferentielle Integritat kann in Access durch Beziehungen und deren Eigenschaf-ten definiert werden. Um solche Fehler zu vermeiden, sollten Integritaten undIntegritatsprufungen nicht durch Access-Beziehungen sondern durch ARTA-Trigger definiert werden.

Im Code der Prozedur ,,doAction” (Im Abschnitt: 6.5) wurden VBA-Metho-den der Transaktionsverwaltung und der Fehlerbehandlung genutzt und mitein-ander kombiniert. Durch diese Kombination wird der erste Innen-Befehlsfehlergefangen und an die Funktion ,,doAction” zuruckgegeben.

6.7 Besondere Aspekte

6.7.1 Trigger Execution Context

Bei einem Trigger, der durch ein Anderungsereignis gefeuert wird, konnen Pa-rameter fur die Inhalte der betroffenen Tabelle bzw. der betroffenen Zeilen derTabelle definiert werden. Diese Parameter konnen im Bedingungs- sowie imAktionsteil des Triggers vorkommen. Dazu mussen die Anderungen des SQL-Ausdrucks, durch dessen Ausfuhrung ein Anderungsereignis eintritt und dieTrigger gefeuert werden, vor der eigentlichen Ausfuhrung bestimmt werden.Um diese Anderungen vorher zu bestimmen, mussen zwei temporare Tabellenerzeugt werden. Die erste temporare Tabelle enthalt die betroffenen Datensatzevor der SQL-Ausfuhrung und die andere temporare Tabelle die betroffene Da-tensatze nach der SQL-Ausfuhrung auf der Originaltabelle. Die temporaren Ta-bellen werden intern erzeugt und nach einer Triggerbearbeitungssitzung au-tomatisch geloscht. Es ist lediglich ein Lesezugriff auf Daten der temporarenTabellen erlaubt. Vor einer Bedingungsauswertung, sowie bei der Bereitstellung


eines Aktionsteils sollten die temporaren Tabelle vorhanden sein.

Bei einem Statement-Level-Trigger ist ein Datenzugriff auf die gesamten In-formationen dieser Tabellen relevant und bei einem Row-Level Trigger sind dieeinzelnen Datensatze interessant. Um einzelne Datensatze zu lesen, mussen die-se Tabellen durchlaufen werden. Die Klasse ,,USys clsTriggerExecutionContext”(Klassenmodul) wurde fur die Erledigung der o.g. Aufgaben vorgesehen. Ein Ob-jekt dieser Klasse wird bei jedem Aufruf der Funktion ,,ExecuteSQL Statement(strAction)” erzeugt, falls ,,strAction” ein SQL-Ausdruck ist und Trigger feuert.Ein Objekt dieser Klasse wird wie folgt erzeugt:

Dim tec As New USys clsTriggerExecutionContext.Nach Erzeugung dieses Objektes stehen seine Methoden zur Verfugung. Mittec.initTEC (strAction) werden die zwei temporare Tabellen auf das aktuelleVerzeichnis (auf dem Verzeichnis, in dem die Datenbank gespeichert ist) ge-speichert. Die temporaren Tabellen haben genau die gleiche Struktur wie dieOriginaltabelle. Um diese Tabelle herzustellen, wird auch die Technik von ,,Ta-bellenerstellungsabfragen” eingesetzt. Eine Tabellenerstellungsabfrage hat dieForm ,,SELECT <feldliste> INTO neueTabellenname FROM alteTabellenna-me WHERE bedingung;”.

Die Herstellung von temporaren Tabellen wird wie folgt durchgefuhrt:

• bei INSERT:

1. newTmp := Orgtable, dabei wird der Befehl ,,DoCmd.CopyObject”eingesetzt.

2. Loschen aller Datensatze aus newTmp mit dem Befehl,,CurrentDb.Execute ’DELETE * From ’ & newTmp”

3. Iem Original-SQL wird der Tabellenname ,,Orgtable” durch ,,new-Tmp” ersetzt. Damit entsteht ein neuer SQL-Ausdruck, ,,sqltmp”.

4. ,,sqltmp” ausfuhren.

Damit besteht ,,newTmp” aus den neuen Datensatzen, die mit der Ausfuhr-ung des SQL-Ausdrucks zur ,,Orgtable” hinzugefugt werden. Bei INSERThat die ,,oldTmp” keine Daten.

• Bei DELETE soll der Befehl ,,CurrentDb.Execute ’SELECT * into ’ &oldTmp & ’ From ’ & Orgtable & ’ ’ & getWhere” ausgefuhrt werden, wo-bei der WHERE-Teil mit Hilfe von Prozeduren der Klasse ,,USys clsparser”aus dem Original-SQL berechnet wird. Durch die Ausfuhrung dieses Be-fehls wird eine Tabelle Namens ,,oldTmp” erstellt, die genau diejenigen


Datensatze besitzt, die aus der Originaltabelle geloscht werden sollen. Bei,,DELETE” ist die temporare Tabelle ,,newTmp” leer.

• Bei UPDATE:

1. oldTmp := Orgtable mit dem Befehl ,,DoCmd.CopyObject”.

2. in oldTmp werden alle nicht betroffenen Datensatze geloscht, damitin dieser Tabelle nur die betroffenen Datensatze im alten Zustandubrig bleiben. Dabei werden die Methoden der Klasse ,,USys clsparser”benutzt, um den WHERE-Teil vom Original-SQL zu berechnen undzu negieren.

3. newTmp := oldTmp mit dem Befehl ,,DoCmd.CopyObject”. Nunsind beide temporaren Tabellen identisch.

4. Im Original-SQL wird der Tabellenname ,,Orgtable” durch ,,new-Tmp” ersetzt. Damit entsteht ein neuer SQL-Ausdruck, ,,sqltmp”.

5. ,,sqltmp” ausfuhren.

Die temporaren Tabellen werden unter zufallig erzeugten Namen gespeichert.Der Name von oldtmp hat die Vorsilbe ,,USys ARTA OLD ” und der Namevon newtmp hat die Vorsilbe ,,USys ARTA NEW ”. Nach der Vorsilbe kommteine zufallige Zeichenkette, bestehend aus zehn Buchstaben gefolgt von einerzufalligen (achtstelligen) Zahl. Dabei werden die VBA-Befehle ,,Randomize”und ,,Rnd” eingesetzt. Diese Namen werden nach Beendigung einer Trigger-bearbeitungssitzung in der Funktion ,,doAction” geloscht. Zur Sicherheit wirdbeim Loschen uberpruft, ob der Name der o.g. Form entspricht, damit keinewichtige Tabellen geloscht werden.

Durchlaufen der TransitionenIn einem Objekt der Klasse ,,USys clsTriggerExecutionContext” sind zwei in-

terne Variablen zustandig fur die Bereitstellung der betroffenen Datensatze furden Einsatz in den Triggerteilen. Diese Variablen sind vom Typ ,,Recordset”der Schnittstelle ,,DAO” und werden wie folgt definiert:Private rstOld As DAO.RecordsetPrivate rstNew As DAO.Recordset

Nachdem die temporaren Tabellen hergestellt sind, werden die betroffenenDatensatze werden in diese Variablen wie folgt ubernommen:Set rstNew = CurrentDb().OpenRecordset(USys ARTA NEW . . . )Set rstOld = CurrentDb().OpenRecordset(USys ARTA OLD . . . )Mit Hilfe von Methoden, die in dieser Klasse programmiert sind, wie ,,Mo-veNextRow”, ,,MovePrevRow”, ,,MoveFirstRow”, ,,MoveLastRow” werden die


Recordset-Variablen durchlaufen.

Mit Hilfe der Methode ,,makeAction” werden alle Parameter im Aktionsteileines Triggers durch die Inhalte von temporaren Tabellen ersetzt. Dazu werdenMethoden der Klasse ,,USys clsparser” sowie ,,USys clsTriggerExecutionContext”benutzt.

Eine weitere wichtige Methode dieser Klasse ist ,,ConditionValue”. DieseMethode gibt ja/nein zuruck, d.h. dass die Auswertung der Triggerbedingungdurch diese Methode erledigt wird. In dieser Methode werden Parameter dertemporaren Tabellen berechnet und in der Triggerbedingung eingesetzt. Nachdem Einsetzen der Inhalte von Parameter wird das Ergebnis mit Hilfe des Be-fehls ,,ConditionValue=CBool(Eval(CStr(strconditionText)))” ausgewertet, wo-bei der Triggerbedingungstext nach dem Parametereinsatz ,,strconditionText”ist.

6.7.2 Timer

Timer wurden in ARTA mit Hilfe von API-Schnittstelle realisiert. Dabei wurdenzwei Prozeduren aus der DLL-Datei ,,User32.dll” eingesetzt. Zunachst mussendiese Prozeduren wie folgt deklariert werden:

Private Declare Function SetTimer _

Lib "User32" _

( _

ByVal Hwnd As Long, _

ByVal nIDEvent As Long, _

ByVal uElapse As Long, _

ByVal lpTimerFunc As Long _

) _

As Long

Private Declare Function KillTimer _

Lib "User32" _

( _

ByVal Hwnd As Long, _

ByVal nIDEvent As Long _

) _

As Long

Mit dem Aufruf der Prozedur ,,SetTimer” wird ein Timer gesetzt, der alle,,uElapse”-Millisekunden ,,periodisch” eine Ruckruf-Funktion der Adresse ,,lp-


TimerFunc” aufruft. Durch den Aufruf der Prozedur ,,KillTimer” wird der Ti-mer mit der Idenditatsnummer ,,nIDEvent” abgebrochen. Der Einsatz dieserProzeduren in ARTA ist wie folgt:

Zur Realisierung der Timerverwaltung, deren Semantik im Bild 5.4 geschil-dert wurde, sollen zwei Ruckruf-Funktionen vorgesehen werden, ,,TimerProc”und ,,settingTimer”. Der Aufruf von ,,TimerProc” bedeutet, dass ein Zeiter-eignis aufgetreten ist. Aufruf von ,,settingTimer” bedeutet, dass ein Timer ggf.entweder fur ein Datum innerhalb einer Woche oder fur ,,einen Tag” gesetztwerden soll. Diese Prozeduren sind wie folgt aufgebaut:

Public Function TimerProc(Hwnd, uMsg, idEvent, dwTime) As Long

0)Aktuellen Timer abbrechen

Dim lRet As Long

lRet = KillTimer(0&, TimerID)

1)Trigger der Zeitereignisses werden bearbeiten

2)Die Variable mit dem Zeitereignismuster modifizieren

3)Die in der Vergangenheit aufgetretenen Zeitereignisse

bearbeiten

4)"settingTimer 0, 0, 0, 0" aufrufen

End If End Function

Public Function settingTimer(Hwnd, uMsg, idEvent, dwTime)

0)Aktuellen Timer abbrechen

Dim lRet As Long

lRet = KillTimer(0&, TimerID)

1)If Ein Zeitereignis innerhalb einer Woche erwartet

TimerID = _

SetTimer(0&, 0&, DauerbisZeitereignis, AddressOf TimerProc)

Else

TimerID = _

SetTimer(0&, 0&, DauereinesTages, AddressOf settingTimer)

End If

End Function

Diese Prozeduren mussen genau die gezeigte Gestaltung besitzen, damit sieals Ruckruf-Funktion von ,,SetTimer” akzeptiert werden. Fur die Eingabepara-meter von ,,TimerProc” und ,,settingTimer” werden hier immer ,,0” eingesetzt.Diese Parameter ermoglichen in ,,Visual Basic” (VB) mehr Funktionalitaten,z.B. die Verbindung von Timern mit Forms.


6.7.3 Behandlung vergangener Zeitereignisse

Zeitereignisse, die in der Vergangenheit aufgetreten sind sollen berucksichtigtund deren Trigger bearbeitet werden, falls deren DeadLines noch nicht um sind.Durch die Berucksichtigung der Deadlines wird festgestellt, ob Trigger einesZeitereignisses gefeuert werden durfen oder nicht. Jedes mal wenn eine zeitlangkein Timer gesetzt war, sollen solche Zeitereignisse in der Vergangenheit gesuchtwerden. Solche Ereignisse sind zunachst in der Systempause zu suchen, wenndas Accessprogramm oder der Rechner eine zeitlang abgeschaltet war.

Diese Zeitereignisse konnen auch nach der Bearbeitung von Triggern, diedurch ein Zeitereignis gefeuert wurden, gefunden werden. Nachdem ein Zei-tereignis aufgetreten ist, wird der Timer abgeschaltet und gefeuerte Triggerwerden bearbeitet. Die Deadline darf nicht kurzer als 5 Minuten sein. DieseGrenze kann hoher angesetzt werden, falls die Dauer von Triggerbearbeitungin einer ARTA-Datenbank sehr groß wird oder falls Trigger eines Zeitereig-nisses auf jeden Fall/unbedingt bearbeitet werden mussen. Die Bearbeitungsolcher Trigger wird mit Hilfe von Funktion ,,processOldTimeEvents” durch-gefuhrt. Annahme: ,,allTimeEvents” ist die Auflistung vom Typ (der Klasse),,USys clsSetOfTimeEvents”, die alle Zeitereignismuster beinhaltet. Durch die-se Funktion wird folgender Algorithmus realisiert:

1. Begin der Bearbeitung von ,,processOldTimeEvents”

2. In dieser Funktion wird das erste Element der Auflistung ,,allTimeEvents”(die Agenda) von Zeitereignismustern untersucht.Tritt das Zeitereignis in der Zukunft auf, gehe zu (7).

3. Liegt sein Erwartungszeit in der Vergangenheit, so werden seine Triggerbearbeitet.

4. Ausfuhrung des Befehls,,Call allTimeEvents.addEvents (allTimeEvents.Item.ModifyEventsStaten)”.Das erledigt zwei Aufgaben:

(a) Durch ,,allTimeEvents.Item.ModifyEventsStaten” wird das erste Ob-jekt der Auflistung durchsucht und modifiziert. D.h. alle absolutenZeitereignismuster in diesem Objekt werden als erledigt eingestuftund gekennzeichnet und bei jedem periodischen Zeitereignismusterwird der nachste Termin berechnet. Zusatzlich werden die periodi-schen Zeitereignismuster mit neuen Terminen zuruckgegeben.

(b) Die periodischen Zeitereignismuster mit neuen Terminen werden durchden Befehl ,,allTimeEvents.addEvents(. . . )” wieder in die Auflistungaufgenommen.


5. Nun wird das modifizierte Objekt aus der Auflistung entfernt:allTimeEvents.Remove

6. Gehe zu der Zeile (1).

7. Ende der Bearbeitung von ,,processOldTimeEvents”

,,processOldTimeEvents” ist eine rekursive Prozedur und endet mit der Erfullungder Bedingung der Zeile (2).

Kapitel 7

Zusammenfassung und Ausblick

In der vorliegenden Arbeit wurde ARTA als eine Erweiterung des Access-Daten-bankmanagementsystems um die Triggerfunktionalitat implementiert. In ARTAwerden Formulare als Benutzeroberflachen eingesetzt, um Benutzern die Ver-waltung von Triggern und Ereignismustern zu ermoglichen. Ereignisse, die inARTA spezifiziert und wahrgenommen werden sind ,,atomar” bzw. primitiv.Dabei konnen Ereignisse entweder vom Typ ,,Anderungsereignisse” oder vomTyp ,,Zeitereignisse” sein. Die Triggersprache in ARTA basiert insoweit auf derTriggersprache von SQL3, dass sie ,,fast” die gleiche Syntax und Semantik in Be-zug auf Anderungsereignisse besitzen. Bezuglich Zeitereignissen sind sie dagegenvollig unterschiedlich, da in SQL3 im Gegensatz zu ARTA Zeitereignisse nichtunterstutzt werden. Um Zeitereignisse zu realisieren, wurden in ARTA Timerdurch Einsatz geeigneter Funktionen von API-Schnittstellen implementiert. UmAnderungsereignisse erkennen und deren Trigger bearbeiten zu konnen, sollenalle Datenbankanderungen durch SQL-Befehle und unter dem direkten Einsatzvon ARTA vorgenommen werden.

ZeitereigniserkennungsgranularitatWenn Access eine Transaktion von Datenbankanderungen durchfuhrt und

gleichzeitig die Ruckruffunktion des Timers aufgerufen wird (Eintreten einesZeitereignisses), muss das Zeitereignis eigentlich als nicht geschehen betrach-tet werden. Trigger eines solchen Zeitereignisses konnen nicht direkt bei Ereig-niseintritt bearbeitet werden, da in Access eine Transaktion lauft, die durchAusfuhrung einer Prozedur begonnen wurde. Diese beiden Vorgange konnen inAccess nicht gleichzeitig bearbeitet werden konnen. Um dieses Problem zu losenhabe ich in der vorliegenden Arbeit eine Deadline fur Zeitereignisse eingefuhrt.Bei der Eingabe der Deadline kann eine beliebige Granularitat fur das Erkennendes jeweiligen Zeitereignisses eingeplant werden. Dadurch werden Trigger einesZeitereignisses gefeuert, obwohl das Zeitereignis nicht direkt an dem definierten

89

90 KAPITEL 7. ZUSAMMENFASSUNG UND AUSBLICK

Zeitpunkt sonder Spater wahrgenommen wird.

Erweiterungs- bzw. Verbesserungsvorschlage

Ohne auf den Source Code von Access und DB Engine zugreifen zu mussen,lasst sich ARTA in folgenden Bereichen erweitern:

Zusammengesetzte Ereignisse:ARTA unterstutzt nur primitive Ereignisse. Solche Ereignisse werden durch Er-eignismuster beschrieben, denen bei der Definition eindeutige Namen zugeord-net werden. Diese Benennung von Ereignismustern kann als eine Voraussetzung(eine Basis) fur eine Erweiterung von ARTA um zusammengesetzte Ereignissedienen, indem das Eintreten jedes (interessanten) Ereignisses in einer Ereignis-historie protokolliert wird. Um ein zusammengesetztes Ereignismuster zu erken-nen, konnen die eingetretenen (und protokollierten) Ereignisse aus der Historieabgelesen und mit dem Ereignismuster verglichen werden. Damit werden in-teressante Datanbanksituationen beschreibbar, z.B. ,,At Zeitereignis AND OnAnderungsereignis”, ,,Beim vierten Eintreten von E”.

Es stellt sich hier die Frage, ob alle auftretenden Ereignisse protokolliertwerden mussen: Wenn alle Ereignisse protokolliert werden, erhalt man mogli-cherweise eine riesige Datenmenge, von der nur ein relativ kleiner Anteil imweiteren gebraucht wird. Um diese großen Mengen uberflussiger Daten zu ver-meiden ware die Realisierung eines intelligenten Systems notig, das interessanteEreignisse bei der Triggerdefinition herausfiltert. Ein solches System konnte z.B.bei der Definition von zusammengesetzten Ereignismustern nur ,,die beteiligtenprimitiven Ereignisse” als interessante Ereignisse einstufen, die dann in der Fol-ge protokolliert werden.

Relative ZeitereignisseDie Realisierung von relativen Zeitereignissen ist eine weitere Erweiterungsmoglich-keit. Dadurch werden Zeitereignisse erkannt, die eine bestimmte Zeitdauer voroder nach periodischen bzw. absoluten Zeitereignissen eintreten: z.B. ,,der letz-te Freitag vor dem 15.10.2002” oder ,,6 Monate nach der Anmeldung einesDiplomarbeitsthemas”.

Verbindung mit anderen DatenbankenDurch die Benutzung von Schnittstellen wie ODBC bzw. JDBC und Access-

ADO, kann Access mit anderen Datenbanksystemen verbunden werden. In ARTA

91

wurde die Anfragesprache SQL eingesetzt, um automatische Datenbankande-rungen mit Hilfe von VBA-Befehlen (z.B. database.Execute(SQL)) durchzufuhren.Da SQL in vielen Datenbankmanagementsystemen (Oracle, Sybase, DB2, . . . )eingesetzt wird, bietet sich eine ARTA-Erweiterung an, um auch in diesen ande-ren Datenbanken die ARTA-spezifische Triggerfunktionalitat anzuwenden. Umeine Kommunikation zwischen Benutzern und Datenbanken in anderen Syste-men zu ermoglichen, wird Access als Benutzteroberflache benutzt. Dabei sollenentschieden werden, ob z.B. Informationen von Triggern in ARTA (Access) blei-ben oder in der jeweiligen Datenbank eingesetzt werden sollen.

Echtzeit-DatenbanksystemZeitereignisse werden in ARTA mit einer Deadline versehen. Die Deadline einesZeitereignisses kontrolliert, dass ein Zeitereignis Trigger nur innerhalb eines Zei-tintervals feuern darf bzw. kann. Das Zeitinterval ist [t, t+Deadline], wobei abdem Zeitpunkt t das Ereignis erwartet wird. Wie lange die Bearbeitung solcherTrigger dauert, ist dabei nicht relevant. Eine mogliche Verbesserungs ware, aucheine Zeitgrenze fur das Bearbeitungsende von Triggern vorzusehen, die durchein Zeitereignis (oder gar Anderungsereignis) gefeuert werden. Dadurch sollteein Zeitereignis bzw. Anderungsereignis innerhalb eines Zeitintervales Triggerfeuern durfen und die Bearbeitung von solchen Triggern sollte innerhalb einerZeitdauer fertig sein.

Entwurf eines besseren ParsersHat sich ein Fehler bei der Formulierung eines SQL-Ausdrucks eingeschlichen,so wird erst bei der Ausfuhrung dieses SQL-Ausdrucks (z.B. durch VBA-Befehl,,database.Execute(SQL)” oder durch Aktualisierungsabfragen) eine detaillier-te Fehlermeldung ausgegeben. Daraus kann erkannt werden, dass in Access eininterner SQL-Parser installiert ist. Leider ist der Access-Parser weder mit Hilfevon Access- noch VBA-Befehlen vollstandig benutzbar. So kann z.B. der Nameder betroffenen Tabelle im SQL-Ausdruck mit Hilfe von Access- bzw. VBA-Befehlen nicht gefunden werden.

In ARTA sollten SQL-Ausdrucke bis ins Detail analysiert werden, um da-mit insbesondere die Transitionstabellen herzustellen (Parser-Problem). In derAnalyse sollten z.B. der Tabellenname, die betroffenen Spaltennamen und derWHERE-Teil eines SQL-Ausdrucks bestimmt werden. Um eine solche Analysezu gewahrleisten wurde in ARTA ein Parser realisiert, der nicht jeden moglichenSQL-Ausdruck analysieren (parsern) kann. Er beschrankt sich dagegen auf diewesentlichen SQL-Ausdrucke zur Erstellung von Transitionstabellen. Die Rea-lisierung eines Parsers, der SQL-Ausdrucke in vollem Umfang analysieren kannware eine deutliche Verbesserung. Der Parser konnte direkt in der Programmier-

92 KAPITEL 7. ZUSAMMENFASSUNG UND AUSBLICK

sprache VBA realisiert werden. Man konnte auch einen Parser in einer anderenProgrammiersprache (z.B. c++ oder Java) programmieren und ihn dann in ei-nem VBA-Code ausfuhren lassen.

Literaturverzeichnis

[ISHaRa] Theo Harder, Erhard Rahm: Datenbanksysteme, Konzepte undTechniken der Implementierung, ISBN 3-540-65040-7, Springer,1999.

[ISVos] Gottfried Vossen: Datenbankmodelle, Datenbanksprachen und -Datenbankmanagementsystemen, ISBN 3-486-25339-5, Olden-bourg Wissenschaftsverlag GmbH, 2000.

[ISKeEi] Alfons Kemper, Andre Eickler: Datenbanksysteme, EineEinfuhrung, R. Oldenbourg Verlag Munchen, Wien, 1999.

[ISVrl] Prof. Dr. Rainer Manthey: Vorlesungsskript zur Vorlesung ,,Infor-mationssysteme”, Universitat Bonn, Wintersemester 1999/2000.

[AKHaWi] Eric N. Hanson, Jennifer Widom: An overview of production ru-les in database systems, 121-143, The Knowledge Engineering Re-view, Vol 8:2 1993 Cambridge University Press.

[AKWiCe] Jennifer Widom, Stefano Ceri: Introduction to Active DatabaseSystems, Morgan Kaufmann Publishers, 1996.

[AKPaDi] Norman W. Paton, Oscar Dıaz: Active Database Systems ACMComputing Surveys, Volume 31, Number 1, March 1999, 63-103.

[AKPat10] Krishna Kulkarni, Nelson Mattos, Roberta Cochrane: Active Da-tabase Features in SQL3, Chapter 10 in (Norman W. Paton: ActiveRules in Database Systems, ISBN 0-387-98529-8, Springer-Verlag,Berlin Heidelberg, 1999).

[AKPat12] Stella Gatziu, Klaus R. Dittrich: SAMOS, Chapter 12 in (NormanW. Paton: Active Rules in Database Systems, ISBN 0-387-98529-8, Springer-Verlag, Berlin Heidelberg, 1999).

93

94 LITERATURVERZEICHNIS

[AKPat21] Jorgen Hansson, Mikael Berndtssen: Active Real-Time Databa-se Systems, Chapter 21 in (Norman W. Paton: Active Rules inDatabase Systems, ISBN 0-387-98529-8, Springer-Verlag, BerlinHeidelberg, 1999).

[AKDiGa] Klaus R. Dittrich, Stella Gatziu: Aktive Datenbanksysteme, Kon-zepte und Mechanismen, ISBN 3-932588-19-3, dpunkt-Verlag,2000.

[DKCrGH] Armin B. Cremers, Ulrike Griefahn, Ralf Hinze: Deduktive Da-tenbanken. Eine Einfuhrung aus der Sicht der logischen Program-mierung, ISBN 3-528-04700-3, Vieweg & Sohn VerlagsgesellschaftmbH, Braunschweig/Wiesbaden, 1994.

[AKVrl] Prof. Dr. Rainer Manthey: Vorlesungsskript zur Vorlesung ,,Ak-tive Datenbanken und Ereignisorientierte Programmierung”, Uni-versitat Bonn, Wintersemester 2000/2001.

[DKVrl] Prof. Dr. Rainer Manthey: Vorlesungsskript zur Vorlesung,,Deduktive Datenbanken”, Universitat Bonn, Wintersemester2000/2001.

[VB6Ko] Michael Kofler: Visual Basic, Programmiertechniken, Datenban-ken, Internet, ISBN 3-8273-1428-3, Addison Wesley Longman Ver-lag GmbH, 1999.

[VBAHGG] Ken Getz, Mike Gilbert: Visual Basic Language Developers Hand-book, chapter 3 & chapter 6 SYBEX, Alameda 2000.

[APIHnd] Gotz Reinecke: Das API Handbuch, Ein Artikel uber dieVerwendung des APIs unter Visual Basic, Version 1.02,http://www.activevb.de, 7/2001.

[APIApp] Dan Appelman: Dan Appelmans Win32 Puzzle-Buch, Puzzles undTutorials fur Visual Basic-Profis, ISBN 3-934358-21-7, GalileoPress GmbH, Bonn, 2000.

[A00AN] Ralf Albrecht, Natascha Nicol: Access 2000 Programmieren, Pro-fessionelle Anwendungsentwicklung mit Access und VBA, ISBN3-8273-1547-6, Addison-Wesley, 2000.

[A00BK] Wayne F. Brooks, Lars Klander: Professionelle Access 2000 Pro-grammierung, ISBN 3-8266-0577-2, MITP-Verlag GmbH, Bonn,1999.

LITERATURVERZEICHNIS 95

[A97AN] Ralf Albrecht, Natascha Nicol: Microsoft Access 97, Das Hand-buch, Das ganze Softwarewissen, ISBN 3-86063-135-7, MicrosoftPress Deutschland, 1998.

[A0SQLBB] Irene Brauer, Jurgen Bar: Access 2000 und MS SQL Server imTeamwork, ISBN 3-446-21473-9, Carl Hanser Verlag, MunchenWien, 2000.

[ASQLMH] Norbert Michelmann, Rolph Hettwer, Mitarbeit: Hans-DieterSchmidt: Datenbankentwicklung und -anpassung mit MS Accessund SQL, ISBN 3-8237-6802-6, Verlag H. Stam GmbH, Koln,2001.

[dplLein] Hans-Hermann Leinen: Ein Praprozessor zur Implementierung ei-ner temporalen Erweiterung von SQL, Diplomarbeit an der Uni-versitat Bonn, Institut fur Informatik III, August 2001.

[dplLoeh] Torsten Lohr: Eine Erweiterung der aktiven Regelsprache Phoenixum temporale Ereignisse, Deadlines und Alternativen, Diplomar-beit an der Universitat Bonn, Institut fur Informatik III, Mai1997.

[dplModi] Jurgen Modic: Eine Erweiterung des Triggerkonzeptes von Phoe-nix um temporale Ereignisse, Diplomarbeit an der UniversitatBonn, Institut fur Informatik III, August 2001.

[dplMuen] Sascha Munch: ARA, Eine Erweiterung des relationalen Daten-banksystems Access um Trigger, Diplomarbeit an der UniversitatBonn, Institut fur Informatik III, Oktober 2001.

[AutoHoUl] John E. Hopcroft, Jeffrey D. Ullmann: Einfuhrung in die Auto-matentheorie, formale Sprachen und Komplexitatstheorie, ISBN3-89319-744-3, Addison-Wesley, 1994.

[SQLVrl] Prof. Dr. Rainer Manthey: Vorlesungsskript zur Vorlesung ,,Rela-tionale Datenbanken”, Universitat Bonn, Sommersemester 2000.

[SQLMeSi] Jim Melton, Alan R. Simon: SQL:1999Understanding Relational Language Components, Chapter 11,Morgan Kaufmann Publishers.

[SQLTrKo] Robert Cochrane, Hamid Pirahesh, Nelson Mattos: IntegratingTriggers and Declarative Constraints in SQL Database Systems,Site 567-578, IBM Almaden Research Center, SanJose, CA,www.vldb.org/conf/1996/P567.PDF.

96 LITERATURVERZEICHNIS

[SQLStnd] American National Standard for Information Technology:ANSI/ISO/IEC 9075-2-1999, Database Languages -SQL-Part2:Foundation (SQL/Foundition), 08.12.1999, 90-92, 387-389,497-501.

Erklarung gemaß §19,7 DPOHiermit erklare ich, die vorliegende Diplomarbeit selbstandig verfasst und kei-ne anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitatekenntlich gemacht zu haben.

Bonn, den 30. August 2002

97

ARTA Entwurf und Implementierung einer Triggersprache mit ... · Rheinische...

Documents

Transcript of ARTA Entwurf und Implementierung einer Triggersprache mit ... · Rheinische...