Erweiterungskonzepte für das aktive Datenbanksystem ARTA

Rheinische Friedrich – Wilhelms – Universität Bonn
Institut für Informatik III
Erweiterungskonzepte für das aktive
Datenbanksystem ARTA
Diplomarbeit von
Vincenzo Calí
Kalker-Hauptstr.205
D – 51103 Köln
Email:[email protected]
Betreuer
Prof. Dr. Rainer Manthey
April 2004
II
Eidesstattliche Erklärung:
Ich erkläre hiermit wahrheitsgemäß, daß ich
-
die eingereichte Arbeit selbständig und ohne unerlaubte Hilfsmittel angefertigt,
-
nur die im Literaturverzeichnis aufgeführten Hilfsmittel benutzt und fremdes
Gedankengut als solches kenntlich gemacht,
-
alle Personen und Institutionen, die mich bei der Vorbereitung und Anfertigung
der Abhandlung unterstützt haben, genannt und
-
die Arbeit noch keiner anderen Stelle zur Prüfung vorgelegt habe
Ort, Datum
Unterschrift (Vor – und Zuname)
III
IV
Vorwort
Mein Dank gebührt Herrn Prof. Dr. Rainer Manthey für die Empfehlung, mich mit diesem interessanten Thema zu beschäftigen und die wissenschaftliche Betreuung der Arbeit. Seine zahlreichen Anregungen und wertvollen Kommentare haben wesentlich zur
Verbesserung der Arbeit beigetragen.
Außerdem möchte ich meiner Lebensgefährtin Rebecca, die gerade unser Kind austrägt,
für ihre tolle Unterstützung danken. Sie ist der treibende Motor in meinem Leben
DANKE!!!! ☺
V
VI
Inhaltsverzeichnis
Einleitung
Kapitel 1
1.1
1.2
1.3
Kapitel 2
2.1
2.2
2.3
Kapitel 3
3.1
3.2
3.3
3.4
Kapitel 4
4.1
4.2
4.3
4.4
Kapitel 5
5.1
5.2
5.3
Kapitel 6
6.1
6.2
6.3
6.4
Kapitel 7
7.1
7.2
7.3
7.4
Kapitel 8
8.1
8.2
8.3
8.4
1
Aktive Datenbanken
3
Motivierende Beispiele...................................................................................4
Regelparadigma..............................................................................................5
Regelspezifikation ..........................................................................................6
Microsoft Access
11
Architektur von Microsoft Access ...............................................................11
Komponenten einer Datenbankanwendung..................................................12
Datenzugriffsschnittstellen...........................................................................28
Microsoft Visual Basic
32
Visual Basic-Entwicklungsumgebung .........................................................32
Objekte, Eigenschaften und Module ............................................................34
Visual Basic-Grundlagen .............................................................................36
API................................................................................................................37
SQL:1999
39
Grundlagen von SQL....................................................................................39
SQL-Triggersprache.....................................................................................41
Syntax der SQL-Triggersprache...................................................................41
Semantik der SQL-Triggersprache...............................................................44
ARTA (Active Real Time Access DBS)
46
Namenskonvention.......................................................................................46
GUI von ARTA ............................................................................................46
Erweiterungen in ARTA II...........................................................................48
Erweiterungen der SQL-Triggersprache
49
Steuerungskomponenten ..............................................................................49
Zeitereignisse................................................................................................51
Syntax der ARTA II-Trigger........................................................................57
Semantik der ARTA II-Trigger....................................................................60
ARTA II
63
Schichtenarchitektur.....................................................................................64
Systemarchitektur.........................................................................................65
Time Event Manager ....................................................................................66
Trigger Execution.........................................................................................71
GUI
75
ARTA II-Menüstruktur ................................................................................75
Triggerübersichtsoberfläche.........................................................................77
Triggereditor.................................................................................................78
SQL-Statement Terminal .............................................................................82
Zusammenfassung
Literaturverzeichnis
Anhang
83
85
83
VII
VIII
Erweiterungskonzepte für das aktive DBMS ARTA
Einleitung
..
Einleitung
„A Trigger is like a genie that you can place inside the database, to wake up and do your bidding whenever a certain
event takes place“ [DCha98].
DB
DB
DB
In dieser Arbeit wird das System ARTA II vorgestellt, das als Präprozessor für das
Datenbankverwaltungssystem (DBMS) Microsoft Access dient. ARTA II wurde in
Visual Basic implementiert, basiert auf einem in früheren Diplomarbeiten entwickelten aktiven DBMS namens ARTA und steht für „Active Real Time Access Database System“. Das Microsoft Access-Datenbanksystem wurde um aktive Regeln
erweitert, die das passive in ein aktives Datenbanksystem überführen, um auf eintretende Situationen geeignet zu reagieren.
Die aktiven Regeln, die in ARTA II verwendet werden, funktionieren nach dem
Grundkonzept der ECA-Regeln und werden auch als Trigger bezeichnet. Als Trigger (deutsch: Auslöser) bezeichnet man in SQL eine Anweisungsfolge (eine Abfolge von Aktionen), die ausgeführt wird, wenn eine verändernde Anweisung auf einer bestimmten Tabelle ausgeführt werden soll. Sie dienen der automatischen, ereignisgesteuerten Ausführung von SQL-Befehlen. Diese werden vom DBMS ausgewertet bzw. überprüft, um dann automatisch zugehörige Aktionen auszuführen.
Trigger sind ein mächtiges und flexibles Programmierungskonzept. Durch aktive
Regeln, kann die Datenbank auf bestimmt eintretende Ereignisse reagieren. Die
Ereignisse, die eine aktive Regel auslösen können, sind z.B. Datenbankänderungen
(insert, delete oder update) oder das Eintreten eines bestimmten Zeitpunktes.
In SQL sind Trigger erstmals im SQL:1999-Standard eingeführt worden. Die Trigger in SQL werden durch die primitiven Datenmanipulationsereignisse insert, update und delete ausgelöst. Die ARTA II-Triggersprache hingegen erlaubt es, auch
auf Zeitereignisse zu reagieren. Dazu mußte das SQL-Triggerkonzept von
SQL:1999 beträchtlich erweitert werden. Außerdem ist eine Erweiterung der SQLTriggersprache um Steuerungselemente nötig. Die Steuerungselemente eines Triggers dienen z.B. der Angabe über den Zustand eines Triggers, also ob dieser aktiviert oder deaktiviert ist. Es kann ein Gültigkeitsintervall für einen Trigger angegeben werden, um festzulegen, wie lange dieser gültig ist. Bei Erstellen eines Triggers wird eine Priorität vergeben, die auch manuell verändert werden kann. Mit ihr
kann eine eindeutige Abarbeitungsreihenfolge festgelegt werden. In SQL:1999 ist
die Abarbeitungsreihenfolge durch das Erstellungsdatum des Triggers festgelegt
und somit nicht so flexibel zu handhaben wie in ARTA II.
Der Zeitereignisaspekt wurde bereits in verschiedenen Arbeiten untersucht, wie in
[Modic00] und [Löhr97] und in einigen objektorientierten Datenbankverwaltungssystemen wie z.B. HiPAC (High Performance Active Database System) oder
SAMOS (Swiß Active Mechanism Besed Object-Oriented Active Database Sys1
Erweiterungskonzepte für das aktive DBMS ARTA
Einleitung
tems) realisiert. Die periodischen Zeitereignisse, die in ARTA realisiert wurden
beruhten auf diese Studien. In ARTA II hingegen wurde ein neues Konzept zur
Realisierung der periodischen Zeitereignisse erstellt und umgesetzt.
Die Entwicklung eines aktiven DBMS stellt auch eine besondere Anforderung an
die grafische Benutzerschnittstelle (GUI). Mit der in ARTA II neu gestalteten
grafischen Benutzeroberfläche wird dem Anwender ein komfortables Werkzeug
zur Verfügung gestellt, um Trigger in der erweiterten SQL-Triggersprache zu erstellen. Schwerpunkt bei der Gestaltung und Implementierung der GUI war es, dem
Anwender bei der Erstellung eines SQL-basierten Triggers so zu helfen, daß dieser
keinerlei Fehleingaben bezüglich der Syntax tätigen kann. Ein weiterer Schwerpunkt war die Realisierung der Triggerverwaltung und -aktivierung mittels der
GUI, so daß der Anwender den Zustand der ARTA-Trigger abrufen und auch ändern kann. Der wichtigste Aspekt jedoch beruht auf der grafischen Realisierung für
die Eingabe und Anzeige der verschiedenen Ereignistypen.
Möchte man direkt SQL-Statements an die Datenbank absetzen, so kann dies über
eine Art Terminal realisiert werden. Auch hier soll eine komfortable Verwaltung
bereits gespeicherter SQL-Statements über der GUI das Arbeiten erleichtern.
Aufbau der Arbeit
In Kapitel 1 wird eine Einführung in aktive Datenbanken gegeben. Dieses, sowie
die folgenden drei Kapitel bilden den Grundlagenteil dieser Arbeit. In Kapitel 2
wird das Datenbankverwaltungssystem Microsoft Access vorgestellt in das ARTA
II implementiert wurde. Kapitel 3 stellt die Programmiersprache Microsoft Visual
Basic vor, in der ARTA II vollständig programmiert wurde. Die Entwicklungsumgebung, sowie wichtige Sprachkonstrukte werden hier behandelt. Anschließend
wird in Kapitel 4 SQL:1999 kurz vorgestellt. Die Syntax und die Semantik der
SQL-Triggersprache sind hier von relevanter Bedeutung, da diese die Basis der
ARTA II-Triggersprache bildet. In Kapitel 5 wird das alte ARTA-System vorgestellt. Anschließend werden die Erweiterungen zum neuen ARTA-System kurz
angesprochen, die dann in den folgenden Kapiteln genauer dargestellt werden. Kapitel 6 stellt die Erweiterung der ARTA II-Triggersprache vor. Dabei wird auf die
neue Syntax und die damit verbundenen semantischen Änderungen der Sprache
eingegangen. Kapitel 7 beschäftigt sich mit der ARTA II-System-architektur und
Kapitel 8 schließlich mit der Umsetzung der grafischen Benutzerschnittstelle
(GUI).
2
Erweiterungskonzepte für das aktive DBMS
Aktive Datenbanken
Kapitel 1 Aktive Datenbanken
Aktive Datenbanken
In diesem Abschnitt wird erläutert, was eine aktive Datenbank ist. Nach einer kurzen Motivation werden die aktiven (ECA)-Regeln eingeführt, welche das grundlegende Paradigma einer aktiven Datenbank bilden.
Programm 1
Programm 2
…
Programm n
DBMS (Datenbankverwaltungssystem)
DB 1
(Datenbank)
DB 2
(Datenbank)
DB n
(Datenbank)
DBS (Datenbanksystem)
Abbildung 1.1: Architektur eines Datenbanksystems
Datenbanksysteme (engl. Database Systems, abgek. DBS) ermöglichen eine integrierte Verwaltung aller Daten in einer Organisation. Ein Datenbanksystem besteht
aus einer Datenbank und einem Datenbankverwaltungssystem.
Eine Datenbank (engl. Database, abgek. DB) wird als eine Sammlung von Daten,
die aus der Sicht des Benutzers zusammen gehören, bezeichnet. Ein Datenbankverwaltungssystem (engl. Database Management Systems, abgek. DBMS) hat die
Aufgabe, die Daten der Datenbank so zu verwalten, daß logische und physische
Datenunabhängigkeit, Datenintegrität, Datensicherheit und weitestgehende Redundanzfreiheit bestehen. [NiJo92]
Eine Datenbank heißt aktive Datenbank, wenn sie, zusätzlich zu den Leistungen
passiver Datenbanksysteme, Ereignisse erkennen und automatisch mit vordefinierten Aktionen darauf reagieren kann. Dazu benötigt man aktive Regeln, die bei bestimmten Ereignissen ausgelöst werden. Die Ereignisse, auf die durch aktive Regeln reagiert werden kann, sind ein wichtiger Bestandteil dieses Kapitels.
Am folgenden vereinfachten Beispiel einer Sekretärin des Prüfungsamtes, die mit
Hilfe eines Datenbanksystems über den aktuellen Stand der Abgabefristen für Diplomarbeiten Buch führt, soll das aktive Datenbanksystem motiviert werden.
3
Erweiterungskonzepte für das aktive DBMS
Aktive Datenbanken
1.1 Motivierende Beispiele
Meldet ein Student seine Diplomarbeit an, so müssen zunächst eine große Anzahl
an Bedingungen überprüft werden, wie z.B.:
• hat dieser Student die Zulassung, um eine Diplomarbeit anzumelden? oder
• hat dieser Student schon eine Diplomarbeit angemeldet?
Das Datenbanksystem sollte solche Situationen erkennen und die passenden Regeln
auslösen, um mitzuteilen, ob eine Bedingung verletzt wurde. Dies setzt voraus, daß
das System automatisch bestimmte Ereignisse, wie das Anmelden einer Diplomarbeit, erkennen und darauf reagieren kann. Mit einem passiven Datenbanksystem
können Situationen dieser Art nicht erkannt werden, da ein solches System nicht
über aktive Regeln verfügt. D.h. es enthält keine Mechanismen, mit denen Situationen erkannt und entsprechende Reaktionen ausgeführt werden können. Um dennoch ein solches Verhalten realisieren zu können, müssen Programme auf Applikationsebene geschrieben werden, die mit dem DBS kommunizieren. Dabei treten die
zwei folgenden Nachteile ein:
Jedes Anwendungsprogramm, das die Anmeldung einer Diplomarbeit registriert,
muß um zusätzliche Prozeduren erweitert werden, die bei einer Anmeldung sämtliche Regeln der DPO (Diplomprüfungsordnung) überprüft und bei einer Verletzung
eine entsprechende Aktion ausführt. Die Aktualisierungen der DB wird somit von
Anwendungsprogrammen übernommen, d.h. daß das die aktiven Regeln nicht im
Datenbanksystem, sondern in den Anwendungsprogrammen implementiert wurden.
Die Nachteile dieser Arbeitsweise werden bei der Änderung einer Regel bewußt.
Es entsteht ein sehr hoher Verwaltungsaufwand, da das Ändern einer Regel in allen
Anwendungsprogrammen stattfinden muß, die auf die gleiche Datenbank zugreifen. Dies setzt wiederum voraus, daß man alle Regeln für alle Anwendungen kennt,
da dem Datenbanksystem selbst diese Regeln nicht bekannt sind und es somit den
inkonsistenten Zustand nicht erkennen kann. Ein weiterer Nachteil betrifft die Situationserkennung:
Ein Mitarbeiter des Prüfungsamtes möchte über die Überschreitung der Abgabefrist
einer Diplomarbeit informiert werden. Diese Situation kann in einem passiven Datenbanksystem nur dann erkannt werden, wenn ein Mitarbeiter eine manuelle Anfrage oder wenn ein Anwendungsprogramm regelmäßige Anfragen an die Datenbank tätigt. Dieses Abfragen des Datenbankzustandes nennt man polling. Bei diesem Verfahren besteht die Gefahr, daß diese Anfragen entweder zu häufig oder zu
selten stattfinden. Finden sie zu häufig statt, führt dies zu einer unnötigen Belastung des Systems. Geschehen die Anfragen zu selten, so kann es vorkommen, daß
die Situation zu spät bemerkt wird und die erforderliche Aktion dadurch zu lange
unterbleibt. [DiGa00]
Da in der Datenbank üblicherweise viele Informationen für die Beschreibung von
Situationen, die zur Ausführung von Folgeaktionen führen, vorhanden sind, liegt es
nahe, das Erkennen von Situationen durch das Datenbanksystem selbst anzustreben. Dafür muß das System um eine aktive Komponente erweitert werden. Eine
4
Erweiterungskonzepte für das aktive DBMS
Aktive Datenbanken
anerkannte Definition des Begriffes aktives Datenbanksystem existiert nicht. Die
folgende grobe Definition stammt aus [DiGa00].
Ein Datenbanksystem heißt aktiv, wenn es, zusätzlich zu den üblichen DBS - Fähigkeiten, in der Lage ist, interessante Situationen in der Datenbank (und wenn
möglich darüber hinaus) zu erkennen und als Folge davon bestimmte (ebenfalls
definierbare) Reaktionen auszulösen. [DiGa00]
Aus dieser Definition geht hervor, daß ein aktives Datenbanksystem (Active Database System, abgek. ADBS) die Funktionalität eines passiven Datenbanksystems
enthält,
das
um
aktive
Regeln
erweitert
wurde.
Das
aktive
Datenbankverwaltungssystem (Active
Database Management System, abgek. ADBMS) ist die Software für Verwaltung
und Benutzung der aktiven Datenbank (Active Database, abgek. ADB). ADBS ist
ein ADBMS samt (mindestens) einer ADB. Für ein Datenbanksystem ist die Eigenschaft „aktiv“ orthogonal zu seinem zugrunde liegenden Datenmodell; demzufolge kann man von aktiven relationalen Datenbanksystemen sprechen.
Die Definition des aktiven Verhaltens geschieht mit Hilfe der Situations–, Aktionsregeln, die beschreiben, wie beim Eintreten einer bestimmten Situation reagiert
werden muß. Als Beispiel soll die oben erwähnte Überprüfung der Fristen zur Abgabe einer Diplomarbeit dienen.
• Situation: Die Abgabefrist wurde überschritten.
• Aktion: Erstellung einer E-Mail für den betreffenden Studenten.
Im folgenden Abschnitt werden die Situations-, Aktionsregeln (ECA-Regeln) vorgestellt.
1.2 Regelparadigma
Konventionelle DBMS, wie z.B. Microsoft Access, sind passive DBMS. Bei diesen
passiven Systemen werden Datenbankänderungen nur als Reaktion auf eine ausgelöste Operation eines Anwenders oder einer Anwendung ausgeführt. Soll die Datenbank aber automatisch auf bestimmte vordefinierte Ereignisse reagieren können, so muß das passive Datenbankverwaltungssystem um die Möglichkeit erweitert werden, zur Laufzeit selbstständig auf eine bestimmte eintretende Situation mit
einer festgelegten Aktion reagieren zu können.
Die Situationsüberwachung kann mittels Ereignis-Bedingung-Aktion-Regeln (engl.
Event, Condition, Action, abgek. ECA) realisiert werden. Eine ECA-Regel kann
als Tripel (E, C, A) modelliert werden, wobei E, C und A die Regelkomponenten
wie folgt bezeichnen:
• E: (event), der Ereignisteil spezifiziert das auslösende Ereignis, bei dessen
Auftreten die Regel gefeuert wird.
5
Erweiterungskonzepte für das aktive DBMS
Aktive Datenbanken
• C: (condition), der Bedingungsteil drückt eine Vorbedingung für das Ausführen der Regel aus. Ereignis und Bedingung spezifizieren eine Situation.
• A: (action), der Aktionsteil enthält den eigentlichen, auszuführenden Code,
der die Reaktion auf die eintretende Situation darstellt.
1.3 Regelspezifikation
Im folgenden Abschnitt geht es um die Abgrenzung der drei Komponenten einer
Regel. Diese finden sich im Abschnitt Regelausführung wieder.
Ereignisteil
Im Ereignisteil einer ECA-Regel können verschiedene Ereignistypen angegeben
werden. In diesem Abschnitt soll eine Übersicht über die verschiedenen
Ereignistypen in aktiven Datenbanken gegeben werden. Dazu soll zunächst auf das
obige Beispiel „Ein Student meldet seine Diplomarbeit an“ eingegangen werden.
Das Ereignis das hier eintritt, ist die Anmeldung der Diplomarbeit und entspricht
dem Typ der Änderungsereignisse. Das Ereignis könnte sich aber auch auf einen
Zeitpunkt beziehen wenn man die Abgabefrist einer Diplomarbeit in Betracht zieht.
Das Ereignis könnte lauten: „die Abgabefrist der Diplomarbeit läuft am
09.04.2004 um 10:00 Uhr ab“. Dieses Ereignis entspricht einem Zeitereignistyp.
Diese Ereignisse beschreiben interessante Situationen. Zudem kann eine interessante Situation auch durch die Kombination mehrerer anderer Situationen entstehen. Kommen wir zunächst zu einer groben Definition von Ereignis:
Unter einem Ereignis versteht man das signalisierte Auftreten eines internen oder
externen Zustandes in Form eines Zeitpunktes, einer Datenbankoperation oder
eines Anwendungssignals. Man unterscheidet in der Regel zwischen einfachen und
den zusammengesetzten Ereignissen. [DiGa00]
Unter einem einfachen Ereignis versteht man ein Datenbank- oder ein Zeitereignis. Diese Ereignistypen können wiederum in verschiedene Untertypen unterteilt
werden. So können Datenbankereignisse in Änderungs- oder Transaktionsereignisse unterteilt werden. Bei den Zeitereignissen werden die Untertypen relative, absolute und periodische Zeitereignisse unterschieden.
6
Erweiterungskonzepte für das aktive DBMS
Aktive Datenbanken
Ereignisse
zusammengesetzte
Ereignisse
einfache Ereignisse
Datenbankereignisse
Transaktionsereignisse
Zeitereignisse
Änderungsereignisse
…
begin trans
insert
end trans
delete
rollback
update
absolute
Zeitereignisse
periodische
Zeitereignisse
relative
Zeitereignisse
Abbildung 1.2: Ereignistypen
Mit Änderungsereignissen läßt sich der Zustand einer Datenbank verändern. Das
Löschen, Einfügen und Ändern kann mittels der Änderungsoperatoren insert,
delete oder update realisiert werden. Zu den Datenbankereignissen gehören aber
auch Transaktionsereignisse, die durch Transaktionsbefehle ausgelöst werden
(transaction begin, transaction end), sowie z.B. das An- und Abmelden eines Benutzers an einer Datenbank. Weitere Datenbankereignisse, die zur Auslösung einer
Regel führen können, sind z.B. Aufrufe einer Prozedur oder einer Funktion in
einer Datenbankprogrammiersprache.
Zeitereignisse sind weitere atomare Ereignistypen, die zur Auslösung einer Regel
führen können. Sie werden in drei Untertypen unterteilt: In periodische (alle 5
Stunden), absolute (am 20.07.2004 um 09:00 Uhr) oder relative Zeitereignisse
(alle 2 Stunden nach dem Löschen einer bestimmten Tabelle),
Die atomaren Ereignistypen zählen zu den einfachen Ereignissen. Neben den bisher
beschriebenen einfachen Ereignissen, gibt es die komplexen (zusammengesetzten) Ereignisse, die aber in dieser Arbeit nicht weiter behandelt werden und deshalb nur vollständigkeitshalber erwähnt werden. Bei zusammengesetzten Ereignissen werden zwei oder mehrere atomare Ereignisse mittels der
Kompositionsoperatoren Sequenz, Disjunktion, Konjunktion, Negation und Reduktion kombiniert. Diese können wiederum aus der Kombination weiterer zusammengesetzter Ereignisse bestehen. [Modic00]
Ein interessanter Aspekt, was die zusammengesetzten Ereignisse betrifft, ist die
Erkennung des Auftretens eines komplexen Ereignisses. Wichtig dabei ist das
Erkennen der Reihenfolge für das Eintreten der atomaren Ereignisse. Dazu könnte
eine Protokolldatei geführt werden, in welcher der Eintrittszeitpunkt und weitere
Parameter verzeichnet werden. Bei der Erkennung zusammengesetzter Ereignisse
treten zudem verschiedene Fragen in Bezug auf den Ereignisverbrauch
auf.[Modic00]
7
Erweiterungskonzepte für das aktive DBMS
Aktive Datenbanken
Bedingungsteil
Durch die Angabe einer Bedingung kann der aktuelle Datenbankzustand auf bestimmte Eigenschaften hin überprüft werden. Die Bedingung wird dann ausgewertet, wenn die Regel ausgelöst wurde, d.h. wenn das Ereignis eingetreten ist. In einigen Systemen ist das Weglassen des Bedingungsteils erlaubt, was zur Folge hätte,
daß eine Regel nach Eintritt des auslösenden Ereignisses immer gefeuert würde.
Eine Bedingung kann z.B. eine Datenbankanfrage, ein Datenbankprädikat oder
eine Anwendungsprozedur sein.
• Bei einer Datenbankanfrage handelt es sich um eine Anfrage in der zugehörigen Anfragesprache, die entweder eine leere oder nicht leere Antwort
liefert.
• Bei einem Datenbankprädikat wird ein Datenbankzustand überprüft (z.B.
eine WHERE Klausel in SQL). Die am schwersten zu kontrollierenden aber
auch ausdrucksstärksten Beschreibungsarten in der Bedingung sind die Anwendungsprozeduren, die analog zu den Datenbankprädikaten einen Boole’schen Wert (TRUE oder FALSE) oder analog zu den Datenbankanfragen
leere oder nicht leere Datenmengen zurückgeben.
• Die Anwendungsprozeduren werden in der Anwendungsprogrammiersprache des zugrundeliegenden Systems in Form von Prozeduren oder Modulen geschrieben.
Aktionsteil
Im Aktionsteil wird definiert, wie auf eine bestimmte Situation (Ereignis und Bedingung) reagiert werden soll. Der Aktionsteil kann aus mehreren Anweisungen
bestehen, wie z.B. Datenmanipulationsoperationen, Datenbankbefehlen und Anwendungsprozeduren. Der Aktionsteil wird nach Eintreten eines Ereignisses und
nach Erfüllung einer Bedingung ausgeführt.
1.3.1
Regelausführung
Bei der Regeldefinition können gewisse Semantiken spezifiziert werden, die bei
der Aktionsverarbeitung zu berücksichtigen sind. Beispiele dafür sind, Prioritäten,
mit denen eine Verarbeitungsreihenfolge festgelegt werden kann, sowie auch
Kopplungsmodi, welche die Ausführung in Bezug auf Transaktionen1 beschreiben.
Daneben muß das Ausführungsmodell auch Mechanismen beinhalten, mit denen
Probleme, wie die Terminierung und die Reihenfolge der Regelverarbeitung
(conflict resolution), behandelt werden. Ein Überblick über solche Konstrukte wird
in den folgenden Abschnitten gegeben.
1
Bezeichnung für eine Folge von Datenbankoperationen, die einen bezüglich bestimmter Bedingungen zulässigen Übergang von einem zulässigen DB-Zustand wieder in einen zulässigen DBZustand bewirkt und nur als Einheit wirksam werden kann.
8
Erweiterungskonzepte für das aktive DBMS
Aktive Datenbanken
Auslösungszeitpunkte
Wird der Aktionsteil einer Regel gefeuert, so kann man in der Datenbank zwei
Zeitpunkte beobachten Einmal den Zeitpunkt vor (Pre-Zeitpunkt) und einmal den
nach (Post-Zeitpunkt) der Änderung des Datenbankzustandes. Es ist daher bei einem aktiven Datenbanksystem sinnvoll auf beide Auslösezeitpunkte reagieren zu
können.
Auslösungsgranularität
Da bei der Ausführung von Befehlen häufig auf mehrere Datensätze zugegriffen
wird, kann es sinnvoll sein, zwischen zwei verschiedenen Auslösegranularitäten
unterscheiden zu können. Instanzorientierte Regeln (instance-oriented) werden
für jeden betroffenen Datensatz einmal ausgeführt, während mengenorientierte
Regeln (set-oriented) einmal pro Befehl ausgeführt werden, egal auf wie viele Datensätze der Befehl zugreift.
Prioritäten
Bei der Ausführung einer Regel kann es vorkommen, daß durch ein Ereignis mehrere Regeln gleichzeitig gefeuert werden. Mit der Angabe einer Priorität für jede
Regel, kann eine Konfliktsituation, was die Reihenfolge der Abarbeitung betrifft,
vermieden werden.
Reihenfolge
Natürlich wäre es schön bei einer Konfliktsituation die Reihenfolge der Verarbeitung mit anzugeben. Es stellt sich die Frage, ob die gleichzeitig gefeuerten Trigger
nacheinander (sequentiell) oder vielleicht sogar nebeneinander (parallel) abgearbeitet werden sollen. Die sequentielle Lösung könnte mittels Datensperren verwirklicht werden, während die parallele Lösung entsprechende Funktionalität an das
ADBS fordert.
Kopplungsmodi [Mos85]
In einem aktiven Datenbanksystem werden Regeln nach Eintritt eines auslösenden
Ereignisses gefeuert. Der Zeitpunkt, zu dem diese Regel gefeuert wurde, muß jedoch nicht dem Zeitpunkt der Abarbeitung der Regel entsprechen. Manchmal ist es
sinnvoll, die Regelverarbeitung erst am Ende der regelauslösenden Transaktion
durchzuführen. Beim Anlegen einer Regel können zwei Arten von Kopplungen
angegeben werden. Diese kann entweder zwischen Ereignis und Bedingung (ECKopplung) oder zwischen Bedingung und Aktion (CA-Kopplung) angegeben
werden. Mit EC-Kopplung wird die zeitliche Beziehung zwischen dem Auftreten
eines regelauslösendem Ereignisses (E) und der Auswertung ihrer Bedingung (C)
beschrieben. Mit CA-Kopplung wird die zeitliche Beziehung zwischen der Auswertung der Bedingung (C) und der Ausführung der Aktion (A) beschrieben. Bei beiden Kopplungsarten können drei verschiedene Modi angegeben werden. Anhand
einer EC-Kopplung sind hier exemplarisch drei Möglichkeiten dargestellt.
9
Erweiterungskonzepte für das aktive DBMS
Aktive Datenbanken
• Immediate (sofort): die Bedingungsauswertung erfolgt in der gleichen
Transaktion unmittelbar nach dem Eintritt des Ereignisses.
• Deferred (verzögert): Die Bedingungsauswertung erfolgt in der gleichen
Transaktion, jedoch nach dem letzten Befehl und bevor die Transaktion in
die Datenbank festgeschrieben wird.
• Decoupled (getrennt): Die Bedingung wird in einer separaten Transaktion
ausgewertet. Es besteht keine Abhängigkeit zwischen den beiden Transaktionen.
Terminierung
In aktiven Datenbanksystemen können Regeln spezifiziert sein, die sich gegenseitig auslösen. Die Verarbeitung kann daher zu Regelkaskaden führen, da eine Regel
eine oder mehrere andere Regeln auslöst und jede dieser Regeln wiederum eine
oder mehrere Regeln auslöst usw. Einen Spezialfall dieser Kaskaden stellen Zyklen
dar, die eine Regel enthalten, die entweder direkt oder indirekt immer wieder ausgelöst wird. Ein solches Verhalten kann von den Benutzern gewollt sein. Jedoch
muß sichergestellt sein, daß Zyklen immer terminieren. Dieses Problem kann in
aktiven Datenbanksystemen auf verschiedene Arten gelöst werden. Eine triviale
Lösung besteht darin, daß keine Regeln definiert werden dürfen, die einen Zyklus
bilden.
Reihenfolge der Regelverarbeitung (conflict resolution)
Mit diesem Begriff wird das Problem der Verarbeitungsreihenfolge bezeichnet.
Durch
das Eintreten eines Ereignisses können mehrere Regeln ausgelöst werden, die zu
verarbeiten sind. Es stellt sich daher die Frage: „Welche Regel soll zuerst, welche
Regel danach usw. ausgeführt werden?“ Dieses Problem muß in aktiven Datenbanksystemen behandelt werden. Eine Möglichkeit besteht darin, daß das System
die Regeln in einer willkürlich festgelegten Reihenfolge verarbeitet.
Verbrauch von Ereignissen
Wenn eine Regel bearbeitet wird, d.h. ihre Bedingung ausgewertet und/oder ihre
Aktion ausgeführt wird, werden die sie auslösenden Ereignisse auf verschiedene
Arten behandelt, die als Ereignisverbrauchsmodi (event consumption modes) bezeichnet werden. Dabei sind zwei Aspekte von Bedeutung. Zum einen, ob die bearbeiteten Ereignisse ihre auslösende Wirkung auf Regeln beibehalten und zum
anderen, falls sie diese verlieren, wann die Wirkung erlischt, d.h. sozusagen das
Ereignis verbraucht wird. [ToPy98]
10
Erweiterungskonzepte für das aktive DBMS
Microsoft Access
Kapitel 2 Microsoft Access
Microsoft Access - ein relationales DBMS
Microsoft Access (abgek. MS-Access) [MS-A00] ist ein Vertreter der sogenannten
relationalen Datenbankverwaltungssysteme (Relational Database Management
System, abgek. RDBMS). In einem relationalen Datenbankverwaltungssystem
werden Daten als eine Menge von zweidimensionalen Tabellen gespeichert. Die
Tabellen bestehen aus einer festen Anzahl von Spalten und einer beliebigen Anzahl
von Zeilen. Jede Spalte einer Tabelle repräsentiert ein Attribut des Relationsschemas und jede Zeile entspricht einer spezifischen Instanz dieses Schemas, also einem Datensatz. Die Daten in diesen Tabellen werden mit Hilfe der strukturierten
Anfragesprache SQL (engl. Structured Query Language) manipuliert. SQL ist eine
standardisierte Sprache zur Definition und Manipulation von Daten in einer relationalen Datenbank.
MS-Access ist für die Verwaltung großer Datenbestände entwickelt worden. Neben
dieser Eigenschaft zeichnet sich MS-Access jedoch besonders durch die sehr leicht
zu bedienenden Oberflächen aus, die die Bearbeitung und Repräsentation von Daten gegenüber den klassischen RDBMS deutlich vereinfacht.
2.1 Architektur von Microsoft Access
Das Datenbanksystems Microsoft Access besteht aus drei funktionellen Komponenten:
• Dem Datenbankverwaltungssystem, das die Datenbestände auf der Festplatte verwaltet.
• Der Benutzeroberfläche, die als Schnittstelle zwischen Anwender und Datenbankverwaltungssystem den Zugriff auf die Daten und deren Präsentation erlaubt.
• Das VBA-System (Visual Basic for Application), welche die Programmierung von eigenen Anwendungen mit eigenen Benutzeroberflächen ermöglicht.
Darüber hinaus wird mit dem Datenbanksystem eine JET-Datenbank-Engine (siehe
Unterkapitel 2.2.2) zur Verfügung gestellt, um eine Verbindung zwischen den Datenbanken herzustellen. Dieser Datenmanager kommuniziert mit Objektschnittstellen wie DAO (Data Access Object), ADO (ActiveX Data Objects) und ODBC
(Object Database Connectivity). Die JET-Datenbank-Engine ist ein Teil des
Microsoft Access Datenbanksystems und liegt in Form von Systemdateien vor,
welche über ihre DAO-Objektschnittstelle angesprochen werden. Neben der DAOSchnittstelle werden ODBC, OLE-DB und in der neuesten Version auch ADO unterstützt. Die JET-Datenbank-Engine ist somit der Teil des Microsoft Access Da11
Erweiterungskonzepte für das aktive DBMS
Microsoft Access
tenbanksystems, der Daten aus Benutzer- und Systemdatenbanken abruft bzw. darin speichert. Sie kann als Datenmanager aufgefaßt werden.
2.2 Komponenten einer Datenbankanwendung
Nach dem Start einer neuen MS-Access-Anwendung wird das Datenbankfenster
eingeblendet. Es ist das Hauptfenster dieses Systems und stellt die Schaltzentrale
dar. Das Datenbankfenster dient der Übersicht über die Anwendungskomponenten.
In MS-Access bezeichnet man alles, was benannt werden kann, als Objekt. So besteht eine Microsoft Accessdatenbank aus verschiedenen Objekten, die man einem
bestimmten Objekttyp zuordnen kann. Aus dem Zusammenspiel dieser Objekte
wird aus einer Datenbank eine Anwendung erstellt. Die Hauptobjekte einer AccessDatenbank sind Tabellen, Abfragen, Formulare, Berichte, Datenzugriffsseiten,
Makros und Module. Im folgenden werden diese Komponenten in einfacher Form
vorgestellt, da eine detaillierte Erläuterung den Rahmen der Arbeit sprengen würde.
Datenbankkomponenten
ausgewählte Registerkarte
Liste der Tabellen in der Datenbank
Abbildung 2.1: Datenbankfenster
Alle Daten werden in Tabellen gespeichert. Alle anderen Objekte der Datenbank
greifen auf diese Tabellen zu, um die dort gespeicherten Daten bearbeiten, ergänzen,
löschen oder anzeigen zu können. Ein Datensatz dieser Tabellen bildet dabei ein Objekt aus der Wirklichkeit ab. Die dazugehörigen Datenfelder enthalten die relevanten Eigenschaften des Objekts. Für jede Tabelle kann ein Primärschlüssel (bestehend aus einem oder mehreren Feldern einer Tabelle) und einem Index (oder meh12
Erweiterungskonzepte für das aktive DBMS
Microsoft Access
reren Indizes) definiert werden. Der Primärschlüssel dient der eindeutigen Identifizierung des Datensatzes und der Index (oder mehrere Indizes) dem schnelleren
Zugriff auf diesen.
Abfragen sind Objekte, mit denen eine individuelle Auswahl der Daten aus einer
oder mehreren Tabellen ermöglicht wird. Eine Abfrage kann unter Microsoft Access auf zwei Weisen realisiert werden. Entweder mit SQL-Befehlen in einem speziellen SQL-Ansichtsfenster oder in einem Entwurfsansichtsfenster. In der Entwurfsansicht bedient man sich der QBE-Funktion (Query By Example). Die Abfragen werden hier mit den Möglichkeiten der graphischen Benutzeroberfläche
entworfen. Beim Wechsel in die SQL-Ansicht werden die QBE-Funktionen automatisch in SQL-Befehle übersetzt, so daß man beide Möglichkeiten gemeinsam bei
der Entwicklung einer Abfrage nutzen kann.
Formulare sind mit die interessantesten Objekte die Microsoft Access zu bieten
hat. Sie dienen im wesentlichen der Dateneingabe und Datenanzeige, sowie der
Steuerung von Programmausführungen. Ein Formular kann an einer Datenbankquelle (z.B. an eine Tabelle oder eine Abfrage) gebunden werden, um die Daten
benutzergerecht darzustellen und um die Dateneingabe zu kontrollieren. Formulare
können als Reaktion auf ein beliebiges Ereignis aufgerufen werden und bieten die
Möglichkeit Grafiken und OLE-Objekte (Objekt Linking and Embedding) in einem Formular anzuzeigen (Kapitel 2.2.2).
Berichte ähneln Formularen. Sie dienen jedoch nicht der Datenbearbeitung, sondern der Datenanzeige. Berichte sind für die Ausgabe auf dem Medium Papier zugeschnitten. Formulare hingegen sind zugeschnitten auf die Ausgabe der Daten auf
Monitoren. Auf Berichte wird hier nicht weiter eingegangen, da sie in ARTA II
nicht verwendet werden.
Möchte man die Daten einer Access-Datenbank im Internet oder Intranet anzeigen
oder bearbeiten, so kann dies mit Hilfe der Datenzugriffsseiten verwirklicht werden. Sie sind in ihrer Zweckbestimmung mit den Formularen und Berichten verwandt. Im Gegensatz zu Formularen und Berichten werden Datenzugriffsseiten
aber nicht direkt in der Datenbank gespeichert. Wenn in Access eine Datenzugriffsseite erstellt wird, wird die entsprechende Seite außerhalb der Datenbankdatei gespeichert und in der Datenbankdatei eine Verknüpfung zu dieser externen
Datei erstellt. Im Verlauf der Arbeit wird auf diesen Punkt nicht weiter eingegangen. [JeRe02]
In einer Datenbank werden unter Umständen bestimmte Aktionen immer wieder
ausgeführt. Um diese Vorgänge zu automatisieren, können Makros verwendet
werden. Sie dienen der Steigerung der Benutzerfreundlichkeit und stellen im Grunde eine Liste von Aktionen dar, die nacheinander ausgeführt werden sollen. Prinzipiell könnten die Aktionen eines Makros auch über Menubefehle in Access ausgeführt werden. Über Makros und Module wird die Intelligenz der Datenbank entworfen. Sie sind das fehlende Glied zwischen den einzelnen Objekten der Datenbank und verbinden diese zu einer leistungsstarken Anwendung. [JeRe02]
13
Erweiterungskonzepte für das aktive DBMS
Microsoft Access
Ein Modul besteht aus selbstdefinierten Prozeduren oder Funktionen, die in VBA
erstellt wurden. Mit Hilfe der Module können Aktionen in mehrere Einzelschritte
zerlegt werden. Zudem besteht die Möglichkeit der Fehlerbehandlung, was den
wesentlichen Unterschied zu Makros darstellt. Module sind entweder eigenständige
Objekte, die von jedem Punkt der Anwendung aus aufgerufen werden können oder
Objekte, die unmittelbar mit Formularen oder Berichten verknüpft sind. Der Vorteil ist, daß sie auf Ereignisse antworten, die im Formular oder Bericht auftreten
können. [JeRe02]
Der Vollständigkeit halber seien hier die Gruppen in der Gruppenleiste erwähnt
(siehe Abbildung 2.1). Bei Gruppen handelt es sich nicht um Datenbankobjekte im
strengen Sinne. Verknüpfungen zu Datenbankobjekten können hier angelegt werden, um einen schnelleren Zugriff auf diese zu bekommen. Oft benutzte Formulare
können in Gruppen hinzugefügt werden, so daß sie stets schnell verfügbar sind.
[JeRe02]
Die folgende Abbildung verdeutlicht die Beziehungen zwischen den Objekten von
Microsoft Access. Es wurde mit Absicht auf die Datenblattansicht verzichtet, um
das Diagramm zu vereinfachen.
Definieren
Formulare, Berichte
Abfragen, Tabellen
Öffnen, Format,
Filter, Formulare,
Abfragen, Berichte
Module
Funktionen
Subroutinen
Auslöser
Öffnen/
Filter
Ausführen/
Aufrufen
Auslöser
Ausführen (Funktionen)
Druck
Ansicht
Filter
Makros
Auslöser
Auslöser
Öffnen, Format,
Filter, Formulare,
Abfragen, Berichte
Formulare
Berichte
Ausführen (Funktionen)
Abfragen
Aktion
Tabellen
Datenfluß
Abbildung 2.2: Die Hauptobjekte von Microsoft Access und ihre Beziehungen [JoVi96]
Jede Microsoft Access-Anwendung (-Datenbank) speichert die zuvor erwähnten
Anwendungskomponenten (Tabellen, Formulare, Abfragen, Berichte, Makros und
Module) in einer monolithischen .mdb-Datei (Microsoft Access Database) ab. Es
14
Erweiterungskonzepte für das aktive DBMS
Microsoft Access
ist allerdings möglich die Tabellendefinitionen (Data Dictionary) und den Datenbestand, sowie die Oberfläche in zwei verschiedenen Dateien zu halten. Dies geschieht durch eine Funktion, die zur Verknüpfung von Tabellen dient. Bei der Entwicklung von ARTA II wurden die Datenbanktabellen und das ARTA IIDatenbanksystem voneinander getrennt, was viele Vorteile mit sich bringt. Mehr
dazu in Kapitel 7.
In den folgenden Abschnitten werden die einzelnen zuvor erwähnten Anwendungskomponenten vorgestellt. Dabei werden nur die in Bezug auf das ARTASystem relevanten Komponenten erwähnt.
2.2.1
Tabellen
Eine Tabelle ist eine Auflistung von Daten zu einem bestimmten Thema, wie z.B.
Angaben zu einem Student: Name, Matrikelnummer, Semester. Wie zuvor erwähnt
repräsentiert jede Spalte einer Tabelle ein Attribut des Relationsschemas und jede
Zeile der Tabelle entspricht einem Tupel der Relation. Ein Datensatz entspricht
einem Datenbankzustand.
Entwurfs- und Datenblattansicht
Wenn die Struktur oder die Gestaltung der Tabelle verändert werden soll, so geschieht dies in der Entwurfsansicht der Tabelle. In dieser Ansicht bezeichnet jede
Zeile im oberen Teil des Tabellenfensters ein anderes Feld der Tabelle. Beim Markieren eines Feldes erscheinen im unteren Bereich die Eigenschaften zu diesem
Feld. Diese sind unterteilt in „Allgemein“ und „Nachschlagen“.
Schlüsselvergabe
Jede Zeile definiert ein Feld der Tabelle
Einstellungen für die Eigenschaften
Liste der Eigenschaften für das aktuelle Feld
Abbildung 2.3: Entwurfsansicht einer Tabelle
15
Erweiterungskonzepte für das aktive DBMS
Microsoft Access
In den allgemeinen Feldeigenschaften können Gültigkeitsregeln für die einzelnen
Felder angegeben werden. So ist es z.B. möglich bei einem Textfeld die Feldgröße
anzugeben. Bei der Verletzung einer Gültigkeitsregel kann eine vordefinierte Meldung, die unter Gültigkeitsmeldung formuliert wird, ausgegeben werden. Mit dem
Eingabeformat lassen sich Eingabehilfen erstellen. Dazu das Beispiel der Eingabe
eines Datums. Wünschenswert wäre, die Eingabe eines Datums ohne Trennpunkte
und mit Platzhaltern für Tag, Monat und Jahr (_ _. _ _ . _ _ _ _). Eine weitere hilfreiche Eigenschaft ist die Formulierung von Gültigkeitsregeln. Diese geben an,
welche Anforderungen die Eingabedaten in einem Datensatz, Feld oder Steuerelement erfüllen müssen Dazu kann ein Ausdrucksgenerator aufgerufen werden, mit
dessen Hilfe sich komplexe Ausdrücke mittels Funktionen, Konstanten und Operatoren erstellen lassen.
Interessant ist auch die zweite Seite der Feldeigenschaften „Nachschlagen“. Hier
kann angegeben werden, wie sich ein Steuerelement verhalten soll, wenn es an dieses Tabellenfeld gebunden wird. In der folgenden Abbildung sind die Einstellungen
für das Tabellenfeld Student_Hauptfach zu sehen. Ein Steuerelement, das mit diesem Feld in Verbindung steht, bekommt eine Werteliste als Datenherkunft zugewiesen. Die Werte der Liste werden durch Semikolon getrennt. In der Datenblattansicht in Abbildung 2.5 wird diese Einstellung sichtbar. Bei der Eingabe eines
Hauptfaches wird die Werteliste eingeblendet, um aus ihr einen Eintrag auswählen
zu können.
Abbildung 2.4: Zweite Seite der Feldeigenschaften
Schlüsselvergabe
Jede Tabelle einer relationalen Datenbank sollte mit einem Schlüsseln versehen
werden, um im Regelfall den Zugriff auf die in den Tabellen gespeicherten Daten
zu beschleunigen und eindeutig zu machen. Einmal definierte Schlüssel werden
von MS-Access automatisch verwendet, sofern es die Anwendung erlaubt. MSAccess ermöglicht es zwei Arten von Schlüsseln in Tabellen zu vergeben:
• Der Primärschlüssel beschleunigt den Zugriff auf die Daten in der Tabelle.
Für jede Tabelle sollte ein Primärschlüssel vergeben werden, der eine ein16
Erweiterungskonzepte für das aktive DBMS
Microsoft Access
deutige Identifikation eines jeden Datensatzes in der Tabelle ermöglicht.
Unter MS-Access kann der Primärschlüssel aus einem oder mehreren Feldern bestehen. Es kann jedoch nur einen Primärschlüssel oder zusammengesetzten Primärschlüssel in einer Tabelle geben.
• Fremdschlüssel werden von MS-Access automatisch bei der Suche oder bei
der Abfrage von Datenbeständen verwendet und können diese Prozesse erheblich beschleunigen. Unter MS-Access können Fremdschlüssel definiert
werden, die aus einem oder bis zu zehn Datenfeldern bestehen.
Bei der Vergabe von Schlüsseln unter MS-Access ist zu beachten, daß deren Pflege
während der Bearbeitung von Daten Rechenzeit, Arbeits- und Festplattenspeicher
erfordert. Schlüssel sollten daher hauptsächlich für die Felder definiert werden, die
häufig bei der Datensuche oder der Sortierung verwendet werden. Für weniger häufig auftretende Sortierreihenfolgen sollten Abfragen definiert werden. Zwar benötigen diese mehr Zeit als ein Zugriff über Schlüssel, der Zeitbedarf ist jedoch auf
einen Zeitpunkt beschränkt. Abfragen werden von MS-Access nicht ständig gepflegt und belasten somit den normalen Ablauf weniger als Schlüssel.
In der Datenblattansicht können die Daten einer Tabelle hinzugefügt, gelöscht
oder geändert werden. Jeder Datensatz, der erfaßt oder geändert wird, wird automatisch gespeichert, sobald der Cursor aus diesem Datensatz herausgenommen wird.
Abbildung 2.5: Datenblattansicht einer Tabelle
Beziehungen
Microsoft Access bietet mit dem Beziehungsfenster die Möglichkeit, Beziehungen
zwischen einzelnen Tabellen anzugeben. Interessant ist der Aspekt, daß Beziehungen ein separates Konzept und nicht Teil des Tabellenentwurfs sind. Das Beziehungsfenster kann von der Menüleiste aus geöffnet werden.
Nachdem verschiedene Tabellen zu den einzelnen Themen in der Microsoft Access-Datenbank angelegt wurden, muß Microsoft Access mitgeteilt werden, wie
17
Erweiterungskonzepte für das aktive DBMS
Microsoft Access
diese Informationen wieder zusammengeführt werden. Der erste Schritt in diesem
Prozeß besteht darin, Beziehungen zwischen ihren Tabellen zu definieren. Anschließend können Abfragen, Formulare und Berichte erstellt werden, um die Informationen aus verschiedenen Tabellen gleichzeitig anzuzeigen.
Eine Beziehung bezeichnet die Ein- oder Mehrdeutigkeit einer sinnvollen Verknüpfung von Attributen (Datenfeldern) innerhalb einer oder mehrerer Datentabellen.
Eine wichtige Rolle spielen solche Beziehungen vor allem bei der Verknüpfung
mehrerer Tabellen zu einem umfassenden Informationspool. Eine solche Verknüpfung wird in Microsoft Access durch das Einfügen eines eindeutigen Attributes
(Datenfeld) aus der Primärtabelle ermöglicht.
Abbildung 2.6: ARTA II-Anwendungsdaten in der Beziehungsansicht
Beziehungstypen
Microsoft Access kennt drei Typen von Beziehungen. Die 1:1 (eins zu eins), 1:n
(eins zu n) und die n:m (n zu m)Beziehungen.
In der 1:1 Beziehung entspricht ein Attributwert der Primärtabelle genau einem
einzigen anderen Attributwert aus der Fremdtabelle. Dies ist die einfachste und
klarste Datenbeziehung.
Eine 1:n Beziehung kennt für einen eindeutigen Ausgangswert mehrere andere
zugeordnete Werte. Sie gehört zu den häufigsten Typen von Datenbeziehungen.
Das wichtigste bei diesem Beziehungstyp ist die klare Identifizierung des eindeutigen Ausgangswertes.
Bei einer m:n Beziehung lassen sich mehrere Attributwerte mehreren Werten eines anderen Attributes zuordnen. Diese Art der Beziehung sollte nach Möglichkeit
vermieden werden, da bei einer derartig unklaren Beziehungsdefinition kaum ver18
Erweiterungskonzepte für das aktive DBMS
Microsoft Access
nünftige Auswertungen mit den Daten durchgeführt werden können. Häufig können solche Beziehungen durch zusätzliche Tabellen weiter aufgegliedert und vereinfacht werden.
19
Erweiterungskonzepte für das aktive DBMS
Microsoft Access
Referentielle Integrität
Microsoft Access bietet die Möglichkeit referentielle Integrität in Tabellen festzulegen. Dadurch wird sichergestellt, das Beziehungen zwischen Datensätzen gültig
sind und die verknüpften Daten nicht versehentlich geändert oder gelöscht werden.
Dies dient unter anderem der Aktualisierungsweitergabe und der Löschweitergabe
bei Tabellen.
Bei der Löschweitergabe werden beim Löschen eines Datensatzes in der Primärtabelle ebenfalls alle Detaildatensätze in der Detailtabelle gelöscht.
Bei der Aktualisierungsabfrage wird beim Ändern eines Primärschlüsselwertes in
der Primärtabelle der damit übereinstimmende Wert in allen Detaildatensätzen automatisch aktualisiert.
Abbildung 2.7: Fenster zum Einstellen der referentiellen Integrität
Mit der Definition der referentiellen Integrität werden gleichzeitig eine Beziehung
und eine Eingabeprüfung definiert. Ist sie erst einmal definiert, so erkennt MSAccess die relationale Verknüpfung dieser Tabellen bei der Neuanlage von Abfragen, Formularen und Berichten automatisch. Weiterhin gewährleistet MS-Access
die referentielle Integrität nun überall dort, wo Daten bearbeitet werden können.
Dies betrifft sowohl Dateneingaben in das Tabellen- und Formularfenster, als auch
beispielsweise Aktualisierungsabfragen.
2.2.2
Abfragen
Eine Abfrage dient dazu, aus den Tabellen einer Datenbank ausgewählte Felder
anzuzeigen und ggf. zu ändern. Man kann also Spalten angeben, die in die Abfrage
aufgenommen werden sollen. Außerdem können Kriterien angegeben werden, nach
denen die anzuzeigenden Datensätze ausgewählt werden. Dies erzeugt also eine
Auswahl unter den Zeilen der Tabellen. Eine Abfrage stellt somit einen Ausschnitt
aus der Datenbank dar, der entweder direkt als Datenblatt betrachtet oder als
Grundlage für einen Bericht oder ein Formular benutzt werden kann.
20
Erweiterungskonzepte für das aktive DBMS
Microsoft Access
Der für ARTA II wichtigste Abfragetyp ist die Auswahlabfrage, die der gebräuchlichste Abfragetyp ist. Sie ruft Daten aus einer oder mehrerer Tabellen ab und zeigt
die Ergebnisse in einem Datenblatt an. Dort können die Datensätze nach einer Änderung direkt aktualisiert werden. Mit einer Auswahlabfrage können auch Datensätze gruppiert und Summen, Anzahl, Durchschnittswerte und andere Werte berechnet werden. Für die Auswahlabfrage stehen verschiedene Ansichten zur Auswahl. Die wichtigsten sind die Entwurfs-, Datenblatt- und SQL-Ansicht.
In der Entwurfsansicht werden mit Hilfe der Tabellen oder abgespeicherten Abfragen neue Abfragen formuliert. Im oberen Bereich des Abfragefensters werden
die Feldlisten der Tabelle oder anderer Abfragen angezeigt, die in die Abfrage eingehen.
Abbildung 2.8: Auswahlabfrage mit Hilfe einer Tabelle (tbl_Student)
Im unteren Bereich des Abfragefensters sieht man das Entwurfsraster. Hier werden
alle für die Abfrage verwendeten Felder angezeigt. Hier können Sortier- und Auswahlkriterien eingestellt werden.
In der Datenblattansicht wird die Auswertung der Abfrage in Form eines Datenblattes angezeigt. Es werden alle Daten angezeigt, die aus der Abfrage hervorgehen. Diese Sicht dient vor allem der Überprüfung der Richtigkeit. So können einfache Fehler bei der Erstellung einer Abfrage direkt entdeckt werden. Die Datenblattansicht ähnelt sehr der Tabellenansicht mit dem Unterschied, daß der Anwender
nicht unterscheiden kann, ob die Daten aus einer oder mehrerer Tabellen stammen.
Auch hier können Daten eingegeben, geändert und gelöscht werden.
21
Erweiterungskonzepte für das aktive DBMS
Microsoft Access
Abbildung 2.9: Datenblattansicht einer Abfrage
In der SQL-Ansicht wird die SQL-Anweisung, die in der aktuellen Abfrage verwendet wird, angezeigt. Wenn eine Abfrage in der Entwurfsansicht formuliert
wurde, erstellt MS-Access im Hintergrund die entsprechende SQL-Anweisung. Die
meisten Abfrageeigenschaften im Eigenschaftsfenster der Entwurfsansicht besitzen
äquivalente Klauseln und Optionen in der SQL-Ansicht. SQL-Anweisungen können in der SQL-Ansicht bearbeitet und anzeigt werden.
Abbildung 2.10: SQL-Ansichtsfenster
Außer der Auswahlabfrage existieren noch eine Aktualisierungs-, Einfüge-, und
Löschabfrage, auf die hier nicht weiter eingegangen wird.
2.2.3
Formulare
Ein Formular ist ein Typ von Datenbankobjekt, der hauptsächlich zur Eingabe oder
Anzeige von Daten in einer Datenbank verwendet wird. Die meisten Formulare
sind an eine Datenquelle gebunden.
Die Datenquelle eines Formulars bezieht sich auf die Felder in den zugrunde liegenden Tabellen oder Abfragen. Als Datenquelle kann auch eine SQL-Anweisung
dienen. Ein Formular muß nicht alle Felder der Datenquelle enthalten, sondern
kann auch gefilterte Daten anzeigen.
Wie zuvor erwähnt werden in einem gebundenen Formular alle Daten aus der
zugrunde liegenden Datenquelle zur Verfügung gestellt. Zusätzliche Informationen
zum Formular, wie z. B. Titel, Datum oder grafische Elemente, sind in dem Entwurf des Formulars gespeichert.
22
Erweiterungskonzepte für das aktive DBMS
Microsoft Access
Entwurfsansicht eines Formulars
Möchte man das Design, die Datenquelle oder andere Objekte bezüglich des Formulars ändern, so muß das Formular in der Entwurfsansicht geöffnet werden, siehe
folgende Abbildung.
Schaltfläche Toolbox
Schaltfläche Feldliste
Eigenschaftsfenster
Schaltfläche Eigenschaft
Formular in
Entwurfsansicht
Feldlistenfenster
Symbolleiste
Toolbox
Abbildung 2.11: Das Formular Usys_frm_Trigger_CreateModify in der Enwurfsansicht
Die Toolbox ist das Kontrollzentrum der Formulargestaltung. Mit diesem Werkzeug werden bei der Erstellung des Formulars alle notwendigen Steuerelemente zur
Verfügung gestellt.
Steuerelemente sind Objekte, die im Formular eingebunden werden können, um
Daten anzuzeigen, zu verändern oder sogar zu löschen. Außerdem kann man mit
Steuerelementen, wie Linien oder Rechtecke, die Formulare grafisch aufbereiten,
um z.B. Daten strukturierter darstellen zu können.
Die Feldliste ist ein Fenster, in welchem alle verfügbaren Felder einer zuvor mit
dem Formular gebundenen Datenquelle, angezeigt werden können. Per Drag &
Drop kann man ein Feldelement in das Formular integrieren. Beim Wechsel von
der Entwurfs- in die Formularansicht erscheint dann an dieser Stelle der Inhalt des
Feldes der Tabelle.
23
Erweiterungskonzepte für das aktive DBMS
Microsoft Access
Um die Eigenschaften eines Steuerelementes zu ändern, ruft man das Eigenschaftsfenster auf. Das Eigenschaftsfenster zeigt immer die Werte für das aktuell
ausgewählte Steuerelement im Formularfenster an. Allein durch die immensen Einstellungsmöglichkeiten für jedes Steuerelement kann man eine Anwendung erstellen, ohne auch nur eine einzige Zeile Programmiercode zu schreiben. Über das Eigenschaftsfenster können sogar Gültigkeitsregeln festgelegt werden, so daß Daten
bei der Eingabe direkt auf ihre Richtigkeit hin überprüft werden können. Im Eigenschaftsfenster findet man den Reiter „Ereignis“, hier können Makros oder Ereignisprozeduren hinterlegt werden.
In Formularen und Berichten stellt Microsoft Access über 40 Ereignisse zur Verfügung, die Makros oder Ereignisprozeduren2 auslösen können. Ein Ereignistyp für
ein Steuerelement könnte z.B. On_Click (bei Mausklick) lauten. Eine entsprechende Reaktion auf den Mausklick könnte das Schließen des aktiven Fensters sein.
Wichtig zu wissen ist auch die Reihenfolge, mit der Ereignisse abgearbeitet werden. Im folgenden ist die Ereignisreihenfolge für ein Formular, vom Öffnen bis
zum Schließen, dargestellt.
Open ⇒ Load ⇒ Resize ⇒ Activate ⇒ Current.
So können, z.B. beim Öffnen eines Formulars, VBA-Prozeduren oder Makros ausgeführt werden, bevor das Formular aktiviert und mit Daten gefüllt wird.
Steuerelemente
Steuerelemente sind ein wichtiges Hilfsmittel, um z.B. eine Verknüpfung zwischen
einem Formular und seiner Datenquelle herzustellen. Der am häufigsten zur Anzeige und Eingabe von Daten verwendete Steuerelementtyp ist das Textfeld. Steuerelemente sind Objekte der grafischen Benutzeroberfläche. Es gibt in MS-Access
eine große Anzahl an Steuerelementen, wie z.B. das Textfeld, das Kontrollkästchen, die Bildlaufleiste oder die Befehlsschaltfläche. Sie dienen der Steuerung des
Programms durch den Benutzer. Mit Hilfe von Steuerelementen können Daten
bzw. eine Auswahl von Daten, angezeigt und verändert werden. Ein großer Vorteil
ist zudem die Möglichkeit Aktionen im Hintergrund auszulösen. So kann auf bestimmte Situationen reagiert werden, ohne daß der Benutzer etwas davon erfährt.
Ein weiterer Vorteil für die Benutzung von Steuerelementen ist, daß die Lesbarkeit
der Benutzeroberfläche deutlich vereinfacht wird.
Microsoft Access enthält folgende Steuerelementtypen, auf die in der Entwurfsansicht eines Formulars zugegriffen werden kann: Textfeld, Bezeichnungsfeld, Optionsgruppe, Optionsfeld, Kontrollkästchen, Listenfeld, Befehlsschaltfläche, Registersteuerelement, Bild-Steuerelement, Linie, Rechteck sowie benutzerdefinierte
2
Eine Prozedur ist eine Einheit von Microsoft Visual Basic-Code. Sie enthält eine Reihe von
Anweisungen und Methoden, die eine Operation durchführen oder einen Wert berechnen.
24
Erweiterungskonzepte für das aktive DBMS
Microsoft Access
ActiveX-Steuerelemente. Hier werden nur kurz die Text-, Listen-, Kombinationsfelder und das Registersteuerelement vorgestellt.
25
Erweiterungskonzepte für das aktive DBMS
Microsoft Access
Textfelder
Textfelder dienen der Anzeige und Eingabe von Daten einer Datenquelle in einem
Formular. Dieser Textfeldtyp wird als gebundenes Textfeld bezeichnet, da es an
Daten eines Feldes gebunden ist. Textfelder können auch ungebunden sein. Beispielsweise kann ein ungebundenes Textfeld erstellt werden, um das Ergebnis einer
Berechnung anzuzeigen oder Benutzereingaben aufzunehmen. Daten in einem ungebundenen Textfeld werden nicht in einer Tabelle gespeichert.
Listenfelder
Es ist oftmals leichter und schneller einen Wert aus einer Liste auszuwählen, als
ihn einzugeben. Dies kann mit Hilfe einer Auswahlliste realisiert werden, die außerdem sicherstellt, daß der Wert, der in ein Feld eingegeben wurde, korrekt ist.
Falls auf dem Formular genügend Platz vorhanden ist, um die Liste ständig anzuzeigen, kann ein Listenfeld verwendet werden. Wenn ein Steuerelement erstellen
werden soll, welches eine Liste anzeigen und wenig Platz einnehmen soll, so verwendet man ein Kombinationsfeld.
Abbildung 2.12: Listenfeld
Die Liste eines Listenfeldes besteht aus Datenzeilen. In einem Formular kann ein
Listenfeld aus einer oder mehreren Spalten bestehen, die mit oder ohne Überschriften angezeigt werden können. Wenn ein mehrspaltiges Listenfeld gebunden ist,
speichert MS-Access die Werte aus einer der Spalten in die Datenquelle.
Kombinationsfelder
Ein Kombinationsfeld ist eine Kombination aus Textfeld und Listenfeld und nimmt
folglich wenig Platz ein. Neue Werte können über das Kombinationsfeld eingegeben werden und Werte können aus einer Liste ausgewählt werden. Die Liste eines
Kombinationsfeldes besteht aus Datenzeilen. Diese Zeilen wiederum können aus
einer oder mehreren Spalten bestehen, die mit oder ohne Überschriften angezeigt
werden können.
26
Erweiterungskonzepte für das aktive DBMS
Microsoft Access
Abbildung 2.13: Kombinationsfeld, das mit allen verfügbaren Tabellen verbunden ist
Registersteuerelemente
Mit diesem Steuerelement kann ein Formular oder ein Dialogfeld erstellen werden,
das mehrere Seiten mit je einer Registerkarte enthält. Jede Registerkarte weist dabei ähnliche Steuerelemente auf, wie z. B. Textfelder oder Optionsfelder. Sobald
ein Benutzer auf eine Registerkarte klickt, wird die zugehörige Seite zur aktiven
Seite.
Abbildung 2.14: Registerkartensteuerelement
2.2.4
Makros
Makros bezeichnen eine Reihe von Aktionen, die zur Automatisierung von häufig
vorkommenden Aufgaben erstellt werden. Mit Hilfe von Makrogruppen können
mehrere Aufgaben gleichzeitig ausführt werden. Gegenüber Lösungen die mittels
VBA erstellt werden, haben Makros mehrere Nachteile. So ist z.B. ein vernünftiges
Zusammenspiel der Abfrage genausowenig möglich, wie auf Fehler zu reagieren.
Makros sind in ihrer Gestaltung unübersichtlich und lassen sich nicht im nötigen
Umfang mit Anmerkungen und Dokumentationen für den Entwickler versehen.
Alle Makrobefehle lassen sich auch mit Visual Basic erstellen, mit dem Unterschied, daß hier die zuvor erwähnten Einschränkungen nicht vorhanden sind.
Allerdings gibt es zwei Makros, die sinnvoll sein können:
• Ein Autoexec-Makro kann beim Starten der Anwendung einen einzelnen
„ÖffnenFormular“-Befehl ausführen. Alles weitere erledigt danach eine
Prozedur, die „BeimÖffnen“ des Formulars gestartet wird. Allerdings ist
selbst dafür ein Makro nicht unbedingt notwendig; man kann ebenso im
Menü 'Extras/Start' ein Formular auswählen, das automatisch gestartet werden soll.
27
Erweiterungskonzepte für das aktive DBMS
Microsoft Access
• Ein Tastaturbelegungs-Makro kann zur individuellen Tastenbelegung genutzt werden. Dazu muß das Makro 'Autokeys' genannt werden.
2.2.5
Module
Module [JeRe02] enthalten eine Auflistung von VBA-Deklarationen und Prozeduren. Mit VBA steht ein wirkungsvolles Instrument zur Verfügung, mit dessen Hilfe sich komplexe Datenbankanwendungen entwickeln lassen. Generell kann
man eine Einteilung der Prozeduren in Subprozeduren und Funktionen vornehmen.
Funktionen geben Werte zurück und können in Ausdrücken verwendet werden.
Sie werden mittels der Schlüsselwörter Function und End Function deklariert.
Sub-Prozeduren führen Aktionen aus und liefern keine Werte zurück. Sie werden
mittels der Schlüsselwörter Sub und End Sub deklariert.
Funktionen und Sub-Prozeduren werden in Einheiten zusammengefaßt gespeichert.
Diese Einheiten werden als Module bezeichnet. Module können aber nicht aufgerufen oder ausgeführt werden. Vielmehr werden die in diesen Modulen gespeicherten Sub-Prozeduren und Funktionen aufgerufen. VBA-Code kann in MSAccess auf verschiedene Arten ausgeführt werden. Von besonderer Bedeutung sind
dabei die Ereignisprozeduren.
Mittels Ereignisprozeduren kann auf Aktionen, die durch den Benutzer der Datenbank ausgeführt werden, reagiert werden. Aufgrund dieser Aktionen treten bestimmte Ereignisse ein, in denen so genannte Ereignisprozeduren ausgeführt werden können. Wenn in Formularen, Berichten oder Steuerelementen eine Ereignisprozedur erstellt wurde, stellt MS-Access Vorlagen für die Ereignisprozeduren zur
Verfügung, die auf etwaige Besonderheiten der einzelnen Ereignisse eingehen. So
können zum Beispiel bestimmte Ereignisse rückgängig gemacht werden, jedoch
nicht alle Ereignisse. Es muß lediglich der Code hinzugefügt werden, der als Reaktion auf ein bestimmtes Ereignis ausgeführt werden soll.
Der wesentliche Vorteil der Nutzung von VBA in Modulen gegenüber der Verwendung von Makros besteht in der größeren Flexibilität und den weitreichenden
Möglichkeiten, die diese Programmiersprache bietet.
2.3 Datenzugriffsschnittstellen
Datenzugriffsschnittstellen werden für den Zugriff auf Tabellen und Abfragen benötigt. In den folgenden Abschnitten wird eine Übersicht über die verschiedenen
Schnittstellen vorgestellt die von Microsoft Access benutzt werden.
2.3.1
Microsoft JET-Datenbank-Engine
Die JET-Datenbank-Engine ist ein Teil des MS-Access-DBMS und liegt in Form
von Systemdateien vor, welche über ihre Objektschnittstelle DAO (Data Access
Object) angesprochen werden. Neben der DAO-Schnittstelle werden ODBC, OLEDB und in der neuesten Version auch ADO unterstützt. Die JET-Datenbank-Engine
ist somit der Teil des MS-Access-DBMS, der Daten aus Benutzer- und Systemda28
Erweiterungskonzepte für das aktive DBMS
Microsoft Access
tenbanken abruft bzw. darin speichert. Sie kann als Datenmanager aufgefaßt werden.
2.3.2
ODBC (Object Database Connectivity)
ODBC [WiPe] ist ein so genanntes Application Programming Interface (API), also
eine Programmierschnittstelle, die einem Programmierer erlaubt, seine Anwendung
unabhängig von der verwendeten Datenbank zu entwickeln. Microsoft bietet dazu
einen ODBC-Treiber an, welcher die Kommunikation zwischen Programm und
Datenbank übernimmt.
Wird Quellcode geschrieben, der auf eine Datenbank zugreifen soll, muß gewöhnlich eine Sprache verwendet werden, die nur bei dieser speziellen Datenbank funktioniert. Wenn zum Beispiel Microsoft Access, MySQL und Oracle Datenbanken
unterstützt werden soll, so muß derselbe Programmteil dreimal programmiert werden. Wird hingegen ODBC verwendet, so muß nur die ODBC-Sprache anwendet
werden, welche eine Kombination aus ODBC-API Funktionsaufrufen und der
SQL-Sprache ist.
Der ODBC-Manager findet automatisch heraus, wie er mit der verwendeten Datenbank kommunizieren muß. Unabhängig vom Datenbanktyp übersetzt er die Anweisungen in die Sprache, die der SQL-Server erwartet. Es muß lediglich ein ODBCTreiber für die Datenbank, die verwendet werden soll, installiert sein.
2.3.3
OLE–DB (Object Linking and Embedding)
OLE-DB [AbIt] ist eine Erweiterung von Dynamic Data Exchange (DDE) durch
Microsoft und dient ebenfalls zur Verknüpfung von Elementen, wie Text, Bilder,
Tabellen oder Sound, in verschiedenen Programmen. Man unterscheidet zwischen
zwei Methoden zur Referenzierung von Daten in Dokumenten: Embedding und
Linking. Bei Embedding werden die Daten und Programme fest miteinander verbunden und in einer einzelnen Datei abgespeichert. Änderungen der externen Daten
werden im Gesamtdokument nicht aktualisiert. Die Methode Linking speichert nur
eine Referenz auf die entsprechenden Daten, so daß eine Änderung der Daten sofort im Dokument aktualisiert wird. Wird die Daten-Datei allerdings gelöscht, so
fehlen die Informationen im Dokument.
2.3.4
Database Access Objects (DAO)
DAO ist ein von Microsoft definiertes Datenbankzugriffsobjekt für den Zugriff auf
Datenbanken. Diese Schnittstelle greift auf MS-Access-Datenbanken direkt und
schnell über die sogenannte JET-Engine zu. Alle anderen Datenbanken werden
über die bekannten ODBC-Treiber angesprochen. Die DAO-Bibliothek ist objektorientiert als C++ Klasse implementiert und nur für die 32-Bit-Plattformen Windows 9x/2000 und Windows NT, sowie Nachfolger verfügbar. Zum DAO-Toolkit
werden aber auch alle notwendigen Systembibliotheken mitgeliefert, so daß diese
Schnittstelle auch ohne installiertes Datenbankprodukt genutzt werden kann.
29
Erweiterungskonzepte für das aktive DBMS
Microsoft Access
Microsoft Access-Datenbanken lassen sich auf einem Rechner, auf dem kein
Microsoft Office-Paket installiert ist, erstellen, lesen und schreiben.
30
Erweiterungskonzepte für das aktive DBMS
Microsoft Access
Die DAO- Features sind
•
Zugriff auf Microsoft Access Datenbanken über die schnelle JET-Engine
•
Zugriff auf andere DB über ODBC-Treiber
•
32-Bit Applikation
2.3.5
ActiveX Data Objects (ADO)
ADO ist eine Datenzugriffsschnittstelle, die zur Herstellung einer Verbindung, sowie zum Abfragen, Verändern und Aktualisieren von Daten mit OLE-DBkompatiblen Datenquellen dient. Diese Datenzugriffsschnittstelle ist ein weiterentwickelter Nachfolger der Microsoft DAO-Datenbank-Schnittstelle. Im Unterschied
zu dieser ist ADO nicht so sehr auf MS-Access-Datenbanken beschränkt (oder
auch optimiert). ADO arbeitet für den Zugriff auf Datenbanken mittels eines OLEDB-Providers. Durch diesen Mechanismus sind Verbindungen zu sehr verschiedenen Datenbanken möglich, die unter DAO etwa nur mit verknüpften Tabellen innerhalb MS-Access realisiert werden können. Jede Datenbank kann, wenn es einen
entsprechenden Treiber gibt, nativ, d.h. schnell, und effizient angesprochen werden.
31
Erweiterungskonzepte für das aktive DBMS
Microsoft Visual Basic
Kapitel 3 Microsoft Visual Basic
Microsoft Visual Basic
Visual Basic, (abgek. VB) ist eine, seit Office 97, in allen Microsoft OfficeAnwendungen eingesetzte objektorienterte Programmiersprache, in der auch SQL
eingebettet ist. Bei den visuellen Sprachen, wie VB es ist, steht nicht mehr die Verarbeitung von Daten im Vordergrund, sondern das Hantieren mit Objekten auf dem
Bildschirm. Voraussetzung für die Arbeit mit Objekten ist immer das Vorhandensein einer Oberfläche. Visuelle Sprachen manipulieren Objekte, um dem Anwender
ein Ergebnis auf dem Bildschirm zu präsentieren, z.B. ein Dialogfeld zur Eingabe
von Werten oder Texten. Objekte werden durch Eigenschaften und Aktionen (Methoden) gesteuert. Bildschirmaktionen, wie z.B. Mausklick, können Ereignisse auslösen. Alle Aktionen mit Objekten werden in die Techniken der klassischen Sprachen eingebettet. Dazu gehören Variablendeklarationen, Steueranweisungen wie
Bedingungsabfragen, Schleifen und Sprünge, Subroutines usw.
3.1 Visual Basic-Entwicklungsumgebung
Visual Basic-Programme werden in einer VBA-Entwicklungsumgebung geschrieben. Zur Erstellung von Programmen ist eine Programmierumgebung notwendig.
Für VBA ist dies der Visual Basic-Editor. Mit den Tastenkombination ALT + F11
gelangt man aus dem Datenbankfenster direkt in die Entwicklungsumgebung. Die
Komponenten dieser Umgebung sind der Project Explorer, Visual Basic-Editor,
das Eigenschafts- und das Direktfenster (siehe Abbildung 3.1).
Project Explorer
Dieses Fenster zeigt alle in einem Projekt verwendeten Module. Microsoft Access
unterscheidet zwei Grundtypen von Modulen: Standardmodule und Klassenmodule.
Standardmodul ist ein Modul, in das Sub- und Funktionsprozeduren einEin
gefügt werden können. Diese Prozeduren sind dann für andere Prozeduren der
Datenbank verfügbar. Standardmodule enthalten allgemeine Prozeduren, die nicht
mit einem anderen Objekt verbunden sind, sowie häufig verwendete Prozeduren,
die von jeder beliebigen Stelle innerhalb ihrer Datenbank aus, ausgeführt werden
können. Der wesentliche Unterschied zwischen einem Standardmodul und einem
Klassenmodul, das nicht mit einem bestimmten Objekt verbunden ist, liegt im Gültigkeitsbereich und in der Lebensdauer. Die Werte von Variablen oder Konstanten,
die deklariert sind oder ohne zugeordnetes Objekt in einem Klassenmodul enthalten sind, stehen nur dann zur Verfügung, wenn dieser Code ausgeführt wird bzw.
sind ausschließlich von diesem Objekt verfügbar. Standardmodule werden auch in
Formularen benutzt. Der Unterschied zu den Standardmodulen besteht in ihrem
Gültigkeitsbereich. Eine Prozedur oder eine Funktion, die in einem Formularmodul
32
Erweiterungskonzepte für das aktive DBMS
Microsoft Visual Basic
geschrieben wurde, ist auch nur dort bekannt. Formularmodule werden als
Microsoft Access-Klassenobjekte bezeichnet.
Klassenmodul ist ein Modul, das die Definition für ein neues Objekt entEin
halten kann. Jede Instanz einer Klasse erstellt ein neues Objekt. Jede Prozedur, die
in dem Modul definiert wurde, erhält die Eigenschaften und Methoden des Objekts.
Klassenmodule können eigenständig oder mit Formularen und Berichten verwendet
werden. Diese Funktionalität gibt den Entwicklern eine bessere Kontrolle über den
Code der Applikation und macht es einfacher, widerverwendbare Komponenten zu
erstellen.
Visual Basic-Editor
Projekt-Explorer
Eigenschaftsfenster
Direktfenster
Abbildung 3.1: Die Visual Basic-Entwicklungsumgebung
Eigenschafts-, Direkt- und Überwachungsfenster
Das Eigenschaftsfenster hat in der VB-Entwicklungsumgebung eigentlich nichts
zu suchen. Es kann lediglich der Modulname vergeben oder geändert werden. Das
Direkt- und Überwachungsfenster hingegen sind zwei wichtige Werkzeuge bei der
Entwicklung einer Anwendung.
Im Überwachungsfenster kann der eigene Programmcode überwacht werden.
Dies geschieht mittels der Ausgabe der aktuellen Werte von ausgewählten Variablen. Im Menü unter Ansicht kann das Überwachungsfenster geöffnet werden.
33
Erweiterungskonzepte für das aktive DBMS
Microsoft Visual Basic
Das Direktfenster zeigt Informationen an, resultierend aus Anweisungen zur Fehlerbeseitigung im Code oder aus Befehlen, die direkt in dieses Fenster eingegeben
wurden. Sowohl das Direktfenster, wie auch das Überwachungsfenster sind ein
wichtiges Hilfsmittel bei der Fehlersuche.
Visual Basic-Editor
Im Visual Basic-Editor wird der Programmcode geschrieben. Es stehen eine Objekt- und eine Ereignisliste in der Kopfleiste des Editors zur Verfügung. In der
Fußleiste kann zwischen Prozedur- und Modulansicht umgeschaltet werden.
Ereignisliste
Objektliste
Prozeduransicht
Modulansicht
Abbildung 3.2: Visual Basic-Editor
3.2 Objekte, Eigenschaften und Module
Microsoft Access ist keine vollständige objektorientierte Sprache. Obwohl MSAccess von Objekten „lebt“, fehlt z.B. die Vererbung. Die Vererbung ist ein wesentliches Merkmal der objektorientierte Programmierung, bei dem ein neues Objekt, durch Änderung oder Verfeinerung des Verhaltens eines vorhandenen Objekts, definiert wird. Leider ist dieses Konzept in Microsoft Visual Basic nicht umgesetzt worden. So ist die objektorientierte Programmierung in Visual Basic nur
beschränkt möglich.
34
Erweiterungskonzepte für das aktive DBMS
Microsoft Visual Basic
Alle MS-Access Objekte verfügen über Eigenschaften und Methoden. Eigenschaften beschreiben physische Charakteristika eines Objekts. So verfügt das Objekt Formular über die Eigenschaften Namen, Hintergrundfarbe, Höhe, Breite,
Rahmen, Beweglichkeit, Sichtbarkeit usw. Methoden sind Dinge, die ein Objekt
tun kann. So kann das Objekt Formular geöffnet, geschlossen, vergrößert oder verkleinert werden.
Die wesentliche Eigenschaft eines Objektes ist die Einheit von Daten und Methoden. Nur mit den Methoden, die der allgemeinen Benutzung freigegeben sind, kann
man die Daten manipulieren. Man spricht von Datenkapselung. Auf diese Weise
kann der Datenzugriff, insbesondere bei großen Projekten, geregelt und weitgehend
fehlerfrei gestaltet werden.
Die Definition eines Objektes erfolgt in einer sogenannten Objektklasse, die eine
Definition für ein Objekt, einschließlich seines Namens, seiner Eigenschaften und
seiner Methoden, sowie aller zugehörigen Ereignisse ist. Meist beinhaltet eine Objektklasse innere, man sagt private oder versteckte, Daten und Prozeduren, auf die
der Anwender keinen Zugriff hat, die aber für die Ausführung der Methoden wichtig sind. VBA sieht verschiedene Möglichkeiten vor, eigene Objekte zu definieren
oder objektorientierte Arbeitsweisen zu entwickeln.
Wenn eine Instanz einer Klasse erstellt wird, entsteht ein neues Objekt mit allen
durch diese Klasse definierten Merkmalen. Jede innerhalb der Objektklasse definierte öffentliche Prozedur wird eine Methode des benutzerdefinierten Objekts. Die
Anweisung Sub definiert eine Methode, die keinen Wert zurückgibt. Die Anweisung Function definiert dagegen eine Methode, die einen Wert eines festgelegten
Typs zurückgeben kann. Alle Property Let-, Property Get- und Property SetProzeduren, die definiert werden, werden zu einer Eigenschaft des neuen Objekts.
Property Get-Prozeduren rufen den Wert einer Eigenschaft ab. Property LetProzeduren stellen den Wert einer Nicht-Objekteigenschaft ein. Property SetProzeduren stellen den Wert einer Objekteigenschaft ein. [MS-Ac00]
Einen weiteren Vorteil bringt das Collection Object. Es stellt ein Objekt dar, mit
dessen Hilfe eigene Listenobjekte oder Auflistungen erzeugt werden können. Man
kann Objekte hinzufügen, herausnehmen oder ein einzelnes Objekt bearbeiten. Gegenüber der Anordnung der Daten in einem Datenfeld (Array) haben Collection
Objects den Vorteil, die Arraygrößen vorher nicht festlegen zu müssen. Beim Löschen von Werten entstehen keine leeren Felder und die Listen können mit einer
For-Next-Schleife durchlaufen werden. Außerdem ermöglicht das Collection Object den Zugriff auf die Listenelemente, sowohl über einen Namen als auch über
einen Index.
35
Erweiterungskonzepte für das aktive DBMS
Dim colTrigger As New Collection
Name des Kollektionobjektes
Microsoft Visual Basic
Objekttyp Collection
Zuweisung einer neuen Instanz schon bei der Definition
Abbildung 3.3: Definition einer Collection
3.3 Visual Basic-Grundlagen
In diesem Abschnitt werden einige Sprachkonstrukte vorgestellt. Dieser Abschnitt
soll kein Einstigerkurs in VBA sein, vielmehr soll ein grober Überblick über Prozeduren, Bedingungen, Funktionen, Variablen, Datentypen und Konstanten gegeben werden.
Variablen sind Programmelemente, die während eines Programmablaufes unterschiedliche Werte annehmen können. Für jede Variable wird Speicherplatz im Arbeitsspeicher des Computers reserviert. Die Größe des Speicherplatzes wird vom
vereinbarten Datentyp der Variablen bestimmt. Variablen werden mit einem Namen angesprochen. Sie werden mit dem Schlüsselwort Dim eingeleitet, gefolgt von
einem Variablennamen und einem Datentyp. Die Standarddatentypen die in MSAccess angegeben werden können sind aus der Abbildung 3.3 zu entnehmen.
Dim sText As String
Name der Variable
Variable bekommt den Datentyp Zeichenkette zugewiesen
Deklariert die Variablen und reserviert Speicherplatz dafür
Abbildung 3.4: Definition einer Collection
Feste Zahlenwerte im Programmcode sollte man durch Konstanten ersetzen. Bei
Änderungen muß dann nur die Konstantenzuweisung geändert werden und nicht
die vielen Stellen, wo der Wert auftritt. Konstanten werden in den Deklarationsteilen von Modul und Prozedur vereinbart. Der Wert einer Konstanten läßt sich während des Programmablaufes nicht ändern. Er bleibt während des gesamten Programmablaufes erhalten. Eine Konstante wird mit dem Schlüsselwort Const eingeleitet, gefolgt von einem Name für die Konstante und der Zuweisung zu einem
Wert.
Typ
Byte
Boolean
Integer
KZ
%
Erläuterung, Wertebereich
Ganzzahl, 0…255
Wahrheitswert, TRUE=1, False=0
Ganzzahl, -32768 … 32767
36
Speicher
[Byte]
1
2
2
Erweiterungskonzepte für das aktive DBMS
Long
Single
Double
Currency
String
Date
Object
Variant
&
!
#
@
$
Microsoft Visual Basic
Ganzzahl lang: -2 147 483 648 … 2 147 483 647
4
Gleitkommazahl, einfachgenau (7 Ziffern) 10E-38 … 10E+38
4
Gleitkommazahl, doppeltgenau (16 Ziffern) 10E-308 … 10E+308
8
Währung: (15 Stellen), (Dezimalpunkt), (4Stellen)
8
Zeichenfolge, max. ca. 2 Mrd. Zeichen (2^31)
10+Länge
1. Januar 100 … 31.Dezember 9999
8
Verweis auf ein Objekt
4
universeller Datentyp
≥16
Abbildung 3.5: Datentypen und Wertebereiche
Der Gültigkeitsbereich einer Variablen wird bei ihrer Deklaration bestimmt. Mit
dem Gültigkeitsbereich wird die Verfügbarkeit von Variablen, Konstanten oder
Prozeduren zur Verwendung durch eine andere Prozedur bezeichnet. Es gibt drei
Gültigkeitsbereichebenen: Prozedurebene, private Modulebene und öffentliche
Modulebene [MS-Ac00]. Innerhalb einer Prozedur definierte Variablen oder Konstanten sind außerhalb dieser Prozedur nicht verfügbar. Variablen und Konstanten
können auch auf Modulebene privat oder öffentlich deklariert werden. Öffentliche
Variablen sind für alle Prozeduren in allen Modulen eines Projektes verfügbar, private Variablen sind nur für die Prozeduren in diesem Modul verfügbar.
3.3.1
Kontrollstrukturen
Ein Programm besteht aus einer Folge von Anweisungen. In seiner einfachsten
Form enthält ein Programm Anweisungen, die der Reihe nach ausgeführt werden
(Folge). Anweisungen können jedoch auch mehrmals wiederholt, als Folge einer
Auswahl, ausgeführt werden. Die Kontrollstrukturen Folge, Wiederholung und
Auswahl sind die Hauptbestandteile eines Programms.
Anweisungen, die nacheinander und jede genau einmal abgearbeitet werden, nennt
man Folge. Ein rein sequentieller Programmablauf ist die einfachste Struktur eines
Programms. Als Auswahl bezeichnet man eine oder mehrere abhängige Bedingungen. Man unterscheidet zwischen einseitige, zweiseitige, mehrstufige und mehrseitige Auswahl.
3.4 API
API ist die Abkürzung für Application Programmer's Interface" und bedeutet Programmier- und Anwendungsschnittstelle. Wo Microsoft Access nicht weiterhilft,
kann in vielen Fällen die vorhandene Funktionalität durch den Einsatz von APIFunktionen erweitert werden. Nicht zuletzt diese Flexibilität macht den Erfolg von
Microsoft Access als Datenbankentwicklungssystem für anspruchsvolle Lösungen
aus.
37
Erweiterungskonzepte für das aktive DBMS
Microsoft Visual Basic
Abbildung 3.6: Verweisfenster
In ARTA II wird mit Hilfe dieser Technik die Timer- und Kalenderfunktionalität
realisiert. Dazu werden .dll-Dateien (Dynamic Link Library) in Microsoft Access
über ein Verweisfenster (siehe Abbildung 3.6) eingebunden. Das Verweisfenster
läßt sich über das Menü unter Extras/Verweise öffnen. Da in Visual Basic nicht auf
alle Objektbibliotheken über das Verweisfenster zugegriffen werden kann, muß das
Einbinden der Objektbibliotheken über den Visual Basic-Programmiercode geschehen. Dazu werden die .dll-Dateien vor der Benutzung mit einem DECLAREBefehl dem System bekannt gemacht. Diese Deklaration sollte in einem Modul
stattfinden, um den Gültigkeitsbereich zu vergrößern. Anschließend stehen dem
Benutzer die Methoden zur Verfügung. In ARTA II wird vor allem die SetTimerFunktion der User32.dll genutzt um die Timerfunktionalität zu realisieren.
38
Erweiterungskonzepte für das aktive DBMS
SQL:1999
Kapitel 4 SQL:1999
SQL:1999
Ende der siebziger Jahre entwickelte die Firma IBM für die relationale DBMS DB2
eine Computersprache speziell für Datenbankanfragen. Die erste Sprachversion
hieß SEQUEL, als Abkürzung für Structured English Query Language (deutsch:
strukturierte englische Abfragesprache). Der Name dieser Sprache wurde später aus
rechtlichen Gründen geändert und lautet nun SQL (Structured Query Language
oder deutsch: strukturierte Abfragesprache). 1983 begann das American National
Standards Institute (ANSI) mit der Ausarbeitung eines Standards für relationale
Datenbanksprachen. Der Abschlußbericht wurde als American National Standard
Database Language-SQL (ANSI X3.135-1986) verabschiedet. Dieser Standard
wurde 1987 auch von der International Standards Organisation (ISO) als ISOStandard übernommen (ISO 9075 Database Language SQL). In den Jahren 1986
bzw. 1989 gab es weitere Standarddokumente, für die sich die Begriffe SQL:1986,
SQL:1989 und SQL-1 als Überbegriffe entwickelt haben. 1992 kam eine überarbeitete Version als SQL:1992 bzw. SQL-2 heraus. Das SQL-2-Standarddokument
umfaßt bereits mehr als 600 Seiten gegenüber den 120 Seiten des SQL:1989Dokuments. SQL-3 wurde 1999 verabschiedet und ist deshalb auch unter
SQL:1999 bekannt. SQL:1999 wurde mit Konzepten wie Rekursion und
objektorientierten Ansätzen erweitert. Im Laufe der Jahre sind verschiedene
Erweiterungen hinzugekommen, so daß sich mit dieser Sprache nicht nur Abfragen
ausführen, sondern auch Datenbanken erstellen und die Sicherheitsaspekte des
Datenbanksystems verwalten lassen.
4.1 Grundlagen von SQL
SQL kann eingebettet in eine Programmiersprache als embedded-SQL oder auch
als stand alone-Sprache benutzt werden. Heute ist SQL eine „vollständige“ DBSprache, die sich in drei Teilsprachen gliedert:
• DDL (Data Definition Language),
• DML (Data Manipulation Language)
• DCL (Data Control Language).
Mit dem Begriff Data Definition Language DDL sind Anweisungen gemeint, mit
denen man Daten definieren kann. Es geht dabei um Löschung, Änderung und Einrichtung von Datenbankobjekten, wie z.B. Datenbanken (databases), Tabellen
(tables) oder Sichten (views). Diese Anweisungen werden mit den folgenden
Schlüsselbegriffen eingeleitet:
39
Erweiterungskonzepte für das aktive DBMS
Schlüsselwort
CREATE
ALTER
DROP
SQL:1999
Bedeutung
Erzeugen neuer Objekte
Verändern der Eigenschaften existierender Objekte
Löschen existierender Objekte
Tabelle 4.1: DDL-Anweisungen
Ergänzt werden diese Schlüsselwörter in der Regel um das Schlüsselwort für das
zu bearbeitende Datenbankobjekt, wie beispielsweise TABLE, VIEW, usw.
Der Begriff „Data Manipulation Language“ faßt alle SQL-Anweisungen zur Anfrage und zur Datenmanipulation, wie Einfügen, Löschen und Ändern, zusammen.
Zur Datenmanipulation verwendet SQL folgende Anweisungen:
Schlüsselwort
DELETE
INSERT
UPDATE
Bedeutung
Löschen einer oder mehrerer Zeilen aus einer Tabelle
Erzeugen einer oder mehrerer neuer Zeilen in einer Tabelle
Verändern einer oder mehrerer Zeilen einer Tabelle
Tabelle 4.2: DML-Anweisungen
Das SELECT-Statement erlaubt das Abfragen und Finden von Informationen in
der Datenbank. Dies ist vermutlich der wichtigste, mächtigste und komplizierteste
aller SQL-Befehle. Mit diesem Befehl können die Daten verschiedener Tabellen
der Datenbank gesammelt und ausgewertet werden. Dies erlaubt eine von der tatsächlichen Tabellenstruktur unabhängige Sicht auf die Daten. Mit einem DDLBefehl (CREATE VIEW Sichtname) können darüber hinaus häufig benutze Anfragebefehle und Strategien als so genannte Sichten in der Datenbank gespeichert
werden. Auf diese Art kann durch einen einfachen SELECT-Befehl (SELECT *
FROM Sichtname) ein weitaus komplexerer SELECT-Befehl abgekürzt werden.
Mit dem Begriff „Data Control Language“ werden alle SQL-Anweisungen zur
Rollen- und Rechtevergabe zusammengefaßt, die festlegen, wer welche Anweisungen zur Datenänderung bei einem Datenbanksystem anwenden kann. Zur Rollenund Rechtevergabe verwendet SQL folgende Anweisungen:
Schlüsselwort
Bedeutung
GRANT
Erteilt Berechtigungen, um entweder mit Daten zu
arbeiten oder andere Transact-SQL-Anweisungen
auszuführen
DENY
Verweigert Berechtigungen und verhindert, daß der angegebene
Benutzer, die Gruppe oder Rolle, die Berechtigung
über Gruppen- und Rollenmitgliedschaften erbt
REVOKE
Entfernt zuvor erteilte oder verweigerte Berechtigungen
Tabelle 4.3: DLC-Anweisungen
40
Erweiterungskonzepte für das aktive DBMS
SQL:1999
4.2 SQL-Triggersprache
Der SQL-Standard wurde 1999 unter anderem um ein Triggerkonzept erweitert,
welches den Schwerpunkt dieses Kapitels bilden soll. Im Laufe des Kapitels ist
mit SQL immer der SQL:1999 Standard gemeint.
Trigger in SQL sind spezielle Formen aktiver (ECA)-Regeln. Aus der Syntax in
Abbildung 4.4 ist zu ersehen, daß die Trigger durch die primitiven Datenmanipulationsereignisse insert, update und delete ausgelöst werden. In der WHEN-Klausel
wird die Regelbedingung definiert, die ein (beliebiges) Prädikat ist. Die Aktionskomponente setzt sich aus einer Sequenz von SQL-Befehlen zusammen, wobei u.a.
Transaktionsbefehle nicht zulässig sind. Wenn das triggerauslösende Ereignis (E)
eintritt und die Bedingung (C) erfüllt ist, werden die SQL-Befehle des Aktionsteils
(A) verarbeitet.
4.3 Syntax der SQL-Triggersprache
Trigger in SQL haben die folgende zunächst vereinfacht dargestellte Form
CREATE TRIGGER Triggername
BEFORE | AFTER Ereignistyp ON Tabellenname
REFERENCING NEW AS correlation_name
OLD AS correlation_name
FOR EACH ROW | STATEMENT
WHEN Bedingung
Triggerbody
BEGIN
END
Abbildung 4.4: Einfache Syntax eines Triggers
Triggername
Die Erstellung eines Triggers wird immer mit dem Schlüsselwort create trigger
eingeleitet. Anschließend folgt die Vergabe eines eindeutigen Namens, um den
abgespeicherten Trigger identifizieren zu können. Der Triggername besteht aus
einer Zeichenfolge.
trigger name
CREATE TRIGGER
Abbildung 4.5: Triggername
41
Erweiterungskonzepte für das aktive DBMS
SQL:1999
Triggerndes Ereignis
Mit der trigger action time setzt man den Auslösungszeitpunkt des Triggers fest.
Hier wird der Zeitpunkt spezifiziert, zu dem die Regel ausgelöst werden soll. Dabei
wird zwischen zwei Zeiten unterschieden: Ein Trigger kann entweder vor (BEFORE) oder nach (AFTER) des auslösenden Befehls ausgelöst werden.
Anschließend wird das triggernde Ereignis (trigger event) angegeben. Die triggernden Operationen auf die ein SQL-Trigger reagieren kann sind INSERT, DELETE oder UPDATE. Dieser Parameter wird gefolgt vom Schlüsselwort ON und
der Angabe einer betroffenen Tabelle, auf der die Änderungsoperation ausgeführt
werden soll. Diese Syntaxstruktur ist in der folgenden Abbildung zu sehen.
trigger event
trigger action time
INSERT
BEFORE
DELETE
ON
table name
AFTER
UPDATE
Abbildung 4.6: Triggerndes Ereignis
Durch die Vergabe eines Aktivierungszeitpunktes und eines Triggertyps können
sechs verschiedene Ausführungskombinationen angegeben werden.
Transitionsvariablen und Triggergranularität
Nachdem das zu triggernde Ereignis festgelegt wurde, kann zudem angegeben
werden, mit welchem Namen man auf die Transitionstabellen zugreifen möchte.
Dies wird durch die Angabe einer Referencing-Klausel ermöglicht. Die alten Attributwerte werden über OLD und die neuen Attributwerte über NEW referenziert. So
kann während der Abarbeitung des Triggers auf die alten und die neuen Werte der
Transitionstabelle zugegriffen werden.
REFERENCING
NEW
ROW
AS
tupel name
OLD
TABLE
AS
relation name
FOR EACH ROW
FOR EACH STATEMENT
Abbildung 4.7: Triggergranularität
42
Erweiterungskonzepte für das aktive DBMS
SQL:1999
Durch die Angabe von ROW oder STATEMENT wird die Granularität, mit der der
Trigger arbeiten soll, angegeben. FOR EACH ROW wird als tupelorientiertes Verarbeitungsmodell bezeichnet, da die folgende Aktion bei jedem zu ändernden Tupel
auszuführen ist. FOR EACH STATEMENT wird als mengenorientiertes Verarbeitungsmodell bezeichnet, da die folgende Aktion nur einmal für die gesamte SQLAnweisung ausgeführt wird. In der folgenden Tabelle sind die gültigen Kombinationen für die Trigger, Granularität und Transitionsvariablen zu ersehen.
Granularität
Auslösezeitpunkt
BEFORE
triggernde
Operation
Transitionsvariablen
INSERT
NEW
UPDATE
OLD, NEW
DELETE
OLD
INSERT
NEW
UPDATE
OLD, NEW
DELETE
OLD
Übergangstabellen
NONE
ROW
AFTER
NEW_TABLE
OLD_TABLE,
NEW TABLE
OLD_TABLE
INSERT
BEFORE
UPDATE
NONE
NONE
DELETE
STATEMENT
INSERT
AFTER
UPDATE
NONE
DELETE
NEW_TABLE
OLD_TABLE,
NEW TABLE
OLD_TABLE
Tabelle 4.8: Kombinationsmöglichkeiten
Triggerbedingung
Die Ausführung des Triggeraktionsteils kann durch Angabe einer Triggerbedingung eingeschränkt werden. Die Bedingung wird mit dem Schlüsselwort WHEN
eingeleitet. Die Angabe einer Triggerbedingung ist optional, d.h. wenn die Bedingung nicht angegeben wird, wird der Aktionsteil bei jedem Auslösen des Triggers
ausgeführt.
WHEN
(
condition
)
Abbildung 4.9: Triggerbedingung
43
Erweiterungskonzepte für das aktive DBMS
SQL:1999
Triggeraktionsteil
Der Triggeraktionsteil wird durch BEGIN ATOMIC und END eingeschlossen.
Der Aktionsteil kann in Form eines SQL-Statements oder einer Anweisungsfolge,
die in einer Programmiersprache des zugrunde liegenden Systems geschrieben
wurde, angegeben werden. Natürlich ist es möglich, daß im Aktionsteil weitere
Trigger gefeuert werden können. Doch auch hier ist es nicht erlaubt, SQLStatements zu formulieren, welche Änderungen an der Tabelle, die gerade vom
Trigger bearbeitet wird, vornehmen. Denn solch eine Aktivierung könnte zyklisch
sein (rekursive Trigger) und die Terminierung der Aktivierungskette wäre nicht
sichergestellt. Ein weiteres Problem entsteht, wenn mehrere Trigger zum gleichen
Zeitpunkt und mit identischer Granularität definiert werden. Da in SQL:1999 keine
Priorität existiert, kann eine Ausführungsreihenfolge nur durch das Erstellungsdatum des Triggers festgelegt werden.
BEGIN ATOMIC
command
END
;
Abbildung 4.10: Triggeraktionsteil
4.4 Semantik der SQL-Triggersprache
Ausführungsreihenfolge: In SQL:1999 können mehrere Trigger für eine Tabelle
definiert werden, die durch dasselbe Ereignis ausgelöst werden. Diese Trigger werden in einer bestimmten Reihenfolge verarbeitet. Bei Triggern mit dem Auslösungszeitpunkt BEFORE werden die mengenbasierten Trigger vor den instanzbasierten Regeln verarbeitet. Bei Triggern mit dem Auslösungszeitpunkt AFTER
werden die instanzbasierten Regeln vor den mengenbasierten ausgeführt. Dadurch
ergibt sich die folgende Ausführungsreihenfolge:
• Alle Before-Statement-Trigger werden gesammelt und rekursiv abgearbeitet.
• Alle Before-Row-Trigger werden gesammelt und rekursiv abgearbeitet.
• Ausführung der triggernden Operationen
• Überprüfung der Integritätsbedingung
• Alle After-Row-Trigger werden gesammelt und rekursiv abgearbeitet.
• Alle After-Statement-Trigger werden gesammelt und rekursiv abgearbeitet.
Nach dem Sammeln der Trigger werden diese nach ihrem Erstellungsdatum sortiert, um somit eine Abarbeitungsreihenfolge festzulegen. Als Defaultwert werden
alle Trigger sofort (immediate) ausgeführt. Jedoch gibt es auch Möglichkeiten, die
Verarbeitung der Trigger bis zum Ende einer Transaktion zu verzögern (deferred).
44
Erweiterungskonzepte für das aktive DBMS
SQL:1999
In SQL:1999 können durch die Ausführung einer triggernden Aktion Ereignisse
eintreten und somit weitere Trigger ausgelöst werden. Diese Triggerkaskaden
können zyklisch verlaufen und dazu führen, daß die Abarbeitung nicht terminiert.
SQL:1999 bietet kein Konzept an, um Zyklen zu erkennen und nicht-endende Regelausführungen zu verhindern. Da Before-Trigger keine weiteren Trigger auslösen
dürfen, gilt das Problem der Triggerkaskade nur für die After-Trigger.
Die Bedingungsüberprüfung und die Aktionsausführung eines SQL:1999-Triggers
erfolgen innerhalb der Transaktion, die den Trigger anstößt. Kommt es bei der Aktionsausführung zu einem Fehler, so werden alle Aktionen (einschließlich des auslösenden Statements) zurückgesetzt (ROLLBACK).
45
Erweiterungskonzepte für das aktive DBMS
ARTA (Active Real Time Access DBS)
Kapitel 5 ARTA (Active Real Time Access DBS)
ARTA
ARTA II basiert auf einem in früheren Diplomarbeiten entwickelten aktiven Datenbankverwaltungssystem. In diesem Kapitel wird das „alte“ ARTA-System vorgestellt und die Unterschiede zum neuen System aufgeführt.
5.1 Namenskonvention
ARTA setzt sich aus vier Initialen zusammen, die für Active Real Time Access
Database System stehen. Das vierte Initial steht für Microsoft Access, was das
zugrundeliegende DBMS repräsentiert. Da MS-Access kein aktives DBMS ist und
demzufolge nicht die Möglichkeit bietet aktive Regeln (Trigger) anzugeben, wurde
dieses System um diese Erweitert. So wurde aus einem passiven ein aktives
DBMS, wofür das erste Initial in ARTA steht. Um die Initialen R und T in der
Namensgebung zu erklären, muß zunächst der folgende Begriff eingeführt werden.
Ein Echtzeitsystem (engl. Real Time System, abgek. RTS) ist ein System, daß ein
korrektes Ergebnis innerhalb einer vorgegebenen Zeitspanne liefert.
Die ARTA-Trigger wurden um die Möglichkeit erweitert, auf vordefinierte Zeitereignisse reagieren zu können. Dazu wurde die Timerfunktionalität des Betriebssystems genutzt, die über die API-Schnittstelle angesprochen wird. Zudem wurde
durch die Angabe einer Zeitspanne, die angibt bis zu welchem Zeitpunkt ein Trigger spätestens gefeuert werden muß, ein wichtiger Aspekt eines Echtzeitsystems
geliefert. Aufgrund dieser neuen Funktionalitäten wurde aus dem aktiven DMBS
ein aktives Echtzeit-DBMS.
5.2 GUI von ARTA
In ARTA werden Formulare als Benutzeroberflächen eingesetzt, um Anwendern
die Möglichkeit der Verwaltung von Triggern und Ereignismustern zu geben. Zur
Ereigniserkennung werden alle Datenbankänderungen unter dem direkten Einsatz
von ARTA vorgenommen. ARTA-II wurde mit einer komplett neuen GUI versehen, siehe Kapitel 8, so daß eine weitgehend übersichtliche Arbeit ermöglicht wird.
Dies betrifft nicht nur den Anwender, sondern auch den Entwickler. In der Entwicklungsansicht der Formulare wurde sehr großen Wert darauf gelegt, jedes benutzte Objekt vernünftig zu benennen und es so anzuordnen, das eine Änderung
nicht gleich eine komplette Umgestaltung mit sich zieht. Oft werden Steuerelemente, wie z.B. Textfelder übereinander gelegt und nach Bedarf sichtbar geschaltet.
Werden jedoch in einer Benutzeroberfläche sehr viele dieser Objekte untergebracht, ist es dem Entwickler fast unmöglich eines dieser Objekte vernünftig modifizieren zu können, ohne gleich darüberliegende Objekte bewegen zu müssen.
Nach einer Modifizierung eines Objektes, müssen dann all diejenigen Objekte die
provisorisch „zur Seite gelegt wurden“, wieder in ihrer ursprünglichen Position
46
Erweiterungskonzepte für das aktive DBMS
ARTA (Active Real Time Access DBS)
angebracht werden. In ARTA-II wurden bei der Gestaltung Lösungen gefunden,
um die Verschiebung der Objekte bei einer Änderung im Rahmen zu halten. Eine
dieser Lösungen war die Verwendung von Registersteuerungselementen, um zusammengehörige Objekte gruppiert auf einer Registerkarte anzuordnen.
Abbildung 5.1:
ARTATriggerübersicht
Abbildung 5.2: ARTA II-Triggerübersicht
47
Erweiterungskonzepte für das aktive DBMS
ARTA (Active Real Time Access DBS)
5.3 Erweiterungen in ARTA II
Um den Unterschied kurz anzudeuten, ist in den obigen zwei Abbildungen eine
Gegenüberstellung einer ARTA- und einer ARTA II-Benutzeroberflächen gegeben.
Weitere Unterschiede zum ARTA-System werden hier Stichpunktartig aufgezählt.
• Die Deadline in ARTA wurde nur für Zeitereignisse implementiert. In ARTA-II werden auch Änderungsereignisse mit einer Deadline versehen.
• In ARTA II wird für jeden Trigger ein Gültigkeitsintervall angegeben, um
festzulegen, wie lange dieser überhaupt gültig ist. Das Gültigkeitsintervall
spielt auch bei der Erstellung von Triggern vom Typ periodisches Zeitereignis eine große Rolle.
• In ARTA-II wurde das Konzept der Priorität erweitert, so daß komfortabel
und übersichtlich die Priorität eines Triggers geändert werden kann. Dabei
hat man stets die Priorität der anderen Trigger im Überblick.
• In der Syntax der ARTA-Trigger wurde ein Flag (activity) angegeben, das
den Aktivierungszustand des Triggers angibt. Dieses Flag wurde aus der
Syntax entfernt. Die Notation, ob ein Trigger aktiviert oder deaktiviert ist,
erfolgt in der Datenbank.
• Die Syntax eines periodischen Zeitereignistyps wurde wesentlich erweitert,
siehe Kapitel 6.2 und 6.3.
• Der Ereignistyp eines ARTA-Triggers wird bei der Erstellung in einer eigenen Tabellen in der Datenbank gespeichert. Jeder Ereignistyp wird mit einem eindeutigen Namen versehen und kann später als „Ereignismuster“
wiederbenutzt werden. Die Wartung ist sehr aufwendig und das Löschen eines Ereignismusters, das von mehreren Triggern benutzt wird, kann zu fatalen Fehlern führen. In ARTA II wird ein Trigger komplett in einer Tabelle
in der Datenbank gespeichert. Überdies besteht die Möglichkeit, oft benutzte Ereignistypen als Ereignismuster zu definieren, die dann in einer gesonderten Tabelle gespeichert werden. Ereignismuster sind eine Kopie eines
vorher erstellten Ereignistyps, gekennzeichnet durch einen eindeutigen Namen. Bei der Erstellung eines Triggers werden die Ereignismuster in einer
Auswahlliste angeboten, um die Eingabe zu erleichtern. Um diese Änderungen an ARTA vorzunehmen, mußten sehr große Teile der Struktur geändert
werden. Ganze Klassen mußten modifiziert und ihre Routinen angepaßt
werden.
• Wie in Kapitel 4.4 erwähnt, existiert in der SQL:1999-Triggersprache kein
Konzept um mit Zyklen umzugehen. In ARTA-II wurde eine Beschränkung
der Kaskadentiefe implementiert, um zu verhindern, daß Regelausführungen
nicht terminieren. Wird die Kaskadentiefe erreicht, so werden alle Transaktionen zurückgerollt.
48
Erweiterungskonzepte für das aktive DBMS
Erweiterungen der SQL-Triggersprache
Kapitel 6 Erweiterungen der SQL-Triggersprache
Erweiterungen der SQL-Triggersprache
Ein wesentliches Merkmal von ARTA II ist es, auf Ereignistypen reagieren zu können, auf die, mittels der SQL:1999 Triggersprache, nicht reagiert werden kann. Ein
in SQL:1999 erstellter Trigger kann nur auf das Eintreten eines Änderungsereignisses mit einer Aktion reagieren. Interessant war die Überlegung SQL:1999 so
zu erweitern, das Trigger auch auf zeitliche Ereignisse mit einer Aktion reagieren
konnten. Dazu mußte natürlich die Syntax der SQL:1999 Triggersprache um neue
Konzepte erweitert werden. Zum einen benötigt man neue Ereignistypen und zum
anderen neue Steuerungskomponenten, mit der das neue Unterfangen gelingen sollte. In den folgenden Abschnitten wird das neue Konzept vorgestellt. Es wird auf
die einzelnen Komponenten eingegangen und die Problematik nahegebracht.
Die Erweiterung der Triggersprache von SQL:1999 wurde erweitert um:
• Steuerungskomponenten (Deadline, Gültigkeitsintervall, Priorität,
Aktivierungszustand)
• Zeitereignisse (absolute und periodische ZE)
6.1 Steuerungskomponenten
Ein wichtiger Bestandteil eines Triggers sind seine Steuerungskomponenten ohne
die die Umsetzung der Zeitereignistypen nicht möglich wäre. Die Steuerungskomponenten dienen, wie der Name schon sagt, der Steuerung eines Triggers. Mit ihnen kann beim Erstellen eines Triggers angegeben werden, ob dieser aktiviert oder
deaktiviert ist oder durch die Angabe eines Gültigkeitsintervall sichergestellt werden, in welche Zeitspanne ein Trigger gefeuert werden darf. Weitere Komponenten
werden in folgenden Abschnitten erläutert.
6.1.1
Gültigkeitsintervalle
Will man Zeit darstellen, geschieht dies meistens mittels eines Zeitstrahls, wie in
Abbildung 6.2 zu sehen ist. Es gilt eine totale Anordnung der Zeitpunkte, d.h. für
jeweils zwei verschiedene Zeitpunkte t1 und t2 gilt: t1 < t2. Die Zeitachse des Zeitstrahls ist in beiden Richtungen unendlich. Für jeden beliebigen Punkt auf dieser
Zeitachse gilt, daß sich alle Punkte, die links des ausgewählten Punktes liegen, in
der Vergangenheit und alle Punkte, die rechts des ausgewählten Punktes liegen, in
seiner Zukunft befinden. Der Punkt selbst spiegelt dabei die Gegenwart wieder.
Eine wichtige Steuerungskomponente eines ARTA-Triggers ist die Angabe eines
Gültigkeitsintervalls. Mit start on date und start at time werden der Start des Intervalls, mit end on date und end at time das Intervallende angegeben. Nur innerhalb dieses Intervalls darf der Trigger gefeuert werden. Wird das Intervall überschritten, so wird der Trigger gelöscht, bzw. als abgearbeitet markiert und es erfolgt ein Eintrag in eine Protokolldatei. Im Zusammenhang mit einer Deadline
49
Erweiterungskonzepte für das aktive DBMS
Erweiterungen der SQL-Triggersprache
können verschiedene Grenzfälle auftreten, auf die in Abschnitt 6.1.3 eingegangen
wird.
start on date: 21.01.2004
start at time: 09:00
t1
t2
end on date: 03.04.2004
end at time: 10:30
…
tn
t
Abbildung 6.1: Das Gültigkeitsintervall
6.1.2
Deadlines
Die Deadline ist eine der wichtigsten Steuerkomponenten der ARTA-II Trigger.
Bei der Abarbeitung eines Triggers kann nie genau der Zeitpunkt angegeben werden, wann dieser seiner Arbeit beendet hat. Während dieser Abarbeitung können
weitere Trigger gefeuert werden, die aber warten müssen, da die Trigger in ARTA
sequentiell, also nacheinander abgearbeitet werden. So kann es vorkommen, daß
der Zeitpunkt für die Abarbeitung des Triggers verpaßt wird. Um dennoch diesen
Trigger behandeln zu können wird eine gewisse Zeittoleranz einkalkuliert, in der
der Trigger doch noch gefeuert werden darf. Diese Zeittoleranz wird berechnet aus
Ausführungszeitpunkt + (angegebenen) Deadline. Die Granularität der Deadline
wird in Minuten angegeben und ist standardmäßig auf 5 Minuten eingestellt. Trigger, die nicht innerhalb dieser Zeittoleranz ausgeführt wurden, werden nicht bearbeitet. Damit der Anwender dies auch mitbekommt, wird ein Protokolleintrag in
die Datenbank erstellt. Die Deadline ist auch eine wichtige Komponente in Bezug
auf das folgende Problem:
Das ARTA-DBMS wird in der Regel nicht ununterbrochen eingesetzt. In diesen
Ruhephasen, kann das System nicht auf bestimmt eintretende Zeitereignisse reagieren. Darum ist es wichtig für solche Trigger eine längere Deadline anzugeben. So
können nach Einschalten des Systems all diejenigen Trigger mit einer gültigen Aktivierungszeit (Ausführungszeitpunkt + Deadline) ausgeführt werden.
Grenzfälle für das Feuern eines Triggers
Was passiert mit den Triggern, die zwar eine gültige Zeittoleranz (Ausführungszeitpunkt + Deadline) haben, aber außerhalb der Gültigkeitsintervalls gefeuert
werden sollen? Darf ein solcher Trigger gefeuert werden? Was passiert mit einem
Trigger der innerhalb eines Gültigkeitsintervalls gefeuert wurde, aber die Abarbeitung so viel Zeit in Anspruch nimmt, daß der Beendigungszeitpunkt außerhalb des
Intervalls liegt? In beiden Fällen muß festgelegt werden, wie ARTA II mit solchen
Situationen umgehen soll. Wird ein Trigger innerhalb des Gültigkeitsintervalls gefeuert, so darf dieser auch bis zum Ende ausgeführt werden. Ein Trigger der warten
muß bis ein zuvor gefeuerter Trigger abgearbeitet ist und dabei trotz einer gültigen
Zeittoleranz außerhalb des Intervallendes liegt, wird nicht gefeuert.
50
Erweiterungskonzepte für das aktive DBMS
start on date: 21.01.2004
start at time: 09:00
Erweiterungen der SQL-Triggersprache
end on date: 03.04.2004
end at time: 10:30
deadline
t1
t2
…
tn
t
execute time of trigger
trigger react begin
Abbildung 6.2: Die Deadline
6.1.3
Prioritäten
Während der Abarbeitung eines Triggers kann es vorkommen, daß zwei Trigger
zum selben Zeitpunkt gefeuert werden. An dieser Stelle muß klar unterschieden
werden, welcher Trigger zuerst abgearbeitet werden darf und welcher Trigger warten muß. In SQL:1999 werden die Trigger nach ihrem Erstellungsdatum (Timestamp) sortiert. Nachdem ein SQL:1999-Trigger erstellt wurde, kann seine Ausführungsreihenfolge nicht mehr verändert werden. Um diese Situation in den Griff zu
bekommen, wurde in ARTA eine weitere Steuerungskomponente entwickelt und
zwar die Triggerpriorität. Diese legt eindeutig fest, welcher Trigger zuerst abgearbeitet werden darf. Zwei Trigger dürfen nicht dieselbe Priorität besitzen. So kann
sichergestellt werden, daß bei der Abarbeitung stets eine eindeutige Reihenfolge
eingehalten werden kann. Die Priorität wird erstmals beim Erstellen eines Triggers
automatisch gesetzt. Es wird die bereits höchste vergebene Priorität ermittelt und
um 1 erhöht. Man kann die Priorität eines Triggers jederzeit manuell über den Prioritätenmanager verändern, um auch nach Erstellung des Triggers zu bestimmen,
wie sich dieser in Bezug auf andere Trigger, was die Abarbeitungsreihenfolge betrifft, zu verhalten hat.
6.2 Zeitereignisse
In diesem Abschnitt wird die Syntax für Zeitregeln in ARTA II vorgestellt. Wie
schon zuvor erwähnt, wurde die SQL-Triggersprache um neue Zeitereignistypen
erweitert, d.h. die Trigger von ARTA II können, außer auf das Eintreten eines Änderungsereignisses, auch auf das Eintreten eines Zeitereignisses reagieren. Es werden zwei Arten von Zeitereignissen unterschieden. Die absoluten Zeitereignisse,
die durch einen absoluten Zeitpunkt angegeben werden und die periodischen Zeitereignisse, die durch eine Regel, wie jeden Sonntag um 23:59 Uhr beschrieben
werden. Beim Entwurf der periodischen Zeitereignisse wurde sorgsam eine Syntax
erstellt, mit der alle gängigen periodischen Zeitereignistypen abgedeckt werden.
Was sind gängige periodischen Zeitereignistypen? Im normalen Sprachgebrauch
werden oft Zeitangaben formuliert, die sich auf den ersten Blick nicht ohne weiteres Formulieren lassen, wie z.B.
51
Erweiterungskonzepte für das aktive DBMS
Erweiterungen der SQL-Triggersprache
• jeden dritten Tag um 11:00 Uhr
• alle zweieinhalb Stunden
• alle 20 Minuten
• jeden Sonntag jeder dritte Woche um 9:00 Uhr
• jeden ersten Januar des Jahres um 9:00
• jedes zweite Jahre am jeweils zweiten Samstag im Monat Januar um 09:00
Uhr.
• alle zwei Monate jeden Montag um 09:00 Uhr.
• alle zwei Monate an jedem ersten Sonntag um 09:00 Uhr.
• alle zwei Monate am 25.Tag des Monats um 09:00 Uhr.
Es sollte eine möglichst einheitliche Formulierung gewählt werden, die für sich
selbstsprechend ist, so daß der Anwender schon an der Syntax erkennen kann, wie
der Ausdruck zu formulieren ist. In den folgenden Abschnitten werden die Zeitereignistypen und ihre Syntax anhand von Beispielen vorgestellt.
6.2.1
Absolute Zeitereignistypen
Die einfachsten Zeitereignistypen, die in ARTA II existieren, sind die absoluten
Zeitereignisse. Dies sind einmalig eintretende Ereignisse, die mittels eines Datums
und einer Zeitangabe angegeben werden können. Ein absolutes Zeitereignismuster
wird mit dem Schlüsselwort ON eingeleitet, gefolgt vom Datum. Anschließend
wird die Zeitangabe mit dem Schlüsselwort AT eingeleitet.
absolute time event type
ON
date
AT
time
Abbildung 6.3: Absolutes Zeitereignis
6.2.2
Periodische Zeitereignistypen
Periodische Zeitereignisse in ARTA II werden in sechs verschiedene Perioden unterteilt. Diese, wie in der folgenden Abbildung zu sehen ist, unterteilen sich in die
Perioden Minute, Stunde, Tag, Woche, Monat und Jahr. Die Perioden Monat und
Jahr können wiederum unterteilt werden.
52
Erweiterungskonzepte für das aktive DBMS
Erweiterungen der SQL-Triggersprache
periodic time event type
minutes event type
hours event type
days event type
weeks event type
months event type
years event type
Abbildung 6.4: Verschiedene Perioden eines Zeitereignisses
Die periodischen Zeitereignistypen unterscheiden sich von den absoluten Zeitereignistypen dadurch, daß sie mehrmals zu eintretenden Zeitpunkten passen können.
Periodische Zeitereignistypen beginnen immer mit dem Schlüsselwort EVERY,
um den Unterschied zu den absoluten Zeitereignissen deutlich zu machen.
Bei einem Zeitereignis vom Typ Minute muß nur eine Minutenzahl angegeben
werden. Anhand des Startdatums des Gültigkeitsintervalls wird der nächste Ausführungstermin, der in der Zukunft liegt, berechnet. Liegt der berechnete Ausführungszeitpunkt außerhalb des Gültigkeitsintervalls, so wird dieser Trigger als abgearbeitet markiert und gelöscht.
minutes event type
EVERY
minutes
MINUTES
Abbildung 6.5: Zeitereignis der Periode Minute
Angenommen die Periode Minute wird mit 30 Minuten und das Gültigkeitsintervall
mit start at: 9:35 und end at: 11: 30 angegeben, dann wären die nächsten Ausführungstermine: 9:35 Uhr, 10:05 Uhr und 10:35 Uhr.
start on date: 21.01.2004
start at time: 09:35
end on date: 03.04.2004
end at time: 11:00
t
09:35
10:05
10:35
11:05
Abbildung 6.6: Wiederkehrende Minutenperiode
53
Erweiterungskonzepte für das aktive DBMS
Erweiterungen der SQL-Triggersprache
Auch beim Periodentyp Stunde wird anhand der Start- und Endzeit des
Gültigkeitsintervalls des nächsten Ausführungszeittermins berechnet. Mit dem
folgenden Konstrukt kann ein periodisches Zeitereignis der Form „alle 02 Stunden
um 30 Minuten nach“ angegeben werden. Für das folgende Beispiel ist das
Gültigkeitsintervall wie folgt angegeben: start at 9:35, end at 14:30. Nächster
Ausführungstermin wäre um 12:05 Uhr. Der anschließende Termin um 14:35 Uhr
liegt nicht mehr im Gültigkeitsbereich.
hours event type
2digit
EVERY
minutes
HOURS AT
MINUTES PAST
Abbildung 6.7: Zeitereignis der Periode Stunde
Mit dem Periodentyp Tag kann man einen Ausdruck in der folgenden Form formulieren: „alle 3 Tage um 9:00 Uhr“, was im normalen Sprachgebrauch „jeden dritten
Tag um 09:00 Uhr“ entspricht.
days event type
EVERY
3digit
DAYS AT
time
Abbildung 6.8: Zeitereignis der Periode Tag
Dieses Konstrukt erlaubt die Angabe eines Ereignisses, mit der Periode Woche.
Ein möglicher Ausdruck durch dieses Syntax wäre „alle 02 Wochen am Sonntag
um 09:00 Uhr“, was im normalen Sprachgebrauch „jede zweite Woche am Sonntag
um 9:00 Uhr“ entspricht.
weeks event type
EVERY
2digit
day of week
WEEKS ON
AT
time
Abbildung 6.9: Zeitereignis der Periode Woche
Interessant sind die Konstrukte vom Periodentyp Monat und Jahr. Diese werden in
weitere Untertypen unterteilt, um die verschiedenartigen und noch sinnige periodische Zeitereignistypen abzudecken. Der Periodentyp Monat läßt sich in drei und
der des Jahres in zwei Untertypen einteilen.
months event type
EVERY
2digit
EVERY
MONTHS ON
day of week
ordined 1stTo5th
ordined digit day
day of week
DAY
Abbildung 6.10: Zeitereignis der Periode Monat
54
AT
time
Erweiterungskonzepte für das aktive DBMS
Erweiterungen der SQL-Triggersprache
Für die Periode Monat können folgende Ausdrücke formuliert werden:
• alle 02 Monate an jedem Montag um 09:00 Uhr.
• alle 02 Monate an jedem ersten Sonntag um 09:00 Uhr.
• alle 02 Monate am 25.Tag um 09:00 Uhr.
Der letzte Periodentyp der angegeben werden kann, ist der des Jahres. Auch hier
wird zu jedem Konstrukt ein Beispiel angegeben.
years event type
EVERY
2digit
YEARS ON
ordined day
month of year
ordined number
day of week
IN
month of year
AT
time
Abbildung 6.11: Zeitereignis der Periode Jahr
Für die Periode Jahr können folgende Ausdrücke formuliert werden:
• alle 02 Jahre am ersten Januar um 09:00 Uhr oder
• alle 02 Jahre am zweiten Samstag im Januar um 09:00 Uhr.
6.2.3
Korrektheit
Die Angabe einer so großen Anzahl an Konstrukten verschafft dem Anwender eine
optimale Übersicht bei der Formulierung eines Triggers. Die Syntaxüberprüfung
bei der Eingabe eines Triggers, wird teils von den Steuerelementen selbst und teils
mit Hilfe von Routinen realisiert, die in die Eingabemaske implementiert wurden.
Abbildung 6.12: Steuerelement für die Vergabe einer Priorität
In Abbildung 6.12 ist ein Textfeld dargestellt, das bei der Erstellung dafür sorgt,
daß die Triggerpriorität automatisch gesetzt wird. Im Feld „Standardwert“ wird
eine Routine (siehe Abbildung 6.13) aufgerufen, die aus der Datenbank die höchstvergebene Triggerpriorität ermittelt. Dieser ermittelte Wert wird dann um 1 erhöht
55
Erweiterungskonzepte für das aktive DBMS
Erweiterungen der SQL-Triggersprache
und als Steuerelementinhalt des Attributes „priority“ in der Datenbank abgespeichert.
Abbildung 6.13: Routine zur Ermittlung der höchstvergebenen Priorität
Um zu überprüfen, ob die getätigte Eingabe in einem Textfeld korrekt ist, kann
nach der Eingabe (nach der Aktualisierung des Textfeldes) eine Ereignisprozedur
ausgelöst werden, die die falsche Eingabe zurücksetzt. Diese Routine ist in Abbildung 6.14 mit abgebildet. Der Undo-Befehl macht die Eingabe rückgängig, wenn
der eingegebene Wert kleiner oder gleich 0 ist. An dieser Stelle könnte noch ein
Dialogfenster geöffnet werden, um den Anwender mitzuteilen, was er falsch gemacht hat. Da aber die Priorität automatisch gesetzt werden soll, erübrigt sich eine
Meldung.
Aufruf einer Ereignisprozedur
Ereignisprozedur:
Abbildung 6.14: Eingabeüberprüfung über eine Ereignisprozedur
56
Erweiterungskonzepte für das aktive DBMS
Erweiterungen der SQL-Triggersprache
6.3 Syntax der ARTA II-Trigger
In diesem Kapitel wird die komplette Syntax der ARTA II-Trigger vorgestellt. Die
Syntax wurde aufgrund der Übersichtlichkeit farbig dargestellt.
<trigger definition> :: =
CREATE TRIGGER <trigger name><priority><interval><deadline>
ON <event type> REFERENCING <old or new values alias list>
IF
<condition>
DO <action>.
<trigger name> ::= <identifier–name>.
<priority> ::=<integer>.
<interval>::= <begin validity interval> <end validity interval>.
<deadline>::= <integer>.
<event type> :: =
<modification event type>
|<absolute time event type >
|<periodic time event type>.
<old or new values alias list> :: =
OLD
ROW
AS
OLD
TABLE
AS
NEW ROW
AS
NEW TABLE
AS
<old values correlation name>
<old values table alias>
<new values correlation name>
<new values table alias>.
<condition> :: = [
WHEN [<left parent><search condition><right parent>]
<triggered SQL Statement>
].
<action> :: =
FOR EACH {ROW | STATEMENT}.
<triggered SQL Statement>
| <VBA expression>.
57
Erweiterungskonzepte für das aktive DBMS
Erweiterungen der SQL-Triggersprache
<begin validity interval> ::= <date> <time>.
<end validity interval>
::= <date> <time>.
<modification event type> :: = <trigger action time><modification type>ON<table
name>
<trigger action time> :: =
BEFORE
|AFTER.
<modification type> :: =
INSERT
|DELETE
|UPDATE.
<table name> ::= <identifier-name>.
<absolute time event type> ::= ON<date>AT<time>.
periodic time event type > ::=
<minutes event type>
|<hours event type>
|<days event type>
|<weeks event type>
|<months event type>
|<years event type>.
<minutes event type> ::= EVERY<minutes>MINUTES.
<hours event type> ::= EVERY<2digit>HOURS AT<minutes>PAST.
<days event type> ::= EVERY<3digit>DAYS AT<time>.
<weeks event type> ::= EVERY<2digit>WEEKS ON <list day of week>AT<time>.
<months event type > ::=
EVERY<2digit>MONTHS ON EVERY<day of week>AT<time>.
|<EVERY<2digit>MONTHS ON<ordined>< day of week>AT<time>.
| EVERY<2digit>MONTHS ON<ordined digit day>DAY<time>.
<years event type > ::=
58
Erweiterungskonzepte für das aktive DBMS
Erweiterungen der SQL-Triggersprache
EVERY<2digit>YEARS ON<ordined day><month>AT<time>
|EVERY<2digit>YEARS ON<ordined number><day of
week>IN<month>AT<time>.
<old values correlation name> ::= <identifier-name>.
<old values table alias>
::= <identifier-name>.
<new values correlation name> ::= <identifier-name>.
<new values table alias>
::= <identifier-name>.
<left paren> <search condition><right paren> : Ja/Nein-Abfragen an die DB.
<triggered SQL Statement>: Ein SQL-Ausdruck.
<VBA expression>: Eine Routine in Visual Basic Appication.
<identifier-name> ::=
<letter>
| <identifier-name> <letter>
|<identifier-name> <digit0>.
<day of week> ::= monday | ... | sunday.
<month>
::= january | ... | december.
<3digit>
::= <digit0><digit0><digit>.
<2digit>
::= <digit0><digit>.
<date>
::= <digit days>.<digit months>.<digit years>.
<time>
::= <hours>:<minutes>.
<ordined>
:: = 1st | ... | 5th.
<ordined digit day> ::= 1st | ... | 31th .
<minutes>
::= 00 | ... | 59.
<digit hours>
::= 01 | ... | 23.
<digit days>
::= 01 | ... | 31.
<digit months> ::= 01 | ... | 12.
<digit years>
::= 1900 | ... | 2100.
<digit0>
::= 0 | ... | 9.
<digit>
::= 1 | ... | 9.
<letter>
::= a | ... | z | A | ... | Z.
<integer> ::= <digit> | <integer> <digit>.
<boolean> ::= TRUE | FALSE.
59
Erweiterungskonzepte für das aktive DBMS
Erweiterungen der SQL-Triggersprache
6.4 Semantik der ARTA II-Trigger
Die Abarbeitungsreihenfolge der ARTA-II Trigger entspricht der, der SQL:1999
Trigger, die in Kapitel 4.4 vorgestellt wurde. Hier eine kurze Zusammenfassung.
1.Ermittlung aller Before-Statement-Trigger
2.Ermittlung aller Before-Row-Trigger
3. Ausführen des Aktionsteils
4. Überprüfung der IB (constrains)
5. Ermittlung aller After-Row-Trigger
6. Ermittlung aller After-Statement-Trigger
6.4.1
Ausführungsreihenfolge von simultan ausgelösten Triggern
Nach der Ermittlung der Before- und After-Trigger, muß eine Reihenfolge für die
Abarbeitung der Trigger festgelegt werden. SQL:1999-Trigger werden nach ihrem
Erstellungsdatum und -uhrzeit sortiert und anschließend in dieser Reihenfolge abgearbeitet. Eine Änderung der Abarbeitungsreihenfolge ist nach Erstellen eines
Triggers nicht mehr möglich, es sei denn alle Trigger würden, unter Berücksichtigung des Erstellungsdatums, neu definiert werden. Dies setzt wiederum voraus, daß
schon am Anfang bekannt ist, welche Trigger benötigt werden.
Bei der Erstellung eines ARTA II-Triggers hingegen wird, bei der Erstellung eines
neuen Triggers, eine eindeutige Priorität vergeben, die später manuell verändert
werden kann. Die Trigger werden bei der Abarbeitung nach ihrer Priorität sortiert,
so daß ein Ablaufsreihenfolgenkonflikt vermieden werden kann. Der neue Aspekt
in ARTA II beruht auf der Möglichkeit, die Priorität nach Erstellung des Triggers
ändern zu können. Diese erleichtert die Arbeit mit den ARTA II-Triggern wesentlich, da sich nicht schon bei Erstellung des Triggers darum gekümmert werden
muß, in welchem Abarbeitungsreihenfolgenbezug dieser Trigger zu anderen Triggern steht.
6.4.2
Realisierung der Triggerkaskaden
In ARTA II können Regeln zu unterschiedlichen Zeitpunkten definiert werden. Das
Verhalten der so definierten Triggermenge und die Abhängigkeiten zwischen den
einzelnen Triggern sind schwer voraussehbar. So können z.B. innerhalb der Triggermenge Kaskaden entstehen, wenn durch die Ausführung einer triggernden Aktion Ereignisse eintreten und somit weitere Trigger ausgelöst werden. Diese Kaskaden können auch zyklisch verlaufen, wenn sich ein Trigger selbst direkt oder indirekt über andere Trigger auslöst. Durch die Existenz einer zyklischen Regelkaskade
besteht die Gefahr, daß die Regelverarbeitung nicht abbricht, d.h. daß während der
Verarbeitung immer wieder neue Regeln ausgelöst werden.
Es bedarf einer guten Planung und Übersicht bei der Erstellung eines Triggers, die
dank der gut strukturierten grafischen Benutzeroberflächen wesentlich erleichtert
wird. Trotzdem mußte eine Lösung gefunden werden, um mit Triggerkaskaden
60
Erweiterungskonzepte für das aktive DBMS
Erweiterungen der SQL-Triggersprache
umgehen zu können. ARTA-II kann solche Zyklen nicht erkennen. Um dennoch zu verhindern, daß die Regelverarbeitung nicht abbricht, wurde in ARTA-II die Tiefe der Regelkaskaden beschränkt.
6.4.3
Beschränkte Kaskadentiefe
Die Regelmenge wird in diesem Fall nicht analysiert. Statt dessen wird eine feste Zahl
vorgegeben, die festlegt, wie tief sich Trigger gegenseitig auslösen dürfen, d.h. wie tief
die Triggerkaskade sein darf. Beim Erreichen dieser Schranke wird die Verarbeitung
abgebrochen. Dabei können zwei Varianten unterschieden werden:
1. Der letzte Befehl wird zurückgesetzt.
2. Die ganze Transaktion wird zurückgesetzt.
Falls eine zyklische Regelkaskade existiert, so wird mit der Beschränkung garantiert,
daß die Verarbeitung terminiert. Die Festlegung einer Kaskadentiefe hat jedoch einige
Nachteile. So kann es z.B. vorkommen, daß eine gewünschte Regelverarbeitung eine
Kaskadentiefe von 10 aufweist, die festgelegte Grenze aber nur bei 5 liegt. Die gewünschte Kaskade könnte in diesem Fall nicht verarbeitet werden, obwohl diese nicht
zu einer Endlosverarbeitung geführt hätte.
6.4.4
Transaktionskonzept
TE.doAction
ControlSystemClose!chkEnableClose = FALSE
Set wks = DBEngine.WorkSpace.(0)
wks.BeginTrans
Set TEC AS New clsTExecute
TEC.executeSQL-Statement (TE.action)
TRUE
Error
wks.Rollback
FALSE
wks.CommitTrans
ControlSystemClose!chkEnableClose = TRUE
Abbildung 6.15: Transaktionskonzept
Ausgelöste SQL-Statements und Triggeraktion laufen in unabhängigen Transaktionen
ab. Die Bedingungsprüfung und die Aktionsausführung erfolgen innerhalb der Transaktion, die den Trigger anstößt. Kommt es bei der Aktionsausführung zu einem Fehler, so
61
Erweiterungskonzepte für das aktive DBMS
Erweiterungen der SQL-Triggersprache
werden alle Aktionen, einschließlich des auszulösenden Statements, zurückgesetzt
(Rollback). Im folgenden Programmablauf wird, vereinfacht dargestellt, der Ablauf einer Transaktion verdeutlicht. Mit Begin Trans wird die Transaktion eingeleitet. Nach
erfolgreicher Ausführung eines SQL-Statements werden mit Commit Trans, die Änderungen in der Datenbank festgeschrieben. Bei einem Fehler hingegen, wird die komplette Transaktion mit Rollback zurückgesetzt. Die Rekursion für die Triggerverarbeitung
findet in Execute.SQL-Statement statt.
62
Erweiterungskonzepte für das aktive DBMS
ARTA II
Kapitel 7 ARTA II
ARTA II
Ein gängiges Konzept beim Aufbau von Access-DB ist es, die Tabellen in Datenbank A
(Back-End genannt) zu speichern und die anderen Objekte einer Datenbank in der Datenbank B (Front-End) zu verwalten. Man spricht hier von geteilten Datenbanken. Dieses Konzept bietet folgende Vorteile:
Bei der Entwicklung von ARTA II wurden die Anwendungsdaten und das neue aktive
Datenbankverwaltungssystem voneinander getrennt. Die Anwendungsdaten und ARTA
II wurden in zwei separaten .mdb-Dateien gespeichert, siehe Abbildung 7.1. Grundsätzlich ist es besser Daten und Anwendungssystem zu trennen, so ist es z.B. bei einem
Versionswechsel einfacher, eine gezielte Datensicherung vorzunehmen ohne gleich das
ganze System mit abzuspeichern. Zudem ist es einfacher das alte System durch ein neues zu ersetzen, ohne gleich alle Anwendungsdaten zu verlieren. Die Datenbank, in der
die Anwendungsdaten liegen, nennt man in einer geteilten Datenbank Back-End und die
Datenbank, die das Anwendungssystem beinhaltet Front-End.
ARTA II soll anhand eines Diplomprüfungsamtsystems vorgestellt werden. Folglich
befinden sich in der Data-Application.mdb die Daten zu den Studenten und deren Abgabefristen für eine angemeldete Diplomarbeit. Zusätzlich werden die angelegten Trigger, Ereignismuster, vordefinierten SQL-Statements, sowie eine Ereignisprotokollierung
abgespeichert. Diese Tabellen sind mit dem ARTA II-System verknüpft, so daß eine
Verbindung zwischen dem System und den Daten besteht. Bei einer Verknüpfung wird
eine Kopie der Tabellen in der Datenbank gespeichert.
Data-Application.mdb
ARTA II.mdb
(DBMS)
(ADBMS)
DB
Abbildung 7.1: ARTA II-Dateistruktur
Möchte man einen neuen Studenten oder zu einem bestehenden Studenten die Abgabefristen für die Anmeldung einer Diplomarbeit in die Datenbank eintragen, so geschieht
dies über das ARTA II-System. Dort können mit Hilfe eines Terminals SQLAnweisungen formuliert werden, die dann vom ARTA II-System ausgeführt werden.
Nur so können Datenbankänderungen vom System erkannt bzw. abgefangen und darauf
reagiert werden. In der folgenden Abbildung wird die ARTA II-Systemarchitektur mit
ihren Komponenten vorgestellt. In den darauf folgenden Abschnitten werden die einzelnen Komponenten in ihrer Arbeitsweise, zum Teil durch Programmablaufpläne (PAP),
dargestellt.
63
Erweiterungskonzepte für das aktive DBMS
ARTA II
7.1 Schichtenarchitektur
ARTA II – DBMS
Timer
SQL-Statement
Manager
Data Application
Trigger
Execution
Event
Manager
GUI
Data
Trigger
Manager
Trigger
Event
SQLStatements Log
Time Event
Manager
Event Type
Manager
Abbildung 7.2: Architekturdiagramm von ARTA II
Die Komponenten von ARTA II, die das passive DBS in ein aktives überführen, werden
wie eine aktive Schicht über das Datenbanksystem gelegt. Sämtliche Befehle eines Benutzers gelangen durch die aktive Schicht an die darunterliegende Datenbank und alle
Daten aus der Datenbank werden durch die Schicht hindurch an den Benutzer weitergereicht. Somit sind sämtliche Informationen in der Schicht verfügbar, die für die Regelausführung notwendig sind. Dieser Ansatz wird auch layered architecture genannt.
• Vorteile: Ein DBS kann ohne Modifikation in ein ADBS umgewandelt werden.
• Nachteile: Es besteht die Gefahr von geringer Performance, da der Kommunikationsaufwand zwischen der aktiven Schicht und der Datenbank hoch sein kann.
ARTA II besteht im wesentlichen aus zwei Subsystemen, die miteinander kommunizieren. Diese Systeme sind die grafische Benutzerschnittstelle (Graphic User Interface,
abgek. GUI), mit welchem die Benutzer arbeiten, und das Verarbeitungssystem
(Processing System), in dem die Regeln modelliert, analysiert, abgelegt und verarbeitet
werden. Das Verarbeitungssystem ist mit dem zugrundeliegenden DBS verbunden. Jeder Benutzerbefehl gelangt durch die grafische Benutzerschnittstelle in das Verarbeitungssystem, in dem Regeln, die durch die Benutzerbefehle ausgelöst werden, in die
Verarbeitung mit einfließen. Die notwendigen Regelaktionen sowie die Benutzerbefehle
selbst, werden sodann auf der darunterliegenden Datenbank ausgeführt.
64
Erweiterungskonzepte für das aktive DBMS
ARTA II
7.2 Systemarchitektur
SQL-Statement
Manager
Event
Manager
SQLStatements
Trigger
Execution
Event Log
GUI
Trigger
Manager
Trigger
Time Event
Manager
Event Type
Manager
Event
Types
Event Log
Timer
Abbildung 7.3: ARTA II: Systemkomponenten
ARTA II besteht aus einer grafischen-, vier Schema- und zwei Ausführungskomponenten, die untereinander in Verbindung stehen. Die GUI ist die grafische Komponente und
die Schnittstelle zur Kommunikation zwischen Anwender und ARTA-System. Die
Hauptaufgabe der GUI ist die grafische Aufbereitung, sowie die Unterstützung der Daten beim Erstellen, Ändern und Löschen. Die Erstellung der grafischen Benutzeroberflächen verlangt viel Fingerspitzengefühl, um komplizierte Zusammenhänge einfach
und verständlich darzustellen.
Die ARTA II-Schemakomponenten dienen hauptsächlich der Verwaltung, also der Erstellung, Modifizierung und Löschung von Daten. Im folgenden werden die vier Schemakomponenten kurz vorgestellt.
Der SQL-Statement Manager, der zusammen mit dem Event Type Manager und dem
Trigger Manager zur Schemakomponente gehört, dient hauptsächlich der Verwaltung
manuell eingegebener SQL-Statements. Möchte ein Anwender einen Datensatz manipulieren, so geschieht dies über eine Art Terminal, mit welchem SQL-Statements formuliert und ausgeführt werden können. Darüber hinaus können formulierte SQLStatements in die Datenbank abgespeichert werden und stehen dann dem Anwender bei
der Formulierung neuer Statements zu Verfügung. Dieser Manager dient somit zum
einen der Verwaltung von SQL-Statements und zum anderen besteht seine Aufgabe
darin, eingegebene Befehle abzufangen, sie auf ihre Richtigkeit hin zu überprüfen und,
falls diese Korrekt sind, an die Trigger Execution weiter zu reichen. Falls die Trigger
Execution mit einem anderen Befehl beschäftigt ist, so wird der auszuführende Befehl
65
Erweiterungskonzepte für das aktive DBMS
ARTA II
als nicht ausgeführt protokolliert und zurückgewiesen. Der Benutzer kann sofort die
Protokolldatei einsehen, um entsprechende Gegenmaßnahmen durchzuführen.
Der Event Type Manager verwaltet Ereignismuster. Bei der Erstellung eines Triggers
können die auslösenden Ereignisse für einen Trigger als Muster gesondert abgespeichert
werden. Diese stehen später bei der Erstellung eines neuen Triggers als Auswahlliste
zur Verfügung. So können in der Ereignismusterübersicht alle Trigger, die ein gemeinsames Ereignismuster besitzen, gruppiert angezeigt werden.
Der Event Manager verwaltet eine Protokolldatei, in der alle abgearbeiteten oder nicht
abgearbeiteten Trigger protokolliert werden. Zu einem Eintrag werden Triggername,
Ausführungszeitpunkt, Erfolgs-, bzw. Mißerfolgsmeldung und ein Timestamp eingetragen. Dieses Protokoll kann ausgedruckt werden.
Der Trigger Manager ist eine der wichtigsten Komponenten, mit dem die ARTA IITrigger verwaltet werden. Der Trigger Manager sorgt bei der Erstellung eines Triggers
von Typ Zeitereignis (TE-Trigger) dafür, daß dieser vom Time Event Manager bei der
Verarbeitung mit berücksichtigt wird. Bei der Erstellung eines TE-Triggers wird vom
Trigger Manager der nächste Ausführungszeitpunkt berechnet und zusammen mit dem
Trigger in die Datenbank gespeichert. Weitere Aufgaben dieser Komponente sind die
Überprüfung auf Korrektheit bei der Erstellung, Modifizierung sowie der Löschung
eines Triggers.
Die ARTA II-Ausführungskomponenten (Time Event Manager und Execution Manager) werden in den folgenden zwei Abschnitten genauer betrachtet, da sie das Kernstück
des Systems bilden.
7.3 Time Event Manager
Trigger
Manager
Trigger
Execution
TIME EVENT MANAGER
Time Event
Trigger
ProcessOldTimeEvents
ProcessNewTimeEvents
Event Log
Timer
Abbildung 7.4: Der Time Event Manager und seine interagierenden Komponenten
66
Erweiterungskonzepte für das aktive DBMS
ARTA II
Der Time Event Manager dient der Zeitereigniserkennung und Verarbeitung von Triggern vom Typ Zeitereignis (TE-Trigger). Die Komponenten, die mit diesem Verwaltungssystem interagieren sind der Trigger Manager und die Trigger Execution. Wird der
Time Event Manager gestartet, so werden zunächst alle „alten“ TE-Trigger und anschließend alle in der Zukunft liegenden TE-Trigger verarbeitet. Genaueres dazu in den
folgenden Routinen.
Bei der Erstellung eines Triggers vom Typ periodisches Zeitereignis, wird durch den
Trigger Manager automatisch, anhand eines Gültigkeitsintervalls und einer Periode, der
nächste Ausführungszeitpunkt berechnet und mit dem Trigger zusammen in der Datenbank abgespeichert. Bei der Abarbeitung der Trigger durch den Time Event Manager,
werden diese Informationen und zusätzliche Steuerelemente der Trigger aus der DB
geladen, um eine Abarbeitungsreihenfolge zu berechnen. Über alle Aktionen die ausgeführt werden, wird Protokoll geführt, so daß der Anwender die Ausführungsschritte
überprüfen kann. Der Zeitereignismanager selbst benutzt die Timer-Funktion des Betriebssystems, die über die API-Schnittstelle bereit gestellt wird, um Aufgaben in der
Zukunft zu planen. Nachdem ein TE-Trigger verarbeitet wurde, wird sein Status geändert. Dies geschieht in einer Routine namens Change Status, die im folgenden vorgestellt wird.
TE.ChangeStatus
TRUE
TE.isAbsolute
FALSE
TE.isPeriodic
FALSE
TRUE
TE.computeNextExecution
t1:= TE.nextExecution
t2 := Date(TE.EndOnDate, TE.EndOnTime)
t1 > t2
TRUE
TE.beDone
= FALSE
FALSE
TE.beDone = TRUE
Abbildung 7.5: PAP Change Status
Change Status: Die Zeitereignisse, auf welche ARTA II-Trigger reagieren können,
sind absolute und periodische Zeitereignisse. Der Time Event Manager verarbeitet die
Trigger vom Typ periodisches Zeitereignis (PTE-Trigger) und die vom Typ absolutes
Zeitereignis (ATE-Trigger) bis auf einen Unterschied in gleicher Weise. Der Unterschied besteht darin, daß nach Abarbeitung eines PTE-Triggers sein nächster Ausfüh67
Erweiterungskonzepte für das aktive DBMS
ARTA II
rungstermin berechnet wird, während ATE-Trigger nach der Abarbeitung sofort als abgearbeitet (beDone=TRUE) markiert werden. Nach der Berechnung des nächsten Ausführungstermins, wird für einen PTE-Trigger überprüft, ob sein berechneter Ausführungstermin innerhalb des angegebenen Gültigkeitsintervalls liegt. Zur Ermittlung wird
das Intervallende mit dem Ausführungszeitpunkt verglichen. Ist der Ausführungstermin
echt kleiner, so wird dieser noch ausgeführt, ansonsten wird der Trigger als abgearbeitet
markiert.
ProcessNewTimeEvents: Diese Routine führt zunächst eine Initialisierung durch. Dabei wird unter anderem der Timer initialisiert, auch wenn zuvor bereits einer gesetzt
wurde. Anschließend wird eine Anfrage (getNextTE) an die DB gestellt, um anhand der
Priorität und dem Ausführungstermin, den nächsten TE-Trigger zu ermitteln. Falls es
keinen Trigger gibt, der ausgeführt werden soll, wird ein interner Timer (auf 24 Stunden) gesetzt, so daß nach Ablauf des Timers erneut mit der Ermittlung begonnen wird.
Wird jedoch ein Trigger gefunden, so wird für diesen ein Timer zum nächsten Ausführungstermin gesetzt. Sobald sich der Timer meldet, was unter Umständen eine Weile
dauern kann, muß festgestellt werden, ob es sich beim zuvor gesetzten Timer um einen
internen oder normalen Timer gehandelt hat. Handelte es sich um einen normalen Timer, so wird dieser an die Ausführungskomponente (TE.doAction) weitergereicht. Nach
der Abarbeitung des Triggers durch die Ausführungskomponente, wird ein Eintrag in
die Protokolltabelle geschrieben, der Status des Triggers geändert (ChangeStatus) und
dieser anschließend aus der Datenbank gelöscht, falls er zuvor als abgearbeitet markierten wurde. Anschließend wird der Time Event Manager neu gestartet, um den nächsten
TE-Trigger zu ermitteln.
processNewTimEvent
initAllTE
TE:= getNextTE
TRUE
setTimer
(one Day)
FALSE
TE = Ø
processOldTimeEvents
setTimer
(TE.nextExecution)
deleteBeDoneTrigger
TE.ChangeStatus
wait until Timer bells
writeLog (TE)
TRUE
TE = Ø
FALSE
TE.doAction
TE:= (SELECT TimeEventTrigger FROM tbl_Trigger
WHERE Trigger.nextExecution + Trigger.Deadline > Now()
AND Trigger.beDone = FALSE
AND Trigger.activated = TRUE
ORDER BY Max (Trigger.priority))
Abbildung 7.6: PAP ProccesNewTimeEvent
68
Erweiterungskonzepte für das aktive DBMS
ARTA II
Bei der Erstellung eines neuen TE-Triggers durch den Anwender, kann es vorkommen,
daß der neue TE-Trigger vor dem TE-Trigger ausgeführt werden soll, für den schon ein
Timer gesetzt wurde. Um dieses Problem in den Griff zu bekommen, muß nach der Erstellung oder Modifizierung eines TE-Triggers der Time Event Manager vom Trigger
Manager neu gestartet werden. Dabei wird der Timer neu initialisiert. Da die Trigger in
der Datenbank immer aktuell sind (z.B. nach dem Erstellen oder Modifizieren eines
Triggers durch den Trigger Manager), stehen beim Start dieser Komponente immer die
aktuellen Trigger zur Verfügung. Die abgespeicherten Trigger in der Datenbank dienen
dem Time Event Manager als aktuelle Ausführungsliste, da bei jedem TE-Trigger der
nächste Ausführungstermin und seine Priorität bekannt sind.
Bei der Abarbeitung eines TE-Triggers kann die folgende Situation eintreten: Zum Zeitpunkt 13.04.2005 um 9:00 sollen drei TE-Trigger gefeuert werden. Dieser Zeitpunkt
wird als Soll-Ausführungszeitpunkt bezeichnet. Die Ausführungsreihenfolge ist aufgrund der eindeutigen Priorität für jeden Trigger gegeben. Es darf immer nur ein Trigger gleichzeitig ausgeführt werden. Die Abarbeitungsreihenfolge ist durch die Priorität
der Trigger gegeben. So sollen Tr1 vor Tr2 und Tr2 vor T3 ausgeführt werden. Da immer nur ein Trigger gleichzeitig abgearbeitet werden darf und erst mit Beendung der
Abarbeitungszeit eines Triggers der nächste zum Zuge kommt, kann es zum folgenden
Problem kommen.
Angenommen der erste Trigger habe eine Deadline von 60, der zweite eine von 120 und
der dritte eine von 180 Minuten. Da die Bearbeitungszeit eines Triggers nach dessen
Feuern unterschiedlich lang ausfallen kann, ist nie genau vorhersagbar, wann dieser
seine Arbeit beendet.
Soll-Ausführungszeitpunkt aller drei Trigger
Tr1.priorität = 1
Tr2.priorität = 2
09:00
10:00 11:00
Tr3.priorität = 3
12:00
Tr1
t
Tr2
t
t
Tr3
benötigte
Abarbeitungszeit
Deadline
Tr1
Tr2
Tr3
Ist-Ausführungszeitpunkt aller drei Trigger
Abbildung 7.7: Ausführungszeitpunkt
Wenn der erste Trigger seine Arbeit um 9:00 Uhr beginnt und sie erst um 11:05 beendet, findet die Routine getNextTE den dritten Trigger, während der zweite ignoriert
wird, da dieser nur bis 11:00 Uhr ausgeführt werden durfte. Da der ignorierte Trigger
nicht gefunden wurde, wurde sein Zustand durch die Routine ChangeStatus auch nicht
geändert. D.h. er wurde nicht als abgearbeitet markiert, es fand kein Protokolleintrag
statt und der Trigger wurde nicht aus der Datenbank gelöscht. Eine Lösung des Problems liegt nahe. Nach Abarbeitung der Trigger müssen eventuell nicht abgearbeitete
69
Erweiterungskonzepte für das aktive DBMS
ARTA II
und noch aktive Trigger gesammelt und behandelt werden. Dies geschieht mit einer
Routine namens processOldTimeEvents, die im folgenden Abschnitt vorgestellt wird.
Ein weiterer Grund für die Erstellung dieser Routine wird klar, wenn folgende Situation
betrachtet wird:
Das ARTA-System kann in seiner Ruhepause, d.h. zu den Zeiten, zu denen das System
ausgeschaltet ist, nicht auf eintretende vordefinierte Zeitereignisse reagieren. Diese Reaktion sollte nach dem Start des Systems erfolgen. Dafür benötigt man eine Routine, die
die „alten“ TE-Trigger sammelt und gegebenenfalls ausführt.
ProcessOldTimeEvents: Mit getAllOldTimeEvents werden alle TE-Trigger aus der
Datenbank geladen, dessen Ausführungszeitpunkte in der Vergangenheit liegen. Außerdem müssen diese Trigger aktiviert und der Bearbeitungsstatus (BeDone) auf FALSE
gesetzt sein. Nach der Ermittlung dieser Liste wird überprüft ob diese leer ist. Falls ja,
so gibt es keine „alten“ TE-Trigger und die Routine ist beendet. Falls die Liste nicht leer
ist, so wird der erste TE-Trigger aus der Liste genommen und bearbeitet. Liegt der Zeitraum, in dem der Trigger ausgeführt werden soll in der Vergangenheit, so wird dieser
Trigger als abgearbeitet markiert, protokolliert und aus der Datenbank gelöscht. Liegt
der Zeitraum in der Zukunft, so wird der Aktionsteil des Triggers, nach erfolgreicher
Auswertung der Triggerbedingung, ausgeführt und sein Status anschließend geändert.
Nachdem ein Trigger abgearbeitet wurde, wird der nächste aus der Liste genommen, bis
diese komplett leer ist.
processOldTimeEvents
allTE:= getAllOldTimeEvents
TRUE
allTE = Ø
FALSE
TE := allTE.first
nextT := TE.nextExecution + TE.deadLine
FALSE
nextT > Now
TRUE
FALSE
TE.cond
is OK
TE:= allTE.MoveNext
TRUE
TE.doAction
deleteBeDoneTrigger(TE)
TE.ChangeStatus
writeLog (TE)
processNewTimEvent
allTE = List of Time Event
WHERE Trigger.nextExecution < Now
AND Trigger.beDone = FALSE
AND Trigger.activated = TRUE
Abbildung 7.8: Process old time events
70
Erweiterungskonzepte für das aktive DBMS
ARTA II
Die doAction-Routine (siehe Abbildung 6.15) sorgt dafür, daß die Ausführung des
Triggers nicht durch den Benutzer unterbrochen wird. Dafür wird im Hintergrund ein
Formular geöffnet, das ein Schließen von ARTA II verhindert. Nach Beendigung des
Prozesses wird das Formular wieder geschlossen. Mit BeginTrans wird eine neue
Transaktion gestartet. Anschließend wird der Trigger an die Ausführungskomponente
weitergereicht. Tritt bei der Abarbeitung ein Fehler auf, so wird die komplette Transaktion mit Rollback zurückgesetzt. Mit CommtTrans wird nach einer erfolgreichen Ausführung des Triggers, die Änderungen in die Datenbank geschrieben. Im folgenden Abschnitt wird die Ausführungskomponente genauer beschrieben, die in dieser Routine
durch TEC.executeSQL-Statement(TE.action) gestartet wird. Diese Routine gehört zur
Trigger Execution-Komponente.
7.4 Trigger Execution
Diese Komponente dient der Verarbeitung eines SQL-Statements, das entweder vom
Time Event Manager oder aus einer manuellen Eingabe über den SQL-Statement Terminal an die Triggerausführungskomponente weitergereicht wurde. Die Abarbeitung
des SQL-Statements kann, wie zuvor erwähnt, zu Triggerkaskaden führen. Eine Abarbeitungsstrategie ist hier von relevanter Bedeutung.
SQL-Statement
Manager
SQL
Time Event Manager
TEC.initTEC(SQL)
Trigger
ExecuteBeforeOrAfterTrigger(Before,SQL)
executeAction (SQL)
Log
ExecuteBeforeOrAfterTrigger(After, SQL)
TRIGGER EXECUTION
Abbildung 7.9: Triggerausführungskomponente
Als erstes werden alle Before-Trigger, die vom SQL-Befehl gefeuert werden, gesammelt, nach ihrer Priorität sortiert und anschließend ausgeführt. ARTA II-Before-Trigger
dürfen keine weiteren Trigger feuern, so daß das Problem der Triggerkaskade nur bei
der Bearbeitung der After-Trigger aufkommen kann. Nachdem alle Before-Trigger ausgeführt wurden, wird das eigentliche SQL-Statement ausgeführt. Letztlich werden alle
After-Trigger, die nach ihrer Priorität sortiert werden, gesammelt und verarbeitet. Das
Ausführen eines After-Triggers kann ein weiteres Auslösen von Triggern zur Folge haben. Die Abarbeitung erfolgt rekursiv, so daß die Verarbeitung zuerst in die Tiefe geht.
71
Erweiterungskonzepte für das aktive DBMS
ARTA II
Sind alle Trigger einer Ebene abgearbeitet, so erfolgt die Bearbeitung der Trigger der
darüberliegenden Ebene. Die Routine TEC.executeSQL_Statement, (Abbilung 7.10), ist
die Routine die rekursiv bei der Abarbeitung der Trigger ausgelöst wird.
TEC. executeSQL_Statement (SQL)
TEC.initTEC(SQL)
ExecuteBeforeOrAfterTrigger(Before, SQL)
executeAction (SQL)
ExecuteBeforeOrAfterTrigger(After, SQL)
Abbildung 7.10: executeSQL-Statement-Routine
Abbildung 7.11 zeigt die Routine, mit der alle Before- und After-Trigger bearbeitet
werden. Abbildung 7.12 und Abbildung 7.13 zeigt die Bearbeitung der Row- und Statement Lever-Trigger.
ExecuteBeforeOrAfterTrigger(ActionTime, SQL)
allTrs := allModifyEvent.getTriggers & _
(ActionTime,modificationType,tablename)
TRUE
allTrs
=Ø
FALSE
Tr := allTrs.First
TRUE
Tr is
Row
FALSE
ExecuteRowLevelTrigger(Tr)
ExecuteStatementLevelTrigger(Tr)
allTrs.Remove(Tr)
TRUE
allTrs
=Ø
FALSE
TEV:= ATEVs.MoveNext
Abbildung 7.11: ExecuteBeforeOrAfterTrigger-Routine
72
Erweiterungskonzepte für das aktive DBMS
ARTA II
ExecuteRowLevelTrigger(Tr)
tec.MoveFirstRow
TRUE
tec.EOL
FALSE
FALSE
tec.cond(Tr)
TRUE
Call ExecuteAction(tec.makeAction(Tr)
tec.MoveNextRow
Abbildung 7.12: ExecuteRowLevelTrigger-Routine
ExecuteStatementLevelTrigger(Tr)
FALSE
tec.cond(Tr)
TRUE
Call ExecuteAction(tec.makeAction(Tr)
Abbildung 7.13: ExecuteStatementLevelTrigger-Routine
73
Erweiterungskonzepte für das aktive DBMS
ARTA II
Die letzte Routine die hier vorgestellt wird ist Routine, mit der der Aktionsteil ausgeführt wird. Vor der Ausführung, wird das Statement auf seine Korrektheit hin überprüft.
executeAction (action)
isNull(action)
TRUE
LOGFILE:
„Aktionsteil ist leer“
FALSE
isValid(action) FALSE
LOGFILE:
„Aktionsteil ist ungültig “
TRUE
LOGFILE:
„Ausführung des Aktionsteils“
CurrentDB.Execute action
Abbildung 7.14: ExecuteAction-Routine
74
Erweiterungskonzepte für das aktive DBMS
GUI
Kapitel 8 GUI
GUI
Die grafische Benutzeroberfläche ist eine der wesentlichen Erweiterungen des ARTA
II-Systems. Ziel war es, übersichtliche Benutzeroberflächen zu implementieren, so daß
der Benutzer sich ohne großen Aufwand schnell zurecht finden kann. Der Benutzer soll
interaktiv mit den Masken agieren. Dazu wurden alle Oberflächenobjekte möglichst
selbstsprechend eingesetzt um eine einfache und fehlerfreie Generierung eines Triggers
zu ermöglichen. Benutzerfreundlichkeit und einfache Bedienung standen bei der Implementierung der grafischen Benutzeroberflächen an höchster Stelle.
Die Schemakomponenten, die den logischen Teil der Benutzeroberflächen bilden, sind
der Trigger-, Event Log-, Event Type- und SQL-Statement Manager. Diese liegen in
Form von Ereignis- und Anwendungsprozeduren vor. Mit ihrer Hilfe werden Eingabeüberprüfungen, interne Berechnungen, Meldungen, Protokollierungen sowie Datensatzoperationen durchgeführt.
Ein Beispiel für eine Berechnung, die der Trigger Manager ausführt, ist die Kalkulation
des nächsten Ausführungstermins eines Triggers, anhand der eingestellten Periode (gilt
nur für Trigger vom Typ periodisches Zeitereignis) oder die Gültigkeitsüberprüfung
des eingestellten Gültigkeitsintervalls (siehe Trigger Editor). Einfache Eingabeüberprüfungen werden über die Gültigkeitsüberprüfung realisiert, die die Steuerelemente selbst
anbieten.
8.1 ARTA II-Menüstruktur
Für ARTA II wurden verschiedene grafische Benutzeroberflächen implementiert, die
die Arbeit mit den ARTA II-Triggern erleichtern sollen. In diesem Abschnitt wird eine
kurze Übersicht über die ARTA II- Menüstruktur gegeben und ihre Aufrufstruktur gezeigt. In den folgenden Abschnitten werden die einzelnen Benutzeroberflächen vorgestellt.
Beim Start von ARTA II gelangt man zum ARTA II-Hauptfenster. Dieses Fenster
wird erst mit der Beendung von ARTA II geschlossen. Vom Hauptfenster aus gelangt
man zur Trigger- und Ereignismusterübersicht, sowie zum SQL-Statement Terminal.
Die Triggerübersichtsoberfläche dient der Anzeige aller vorhandenen Trigger. Es
kann ein speziell ausgewählter Trigger betrachtet werden. Ist dieser vom Typ Zeitereignis, so wird auch der nächste Ausführungszeitpunkt angezeigt, da diese im voraus berechnet werden. Aus dieser Maske heraus ist es auch möglich einen Trigger zu löschen.
Möchte man einen Trigger neu anlegen oder einen existierenden bearbeiten, so kann
von hier aus der Triggereditor aufgerufen werden.
75
Erweiterungskonzepte für das aktive DBMS
GUI
Hauptfenster
Triggerübersicht
Ereignismusterübersicht
SQL-Statement-Terminal
Triggereditor
Ereignismustereditor
SQL-Statementeditor
Abbildung 8.1: ARTA II-Menüstruktur
Der Triggereditor ist die wichtigste Benutzeroberfläche von ARTA II. Aus dieser Oberfläche heraus können Trigger auf eine recht einfache Art und Weise erstellt werden
ohne daß der Benutzer die genaue Syntax eines Triggers kennen muß. Dazu mehr in den
folgenden Abschnitten.
Wie erwähnt gelangt man aus dem ARTA II-Hauptfenster in die Ereignismusterübersicht. Sie dient der Anzeige aller Trigger gruppiert nach ihrem Ereignistyp. So erhält
man z.B. eine Übersicht über alle Trigger, die am ersten Sonntag des Monats gefeuert
werden sollen. Oft benutze Ereignistypen sollten als Ereignismuster definiert werden,
was der Übersichtlichkeit zu Gute kommt.
Über einen Ereignismustereditor können Ereignismuster geändert, neue erstellt oder
gelöscht werden. Das Anlegen eines Ereignismusters kann auch beim Anlegen eines
Triggers erfolgen.
Die SQL-Statementoberfläche, die auch aus dem ARTA II-Hauptfenster heraus aufgerufen werden kann, bietet dem Benutzer die Möglichkeit, Befehle in Form von SQLStatements „direkt“ an die Datenbank abzusetzen. Dieses Fenster bietet eine Art Terminal an, um SQL-Befehle einzugeben und auszuführen. Jeder Befehl, der über das Terminal eingegeben wurde, wird vom ARTA-System zur Ereigniserkennung abgefangen.
Nur so kann eine korrekte Triggerverarbeitung sichergestellt werden. Um die Eingabe
76
Erweiterungskonzepte für das aktive DBMS
GUI
eines SQL-Befehls zu erleichtern, können SQL-Befehle abgespeichert werden so daß
sie bei der Eingabe als Auswahlliste zur Verfügung stehen. Die Erstellung, Modifizierung und Löschung eines SQL-Statements erfolgt über den SQL-Statement Editor, der
von der SQL-Statementoberfläche aus aufgerufen werden kann.
8.2 Triggerübersichtsoberfläche
1
4
2
3
Abbildung 8.2: Triggerübersicht
Dieses Fenster ist in zwei Bereiche unterteilt. Im oberen Bereich ist eine Übersichtsliste
aller vorhandenen Trigger implementiert worden. Die wichtigsten Angaben dieser Liste
sind der Triggername, Triggertyp und der nächste Ausführungszeitpunkt bei einem
Trigger vom Typ Zeitereignis. Wird ein Trigger aus der Liste markiert, so erscheinen
seine Einstellungen im unteren Bereich des Fensters. Hier werden detaillierte Informationen zum ausgewählten Trigger angezeigt. Wichtig ist dabei, daß der Aufbau der Anzeige, der Triggersyntax nahezu entspricht. Dieser Teil des Fensters wurde wiederum in
vier Teilbereiche unterteilt. Bereich 1 stellt das triggernde Ereignis, Bereich 2 die Auslösebedingung, Bereich 3 die zu triggernde Aktion und Bereich 4 die Steuerelemente
dar. Im unteren Rand der Oberfläche wurde ein Kommentarfeld integriert, in das Bemerkungen zum Trigger angezeigt werden.
77
Erweiterungskonzepte für das aktive DBMS
GUI
8.3 Triggereditor
1
2
5
3
4
Abbildung 8.3: Triggereditor
Der Triggereditor ist wie bereits erwähnt die wichtigste Benutzeroberfläche des ARTA
II-Systems. Mit ihm lassen sich Trigger erstellen und modifizieren. Darüber hinaus läßt
sich das zu triggernde Ereignis, einmal eingegeben, als Ereignismuster speichern.
Der Triggereditor ist in fünf Bereiche unterteilt. In Bereich 1 kann ein Triggername
vergeben und das Gültigkeitsintervall eingestellt werden. Bei der Eingabe des Gültigkeitsintervalls wird, mit Hilfe einer Kalenderfunktion, die Eingabe wesentlich erleichtert. Der Trigger Manager prüft das eingegebene Gültigkeitsintervall auf seine Richtigkeit. Es ist z.B. nicht möglich ein Intervallende anzugeben, das vor dem Intervallstart
liegt.
Abbildung 8.4: Bereich 1
78
Erweiterungskonzepte für das aktive DBMS
GUI
In Bereich 2 wird der Triggertyp ausgewählt. Hier kann aus einer Auswahlliste auf bereits vorhandene Ereignismuster zurückgegriffen werden.
Abbildung 8.5: Bereich 2
In Bereich 3 wird das zu triggernde Ereignis eingestellt. Abhängig vom gewählten Ereignistypen ergeben sich verschiedene Einstellungsmöglichkeiten. In den folgenden
zwei Abbildungen sind ein Änderungsereignis und ein periodisches Zeitereignis vom
Typ Jahr dargestellt.
Abbildung 8.6: Bereich 3: Änderungsereignis
Abbildung 8.7: Bereich 3: periodisches Zeitereignis vom Typ Jahr
Bereich 3 ist der wohl wichtigste, was die Gestaltung der Oberfläche betrifft. Bei der
Gestaltung wurde der Aspekt der Benutzerfreundlichkeit nicht nur für den Anwender,
sondern auch für den Entwickler in Betracht gezogen. Es müssen eine große Anzahl an
Steuerelementen, abhängig vom ausgewählten Ereignistyp oder der Periode, ein- bzw.
ausgeblendet werden. In den folgenden Abbildungen soll verdeutlicht werden wie groß
die Anzahl an Steuerelementen ist, die verwendet werden. Bei so einer großen Anzahl
an Steuerelementen taucht das folgende Problem auf. Wie legt man diese Anzahl an
Objekten so an, daß sie für einen Benutzer in der Formularansicht eine benutzerfreund79
Erweiterungskonzepte für das aktive DBMS
GUI
liche Eingabe erlauben und im Formularentwurf dem Entwickler ein einfaches Ändern
der Objekte ermöglichen. Es mußte für den Entwickler eine Möglichkeit gefunden werden die Steuerelemente auf dem Formular so anzubringen, daß diese nicht übereinander
liegen. So müssen bei einer Änderung an einem Steuerelement nicht alle darüberliegenden verschoben werden, was die Übersichtlichkeit beim Formularentwurf sehr beeinträchtigen würde.
Abbildung 8.8: verschieden Einstellungen für Bereich 3
Die Lösung dieses Problems war die Benutzung eines Registersteuerelementes, was
hierfür zweckentfremdet wurde. Der Anwender bekommt davon nichts mit, da es für ihn
stets unsichtbar geschaltet ist. Der Entwickler hingegen benutzt dieses Registersteuerelement, um die verschiedenen Steuerelemente, die zu einem Ereignistyp und gegebenenfalls zu einer Periode gehören, zusammenzuhalten. Die Reiter des Registersteuerelementes sind nach Typ bzw. Periode bezeichnet, was in der folgenden Abbildung verdeutlicht wird.
80
Erweiterungskonzepte für das aktive DBMS
GUI
Abbildung 8.9: Registersteuerungselement, Seite Jahr
In Bereich 4 wurden aus Platzgründen die Ausführungsbedingung, die zu triggernde
Aktion sowie ein Kommentarfeld in ein Registersteuerelement untergebracht. An den
Reitern kann zwischen den dreien ausgewählt werden. Um eine komfortablere Eingabe
zu ermöglichen, kann über eine Befehlsschaltfläche (Button) ein Editierfenster geöffnet
werden, was wesentlich mehr Platz und Übersicht bei der Erstellung einer Bedingung
oder auch eines Kommentars bietet.
Eingabefenster
Befehlsschaltfläche
Abbildung 8.10: Bereich 4
Bereich 5 ermöglicht die Modifikation der Deadline, die beim Erstellen eines Triggers
automatisch auf fünf Minuten gesetzt wird. Des weiteren kann eine Priorität für den
Trigger, sowie sein Aktivierungszustand verändert werden. Der Defaultwert für die Priorität ist die nächst höher verfügbare Priorität und der Default-Aktivierungszustand ist
auf aktiviert gesetzt.
Abbildung 8.11: Bereich 5
81
Erweiterungskonzepte für das aktive DBMS
GUI
8.4 SQL-Statement Terminal
Mit Hilfe dieser Benutzeroberfläche können SQL-Befehle direkt an die Datenbank gestellt werden. Das mittlere Fenster zeigt das Eingabefenster für die SQL-Befehle. Im
oberen Bereiche des Fensters ist eine Auswahlliste integriert, aus der vordefinierte SQLStatements ausgewählt werden können. Über einen Editor, der sich von diesem Fenster
aus öffnen läßt, können SQL-Statements vordefiniert oder geändert werden.
Abbildung 8.12: SQL-Statement Terminal
82
Erweiterungskonzepte für das aktive DBMS
GUI
Zusammenfassung
In dieser Arbeit wurde das bestehende ARTA-System weiterentwickelt. Die Triggersprache von ARTA II basiert auf der SQL-3-Triggersprache mit dem Unterschied, daß
in ARTA II nicht nur Änderungsereignisse, sondern auch Zeitereignisse unterstützt
werden. Dazu wurde die Syntax der SQL-3-Triggersprache um Zeitereignisse und Steuerungselemente erweitert. ARTA II kann auf absolute und auf periodisch eintretende
Zeitereignisse reagieren. Die Synchronisation der Abarbeitungsmechanismen von Änderungs- und Zeitereignissen ist dabei von relevanter Bedeutung.
Zeitereignisse sind im Gegensatz zu Änderungsereignissen prä-aktiv, d.h. sie werden im
voraus anhand der berechneten Ausführungszeitpunkte geplant. Für den jeweils nächsten Ausführungstermin eines Triggers vom Typ Zeitereignis wird ein Timer gesetzt. In
ARTA II wird die Timerfunktionalität des Betriebssystems genutzt, die über eine APISchnittstelle mit ARTA II kommuniziert, da Microsoft Access keine Timerfunktionalität besitzt. Datenbankänderungen hingegen sind post-aktiv, d.h. daß der nächste Ausführungszeitpunkt einer Änderungsanweisung nicht bekannt ist und somit eine Ereigniserkennung nur über ein „pollendes“ System zu erkennen ist. Die Nachteile dieses Vorgehens liegen in der Ereigniserkennung. Ein zu häufiges Anfragen der Datenbank kann
zur Systemüberlastung führen, während ein zu seltenes Anfragen dazu führen kann, daß
der Zeitpunkt, zu dem eine Datenbankänderung stattfindet, nicht erkannt wird. Dieses
Problem wurde gelöst, indem das ARTA-System als Präprozessor implementiert wurde.
Alle Eingaben des Benutzers gehen über die ARTA II-Benutzeroberflächen, wo sie vom
System erkannt, ausgewertet und verarbeitet werden.
ARTA-II wurde, vor allem was die Benutzeroberflächen anbetrifft, enorm erweitert.
Der Benutzer wird beim Umgang mit Triggern aktiv unterstützt. Die grafisch aufbereiteten Eingabemasken erlauben den sicheren Umgang mit Triggern. Mittels des Trigger-,
Ereignismuster-, Ereignisprotokoll- und SQL-Statementmanagers, werden die Verwaltungsaufgaben des Systems realisiert. Diese Schemakomponenten sind die Logik, die
sich hinter den Benutzeroberflächen verbirgt. So führt der Trigger Manager bei Eingabe
oder Änderung eines Triggers Syntaxüberprüfungen durch, so daß Fehleingaben vom
Benutzer direkt abgefangen und korrigiert werden können. Eine Triggerübersicht gibt
Auskunft über anstehende Ausführungstermine, was den Umgang mit den angelegten
Triggern sehr erleichtert. Über einen Protokollmanager, der die Ereignisprotokollierung
verwaltet, kann zu jeder Zeit nachvollzogen werden, welche Trigger ausgeführt wurden
und welche nicht. Ein Event Type Manager verwaltet vordefinierte Ereignismuster und
zeigt überdies alle Trigger an, die ein solches Muster besitzen. Oft benutzte Ereignisdeklarationen beim Anlegen eines Triggers können gesondert als Ereignismuster in die
Datenbank gespeichert werden, um bei Neuerstellung eines Triggers auf eben diese vordefinierten Ereignismuster zurückgreifen zu können. Der SQL-Statement Manager dient
der Verwaltung vordefinierter SQL-Statements. Um SQL-Statements nicht immer wieder neu angeben zu müssen, können diese in die Datenbank gespeichert werden. Möchte
man ein SQL-Statement ausführen, das einem bestehenden Statement ähnelt, so genügt
es, ein bestehendes zu modifizieren.
83
Erweiterungskonzepte für das aktive DBMS
GUI
Ausblick auf mögliche Erweiterungen
ARTA II unterstützt zwei primitive Ereignisse. Die absoluten und die periodischen
Zeitereignisse. Es gibt noch einen dritten Ereignistyp und zwar den der relativen Zeitereignisse. Diese wurden leider aus zeitlichen Gründen nicht in ARTA II implementiert.
Eine interessante Erweiterung des ARTA II-Systems wäre die Implementierung von
zusammengesetzten Ereignissen, bei denen zwei oder mehrere Ereignisse kombiniert
werden. Zusammengesetzte Ereignisse können wiederum mit anderen primitiven oder
zusammengesetzten Ereignissen kombiniert werden. Um diese Aufgabe zu lösen ist es
wichtig, ein Ereignisprotokoll zu führen, um festzustellen, welche Ereignisse bereits
eingetroffen sind. So kann berechnet werden, welche Ereignisse noch fehlen, um ein
zusammengesetztes Ereignis auszulösen. Ein weiterer wichtiger Aspekt ist der Ereignisverbrauch. Diese Problematik wird in den Arbeiten von [Modic00] und [Löhr97] ausführlich behandelt.
In Microsoft Access ist es möglich, gewisse Integritätsbedingungen anzugeben. Bei der
Erstellung einer Tabelle können Schlüssel vergeben und Gültigkeitsregeln für einzelne
Attribute einer Tabelle angegeben werden, was den CHECK CONTRAINTS in SQL
entspricht. Über das Beziehungskonzept von MS-Access kann eine referenzielle Integrität gesetzt werden, wodurch Änderungen an Tabellen kaskadenförmig weitergereicht
werden können. Man hat jedoch keine Möglichkeit SQL-artige Integritätsbedingungen
auszudrücken, da die Integritätsprüfung in MS-Access unmittelbar nach einer Änderung
(immediate) stattfindet. Es gibt jedoch Transaktionsänderungen, bei denen man nicht
sofort eine Integritätsprüfung vornehmen möchte. Bei einer Einfügung zum Beispiel,
die zunächst einen Zustand verletzt, aber durch eine folgende Transaktion diesen wieder
repariert. Würde die Überprüfung nach dem Einfügen stattfinden und nicht am Ende der
kompletten Transaktion, so würde das System einen Fehler melden. Will man in MSAccess deferred ausdrücken, so muß dies mit Triggern erfolgen. Es muß ein Transaktionskonzept für die ARTA-Trigger implementiert werden.
84
Erweiterungskonzepte für das aktive DBMS
GUI
Literaturverzeichnis
[Löhr97]
Torsten Löhr. „Eine Erweiterung der aktiven Regelsprache Phoenix um
temporale Ereignisse, Deadlines und Alternativen.“ Rheinische Friedrich –
Wilhelms – Universität Bonn, 1997
[Modic00]
Jürgen Modic. „Eine Erweiterung des Triggerkonzeptes von Phönix um
temporale Ereignisse.“ Rheinische Friedrich – Wilhelms – Universität
Bonn, 2000
[Fortier99] Dr.Paul J. Fortier. „SQL – 3 Implementing the Object – Relational Database.” Chapter 10 (Triggers). McGraw – Hill 1999
[MeSi02]
Jim Melton and Alan R.Simon. „SQL:1999 Understanding Relational Language Components.” Chapter 11 (Active Databases and Triggers). Morgan
Kaufmann Publishers. 2002
[Fadaei02] Kazem Fadaei. „Entwurf und Implementierung einer Triggersprache mit
Zeitereignissen für Access – Datenbanken.” Rheinische Friedrich – Wilhelms – Universität Bonn, 2002
[DiGa00]
Dittrich, Klaus R. / Gatziu, Stella: Aktive Datenbanksysteme – Konzepte
und Mechanismen, ISBN 3-932588-19-3, 2.Auflage, April 2000, dpunktVerlag.
[Mos85]
J.B.E. Moss. Nested Tranactions: An approach to Reliable Destributed
Computing. MIT Press, Cambridge, Mass. , 1985
[ToPy98]
Thomas Pydde. Semantik von Regelsystemen für aktive Datenbanken Institut für Informatik Fachgebiet Datenbanken und Informationssysteme,
Dezember 1998
[NiJo92]
Niedereichholz, Joachim.: Datenbanksysteme - Konzepte und Management. 5.Auflage. Physica-Verlag Heidelberg, 30. März 1992
[DCha98]
D. Chamberlin: A Complete Guide to DB2 Universal Database, Morgan
Kaufmann, 1998
[HoSP]
Hoffbauer, N./Spielmann Chr., Das Access 97 Buch (1997) umfaßt 1462
Seiten, inkl. CD-Rom>>Sybex-Verlag GmbH, Düsseldorf
[HoCo99]
C. Horstmann, G. Cornell: Core Java Volume II-Advanced Features, Prentice-Hall, 1999
[JoVi96]
Übersetzt von John Viescas: Microsoft Access für Windows 95. ISBN 386063-121-7, 1996, Microsoft Press.
[JeRe02]
Egbert Jeschke / Helmut Reinke : ACCESS 2002 EINFÜHRUNG, ISBN:
3-902062-33-9, Redmonds Anwendertraining
[WiPe]
http://wikipedia.t-st.de/
[AbIt]
http://www.aboutit.de/index.html
[MS-Ac00] Microsoft Access 2002 Hilfe (10.2616.2625)
85
Erweiterungskonzepte für das aktive DBMS
Anhang
86
GUI
Erweiterungskonzepte für das aktive DMS ARTA
trigger name
CREATE TRIGGER
priority
Anhang
deadline
trigger interval
START ON
date
time
AT
END ON
date
AT
time
trigger event type
modification event type
modification type
trigger action time
INSERT
BEFORE
ON
DELETE
AFTER
table name
UPDATE
FOR EACH ROW
FOR EACH STATEMENT
REFERENCING
NEW
ROW
AS
tupel name
OLD
STATEMENT
AS
relation name
absolute time event type
ON
date
AT
time
periodic time event type (period)
SEE NEXT PAGE
WHEN
condition
(DO)
action
Seite A 87
Erweiterungskonzepte für das aktive DMS ARTA
Anhang
trigger event type
modification event type
absolute time event type
periodic time event type (period)
minutes event type
minutes
EVERY
MINUTES
hours event type
2digit
EVERY
minutes
HOURS AT
MINUTES PAST
days event type
3digit
EVERY
AT
time
weeks event type
2digit
EVERY
WEEKS ON
day of week
AT
time
months event type
2digit
EVERY
EVERY
MONTHS ON
day of week
ordined 1stTo5th
day of week
ordined digit day
DAY
AT
time
years event type
EVERY
2digit
ordined day
ordined number
WHEN
condition
YEARS ON
month of year
day of week
(DO)
AT
IN
month of year
time
action
Seite A 88