Eine Erweiterung des aktiven Datenbanksystems ARTA um relative Zeitereignisspezifikationen

Größe: px
Ab Seite anzeigen:

Download "Eine Erweiterung des aktiven Datenbanksystems ARTA um relative Zeitereignisspezifikationen"

Transkript

1 Rheinische Friedrich-Wilhelms-Universität Bonn Institut für Informatik Abteilung III Diplomarbeit Eine Erweiterung des aktiven Datenbanksystems ARTA um relative Zeitereignisspezifikationen JULIANE WERNECKE 8. November 2005 Erstgutachter: Prof. Dr. Rainer Manthey

2 Inhaltsverzeichnis 1 Einleitung 1 2 Aktive Datenbanken Einführung Semantik von Ereignissen Modifikationsereignisse Zeitereignisspezifikationen Relative Zeitereignisspezifikationen Grundlagen des SQL-Trigger-Konzepts SQL-Modifikationsereignisse Syntax von SQL-Trigger Semantik von SQL-Trigger ARTA II Einführung Trigger in ARTA II Syntax Semantik ARTA II-Trigger und Transaktionen Komponenten von ARTA II Systemarchitektur Das Zeitereignis -Modul Das Trigger Ausführungs -Modul Diskussion des bestehenden Systems Allgemeine Erweiterungen und Modifikationen von ARTA II Trigger-Steuerungskomponenten Prioritäten Deadline Aktivierungszustand Gültigkeitsintervall Zeitereignistrigger Ereignisparameter I

3 Inhaltsverzeichnis Verzögerte Ereignisverarbeitung Zeitperioden Entwurf von relativen Zeitereignisspezifikationen Anforderungsanalyse Trigger mit einer relativen Zeitereignisspezifikation Ereignisparameter Syntax Semantik Implementierung Speicherung relativer Zeitereignistrigger Generierung der abgeleiteten Zeitereignistrigger Grafische Benutzeroberfläche Ausnahmebehandlung Anwendungsszenarien Trigger mit absolut relativen Zeitereignisspezifikationen Trigger mit periodisch relativen Zeitereignisspezifikationen Zusammenfassung 97 II

4 1 Einleitung Das relationale Datenbankmanagementsystem Access von Microsoft ist ein passives Datenbankmanagementsystem. Operationen werden hierbei ausschließlich auf explizite Anforderungen durch einen Benutzer oder eine Anwendung durchgeführt. Aktive Datenbanksysteme dagegen unterstützen zusätzlich Mechanismen, mit denen sie anwendungsspezifisch definierte Situationen erkennen und automatisch auf diese reagieren können. Zur Umsetzung dieser Mechanismen werden aktive Regeln eingesetzt, welche eine prozedurale Spezifikation reaktiven Systemverhaltens erlauben. Aktive Datenbanksysteme besitzen einen Ereignis-Monitor und eine Reaktions- oder Rückkopplungskomponente. Der Ereignismonitor ist eine Komponente mit der der Anwender aktive Regeln definieren und verwalten kann. Die Reaktions- oder Rückkopplungskomponente ist für die Ausführung der benutzerdefinierten aktiven Regeln verantwortlich. Aktive Regeln, auch Trigger genannt, gehören seit 1999 zum offiziellen SQL-Standard. SQL-Trigger sind spezielle aktive Regeln. Das Ereignis eines SQL-Triggers bezieht sich auf eine Datenbankänderung in Form einer Einfügung, Löschung oder Modifikation von Zeilen einer Tabelle. Die Ereignisspezifikationen von SQL-Triggern können somit einzig die Modifikation von Daten beinhalten und sind damit sehr beschränkt. Andere Ereignistypen mit hoher praktischer Relevanz können beispielsweise Zeitereignisse sein. Zeitereignisse werden durch Zeitereignisspezifikationen definiert und können u.a. absolut bzw. periodisch sein. Eine absolute Zeitereignisspezifikation definiert genau einen einzelnen Zeitpunkt, wie etwa am 9. November 2005 um 12:00 Uhr. Demgegenüber steht eine periodische Zeitereignisspezifikation, die einer Menge von einzelnen Zeitpunkten entspricht, wie beispielsweise jeden 3. Tag um 12:00 Uhr. Mit Hilfe von Zeitereignisspezifikationen kann eine Datenbankoperation durch den Anwender im Vorhinein festgelegt und zu einem späteren Zeitpunkt ausgeführt werden. Periodische Zeitereignisspezifikationen können somit der Automatisierung von regelmäßig durchzuführenden Routineaufgaben dienen, wie etwa der Ausführung von Datensicherungsmaßnahmen oder der Erstellung von Statistiken. Am Institut für Informatik III der Universität Bonn wurde im Rahmen zweier Diplomarbeiten ([Fad02, Cali04]) mit Hilfe des kommerziellen Datenbankmanagementsystems Access das ARTA II-System entwickelt. Diese System erweitert das passive und relationale Access Datenbankmanagementsystem um eine aktive Komponente. Die Abkürzung ARTA steht hierbei für Active Real Time Access Database System und charakterisiert 1

5 1 Einleitung die funktionale Ausrichtung dieses Systems. Die in ARTA II realisierte Triggersprache orientiert sich an dem Triggerkonzept des SQL-Standards. Neben den bereits im SQL- Trigger-Konzept enthaltenen Modifikationstriggern unterstützt ARTA II ebenso Trigger mit einer absoluten sowie periodischen Zeitereignisspezifikation. Zusätzlich zu den SQL- Triggern besitzen ARTA II-Trigger so genannte Steuerungskomponenten, die der Kontrolle bzw. Steuerung der Triggerausführung dienen. Ziel dieser Arbeit ist die Erweiterung und Umsetzung einer weiteren Zeitereignisspezifikation, nämlich der relativen Zeitereignisspezifikation für das ARTA II-System. In relativen Zeitereignispezifikationen werden Zeitpunkte relativ zum Eintritt eines anderen Ereignisses definiert. Der Nutzen dieser relativen Zeitereignisspezifikationen ist offensichtlich. Verwendung für diese Form der Zeitereignisspezifikation könnte zum Beispiel ein Unternehmen haben, deren Datenbank unter anderem eine Tabelle mit den gestellten Rechnungen enthält, die nicht rechtzeitig bezahlt wurden. Für eine Einfügung in diese Tabelle kann mittels einer relativen Zeitereignisspezifikation ein Trigger definiert werden, durch dessen Aktion automatisch nach Verstreichen einer festgesetzten Frist die Versendung einer Zahlungsaufforderung per mail vorgenommen wird. Während der Umsetzung der relativen Zeitereignistrigger wird vor allem darauf geachtet eine möglichst orthogonale Erweiterung zu den bestehenden ARTA II-Triggern zu schaffen. Hierbei sollen bestehende Konzepte der ARTA II-Trigger nicht verändert und für relative Zeitereignistrigger übernommen werden. Die im Rahmen des SQL-Trigger- Kontextes getroffenen Entscheidungen sollen ebenso bei der Erweiterung von relativen Zeitereignisspezifikationen berücksichtigt werden. Die Voraussetzung einer erfolgreichen Erweiterung des ARTA II-System um relative Zeitereignistrigger ist ein korrekt funktionierendes System. Aus diesem Grund soll zuvor eine genaue Analyse des System vorgenommen werden. Dabei sollen alle Komponenten des Systems genauer betrachtet werden sowie die Funktionalitäten des Systems getestet werden. Bei Bedarf wird das System um fehlende Funktionalitäten bzw. wünschenswerte Eigenschaften erweitert. Die Arbeit ist wie folgt gegliedert: Kapitel 2 gibt eine allgemeine Einführung zu aktiven Datenbanken und betrachtet anschliesend die Semantik von Ereignissen in aktiven Datenbanken, um darauf folgend speziell Modifikationsereignisse und Zeitereignisspezifikationen zu behandeln. Kapitel 3 widmet sich den Grundlagen des SQL-Trigger-Konzepts, wobei insbesondere auf die in SQL realisierten Modifikationsereignisse eingegangen wird. Kapitel 4 gibt zunächst eine Einführung zum ARTA II-System. Danach werden die in ARTA II realisierten Trigger syntaktisch sowie semantisch beschrieben. Abschließend werden in Kapitel 4 die Komponenten des ARTA II-Systems vorgestellt und eine kurze Diskussion zum bestehenden System präsentiert. Diese Diskussion motiviert die in Kapitel 5 vorgestellten Erweiterungen und Modifikationen für ARTA II. Kapitel 6 beschreibt die Umsetzung von relativen Zeitereigisspezifikationen. In Kapitel wird die Implementierung der relativen Zeitereignistrigger im ARTA II-System beschrieben. Insbesondere gibt 2

6 1 Einleitung dieses Kapitel einen Einblick in die Spezifizierung von relativen Zeitereignistriggern. Anhand von Zuständen von Tabellen vor und nach der Triggerausführung wird gezeigt, dass wichtige Konzepte korrekt umgesetzt werden konnten. 3

7 2 Aktive Datenbanken Dieses Kapitel gibt zunächst eine allgemeine Einführung zu aktiven Datenbanken. In Abschnitt 2.2 wird die Semantik von Ereignissen in aktiven Datenbanken diskutiert, die sich im Wesentlichen an [CM94] und [GD93] orientiert. In den sich der Diskussion anschließenden Unterabschnitten 2.2.1, werden Modifikationsereignisse (2.2.1) und absolute sowie periodische Zeitereignispezifikationen (2.2.2) in Hinblick auf die betrachtete Semantik untersucht. Dabei werden vor allem die Unterschiede der beiden Ereignistypen herausgestellt. Die Modifikationsereignisse und die absoluten und periodischen Zeitereignisspezifikationen sind bereits in den ARTA II-Triggern umgesetzt worden. Unterabschnitt gibt einen ersten Einblick zu relativen Zeitereignisspezifikationen, die zurzeit noch nicht im ARTA II-System realisiert worden sind und im Rahmen dieser Arbeit als Erweiterung eingebracht werden sollen. Die Diskussion der Semantik von Ereignissen ist in dieser Form in vorangegangenen Arbeiten noch nicht erfolgt. Sie ist jedoch wesentlich für die Vorstellung und Spezifizierung von relativen Zeitereignisspezifikationen. 2.1 Einführung Aktive Datenbanksysteme besitzen zusätzlich zu passiven Datenbanksystemen Mechanismen, mit denen sie automatisch auf Ereignisse reagieren können, die entweder innerhalb oder außerhalb des Datenbanksystems stattfinden. Aktive Datenbanken lassen sich im Allgemeinen wie folgt definieren: Active database systems support mechanisms that enable them to respond automatically to events that are taking place either inside or outside the database system itself. ([PD99]) Ein Datenbanksystem heißt aktiv, wenn es zusätzlich zu den üblichen DBMS- Funktionalitäten in der Lage ist, anwendungsspezifisch definierte Situationen zu erkennen und daraufhin anwendungsspezifisch definierte Reaktionen auszulösen. ([Man01]) Zur Umsetzung der Mechanismen werden in aktiven Datenbanken aktive Regeln - auch Trigger genannt - eingesetzt, welche eine prozedurale Spezifikation reaktiven Systemverhaltens erlauben. Bevor Trigger Teil des SQL:1999 Standards wurden, gab es bereits Produkte, die sie unterstützten. Heutzutage werden Trigger aufgrund ihrer hohen praktischen Bedeutung von den meisten kommerziellen SQL-Datenbanksystemen bereitgestellt. 4

8 2 Aktive Datenbanken Aktive Regeln können in Form von ECA-Regeln ([Hay85, MD89]) dargestellt werden. Eine ECA-Regel besteht aus drei Regelkomponenten: einem Ereignisteil (Event), einer Bedingung (Condition) und einer Aktion (Action). Für sie ergibt sich folgende Bedeutung: Nach Eintritt eines in der Regel spezifizierten Ereignisses wird die Regel aktiviert. Nach der Aktivierung erfolgt die Evaluierung der Regelbedingung. Ist die Evaluierung erfolgreich verlaufen, wird die in der Regel definierte Aktion ausgeführt. SQL-Trigger sind spezielle ECA-Regeln. Das Ereignis eines SQL-Triggers bezieht sich auf eine Datenbankänderung in Form einer Einfügung, Löschung oder Modifikation von Zeilen einer Tabelle. Seine Bedingung ist eine beliebige SQL search condition, während die Aktion entweder ein SQL-Statement oder vom Benutzer eigens definierte Funktionen oder Prozeduren sind. Da die Aktion eines Triggers aus einer Datenänderungsanweisung bestehen kann, ist es möglich, dass durch die Ausführung eines Triggers die Aktivierung weiterer Trigger resultiert. Dies erlaubt den Entwurf von komplexen Anwendungen. Demgegenüber stehen die simplen Ereignistypen INSERT, DELETE sowie UPDATE, die sich nur auf eine Tabelle beziehen können, gegebenenfalls beschränkt auf bestimmte Spalten, und die Anwendung von SQL-Trigger beträchtlich begrenzen. Diese simplen Ereignistypen begrenzen die Anwendung von SQL-Triggern beträchtlich. Aus diesem Grund lassen sich bereits viele Erweiterungsvorschläge für Ereignisse von SQL-Triggern in der Literatur finden ([CCW00, Han92, SD95]). Eine Klasse dieser Triggerereignisse sind zeitbasierte Ereignisse. Diese Zeitereignisse werden zurzeit weder von gängigen Produkten noch vom SQL:2003 Standard unterstützt, obwohl sie in vielen Prototypen, wie HIPAC [DHP88], Ode [GJ91], Snoop [CM94] sowie Samos [Gatz94] Anwendung fanden. Zeitereignisse werden durch die Systemuhr erkannt und deren Spezifikationen sind entweder absolut, periodisch oder relativ. Eine absolute Zeitereignisspezifikation ist ein temporaler Ausdruck, der sich auf genau einen Zeitpunkt bezieht, während periodische Zeitereignisspezifikationen einer Menge von Zeitereignissen entsprechen. In relativen Zeitereignisspezifikationen werden dagegen Zeitereignisse mit anderen Ereignissen in Beziehung gesetzt, wobei ein temporaler Offset in Bezug auf den Zeitpunkt des Ereigniseintritts definiert wird. Beispielsweise könnte in SQL diese Art der Spezifikation zum Einsatz kommen, wenn eine Aktion 3 Wochen nach dem Auftreten einer Datenbankänderung ausgeführt werden soll. Zeitereignistrigger können in verschiedenen Anwendungen hilfreich sein. Diese Anwendungen können zum Beispiel das Erzwingen von Deadlines oder das Durchführen von in regelmäßigen Abständen auftretenden Aufgaben sein, wie beispielsweise Datensicherungsmaßnahmen. Die Bedeutung dieser Zeitereignistrigger wird veranschaulicht durch die Tatsache, dass Oracle bereits die Ausführung von PL/SQL Routinen zu vordefinierten Zeitpunkten oder deren wiederholende Ausführung in regelmäßigen Abständen unterstützt (vgl. [UHL04]). Deren Bedeutung hat insbesonders zugenommen, seitdem viele kommerzielle Datenbanksysteme annähernd dauerhaft in Betrieb sind und somit die meisten Zeitperioden abdecken, in denen ein benutzerdefiniertes Zeitereignis eintreten kann. Folglich kann dieser neue Triggertyp eine große Rolle in so genannten monitoring 5

9 2 Aktive Datenbanken applications spielen, in denen bestimmte Bedingungen immer wieder in regelmäßigen Abständen überprüft werden müssen. 2.2 Semantik von Ereignissen Zusätzlich zu passiven Datenbanksytemen besitzen aktive Datenbanksysteme einen Ereignis- Monitor, eine Komponente mit der der Benutzer aktive Regeln definieren und verwalten kann, sowie eine Reaktions- oder Rückkopplungskomponente. Letztere ist für die Ausführung der benutzerdefinierten aktiven Regeln verantwortlich. Durch den Ereignis-Monitor werden die Ereignistypen bzw. Ereignisklassen festgelegt, die durch das System erkannt werden. Ebenfalls ist es im Allgemeinen möglich, Ereignisstypen in Beziehung zueinander zu setzen, um so neue benutzerdefinierte Ereignisklassen abzuleiten. Ereignisse werden durch den Ereignis-Monitor ausschließlich beobachtet. Die aktiven Regeln werden nicht durch diesen Monitor ausgeführt, sondern nach Beobachtung eines Ereignisses aktiviert. Bei Beobachtung eines Ereignisses wird die laufende Aktion des passiven Datenbanksystems unterbrochen und eine (Re-) Aktion auf das Ereignis wird durchgeführt. Diese (Re-) Aktion kann zum Auftreten neuer Ereignisse führen, für die weitere (Re-) Aktionen ausgelöst werden sollen. Diese rekursive Form der Abarbeitung aktiver Regeln wird solange fortgesetzt, bis keine Aktionen mehr ausgeführt werden sollen und wird als kaskadierende Triggerauslösung bezeichnet. Nachdem die vollständige (Re-) Aktion auf das ursprüngliche Ereignis beendet ist, wird die Kontrolle wieder an das passive Datenbanksystem zurückgeben und es erfolgt die weitere Abarbeitung der zuvor unterbrochenen Aktion. Im Allgemeinen ist ein Ereignis die Beobachtung eines Geschehens von Interesse zu einem bestimmten Zeitpunkt. Üblicherweise spezifiziert der Benutzer dieses Geschehen, das vom System überwacht und erkannt werden soll. Dabei wählt er eine Ereignisklasse E C aus, die durch den Ereignis-Monitor unterstützt wird, wie zum Beispiel die Klasse der zeitbasierten Ereignisse. Denkbar wäre auch die Herleitung des definierten Ereignisses aus einer oder mehreren Basisereignisklassen. Eines dieser hergeleiteten Ereignisse könnte beispielsweise Jeden zweiten Monat innerhalb des Intervalls [09/05, 09/06] lauten, das sich aus mehreren Zeitereignissen zusammensetzt. Ein tatsächliches Ereignis E entspricht dann einer Instanz einer spezifischen Ereignisklasse E C. Jedes Ereignis E besitzt einen eigenen Zeitpunkt E.TP, der genau den Zeitpunkt spezifiziert, zu dem das Ereignis aufgetreten ist. Dies setzt voraus, dass ein Ereignis keine Dauer 1 besitzt, sondern als unzerlegbar bzw. atomar angesehen werden sollte. Nach dieser Sichtweise existieren somit keine komplexen oder zusammengesetzten Ereignisse wie z. B. in [GD93, PD99] interpretiert, sondern einzig komplexe Ereignisspezifikationen. Diese Spezifikationen erlauben die Spezifizierung von aktivierenden Ereignissen, 1 In [GA02] wird eine alternative Sichtweise vorgestellt, die Ereignisse mit einer Dauer betrachtet. 6

10 2 Aktive Datenbanken abhängig von einer bestimmten Historie von Ereignis-Beobachtungen. Eine komplexe Ereignisspezifikation entspricht somit mehreren Ereignissen, die miteinander in Beziehung gesetzt werden. Diese Beziehungen können beispielsweise durch temporale Offsets definiert werden, wie 10 Minuten nach Eintritt von Ereignis A. Ein Ereignis E kann für den Ereignis-Monitor vorhersehbar oder unvorhersehbar sein. Dies ist abhängig vom Zeitpunkt E.TP des Ereignisses, der entweder vorbestimmt oder unbestimmt sein kann. Üblicherweise sind benutzer-abhängige Datenänderungen unvorhersehbare Ereignisse, während interne Ereignisse des Systems, wie zum Beispiel Prozeduraufrufe, als vorhersehbar angesehen werden können. Neben dem verbindlichen Zeitpunkt seines Auftretens, kann ein Ereignis über so genannte Ereignisparameter verfügen. Diese Parameter sind von der Ereignisklasse des Ereignisses abhängig. Zusammenfassend kann ein Ereignis E als 3-Tupel (EC, EP, T P ) angesehen werden, bestehend aus : einem Ereignistyp EC, welcher die Ereignisklasse E C von E spezifiziert einer (möglicherweise leeren) Parameterliste EP von E einem Zeitpunkt T P, zu dem das Ereignis E eintritt. Das aktive Datenbanksystem überwacht das Auftreten von Ereignissen und startet eine (Re-) Aktion, wenn ein Ereignis wahrgenommen wird Modifikationsereignisse Bei Ereignissen vom Typ Modifikation handelt es sich stets um Änderungen von Zeilen einer Tabelle. Diese Ereignisse besitzen neben einem Zeitpunkt und eventuellen Ereignisparametern eine zum Ereignis gehörende (Datenbank-) Operation. Hierbei findet zunächst ein Aufruf dieser Operation statt, der zugleich die Ereignisbeobachtung darstellt. Aus diesem Grund sollen Ereignisse mit einer zugehörigen Operation im Folgenden auch als call events bezeichnet werden. Der Aufruf der Operation stellt einzig die Ereignisbeobachtung dar, nicht den Start oder das Ende der Ausführung der aufgerufenen Operation. Dabei wird angenommen, dass einige der Parameterbindungen an die nachfolgende zum Ereignis gehörende Operation weitergegeben werden. Die zum call event zugehörige Operation bleibt bei der Definition eines Ereignisses implizit. Die Ereignisparameter eines Modifikationsereignisses bestehen u. a. aus der zu modifizierenden Tabelle, aus dem Datenänderungstyp aber auch aus den zu ändernden Zeilen der 7

11 2 Aktive Datenbanken Tabelle. Hierbei ist es einerseits möglich einen Trigger genau einmal für das Modifikationsereignis auszuführen oder andererseits eine Ausführung für jede durch das Modifikationsereignis betroffene Zeile zuzulassen. Der Trigger iteriert dabei über die Ereignisparameter. Die Abbildung 2.1 stellt die Phasen dar, die durchlaufen werden, nachdem ein call event CE zum Zeitpunkt CE.T P beobachtet wurde. Abbildung 2.1: Phasen nach Beobachtung eines call events Zum Zeitpunkt BoR (Begin of Reaction) startet das System eine Reaktion bezüglich der Beobachtung von CE, die zum Zeitpunkt EoR (End of Reaction) vollständig beendet ist. Während der Phasen A und B werden alle Reaktionen des Systems ausgeführt. Diese Reaktionen werden eingeteilt in Ausführungen vor bzw. nach der tatsächlichen Ausführung der Operation. Der Ausführungszeitpunkt eines Triggers spezifiziert dagegen nicht, ob die Aktion des Trigger vor oder nach der Beobachtung eines unvorhersehbaren Modifikationsereignisses ausgeführt werden soll. Diese Interpretation wird in [ANSI99I, CPM96, CW96, MS93] vorgeschlagen und ist mit verschiedenen Problemen verbunden. Zum einen stellt ein BEFORE-Trigger bereits eine Reaktion des Systems dar, wobei für diese Reaktion im Vorhinein ein aktivierendes Ereignis eingetreten sein muss (folgt man dem vorgestellten allgemeinen Auswertungsschema in aktiven Datenbanken). Zum anderen müssen so genannte INSTEAD OF-Trigger [CW96] als Ereignis ersetzende Regeln interpretiert werden. Diese Funktionalität würde weit über die eines Ereignis-Monitors hinausgehen. Nach unserer Sichtweise wird durch einen INSTEAD OF-Trigger einzig die tatsächliche Datenmanipulation ersetzt. Diese Interpretation scheint offenbar die Adäquatere von beiden zu sein Zeitereignisspezifikationen Zeitbasierte Ereignisspezifikationen können entweder als absolut, periodisch oder als relativ angesehen werden. In diesem Abschnitt werden wir auf absolute sowie periodische 8

12 2 Aktive Datenbanken Zeitereignisspezifikationen eingehen. Relative Zeitereignisspezifikationen werden gesondert im Abschnitt behandelt. Eine absolute Zeitereignisspezifikation besteht aus einem temporären Ausdruck, der einen Zeitpunkt spezifiziert, wie beispielsweise am um 10:00 Uhr. Diese Spezifikation benötigt eine Zeit- und Datumsangabe, abhängig von der gewählten Granularität. Mit absoluten Zeitereignisspezifikationen können Datenbankoperationen im Vorhinein festgelegt werden ohne Unterstützung eines Benutzers oder anderer Anwendungsprogramme. Demgegenüber steht eine periodische Zeitereignisspezifikation, die eine Menge von Zeitereignissen beschreibt. Diese Zeitereigsnisse beginnen zu einem bestimmten Zeitpunkt und treten in regelmäßigen Abständen auf. Eine periodische Zeitereignisspezifikation entspricht demnach einer Menge von Zeitereignissen, die zur Aktivierung eines Triggers in regelmäßigen Abständen führen und somit dessen Ausführung anstoßen können. Ein Beispiel für diese Spezifikation wäre Jede Woche am Montag um 10:00 Uhr. Während Modifikationsereignisse innere Ereignisse in dem Sinne sind, dass das Datenbanksystem bei Eintritt des Ereignisses in Betrieb sein muss, sind Zeitereignisse äußere Ereignisse, die unabhängig vom Zustand des Systems eintreten. Zeitbasierte Ereignisse sind keine call events, da sie keine zugehörige Operation besitzen. Bezug nehmend auf die in Abbildung 2.1 betrachteten Phasen, stimmt bei einem absoluten Zeitereignis T E die Reaktionszeit BoR (Begin of Reaction) und EoR (End of Reaction) mit der Zeitperiode A überein, da keine Datenmanipulation in der Datenbank vorgenommen wird, vgl. Abbildung 2.2. Infolgedessen können in Bezug auf Zeitereignisse die Reaktionen auf das Ereignis nicht in Ausführungen vor bzw. nach einer Operation eingeteilt werden. Abbildung 2.2: Phasen nach Beobachtung eines absoluten Zeitereignisses TE Die Spezifikation eines Zeitereignisses T E ist grundsätzlich äquivalent mit dem Zeitpunkt T E.T P zu dem das Ereignis T E eintritt. Aus diesem Grund besitzen Trigger, die auf genau einem Zeitereignis T E basieren, keine anderen Ereignisparameter als den Zeitpunkt T E.T P. In diesem Zusammenhang macht eine Iteration des Triggers über die Ereignisparameter, wie sie für Modifikationsereignisse möglich ist, keinen Sinn, da es stets nur einen Ereignisparameter gibt. Ergänzend soll erwähnt werden, dass Zeitereignisse als vorhersehbar angesehen werden sollten. 9

13 2 Aktive Datenbanken Relative Zeitereignisspezifikationen Eine relative Zeitereignisspezifikation beschreibt ein Zeitereignis oder eine Menge von Zeitereignissen, das oder die mit Hilfe eines temporalen Offsets bezüglich des Auftretens eines anderen Ereignisses spezifiziert werden. Ein anderes Ereignis kann dabei ein externes Ereignis darstellen, wie z. B. 10 Minuten nach dem Hochfahren des Systems, oder ein weiteres Zeitereignis, wie beispielsweise 10 Minuten nach 12 Uhr. Ebenso kann bezüglich des Eintrittszeitpunktes eines Modifikations- oder Transaktionsereignisses mit einem temporalen Offset ein Zeitereignis berechnet werden. Im Allgemeinen kann in absolut relativen Zeitereignisspezifikationen, wie etwa 3 Wochen nach der Einfügung in die Tabelle A oder in periodisch relativen Zeitereignisspezifikationen, wie zum Beispiel Jeden Monat nach der Einfügung in die Tabelle A unterschieden wären. Denkbar wäre im Zusammenhang der periodisch relativen Zeitereignisspezifkationen ebenso zunächst einen temporalen Offset zu spezifizieren und danach mit einer zusätzlich spezifizierten Zeitperiode Zeitereignisse zu berechnen, wie zum Beispiel 3 Wochen nach dem Einfügen in Tabelle A und dann jeden Monat. Wir verwenden bewusst nicht den Begriff der relativen Zeitereignisse, sondern den Begriff der relativen Zeitereignisspezifikation. Dies geschieht aus folgendem Grund: Eine relative Spezifikation von Zeitereignissen, wie beispielsweise 2 Stunden nach der Einfügung in die Tabelle A, ist kein einzelnes Ereignis, sondern eine komplexe Spezifikation einer Folge von zwei Ereignissen e 1 und e 2. Dabei bezieht sich e 1 auf das Einfügen in Tabelle A und e 2 ist ein absolutes Zeitereignis zum Zeitpunkt e 1.T P + 2 Stunden. In diesem Zusammenhang verbleiben beide Ereignisse unabhängig in der relativen Ereignisspezifikation dahingehend, dass die Effekte von e 1 nicht mehr zu dem Zeitpunkt in der Datenbank vorliegen müssen zu dem das Ereignis e 2 eintritt, sofern dies nicht durch eine andere zusätzliche Bedingung explizit gefordert wird. Das bedeutet, dass es kein einzelnes relatives Zeitereignis gibt, sondern zwei Ereignisse, die in Beziehung zueinander gesetzt werden. Relative Zeitereignisspezifikationen können sich beispielsweise auf genau ein Modifikationsereignis und ein oder mehrere assoziierte Zeitereignisse beziehen. In diesem Fall sollten Ereignisparameter bezüglich beider Ereignistypen Teil der Ereignisspezifikation eines Triggers sein. Da die Ereignisparameter des Modifikationsereignis aus mehreren zu ändernden Zeilen bestehen können, ist es möglich den Trigger einerseits über diese Ereignisparameter iterieren zu lassen und diesen Trigger für jede durch das Modifikationsereignis betroffene Zeile auszuführen. Andererseits besteht die Möglichkeit die Ausführung des Triggers nur einmal zu erlauben. In Bezug auf die Ereignisparameter des Zeitereignisses gibt es keine Möglichkeit der Iteration über die Ereignisparameter (vgl ). Da das Trigger aktivierende Ereignis ein Zeitereignis ist und somit keine zugehörige (Datenbank-) Operation besitzt, können die Reaktionen auf das Ereignis nicht in Ausführungen vor oder nach einer nicht vorhandenen Operation eingeteilt werden, wie dies 10

14 2 Aktive Datenbanken bereits in Abschnitt für Trigger mit absoluter und periodischer Zeitereignisspezifkation beschrieben wurde. 11

15 3 Grundlagen des SQL-Trigger-Konzepts Dieses Kapitel gibt eine syntaktische sowie semantische Klassifikation von SQL-Triggern als spezielle ECA-Regeln, basierend auf den Quellen [ANSI99I, ANSI99II, CPM96, Horo92, PD99]. Im Rahmen der SQL-Trigger ist einzig die Spezifikation von Modifikationsereignissen möglich. Diese von einer allgemeinen Klasse der Modifikationsereignisse abgeleiteten SQL-Modifikationsereignisse wurden u.a. im ARTA II-System umgesetzt und sollen aus diesem Grund in Abschnitt 3.1 vorgestellt werden. Die im aktiven Datenbanksystem ARTA II realisierten Trigger stellen eine orthogonale Erweiterung der SQL-Trigger dar, so dass eine Kenntnis über die Grundlagen des SQL- Trigger-Konzepts unerlässlich ist. In Abschnitt 3.2 wird zunächst die Syntax der SQL- Trigger vorgestellt um darauf folgend die Semantik (3.3) der Trigger zu beschreiben. Dieses Kapitel ermöglicht somit eine Beschreibung der ARTA II-Trigger in syntaktischer und semantischer Hinsicht im nächsten Kapitel. Weiterhin bilden die im Rahmen des SQL-Trigger-Kontext getroffenen Entscheidungen neben den ARTA II-Triggern die Grundlage für die Umsetzung von relativen Zeitereignistriggern im ARTA II-System. 3.1 SQL-Modifikationsereignisse SQL-Modifikationsereignisse sind immer genau auf eine Basistabelle und einen Datenänderungstyp festgelegt. Der Datenänderungstyp kann entweder eine Einfügung, Löschung oder Änderung sein. Die Ereignisspezifikation eines SQL-Triggers TR definiert eine von der allgemeinen Klasse der Modifikationsereignisse abgeleitete Ereignisklasse E. Diese ist ein 3-Tupel (M, B, C) und beinhaltet: einen Datenänderungstyp M {INSERT, UPDATE, DELETE} einen Namen B einer Basistabelle sowie eine Teilmenge C der Spaltennamen von B, wobei für M {INSERT, DELETE} stets C = gilt. 12

16 3 Grundlagen des SQL-Trigger-Konzepts Der Ereignisteil eines Triggers TR spezifiziert genau eine Ereignisklasse T R E, durch den die Menge der TR aktivierenden Operationen bestimmt wird. Hierbei handelt es sich für T R E.M = INSERT um alle Einfügeoperationen auf T R E.B, für T R E.M = UPDATE um alle Aktualisierungsoperationen, die sich auf mindestens einer der Spalten aus T R E.C von T R E.B beziehen und schließlich im Falle von T R E.M = DELETE um alle Löschoperationen bezüglich T R E.B. In diesem Zusammenhang kann eine Operation entweder eine SQL-Änderungsanweisung sowie - im Falle T R E.M { UPDATE, DELETE } - eine referentielle Aktion sein. Hierbei stellt der Aufruf der Änderungsanweisung ein unvorhersehbares Modifikationsereignis dar. Die Teilmenge C einer Ereignisspezifikation enthält alle Spaltennamen, die von der Modifikation betroffen sind und ist ganz offensichtlich nur für Aktualisierungsoperationen sinnvoll, da von Einfüge- und Löschoperationen stets alle Spalten der Tabelle T R E.B betroffen sind. Damit der Benutzer nicht jedes Mal sämtliche Spaltennamen bei der Spezifikation angeben muss, vor allem bei T R E.M {INSERT, DELETE}, gilt T R E.C = als Äquivalent zu der Angabe aller Spaltennamen der Tabelle T R E.B, auch wenn T R E.M eine Aktualisierungsoperation ist. Falls durch die Operationen effektiv keinerlei Modifikationen an der Basistabelle T E.B durchgeführt werden, sprechen wir trotzdem von einer aktivierenden Operation, durch die Trigger gefeuert werden können. Dies könnte beispielsweise bei einer Einfügeoperation vorkommen, falls die Bedingung im WHERE-Teil des SQL-Statements keine Zeile der betroffenen Tabelle zu TRUE evaluieren kann. Die Ereignisspezifikation eines SQL-Triggers ist nicht komplex, da die Kombination mehrerer Datenmodifikationen innerhalb einer Ereignisspezifikation eines SQL-Triggers nicht erlaubt ist. Ebenso können die SQL-Ereignistypen nicht mittels einer Prioritätendeklaration angeordnet werden. Des weiteren stellen diese Ereignisspezifikationen eine parameterlose Spezifikation dar. Beispielsweise werden Parameterbindungen für die Bedingung oder Aktion eines Triggers nicht unterstützt. Auf Ereignisparameter kann allerdings per Transitionsvariablen zugegriffen werden. Hierbei stellen die Ereignisparameter die durch das eingetretene Ereignis zu modifizierenden Daten dar. Ein Datenmodifikationsereignis in SQL ist ein so genannter call event. Die Parameter dieses call events sind hierbei die modifizierten Attributwerte, während die zum Ereignis gehörende Operation die tatsächliche Datenbankmodifikation darstellt. In diesem Zusammenhang spezifiziert der Ausführungszeitpunkt eines SQL-Triggers, ob seine Triggeraktion vor (BEFORE) oder nach (AFTER) der Bearbeitung der zum Ereignis gehörenden Operation ausgeführt werden soll. Das Ereignis an sich stellt hierbei allein eine Datenänderungsanfrage dar, die durch ein SQL-Statement oder eine referentielle Aktion induziert wird. Betrachten wir in diesem Zusammenhang noch einmal die in Abbildung 2.1 (in Abschnitt 2.2.1) dargestellten Phasen, die nach Eintritt eines call events durchlaufen werden: Handelt es sich um einen so genannten BEFORE-Trigger wird die Aktion vor der Datenmanipulation und zwar in der Phase B ausgeführt. Im Falle eines so genannten AFTER-Triggers erfolgt die Ausführung nach der Datenbankmanipulation in Phase A. 13

17 3 Grundlagen des SQL-Trigger-Konzepts Die im Abschnitt erwähnten INSTEAD OF-Trigger sind im SQL-Standard nicht enthalten. 3.2 Syntax von SQL-Trigger Der Abschnitt 3.1 beschäftigte sich mit den Modifikationsereignissen durch die ein SQL- Trigger aktiviert werden kann. Wie konkret die Spezifikation eines Ereignistyps oder einer aktiven Regel aussieht wurde jedoch nicht betrachtet. So ist lediglich bezüglich Modifikationsereignissen bekannt, dass im Ereignisteil eines Triggers T R sein Ereignistyp T R E spezifiziert werden kann. Ebenso wurde erwähnt, dass die Möglichkeit besteht, innerhalb des Ereignistyps zu spezifizieren, ob ein Trigger vor oder nach dem ihn aktivierenden Ereignis auszuführen ist. Dieser Abschnitt soll eine ausführliche Beschreibung sämtlicher Möglichkeiten bei der Spezifikation eines Triggers mit Hilfe der CREATE TRIGGER- Anweisung geben. Mit dieser aus der SQL-Teilsprache DDL (Data Definition Language) stammenden CREA- TE TRIGGER-Anweisungen wird ein Trigger in SQL erzeugt. Die Syntax dieser Anweisung soll im Weiteren mittels der BNF (Bakus Naur Form) dargestellt werden. Zunächst betrachten wir die in [ANSI99I] verwendete Syntax. <trigger definition>::= CREATE TRIGGER <trigger name> <trigger action time> <trigger event> ON <table name> [ REFERENCING <old or new values alias list> ] <triggered action> <trigger action time> ::= BEFORE AFTER <trigger event> ::= INSERT DELETE UPDATE [OF <trigger column list> ] <trigger column list> ::= <column name list> <triggered action> ::= [ FOR EACH { ROW STATEMENT } ] [ WHEN <left paren> <search condition> <right paren> ] 14

18 3 Grundlagen des SQL-Trigger-Konzepts <triggered SQL statement> <triggered SQL statement> ::= <SQL procedure statement> BEGIN ATOMIC { <SQL procedure statement> <semicolon> }... END <old or new values alias list> ::= <old or new values alias>... <old or new values alias> ::= OLD [ ROW ] [ AS ] <old values correlation name> NEW [ ROW ] [ AS ] <new values correlation name> OLD TABLE [ AS ] <old values table alias> NEW TABLE [ AS ] < new values table alias> <old values table alias> ::= <identifier> <new values table alias> ::= <identifier> <old values correlation name> ::= <correlation name> <new values correlation name> ::= <correlation name> <correlation name> ::= <identifier> Auf die wichtigsten Komponenten der Triggerdefinition wird ausführlicher eingegangen: <TRIGGER NAME>: Der trigger name ist eine Zeichenfolge, die den Namen des Triggers festlegt. Um den Trigger innerhalb des SQL-Schemas eindeutig identifizieren zu können, sollten immer für jeweils zwei verschiedene Trigger unterschiedliche Namen spezifiziert werden. <TRIGGER ACTION TIME>: Mit der trigger action time wird der bereits in 3.1 eingeführte Ausführungszeitpunkt spezifiziert. Für BEFORE-Trigger liegt dieser Zeitpunkt immer vor der Bearbeitung der Datenbankoperation, während die Aktion eines AFTER-Triggers erst nach Einbringung der Datenänderung in die Datenbank ausgeführt wird. Neben dem Ausführungszeitpunkt unterscheiden sich BEFORE- und AFTER-Trigger ebenfalls indem für sie intendierten Verwendungszweck. So liegt der Schwerpunkt bei 15

19 3 Grundlagen des SQL-Trigger-Konzepts BEFORE-Triggern auf der Prüfung von Integritätsbedingungen, wobei die Möglichkeiten der Korrektur der zu modifizierenden Daten besteht. Dagegen werden AFTER-Trigger neben der Integritätssicherung vor allem für Folgeverarbeitungen verwendet. Als Konsequenz besitzen BEFORE- und AFTER-Trigger unterschiedliche Funktionalitäten. Dies zeigt sich unter anderem in den für BEFORE-Triggern vorgeschriebenen syntaktischen Einschränkungen, auf die in Bezug auf die old or new values alias list noch eingegangen werden soll. <TABLE NAME>: Der table name legt die in Abschnitt 3.1 eingeführte Komponente B des Ereignistyp TE fest und damit die SQL-Basistabelle auf die sich das Ereignis bezieht. <TRIGGER EVENT>: Der trigger event spezifiziert den Datenänderungstyp M und die Teilmenge C, die die durch das Ereignis betroffenen Spaltennamen von B enthält. Beide Komponenten wurden bereits in Abschnitt 3.1 im Rahmen der Definition des Ereignistyps eingeführt. <OLD OR NEW VALUES ALIAS LIST>: Jeder Trigger hat zum Zeitpunkt seiner Ausführung Zugriff auf die Ereignisparameter des Ereignisses. Diese Ereignisparameter sind die, durch das Änderungsereignis betroffenen neuen und alten Zeilen- und Tabellenwerte der SQL-Basistabelle. Diese Werte sind in einer Transitionstabelle gespeichert und können mittels Transitionsvariablen im Bedingungsteil sowie im Aktionsteil des Triggers referenziert werden. Mit der old or new values alias list besteht die Möglichkeit die Bezeichner für die Variablen zu spezifizieren. Diese können abhängig vom trigger event ganz unterschiedlich ausfallen: Wurde für den trigger event als Datenänderung INSERT angegeben, enthält die Transitionstabelle alle einzufügenden Zeilen. Dabei kann mit new values correlation name auf die einzelnen Transitionen und mit new values table alias auf die gesamte Transitionstabelle zugegriffen werden. Für den Datenänderungstyp DELETE sind alle zu löschenden Zeilen in der Transitionstabelle enthalten und es kann ein old values correlation name und ein old values table alias spezifiziert werden. Dabei kann wieder mit dem old values correlation name auf eine einzelne Transition und mit Letzterem - dem old values table alias - auf die ganze Transitionstabelle zugegriffen werden. Im Falle des Datenänderungstyps UPDATE werden zwei Transitionstabellen angelegt, einerseits für die Daten vor der Datenmodifikation und andererseits für die Daten nach der Datenänderung. Hierbei kann mit new values correlation name und old values correlation name auf die neuen und alten Transitionen zugegriffen werden, während mit new values table alias und old values table alias auf die neue bzw. alte Transitionstabelle zugegriffen werden kann. 16

20 3 Grundlagen des SQL-Trigger-Konzepts Die durch new values correlation name und old values correlation name spezifizierten Variablen werden auch als OLD- bzw. NEW-Transtionsvariablen bezeichnet. Im Zusammenhang mit der trigger action haben wir bereits erwähnt, dass es für BEFORE- Trigger gewisse Einschränkungen bezüglich der Syntax gibt. Diese wären zum einen das Verbot Bezeichner für die old values table alias sowie new values table alias zu definieren, d. h. BEFORE-Trigger dürfen nicht ihre zugehörigen Transitionstabellen referenzieren. Die Gründe liegen in der noch nicht stattgefundenen Integritätsprüfung zum Zeitpunkt der Ausführung eines BEFORE-Triggers bezüglich der Transitionstabelle des ihn aktivierenden Ereignisses. Insbesondere wurden zu diesem Zeitpunkt noch keine referentiellen Aktionen durchgeführt. Gerade vor dem Hintergrund, dass Aggregation einen der Hauptgründe für die Verwendung von Transitionstabellen darstellt, ist deren Inhalt zu diesem Zeitpunkt noch von so vorläufigem Charakter, dass ein Zugriff auf sie nicht erlaubt ist. Die Inspizierung einzelner Transitionen hingegen ist nach wie vor möglich, um bereits im Vorfeld der Ausführung mögliche Integrationsverletzungen aufdecken und korrigierend eingreifen zu können. Für die Spezifikation eines old values correlation name oder new values correlation name ist die Vereinbarung zu FOR EACH ROW zwingend erforderlich. <TRIGGERED ACTION>: Durch die triggered action wird die Ausführungsgranularität, der Bedingungs- sowie der Aktionsteil eines Triggers spezifiziert. Ausführungsgranularität: Durch die Ausführungsgranularität kann angegeben werden, ob die Aktion eines Triggers für jede durch das Ereignis zu ändernde Zeile ausgeführt werden soll ( FOR EACH ROW ) oder nur einmal für die gesamte Datenbankmodifikation ( FOR EACH STATE- MENT ). In Bezug auf Ereignisparameter hat ein STATEMENT LEVEL-Trigger einzig Zugriff auf die gesamte Transitionstabelle, nicht auf die einzelnen Transitionsvariablen. Die Transitionsvariablen sind allein dem ROW LEVEL-Trigger vorbehalten. Folglich besitzen BEFORE STATEMENT LEVEL-Trigger keinen Zugriff auf ihre Ereignisparameter, da sie ihre zugehörigen Transtionstabellen nicht referenzieren dürfen. Bedingungsteil: Der Bedingungsteil eines SQL-Triggers besteht aus einer beliebigen search condition. Diese search condition muss zuvor auf TRUE evaluiert werden, bevor der Aktionsteil eines Triggers ausgeführt werden kann. Wird keine search condition für den Bedingungsteil spezifiziert, ergibt die Evaluierung der Bedingung immer den Wert TRUE. Ähnlich zur Ereignisspezifikation, bietet auch der Bedingungsteil keine Parameterbindungen für den Aktionsteil eines Triggers. Allerdings kann die Bedingung eines Triggers mittels Transitionsvariablen auf die Ereignisparameter des Triggers zugreifen. Auf diese Art kann die Bedingung eine Ereignisbewertung durchführen und somit als Filter in Bezug auf das Ereignis agieren. 17

21 3 Grundlagen des SQL-Trigger-Konzepts Aktionsteil: Der Aktionsteil eines Triggers wird konstituiert durch das so genannte triggered SQL statement. Dieses Statement kann aus einem oder mehreren SQL procedure statements bestehen. Die SQL procedure statements schließen Anfragen, Änderunganweisungen und benutzerdefinierte Funktionsaufrufe mit ein. Die Zulässigkeit von Schema-Änderungen und Transaktionsanweisungen im Aktionsteil wird vom Standard nicht verbindlich spezifiziert. Da sich diese als semantisch problematisch erwiesen haben, bleibt es dem Datenbank- Entwicklern überlassen über deren Umsetzung zu entscheiden. Die Anweisungen im Aktionsteil eines Triggers werden in genau der Reihenfolge abgearbeitet, in der sie vom Benutzer angegeben werden. Wie der Bedingungsteil hat auch der Aktionsteil Zugriff auf die Ereignisparameter des Triggers mit Hilfe der Transitionsvariablen. Dabei ist einzig BE- FORE UPDATE- und BEFORE INSERT-Triggern, die gleichzeitig ROW LEVEL-Trigger sein müssen, die Änderung von neuen Transitionen erlaubt. Diese Regelung korrespondiert zu ihrem angedachten Verwendungszweck als aktive Regeln für die Integritätserhaltung. Auf der anderen Seite darf ein BEFORE-Trigger in seinem Aktionsteil keine Art von Datenänderungsanweisungen oder Funktionen besitzen, die solche Anweisungen aufrufen könnten. Somit werden bei der Ausführung eines BEFORE-Triggers keine weiteren Trigger aktiviert. Die vorgestellte und in [ANSI99I] verwendete Syntax ist leicht verständlich, so dass durch sie schnell ein Überblick über die Spezifikation eines Triggers entsteht. Jedoch ist durch diese Syntax die Aufteilung eines Triggers in Ereignis-, Bedingungs-, und Aktionsteil nicht sofort ersichtlich. Diese strenge Aufteilung wird benötigt um zu zeigen, dass die im Rahmen des ARTA II-Systems und dieser Arbeit vorgenommenen Erweiterungen weitgehend orthogonale Erweiterungen des bestehenden SQL-Trigger-Konzeptes darstellen. Aus diesem Grund wird ein anderer Syntaxvorschlag präsentiert. In diesem Syntaxvorschlag sollen fortlaufend die Erweiterungen des SQL-Trigger-Konzeptes eingegliedert werden: <trigger definition>::= CREATE TRIGGER <trigger name> <trigger event spec> [ <event parameter reference>] [ <trigger condition> ] <triggered action> <trigger event spec> :: = <modification event spec> <modification event spec> ::= <trigger action time> <trigger event> ON <table name> <event parameter reference> ::= 18

22 3 Grundlagen des SQL-Trigger-Konzepts REFERENCING <old or new values alias list> <trigger condition> ::= WHEN <left paren> <search condition> <right paren> <triggered action> ::= [ FOR EACH { ROW STATEMENT } ] <triggered SQL statement> 3.3 Semantik von SQL-Trigger Die Triggersemantik bestimmt die Organisation und Reihenfolge der Abarbeitung der Trigger. Sie legt beispielsweise die Anzahl der Triggerausführungen fest oder den Zeitpunkt zu dem die Bedingung eines Triggers ausgewertet und die Triggeraktion ausgeführt wird. Ebenfalls wird durch sie die Reihenfolge der Ausführung von gleichzeitig aktivierten Triggern bestimmt. Der Ereignisverbrauchsmodus spezifiziert, ob ein Trigger lediglich einmal oder mehrmals für sein aktivierendes Ereignis ausgeführt werden soll. Während bei einem ereignisverbrauchenden Modus ein Trigger nur genau einmal für sein aktivierendes Ereignis ausgeführt wird, ist es bei einem ereigniserhaltenen Modus möglich, dass der Trigger bezüglich eines Ereignisses mehrmals zur Ausführung selektiert werden kann. Nun sind SQL-Trigger bezüglich der Ereignisverbrauchsstrategie ereignisverbrauchend, wie auch die aktiven Regeln in ARIEL und STARBUST. Die Ausführungsgranularität eines Triggers spezifiziert, ob der Trigger entweder für jede zu ändernde Zeile ( FOR EACH ROW ) oder für jedes Statement ( FOR EACH STATE- MENT ) ausgeführt wird. Damit ist nicht die Transitionsgranularität gemeint, wie dies beispielsweise in [PD99] beschrieben wird. Durch sie wird das Verhältnis zwischen Ereigniseintritt und Regelinstantiierung beschrieben und instanz-orientierte von mengenorientierter Granularität unterschieden. Diese Betrachtung spielt insbesondere bei der ereigniserhaltenen Regelausführung eine Rolle. In [CPM96] legt man sich eindeutig darauf fest, dass die Ausführungsgranularität die Anzahl der Triggerausführungen für ein Ereignis bestimmt. Während ein ROW LEVEL-Trigger für jede Zeile seines aktivierenden Ereignisses ausgeführt wird, erfolgt die Ausführung eines STATEMENT LEVEL-Triggers nur genau einmal für sein aktivierendes Ereignis. Aus diesem Grund sind die aus einer bedingten SQL-Änderungsanweisung resultierenden individuellen Änderungen von einzelnen Zeilen keine unterschiedlichen Ereignisse, wie beispielsweise in [MS93] beschrieben, sondern Ereignisparameter. Beide Triggertypen ROW LEVEL- wie auch STATEMENT LEVEL-Trigger besitzen somit eine instanzorientierte Transitionsgranularität. Ein ROW LEVEL-Trigger wird genau einmal für eine Menge von induzierten Updates bzw. Änderungen instantiiert. Für die Abarbeitung dieser Menge ist keine feste Reihen- 19

23 3 Grundlagen des SQL-Trigger-Konzepts folge spezifiziert, d.h. es ist nicht festgelegt, in welcher Reihenfolge über die Ereignisparameter iteriert werden soll. Dieses nichtdeterministische Verhalten sollte durch weitere Einschränkungen in der Granularitätenspezifikation, wie beispielsweise FOR EACH ROW IN ALPHABETICAL ORDER DO..., unterbunden werden. Zusätzliche Prioritätenangaben für ROW LEVEL-Trigger würden zu keiner Lösung führen, da immer der gleiche Trigger für die jeweiligen Zeilen ausgeführt wird und sich somit keine eindeutige Reihenfolge ergeben würde. Ein weiteres semantisches Klassifikationsmerkmal ist der Kopplungsmodus, der die zeitliche Beziehung zwischen auslösendem Ereignis, Bedingungsauswertung und Aktionsausführung bestimmt. Im Allgemeinen wird der gekoppelte - die Aktivierung und Ausführung eines Triggers erfolgen in einer Transaktion - von dem entkoppelten Modus - die Aktionsausführung erfolgt in einer separaten Transaktion - unterschieden. In SQL wird eine Datenänderungsanweisung zusammen mit den durch sie aktivierten Triggern (und allen durch diese Trigger auszuführenden Anweisungen) innerhalb einer Transaktion ausgeführt. Somit ist die Ausführung von SQL-Triggern gekoppelt. Im Falle einer gekoppelten Ausführung wird die direkte (immediate) von der verzögerten (deferred) Kopplung unterschieden. Der Kopplungsmodus bezüglich des Bedingungs- und Aktionsteils (CA) eines SQL-Triggers ist immediate. Die search condition wird nicht während der Aktivierungsphase eines Triggers evaluiert, sondern in seiner Ausführungsphase, kurz vor Ausführung der Aktion eines Triggers. Der Kopplungsmodus des Ereignis- und Bedingungsteils ist dagegen deferred 1, da die Bedingung kurz vor der Aktionsausführung eines Triggers über einem bereits modifizierten Transitionszustand (infolge von gegebenenfalls anderen Triggerausführungen) ausgewertet wird. Aufgrund der kaskadierende Triggerauslösung können Zyklen bei der Triggerausführung entstehen. Dies ist der Fall, wenn spezifizierte Trigger sich gegenseitig auslösen. Hierbei gibt es einen Trigger, der sich entweder direkt oder indirekt immer wieder auslöst. Durch das System muss sichergestellt sein, dass solche Zyklen terminieren. Dieses Terminierungsproblem wird im Rahmen des SQL-Kontextes nicht gelöst, sondern bleibt dem Implementierer überlassen. Nach Beobachtung eines Modifikationsereignisses wird ein so genannter Trigger Execution Context (TEC) erzeugt, der sich aus folgenden Bestandteilen zusammensetzt: dem Namen der betroffenen Tabelle, die SQL Basistabelle dem Datenänderungstyp (DELETE, INSERT oder UPDATE) einer Menge von Transitionen bestehend aus zwei temporären Tabellen: OLD TA- BLE beinhaltet die alten und noch nicht veränderten Werte der betroffenen Zeilen im Falle der Datenänderungstyp ist DELETE oder UPDATE und NEW TABLE 1 Der Kopplungsmodus deferred wird normalerweise mit der Assoziation am Ende der aktuellen Transition gebraucht. Indes wird hier dieses Wort benutzt, um die lose Kopplung zwischen Ereignisteil und Bedingungsteil zu betonen. 20

24 3 Grundlagen des SQL-Trigger-Konzepts beinhaltet die neuen und geänderten Werte der betroffenen Zeilen im Falle der Datenänderungstyp ist INSERT oder UPDATE Mit Hilfe des TEC werden einerseits die Trigger ermittelt, die durch durch das Modfikationsereignis aktiviert werden. Anderseits können vor Bedingungsauswertung und Aktionsausführung eines Triggers jeweils die Werte, die mittels Transitionsvariablen in Bedingung und Aktion eines Triggers referenziert werden, aus der Menge der Transitionen berechnet und entsprechend eingesetzt werden. In der Ausführungsphase eines BEFORE-Triggers finden keinerlei Modifikationen des Datenbankzustands statt. Somit werden in dieser Phase keine weiteren Modifkationsereignisse beobachtet. Allerdings kann im Falle eines INSERT oder UPDATE Datenänderungstyp die NEW TABLE durch die Aktion eines BEFORE Triggers aktualisiert werden, um zum einen die Prüfung statischer und transitionaler Integritätsbedingungen und zum anderen die Korrektur der zu modifizierenden Daten zu ermöglichen. Die Aktualisierungen sind für in späteren Iterationsrunden auszuführende Trigger sichtbar, stellen jedoch keine neuen Ereignisse dar, die verarbeitet werden müssten. Während der Ausführung von AFTER-Triggern können weitere Ereignisse beobachtet werden, da der Aktionsteil eines AFTER-Triggers Datenänderungsanweisungen enthalten kann. Hierbei wird das durch eine Datenänderungsanweisung induzierte atomare Modifikationsereignis rekursiv - beginnend mit dem Erzeugen des Trigger Execution Context (TEC) - verarbeitet. Ein neuer TEC wird bezüglich des aufgetretenen Modifikationsereignisses erzeugt. Dabei wird der aktuelle TEC auf einen Stack gelegt. Mit dessen Bearbeitung wird fortgefahren, wenn der neue TEC vollständig bearbeitet wurde, das heisst wenn alle durch dieses Modifikationsereignis aktivierten Trigger ausgeführt wurden. Das Erstellungsdatum eines Triggers dient als Priorität, falls mehrere Trigger simultan durch das selbe Modifikationsereignis aktiviert wurden. Das bedeutet, dass es keine explizite Prioritätenvergabe gibt, sondern diese implizit durch das Erstellungsdatum erfolgt. Werden mehrere Trigger simultan aktiviert, wird der Trigger mit dem ältesten Erstellungsdatum als erstes zur Ausführung selektiert. 21

25 4 ARTA II Das ARTA II-System ist eine Anwendung für das relationale Datenbankmanagementsystem Access von Microsoft, das am Institut für Informatik III der Universität Bonn entstanden ist. Im Rahmen der Diplomarbeit [Fad02] wurde zunächst das ARTA-System entwickelt. Mit den Erweiterungen aus der Diplomarbeit [Cali04] wurde das System in ARTA II umbenannt. Dieses System erweitert das passive und relationale Access Datenbankmanagementsystem um eine aktive Komponente und unterstützt derzeit Modifikationstrigger sowie Trigger mit einer absoluten und periodischen Zeitereignisspezifikation. Im Rahmen dieser Arbeit soll das ARTA II-System um relative Zeitereignistrigger ergänzt werden. Abschnitt 4.1 gibt eine kurze Einführung zu dem System. Im darauf folgenden Abschnitt wird näher auf die in ARTA II realisierten Trigger eingegangen. Die detaillierte Semantikbeschreibung der SQL-Trigger im vorangegangen Kapitel (3) erlaubt eine ebenso ausführliche Beschreibung der Semantik der ARTA II-Trigger in Abschnitt Diese Beschreibung ist in vorhergehenden Diplomarbeiten zum ARTA II-System ([Fad02, Cali04]) lediglich formal erfolgt. Eine ausführliche Semantikbeschreibung ist jedoch notwendig, um die Definition der Semantik der relativen Zeitereignistrigger vornehmen zu können. Die Voraussetzung einer erfolgreichen Erweiterung des ARTA II-System um relative Zeitereignistrigger ist ein korrekt funktionierendes System. Aus diesem Grund werden die Komponenten des ARTA II-System in Abschnitt 4.3 detailliert betrachtet. Zusätzlich wurde im Rahmen dieser Arbeit eine Analyse des Systems vorgenommen. Während dieser Analyse wurde das System auf wichtige Funktionalitäten getestet. Die Ergebnisse dieser Analyse sind in Abschnitt 4.4 (Diskussion des bestehenden Systems) zusammengetragen. 4.1 Einführung Access ist kein aktives sondern ein passives Datenbankmanagementsystem. Operationen werden hier ausschließlich auf explizite Anforderungen durch einen Benutzer oder eine Anwendung durchgeführt. Um dem Benutzer die Möglichkeit zu geben aktive Regeln bzw. ECA-Regeln zu definieren, wurde die Anwendung ARTA II für Access entwickelt, die das passive Access Datenbankmanagementsystem um eine aktive Komponente ergänzt. 22

26 4 ARTA II Das Akronym ARTA steht für Active Real Time Access Database System. Das Wort Active steht für die Erweiterung von Access um eine aktive Komponente. Real Time besagt, dass es sich bei ARTA um ein Echtzeitsystem (engl. Real Time System) handelt. Ein Echtzeit-System ist ein System, das anfallende Daten oder Ereignisse unter Einhaltung von Echtzeitanforderungen verarbeiten kann. Solche Echtzeitanforderungen sind zeitliche Rahmen, die bei der Bearbeitung nicht überschritten werden dürfen ([wiki]). Diese Eigenschaft bezieht sich auf die in ARTA II realisierten Trigger, die auf vordefinierte Zeitereignisse reagieren können. Hierbei wurde die Angabe eines Zeitintervalls ermöglicht, welches die Zeit angibt, die dem System bleibt um einen aktivierten Trigger auszuführen. Die Korrektheit solcher Systeme hängt demnach nicht nur vom logischen Ergebnis ab, sondern auch vom Zeitpunkt, bis zu dem das Ergebnis produziert wird. Aufgrund dieser Funktionalitäten wird aus dem aktiven DBMS ein aktives Echtzeit-DBMS. Das System ARTA II wurde in Form einer Access-Anwendung unter der Benutzung der Programmiersprache VBA implementiert. Zusätzlich wurden Access-Formulare und die unter Access verwendete SQL-Anfragesprache eingesetzt. Mit Hilfe der Oberfläche von ARTA II, die in Form der Access-Formulare realisiert wurde, kann der Benutzer sehr komfortabel Trigger definieren. Die Verwaltung der Trigger wird von dem System übernommen. Wird vom System ein Ereignis beobachtet, kommt es zur Ausführung der Trigger, die durch das eingetretene Ereignis aktiviert wurden. Zusätzlich hat der Benutzer die Möglichkeit einfache SQL-Statements auszuführen, die durch das System in die Datenbank eingebracht werden. Hierbei werden nur die drei Datenmanipulations-Befehle DE- LETE, INSERT sowie UPDATE zugelassen. Die Bedeutung dieser Funktionalität liegt in der eingeschränkten Ereigniserkennung von ARTA II, auf die noch genauer in Abschnitt eingegangen wird. Die Unterstützung weiterer SQL-Statements fehlt in ARTA II, hierfür steht weiterhin die Anwendung Access zur Verfügung. Während andere aktive Datenbanksysteme, wie Ariel, A-RDL, Postgree, Starburst und die auf dem objektorientierten Datenmodel basierenden aktiven Datenbanksysteme Chimera sowie die schon erwähnten Systeme Ode und HiPAC sehr große Unterschiede hinsichtlich ihrer Semantik aufweisen, orientiert sich ARTA II an dem Triggerkonzept des SQL:1999- Standards, das in Kapitel 3 ausführlich beschrieben wurde. Dieses Triggerkonzept stellt einen ersten Ansatz zur Etablierung eines Standards dar (vgl.[dor04]). 4.2 Trigger in ARTA II In ARTA II werden neben den im SQL-Trigger-Konzept realisierten Modifikationstrigger, auch Zeitereignistrigger unterstützt. Mit Hilfe der Zeitereignistrigger können absolute sowie periodische Zeitereignisspezifikationen definiert werden. Für die Umsetzung dieser Zeitereignistrigger wurden weitere so genannte Steuerungskomponenten eingeführt. Diese Komponenten dienen zusätzlich der Kontrolle bzw. Steuerung der Triggerausführung. Zu ihnen zählen ein Aktivierungszustand, ein Gültigkeitsintervall, eine Deadline sowie 23

27 4 ARTA II eine Priorität, die für jeden Triggertyp - auch für Modifikationstrigger - definiert werden können. In Abschnitt wird die bereits in Abschnitt 3.2 vorgestellte Syntax für SQL-Trigger um absolute und periodische Zeitereignisspezfikationen sowie um die Steuerungskomponenten erweitert. Anhand der Syntax kann gesehen werden, dass die ARTA II-Trigger eine orthogonale Erweiterung des SQL-Trigger-Konzepts darstellen. In Abschnitt wird die Semantik der ARTA II-Trigger ausführlich beschrieben. Abschließend soll auf das Zusammenspiel von ARTA II-Triggern und den in ARTA II realisierten Transaktionen eingegangen werden Syntax Die ARTA II-Trigger stellen eine weitgehend orthogonale Erweiterung der Modifikationstrigger des SQL-Trigger-Konzepts dar, deren Syntax im Abschnitt 3.2 detailliert beschrieben wurde. Aus diesem Grund liegt der Fokus in diesem Abschnitt auf den Zeitereignistriggern. Ebenso wird auf die Steuererungskomponenten der ARTA II-Trigger eingegangen. Die bereits in 3.2 vorgestellte Syntax wird folgendermaßen erweitert: <trigger definition> ::= CREATE TRIGGER <trigger name> <trigger interval> <trigger event spec> <trigger activation state> <trigger priority> <trigger deadline> [ <event parameter reference> ] [ <trigger condition> ] <triggered action> <trigger interval> ::= <begin interval> <end interval> <begin interval> ::= START ON <date value> AT <time value> <end interval> ::= END ON <date value> AT <time value> <date value> ::= <days value>. <months value>. <years value> <time value> ::= 24

28 4 ARTA II <hours value> : <minutes value> <days value> ::= <digit> <digit> <months value> ::= <digit> <digit> <years value> ::= <digit> <digit> <digit> <digit> <hours value> ::= <digit> <digit> <minutes value> ::= <digit> <digit> <digit> ::= <trigger activation state> ::= TRUE FALSE <trigger priority> ::= <integer> <integer> ::= <digit 1 > <integer> <digit 1 > <digit 1 > ::= <trigger deadline> ::= <digit> <digit> <digit> <digit> <digit 1 > MINUTES Es existieren folgende Einschränkungen bezüglich der zulässigen Werte: 1900 bis 2100 für years value, 01 bis 12 für months value, 01 bis 31 für days value, 01 bis 23 für hours value und 00 bis 59 für minutes value. Mit dem days value muss zusammen mit dem years value und dem months value ein gültiges Datum des gregorianischen Kalenders repräsentiert werden. Weiterhin werden bestimmte Kontextbedingungen in dieser Syntax nicht erwähnt. Zum Beispiel ist die Angabe der Ausführungsgranularität in der triggered action für Zeitereignistrigger nicht sinnvoll, 25

29 4 ARTA II da für diese Trigger derzeit keine Ereignisparameter definiert werden können und somit eine Iteration über Ereignisparameter nicht möglich ist. ARTA II-Trigger besitzen (zusätzlich zu SQL-Triggern) eine Priorität - trigger priority -, ein Gültigkeitsintervall - trigger interval - eine Deadline - trigger deadline - sowie einen Aktivierungszustand - activity state. Durch den Aktivierungszustand wird spezifiziert, ob ein Trigger zur Ausführung selektiert werden kann oder nicht. Befindet sich der Trigger in einem deaktiven Zustand, wird er trotz Aktivierung durch ein Ereignis nicht ausgeführt. Das Gültigkeitsintervall bezüglich eines ARTA II-Triggers ist ein Zeitintervall, wobei der Beginn - spezifiziert durch begin interval - zeitlich vor dem Ende - spezifiziert durch end interval - liegen muss. Nur innerhalb dieses Zeitintervalls darf ein Trigger durch ein Ereignis aktiviert werden. Die Deadline eines Triggers gibt an, wie lange das System nach seiner Aktivierung Zeit hat seine Ausführung zu beginnen. Die Deadline wird in Minuten angegeben, wobei der Standard-Wert bei 5 Minuten liegt. Für Trigger in ARTA II wurde nicht das auf dem Erstellungsdatum basierende Prioritätenkonzept des SQL:1999- Standards übernommen, sondern für jeden Trigger kann in ARTA II eine natürliche Zahl spezifiziert werden, die als Priorität gelten soll. Sollten in der Selektionsphase mehrere Trigger ausgewählt werden, wird der Trigger selektiert, der die maximale Priorität besitzt. Ein Unterschied zu SQL-Triggern besteht in der Spezifizierung der Aktion eines Triggers. In ARTA II darf innerhalb der Aktion nur ein SQL-Statement angegeben werden. Jedoch besteht die Möglichkeit eine VBA-Funktion zu definieren, durch die beispielsweise mehrere SQL-Statements ausgeführt werden können. Ein weiterer Unterschied zu SQL-Trigger besteht in der Einschränkung, dass Änderungsereignisse in ARTA II nur auf der Ebene von Tabellen und nicht auf einem bestimmten Feld einer Tabelle definiert werden können. Eine Datenänderung eines bestimmten Feldes kann jedoch immer auch als Datenänderung auf einer Tabelle interpretiert werden. Die trigger event spec wird folgendermaßen erweitert: <trigger event spec> ::= <modification event spec> <time event spec> <time event spec> ::= <absolute event spec> <periodic event spec> Eine absolute Zeitereignisspezifikation bezieht sich direkt auf einen Zeitpunkt und benötigt eine Zeit- und Datumsangabe. Mittels der absolute event spec erfolgt die Spezifikation.: <absolute event spec> ::= ON <date value> AT <time value> 26

30 4 ARTA II Der Trigger muss vor Eintritt des aktivierenden Zeitereignisses definiert werden. Die Darstellung des Zeitereignisses orientiert sich an dem SQL Datentyp TIMESTAMP - Zeitstempel. Zusätzlich werden mnemonic keywords (ON, AT) verwendet, um die Spezifikation von Uhrzeit und Datum zu trennen. Dabei lassen sich Zeitpunkte mit der Genauigkeit Minute spezifizieren. Die Unterschiede zum ARTA II-Modifikationstrigger liegen im Wesentlichen in der fehlenden Spezifikation einer vom Ereignis betroffenen Tabelle, dem fehlenden Ausführungszeitpunkt, der Triggergranularität sowie der fehlenden Referenzierung der Ereignisparameter. Hingegen bestehen zwischen dem Namen, der Priorität, dem Gültigkeitszustand sowie der Deadline eines Triggers keinerlei Unterschiede. Da ein Zeitereignis keine zum Ereignis gehörende Datenbankoperation besitzt, muss für Zeitereignistrigger der Ausführungszeitpunkt nicht spezifiziert werden. Unterscheidungen in BEFORE bzw. AFTER-Trigger gibt es bei Zeitereignistriggern dementsprechend nicht. Ein absoluter Zeitereignistrigger wird durch das Eintreten des durch die absolute event spec eindeutig spezifizierten Zeitpunktes aktiviert. Dieser Zeitpunkt stellt zugleich den intendierten Ausführungszeitpunkt dar. Ist zu diesem Zeitpunkt das System ausgeschaltet oder sind andere Prozesse aktiv, wird der Zeitereignistrigger möglicherweise erst zu einem späteren Zeitpunkt ausgeführt. In diesem Fall kann der tatsächliche Ausführungszeitpunkt vom intendierten Ausführungszeitpunkt zeitlich abweichen. In diesem Zusammenhang spielt das Konzept der Deadline eine große Rolle. Dieses Konzept wird im folgenden Abschnitt sowie im Kapitel 5 Erweiterungskonzepte für das ARTA II-System näher betrachtet. Neben der absoluten Zeitereignisspezifikation gibt es die periodische Zeitereignisspezifikation. Eine periodische Ereignisspezifikation entspricht einer Menge von absoluten Zeitereignissen, die in einem bestimmten Zeitintervall liegen. Diese Zeitereignisse treten ab einem bestimmten Zeitpunkt in regelmäßigen Abständen auf. Für Trigger mit einer periodischen Zeitereignisspezifikation ergibt sich folgende Syntax: <periodic event spec> ::= <minutes event type> <hours event type> <days event type> <weeks event type> <months event type> <years event type> Die periodische Zeitereignisspezifikation unterteilt sich in 6 Komponenten bzw. Perioden. Diese sind Minuten, Stunden, Tage, Wochen, Monate sowie Jahre. Um die Definition der Periode möglichst nahe an Zeitangaben zu erlauben, wie diese im normalen Sprachgebrauch gebräuchlich sind, werden mnemonic keywords - ähnlich zur Spezifikation des 27

31 4 ARTA II absoluten Zeitereignisses - verwendet, wie beispielsweise EVERY, WEEKS ON oder AT. Die verschiedenen Möglichkeiten für die Definition der Periode werden im Folgenden einzeln vorgestellt: 1. Periodenspezifikation Minute <minutes event type> ::= EVERY <digit minutes> 1 MINUTES <digit minutes> 1 ::= Für digit minutes können Werte von 1 bis 59 angegeben werden. Der erste Ausführungszeitpunkt besteht aus dem Beginn des Gültigkeitsintervalls. Der jeweils nächste Ausführungszeitpunkt berechnet sich durch Addition des letzten Ausführungszeitpunktes mit der durch digit minutes definierten Zahl. Die Menge intendierter Ausführungszeitpunkte setzt sich aus sämtlichen Zeitpunkten zusammen, die sich innerhalb des Gültigkeitsintervalls befinden. 2. Periodenspezifikation Stunde <hours event type> ::= EVERY <digit hours> HOURS AT <digit minutes> MINUTES PAST <digit hours> ::= <digit minutes> ::= Für digit hours kann eine Zahl zwischen 1 und 23 spezifiziert werden, die angibt in welchen Stundenschritten der Trigger aktiviert werden soll. Zusätzlich könnnen mittels digit minutes Minuten definiert werden. Der erste Ausführungszeitpunkt ist analog zur Periodenspezifikation Minute der Beginn des Gültigkeitsintervalls. Der jeweils nächste intendierte Ausführungszeitpunkt eines Triggers mit Periodenspezifikation Stunde berechnet sich durch Addition der Stunden und Minuten auf den jeweils letzten Ausführungszeitpunkt. 3. Periodenspezifikation Tag <days event type> ::= EVERY <digit days> DAYS AT <time value> <digit days> ::=

32 4 ARTA II Für digit days kann eine Zahl zwischen 1 und 366 definiert werden. Time value gibt die Uhrzeit an zu der der Trigger jeweils gefeuert wird. EVERY 12 DAYS AT 12:15 würde beispielsweise im normalen Sprachgebrauch Jeden zwölften Tag um 12 Uhr 15 entsprechen. Für ein Gültigkeitsintervall vom :00 bis zum :00 würde sich die Menge der intendierten Ausführungszeitpunkte aus { :15, :15, :15} zusammensetzen. 4. Periodenspezifikation Woche <weeks event type> ::= EVERY <digit weeks> WEEKS ON <day of week> AT <time value> <digit weeks> ::= <day of week> ::= SUNDAY MONDAY TUESDAY WEDNESDAY THURSDAY FRIDAY SATURDAY Für digit weeks kann eine Zahl zwischen 1 und 52 definiert werden. Mit day of week wird der Wochentag definiert an dem der Trigger jeweils gefeuert werden soll. Wie bei der Periodenspezifikation Tag muss ebenso eine Uhrzeit definiert werden, zu der der Trigger aktiviert wird. Besitzt ein Trigger beispielsweise ein Gültigkeitsintervall vom :30 bis zum :30 und soll jede Woche am Montag um 11:30 Uhr gefeuert werden, beschreibt die Ereignisspezifikation die folgende berechenbare Menge von Zeitereignissen { :30, :30, :30,...}. Hierbei sind die Abstände zwischen zwei aufeinanderfolgenden intendierten Ausführungszeitpunkten immer identisch. Aus diesem Grund sprechen wir von festen Perioden. Alle bisher vorgestellten Periodenspezifikationen beschreiben feste Perioden. Im Gegensatz zu festen Perioden gibt es variable Perioden, wie beispielsweise Jeden 4. Monat. In diesem Fall muss die Zeitdifferenz von zwei aufeinanderfolgenden intendierten Ausführungszeitpunkten nicht immer identisch sein, da die Länge eines Monats von 28 bis 31 Tagen variiert, während ein Jahr aus 365 oder 366 Tagen bestehen kann. Im Folgenden werden die Möglichkeiten bezüglich variabler Perioden vorgestellt, die es in ARTA II gibt. 5. Periodenspezifikation Monat <months event type> ::= EVERY <digit months> MONTHS ON EVERY <day of week> AT <time value> EVERY <digit months> MONTHS ON <ordined> <day of week> AT <time value> EVERY <digit months> MONTHS ON <ordined digit day> DAY 29

33 4 ARTA II AT <time value> <digit months> ::= <ordined> ::= 1ST 2ND 3RD 4TH 5TH <ordined digit day> ::= 1ST... 31TH Für die Periodenspezifikation Monat wurden 3 Möglichkeiten realisiert, um dem Anwender bezüglich der Periodendefinition eine größtmögliche Flexibilität bieten zu können. Für digit months kann eine Zahl zwischen 1 und 12 angegeben werden. Sie gibt die Monate an in denen der Trigger ausgeführt werden soll. Die erste Spezifikation erlaubt Periodenangaben wie Jeden 2. Monat jeden Montag um 9:00 Uhr. Beginnt das Gültigkeitsintervalls am :00 und endet am :00, setzt sich die Menge der intendierten Ausführungszeitpunkte wie folgt zusammen: { :15,..., :15, :15,..., :15}. Der Trigger wird für jeden Montag im Monat Oktober ausgeführt. Danach erfolgt die Ausführung für jeden Montag im Monat Dezember. Ein Beispiel für die zweite Möglichkeit der Periodenspezifikation Monat ist Jeden 2. Monat an jedem 3. Montag um 9:00 Uhr. Der Unterschied zur ersten Periodenspezifikation Monat liegt darin, dass der Trigger beispielsweise nur jeden 3. Montag und nicht jeden Montag in einem Monat ausgeführt wird. Hierbei kann für ordined eine Zahl angegeben werden, so dass entweder der 1., 2., 3., 4., oder 5. Montag gewählt werden kann. Mit Hilfe der dritten und letzten Möglichkeit der Periodenspezifikation Monat können Formulierungen wie Jeden 2. Monat am 15. Tag um 9:00 Uhr verwendet werden. Für ordined digit day wird der Tag im Monat angegeben, zudem der Trigger aktiviert werden soll. Für ordined digit day können die Werte 1 bis 31 spezifiziert werden. 6. Periodenspezifikation Jahr <years event type> ::= EVERY <digit years> YEARS ON <ordined digit day> <month> AT <time value> EVERY <digit years> YEARS ON <ordined> <day of week> IN <month> AT <time value> <digit years> ::= <month> ::= JANUARY... DECEMBER 30

34 4 ARTA II Die erste von zwei Möglichkeiten bezüglich der Periodenspezifikation Jahr erlaubt Formulierungen wie Jedes 2. Jahr am 14. September um 9:00 Uhr. Ordined digit day gibt den Tag im Monat an zu dem der Trigger ausgeführt werden soll. Die letzte Spezifikation unterstützt Perioden der Form Jedes 2. Jahr am 3. Montag im Januar um 9:00 Uhr. Beginnt das Gültigkeitsintervall eines Triggers am und besitzt eine Dauer von 4 Jahren, ergeben sich bezüglich der genannten Periode folgende zwei intendierte Ausführungszeitpunkte: { :00, :00}. Die vorgestellten Periodenspezifikationen erlauben aufgrund ihrer Orientierung am allgemeinen Sprachgebrauch eine komfortable und intuitive Spezifikation periodischer Zeitereignistypen. Sie bieten zudem eine hohe Ausdrucksstärke. Des weiteren wird der Anwender aktiv bei der Spezifizierung der Perioden unterstützt, so dass die komplexe Semantik keine Einschränkung in Bezug auf die Benutzerfreundlichkeit darstellt Semantik Die Semantik der ARTA II-Modifikationstrigger orientiert sich am SQL-Trigger-Konzept, das in 3.3 beschrieben wurde. Aus diesem Grund wird - ähnlich zum Abschnitt der Fokus auf der Semantik der Zeitereignistrigger sowie auf den durch die Erweiterung um Steuerungskomponenten entstandenen semantischen Unterschieden zwischen ARTA IIund SQL-Triggern liegen. Die Unterschiede zwischen den ARTA II-Triggern und den SQL-Triggern liegen unter anderem im unterschiedlichen Prioritätenkonzept. In ARTA II erfolgt die Selektion nicht anhand des Erstellungsdatums, falls mehrere Trigger simultan durch ein Ereignis aktiviert werden, sondern anhand einer spezifizierten Prioriät. Diese Priorität wird durch eine natürliche Zahl dargestellt. Es wird derjenige Trigger ausgewählt, der die höchste Priorität besitzt. Hierbei erfolgt die Prioritätenvergabe für Modifikations- sowie für Zeitereignistrigger einheitlich, obwohl die Ausführung beider Triggertypen getrennt verläuft, vgl Weiterhin kann ein Trigger nur zur Ausführung ausgewählt werden, wenn die für ihn spezifizierte Deadline noch nicht abgelaufen ist. Ebenfalls stellt der Aktivierungszustand ein weiteres Selektionskriterium dar, der für ARTA II-Trigger definiert werden kann. Dieses Kriterium findet noch vor Überprüfung der Deadline und vor dem Prioritätenvergleich Anwendung. Anders als im Abschnitt 3.3 zur Semantik der SQL-Trigger beschrieben, können im ARTA II-System Modifikationstrigger nicht durch referentielle Aktionen gefeuert werden. Die Gründe hierfür werden genauer im Zusammenhang mit dem SQL-Statement- Modul in Abschnitt betrachtet. Während SQL-Trigger statische Schema-Objekte darstellen, wobei die Triggerspezifikationen nach ihrer Erstellung nicht mehr veränderbar 31

35 4 ARTA II sind, können die Spezifikationen von ARTA II-Triggern nach ihrer Definition modifiziert werden. Nachdem die Unterschiede zwischen der Semantik von SQL-Triggern und ARTA II- Triggern erläutert wurden, wird nun die Semantik der ARTA II-Zeitereignistrigger beschrieben. Die Semantikbeschreibung der Zeitereignistrigger soll nicht wie für SQL- Trigger anhand der Charakterisierung der Klassifikationsmerkmale (z.b. Ereignisverbrauchsmodus oder Kopplungsmodus), sondern mit Hilfe der Reduktion eines Zeitereignistriggers auf einen AFTER STATEMENT LEVEL-Modifikationstrigger erfolgen. Mit dieser Reduktion soll gezeigt werden, dass die Semantik der Zeitereignistrigger konsistent mit dem Entwurf von Modifkationstriggern spezifiziert werden kann. Die Reduktion eines Zeitereignistriggers auf einen solchen Modifikationstrigger soll nicht als Implementierungsvorschlag angesehen werden, sondern einzig dem Zweck der Semantikbeschreibung von Zeitereignistriggern dienen. Betrachten wir zunächst den AFTER STATEMENT LEVEL-Trigger tr_absolute in Beispiel 1. Dieser Trigger kann als semantisch äquivalent zu einem absoluten Zeitereignistrigger angesehen werden, der am um 10:15 Uhr seinen intendierten Ausführungszeitpunkt besitzt. Dieser löscht alle Studenten aus der Tabelle studs, die sich nicht bis zum um 10:15 Uhr für ihr Studium zurückgemeldet haben. Der Trigger benutzt eine Systemtabelle time-event _at_10:15, um auf das Zeitereignis reagieren zu können: Beispiel 1: CREATE TRIGGER tr_absolute AFTER INSERT ON time_event_ _at_10:15 FOR EACH STATEMENT WHEN ((SELECT Count(*)FROM unreg_studs)>0) BEGIN DELETE FROM studs WHERE name= SELECT name FROM unreg_studs; END Das Zeitereignis wird hierbei durch das Einfügen in eine Hilfstabelle zum Zeitpunkt um 10:15 Uhr simuliert. Ein Zeitereignistrigger mit einer periodischen Zeitereignispezifikation kann entsprechend durch mehrere AFTER STATEMENT-Modifikationstrigger ersetzt werden, da dessen Ereignisspezifikation eine Menge von Zeitereignissen repräsentiert. Ein Zeitereignistrigger kann nur als semantisch äquivalent zu dem hier vorgestellten Modifikationstrigger angesehen werden, solange das System in Betrieb ist. Der Grund liegt in der Unabhängigkeit eines Zeitereignisses vom System. Während das System für ein Modifikationsereignis eingeschaltet sein muss, damit dieses eintreten kann, ist es für das Eintreten von Zeitereignissen unerheblich. 32

36 4 ARTA II Neben dem angeführten Beispiel gibt es noch andere Gründe für eine konsistente Semantikdefinition beider Triggertypen. Beispielsweise ist es möglich, dass die Ausführung von aktivierten Zeitereignistriggern aufgeschoben werden muss, da andere Trigger gerade vom System ausgeführt werden. In diesem Fall ist es sinnvoll einen verzögerten (deferred) Kopplungsmodus bezüglich Ereigniseintritt und Bedingungsauswertung zu wählen, um diese verspätete Ausführung der Trigger zu erlauben. Bevor ein Zeitereignistrigger zur Ausführung selektiert werden kann, muss für ihn neben den Kriterien, die ein Modifikationstrigger erfüllen muss (aktiver Zustand, noch nicht abgelaufenen Deadline sowie eine maximale Priorität) zusätzlich folgende Bedingung erfüllt sein: Das Zeitereignis bezüglich dessen der Zeitereignistrigger ausgeführt werden soll, muss minimal sein, d.h. dieses Zeitereignis muss einen maximal in der Vergangenheit liegenden Zeitpunkt darstellen (im Vergleich zu den anderen aufgetretenen Zeitereignissen). Aus diesem Grund verläuft die Ausführung der Zeitereignistrigger streng chronologisch. Werden mehrere Trigger zum gleichen Zeitpunkt aktiviert, entscheidet die Priorität über die Reihenfolge der Ausführung. Hierbei ist es nicht möglich einem Trigger mit periodischer Zeitereignisspezifkation für seine verschiedenen Ausführungszeitpunkte unterschiedliche Prioritäten zuzuweisen, weil für jeden Trigger jeweils nur eine Priorität vorgesehen ist. Die Trigger werden bezüglich aufgetretener Zeitereignisse iterativ zur Ausführung ausgewählt und ausgeführt. Hierbei müssen die Transitionsvariablen im Bedingungs- sowie Aktionsteil nicht ersetzt werden, da bislang keine Ereignisparameter für Zeitereignistrigger in ARTA II unterstützt werden. Beinhaltet die Aktion eine Datenänderungsanweisung wird das beobachtete Modifikationsereignis rekursiv verarbeitet. Diese Verarbeitung verläuft in der in Abschnitt 3.3 beschrieben Weise mit den in diesem Abschnitt genannten Unterschieden bezüglich der Steuerungskomponenten eines ARTA II-Triggers. Modifikations- und Zeitereignistrigger werden in ARTA II getrennt ausgeführt, d.h. es werden entweder Modifikationstrigger oder Zeitereignistrigger ausgeführt, nicht beide Triggertypen gleichzeitig. Es besteht lediglich die Möglichkeit, dass durch eine Datenänderungsanweisung im Aktionsteil eines Zeitereignistrigger, die aktuelle Triggerausführung unterbrochen wird, um diese Änderungsanweisung und der durch sie aktivierten Modifikationstrigger auszuführen. Die Motivation für die Trennung der Ausführung von Modifikations- und Zeitereignistriggern liegt im Zusammenspiel von Transaktionen und Triggern. Dieses Zusammenspiel wird im folgenden Abschnitt ausführlicher betrachtet ARTA II-Trigger und Transaktionen Alle Datenbankanweisungen sollten mit den durch sie aktivierten Modifikationstriggern in einer Transaktion ausgeführt werden. Tritt während der Transaktion ein Fehler auf, können alle Datenänderungen zurückgesetzt werden, die innerhalb der Transaktion vorgenommen wurden. Transaktionen bilden eine Einheit, in der entweder alle Datenänderungs- 33

37 4 ARTA II Anweisungen in die Datenbank eingebracht werden oder - im Falle eines Fehlers - keinerlei Änderungen erfolgen. Neben SQL-Statements sollten Zeitereignistrigger ebenso Transaktionen initiieren, da der Aktionsteil dieser Trigger ebenfalls Datenänderungsanweisungen beinhalten kann. Diese Anweisungen können zum Eintritt eines Modifikationsereignisses und folglich zur Aktivierung von weiteren Triggern führen. Die rekursive Abarbeitung dieser resultierenden Menge von aktivierten Modifikationstriggern sollte innerhalb einer Transaktion erfolgen. Auf diese Weise kann garantiert werden, dass entweder alle Anweisungen ausgeführt werden oder im Falle eines Fehlers keine Ausführung dieser Anweisungen erfolgt. Falls während des Auftretens eines Zeitereignisses bereits eine Transaktion im System aktiv ist, besteht einerseits die Möglichkeit die Ausführung der Zeitereignistrigger in diese Transaktion zu integrieren oder deren Ausführung zu verzögern bis die Transaktion beendet ist. 1 Im Sinne einer möglichst zeitnahen Ausführung (zum intendierten Ausführungszeitpunkt) der Zeitereignistrigger wäre es sinnvoll, diese Trigger nicht nach Beendigung der Transaktion, sondern während der Abarbeitung der AFTER-Trigger ausführen zu lassen. Probleme treten auf, wenn eine Transaktion aufgrund eines Fehlers zurückgesetzt wird. In diesem Fall müssen die durch den Zeitereignistrigger vorgenommenen Datenänderungen ebenfalls zurückgesetzt werden, obwohl diese bei isolierter Ausführung der Zeitereignistrigger in der Datenbank hätten festgeschrieben werden können. Dies bedeutet, dass die erfolgreiche Ausführung eines Zeitereignistriggers von der erfolgreichen Ausführung einer fremden Transaktion abhängig ist. Aus diesem Grund sollte ein Zeitereignistrigger nicht in eine laufende Transaktion eingegliedert werden, sondern seine eigene Transaktion erhalten, in der ebenfalls alle resultierenden Modifikationstrigger ausgeführt werden. In parallelen Systemen kann diese verzögerte Ausführung von Zeitereignistrigger teilweise vermieden werden, da in diesen Systemen mehrere Transaktionen gleichzeitig ausgeführt werden können. Nun gibt es im DBMS Access kein Transaktionskonzept. Allerdings wurde im ARTA II-System mit Hilfe der Programmiersprache VBA eine vereinfachte Form eines Transaktionskonzeptes umgesetzt. Dieses Konzept entspricht nicht der Funktionalität richtiger Transaktionen, wie diese in kommerziellen DBMS umgesetzt werden. Es wird lediglich mit dem Befehl BeginTrans() eine Transaktion gestartet. Ab diesem Befehl werden alle Datenänderungen zunächst zwischengespeichert. Der Befehl CommitTrans() beendet die aktuelle Transaktion. Hierbei werden alle Datenänderungen festgeschrieben, die innerhalb der Transaktion vorgenommen wurden. Mit dem Befehl Rollback() wird - im Fall eines Fehlers - die aktuelle Transaktion beendet und der Zustand der Datenbank vor Beginn der Transaktion wiederhergestellt. Das Starten und Beenden einer Transaktion geschieht vom Anwender des ARTA II-Systems unbemerkt. Eine solche Transaktion wird in ARTA II einerseits durch ein vom Anwender eingegebenes SQL-Statement oder andererseits durch einen Zeitereignistrigger initiiert. Das bedeutet Zeitereignistrigger werden nicht in eine laufende Transaktion integriert. Insbesondere werden alle Zeitereignistrigger 1 Diese verzögerte Ausführung der Zeitereignistrigger ist möglich, da deren E(CA)-Kopplung deferred ist. 34

38 4 ARTA II iterativ und isoliert voneinander bearbeitet, um eine gegenseitige Beeinflussung der Ausführungen von Zeitereignistriggern zu vermeiden. Jeder Zeitereignistrigger initiiert seine eigene Transaktion. In ARTA gibt es keine Nebenläufigkeit, demnach besteht nicht die Möglichkeit mehrere Transaktion gleichzeitig auszuführen. 4.3 Komponenten von ARTA II Dieser Abschnitt widmet sich der Architektur des ARTA II-Systems. Zunächst soll erläutert werden, in welchem Zusammenhang das System ARTA II und das relationale Datenbankmanagementsystem Access stehen. Anschließend werden die Komponenten des Systems beschrieben. Diese Beschreibungen orientieren sich weitgehend an [Fad02] sowie [Cali04]. In und werden die zwei wichtigsten Module von ARTA II vorgestellt Systemarchitektur Für die Architekturdiskussion muss die Frage geklärt werden, wie Access im Kontext von Datenbanksystemen (DBS) einzuordnen ist. Zunächst stellen wir fest, dass Access kein DBS sondern ein Datenbankmanagementsystem (DBMS) ist, da dieses System bei Auslieferung nur anwendungsunabhängige Dienste (vgl. [Man03]) und keine benutzterdefinierten Datenbanken zur Verfügung stellt. Access ist jedoch mehr als ein DBMS. Zusätzlich zu den Funktionalitäten eines DBMS bietet Access die Möglichkeit grafische Anwendungen sehr komfortabel zu erstellen, durch die auf die benutzerdefinierte Datenbanken zugegriffen werden kann. Das eigentliche DBMS stellt die zu Access gehörige Jet Datebase Engine dar. Das System ARTA II wurde als Access-Anwendung entwickelt und ist demnach wie Abbildung 4.1 zeigt innerhalb von Access anzuordnen. Dabei legt sich dieses System wie eine aktive Schicht auf die Jet Database Engine von Access, vgl [Cali04]. Sämtliche vom Benutzer über die grafische Benutzeroberfläche von ARTA II eingegebenen Befehle können einerseits mit Hilfe der Jet Database Engine an die darunterliegende Datenbank weitergegeben werden. Andererseits können alle vom Benutzer angeforderten Daten aus der Datenbank, durch die Schicht mittels der ARTA II-Oberfläche sichtbar gemacht werden. Somit stellt die Jet Database Engine die Schnittstelle zwischen der ARTA II-Anwendung und den für diese Anwendung benötigten Daten dar und wird für den Zugriff auf Tabellen und Abfragen benötigt. Vorteil dieses Ansatzes ist - der auch als layered architecture bezeichnet wird -, dass ein passives Datenbankmanagementsystems um eine aktive Komponente ergänzt werden kann, ohne Veränderung des Sourcecodes und ohne zu Hilfenahme einer externen Anwendung oder Applikation. Der Nachteil besteht in der Gefahr der geringen Performance, da der Kommunikationsaufwand zwischen der aktiven Schicht und der Datenbank um ein Wesentliches erhöht ist. 35

39 4 ARTA II Abbildung 4.1: ARTA II und MS-Access 36

40 4 ARTA II In Abbildung 4.2 sind die Komponenten des Systems ARTA II abgebildet. Zusätzlich sind die Kontrollstrukturen bzw. ist die Kommunikation der Komponenten untereinander mittels Pfeilen dargestellt. Die hier präsentierte Systemarchitektur orientiert sich an der Systemarchitektur, die in der Diplomarbeit [Cali04] vorgestellt wurde. Zusätzlich wurden die Kontrollstrukturen zwischen den Komponenten vervollständigt. Auf die Funktionalitäten der einzelnen Komponenten und die Beziehungen untereinander wird im Folgenden ausführlich eingegangen. Abbildung 4.2: Komponenten von ARTA II Zum ARTA II-System gehört zunächst die grafische Benutzeroberfläche, die die Schnittstelle zwischen dem Benutzer und dem System darstellt. Diese Oberfläche setzt sich aus mehreren Access-Formularen zusammen. Formulare sind Access-Objekte, die die Ausführung von Access-Anwendungen steuern. Zusätzlich können sie an eine Tabelle oder Anfrage gebunden sein. Daten der Tabellen und Anfragen können so mittels des Formulars modifiziert, hinzugefügt oder gelöscht werden. Wird ARTA II von einem Benutzer gestartet, öffnet sich zunächst das ARTA II-Hauptfenster, von dem aus drei weitere Formulare zu erreichen sind. Hier hat der Benutzer die Wahl 37

41 4 ARTA II zwischen dem Triggerübersichtsformular, dem SQL-Statement Formular sowie dem Ereignistyp- Formular, indem sämtliche in ARTA II gespeicherten Ereignismuster angezeigt werden. Den logischen Teil dieser Oberfläche bilden so genannte Schemakomponenten (SQL- Statement-Modul, Trigger-Modul, Ereignis-Modul, Ereignistyp-Modul), die für die Verwaltung von Daten zuständig sind. Diese Schemakomponenten liegen in Form von Ereignisund Anwendungprozeduren vor. Hierbei verläuft beispielsweise - anders als in [Cali04] dargestellt - die Kommunikation zwischen der Benutzeroberfläche und den Schemakomponenten in beide Richtungen. Einerseits werden Daten durch den Anwender mit Hilfe der Oberfläche in das System eingegeben. Andererseits zeigt die Oberfläche entsprechend den vom Anwender gegebenen Anweisungen Daten an. Das Triggerübersichtsformular dient der Anzeige aller vorhandenen Triggerspezifikationen in einer Liste. Wird ein Trigger aus der Liste ausgewählt, erfolgt eine Anzeige der zugehörigen Spezifikation im übrigen Formular. Zum einen können hier Spezifikationen von Triggern gelöscht werden, zum anderen kann auch ein weiteres Formular (der Triggereditor) aufgerufen werden mittels dessen die Spezifikationen entweder modifiziert oder neu definiert werden können. Die logische Komponente des Triggerübersichtsformulars und des Triggereditors bildet das Trigger-Modul. Dessen Aufgaben sind die Korrektheitsprüfung bei Erstellung und Modifizierung einer Triggerspezifikation sowie deren Speicherung in der Datenbank. Tritt bei der Korrektheitsprüfung ein Fehler auf, wird dies im Formular angezeigt und der Benutzer erhält die Möglichkeit seine eingegebenen Daten zu revidieren. Im Falle eines Zeitereignistriggers wird für ihn der nächste Ausführungszeitpunkt berechnet, der nach Spezifikation im Formular angezeigt wird. Die Möglichkeit der Einbringung von SQL-Statements in die Datenbank wird durch das SQL-Statement Formular gegeben, das ebenfalls aus dem ARTA II-Hauptfenster heraus aufgerufen werden kann. Es besteht nur die Möglichkeit die drei Datenmanipulations- Befehle DELETE, INSERT sowie UPDATE abzusetzen. Der Grund dieser Einschränkung liegt darin, dass nicht ein Terminal geschaffen werden sollte mit dem es möglich ist sämtliche SQL-Statements einzugeben. Das Eingeben der SQL-Statements kann weiterhin direkt in Access geschehen. Statt dessen sollte ARTA II die Beobachtung von Änderungsereignissen und die damit verbundene Ausführung von Modifikationstriggern ermöglicht werden. Für den Benutzer ergibt sich demnach folgende Einschränkung. Erwartet er, dass seine Änderungsanweisung vom System beobachtet wird sowie eine Aktivierung von ARTA II-Triggern durch dieses Änderungsereignis erfolgt, muss er seine Anweisung im SQL-Statement Formular eingeben. Das System kann anschließend, nach der Ereignisbeobachtung, mit der Triggerausführung beginnen. Somit dient dieses Formular hauptsächlich der Ereigniserkennung. Vollzieht der Benutzer die Änderung direkt an der Tabelle oder erstellt eine Abfrage, die eine Manipulation an einer Tabelle nach sich zieht, wird diese Änderung nicht vom System ARTA II erkannt. Ebenfalls werden die von der Jet Database Engine vorgenommenen referentiellen Aktionen nicht als Modifikationsereignisse erkannt. Ein SQL-Editor kann aufgerufen werden, wenn der Benutzer eine neue SQL-Änderungsanweisung erstellen oder eine bestehende modifizieren möchte. Mit Hilfe dieses Editors soll eine 38

42 4 ARTA II möglichst einfache Erstellung und somit auch eine einfache Ausführung solcher SQL- Statements gewährleistet sein. Auch hier übernimmt das so genannte SQL-Statement- Modul die Verwaltung der Daten. Soll eine SQL-Statement abgegeben werden, wird zunächst vom SQL-Statement-Modul geprüft, ob es sich um eine Änderungsanweisung handelt. Anschließend wird sie an das Trigger Ausführungs-Modul weitergegeben. Nachdem die Datenänderung erfolgreich in die Datenbank eingebracht wurde, erfolgt eine Meldung an den Benutzer. Eine Fehlermeldung wird angezeigt, wenn bei der Ausführung ein Fehler aufgetreten ist. Das SQL-Statement-Modul hat Zugriff auf sämtliche gespeicherten SQL-Statements, die als Vorlage für weitere noch zu erstellende SQL-Statements dienen und somit die Definition neuer Datenänderungsbefehle erleichtern können. Schließlich ist es möglich vom ARTA II-Hauptformular zu dem Ereignistyp-Formular zu gelangen. Hier erhalten wir eine Übersicht zu allen Triggern mit Fokus auf ihre Ereignisspezifikation. Die Trigger sind nach ihren Ereignisklassen sortiert. Zusätzlich kann aus diesem Fomular heraus der Triggereditor aufgerufen werden und eine neuer Trigger spezifiziert werden. Das Ereignistyp-Modul ist für die Verwaltung der Ereignismuster verantwortlich. Eine Weiterentwicklung dieser Komponenten ist im Rahmen dieser Diplomarbeit nicht erfolgt. Das Ereignis-Modul verwaltet eine Protokoll-Datei namens ARTAII_LOGDATA. In dieser Datei wird der Verlauf der Triggerausführung protokolliert. Die Einträge werden durch das Zeitereignis-Modul und das Trigger-Ausführungsmodul vorgenommen. Die Protokoll- Datei kann über die grafische Benutzeroberfläche eingesehen werden. Für die Beschreibung des Zeitereignis-Moduls und des Trigger Ausführungs-Moduls sind zwei zusätzliche Abschnitte vorgesehen, und 4.3.3, da diese Module entscheidene Aufgaben des ARTA II-Systems übernehmen Das Zeitereignis -Modul Das Zeitereignis-Modul interagiert mit dem Trigger-Modul und dem Trigger Ausführungs- Modul. Es dient der Erkennung von Zeitereignissen sowie der Verwaltung von Zeitereignistriggern mit absoluter oder periodischer Zeitereignisspezifikation.. Durch das Trigger- Modul hat dieses Modul immer Zugriff auf die aktuellen Spezifikationen der Zeitereignistrigger, die ihm als aktuelle Ausführungsliste dienen. Um das Eintreten von Zeitereignissen in ARTA II wahrnehmen zu können, wurde die Timerfunktionalität des Betriebssystems genutzt, die über die API-Schnittstelle angesprochen werden kann. Nach dem Einschalten des Systems sowie nach ausgeführten Datenbankänderungen wird nach Zeitereignissen gesucht, die in der Vergangenheit aufgetreten sind. Diese Zeitereignisse werden vollständig verarbeitet, bevor ein (neuer) Timer für ein in der Zukunft liegendes Zeitereignis gesetzt wird. Die verzögerte Verarbeitung von aufgetretenen Zeitereignissen wird im Rahmen der Erweiterungskonzepte für das System ARTA II in genauer betrachtet. 39

43 4 ARTA II Abbildung 4.3: Arbeitsweise der Zeitereigniserkennung Abbildung 4.3 zeigt die Arbeitsweise der Zeitereigniserkennung und Timerverwaltung in ARTA II. Existieren keine in der Vergangenheit aufgetretenen und nicht verarbeiteten Zeitereignisse, kann ein neuer Timer gesetzt werden. Hierbei wird geprüft, ob Zeitereignisse vorliegen die innerhalb der nächsten 7 Tage eintreten. Ist dies der Fall wird ein Timer für diesen Zeitpunkt gesetzt. Anderseits wird ein so genannter interner Timer für den nächsten Tag gleicher Uhrzeit gesetzt. Aus implementierungstechnischen Gründen ist es nicht möglich einen Timer für einen mehr als 7 Tage in der Zukunft liegenden Zeitpunkt zu setzen. Ist der Timer für ein Zeitereignis abgelaufen, werden die aktivierten Trigger iterativ abgearbeitet. Während der Bearbeitung dieser Trigger können weitere Zeitereignisse eintreten. Deshalb wird nach der Triggerausführung erneut geprüft, ob Zeitereignisse aufgetreten sind, die zur Aktivierung von Triggern beigetragen haben könnten. Anschließend, nach Abarbeitung aller aktivierter Zeitereignistrigger, kann ein neuer Timer in der im vorhergehenden Absatz beschriebenen Weise gesetzt werden. Kam es zum Ablauf eines internen Timers wird sofort ein neuer Timer gesetzt. Für die jeweilige Bearbeitung eines durch ein Zeitereignis aktivierten Triggers wird die Prozedur ExecuteTimeEventsTriggerAction(Trigger) aufgerufen, die schematisch in Abbildung 4.4 dargestellt ist. In dieser Prozedur wird entschieden, ob der Trigger zur Ausführung herangezogen werden kann. Ein aktiver Trigger wird ausgeführt, wenn seine Deadline nicht abgelaufen ist, d.h. wenn der intendierte Ausführungszeitpunkt + Deadline in 40

44 4 ARTA II Abbildung 4.4: Prozedur ExecuteTimeEventsTriggerAction(Tr) der Zukunft liegen und die Triggerbedingung zu True evaluiert werden kann. Für einen solchen Trigger wird die doaction-methode des Trigger Ausführungs-Modul aufgerufen, die im folgenden Abschnitt (4.3.3) näher beschrieben werden soll. Nach Abschluß der Ausführung werden die Spezifikationen absoluter Zeitereignistrigger aus der Datenbank gelöscht, da durch ihre Ereignisspezifikation genau ein Zeitpunkt definiert wird und sie somit nur genau einmal aktiviert werden können. Für Trigger mit einer periodischen Zeitereignisspezifikation erfolgt die Berechnung des nächsten Ausführungszeitpunktes mittels der Prozedur calcnextexecution(trigger) aus dem Trigger- Modul. Liegt der neu berechnete Ausführungszeitpunkt nicht mehr im Gültigkeitsintervall des periodischen Zeitereignistriggers, wird dieser als abgearbeitet markiert. Das Zeitereignis-Modul wird aus dem Trigger-Modul heraus aufgerufen, nachdem ein neuer Zeitereignistrigger spezifiziert wurde. Dies ist dadurch motiviert, dass der Ausführungszeitpunkt dieses Triggers zeitlich vor dem Zeitpunkt liegen kann für den der aktuelle Timer gesetzt ist. So kann der Timer neu initialisiert werden und es ist ausgeschlossen, dass durch das System eventuell ein Zeitereignis nicht erkannt wird. Bei Modifizierung der Periode eines Zeitereignistrigger wird diese Modifizierung erst bei der Berechnung des nächsten Ausführungszeitpunktes beachtet, d.h. der Ausführungszeitpunkt des Triggers besteht unverändert und erst nach dessen Ausführung wird die modifizierte Periode in die Berechnung des nächsten Ausführungszeitpunktes mit einbezogen. 41

45 4 ARTA II In der Datei namens ARTAII_LOGDATA protokolliert das System den Verlauf der Bearbeitung der Zeitereignistrigger. Darin wird festgehalten, ob der Trigger zur Ausführung herangezogen werden konnte, d.h. ob die Deadline des Triggers nicht abgelaufen ist. So kann der Benutzer leicht die Reihenfolge der Abarbeitung der Zeitereignistrigger nachvollziehen und falls gewünscht nicht erfolgte Aktionsausführungen nachholen Das Trigger Ausführungs -Modul Das Trigger Ausführungs-Modul interagiert mit dem SQL-Statement-Modul und dem Zeitereignis-Modul. Durch das Trigger Ausführungs-Modul werden einerseits die SQL- Statements ausgeführt, die entweder über das SQL-Statement-Formular eingegeben werden oder eine in einem Modifikations- oder Zeitereignistrigger spezifizierte Aktion darstellen. Andererseits werden benutzerdefinierte Funktionen ausgeführt, die ebenfalls in der Aktion eines Triggers vorkommen können. In beiden Fällen wird eine ARTA-Transaktion 2 gestartet, die gewährleistet, dass entweder sämtliche Datenänderungen vorgenommen oder im Falle eines Fehlers während der Ausführung zurückgesetzt werden. In der Prozedur doaction() wird diese erzeugt. Um zu verhindern, dass ARTA II während der Ausführung eines SQL-Statements oder einer benutzerdefinierten Funktion vom Benutzer beendet wird, öffnet sich im Hintergrund das unsichtbare Formular ControlSystemClose. Für dieses Formular wird festgelegt, bevor die Prozedur doaction() aufgerufen wird, dass es nicht geschlossen werden darf. Somit wird im Falle einer möglichen, teilweisen Ausführung aktivierter Trigger, ein inkorrekter Zustand des Systems verhindert. Nach der Berarbeitung einer benutzerdefinierten Funktion oder eines SQL-Statements und aller durch das Statement aktivierten Trigger können das Formular ControlSystemClose und auch ARTA II wieder geschlossen werden. Somit ist das vorzeitige Beenden des Systems durch den Benutzer ausgeschlossen. Anders als in [Cali04] beschrieben wird die Methode doaction() dem Trigger Ausführungs- Modul zugeordnet. Diese Prozedur wird nicht nur vor der Aktionsausführung eines Zeitereignistriggers aufgerufen, sondern auch vor der Ausführung eines SQL-Statements, das im SQL-Formular eingegeben wurde. Zum Aufruf der Methode ExecuteSQLStatement(strSQL) kommt es, nachdem in doaction() eine ARTA-Transaktion gestartet wurde. In dieser Methode wird zunächst das, bereits in Abschnitt 3.3 über die Semantik der SQL-Trigger erwähnte, Trigger Execution Context (TEC) initialisiert. Hierbei wird u.a. die Menge von Transitionen bestehend aus den zwei temporären Tabellen OLD Table und NEW Table berechnet, um die Transitionsvariablen in Bedingungs- bzw. Aktionsteil eines Triggers unmittelbar vor Bedingungsauswertung bzw. Aktionsausführung durch deren Werte ersetzen zu können. Zuvor wird geprüft, ob Trigger durch die Datenänderung gefeuert werden. Ist dies nicht der Fall wird 2 Die im ARTA II-System realisierten Transaktionen sollen im Folgenden als ARTA-Transaktionen bezeichnet werden. 42

46 4 ARTA II der Befehl ausgeführt, jedoch kein TEC erzeugt. Andererseits folgt die Ausführung der BEFORE-Trigger. Die Aktionsausführung erfolgt in der Prozedur ExecuteAction(strSQL) in der Datenbankänderungen in die Datenbank eingebracht aber auch benutzerdefinierte Prozeduren ausgeführt werden können. Trigger mit einem leeren Aktionsteil werden zwar immer wieder bei Eintritt ihres aktivierenden Ereignisses ausgelöst, für sie wird jedoch keine Aktion ausgeführt und somit auch kein Laufzeitfehler ausgelöst. Nachdem sämtliche BEFORE-Trigger abgearbeitet wurden, erfolgt die Ausführung des SQL-Statements ebenfalls in der Prozedur ExecuteAction(strSQL). Die Ausführung der After-Trigger verläuft analog zu der Bearbeitung der BEFORE-Trigger. Allerdings können durch AFTER- Trigger weitere Triggeraktivierungen erfolgen. Aus diesem Grund wird für die Aktionsausführung rekursiv die Prozedur ExecuteSQLStatement(strSQL) aufgerufen und nicht wie in [Cali04] beschrieben die Prozedur ExecuteAction(strSQL). In der Prozedur ExecuteSQLStatement(strSQL) wird ein TEC unabhängig vom aktuellen TEC erzeugt. Die Rekursion ist beendet, wenn alle AFTER-Trigger ausgeführt wurden. Ein Terminierungsproblem entsteht, falls ein Trigger sich direkt oder indirekt immer wieder selbst auslöst. Um in diesem Fall eine Terminierung zu erzwingen, wurde in ARTA II eine Beschränkung der Kaskadentiefe vorgenommen. Wird die Kaskadentiefe erreicht, folgt ein Rollback der ARTA-Transaktion. Dies bedeutet, dass alle SQL-Anweisungen zurückgesetzt werden, die innerhalb der ARTA-Transaktion Anwendung fanden. Diese Anweisung haben somit keine Auswirkung auf den Datenbankzustand. Die Ausführung eines SQL-Statements, einer benutzerdefinierten Funktion sowie einer Triggeraktion wird protokolliert. Es werden die erfolgreich ausgeführten Datenänderungsanweisungen und die durch sie gefeuerten Trigger in der ARTAII_LOGDATA Datei festgehalten. Ebenso erhält eine fehlerhafte Ausführung von Datenänderungen einen Eintrag in der Log-Datei. Weiterhin existiert eine Tabelle Event-History in der alle ausgeführten Trigger zusammen mit ihrem Ausführungszeitpunkt protokolliert werden. 4.4 Diskussion des bestehenden Systems Im Rahmen dieser Arbeit wurde eine Analyse des bestehenden Systems durchgeführt. Diese Analyse ergab, dass grundsätzliche Ziele umgesetzt werden konnten. Jedoch existierten ebenso eine Reihe von Defiziten. Zunächst wird in diesem Abschnitt auf die Ziele und Funktionalitäten eingegangen, die im ARTA II-System erfolgreich realisiert werden konnten. Anschließend werden einige der Defizite bzw. Einschränkungen aufgeführt, die das System bei der Analyse zeigte. ARTA II wurde entworfen, um das Datenbankmanagementsystem Access um eine aktive Komponente zu erweitern, die zum einen Zeit- und Änderungsereignisse erkennen, Triggerspezifikationen verwalten sowie Trigger ausführen kann. Dieses System sollte möglichst einfach gehalten werden, jedoch dem Benutzer ein komfortables Werkzeug zur Verfügung stellen, das ihn aktiv bei der Definition und Modifizierung von Triggerspezifikationen unterstützt. Dabei sollte der Anwender sich beispielsweise bei mehr als 10 43

47 4 ARTA II Triggerspezifikationen leicht eine Übersicht über diese Spezifikationen verschaffen können. Durch den Einsatz von Formularen als Benutzeroberflächen und durch die Bereitstellung von Formularen, wie dem Triggereditor und dem Triggerübersichts-Formular, konnten diese Ziele umgesetzt werden. Mit Hilfe des Triggereditors kann der Benutzer ohne die Syntax eines Triggers zu kennen, diesen ohne großen Aufwand definieren. Zusätzlich werden durch das Trigger-Modul Syntaxprüfungen durchgeführt, so dass fehlerhafte Eingaben direkt korrigiert werden können. Durch das Triggerübersichts-Formular erhält der Benutzer eine Übersicht über alle erstellten Trigger, deren aktivierenden Ereignistyp sowie über die nächsten Ausführungszeitpunkte von Zeitereignistriggern. Mittels der Log- Datei, in der das Eintreten von Ereignissen und die Triggerausführungen protokolliert werden, kann der Benutzer jederzeit nachvollziehen welche und in welcher Reihenfolge Trigger ausgeführt wurden. Um das Eintreten von Zeitereignissen in ARTA II beobachten zu können, werden Timer gesetzt. Diese Timer, die mittels einer API-Schnittstelle realisiert werden, laufen in separaten Prozessen im Betriebssystem ab. Somit wird die in Access zu bewältigende Datenverarbeitung und deren Geschwindigkeit nicht beeinträchtigt. Damit ARTA II Änderungsereignisse beobachten kann, wurde das SQL-Statement Formular erstellt. SQL-Statements können in der Datenbank gespeichert werden, so dass der Benutzer bei Erstellung eines neuen SQL-Statements meist nur ein Bestehendes Statement modifizieren muss, und so das Definieren von SQL-Statements erheblich erleichtert wurde. Dem System ARTA II ist es jedoch einzig möglich auf Änderungsereignisse zu reagieren, die im SQL-Statement Formular eingegeben werden. Referentielle Aktionen beispielsweise bleiben von ARTA II unbemerkt. Es besteht keine Möglichkeit diese eingeschränkte Funktionaltität mit einer Access-Anwendung umzusetzen, da die Sourcecodes von Access und der jet database engine nicht erweiterbar sind (vgl. [Cali04]). Defizite zeigte das System bei der Verarbeitung von Zeitereignissen und der Ausführung der durch sie aktivierten Trigger. Zum Beispiel konnte immer nur ein Zeitereignistrigger bezüglich genau eines Zeitereignisses korrekt ausgeführt werden. Existierten mehrere Trigger mit einem identischen nächsten Ausführungszeitpunkt, konnte nicht garantiert werden, dass diese immer ausgeführt wurden. Hierbei wurden immer die absoluten Zeitereignistrigger präferiert, obwohl die Selektion allein anhand der Prioritäten vorgenommen werden sollte. Die Berechnung des jeweils nächsten Ausführungszeitpunktes für Trigger mit einer periodischen Zeitereignisspezifikation erfolgte bezüglich der Periodenspezifikationen Monat und Jahr teilweise überhaubt nicht oder fehlerhaft. Des weiteren verlief die verzögerte Verarbeitung von aufgetretenen Zeitereignissen nach Systemstart nicht korrekt. Hierbei wurden die aktivierten Trigger nicht in der chronologisch korrekten Reihenfolge ausgeführt. Ebenso konnte es zur Instabilität des Systems nach dessen Wiedereinschalten kommen, wenn zu viele Zeitereignisse zu verarbeiten waren. Dies geschah unabhängig davon, ob die Aktion eines Zeitereignistrigger noch aus- 44

48 4 ARTA II geführt werden konnte, oder deren Deadline abgelaufen war und keine Aktionausführung erfolgte. Ebenfalls existierten Einschränkungen bezüglich der Steuerungskomponenten, um die die ARTA II-Trigger erweitert wurden. Unter anderem konnte der Benutzer auf die Prioritäten der Trigger keinen Einfluß nehmen. Die Prioritäten wurden vom System vorgegeben und konnten durch den Anwender nicht modifiziert werden. Einem neu spezifizierten Trigger wurde immer die maximalvorhandene Priorität + 1 zugeordnet, so dass die Trigger in der Reihenfolge in der sie erstellt wurden die Prioritäten zugeteilt bekamen. (Somit entsprach das Prioritätenkonzept dem bezüglich der SQL-Trigger vorgestellten Konzept.) Ebenso war es lediglich möglich eine Deadline mit der Granularität Minute anzugeben. Dabei war die Angabe der Deadline auf den Datentyp Integer beschränkt. Variablen von diesem Datentyp werden als 16-Bit-Zahlen gespeichert und können Zahlen im Bereich von bis darstellen. Somit konnte höchstens ein Zeitraum von 3 Wochen für die Deadline spezifiziert werden. Wollte der Anwender eine Deadline von etwa 2 Wochen für einen Trigger angeben, musste er diese erst in Minuten umrechnen. Diese Form der Berechnung kann für den Anwender sehr aufwendig werden. Zudem wurde die Praxistauglichkeit eingeschränkt falls das System länger als 3 Wochen ausgeschaltet bleiben sollte. Angenommen der Anwender schaltet das System erst nach einer längeren Pause wieder ein, nach etwa einem Monat. Dann ist es möglich, dass die Ausführung eines Triggers mit periodischer Zeitereignisspezifikation, der nur alle 6 Monate aktiviert wird - dessen Ausführung jedoch von großer Bedeutung und Wichtigkeit ist - an einer zu kurzen Deadline scheitert. So müsste der Benutzer nach längerer Inaktivität des Systems in der Log-Datei nachsehen, welche Zeitereignistrigger noch ausgeführt werden konnten und welche nicht, um gegebenfalls dringende Aufgaben nachzuholen. Bezüglich der Bedingungsauswertung gab es folgende Einschränkungen: Während für Zeitereignistrigger die Evaluierung der Bedingung (unabhängig von ihrer Spezifikation) in jedem Fall TRUE lieferte, wurden für Modifikationstrigger die referenzierten Transitionsvariablen nicht ersetzt, so dass die Bedingungsevaluierung FALSE ergab, wenn die Bedingung Transitionsvariablen enthielt. Außerdem konnten zum Teil Triggerspezifikationen in der Datenbank gespeichert werden, ohne dass eine Syntaxprüfung vorgenommen wurde. Die nicht korrekt spezifizierten Trigger wurden ohne besondere Kennzeichnung in der Triggerübersicht angezeigt, so dass der Benutzer nicht auf einen Blick erkennen konnte, ob es sich um einen korrekt spezifizierten Trigger handelt oder nicht. Die Analyse des ARTA II-Systems ergab, dass das System Defizite in Bezug auf die Spezifizierung der Steuerungskomponenten in Hinblick auf die Benutzerfreundlichkeit zeigte. Ebenso erfolgte die Evaluierung der Triggerbedingung vor Triggerausführung nicht korrekt. Des weiteren konnte die Ausführung von Zeitereignistriggern in der chronologisch korrekten Reihenfolge vom System nicht garantiert werden. Die korrekte Bedingungsauswertung und die korrekte Triggerausführung sind jedoch Voraussetzung für eine 45

49 4 ARTA II erfolgreiche Erweiterung des ARTA II-Systems um Trigger mit einer relativen Zeitereignisspezifikation. Aus diesem Grund wurde das System ARTA II erweitert bzw. modifiziert. Diese Erweiterungen bzw. Modifikationen werden im Kapitel 5 detailliert erläutert. 46

50 5 Allgemeine Erweiterungen und Modifikationen von ARTA II Die Diskussion des bestehenden ARTA II-Systems in Abschnitt 4.4 ergab, dass dieses System Defizite aufzeigte. Bevor das System ARTA II um Trigger mit relativen Zeitereignisspezifikationen erweitert werden kann, müssen die erwähnten Defizite des Systems beseitigt bzw. aufgehoben werden. Die Beseitigung der Defizite ist die Voraussetzung für eine korrekte Verwaltung und Ausführung von Triggern mit relativen Zeitereignisspezifikation sowie für die korrekte Speicherung der Spezifikationen von relativen Zeitereignistriggern in der Datenbank. Aus diesem Grund wurden zunächst Erweiterungen am System vorgenommen, die in diesem Kapitel beschrieben werden. In Abschnitt 5.1 bzw. 5.2 wird auf die Erweiterungen näher eingegangen, die bezüglich der Trigger-Steuerungkomponenten bzw. der Zeitereignistrigger vorgenommen wurden. Weitere allgemeine Funktionalitäten, um die das System erweitert wurde, sollen im Folgenden kurz genannt werden. Diese Erweiterungen bedürfen keiner detaillierten Erläuterung. Infolgedessen sind für sie keine weiteren Abschnitte vorgesehen. 1. Für Modifikations- und Zeitereignistrigger können Bedingungen spezifiziert werden, deren Auswertung korrekt erfolgt. Vor Bedingungsauswertung werden die Transitionsvariablen eines Modifikationstriggers in der Bedingung durch ihre Werte ersetzt. Des weiteren können Bedingungsanweisungen beginnend mit EXISTS vom Anwender spezifiziert werden. 2. Eine Triggerspezifikation konnte vom System ohne explizite Aufforderung durch den Benutzer in der Datenbank gespeichert werden. Hierbei wurde keine Syntaxprüfung vorgenommen. In der Triggerübersicht wurde der Trigger mit angezeigt, ohne dass der Benutzer diesen Trigger von anderen korrekt spezifizierten Triggern unterscheiden konnte. Nach Erweiterung des Systems können nur noch korrekt definierte Triggerspezifikationen in der Datenbank gespeichert werden, wobei dies ausdrücklich vom Anwender (durch Drücken des save Buttons) angegeben werden muss. 3. Absolute Zeitereignistrigger wurden bei der Selektion zur Triggerausführung stets bevorzugt gegenüber Triggern mit periodischer Zeitereignisspezifikation. Nun erfolgt die Selektion von gleichzeitig aktivierten Zeitereignistriggern einzig anhand der Prioritäten und nicht mehr anhand des Triggertyps. 47

51 5 Allgemeine Erweiterungen und Modifikationen von ARTA II 4. Probleme gab es ebenfalls, wenn mehrere Zeitereignistrigger zur gleichen Zeit gefeuert wurden. Entweder wurden nicht alle Trigger bezüglich des Zeitereignisses ausgeführt oder es wurde kein neuer Timer gesetzt. Somit konnten weitere Zeitereignisse nicht erkannt werden. Diese Probleme wurde behoben. 5. Der Quellcode von ARTA II wurde ausführlich dokumentiert, um eine zukünftige Weiterentwicklung dieses Systems zu erleichtern. Vor sämtlichen Funktionen, die keine Ereignisprozeduren darstellen, gibt es eine kurze Beschreibung der Funktionsaufgabe. 5.1 Trigger-Steuerungskomponenten Die Trigger-Steuerungskomponenten wurden in dieser Arbeit bereits eingeführt. Diese Komponenten umfassen einerseits ein Prioritätenkonzept und andererseits den Aktivierungszustand eines Triggers, der dessen temporären Ausschluß von Triggerausführungen ermöglicht. Zusätzlich motivieren Zeitereignistrigger die Einführung der Steuerungskomponente Deadline. Das Gültigkeitsintervall gibt den Zeitraum an, in dem ein Trigger durch ein Ereignis aktiviert werden kann. In den folgenden Abschnitten sollen diese Komponenten detailliert beschrieben werden, wobei auf die Erweiterungen eingegangen wird, die bezüglich des ARTA II-Systems vorgenommen wurden Prioritäten Die Spezifikation von Prioritäten gibt die Ausführungsreihenfolge gleichzeitig aktivierter Trigger vor und vermeidet somit Konfliktsituationen, falls mehrere Trigger zur Ausführung selektiert werden können. Im Allgemeinen unterscheidet man drei Formen von Prioritäten: 1. Die (absoluten) Prioritäten ergeben sich implizit durch die Reihenfolge der Erstellung der Trigger. Der zuerst erstellte Trigger besitzt die höchste Priorität. 2. Durch relative Prioritäten wird für eine Menge von Triggern explizit definiert, in welcher Reihenfolge diese relativ zueinander ausgeführt werden sollen. 3. Bei der Angabe von nummerischen Prioritäten erfolgt dies durch explizite Zuweisung absoluter nummerischer Werte, wobei auch identische Werte an verschiedene Trigger vergeben werden können. Hierbei repräsentiert der niedrigste Wert die höchste Priorität. 48

52 5 Allgemeine Erweiterungen und Modifikationen von ARTA II Die absoluten Prioritäten finden im SQL-Kontext Anwendung, wobei ein Zeitstempel - TIMESTAMP - für jeden Trigger verwaltet wird, der den Zeitpunkt angibt zu dem der Trigger erstellt wurde. Dieser Zeitstempel gibt Auskunft über die Priorität des Triggers. Nach der Definition eines Triggers kann das Erstellungsdatum nicht mehr verändert werden. Dies bedeutet, dass das SQL-Prioritätenkonzept sehr starr bzw. unflexibel ist, da die Reihenfolge in der die Trigger ausgeführt werden sollen bereits nach ihrer Spezifizierung festgelegt ist und durch den Benutzer zu einem späteren Zeitpunkt nicht mehr modifiziert werden kann. Bei der relativen Prioritätenvergabe kann die Priorität eines Triggers relativ zu einem Referenztrigger spezifiziert werden. Hierbei kann (auch nach der Spezifizierung der Trigger) angegeben werden, ob der Trigger vor oder nach dem Referenztrigger ausgeführt werden soll. Ganz offensichtlich bietet dieses Konzept eine recht flexible und anwendungsfreundliche Möglichkeit in Bezug auf die Prioritätenvergabe sowie -modifizierung. Nach der Definition der Trigger können die Prioritäten beliebig zu jeder Zeit modifiziert werden. Der entscheidene Vorteil dieser Lösung liegt in einer lediglich partiellen Ordnung auf der Triggermenge. Für parallele Systeme oder für Systeme, die eine mengenorientierte Ausführung unterstützen, ist eine partielle Ordnung für die Effizienz der Abarbeitung der Regeln von Vorteil, da so mehrere Trigger gleichzeitig ausgeführt werden können. Für ein System wie ARTA II ergibt sich jedoch kein entscheidener Vorteil. Um eine Wohlordnung bezüglich der Triggerprioritäten zu erhalten, müssten zudem weitere systemdefinierte Kriterien angewandt werden. Im ARTA II-System wurde somit die Prioritätenvergabe mittels nummerischer Prioritäten realisiert. Hierbei wird jedem Trigger eine natürliche Zahl zugewiesen (vgl ). Um auf der Triggermenge eine Wohlordnung zu definieren, ist festgelegt, dass zwei unterschiedliche Trigger keine identischen Prioritäten besitzen dürfen. Bei der Spezifikation eines Triggers, wird dem Trigger automatisch vom System die maximale Priorität + 1 zugewiesen. Jedoch konnte zuvor keine Modifizierung der Triggerprioritäten durch den Anwender vorgenommen werden. Die Prioritätenvergabe erfolgte allein durch das System. Aus diesem Grund wurde das System ARTA II im Rahmen dieser Arbeit dahingehend erweitert, dass die Ausführungsreihenfolge der Trigger zu jeder Zeit durch den Anwender modifiziert werden kann. Abbildung 4.1 zeigt das Formular, das erstellt wurde, um dem Anwender eine möglichst intuitive Modifizierung der Prioritäten zu ermöglichen. Dem jeweils schwarz markierten Trigger kann eine neue Priorität zugewiesen werden. Für diesen Trigger muss zuvor der Triggereditor aufgerufen werden. Aus dem Editor heraus hat der Anwender dann Zugriff auf das Formular. Hierbei wird die neue Priorität aus der Menge von Prioritäten ausgewählt, die bereits an vorhandene Trigger vergeben wurden. Mit diesem Formular hat der Anwender eine Übersicht über die Ausführungsreihenfolge der Trigger und benötigt beim Setzen von Prioritäten für neue Trigger keine genaue Kenntnis über die Prioritäten vorhandener Trigger. Das Anpassen der Prioritäten nach dem Setzen einer neuen Priorität wird automatisch vom System übernommen. Auch nach dem Löschen eines Triggers werden die Prioritäten automatisch vom System angepasst. 49

53 5 Allgemeine Erweiterungen und Modifikationen von ARTA II Abbildung 5.1: Formular zum Setzen der Prioritäten Würde ebenfalls die implizite Ausführungsreihenfolge, die sich durch die Erstellungsreihenfolge der Trigger ergibt, bei einer relativen Prioritätenvergabe mit einbezogen, würde eine Wohlordnung auf der Triggerreihenfolge definiert sein. Auf diese Weise müssten keine weiteren Kriterien definiert werden. Dieser Ansatz hätte ebenfalls im Rahmen dieser Arbeit realisiert werden können. Jedoch wurde der Ansatz der nummerischen Prioritäten weiter verfolgt, da die Realisierung wesentlich leichter und mit weniger Aufwand gelingen konnte. Zum einen wurde für jeden Trigger bereits eine Priorität in Form einer natürlichen Zahl gespeichert und zum anderen hätte für die relative Prioritätenvergabe zusätzlich die Ausführungsreihenfolge der Trigger separat verwaltet werden müssen. Dies kann nun implizit in Form von natürlichen Zahlen erfolgen, die mit der Triggerspezifikation in der Datenbank gespeichert werden. Da die relativen und nummerischen Prioritäten weiterhin keine relevanten Unterschiede in der Prioritätenvergabe aufzeigen, wäre durch die Realisierung einer relativen Prioritätenvergabe kein entscheidener Vorteil für das ARTA II-System entstanden Deadline Die Ausführung eines aktivierten Zeitereignistriggers zu seinem intendierten Ausführungszeitpunkt kann sich gegebenenfalls verzögern, falls bereits andere Prozesse im System aktiv sind, wie beispielsweise die Ausführung einer Änderungsanweisung und der 50

54 5 Allgemeine Erweiterungen und Modifikationen von ARTA II durch sie ausgelösten Modifikationstrigger. In diesem Fall muss zunächst auf die Beendigung dieser Prozesse gewartet werden, bevor mit der Aktionsausführung begonnen werden kann, vgl Aus diesem Grund kann es sinnvoll sein eine Zeitperiode zu spezifizieren innerhalb derer es sinnvoll erscheint auch nach Verstreichen des intendierten Ausführungszeitpunktes die Triggeraktion auszuführen. Diese Zeitperiode wird mittels der Deadline definiert. Die Deadline ist bereits aus Echt-Zeit Datenbanken ( vgl: [AG92]) bekannt und definiert, in welchem Umfang der tatsächliche Ausführungszeitpunkt vom intendierten Ausführungszeitpunkt eines Zeitereignistriggers abweichen kann. Nach Ablauf dieser Deadline wird die Aktionsausführung des Triggers nicht mehr gestartet werden. Die Ausführung der Aktion sollte jedoch nicht unterbrochen, wenn die Ausführung der Triggeraktion während des Ablaufs der Deadline bereits erfolgt. Die Deadline ist ebenfalls im folgenden Fall sinnvoll: Zeitereignisse treten unabhängig vom Systemzustand ein und können demnach auftreten, wenn das System ausgeschaltet ist. Ist dies der Fall, wird die Verarbeitung von aufgetretenen Zeitereignissen solange verzögert, bis das System wieder eingeschaltet wird. Ob die Ausführung von aktivierten Triggern nach wie vor sinnvoll ist, kann durch entsprechende Deadlines bestimmt werden. Bislang war es in ARTA II lediglich möglich eine Deadline mit der Granularität Minute anzugeben. Dabei war die Angabe der Deadline auf einen Zeitraum von höchstens 3 Wochen beschränkt. Um einerseits eine längere Deadline zu erlauben und andererseits eine für den Benutzer intuitivere Spezifizierung der Deadline zu ermöglichen, ist es nach der Erweiterung des Systems möglich die Deadline mit der Zeiteinheit Minute, Stunde, Tag, Woche, Monat sowie Jahr anzugeben. Wenn das System für mehrere Wochen ausgeschaltet bleibt und für in diesem Zeitraum aufgetretene Zeitereitereignisse Trigger ausgeführt werden sollen, kann eine Deadline für diese Zeitereignistrigger leicht (ohne großen Aufwand) in Wochen oder Monaten spezifiziert werden. Hierbei muss zuvor keine Umrechnung der Deadline in Minuten erfolgen. Der Default-Wert der Deadline liegt weiterhin bei 5 Minuten. Die trigger deadline wird aus diesen Gründen syntaktisch folgendermaßen erweitert: <trigger deadline> ::= <interval specification> <interval specification> ::= <minutes interval> <hours interval> <days interval> <weeks interval> <months interval> 51

55 5 Allgemeine Erweiterungen und Modifikationen von ARTA II <years interval> <minutes interval> ::= <minutes> MINUTES <hours interval> ::= <hours> HOURS <days interval> ::= <days> DAYS <weeks interval> ::= <weeks> WEEKS <months interval> ::= <months> MONTHS <years interval> ::= <years> YEARS <minutes> ::= <hours> ::= <days> ::= <weeks> ::= <months> ::= <years> ::= Hierbei ist der minutes für die Spezifizierung der Deadline beschränkt auf 5. Ein weiteres Problem bei der die Deadline eine große Rolle spielt, ist die Vermeidung einer übermäßig wachsenden Anzahl von aktivierten Triggern, deren Aktion noch ausgeführt werden muss. Nach dem Einschalten des Systems ARTA II kann dieses System instabil werden, wenn zu viele Aktionen von Triggern ausgeführt werden müssen, deren Aktivierungszeitpunkte in dem Zeitraum lagen in dem das System ausgeschaltet war. Dieses Problem tritt auf, wenn die Zeitdifferenz zwischen dem intendierten und tatsächlichen Ausführungszeitpunkt eines Zeitereignistriggers mit periodischer Zeitereignisspezifikation entscheidend größer ist als die Zeitperiode, die durch die Zeitereignisspezifikation festgelegt wird. Allerdings kann ebenso die Interaktion von Zeitereignistriggern, die einen ähnlichen intendierten Ausführungszeitpunkt besitzen und deren Aktionsausführungen eine längere Zeit beanspruchen, zur Instabilität des Systems beitragen solange keine angemessenen Deadlines angewendet werden. Generell sollte für Zeitereignistrigger mit einer periodischen Zeitereignisspezifikation die Deadline so gewählt werden, dass seine Aktionsausführung immer vor dem Eintreten des nächsten intendierten Ausführungszeitpunktes liegt. Das Zeitintervall, das durch die Deadline spezifiziert wird, sollte demnach nicht länger sein als die Periode des periodischen Zeitereignistriggers. Das Konzept der Deadline ist ebenfalls für Modifikationstrigger sinnvoll. Mit ihr ist es möglich die Anzahl der rekursiv ausgelösten Modifikationstrigger zu beschränken. In ARTA II konnte bislang eine Deadline für Modifikationtrigger spezifiziert werden, jedoch 52

56 5 Allgemeine Erweiterungen und Modifikationen von ARTA II hatte diese keinen Einfluss auf die Ausführung des Triggers. Somit wurden Modifikationstrigger auch nach dem Ablauf ihrer Deadline ausgeführt. Diese beliebig verzögerte Ausführung der Modifikationstrigger ist nach der Erweiterung nicht mehr möglich. Ein Modifikationstrigger kann nicht mehr zur Ausführung selektiert werden, wenn der Zeitpunkt zu dem sein aktivierendes Ereignis eingetreten ist um mehr als die in der Deadline definierte Zeitperiode vom Ausführungszeitpunkt abweicht Aktivierungszustand Der Aktivierungszustand ist eine weitere Steuerungskomponente, die für beide Triggertypen spezifiziert werden kann. Diese Steuerungskomponente wurde im Rahmen der Diplomarbeit Entwurf und Implementierung einer Triggersprache mit Zeitereignissen für Access-Datenbanken ([Cali04]) für ARTA II-Trigger eingeführt. Der Aktivierungszustand erlaubt die temporäre Deaktivierung eines Triggers. Ein inaktiver Trigger kann zwar durch ein Ereignis aktiviert werden, jedoch wird er nicht zur Ausführung selektiert. Mittels des Triggerübersichts-Formulars kann der Anwender zu jeder Zeit einen Trigger aktivieren oder deaktivieren. Sollte ein Trigger für einen bestimmten Zeitraum nicht ausgeführt werden, muss dieser nicht gelöscht und später wieder neu spezifiziert werden, sondern kann einfach temporär deaktiviert werden. Somit wird die Verwaltung einer großen Triggermenge erheblich erleichtert. Wird ein Zeitereignistrigger, nach vorhergehender Deaktivierung, wieder aktiviert, stellt sich die Frage wie mit Zeitereignissen umgegangen werden soll, die in der Zeit der Deaktivierung des Triggers aufgetreten sind und den Trigger aktiviert hätten. Diese Zeitereignisse können entweder verworfen oder im nachhinein betrachtet werden. Da einerseits die Ausführung eines Zeitereignistriggers bezüglich eines Zeitereignisses erst vollständig verworfen wird, wenn die Deadline für diesen Trigger abgelaufen ist und andererseits die Überprüfung des Aktivierungszustand vor Überprüfung der Deadline erfolgt, sollen für diese Zeitereignisse rückwirkend Triggerausführungen gestartet werden. Wie genau diese verzögerte Verarbeitung von aufgetretenen Zeitereignissen erfolgt, wird in Abschnitt detailliert erläutert. Insbesondere kann hierbei in Zusammenhang mit der Modifizierung der Deadline die Verarbeitung eines Zeitereignisses für einen bestimmten Trigger erzwungen bzw. unterdrückt werden, in dem gleichzeitig mit Reaktivierung des Triggers die Deadline verlängert bzw. verkürzt wird. In ARTA II wurde bislang nach der erneuten Aktivierung eines Triggers keine Triggerausführung gestartet. Die in der Vergangenheit aufgetretenen Zeitereignisse wurden erst betrachtet, wenn entweder das System neu gestartet oder aufgrund eines abgelaufenen Timers die Verarbeitung von aufgetretenen Zeitereignissen angestoßen wurde. Im letzteren Fall wurden die bezüglich der Zeitereignisse aktivierten Trigger nicht in der chronologisch korrekten Reihenfolge ausgeführt. Zunächst erfolgte die Ausführung des Triggers bezüglich des Zeitereignisses zu dem der Timer gesetzt war. Erst anschließend kam es zur 53

57 5 Allgemeine Erweiterungen und Modifikationen von ARTA II Aktionsausführung des reaktivierten Triggers. In beiden Fällen konnte es zu einer Zeitverzögerung kommen, da erst eine Triggerausführung bei Neustart des Systems oder nach Ablauf eines Timers gestartet wurde. Infolge einer Zeitverzögerung konnten - aufgrund einer abgelaufenen Deadline - Aktionen nicht mehr durchgeführt werden, die direkt nach Aktivierung womöglich hätten ausgeführt werden können. Infolgedessen wurde das System in der Form erweitert, dass dieses System nach jeder erneuten Aktivierung eines Zeitereignistriggers nach aufgetretenen Zeitereignissen sucht. Falls noch nicht verarbeitete Zeitereignisse existieren, wird eine Triggerausführung gestartet. Anschließend wird ein neuer Timer gesetzt. Auf dieses Weise wird eine mögliche Zeitverzögerung der Triggerausführung und die chronologisch inkorrekte Ausführung von Zeitereignistriggern verhindert. Ein weiteres Problem entstand bei der Deaktivierung eines Triggers, für den der nächste Timer gesetzt war. Hierbei wurde nach Ablauf des Timers kein neuer Timer initialisiert, so dass weitere eintretene Zeitereignisse nicht erkannt werden konnten. Aus diesem Grund wird nach der Deaktivierung eines Zeitereignistriggers ebenfalls ein neuer Timer gesetzt. Auf diese Weise ist eine korrekte Ausführung von Zeitereignistriggern auch nach Deaktivierung eines Triggers gewährleistet. Modifikationstrigger werden dagegen im ARTA II-System nicht rückwirkend für aktivierende Ereignisse ausgeführt, da dieser Triggertyp immer mit der zum Ereignis gehörenden Datenmodifikation in einer ARTA-Transaktion ausgeführt werden muss. Ist die ARTA- Transaktion abgelaufen, kann der Trigger nicht mehr ausgeführt werden. Für BEFORE- Trigger scheitert dieses Konzept schon an der Tatsache, dass dieser Trigger nicht mehr vor Einbringung der Datenänderung in die Datenbank ausgeführt werden kann Gültigkeitsintervall Im Rahmen der Diplomarbeit Erweiterungskonzepte für das aktive Datenbanksystem ARTA ([Cali04]) wurden ARTA II-Trigger um ein Gültigkeitsintervall erweitert. Bei der Spezifizierung eines Triggers kann mit begin interval bzw. end interval der Beginn bzw. das Ende des Gültigkeitsintervalls angegeben werden. Während deaktivierte Trigger von Ereignissen aktiviert werden können, ist dies für Trigger mit einem abgelaufenen Gültigkeitsintervall nicht möglich. Insbesondere beschreibt das Gültigkeitsintervall für Zeitereignistrigger mit periodischer Zeitereignisspezifikation das Zeitintervall, in dem die intendierten Ausführungszeitpunkte liegen, die mittels der Zeitereignisspezifikation berechnet werden. Bisher wurde ein Teil der Zeitereignistrigger in ARTA II bei Ablauf des Gültigkeitsintervalls vom System gelöscht. Andere Zeitereignistrigger wiederum blieben in der Datenbank, auch nachdem deren Gültigkeitsintervall abgelaufen war. Dabei wurden diese Trigger nicht besonders gekennzeichnet, lediglich ein Ausführungszeitpunkt von 00:00:00 wies darauf hin. Auf diese Weise war es dem Benutzer nicht möglich auf einen Blick zu 54

58 5 Allgemeine Erweiterungen und Modifikationen von ARTA II unterscheiden, ob es sich um einen inkorrekt spezifizierten Trigger - diese Trigger erhielten ebenfalls 00:00:00 als Ausführungszeitpunkt - oder einen Trigger mit abgelaufenen Gültigkeitsintervall handelte. Modifikationstrigger existierten nicht nur im System ARTA II weiter, sondern konnten sogar weiterhin durch Datenänderungsanweisungen aktiviert werden. Diese Vorgehensweise erschwerte die Verwaltung von Triggern. Um eine einheitliche Bearbeitung der ARTA II-Trigger zu gewährleisten, werden nach der Erweiterung alle Trigger spätestens zum Ende ihres Gültigkeitsintervalls endgültig aus der Datenbank gelöscht und können somit auch nicht mehr durch Ereignisse aktiviert werden. Für absolute Zeitereignistrigger ist ein Gültigkeitsintervall nicht zwingend notwendig, da diese nur einmal aktiviert werden können. In ARTA II werden deren Spezifikationen demnach sofort nach ihrer Ausführung aus der Datenbank gelöscht. Nach dem Löschen eines Triggers erfolgt ein Eintrag in der Log-Datei. Es kann durchaus sinnvoll sein eine Triggerspezifikation mit abgelaufenen Gültigkeitsintervall in der Datenbank zu belassen. So könnten diese Spezifikationen als Vorlage für zukünftig zu spezifizierende Trigger dienen und somit die Definition von Triggern erleichtern. Mit Hilfe der Deaktivierung ist es jedoch auch möglich Triggerspezifikationen in der Datenbank zu speichern, ohne dass die Trigger zur Ausführung gebracht werden. Auf diese Weise können diese Spezifikationen ebenfalls als Vorlage für neu zu definierende Trigger dienen. Zu klären bleibt, wie mit Triggern umgegangen wird, deren aktivierendes Ereignis zwar innerhalb des Gültigkeitsintervalls aufgetreten ist, deren Ausführung jedoch - beispielsweise aufgrund von vorhergehenden aktiven Prozessen im System - über das Intervallende hinaus andauert oder sogar erst nach Intervallende beginnen kann. Das Gültigkeitsintervall gibt den Zeitraum an in dem Trigger durch ein Ereignis aktiviert werden können. Entscheidend ist demnach der Aktivierungszeitpunkt eines Triggers und nicht die Dauer seiner Ausführung. Kann ein Trigger erst nach Ablauf seines Gültigkeitsintervalls durch ein Ereignis aktiviert, sollte seine Ausführung nicht begonnen werden. 5.2 Zeitereignistrigger Nachdem Erweiterungskonzepte für alle Triggertypen in ARTA II vorgestellt wurden, soll es in diesem Abschnitt einzig um Erweiterungen für Zeitereignistrigger gehen. Im Zuge der Erweiterungen erhalten zum einen die Zeitereignistrigger so genannte Ereignisparameter DATE und TIME. Zum anderen wurden Änderungen bezüglich der verzögerten Verarbeitung von aufgetretenen Zeitereignissen von ARTA II vorgenommen. Ziel dieser Änderungen war die chronologisch korrekte Ausführung der aktivierten Trigger. 55

59 5 Allgemeine Erweiterungen und Modifikationen von ARTA II Abschließend wird neben der Vorstellung der Zeitperioden periodischer Zeitereignisspezifikation, auf Erweiterungen eingegangen, die für diese Zeitperioden vorgenommen wurden Ereignisparameter Ereignisparameter von Zeitereignistriggern bestehen aus den intendierten Ausführungszeitpunkten dieser Trigger. Bislang wurde auf die Realisierung von Ereignisparameter für Zeitereignistrigger im Rahmen des ARTA II verzichtet. Es wurde davon ausgegangen, dass einem Trigger zum Zeitpunkt seiner Ausführung stets das aktuelle Datum und die aktuelle Uhrzeit zur Verfügung stehen. Allerdings trifft es nicht immer zu, dass der tatsächliche Ausführungszeitpunkt mit dem intendierten Ausführungszeitpunkt des Triggers übereinstimmt. Dies ist der Fall, wenn z. B. nach dem Systemstart Zeitereignistrigger für in der Vergangenheit aufgetretene Zeitereignisse ausgeführt werden sollen. Aus diesem Grund erhalten Zeitereignistrigger mit absoluter sowie periodischer Zeitereignisspezifikation Ereignisparameter, die sich auf die intendierten Ausführungszeitpunkte der Trigger beziehen. Diese Ereignisparameter können im Bedingungs- und Aktionsteil eines Zeitereignistriggers referenziert werden. Hierbei besteht unter anderem die Möglichkeit dem Anwender Parameter für die Minuten, Stunden und auch für das Jahr, den Monat und den Tag des intendierten Ausführungszeitpunktes separat zur Verfügung zu stellen. Auf diese Weise könnten Berechnungen mit den einzelnen Parametern durchgeführt werden. Obwohl diese Art der Spezifizierung eine größere Flexibilität für den Anwender bedeuten würde, beschränken wir uns allein auf die Umsetzung zweier Parameter mit denen einerseits auf die Uhrzeit (TIME) mit der Genauigkeit Minute und andererseits auf das Datum (DATE) des intendierten Ausführungszeitpunktes eines Trigger zugegriffen werden kann. Andernfalls würde die Ereignisspezifikation zu komplex werden, wenn Parameter für jede einzelne Zeitangabe gespeichert werden müssten. Bei absoluten Zeitereignistriggern ist der Zeitpunkt zu dem das Ereignis eintritt bereits durch die Ereignisspezifikation des Triggers gegeben und somit die Referenzierung des intendierten Ausführungszeitpunktes unter Umständen nicht notwendig. Trotzdem können Variablen für die Ereignisparameter für weitere zeitbezogene Berechnungen in der Bedingung oder Aktion hilfreich sein. Für Trigger mit periodischer Zeitereignisspezifikation können die Ereignisparameter zur Unterscheidung der aktivierenden Zeitereignisse genutzt werden, für die die Bedingung evaluiert bzw. die Aktion ausgeführt wird. Für Trigger mit periodischer Zeitereignisspezifikation ist zusätzlich zu überlegen, welcher seiner intendierten Ausführungszeitpunkte mittels Ereignisparameter referenziert werden soll. Analog zu absoluten Zeitereignistriggern sollte der Zugriff auf dem jeweils aktuellen Ausführungszeitpunkt gewährleistet sein. Andere relevante Ereignisparameter wären alle bereits eingetretenen aber auch alle noch folgenden intendierten Ausführungszeitpunkte des Triggers. Es wäre überlegenswert dem Trigger den jeweils letzten und den aktuellen 56

60 5 Allgemeine Erweiterungen und Modifikationen von ARTA II Ausführungszeitpunkt zur Verfügung zu stellen. Auf diese Weise könnten die Zeitabstände zwischen den einzelnen intendierten Ausführungszeitpunkten berechnet werden. Zum Beispiel wäre es möglich heraus zufinden, ob wir uns in einem Schaltjahr befinden oder in einem Monat von 30 bzw. 31 Tagen, wenn eine Periode von einem Monat spezifiziert wurde. Abhängig davon könnte dann eine Ausführung zugelassen werden. Anderseits wäre es denkbar einem periodischen Zeitereignistrigger die Zeitdifferenz zwischen den intendierten Ausführungspunkten als Ereignisparameter direkt zur Verfügung zu stellen. Die zusätzliche Referenzierung von relevanten Ereignisparametern - neben dem intendierten Ausführungszeitpunkt - würde jedoch zu einer komplexeren Ereignisspezifikation führen. Außerdem sind die genannten Beispiele eher konstruiert und finden in der Praxis selten Anwendung. Daher wollen wir einzig die Referenzierung des jeweils aktuellen intendierten Ausführungszeitpunkt zulassen. Neben der Verfügbarkeit des einer Ausführung eines Zeitereignistriggers zugrunde liegenden intendierten Ausführungszeitpunktes ist auch der introspektive Zugriff auf die Schemadaten wie beispielweise Periode oder aktuelle Deadline des jeweiligen Triggers überlegenswert (vgl. [Dor04]). Allerdings wollen wir uns auf die wichtigsten Ereignisparameter beschränken und vernachlässigen auch diese Art der Referenzierungsmöglichkeit. Die Syntax der ARTA II-Zeitereignistrigger wird dementsprechend um die Ereignisparameter DATE und TIME erweitert: <time trigger specification> ::= <absolute time trigger event> <periodic time trigger specification> [ REFERENCING DATE AS <identifier> TIME AS <identifier> ] <time triggered action> Verzögerte Ereignisverarbeitung Zeitereignisse treten unabhängig vom Systemzustand auf. Das bedeutet Zeitereignisse können auftreten, wenn bereits andere Prozesse im System aktiv sind oder wenn das System ausgeschaltet ist. Diese bereits (in der Vergangenheit) aufgetretene Zeitereignisse werden in ARTA II mit der Prozedur processoldtimeevents() verarbeitet. Das System erkennt anhand der nächsten Ausführungszeitpunkte der aktuell in der Datenbank gespeicherten Triggerspezifikationen, ob Zeitereignisse existieren, die noch nicht verarbeitet worden sind. Innerhalb der Prozedur processoldtimeevents() wird nach Zeitereignistriggern gesucht, deren nächster Ausführungszeitpunkt in der Vergangenheit liegt. Lassen sich keine Zeitereignistrigger finden, kann die Prozedur processoldtimeevents() beendet 57

61 5 Allgemeine Erweiterungen und Modifikationen von ARTA II und sofort ein neuer Timer gesetzt werden. Andererseits werden diese Trigger nacheinander ausgeführt. Hierbei wird für jeden aktiven Trigger geprüft, ob dessen Deadline noch nicht abgelaufen ist. Ist dies der Fall wird der Trigger ausgeführt. Handelt es sich um einen Trigger mit periodischer Zeitereignisspezifikation wird dessen nächster Ausführungszeitpunkt berechnet. Anschließend erfolgt die Ausführung eines nächsten Triggers. Bislang wurde bei jedem Aufruf der Prozedur processoldtimeevents() ein Trigger nur jeweils einmal ausgeführt. Das heisst ein Trigger wurde nur bezüglich seines jeweils nächsten Ausführungszeitpunktes betrachtet. Unabhängig davon, ob der nach Ausführung neu berechnete Ausführungszeitpunkt in der Zukunft oder Vergangenheit lag. Gab es weitere noch nicht verarbeitete Zeitereignisse, wurde erneut die Prozedur processoldtimeevents() aufgerufen. Dieser Vorgang wurde solange wiederholt, bis alle Zeitereignistrigger einen in der Zukunft liegenden nächsten Ausführungszeitpunkt besaßen und ein neuer Timer gesetzt werden konnte. Nachteilig bei dieser Vorgehensweise ist, dass die Trigger nacheinander jeweils bezüglich ihres nächsten Ausführungszeitpunktes betrachtet werden, ohne auf die chronologische Reihenfolge ihrer intendierten Ausführungszeitpunkte zu achten. So werden zwar alle in der Vergangenheit aufgetretenen Zeitereignisse verarbeitet, jedoch ist die Ausführung der Trigger in chronologisch korrekter Reihenfolge nicht garantiert. Zum Beispiel kann es bei periodischen Zeitereignistriggern, deren Zeitperioden unterschiedliche Granularitäten besitzen, zu einer chronologisch inkorrekten Ausführung der Trigger kommen. Soll ein Trigger mit einer Zeitperiode von einer Minute und ein weiterer Trigger mit einer Zeitperiode von einer Woche ausgeführt werden, liegen die Ausführungen des Triggers mit der Zeitperiode einer Woche zeitlich vor den Ausführungen des anderen Triggers. Die Ursache liegt darin, dass in jeder Iterationsrunde die Zeitperiode einmal auf den intendierten Ausführungszeitpunkt der Trigger addiert wird und mit der Zeitperiode einer Woche schneller in der Zeit voran geschritten werden kann, als dies mit der Zeitperiode einer Minute der Fall ist. Wenn zusätzlich ein absoluter Zeitereignistrigger existiert, dessen intendierter Ausführungszeitpunkt in der näheren Vergangenheit liegt, wird dieser in der ersten Iterationsrunde ausgeführt. Hierbei können andere noch nicht verarbeitete Zeitereignisse existieren, die viel weiter in der Vergangenheit liegen. Eine chronologisch korrekte Ausführung ist nur möglich, wenn nur ein aktivierter Trigger existiert oder einzig periodische Zeitereignistrigger vorliegen würden, deren Zeitperioden eine identische Granularität besitzen. Aus diesem Grund wurde die Prozedur processoldtimeevents() zunächst in zweierlei Hinsicht erweitert. Zum einen gibt es nicht nur eine Iterationsrunde über die noch auszuführenden Trigger. Statt dessen werden diese Trigger solange betrachtet bis kein Trigger mehr existiert, der einen in der Vergangenheit liegenden intendierten Ausführungszeitpunkt besitzt. Zum anderen wird bei der Auswahl des jeweils nächsten auszuführenden Triggers die Bedingung gestellt, dass dieser Trigger den am weitesten in der Vergangenheit liegenden intendierten Ausführungszeitpunkt besitzt. Auf diese Weise ist eine chronologisch korrekte Ausführung der Zeitereignistrigger garantiert. 58

62 5 Allgemeine Erweiterungen und Modifikationen von ARTA II In Abschnitt wurde bereits erwähnt, dass es zur Instabilität von ARTA II nach dem Wiedereinschalten kommen kann. Dies ist der Fall, wenn eine übermäßig große Anzahl an aktivierten periodischen Zeitereignistriggern auszuführen ist, deren Deadline länger als die Periode des Triggers gewählt wurde. In ARTA II konnte es jedoch trotz einer angemessenen Deadline zur Instabilität bzw. sogar zum Absturz des Systems kommen. Um die Verarbeitung dieser Zeitereignisse nach dem Einschalten des Systems effizienter zu gestalten, wurde die Prozedur processoldtimeevents() nochmals erweitert. Für jeden periodischen Zeitereignistrigger wird - bevor dessen Ausführung erfolgt - derjenige nächste Ausführungszeitpunkt bestimmt, für den die Deadline des Triggers noch nicht abgelaufen ist. Auf diese Weise werden sehr viele Triggerausführungen verhindert, die nicht zu einer Aktionsausführung eines Triggers geführt hätten. Die Laufzeit kann somit meist wesentlich verbessert werden. Zu einer Systeminstabilität kann es allerdings weiterhin kommen, wenn zu viele Trigger - mit einer noch nicht abgelaufenen Deadline - bezüglich der in der Vergangenheit aufgetretenen Zeitereignisse auszuführen sind. So konnte zwar nicht die Ausführung von Triggern nach dem Systemstart an sich beschleunigt werden, jedoch können nun wesentlich mehr Trigger bezüglich aufgetretener Zeitereignisse betrachtet werden. Der Anwender muss hierbei lediglich darauf achten, dass die erwähnte zeitliche Beziehung zwischen Deadline und Periode eines periodischen Zeitereignistriggers angemessen gewählt wird. Die Prozedur processoldtimeevents() wird nach dem Wiedereinschalten des Systems, nach Reaktivierung eines Zeitereignistriggers sowie nach Ausführung einer Änderungsanweisung aufgerufen. Jedoch erfolgt nach der Erstellung oder Modifizierung eines Zeitereignistriggers kein Aufruf dieser Prozedur. Absolute Zeitereignistrigger müssen immer vor ihrem aktivierenden Zeitereignis erstellt werden. Ausführungszeitpunkte eines periodischen Zeitereignistriggers werden nicht betrachtet, wenn sie zwischen dem Beginn des Gütigkeitsintervalls und dem Zeitpunkt der Spezifizierung liegen. Somit können keine Trigger rückwirkend für in der Vergangenheit eingetretene Zeitereignisse erstellt werden. Weiterhin kann eine Verlängerung der Deadline dazu führen, dass Trigger ausgeführt werden können, deren Ausführung bereits wegen einer abgelaufenen Deadline abgebrochen wurde. Allerdings hatten wir in gesagt, dass ein Zeitereignis bezüglich eines Triggers verworfen wird, wenn die Deadline des Triggers abgelaufen ist. Somit kann ein solcher Trigger auch später nicht mehr zur Ausführung selektiert werden. Nach Modifizierung einer Deadline erfolgt demnach kein Aufruf der Prozedur processoldtimeevents() Zeitperioden In diesem Abschnitt werden die Erweiterungen zu variablen Perioden periodischer Zeitereignisspezifikationen beschrieben, die im Rahmen dieser Arbeit vorgenommen wurden. Hierbei soll die Berechnung des jeweils nächsten Ausführungszeitpunktes betrachtet werden und die verschiedenen Probleme aufgezeigt werden, die sich bezüglich der Addition eines Ausführungszeitpunktes mit der innerhalb der Periodenspezifikation Monat 59

63 5 Allgemeine Erweiterungen und Modifikationen von ARTA II und Jahr definierten Zeitperiode ergeben haben. Außerdem werden in Bezug auf diese Probleme verschiedene Lösungswege diskutiert. Die Periodenspezifikationen Monat und Jahr wurden bereits in Abschnitt vorgestellt. Bezüglich dieser Perioden bestanden Einschränkungen. Zwar konnten die Perioden bereits bequem mit Hilfe des Triggereditors spezifiziert werden, jedoch wurden teilweise die intendierten Ausführungszeitpunkte nicht oder nur inkorrekt berechnet. Die Syntax der Periodenspezifikationen wird hier nochmals präsentiert, um die Probleme der Berechnungen des jeweils nächsten Ausführungszeitpunktes verdeutlichen zu können. EVERY <digit months> MONTHS ON EVERY <day of week> AT <time value> Mit der ersten Möglichkeit der Periodenspezifikation Monat konnten Zeitperioden, wie zum Beispiel Jeden 2. Monat jeden Montag um 9:00 Uhr definiert werden. Bei der Berechnung des ersten Ausführungszeitpunktes wird der erste für day of week angegebene Wochentag bestimmt, der innerhalb des Gültigkeitsintervalls liegt. Um weitere Ausführungszeitpunkte zu berechnen, wird zunächst immer eine Woche auf den letzten Ausführungszeitpunkt addiert. Sollte der nächste Ausführungszeitpunkt im folgenden Monat liegen, wird die in digit months angegebene Anzahl an Monaten auf den letzten Ausführungszeitpunkt addiert und wieder der erste für day of week angegebene Wochentag im aktuellen Monat bestimmt. Ausnahmslos jeder intendierte Ausführungszeitpunkt muss die Eigenschaften erfüllen, die durch die Periodenspezifikation gegeben sind, und innerhalb des Gültigkeitsintervalls liegen. Bei dieser Periodenspezifikation gab es zuvor das Problem, dass der erste Ausführungszeitpunkt zwar korrekt bestimmt jedoch die Berechnung des jeweils nächsten Ausführungszeitpunktes nicht korrekt durchgeführt wurde. Es wurde lediglich die für digit months definierte Zahl auf den letzten Ausführungszeitpunkt addiert, ohne dabei den für day of week angegebenen Wochentag zu berücksichtigen. Dieser Fehler wurde behoben. Die Berechnung erfolgt jetzt in der für diese Periodenspezifikation beschriebenen Weise. Im Gegensatz zu festen Perioden ist es bei variablen Perioden möglich, dass kein mittels der Periodenspezifikation berechneter Zeitpunkt die Eigenschaft erfüllt innerhalb des Gültigkeitsintervalls zu liegen. Aus diesem Grund wurde das System dahingehend erweitet, dass nach Spezifzierung eines periodischen Zeitereignistriggers geprüft wird, ob der nächste Ausführungszeitpunkt des Triggers im Gültigkeitsintervall liegt. Ist dies nicht der Fall wird eine Warnung ausgegeben. Der Anwender bekommt auf diese Weise die Möglichkeit entweder das Gültigkeitsintervall zu verlängern oder die Granularität der Periode anzupassen, so dass der Ausführungszeitpunkt im Gültigkeitsintervall liegt und die Triggerspezifikation in der Datenbank gespeichert werden kann. Damit wird verhindert, dass periodische Zeitereignistrigger in ARTA II existieren können, die keinen gültigen nächsten Ausführungszeitpunkt besitzen. 60

64 5 Allgemeine Erweiterungen und Modifikationen von ARTA II EVERY <digit months> MONTHS ON <ordined> <day of week> AT <time value> Ein Beispiel für die zweite Möglichkeit der Periodenspezifikation Monat ist Jeden 2. Monat an jedem 3. Montag um 9:00 Uhr. Hierbei kann für ordined eine Zahl angegeben werden, so dass entweder der 1., 2., 3., 4., oder 5. Montag gewählt werden kann. Ein Problem tritt auf, wenn der Trigger jeden 5. Montag ausgeführt werden soll, da nicht jeder Monat einen 5. Montag enthält. In diesem Fall läßt das System bei der Berechnung diesen Monat wegfallen, addiert die für digit months definierte Zahl auf den aktuellen Monat und gibt als nächsten Ausführungszeitpunkt den 5. Montag des resultierenden Monats zurück. Denkbar wäre gleich im anschließenden Monat nach einem 5. Montag zu suchen oder jeweils den 4. Montag des Monats zu wählen, falls es keinen 5. Montag gibt. Beide Alternativen scheinen jedoch weniger der intendierten Bedeutung dieser Periodenspezifikation zu entsprechen. Erweiterungen mußten vorgenommen werden, da zum einen der erste Ausführungszeitpunkt nur teilweise korrekt bestimmt wurde. Zum anderen verlief die Berechnung des jeweils nächsten Ausführungszeitpunktes nicht korrekt. Sollte beispielsweise an jedem 5. Montag ein Trigger aktiviert werden, wurde der 1. Montag im Folgemonat oder der 4. Montag im aktuellen Monat als nächster Ausführungszeitpunkt berechnet, falls es keinen 5. Montag im Monat gab. Diese unterschiedliche Berechnung der Ausführungszeitpunkte entspricht ganz offensichtlich keiner konsequenten Vorgehensweise. EVERY <digit months> MONTHS ON <ordined digit day> DAY AT <time value> Für die dritte und letzte Möglichkeit der Periodenspezifikation Monat konnten bislang keine Trigger in ARTA II spezifiziert werden. Mit ihr können Formulierungen wie Jeden 2. Monat am 15. Tag um 9:00 Uhr dargestellt werden. Für ordined digit day wird der Tag im Monat angegeben, zudem der Trigger aktiviert werden soll. Für ordined digit day können die Werte 1 bis 31 spezifiziert werden. Hierbei kann der nächste zu berechnende Ausführungszeitpunkt ein ungültiges Datum darstellen. Soll ein Trigger jeden Monat am 31. aktiviert werden, geht dies beispielsweise für den 31. Oktober 2005 noch gut. Für den nächsten Monat erhält man jedoch das ungültige Datum 31. November (SQL vermeidet diese Probleme, indem es zwei voneinander getrennte Klassen von Intervallen verwendet: year-month-intervalle und day-time-intervalle. Year-Month-Intervalle dürfen ausschließlich aus Jahren sowie Monaten bestehten und letzere umfassen Tage, Stunden, Minuten und Sekunden. Die Addition eines Zeitpunktes und eines Intervalls ist hier auch möglich, allerdings führt eine Addition von einem Monat zum 31. Oktober 61

65 5 Allgemeine Erweiterungen und Modifikationen von ARTA II 2005 zu einer invalid date exception. Die Einschränkung periodischer Zeitereignistypen auf genau eine der SQL-Intervallklassen würde zu einer wenig komfortablen und recht unnatürlichen Spezifikation der Perioden führen. Aus diesem Grund werden die genannten Intervalle für ARTA II nicht verwendet.) Durch das ARTA II-System wird in diesen Fällen das ungültige Datum automatisch auf den letzten gültigen Tag des jeweiligen Monats abgerundet. In unserem Beispiel würde demnach der 30. November 2005 als nächster intendierter Ausführungszeitpunkt berechnet werden. Ebenso denkbar wäre es aus der variablen Periode eine feste Periode zu machen und stets 31 Tage zu addieren, um den nächsten intendierten Ausführungszeitpunkt zu erhalten. Betrachten wir diesbezüglich allerdings den allgemeinen Sprachgebrauch, wird deutlich, dass dieser von der Anzahl der Tage bei der Zeitangabe in einem Monat abstrahiert. So lässt sich beispielsweise am 19. eines Monats sagen in einem Monat, womit schlicht der 19. des Folgemonats gemeint ist, unabhängig davon, wieviel Tage der laufende Monat hat (vgl. [Dor04]). Beispielsweise würde mit der Formulierung in vier Monaten am 19. September 2005 nicht der in 4 31 Tagen gelegene 21. Dezember gemeint sein, sondern der 19. Dezember Aus diesem Grund sprechen wir bei der Formulierung in einem Monat am 31.Oktober 2005 wohl eher vom 30. November 2005 als vom 1. Dezember Eine andere Vorgehensweise könnte darin bestehen die Monate wegfallen zu lassen, die nicht aus 31 Tagen bestehen. Auch die Einbeziehung der Deadline in die Berechnung des jeweils nächsten intendierten Ausführungszeitpunktes wäre denkbar. Hierbei könnten wir die Ausführung am 1. des Folgemonats erlauben, wenn eine genügend lange Deadline - länger als ein Tag - vorliegt oder andererseits den Ausführungszeitpunkt in diesem Monat ausfallen lassen. Um die Berechnung nicht zu komplex werden zu lassen, wird jedoch eine Einbeziehung der Deadline nicht in Betracht gezogen und die Berechnung in der beschriebenen Weise durchgeführt. Zudem kann in diesem Fall die Periodenspezifikation Jeden Monat am 31. Tag als semantisch äquivalent zu der oft gebräuchlichen und im ARTA II-System fehlenden Formulierung am Ende jeden Monats verwendet werden. Ebenso existierten Einschränkungen bezüglich der Periodenspezifikation Jahr. Auch hier soll die Syntax für eine bessere Verdeutlichung der aufgetretenen Probleme wiederholt werden. EVERY <digit years> YEARS ON <ordined digit day> <month> AT <time value> Die erste von zwei Möglichkeiten bezüglich der Periodenspezifikation Jahr erlaubt Formulierungen wie Jedes 2. Jahr am 14. September um 9:00 Uhr. Ordined digit day gibt den Tag im Monat an zu dem der Trigger ausgeführt werden soll. Hierbei sind - nach vorhergehender Erweiterung - die Werte von 1 bis 31 zulässig. Zuvor konnte ein Trigger nicht 62

66 5 Allgemeine Erweiterungen und Modifikationen von ARTA II am 31. eines Monats aktiviert werden. Bei dieser Art der Spezifikation besteht ebenfalls die Gefahr der Berechnung eines ungültiges Datums. Dieses ungültige Datum kann durch den Anwender bei der Spezifizierung der Periode ausgewählt werden, wie beispielsweise der 31. September. Sollte dies geschehen, erfolgt durch das System eine Meldung. Diese Meldung teilt dem Anwender mit, dass der entsprechende Monat nur aus 30 Tagen besteht und ändert die Periodenspezifikation automatisch auf den letzten Tag des jeweiligen Monats. Gibt der Benutzer also beispielsweise den 31. September an, erscheint eine Meldung, die dem Benutzer mitteilt, dass der September ausschließlich aus 30 Tagen besteht und die Triggerspezifikation wird automatisch auf den 30. September gesetzt. Auf diese Weise wird die Spezifizierung ungültiger Datumsangaben für diese Periodenspezifikation verhindert. EVERY <digit years> YEARS ON <ordined> <day of week> IN <month> AT <time value> Die letzte Periodenspezifikation Jahr konnte zwar mit Hilfe des Triggereditors spezifiziert werden, allerdings wurden die intendierten Ausführungszeitpunkte nicht berechnet. Zum Beispiel unterstützt diese Spezifikation Perioden der Form Jedes 2. Jahr am 3. Montag im Januar um 9:00 Uhr. Nach Erweiterung kann ein Trigger auch mit dieser Periodenspezifikation definiert werden, wobei der erste und ebenso alle folgenden intendierten Ausführungszeitpunkte des Triggers korrekt berechnet werden. Soll ein intendierter Ausführungszeitpunkt an jedem 5. Montag im Januar stattfinden, entfällt dieser Ausführungszeitpunkt, wenn der Monat Januar keinen 5. Montag enthält. Hierbei wird entsprechend der Diskussion zur zweiten Möglichkeit der Periodenspezifikation Monat vorgegangen. 63

67 6 Entwurf von relativen Zeitereignisspezifikationen Dieses Kapitel präsentiert eine Erweiterung der ARTA II-Trigger um relative Zeitereignisspezifikationen. Während des Entwurfs der Trigger mit einer relativen Zeitereignisspezifikation wurde darauf geachtet eine möglichst orthogonale Erweiterung des bestehenden Konzepts der ARTA II-Trigger zu erhalten. Es wurden Entscheidungen berücksichtigt, die bezüglich der ARTA II-Trigger bereits getroffen worden sind. Dies bedeutet u. a., dass die in dieser Arbeit vorgestellten Konzepte der Steuerungskomponenten und Ereignisparameter für relative Zeitereignistrigger übernommen wurden. Zunächst wird in der Anforderungsanalyse in Abschnitt 6.1 betrachtet, welche Formen der relativen Zeitereignisspezifikationen für das aktive Datenbankmanagementsystem ARTA II im Rahmen dieser Arbeit umgesetzt werden sollen bzw. können. Nach der Anforderungsanalyse werden in 6.2 verschiedene Realisierungsmöglichkeiten von Ereignisparameter für relative Zeitereignistrigger vorgestellt, wobei darauf folgend eine Syntax sowie Semantik bezüglich des neuen Triggertyps definiert wird. 6.1 Anforderungsanalyse Eine relative Zeitereignisspezifikation beschreibt ein Zeitereignis oder eine Menge von Zeitereignissen, die mit Hilfe eines temporalen Offsets bezüglich des Auftretens eines anderen Ereignisses spezifiziert werden. In Abschnitt wurde erwähnt, dass ein temporaler Offset relativ zu Modifikationsereignissen, Transaktionsereignissen sowie externen Ereignissen gesetzt werden kann. Ebenso kann mit Hilfe eines temporalen Offsets in Bezug auf ein Zeitereignis ein neues Zeitereignis oder eine Menge von Zeitereignissen berechnet werden, wie zum Beispiel 3 Wochen nach dem 9. November :00 Uhr. Diese letzte Form der relativen Zeitereignisspezifikation soll vernachlässigt werden. Die Erweiterung konzentriert sich ausschließlich auf die relativen Zeitereignisspezifikationen, die einen Zeitpunkt oder eine Menge von Zeitpunkten relativ zu einem Ereignis eines anderen Ereignistyps bzw. einer anderen Ereignisklasse (z.b. Datenbank- oder externes Ereignis) beschreiben. Sollen Trigger von Zeitereignissen aktiviert werden, die relativ zu anderen Zeitereignissen definiert werden, können diese Trigger vom Anwender selbst spezifiziert werden. Möchte 64

68 6 Entwurf von relativen Zeitereignisspezifikationen der Anwender einen Trigger 3 Wochen nach dem 9. November :00 Uhr vom System ausführen lassen, kann dieser Zeitpunkt vom Anwender selbst berechnet und für diesen Zeitpunkt ein absoluter Zeitereignistrigger spezifiziert werden. Da Zeitereignisse vorhersehbar sind, ist diese Spezifizierung eines Triggers vor dem Zeitereignis stets möglich. In ARTA II können nur Modifikationssereignisse und Zeitereignisse beobachtet werden. Es besteht keine Möglichkeit Zeitpunkte relativ zu externen Ereignissen oder Transaktionsereignissen zu setzen. Aus diesem Grund konzentrieren wir uns auf die Spezifikation von Zeitereignissen relativ zu Modifikationssereignissen, die entweder im SQL-Terminal eingegeben werden oder innerhalb einer Triggeraktion auftreten. Solche Ereignisse können mit einem time offset entweder zu einer absolut relativen Zeitereignisspezifikation, wie etwa 3 Wochen nach einer Einfügung in Tabelle A oder zu einer periodisch relativen Zeitereignisspezifikation, wie zum Beispiel 15 Minuten nach einer Löschung in Tabelle A und dann jeden Monat, in Beziehung gesetzt werde (vgl ). Zur Vereinfachung wird angenommen, dass ein time offset für eine einfache Zeitperiode steht, wie 3 Monate oder 2 Stunden. Spezifikationen wie 3 Wochen vor einer Einfügung in die Tabelle A sollen vernachlässigt werden. Modifikationsereignisse sind im Gegensatz zu Zeitereignissen unvorhersehbar. Aus diesem Grund kann das System keine (Re-) Aktion starten, die 3 Wochen vor einem unvorhersehbaren Ereignis stattfindet. Selbst wenn die Möglichkeit bestände eine (Re-) Aktion vor einem Modifikationsereignis (Aufruf einer Änderungsoperation) zu starten, kann es passieren, dass die Transaktion zurückgesetzt werden muss, innerhalb derer die zugehörige Änderungsoperation ausgeführt wird. Somit wäre eine (Re-) Aktion auf ein Modifikationsereignis ausgelöst worden, dessen zugehörige Datenoperation nicht in die Datenbank eingebracht wurde. Der Nutzen von relativen Zeitereignisspezifikationen ist offensichtlich. Verwendung für diese Form der Zeitereignisspezifikation könnte beispielsweise eine Bibliothek haben, deren Datenbank unter anderem eine Tabelle mit denjenigen Personen enthält, die mit der Rückgabe von Büchern im Rückstand sind. Für eine Einfügung in diese Tabelle kann mittels relativer Zeitereignisspezifikationen die automatische Versendung einer einmaligen (absoluten) oder regelmäßigen (periodischen) Erinnerungsmail realisiert werden. Ein weiteres Beispiel ist die Versendung von Erinnerungsmails nach dem sich Studenten für ihre Diplomarbeit angemeldet haben. Diese Mails könnten Auskunft über die verbleibende Zeit bis zum Abgabetermin in 6 Monaten geben. Hierbei ist ein entscheidener Aspekt zu berücksichtigen. Für die Sekretärin besteht nicht immer die Möglichkeit am Tag der Anmeldung die entsprechenden Daten in die Datenbank einzugeben. Die Anmeldungsdaten können oft erst Tage später in die Datenbank eingebracht werden, weil andere Arbeiten vorrangig erledigt werden müssen oder die Sekretärin sich im Urlaub befindet. Hätten wir einen Trigger definiert, der 5 Monate und 3 Wochen nachdem der Diplomand seine Arbeit abgeben muss, eine Erinnerungsmail an diesen Diplomanden schickt, kommt 65

69 6 Entwurf von relativen Zeitereignisspezifikationen diese Mail zu spät, wenn die Sekretärin die Diplomanmeldungsdaten mehr als eine Woche später in die Datenbank eingebracht hat. Auch das Aufaddieren einer bestimmten Anzahl von Tagen zum time offset führt zu keiner praktikablen Lösung. Die Sekretärin hätte zwar die Möglichkeit die Daten ein paar Tage später in die Datenbank einzubringen und auf diese Weise das Eingeben der Daten zu planen. Jedoch würde wieder ein ähnliches Problem entstehen. Die Sekretärin könnte sich zu diesem Zeitpunkt im Urlaub befinden oder dieses Datum könnte genau auf ein Wochenende fallen, wenn das System ausgeschaltet ist. Die Sekretärin müsste demnach auch am Wochenende arbeiten sowie ihren Urlaub nach diesen Terminen planen. Diese daraus resultierenden Anforderungen an einen Anwender sind in der Praxis nicht umsetzbar. Diese Betrachtung motiviert eine weitere Spezifikationsmöglichkeit, die wir für relative Zeitereignisspezifikationen realisieren wollen. Der Anwender soll die Möglichkeit haben nicht nur ein oder eine Menge von Zeitereignissen relativ zum Zeitpunkt des Eintretens eines Änderungsereignisses setzen zu können, sondern ebenfalls relativ zu einem Zeitpunkt, der durch die Ereignisparameter des Modifikationsereignisses gegeben ist. Für unser Beispiel bedeutet dies, dass ein Trigger aktivierendes Zeitereignis relativ zum Diplomanmeldungsdatum spezifiziert werden kann, das mit der Diplomanmeldung in die Datenbank eingefügt wurde. Die relative Zeitereignisspezifikation ist somit unabhängig von dem Zeitpunkt zu dem die Anmeldungsdaten in die Datenbank eingebracht werden. Folglich können beispielsweise Erinnerungsmails bezüglich einer Diplomarbeitsanmeldung immer zu einem gewünschten bzw. bestimmten Datum versendet werden. Eine relative Zeitereignisspezifikation bezieht sich somit im Rahmen des ARTA II-Systems immer auf ein Zeitereignis oder einer Menge von Zeitereignissen und auf ein Modifikationsereignis. Infolgedessen sollten Ereignisparameter bezüglich beider Ereignistypen Teil der Ereignisspezifikation eines Triggers sein. Die Ereignisparameter des Modifikationsereignisses werden benötigt, um bei Ausführung des Triggers überprüfen zu können, ob die durch das Modifikationsereignis vorgenommenen Änderungen noch in der Datenbank enthalten sind. Der Zugriff auf die Ereignisparameter des Zeitereignisses ist anders als bei absoluten Zeitereignisspezifikationen erforderlich. Das Zeitereignis wird nicht allein durch die Ereignisspezifikation bestimmt, sondern hängt ebenfalls von dem Zeitpunkt ab, zu dem das Modifikationsereignis eintritt. 6.2 Trigger mit einer relativen Zeitereignisspezifikation Nachdem wir uns in der Anforderungsanalyse auf die relativen Zeitereignisspezifikationen festgelegt haben, die im Rahmen von ARTA II umgesetzt werden, sollen in diesem Abschnitt die verschiedenen Möglichkeiten einer Umsetzung diskutiert werden. Insbesondere wird auf die verschiedenen Alternativen der Ereignisparameter für diesen neuen 66

70 6 Entwurf von relativen Zeitereignisspezifikationen Triggertypen eingegangen. Anschließend erfolgt die Vorstellung der Syntax in Abschnitt und der Semantik in Abschnitt Aus Abschnitt ist bekannt, dass es nach unserer Sichtweise kein einzelnes relatives Ereignis, sondern zwei Ereignisse gibt, die zueinander in Beziehung gesetzt werden. Eine relative Zeitereignisspezifikation beschreibt ein Zeitereignis oder eine Menge von Zeitereignissen, die abhängig vom Eintrittszeitpunkt des Modifikationsereignisses spezifiziert werden. Wird dieser Sichtweise gefolgt, kann ein relativer Zeitereignistrigger auf zwei verkappte Trigger reduziert werden, nämlich einem AFTER-Modifikations- sowie einem Zeitereignistrigger. Im ARTA II-System könnte der neue Triggertyp realisiert werden, indem innerhalb der Aktion eines AFTER-Modifikationstriggers die Spezifizierung eines Zeitereignistriggers unterstützt wird. Im Falle der Aktivierung eines solchen Modifikationstriggers generiert das System einen oder mehrere Zeitereignistrigger. Auf diese Weise ergibt sich mit einer Spezifikation eines absoluten Zeitereignistriggers innerhalb der Aktion eines AFTER- Modifikationstriggers ein Trigger mit einer absolut relativen Zeitereignisspezifikation und mit einer Spezifikation eines periodischen Zeitereignistriggers ein Trigger mit einer periodisch relativen Zeitereignisspezifikation. Auf diese Weise würden solche AFTER-Trigger zusammen mit allen anderen AFTER- Triggern im System ausgeführt werden. In diesem Fall könnte ein abgeleiteter Zeitereignistrigger generiert werden, obwohl eine Transaktion aufgrund eines Fehlers zurückgesetzt wird. Dies passiert, wenn nach der Generierung eines Zeitereignistriggers ein AFTER-Trigger ausgeführt wird, der einen Fehler verursacht. Mit Hilfe der Prioritäten könnte erreicht werden, dass die Ausführung dieser AFTER-Trigger immer nach der Ausführung aller anderen AFTER-Trigger stattfindet. Vom Anwender müßte dann kontrolliert werden, dass diese AFTER-Trigger immer die niedrigsten Prioritäten besitzen. Das würde einen erheblichen Aufwand für den Anwender bedeuten. Ein weiteres Argument, das gegen die Realisierung eines relativen Zeitereignistriggers durch Reduktion auf einen AFTER-Modifikationstrigger und einen Zeitereignistrigger spricht, ist die dauerhafte Speicherung von jeweils zwei Triggerspezifikationen für diesen neuen Triggertyp in ARTA II. Der Speicherplatzbedarf eines Triggers mit einer relativen Zeitereignisspezifikation wäre im Vergleich zu anderen Triggertypen in ARTA II demnach doppelt so hoch. Beispielsweise ist jedoch die Spezifikation einer Deadline für einen AFTER-Modifikationstrigger mit einer CREATE TRIGGER-Anweisung innerhalb seiner Aktion nicht notwendig. Die Generierung eines abgeleiteten Zeitereignistriggers stellt keine zeitkritische Aktion. Zudem hängt die Entscheidung, ob die Generierung eines abgeleiteten Zeitereignistriggers noch sinnvoll ist, vom berechneten Zeitereignis und von der Deadline bzw. von dem Gültigkeitsintervall des abgeleiteten Zeitereignistriggers ab. Eine weitere Bedingung in Form einer Deadline des AFTER-Modifikationstriggers für die Generierung ist nicht erforderlich. 67

71 6 Entwurf von relativen Zeitereignisspezifikationen Des weiteren werden Schema-Änderungen vom SQL-Standard im Aktionsteil eines Triggers nicht verbindlich spezifiziert, da diese Schema-Änderungen sich als semantisch problematisch erwiesen haben. Aufgrund der zuvor genannten Gründe verzichten wir auf diese Form der Reduktion. Diese Sichtweise soll jedoch für die Realisierung der relativen Zeitereignistrigger genutzt werden. Die ARTA II-Trigger werden um zwei neue Triggertypen erweitert, nämlich um Trigger mit einer absolut relativen Zeitereignisspezifikation und Trigger mit einer periodisch relativen Zeitereignisspezifikation. Tritt ein in einem relativen Zeitereignistrigger spezifiziertes Modifikationsereignis auf, generiert das System einen absoluten bzw. periodischen Zeitereignistrigger - je nachdem, ob es sich um einen Trigger mit einer absolut relativen oder periodisch relativen Zeitereignisspezifikation handelt. Dabei leitet sich die Spezifikation dieses absoluten oder periodischen Zeitereignistriggers aus der Spezifikation des relativen Zeitereignistriggers ab Ereignisparameter Die Anforderungsanalyse hat ergeben, dass sich relative Zeitereignisspezifikationen in ARTA II immer genau auf ein Modifikationsereignis und ein oder eine Menge assoziierter Zeitereignisse beziehen. Folglich sollten Ereignisparameter beider Ereignistypen für diesen neuen Triggertyp unterstützt werden. Aufgrund einer möglichst orthogonalen Erweiterung der ARTA II-Trigger sollen Ereignisparameter des Modifikationsereignisses im gleichen Maße für die relativen Zeitereignistrigger zur Verfügung stehen, wie dies für die ARTA II-Modifkationstrigger der Fall ist. Dies bedeutet, dass die neuen Triggertypen mittels Transitionsvariablen Zugriff auf die durch das Modifikationsereignis betroffenen neuen und alten Zeilen- und Tabellenwerte der Tabelle besitzen. Die Ereignisparameter können im Bedingungs- und Aktionsteil des Triggers referenziert werden, wie dies für Modifikationstrigger bereits beschrieben wurde. Hierbei stellt sich die Frage, wie dem abgeleiteten Zeitereignistrigger, der nach dem Eintreten des Modifikationsereignisses generiert wird, die Ereignisparameter des Modifikationsereignisses zur Verfügung gestellt werden. Eine mögliche Vorgehensweise könnte darin bestehen Tabellen bis zur Ausführung der abgeleiteten Zeitereignistrigger zu speichern, die die Ereignisparameter des Modifikationsereignisses beinhaltet. Dabei wäre es möglich die Transitionstabellen des TEC (vgl. 3.3) zu speichern, so dass die abgeleiteten Zeitereignistrigger bei ihrer Ausführung Zugriff auf ihre Ereignisparameter haben. Diese Ereignisparameter können im Bedingungsund Aktionsteil des Triggers mittels Variablen referenziert werden (analog zu den Modifikationstriggern). Kurz vor Ausführung würden die Variablen durch ihre Werte ersetzt. Da die Ereignisparameter des abgeleiteten Zeitereignistriggers in diesem Fall nicht nur aus dem intendierten Ausführungszeitpunkt bestehen, sondern ebenso aus den Ereignisparametern des Modifikationsereignisses, könnte eine Ausführungsgranularität bezüglich 68

72 6 Entwurf von relativen Zeitereignisspezifikationen dieses Triggers spezifiziert werden. Das bedeutet, der Trigger wird entweder nur einmal ( FOR EACH STATEMENT ) oder für jede Zeile der gespeicherten Transitionstabelle ( FOR EACH ROW ) ausgeführt. Bei dieser beschriebenen Vorgehensweise wird nach dem Auftreten eines in einem relativen Zeitereignistrigger definierten Modifikationsereignisses jeweils nur ein abgeleiteter Zeitereignistrigger mit einem intendierten Ausführungszeitpunkt generiert. Probleme treten auf, wenn das Zeitereignis relativ zu einem Zeitpunkt bestimmt werden soll, der durch die Ereignisparameter gegeben ist. Sind mehrere Zeilen durch das Modifikationsereignis betroffen, kann es mehrere unterschiedliche Zeitpunkte geben. Hierbei ist es sinnvoll, einen Zeitereignistrigger für jede betroffene Zeile zu generieren, um alle möglichen Zeitpunkte abzudecken. Dies motiviert eine andere Vorgehensweise. Für einen relativen Zeitereignistrigger kann in Bezug auf das Modifikationsereignis die Ausführungsgranularität spezifiziert werden (analog zu den Modifikationstriggern). Für die Ausführungsgranularität FOR EACH ROW wird für jede durch das Modifikationsereignis betroffene Zeile ein Zeitereignistrigger generiert. Hierbei werden die Werte der Transitionsvariablen bei der Generierung im Bedingungs- und Aktionsteil des Triggers ersetzt. Soll das Zeitereignis abhängig vom Eintrittszeitpunkt des Modifikationsereignisses definiert werden, besitzen alle abgeleiteten Zeitereignistrigger den selben nächsten intendierten Ausführungszeitpunkt. Wenn das Zeitereignis relativ zu einem Ereignisparameter bestimmt wird, ist es möglich, dass die abgeleiteten Zeitereignistrigger unterschiedliche intendierte Ausführungszeitpunkte haben. Für abgeleitete periodische Zeitereignistrigger sind die intendierten Ausführungszeitpunkte zusätzlich von der spezifizierte Zeitperiode des Triggers mit einer periodisch relativen Zeitereignisspezifikation abhängig. Für STATEMENT LEVEL-Trigger generiert das System immer nur einen Zeitereignistrigger. Wird durch den abgeleiteten Zeitereignistrigger eine Transitionstabelle referenziert, speichert ARTA II diese Tabelle bis zu seiner Ausführung und löscht diese Tabelle anschließend (nach Triggerausführung). So haben diese Zeitereignistrigger bei Ausführung ebenso Zugriff auf ihre Ereignisparameter. Das Zeitereignis kann nur für die Ausführungsgranularität FOR EACH ROW relativ zu einem Ereignisparameter gesetzt werden. Dies ist aus folgendem Grund ersichtlich: Wenn das Modifikationsereignis aus der Änderung mehrerer Zeilen besteht, ist bei einem STATEMENT LEVEL-Trigger nicht ersichtlich auf welchen Wert der Zeilen sich das Zeitereignis bezieht. Für einen ROW LEVEL-Trigger bezieht sich das Zeitereignis immer auf den Wert der Zeile für die dieser Trigger ausgeführt werden soll. Betrachten wir diesbezüglich noch einmal das Beispiel des relativen Zeitereignistriggers, der abhängig von einem Diplomanmeldungsdatum zu einem bestimmten Zeitpunkt die Versendung einer Erinngerungsmail an den Diplomanden initiiert. Werden Daten mehrerer Diplomanmeldungen gleichzeitig in die Datenbank eingefügt, ist für einen STATE- MENT LEVEL-Trigger nicht mehr eindeutig festgelegt auf welches dieser Diplomanmeldungsdaten sich das Zeitereignis bezieht. Für einen ROW LEVEL-Trigger, der für jede 69

73 6 Entwurf von relativen Zeitereignisspezifikationen Zeile seines aktivierenden Ereignisses ausgeführt wird, bezieht sich das Zeitereignis auf das Diplomanmeldungsdatum, das in der jeweiligen Zeile enthalten ist. Zusätzlich zu den Ereignisparametern des Modifikationsereignisses wäre es möglich die Referenzierung des Zeitpunktes zuzulassen, zu dem das Modifikationsereignis beobachtet wird. Auf diesem Wege könnte innerhalb der Bedingung oder Aktion eines Trigger der time offset des relativen Zeitereignistriggers berechnet werden. Der Zugriff dieses Zeitpunktes wird jedoch nicht unterstützt. Einerseits ist dieser Zugriff im SQL-Trigger- Konzept sowie im ARTA II-System für Modifikationstrigger nicht vorgesehen und andererseits soll die relative Zeitereignisspezifikation nicht noch komlexer und damit unübersichtlich für den Anwender werden. Neben dem Zugriff auf die Ereignisparameter des Modifikationsereignisses sollten relative Zeitereignistrigger Zugriff auf die Ereignisparameter des Zeitereignisses haben. Im Sinne einer orthogonalen Erweiterung werden relative Zeitereignistrigger im Bedingungsund Aktionsteil mittels der Variablen Date und Time Zugriff auf ihren jeweils aktuellen intendierten Ausführungszeitpunkt erhalten, analog zu absoluten und periodischen Zeitereignistriggern. Die Variablen (Date und Time) werden vor Ausführung des abgeleiteten Zeitereignistriggers durch ihre Werte ersetzt. Für Trigger mit einer periodisch relativen Zeitereignisspezifikation sind - ähnlich zu periodischen Zeitereignistriggern - alle vorhergehenden intendierten Ausführungszeitpunkte und auch alle zukünftigen intendierten Ausführungszeitpunkte relevante Ereignisparameter. Ebenso wären die Zeitdifferenzen zwischen den intendierten Ausführungszeitpunkten bei variablen Perioden relevante Ereignisparameter. Allerdings haben wir in Bezug auf periodische Zeitereignisspezifikationen bereits von dieser Form der Ereignisparameterreferenzierung abgesehen und wollen aufgrund dieser Entscheidung diese Referenzierung auch für periodisch relative Zeitereignisspezifikationen vernachlässigen. Ähnlich zum Vorschlag aus der Diplomarbeit [Dor04] zum introspektiven Zugriff auf die Schemadaten wie beispielsweise Periode oder aktuelle Deadline des jeweiligen Triggers, könnte der Zugriff auf den time offset einer relativen Zeitereignsspezifikation realisiert werden. Zum einen wurde im Rahmen der ARTA II-Trigger auf den Zugriff dieser Schemadaten verzichtet. Dies soll ebenso für den neuen Triggertypen gelten. Zum anderen wollen wir uns auf die wichtigsten bzw. gebräuchlichsten Ereignisparameter begrenzen und damit den Speicherplatzbedarf der Spezifikation nicht unnötig erhöhen Syntax Die ARTA II-Trigger werden um zwei neue Triggertypen erweitert: einerseits um Trigger mit einer absolut relativen Zeitereignisspezifikation und andererseits um Trigger mit einer periodisch relativen Zeitereignisspezifikation. Dementsprechend wird die trigger definition folgendermaßen erweitert: 70

74 6 Entwurf von relativen Zeitereignisspezifikationen <trigger definition> ::= CREATE TRIGGER <trigger name> <trigger interval> <trigger event spec> <trigger activation state> <trigger priority> <trigger deadline> [ <event parameter reference> ] [ <trigger condition> ] <triggered action> <trigger event spec> ::= <modification event spec> <time event spec> <time event spec> ::= <absolute event spec> <periodic event spec> <relative event spec> <relative event spec> ::= <absolute relative event spec> <periodic relative event spec> <absolute relative event spec> ::= <modification event spec> START <time offset> AFTER <relative time point> <periodic relative event spec> ::= <absolute relative event spec> <periodic event spec> DURING <relative time period> <time offset> ::= <interval specification> <relative time point> ::= MODIFICATION <identifier> (Spaltennamen der ausgewählten Tabelle) <relative time period> :: = <interval specification> Das Priotitätenkonzept, das Gültigkeitsintervall, die Deadline sowie der Aktivierungszustand werden ausnahmslos für Trigger mit einer relativen Zeitereignisspezifikation über- 71

75 6 Entwurf von relativen Zeitereignisspezifikationen nommen. Innerhalb der modification event spec kann für den Ausführungszeitpunkt eines relativen Zeitereignistriggers ausschließlich AFTER spezifiziert werden. Erst nachdem die Datenänderung tatsächlich in die Datenbank eingebracht ist, kann für relative Zeitereignisrigger eine Aktion abhängig vom time offset gestartet werden. Im vorhergehenden Abschnitt (6.2.1) wurde bereits die Verwendung von Transitionsvariablen bzw. -tabellen motiviert. Die Referenzierung der Transitionsvariablen bzw. -tabellen soll im gleichen Umfang analog zu den ARTA II-Modifikationstriggern realisiert werden. Mit Hilfe der Ausführungsgranularität kann angegeben werden, ob ein abgeleiteter Zeitereignistrigger für jede durch das Modifikationsereignis betroffene Zeile ( FOR EACH ROW ) oder nur einmal für das Modifikationsereignis ( FOR EACH STATEMENT ) generiert wird. In der Anforderungsanalyse wurde erwähnt, dass neben dem Zeitpunkt des Modifikationsereignisses dem Anwender ebenfalls die Möglichkeit gegeben werden soll, Zeitereignisse relativ zu einem Zeitpunkt setzen zu können, der in der vom Änderungsereignis betroffenen Zeile enthalten ist. Dies motiviert das zusätzliche Konstrukt: START <time offset> AFTER <relative time point> : Hierbei wird mit dem relative time point spezifiziert, ob das Zeitereignis relativ zum Zeitpunkt des Auftretens des Modifikationsereignis oder relativ zu einem in einer Zeile enthaltenen Zeitpunkt gesetzt wird. Diesbezüglich kann entweder MODIFICATION - für das Modifikationsereignis - oder ein Spaltenname der durch das Modifikationsereignis betroffenen Tabelle definiert werden. Die Möglichkeit für den relative time point einen Spaltennamen der betroffenen Tabelle zu spezifizieren ist nur für ROW Level-Trigger möglich (vgl ). Für Trigger mit einer periodischen relativen Zeitereignisspezifikation muss zusätzlich eine Zeitperiode definiert werden, die angibt in welchen Abständen die intendierten Ausführungszeitpunke nach Ablauf der durch das time offset spezifizierten Zeitperiode auftreten. Aufgrund einer möglichst einfachen Erweiterung und der größtmöglichen Orthogonalität zum Konzept der periodischen Zeitereignisspezifikation erfolgt die Periodendefinition mittels der periodic event spec, die in Abschnitt ausführlich beschrieben wurde. Zusätzlich soll mittels der relative time period eine Zeitperiode angegeben werden, in der die Zeitereignisse liegen. Zu dem Zeitpunkt an dem, durch eine relative Zeitereignisspezifikation definiertes, Zeitereignis eintritt, ist nicht mehr sichergestellt, dass die Datenänderung noch in der Datenbank enthalten ist, die ursprünglich den relativen Zeitereignistrigger aktiviert hat. In diesem Fall könnten zusätzliche Funktionen realisiert werden, die die Triggerausführung abbrechen, falls die Datenänderung nicht mehr in der Datenbank enthalten ist. Bisher wurden solche Funktionen nicht in ARTA II realisert, weil der Anwender ebenso mittels der Bedingung (trigger condition) vor Aktionausführung des Triggers eine Abfrage bezüglich der Datenänderung vornehmen kann. 72

76 6 Entwurf von relativen Zeitereignisspezifikationen Semantik Für die Beschreibung der Semantik von relativen Zeitereignistriggern wird ähnlich zur Semanikbeschreibung von absoluten und periodischen Zeitereignistriggern vorgegangen (vgl ). Dabei soll die Beschreibung nicht anhand der Charakterisierung der Klassifikationsmerkmale vorgenommen werden, sondern anhand der Reduktion eines relativen Zeitereignistriggers auf zwei Modifikationstrigger. Mit Hilfe dieser Reduktion kann gezeigt werden, dass die Semantik konsistent zu der Semantik von absoluten bzw. periodischen Zeitereignistriggern definiert werden kann. Hierzu betrachten wir in Beispiel 2 einen Trigger mit einer absolut relativen Zeitereignisspezifikation. Dieser Trigger kann eingesetzt werden, um die Frist von 6 Monaten für die Fertigstellung der Diplomarbeit zu kontrollieren, nachdem ein Student sich für eine solche Arbeit angemeldet hat. Überschreitet der Student bei der Bearbeitung der Diplomarbeit diese Frist - ist also kein Eintrag für ihn nach spätestens 6 Monaten in die Tabelle tbl_diplomabgabe vorgenommen worden -, erfolgt für diesen Studenten ein Eintrag in der Tabelle tbl_zeitüberschreitung. Zur Vereinfachung wird ein STATEMENT LEVEL-Trigger verwendet und dementsprechend der Zeitpunkt des Eintretens des Modifikationsereignisses als relative time point ausgewählt. Zudem wird auf die Angaben der Steuerungskomponenten - Gültigkeitsintervall, Aktivierungszustand, Priorität sowie Deadline - verzichtet. Beispiel 2: CREATE TRIGGER tr_relative AFTER INSERT ON tbl_diplanmeldung START 6 months AFTER MODIFICATION REFERENCING NEW TABLE AS nt AND DATE AS date WHEN EXISTS (SELECT * FROM nt,tbl_diplanmeldung WHERE nt.name=tbl_diplanmeldung.name) BEGIN FOR EACH STATEMENT INSERT INTO tbl_zeitüberschreitung(name,date) SELECT Name,date FROM nt,tbl_diplanmeldung, tbl_diplomabgabe WHERE nt.name=tbl_diplanmeldung.name and nt.name NOT IN (SELECT name FROM tbl_diplomabgabe) END Der Abschnitt hat ergeben, dass eine relative Zeitereignisspezifikation nicht aus einem einzelnen relativen Ereignis besteht, sondern eine Kombination von zwei unterschiedlichen Ereignistypen ist. Dabei ist das inbegriffene Zeitereignis nicht vorbestimmt, 73

77 6 Entwurf von relativen Zeitereignisspezifikationen sondern benötigt den Eintrittszeitpunkt des zugehörigen Modifikationsereignisses. Folglich werden für die semantische Umschreibung einer relativen Zeitereignisspezifikation zwei verwandte Modifikationstrigger benötigt. Das folgende Beispiel 3 zeigt die umgeschriebene Form des relativen Zeitereignistriggers, wobei Schema Modifikations-Statements innerhalb des Aktionsteils des Triggers benutzt werden. Dies wird durch den SQL-Standard nicht verboten, könnte jedoch im Allgemeinen problematisch sein. In unserem Fall soll es die losgelöste Kopplung zweier benötigter Modifikationstrigger hervorheben. Der erste Trigger wird für das Modifikationsereignis innerhalb der relativen Ereignisspezifikation definiert, während der zweite Trigger für das abgeleitete Zeitereignis spezifiziert wird. Der erste Trigger unterstützt die Parameterbindungen für den zweiten Trigger bezüglich der Modifikationstabelle und dem Zeitpunkt zu dem das Modifikationsereignis eintrat. Dieser Zeitpunkt wird zusammen mit dem gegebenen time offset von 6 Monaten benutzt um das Zeitereignis zu berechnen, zu dem der zweite Trigger aktiviert werden soll. Wieder wird eine entsprechende System-Hilfstabelle (hier time_event_(time(nt)+6 months) ) benutzt, um das erhaltene Zeitereignis simulieren zu können (vgl ). Beispiel 3: CREATE TRIGGER mtr_relative AFTER INSERT ON tbl_diplanmeldung REFERENCING NEW TABLE AS nt FOR EACH STATEMENT BEGIN CREATE TRIGGER mtr_relative AFTER INSERT ON time_event_(time(nt)+6 months) REFERENCING NEW ROW AS d FOR EACH STATEMENT WHEN EXISTS (SELECT * FROM nt,tbl_diplanmeldung WHERE nt.name=tbl_diplanmeldung.name) BEGIN INSERT INTO tbl_zeitüberschreitung(name,date) SELECT Name,d FROM nt,tbl_diplanmeldung, tbl_diplomabgabe WHERE nt.name=tbl_diplanmeldung.name and nt.name NOT IN (SELECT name FROM tbl_diplomabgabe) END END Nachdem der Trigger mtr_relative aktiviert wurde, erfolgt die Generierung des Triggers mtr_relative. Die vorgeschlagene Semantik für die Evaluierung von Triggern mit einer relativen Zeitereignisspezifikation zeigt, dass zwei separate Prozesse in verschiedenen Transaktionen ausgewertet werden. Ein Trigger mit einer periodisch relativen Zeitereignisspezifikation könnte entsprechend durch einen Modifikationstrigger mit mehreren CREATE TRIGGER-Anweisungen innerhalb seiner Aktion ersetzt werden. Auf diese 74

78 6 Entwurf von relativen Zeitereignisspezifikationen Weise würde für jedes Zeitereignis, das durch die periodische Zeitereignisspezifikation repräsentiert wird, nach Eintreten des Modifikationsereignisses ein Trigger generiert werden. Folglich kann die Semantik konsistent mit dem Entwurf von Modifikationstriggern und somit konsistent mit der Semantik von Triggern mit einer absoluten bzw. periodischen Zeitereignisspezifikation definiert werden. Der Unterschied besteht allein darin, dass zunächst ein Modifikationsereignis stattfinden muss, damit das Zeitereignis berechnet werden kann zu dem der Trigger mit relativer Zeitereignisspezifikation aktiviert wird. Ist die Ausführungsgranularität FOR EACH ROW, wird über die Ereignisparameter des Modifikationsereignisses iteriert und für jede Zeile abhängig von der Spezifikation des relative time point und des time offsets ein Zeitereignis bestimmt, für das der relative Zeitereignistrigger aktiviert wird. 75

79 7 Implementierung Dieses Kapitel präsentiert die Umsetzung von Triggern mit einer absolut relativen Zeitereignisspezifikation und einer periodisch relativen Zeitereignisspezifikation für das ARTA II-System. Nachdem das System um die für die Umsetzung relativer Zeitereignisspezifikationen benötigten Funktionalitäten vervollständigt wurde, sind alle Voraussetzungen für eine erfolgreiche Realisierung dieses speziellen Ereignistyps gegeben. Mit Hilfe eines relativen Zeitereignistriggers soll eine verzögerte (Re-) Aktion abhängig von einem bestimmten time offset auf ein im Trigger spezifizierte Modifikationsereignis ausgeführt werden. Dabei wird die (Re-)Aktion entweder einmal (absolut relativ) oder in regelmäßigen Abständen (periodisch relativ) ausgeführt. In Abschnitt 6.2 wurde gesagt, dass die verzögerte (Re-) Aktion mit Hilfe eines absoluten bzw. periodischen Zeitereignistriggers simuliert wird. Nachdem ein in einem relativen Zeitereignistrigger spezifiziertes Modifikationsereignis beobachtet wird, generiert das ARTA II-System einen abgeleiteten Zeitereignistrigger. Die Spezifikation dieses Zeitereignistriggers leitet sich aus der Spezifikation des relativen Zeitereignistriggers ab. Die genaue Vorgehensweise der Generierung eines abgeleiteten Zeitereignistriggers wird in Abschnitt 7.2 beschrieben. Zuvor werden in Abschnitt 7.1 die Möglichkeiten diskutiert, die sich in Bezug auf die Speicherung relativer Zeitereignistrigger ergeben haben. Die verschiedenen Erweiterungsmöglichkeiten der Oberflächenimplementierung werden in Abschnitt 7.3 betrachtet. Anschließend soll auf Ausnahmen eingegangen werden, die aus der Generierung eines abgeleiteten Triggers resultieren. Am Ende dieses Kapitels werden in Abschnitt 7.5 anhand von Screenshots Anwendungsszenarien von relativen Zeitereignistriggern präsentiert. Infolge der Implementierung des neuen Triggertyps wurden die Oberfläche - das Triggerübersichtsformular und der Triggereditor -, das Trigger-Modul, das Zeitereignis-Modul sowie das Trigger Ausführungs-Modul erweitert. 7.1 Speicherung relativer Zeitereignistrigger Innerhalb einer Access-Anwendung kann nicht auf die Schemadaten der Datenbank zugegriffen werden. Dies bedeutet, dass wir das Schema in Form von Accesstabellen simulieren müssen. In diesen Tabellen werden die Schemadaten gespeichert, die das ARTA II-System benötigt. Die Namen dieser Tabellen beginnen mit dem Kürzel USys_. Somit können diese Tabellen von anderen Anwendungstabellen unterschieden werden. 76

80 7 Implementierung Sämtliche Triggerspezifikationen in ARTA II wurden zusammen mit den zugehörigen Ereignisspezifikationen in der Tabelle USys_Trigger gespeichert. Da für die unterschiedlichen Triggertypen unterschiedliche Werte spezifiziert werden müssen, gibt es in dieser Tabelle Nullwerte. Zum Beispiel sind für die periodische Zeitereignisspezifikation für jede Periode verschiedene Werte zu definieren. Für eine Variante der Periodenspezifikation Monat müssen allein 4 Werte gespeichert werden. Für einen absoluten Zeitereignistrigger oder einem Modifikationstrigger enthalten u. a. alle Spalten für die Periodenspezifikation Nullwerte. Ganz offensichtlich ist dies kein optimaler Schemaentwurf. Die Anzahl der Nullwerte in der Tabelle USys_trigger steigt, wenn auch relative Zeitereignisspezifikationen in dieser Tabelle gespeichert werden sollen. Für eine relative Zeitereignisspezifikation müssen neben der Spezifikation des Modifikations- und Zeitereignisses die Zeitperiode für den time offset und der relative time point gespeichert werden. Für periodisch relative Zeitereignisspezifikationen ist zusätzlich die Speicherung einer Zeitperiode (relative time period) notwendig, die später das Gültigkeitsintervall des abgeleiteten periodischen Zeitereignistrigger bildet. Für die Zeitperioden werden jeweils zwei Werte gespeichert: der Periodentyp (Minuten, Stunden, usw.) sowie eine Zahl, die die Anzahl der jeweiligen Zeitperiode angibt. Da für die anderen Triggertypen diese Werte nicht spezifiziert werden müssen, existieren in diesen Feldern Nullwerte. Um diese Redundanzen zu vermeiden, könnte zunächst erwogen werden, die Spezifikationen der verschiedenen Triggertypen in unterschiedlichen Tabellen zu speichern. Hierbei könnte jedoch nicht mehr garantiert werden, dass sämtliche sich in ARTA II befindlichen Trigger unterschiedliche Prioritäten aufweisen. Dies kann garantiert werden, indem für die Spalte Priorität der Tabelle USys_trigger mittels einer Eigenschaft festgelegt ist, dass keine zwei Zeilen identische Werte besitzen dürfen und alle Triggerspezifikationen in dieser Tabelle gespeichert sind. Eine andere Möglichkeit besteht in der Speicherung der Triggerspezifikationen und der zugehörigen Ereignisspezifikationen in getrennten Tabellen. Beide Tabellen könnten mit einer Access-Beziehung so verknüpft werden, dass eine Ereignisspezifikation mit mehreren Triggern verbunden sein kann. Auf diese Weise könnte jedoch nur Speicherplatz eingespart werden, wenn mehrere Trigger eine identische Ereignisspezifikation besitzen. Die Anzahl der Nullwerte würde nicht entscheidend reduziert. Eine erhebliche Reduktion der Redundanzen kann erreicht werden, wenn die Speicherung der Ereignisspezifikationen der Trigger in verschiedenen Tabellen (eine Tabelle für jeden Ereignistyp) erfolgt. Der Schemaentwurf könnte weiter optimiert werden, wenn zudem die periodischen Ereignisspezifikationen in getrennten Tabellen gespeichert würden, so dass für jede Periode (Periode Minute, Stunde, usw.) eine eigene Tabelle angelegt werden würde, in der die periodischen Zeitereignisspezifikation abhängig von ihrer Periode gespeichert werden. Mit diesem Schemaentwurf könnte zwar eine große Anzahl an Nullwerten vermieden und somit der Speicherplatzbedarf eingeschränkt werden, jedoch müsste eine erhebliche Laufzeitverschlechterung in Kauf genommen werden. Der Wartungsaufwand wäre erhöht, da 77

81 7 Implementierung jedesmal vor der Ausführung eines Triggers seine Spezifikation aus zwei oder im Falle eines periodischen Zeitereignistriggers aus drei Tabellen zusammengesetzt werden müsste. Weiterhin könnte das Löschen einer Ereignisspezifikation zu schwerwiegenden Fehlern führen, wenn es im System einen zugehörigen Trigger gibt, der nicht gelöscht wird. Des weiteren würde die Aufteilung der Speicherung der Triggerspezifikationen auf mehrere Tabellen eine unüberschaubare Umstrukturierung des Programms mit sich bringen. Für eine bessere Laufzeit und einem geringeren Wartungsaufwand verbleibt die Speicherung der Triggerspezifikationen vollständig in der Tabelle USys_trigger. Ein erhöhter Speicherplatzbedarf wird dabei in Kauf genommen. 7.2 Generierung der abgeleiteten Zeitereignistrigger Nachdem ein in einem relativen Zeitereignistrigger spezifiziertes Modifikationsereignis aufgetreten ist, wird ein absoluter oder periodischer Zeitereignistrigger generiert. Diese Generierung darf erst dann vorgenommen werden, wenn sichergestellt ist, dass die Datenmodifikation erfolgreich durchgeführt wurde, das heisst die ARTA-Transaktion nicht mehr abgebrochen werden kann. Andernfalls könnte ein abgeleiteter Zeitereignistrigger erzeugt werden, trotzdem die ARTA-Transaktion möglicherweise zu einem späteren Zeitpunkt ohne Datenänderung abgebrochen werden würde. Nach Ausführung des letzten AFTER-Triggers ist sichergestellt, dass die Datenänderung erfolgreich in die Datenbank eingebracht werden kann. Die Generierung des Zeitereignistriggers sollte zudem innerhalb der ARTA-Transaktion erfolgen, da der Bedingungs- sowie Aktionsteil des Triggers Transitionsvariablen bzw. Transitionstabellen referenzieren kann. Auf die Werte dieser Variablen bzw. Tabellen kann nur innerhalb der Transaktion mittels des Trigger Execution Contexts (vgl. 3.3) zugegriffen werden. Somit findet die Generierung des abgeleiteten Zeitereignistrigger nach Ausführung der AFTER-Trigger innerhalb bzw. kurz vor Ende der ARTA-Transaktion statt. Nach der Ausführung der AFTER-Modifikationstrigger werden folglich alle Trigger mit einer relativen Zeitereignisspezifikation iterativ bertrachtet und abhängig von der spezifizierten Ausführungsgranularität Zeitereignistrigger generiert. Die Priorität des relativen Zeitereignistrigger hat keinerlei Einfluß auf die Reihenfolge der Generierung der abgeleiteten Zeitereignistrigger. Diese Priorität dient allein als Vorgabe für die abgeleiteten Zeitereignistrigger. Während für einen STATEMENT LEVEL-Trigger mit einer absolut relativen Zeitereignispezifikation nach Eintreten des Modifikationsereignisses nur ein abgeleiteter absoluter Zeitereignistrigger generiert wird, erfolgt durch einen ROW LEVEL- Trigger für jede durch das Modifikationsereignis betroffene Zeile eine Generierung eines Triggers mit einer absoluten Zeitereignisspezifikation. Für einen STATEMENT LEVEL-Trigger mit einer periodisch relativen Zeitereignisspezifikation wird nach dem Eintreten des Modifikationsereignisses ein Trigger mit einer 78

82 7 Implementierung periodischen Zeitereignisspezifikation erzeugt. Dementsprechend kommt es durch einen ROW LEVEL-Trigger zur Generierung eines periodischen Zeitereignistriggers für jede durch das Modifikationsereignis betroffene Zeile. Die abgeleiteten Zeitereignistrigger initiieren bei Ausführung ihre eigene ARTA-Transaktion (vgl ). Somit erfolgt die Auswertung einer relativen Zeitereignisspezifikation in zwei unterschiedlichen ARTA-Transaktionen. In einer ersten Transaktion wird das Modifikationsereignis ausgewertet, in dem ein abgeleiteter Zeitereignistrigger generiert wird. In einer zweiten Transaktion findet die Ausführung des abgeleiteten Zeitereignistrigger statt. Die Spezifikationen der abgeleiteten Trigger findet innerhalb der Prozedur createabsoluteperiodictrigger() statt. Der Name eines solchen Triggers setzt sich aus dem Namen des zugehörigen relativen Zeitereignistriggers, einer Zufallszahl und dem Kürzel Absolute oder Periodic zusammen. Die zwei Kürzel besagen, ob der Trigger von einem Trigger mit absolut bzw. periodisch relativer Zeitereignisspezifikation abgeleitet wurde und dementsprechend ein absoluter bzw. periodischer Zeitereignistrigger ist. Zwei unterschiedliche Trigger dürfen in ARTA II nicht denselben Namen besitzen. Ein wiederholtes Eintreten des gleichen Modifikationsereignisses führt zu einer wiederholten Generierung eines Zeitereignistriggers durch einen relativen Zeitereignistrigger. Infolgedessen erhält der Name Zufallszahlen, um zu verhindern, dass zwei unterschiedliche Trigger identische Namen besitzen. Der Name des relativen Zeitereignistrigger wird im Triggernamen übernommen, damit der Anwender nach Generierung des Triggers erkennen kann, von welchem relativen Zeitereignistrigger der Trigger abgeleitet wurde. Die abgeleiteten Zeitereignistrigger erhalten die Priorität des relativen Zeitereignistriggers +1. Da beide Triggerspezifikationen in der selben Datenbank gespeichert werden, ist es nicht möglich beiden Triggern dieselbe Priorität zuzuweisen. Allerdings werden die abgeleiteten Zeitereignistrigger in der gewünschten Reihenfolge relativ zu den anderen Zeitereignistriggern ausgeführt. Werden mehrere Trigger durch den relativen Zeitereignistrigger generiert, besitzt der abgeleitete Trigger die höchste Priorität, der als letztes generiert wurde. Die Deadline sowie der Bedingungs- und Aktionsteil werden unverändert übernommen. Hierbei werden lediglich für einen ROW LEVEL-Trigger die Werte für die Transitionsvariablen im Bedingungs- und Aktionsteil ersetzt. Im Falle eines STATEMENT LEVEL- Triggers werden die Transitionsvariablen durch die Namen der Transitionstabellen ersetzt. Die Transitionstabellen werden bis zur Ausführung des abgeleiteten Zeitereignistriggers im System gespeichert, wenn sie durch ihn referenziert werden. Zusätzlich werden die Ereignisparameter Date und Time übernommen, deren Werte kurz vor Ausführung des abgeleiteten Triggers in der Bedingung und Aktion ersetzt werden. Je nachdem ob es sich um einen Trigger mit absolut bzw. periodisch relativer Zeitereignisspezifikation handelt, muss in Bezug auf die Spezifikation des Gültigkeitsintervalls sowie des nächsten Ausführungszeitpunktes in absolut bzw. periodische Zeitereignisspezifikation unterschieden werden. Für beide Triggertypen beginnt das Gültigkeitsintervall 79

83 7 Implementierung zum Zeitpunkt relative time point + time offset. Der Beginn des Gültigkeitsintervalls darf nicht vor diesem Zeitpunkt definiert werden, da ansonsten ein Trigger mit periodischer Zeitereignisspezifikation schon vor Ablauf der im time offset spezifizierten Zeitperiode ausgeführt werden würde. Der Beginn des Gültigkeitsintervalls ist gleichzeitig der erste und einzige Ausführungszeitpunkt eines abgeleiteten Triggers mit absoluter Zeitereignisspezifikation. Das Ende des Gültigkeitsintervalls eines solchen Triggers berechnet sich aus der Addition mit dem Ausführungszeitpunkt und der Zeitperiode, die durch die Deadline spezifiziert wird. Wenn das System zum Ausführungszeitpunkt ausgeschaltet ist, kann auf diese Weise eine verzögerte Ausführung des Triggers erfolgen, solange die Deadline des Triggers noch nicht abgelaufen ist. Das Ende des Gültigkeitsintervalls spielt für diesen Triggertyp ansonsten keine Rolle, da die Spezifikation eines absoluten Zeitereignistriggers direkt nach der Triggerausführung aus der Datenbank gelöscht wird. Für Trigger mit einer periodischen Zeitereignisspezifikation besteht der erste Ausführungszeitpunkt aus dem ersten Zeitpunkt, der innerhalb des Gültigkeitsintervalls liegt und die in der Periode geforderte Eigenschaft besitzt. Die Dauer des Gültigkeitsintervalls wird durch die relative time period spezifiziert. Werden die abgeleiteten Zeitereignistrigger nach ihrer Ausführung bzw. nach Ablauf ihres Gültigkeitsintervalls gelöscht, gibt es keine Meldung an den Anwender, da diese Trigger nicht explizit vom Anwender spezifiziert worden sind. Die Modifizierung des Aktivierungszustandes eines relativen Zeitereignistriggers hat keinerlei Einfluß auf dessen abgeleitete Zeitereignistrigger. Nachdem ein relativer Zeitereignistrigger deaktiviert wurde, können die von ihm abgeleiteten Zeitereignistrigger trotzdem ausgeführt werden. Tritt während der Deaktivierung eines relativen Zeitereignistrigger ein durch ihn spezifiziertes Modifikationsereignis ein, findet keine Generierung eines Zeitereignistriggers statt. Nach erneuter Aktivierung eines relativen Zeitereignistriggers wird keine rückwirkende Generierung eines abgeleiteten Zeitereignistrigger zugelassen. Analog zu Modifikationstriggern ist diese Generierung nur innerhalb der laufenden ARTA-Transaktion möglich, da nur innerhalb einer Transaktion mit Hilfe des TEC der Zugriff auf die Werte der Transitionsvariablen möglich ist. Ebenso soll die Deadline allein für den abgeleiteten Zeitereignistrigger gelten. Ob die Generierung eines abgeleiteten Zeitereignistriggers noch sinnvoll ist, sollte vom berechneten Zeitereignis und von der Deadline bzw. dem Gültigkeitsintervall des abgeleiteten Zeitereignistriggers abhängen. 7.3 Grafische Benutzeroberfläche Bei der Weiterentwicklung der grafischen Benutzeroberfläche von ARTA II im Rahmen dieser Diplomarbeit wurde vor allem auf eine übersichtliche Gestaltung der Oberfläche geachtet, so dass der Anwender sich leicht und ohne großen Aufwand zurecht finden kann. Die Syntax, die in entwickelt wurde, soll wie für die Modifikationstrigger und 80

84 7 Implementierung die absoluten bzw. periodischen Zeitereignistrigger ebenso für die relativen Zeitereignistrigger auf der Oberfläche des ARTA II-System abgebildet werden. Zunächst bestand für die Erweiterung der Benutzeroberfläche die Möglichkeit zwei neue Formulare zu erstellen, die neben dem Triggerübersichts-, dem Event Type- und dem SQL-Statement Formularen aus dem ARTA II-Hauptfenster heraus zu erreichen wären. Diese Formulare würden dann zum einen - analog zu den Formularen für die ARTA II- Trigger - aus einem Übersichtsformular für die relativen Zeitereignistrigger und zum anderen aus einem Triggereditor für diese neuen Triggertypen bestehen. Das hätte zur Folge, dass entweder keine Übersicht von sämtlichen Triggern in ARTA II vorhanden wäre oder eine solche Übersicht in Form eines weiteren Formulars zusätzlich hätte erstellt werden müssen. Um eine unnötige Erstellung von Formularen zu vermeiden und eine einheitliche Sicht auf alle Trigger zu ermöglichen, wurde das bereits bestehende Triggerübersichts-Formular dahingehend erweitert, dass in diesem auch relative Zeitereignistrigger zusammen mit allen anderen Triggern angezeigt werden können. Weiterhin wurde aus vergleichbaren Gründen von der Implementierung eines weiteren Triggereditors allein für relative Zeitereignistrigger abgesehen und der existierende Editor entsprechend erweitert, so dass mit diesem auch die Definition von Triggern mit einer relativen Zeitereignisspezifikation möglich ist. Auf diese Weise wird die Ähnlichkeit der verschiedenen Triggertypen untereinander verdeutlicht und die Spezifizierung bzw. Modifizierung von Triggern kann einheitlich erfolgen. Dem Anwender wird so eine leichte Bedienung der Oberfläche ohne große Einarbeitungszeit ermöglicht. Innerhalb des Triggereditor-Formulars kann der Anwender neben dem Ereignistyp Modifikation und der absoluten sowie periodischen Zeitereignisspezifikationen jetzt auch zwischen den absoluten bzw. periodischen relativen Zeitereignisspezifikationen wählen. Der Bereich auf dem Formular, der für die Ereignisspezifikation vorgesehen war, ist für die doch etwas umfangreichere Spezifikation von relativen Zeitereignistypen zu klein. Aus diesem Grund wird, um den Bereich und somit das Formular nicht unnötig zu vergrößern, das Registersteuerelement eingesetzt, das sich bei der Oberflächenerstellung bereits bewährt hat (vgl. [Cali04]). Die Auslagerung der Ereignisspezifikation in ein weiteres Formular wäre ebenso möglich gewesen. Mit Hilfe des Registersteuerelements, das mehrere Seiten mit je einer Registerkarte enthält, konnte jedoch die Erweiterung ohne großen Implementierungsaufwand gelingen. Zusätzlich kann die Anzahl der notwendigen Verschiebungen von Objekten bei Änderungen bzw. Erweiterungen mittels der Verwendung dieses Steuerelementes im Rahmen gehalten werden. Für die Definition von absolut relativen Zeitereignisspezifikationen stehen dem Anwender zwei so genannte Reiter des Registersteuerelementes zur Verfügung. In dem ersten Reiter - SET MODIFICATION - kann das Modifikationsereignis spezifiziert werden nachdem der abgeleitete Zeitereignistrigger generiert werden soll. SET TIME OFFSET bezeichnet den zweiten Reiter mit dem der time offset, der relative time point sowie die Ereignisparameter für das Zeitereignis definiert werden können. Zu der periodisch relativen Zeitereignisspezifikation gehört ein weiterer dritter Reiter: SET PERIOD. Auf dieser Registerkarte 81

85 7 Implementierung kann die Zeitperiode und zusätzlich die Zeitdauer (relative time period) bestimmt werden, für die die abgeleiteten Zeitereignistrigger gültig sein sollen. Der Aufbau des Triggereditors wurde nicht verändert, da dieser sich an der Triggersyntax orientiert und gut strukturiert ist. Das Formular ist in drei Bereiche aufgeteilt. Im oberen Bereich kann nachdem der Name des Triggers sowie das Gültigkeitsintervall definiert wurden, der Ereignistyp ausgewählt werden. Neben der Auswahl der Ereignistypen - hier kann auch auf vorhandene Ereignismuster zugegriffen werden - befinden sich die Angaben zu Priorität, Aktivierungszustand und Deadline des Triggers. Im mittleren Bereich wird die Ereignisspezifikation definiert. Die Bedingung, Aktion sowie ein Kommentar des Triggers können im unteren Bereich in das Formular eingegeben werden. Der strukturelle Aufbau des Triggerübersichts-Formulars ist ähnlich dem Triggereditor- Formular. Allerdings können hier zunächst in einer Übersicht die Triggerspezifikation in einer Liste betrachtet werden. Es werden u.a. der Triggername, der Ereignistyp und für Zeitereignistrigger der nächste Ausführungszeitpunkt angezeigt. Die Oberfläche des System wurde so erweitert, dass der Anwender jetzt zwischen zwei unterschiedlichen Übersichten wählen kann. Möchte der Anwender einzig von den Triggerspezifikationen einen Überblick erhalten, die von ihm explizit definiert worden sind, kann er dies innerhalb des Formulars mit Hilfe eines Optionsfeldes angeben. Mit der anderen Übersicht besteht die Möglichkeit sämtliche in ARTA II existierenden Triggerspezifikationen zu betrachten. In dieser Übersicht werden ebenso die abgeleiteten absoluten bzw. periodischen Zeitereignistrigger angezeigt, die durch einen relativen Zeitereignistrigger generiert worden sind. Analog zu den anderen Triggern in ARTA II sind auch die abgeleiteten Zeitereignistrigger nach ihrer Generierung modifizierbar. Der Aktivierungszustand dieser Trigger kann geändert und deren Spezifikation durch Aufruf des Triggereditors durch den Anwender modifiziert werden. Falls ein relativer Zeitereignistrigger vom Anwender nicht korrekt spezifiziert worden ist, könnte ein abgeleiteter Zeitereignistrigger generiert werden, der nicht die vom Anwender benötigte Funktionalität besitzt. Für diesen Trigger besteht nach seiner Generierung die Möglichkeit, dass dieser Trigger vom Anwender modifiziert, deaktiviert sowie gelöscht werden kann. In der Listenübersicht kann eine Triggerspezifikation ausgewählt werden, deren Werte anschließend im Formular dargestellt werden. Unter der Triggerübersicht wird die Ereignisspezifikation des markierten Triggers präsentiert. Die Darstellung der relativen Zeitereignisspezifikation eines Triggers im Triggerübersichts-Formular wurde aus Gründen der Übersichtlichkeit ebenfalls mit einem Registersteuerelement realisiert. Auch hier wird ein Registersteuerelement mit zwei Reitern ( MODIFICATION, TIME OFFSET ) für die absolut relative Zeitereignisspezifikation und ein Registersteuerelement mit drei Reitern ( MODIFICATION, TIME OFFSET, PERIOD ) für die periodisch relative Zeitereignisspezifikation zur Verfügung gestellt (analog zum Triggereditor). Neben der Ereignisspezifikation befinden sich Angaben zur Deadline, zum Gültigkeitsintervall und zum Aktivierungszustand des Triggers, wobei der Aktivierungszustand eines Triggers auch innerhalb dieses Formulars modifiziert werden kann. Unter der Ereignisspezifikation und 82

86 7 Implementierung den Angaben zu den Steuerungskomponenten werden die Bedingung, die Aktion und der Kommentar des Triggers mittels eines weiteren Registersteuerelementes dargestellt. 7.4 Ausnahmebehandlung Die Ausnahmen, die bei Generierung eines abgeleiteten Zeitereignistrigger eintreten können, sollen in diesem Abschnitt betrachtet werden. Zusätzlich wird das Systemverhalten nach Eintreten einer solchen Ausnahme beschrieben. Die Ausnahmen resultieren hauptsächlich aus der Möglichkeit neben dem Eintrittszeitpunkt des Modifikationsereignisses für den relative time point einen Zeitpunkt zu spezifizieren, der in einer vom Modifikationsereignis betroffenen Zeile enthalten ist. Für die Spezifizierung des relative time point eines ROW LEVEL-Triggers ist nicht sichergestellt, dass der referenzierte Wert immer einen Zeitpunkt beinhaltet. Zum Beispiel kann der Anwender einen nicht vorhandenen Spaltennamen oder einen Spaltennamen der kein Datum mit einer Uhrzeit enthält für den relative time point definieren. In diesen Fällen wird kein abgeleiteter Zeitereignistrigger generiert und dem Anwender mitgeteilt, dass der relative time point sich nicht auf einen korrekt spezifizierten Zeitpunkt bezieht. Ebenfalls findet keine Generierung eines abgeleiteten Zeitereignistriggers statt, wenn durch den relative time point einzig eine Uhrzeit spezifiziert wird. Eine Generierung findet jedoch statt, wenn sich der relative time point allein auf ein Datum bezieht. In diesem Fall wird die Uhrzeit des Eintritts des Modifikationsereignisses ausgewählt und relativ zu diesem zusammengesetzten Zeitpunkt ein Zeitereignis oder eine Menge von Zeitereignissen berechnet. Für dieses Zeitereignis oder die Menge dieser Zeitereignisse wird dann ein abgeleiteter absoluter bzw. periodischer Zeitereignistrigger generiert. Ebenfalls wäre es denkbar sich auf den Eintrittszeitpunkt des Modifikationsereignisses zu beziehen, wenn durch den relative time point kein korrekter Zeitpunkt spezifiziert wird. Weiterhin kann der durch den relative time point spezifizierte Zeitpunkt so weit in der Vergangenheit liegen, so dass dieser Zeitpunkt addiert mit dem time offset ebenfalls einen in der Vergangenheit liegenden Zeitpunkt darstellt. 1 Im Falle eines absolut relativen Zeitereignistriggers wird von der Generierung des abgeleiteten absoluten Zeitereignistriggers abgesehen, wenn auch die Deadline dieses Triggers bezüglich des betrachteten Zeitereignisses abgelaufen ist. Für periodisch relative Zeitereignistrigger wird zunächst das berechnete Gültigkeitsintervall betrachtet. Liegt dieses Intervall in der Vergangenheit, kann kein periodischer Zeitereignistrigger erstellt werden. Ist das Gültigkeitsintervall noch nicht abgelaufen, wird 1 Ebenso kann der time offset so klein gewählt sein, dass der Beginn des Gültigkeitsintervall in der Vergangenheit liegt. 83

87 7 Implementierung geprüft, ob es einen Ausführungszeitpunkt innerhalb des Gültigkeitsintervalls gibt, der entweder in der Zukunft liegt oder für den die Deadline des Triggers noch nicht abgelaufen ist. Findet keine Generierung eines abgeleiteten Zeitereignistrigger statt, wird ein Eintrag in der Log-Datei vorgenommen. Zusätzlich erhält der Anwender eine Meldung, in der ihm mitgeteilt wird, dass eine Generierung des Zeitereignistriggers nicht erfolgt ist. Für Zeitereignistrigger mit periodisch relativer Zeitereignisspezifikation sind weitere Fragen zu klären: Was passiert, wenn die Zeitperiode (relative time period), die angibt in welchem Zeitraum der abgeleitete periodische Zeitereignistrigger aktiviert werden soll, wesentlich kleiner ist als die Zeitperiode der Periodenspezifikation? Gibt es in diesen Situationen Zeitpunkte auf die sich der relative time point beziehen kann, so dass es zu einer Aktivierung eines abgeleiteten Zeitereignistrigger kommen kann? Falls es die Zeitpunkte nicht gibt, können diese Ausnahmen schon bei der Erstellung des relativen Zeitereignistrigger erkannt bzw. abgefangen werden? Bezüglich dieser Fragen soll folgendes Beispiel betrachtet werden: ein zu generierender Zeitereignistrigger soll jeden 2. Monat jeden 3. Montag um 9:00 Uhr aktiviert werden. Zusätzlich besitzen der time offset und das Gültigkeitsintervall des abgeleiteten Zeitereignistriggers eine Dauer von einer Minute. Tritt das Modifikationsereignis beispielsweise an einem 3. Montag um 8:59 Uhr eines Monats auf, kann dieser Trigger ausgeführt werden, wenn das System bis 9:00 Uhr eingeschaltet bleibt. Dies bedeutet unabhängig davon, wie klein das Zeitintervall (relative time period) - für den abgeleiteten Zeitereignistrigger das Gültigkeitsintervall - gewählt wurde, es besteht immer die Möglichkeit, dass es für diesen Trigger einen Ausführungszeitpunkt gibt. Dementsprechend sind weitere Überprüfungen bezüglich der Periodenspezifikation und des für den abgeleiteten Zeitereignistriggers spezifizierten Gültigkeitsintervalls bei der Spezifizierung eines Triggers mit einer periodisch relativen Zeitereignisspezifikation nicht notwendig. 7.5 Anwendungsszenarien Nachdem in diesem Kapitel bereits die Umsetzung von Triggern mit einer absolut relativen Zeitereignisspezifikation und Triggern mit einer periodisch relativen Zeitereignisspezifikation beschrieben wurde, beinhaltet dieser Abschnitt Anwendungsszenarien dieser Triggertypen. Für diese Szenarien wurden einfache, leicht verständliche Beispiele ausgewählt, die u.a. die Konzepte Referenzierung von Ereignisparametern, das Setzen des relativen Startzeitpunktes, Priorität, Deadline, Aktivierungszustand sowie die verzögerte Verarbeitung von aufgetretenen Zeitereignissen beinhalten. Für die Präsentation dieser Beispiele wurden drei Tabellen - tbl_a, tbl_b und tbl_c - generiert. Anhand der Zustände dieser Tabellen vor und nach der Triggerausführung soll die korrekte Ausführung der Trigger mit einer absolut bzw. periodisch relativen Zeitereignisspezifikation und die korrekte Umsetzung der genannten Konzepte (wie z.b. die Referenzierung der Ereignisparameter, Priorität, Deadline oder Aktivierungszustand) veranschaulicht werden. In 84

88 7 Implementierung Abschnitt werden Anwendungszenarien für Trigger mit absolut relativen Zeitereignispezifikationen und in Abschnitt Anwendungszenarien für Trigger mit periodisch relativen Zeitereignisspezifikationen präsentiert Trigger mit absolut relativen Zeitereignisspezifikationen In diesem Abschnitt soll die Ausführung zweier (absolut) relativer Zeitereignistrigger (tr_a und tr_b) demonstriert werden. Die dafür notwendige Spezifizierung der Trigger wird exemplarisch anhand des Triggers tr_a im ARTA II-System detailliert mittels Screenshots dargestellt. Abbildung 7.1 stellt das Triggereditor-Formular dar, in dem bereits für den Trigger tr_a der Name, das Gültigkeitsintervall ( : :59), der Ereignistyp (relative time event) und die Deadline (10 Minuten) spezifiziert wurden. Da der Trigger tr_a die erste Triggerspezifikation im ARTA II-System darstellt, erhält dieser Trigger automatisch vom System die Priorität 1. Wird der Ereignistyp relative time event ausgewählt, erscheint ein Registersteuerelement mittels dessen die Ereignisspezifikation vorgenommen werden kann. Innerhalb des ersten Reiters SET MODIFICATION wurde bereits das Modifikationsereignis für Trigger tr_a spezifiziert. Zudem wurde für die Ausführungsgranularität FOR EACH ROW definiert. Dementsprechend erfolgt eine Generierung eines abgeleiteten absoluten Zeitereignistriggers für jede in die Tabelle tbl_a eingefügte Zeile. Transitionsvariablen können ebenso spezifiziert und anschließend im Bedingungsund Aktionsteil des Triggers verwendet werden. Die Werte der Transitionsvariablen werden während der Generierung des abgeleiteten Zeitereignistrigger im Bedingungs- und Aktionsteil ersetzt. Mit Hilfe des zweiten Reiters SET TIME OFFSET, der in Abbildung 7.2 dargestellt ist, werden der time offset, der relative Startzeitpunkt (relative time point) sowie die Ereignisparameter date und time für das Zeitereignis spezifiziert. In der Abbildung wurde bereits eine Zeitdauer von 30 min für den time offset definiert. Für die Spezifizierung des relativen Startzeitpunktes gibt es einerseits die Möglichkeit den Zeitpunkt des Eintritts des Modifikationsereignisses zu wählen ( MODIFICATION ) und andererseits sich auf einen Zeitpunkt zu beziehen, der sich innerhalb einer durch das Modifikationsereignis betroffenen Zeile befindet. Abhängig von der innerhalb des Modifikationsereignisses spezifizierten Basistabelle kann der Anwender neben MODIFICATION Spaltennamen dieser Basistabelle angeben. Diese Spalten müssen den Datentyp Datum besitzen. Für den Trigger tr_a wird der Zeitpunkt des Eintritts des Modifikationsereignisses als relativer Startzeitpunkt ausgewählt. Abbildung 7.3 zeigt ein weiteres Registersteuerelement mittels dessen die Bedingung, die Aktion und gegebenenfalls ein Kommentar für den Trigger eingegeben werden können. Es existiert ein Reiter für alle drei Konponenten eines Triggers. Zusätzlich kann über ein 85

89 7 Implementierung Abbildung 7.1: Triggereditor Abbildung 7.2: Reiter SET TIME OFFSET 86

90 7 Implementierung Befehlssteuerelement ein größeres Editierformular aufgerufen werden. Innerhalb des ersten Reiters ( WHEN ) wird bereits die Triggerbedingung für tr_a angezeigt. Mit dieser Bedingung kann vor Aktionsausführung eines von tr_a abgeleiteten Zeitereignistriggers geprüft werden, ob die eingefügte Zeile noch in der Datenbank enthalten ist, die ursprünglich zur Generierung des abgeleiteten Triggers geführt hat. Abbildung 7.3: Triggerbedingung von tr_a Mit Hilfe des zweiten Reiters ( DO ) kann die Aktion eines Triggers spezifiziert werden. Dieser Reiter wird in Abbildung 7.4 dargestellt. Die Aktion des Triggers tr_a führt eine Einfügung in die Tabelle tbl_b durch. Weiterhin kann mit dem dritten Reiter ( comment ) ein Kommentar für diesen Trigger angegeben werden. Beide Tabellen - tbl_a und tbl_b - besitzen drei Spalten. Der Tabelle tbl_a gehören die Spalte Spalte_A und die Spalte Termin an und die Tabelle tbl_b besitzt die Spalte Spalte_B und die Spalte intendierter_azp. Zusätzlich besitzen beide eine Spalte ID, die den Primärschlüssel der Tabellen darstellt und den Datentyp Autowert besitzt. Durch die Aktion des Triggers tr_a wird der Wert, der in Spalte_A von Tabelle tbl_a eingefügt wurde, in die Spalte_B von Tabelle tbl_b übernommen. Zusätzlich sollen Datum und Uhrzeit des intendierten Ausführungszeitpunkts des von tr_a abgeleiteten Zeitereignistrigger in die Spalte intendierter_azp der Tabelle tbl_b eingetragen werden. Mittels der Aktion und der Bedingung des Triggers tr_a soll gezeigt werden, dass die Ersetzung der Transitionsvariable (newrow) und der Ereignisparameter (date und time) korrekt erfolgt. Abbildung 7.4: Triggeraktion von tr_a 87

91 7 Implementierung Ein Trigger tr_b soll analog zu dem Trigger tr_a spezifiziert werden. Der Unterschied soll allein in der Definition des relativen Startzeitpunktes und der Priorität liegen. Während der Trigger tr_a den Zeitpunkt des Eintritts des Modifikationsereignisses referenziert, bezieht sich der Trigger tr_b bzgl. des relativen Startzeitpunktes auf den Zeitpunkt, der in die Spalte Termin der Tabelle tbl_a eingefügt wird. Der Trigger tr_b bekommt vom System die Priorität 2 zugewiesen, da dieser Trigger den zweiten spezifizierten Trigger im System darstellt. Beide Trigger generieren einen absoluten Zeitereignistrigger, für jede Zeile, die in die Tabelle tbl_a eingefügt wird. Abbildung 7.5 zeigt die Zeile, die in die Tabelle tbl_a eingefügt wurde. Die zugehörige Datenänderungsanweisung wurde im SQL-Statement-Formular am um 15:20 Uhr eingegeben. Abbildung 7.5: Tabelle tbl_a Nachdem die Einfügung in die Datenbank erfolgt ist, werden bezüglich tr_a sowie tr_b zwei abgeleitete absolute Zeitereignistrigger generiert. Wird das Optionsfeld rechts neben der Triggerübersicht aktiviert, werden die abgeleiteten Trigger sichtbar. Abbildung 7.6 zeigt das Triggerübersichtsformular mit den durch tr_a sowie tr_b abgeleiteten Triggern. Hierbei stellt der Trigger AbsoluteTrigger_tr_A_806 den abgeleiteten Trigger von tr_a dar. Die Einfügung in die Tabelle tbl_a fand am um 15:20 Uhr statt, demnach besitzt dieser Trigger mit einem time offset von 30 min den nächsten intendierten Ausführungszeitpunkt am um 15:50 Uhr. Hierbei werden die Ausführungszeitpunkte jeweils mit der Genauigkeit Minute bestimmt. Nachdem der Trigger AbsoluteTrigger_tr_A_806 im Triggerübersichtsformular markiert wurde, wird seine Spezifikation im unteren Teil des Triggerübersichtsformulars dargestellt. Ersichtlich ist, dass die Ereignisparameter date und time, die Deadline sowie die Bedingung und Aktion des Triggers tr_a übernommen wurden und die Transitionsvariable newrow durch ihre Werte im Bedingungs- sowie Aktionsteil ersetzt wurde. In der Triggerübersicht wird ebenso der von Trigger tr_b abgeleitete Trigger AbsoluteTrigger_tr_B_771 angezeigt. Dieser Trigger besitzt den nächsten Ausführungszeitpunkt am um 15:30 Uhr, da sich sein relativer Startzeitpunkt auf das in die Tabelle tbl_a eingefügte Datum bezieht (vgl. 7.5) und dieser Trigger einen time offset von 30 min besitzt. 88

92 7 Implementierung Abbildung 7.6: Triggerübersichtsformular 89

93 7 Implementierung Bereits in Abschnitt 7.2 wurde erwähnt, das die abgeleiteten Trigger die Priorität des zugehörigen relativen Zeitereignistriggers +1 erhalten. Wird der Trigger AbsoluteTrigger_tr_A_806 vor dem Trigger AbsoluteTrigger_tr_B_771 erstellt, erhält dieser Trigger die Priorität 2. Die Prioriät von tr_b wird daraufhin auf 3 angepasst. Der Trigger AbsoluteTrigger_tr_B_771 erhält darauf folgend Priorität 4. Auf diese Weise werden zwar die absoluten Prioritäten der Trigger modifiziert, jedoch die Zeitereignistrigger relativ zueinander in der vom Anwender gewünschten Reihenfolge ausgeführt im Falle der gleichzeitigen Aktivierung der abgeleiteten Zeitereignistrigger. Abbildung 7.7 zeigt die Einfügung in die Tabelle tbl_b, die infolge der Aktionsausführung von AbsoluteTrigger_tr_B_771 vorgenommen wurde. Zum Zeitpunkt des Eintritts des Zeitereignisses ( :30) ist das System ARTA II eingeschaltet und keine anderer Prozess im System aktiv. Aus diesem Grund ist die Deadline des Triggers AbsoluteTrigger_tr_B_771 nicht abgelaufen und die Triggerausführung kann erfolgen. Da der Eintrag in der Tabelle tbl_a nicht gelöscht wurde, kann die Bedingung von AbsoluteTrigger_tr_B_771 zu TRUE evaluiert und die Aktion ausgeführt werden. Abbildung 7.7 zeigt ebenso, dass die Werte für die Ereignisparameter date ( ) und time (15:30:00) in die Triggeraktion eingesetzt wurden. Abbildung 7.7: Tabelle tbl_b Abbildung 7.8 zeigt den Datenbankzustand von Tabelle tbl_b nach der Aktionsausführung von AbsoluteTrigger_tr_A_806. Analog zu Trigger AbsoluteTrigger_tr_B_771 kann gesehen werden, dass die Transitionsvariable und die Ereignisparameter in der Aktion korrekt eingesetzt wurden. Beide Trigger (AbsoluteTrigger_tr_A_806 und AbsoluteTrigger_tr_B_771) werden direkt nach ihrer Ausführung aus der Datenbank gelöscht. Hierbei wird die Priorität des Triggers tr_b wieder auf die ursprüngliche Priorität (2) gesetzt Trigger mit periodisch relativen Zeitereignisspezifikationen Dieser Abschnitt zeigt die Ausführung von zwei Triggern tr_c und tr_d mit periodisch relativer Zeitereignisspezifikation exemplarisch anhand von Screenshots (analog zum vor- 90

94 7 Implementierung Abbildung 7.8: Tabelle tbl_b hergehenden Abschnitt 7.5.1). Hierfür wurde eine neue Tabelle tbl_c angelegt, die in Abbildung 7.9 dargestellt ist. Abbildung 7.9: Tabelle tbl_c Neben dem Primärschlüssel ID enthält die Tabelle tbl_c drei weitere Spalten: intendierter_azp, tatsächlicher_azp und Triggername. Durch Ausführung eines vom Trigger tr_c oder tr_d abgeleiteten Triggers wird bei erfolgreicher Evaluierung der Triggerbedingung ein Eintrag in der Tabelle tbl_c vorgenommen. Hierbei werden der intendierte Ausführungszeitpunkt und der tatsächliche Ausführungszeitpunkt des Triggers in die Spalten intendierter_azp und tatsächlicher_azp eingetragen. Die Spalte Triggername enthält den Namen des relativen Zeitereignistriggers, der den abgeleiteten Zeitereignistrigger generiert hat. Da die Einträge in die Tabelle in der Reihenfolge vorgenommen werden, in der die Trigger ausgeführt werden, kann anhand der Tabelle tbl_c die Reihenfolge der Triggerausführung nachvollzogen werden. Anhand der Zustände dieser Tabelle nach Triggerausführung soll einerseits gezeigt werden, dass im Falle der simultanen Aktivierung zweier Trigger, der Trigger mit der höheren Priorität zuerst ausgeführt wird. Anderseits soll gezeigt werden, dass nachdem das System für eine Dauer von 30 Minuten ausgeschaltet war, die verzögerte Verarbeitung von aufgetretenen Zeitereignissen streng chronologisch verläuft. 91

95 7 Implementierung Die Trigger tr_c und tr_d wurden zunächst analog zu dem Trigger tr_a und dem Trigger tr_b definiert. Das Modifikationsereignis besteht aus einer Einfügung in die Tabelle tbl_a. Für den time offset wurde eine Zeitperiode von 30 min spezifiziert. Für die Definition der periodisch relativen Zeitereignisspezifikation besteht das Registersteuerelement für die Ereignisspezifikation aus einem dritten Reiter. Mit diesem dritten Reiter ( SET PERIOD ) wird die Periode spezifiziert, die die abgeleiteten periodischen Zeitereignistrigger erhalten sollen. Abbildung 7.10 zeigt den Reiter SET PERIOD. Die Seiten für die Spezifikation der unterschiedlichen Perioden wurden analog zu den Seiten für die periodische Zeitereignisspezifikation entworfen. Der Unterschied besteht in der zusätzlichen Möglichkeit ein weiteres Zeitintervall (relative time period) zu spezifizieren. Dieses Zeitintervall bildet die Länge des Gültigkeitsintervalls des abgeleiteten Zeitereignistriggers. Ein abgeleiteter periodischer Zeitereignistrigger von tr_d soll alle 10 Minuten aktiviert werden während ein abgeleiteter Trigger von tr_c nur alle 15 Minuten ausgeführt werden soll (vgl. Abbildung 7.10). Die abgeleiteten Zeitereignistrigger beider Trigger tr_c und tr_d sollen jeweils ein Gütigkeitsintervall von einer Stunde besitzen. Abbildung 7.10: Triggereditor Abbildung 7.11 zeigt das Triggerübersichtsformular. In dieser Abbildung ist ein vom Trigger tr_c abgeleiteter Trigger (PeriodicTrigger_tr_C_319) markiert, so dass dessen Spezifikation im Formular angezeigt wurde. Dieser Trigger und der Trigger PeriodicTrigger_tr_D_859 wurden generiert, nachdem eine Zeile in die Tabelle Tabelle tbl_a um 10:30 Uhr eingefügt wurde. Der erste Ausführungszeitpunkt beider Trigger ist demnach eine halbe Stunde später um 11:00 Uhr, wobei das Gültigkeitsintervall der beiden Trigger von 11:00 bis 12:00 Uhr andauert. Die Trigger tr_a und tr_b wurden deaktiviert, so dass für diese beiden Trigger nach der Einfügung in die Tabelle tbl_a keine abgeleiteten Zeitereignistrigger generiert wurden. Abbildung 7.12 zeigt die Tabelle tbl_c um kurz nach 11:00 Uhr. Der Eintrag ist durch die Aktionausführung von Trigger PeriodicTrigger_tr_D_859 entstanden. Zum Zeitpunkt des Eintritts des Zeitereignis war das System ARTA II eingeschaltet und keine anderen 92

96 7 Implementierung Abbildung 7.11: Triggerübersichtsformular 93

97 7 Implementierung Prozesse im System aktiv. Demnach stimmt der intendierte Ausführungszeitpunkt mit dem tatsächlichen Ausführungszeitpunkt des Triggers überein. Der Trigger PeriodicTrigger_tr_C_319 konnte nicht zur Ausführung gebracht werden, da die Bedingungsauswertung nicht erfolgreich war. Die Triggerbedingung besagt, dass die Aktion dieses Triggers nur für Zeitereignisse ausgeführt werden kann, die nach 11:10 Uhr auftreten (vgl. Triggerbedingung in Abbildung 7.11). Abbildung 7.12: Tabelle tbl_c Zum Zeitpunkt 11:25 Uhr sieht der Zustand der Tabelle tbl_c wie in Abbildung 7.13 aus. Zu den intendierten Ausführungszeitpunkten ist das System eingeschaltet und keine weiteren Prozesse sind im System aktiv, so dass bei beiden Triggern die intendierten Ausführungszeitpunkte mit den tatsächlichen Ausführungszeitpunkten übereinstimmen. Auch die Aktion des Triggers PeriodicTrigger_tr_C_319 konnte um 11:15 Uhr wegen erfolgreicher Bedingungsauswertung ausgeführt werden. Abbildung 7.13: Tabelle tbl_c Das System ARTA II wurde um 11:25 Uhr ausgeschaltet und um 11:55 Uhr wieder eingeschaltet. Die Abbildung 7.14 zeigt den Tabellenzustand von tbl_c um 11:56 Uhr. Hierbei stimmen bei den Triggern die intendierten Ausführungszeitpunkte nicht mehr mit den tatsächlichen Ausführungszeitpunkten überein. Beide Trigger wurden für die aufgetreten Zeitereignisse um 11:55 Uhr ausgeführt. Abbildung 7.14 zeigt, dass die aufgetretenen Zeitereignisse streng chronologisch verarbeitet und die Trigger in dieser Reihenfolge ausgeführt wurden. 94

98 7 Implementierung Abbildung 7.14: Tabelle tbl_c Der Trigger tr_c wurde vor dem Trigger tr_d definiert, so dass tr_c eine höhere Priorität besitzt als tr_d. Demnach sollen alle abgeleiteten Trigger von tr_c vor allen abgeleiteten Triggern von tr_d ausgeführt werden. Zum Zeitpunkt :30 wurden die Trigger PeriodicTrigger_tr_C_319 und PeriodicTrigger_tr_D_859 gleichzeitig aktiviert und der Trigger PeriodicTrigger_tr_C_319 vor dem Trigger PeriodicTrigger_tr_D_859 ausgeführt, vgl. Abbildung Abbildung 7.15 zeigt die Tabelle tbl_c kurz nach 12:00 Uhr. Beide Trigger wurden zum Zeitpunkt :00 nochmals simultan aktiviert. Zu diesem Zeitpunkt ist das System eingeschaltet und es sind keine anderen Prozesse im System aktiv, so dass intendierter und tatsächlicher Ausführungszeitpunkt bei beiden Triggern wieder übereinstimmen. Auch wenn das System eingeschaltet ist, erfolgt die Ausführung der Trigger in der richtigen Reihenfolge, so dass der von tr_c abgeleitete Trigger mit der höheren Priorität vor dem von tr_d abgeleiteten Trigger ausgeführt wird. 95

99 7 Implementierung Abbildung 7.15: Tabelle tbl_c 96

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem Fachbericht zum Thema: Anforderungen an ein Datenbanksystem von André Franken 1 Inhaltsverzeichnis 1 Inhaltsverzeichnis 1 2 Einführung 2 2.1 Gründe für den Einsatz von DB-Systemen 2 2.2 Definition: Datenbank

Mehr

Suche schlecht beschriftete Bilder mit Eigenen Abfragen

Suche schlecht beschriftete Bilder mit Eigenen Abfragen Suche schlecht beschriftete Bilder mit Eigenen Abfragen Ist die Bilderdatenbank über einen längeren Zeitraum in Benutzung, so steigt die Wahrscheinlichkeit für schlecht beschriftete Bilder 1. Insbesondere

Mehr

Universität Duisburg-Essen Informationssysteme Prof. Dr.-Ing. N. Fuhr. Praktikum Datenbanken / DB2 Woche 8: Trigger, SQL-PL

Universität Duisburg-Essen Informationssysteme Prof. Dr.-Ing. N. Fuhr. Praktikum Datenbanken / DB2 Woche 8: Trigger, SQL-PL Betreuer: Sascha Kriewel, Tobias Tuttas Raum: LF 230 Bearbeitung: 26., 27. und 29. Juni 2006 Datum Team (Account) Vorbereitung Präsenz Aktuelle Informationen, Ansprechpartner und Material unter: http://www.is.inf.uni-due.de/courses/dbp_ss07/index.html

Mehr

1 Mathematische Grundlagen

1 Mathematische Grundlagen Mathematische Grundlagen - 1-1 Mathematische Grundlagen Der Begriff der Menge ist einer der grundlegenden Begriffe in der Mathematik. Mengen dienen dazu, Dinge oder Objekte zu einer Einheit zusammenzufassen.

Mehr

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Dateiname: ecdl5_01_00_documentation_standard.doc Speicherdatum: 14.02.2005 ECDL 2003 Basic Modul 5 Datenbank - Grundlagen

Mehr

Gesicherte Prozeduren

Gesicherte Prozeduren Gesicherte Prozeduren Wenn eine Anwendung auf einer Client-Maschine läuft, wird normalerweise jede SQL-Anweisung einzeln vom Client an den Server gesandt, und jedes Ergebnistupel wird einzeln zurückgeliefert.

Mehr

Ablaufbeschreibung für das neu Aufsetzen von Firebird und Interbase Datenbanken mit der IBOConsole

Ablaufbeschreibung für das neu Aufsetzen von Firebird und Interbase Datenbanken mit der IBOConsole Lavid-F.I.S. Ablaufbeschreibung für das neu Aufsetzen von Firebird und Interbase Datenbanken mit der Lavid Software GmbH Dauner Straße 12, D-41236 Mönchengladbach http://www.lavid-software.net Support:

Mehr

Kapitel 10 Aktive DBMS

Kapitel 10 Aktive DBMS Kapitel 10 Aktive DBMS 10 Aktive DBMS 10 Aktive DBMS...1 10.1 Einführung und Definition...2 10.2 Funktionsprinzip: ADBMS und ECA-Modell...4 10.3 Potentiale und Vorteile ADBMS...5 10.4 Aktive Elemente einer

Mehr

etutor Benutzerhandbuch XQuery Benutzerhandbuch Georg Nitsche

etutor Benutzerhandbuch XQuery Benutzerhandbuch Georg Nitsche etutor Benutzerhandbuch Benutzerhandbuch XQuery Georg Nitsche Version 1.0 Stand März 2006 Versionsverlauf: Version Autor Datum Änderungen 1.0 gn 06.03.2006 Fertigstellung der ersten Version Inhaltsverzeichnis:

Mehr

Die Beschreibung bezieht sich auf die Version Dreamweaver 4.0. In der Version MX ist die Sitedefinition leicht geändert worden.

Die Beschreibung bezieht sich auf die Version Dreamweaver 4.0. In der Version MX ist die Sitedefinition leicht geändert worden. In einer Website haben Seiten oft das gleiche Layout. Speziell beim Einsatz von Tabellen, in denen die Navigation auf der linken oder rechten Seite, oben oder unten eingesetzt wird. Diese Anteile der Website

Mehr

FastBill Automatic. Dokumentation Versand. FastBill GmbH. Holteyer Straße 30 45289 Essen Telefon 0201 47091505 Telefax 0201 54502360

FastBill Automatic. Dokumentation Versand. FastBill GmbH. Holteyer Straße 30 45289 Essen Telefon 0201 47091505 Telefax 0201 54502360 FastBill GmbH Holteyer Straße 30 45289 Essen Telefon 0201 47091505 Telefax 0201 54502360 FastBill Automatic Dokumentation Versand 1 Inhaltsverzeichnis: 1. Grundlegendes 2. Produkteinstellungen 2.1. Grundeinstellungen

Mehr

Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements. von Stephanie Wilke am 14.08.08

Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements. von Stephanie Wilke am 14.08.08 Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements von Stephanie Wilke am 14.08.08 Überblick Einleitung Was ist ITIL? Gegenüberstellung der Prozesse Neuer

Mehr

Modul 2: Automatisierung des Posteingangs - Regel- und Abwesenheits-Assistent

Modul 2: Automatisierung des Posteingangs - Regel- und Abwesenheits-Assistent Outlook 2003 - Aufbaukurs 19 Modul 2: Automatisierung des Posteingangs - Regel- und Abwesenheits-Assistent Wie kann ich die Bearbeitung von Nachrichten automatisieren? Wie kann ich Nachrichten automatisch

Mehr

Use Cases. Use Cases

Use Cases. Use Cases Use Cases Eigenschaften: Ein Use Case beschreibt einen Teil des Verhaltens eines Systems aus externer Sicht (Formuliert in der der Fachsprache der Anwendung) Dies geschieht, indem ein Systemdialog beschrieben

Mehr

Lineargleichungssysteme: Additions-/ Subtraktionsverfahren

Lineargleichungssysteme: Additions-/ Subtraktionsverfahren Lineargleichungssysteme: Additions-/ Subtraktionsverfahren W. Kippels 22. Februar 2014 Inhaltsverzeichnis 1 Einleitung 2 2 Lineargleichungssysteme zweiten Grades 2 3 Lineargleichungssysteme höheren als

Mehr

SQL: statische Integrität

SQL: statische Integrität SQL: statische Integrität.1 SQL: statische Integrität Im allgemeinen sind nur solche Instanzen einer Datenbank erlaubt, deren Relationen die der Datenbank bekannten Integritätsbedingungen erfüllen. Integritätsbedingungen

Mehr

1. Man schreibe die folgenden Aussagen jeweils in einen normalen Satz um. Zum Beispiel kann man die Aussage:

1. Man schreibe die folgenden Aussagen jeweils in einen normalen Satz um. Zum Beispiel kann man die Aussage: Zählen und Zahlbereiche Übungsblatt 1 1. Man schreibe die folgenden Aussagen jeweils in einen normalen Satz um. Zum Beispiel kann man die Aussage: Für alle m, n N gilt m + n = n + m. in den Satz umschreiben:

Mehr

Leitfaden #1a. "zanox Publisher-Statistik" (next generation)

Leitfaden #1a. zanox Publisher-Statistik (next generation) Leitfaden #1a "zanox Publisher-Statistik" (next generation) Thema: Sortieren von Leads und Sales nach dem Bearbeitungsdatum (inklusive Abschnitt "Filterung nach Transaktionsstatus") 1/8 Leitfaden "Sortieren

Mehr

Codex Newsletter. Allgemeines. Codex Newsletter

Codex Newsletter. Allgemeines. Codex Newsletter Newsletter Newsletter Dezember 05 Seite 1 Allgemeines Newsletter Mit diesem Rundschreiben (Newsletter) wollen wir Sie in ca. zweimonatigen Abständen per Mail über Neuerungen in unseren Programmen informieren.

Mehr

Datensicherung. Beschreibung der Datensicherung

Datensicherung. Beschreibung der Datensicherung Datensicherung Mit dem Datensicherungsprogramm können Sie Ihre persönlichen Daten problemlos Sichern. Es ist möglich eine komplette Datensicherung durchzuführen, aber auch nur die neuen und geänderten

Mehr

1 topologisches Sortieren

1 topologisches Sortieren Wolfgang Hönig / Andreas Ecke WS 09/0 topologisches Sortieren. Überblick. Solange noch Knoten vorhanden: a) Suche Knoten v, zu dem keine Kante führt (Falls nicht vorhanden keine topologische Sortierung

Mehr

5.2 Neue Projekte erstellen

5.2 Neue Projekte erstellen 5.2 Neue Projekte erstellen Das Bearbeiten von bestehenden Projekten und Objekten ist ja nicht schlecht wie aber können Sie neue Objekte hinzufügen oder gar völlig neue Projekte erstellen? Die Antwort

Mehr

Anwenderdokumentation AccountPlus GWUPSTAT.EXE

Anwenderdokumentation AccountPlus GWUPSTAT.EXE AccountPlus Inhaltsverzeichnis Inhaltsverzeichnis Anwenderdokumentation AccountPlus GWUPSTAT.EXE (vorläufig) ab Version 6.01 INHALTSVERZEICHNIS...1 1 ALLGEMEINES...2 2 INSTALLATION UND PROGRAMMAUFRUF...2

Mehr

3. Stored Procedures und PL/SQL

3. Stored Procedures und PL/SQL 3. Stored Procedures und PL/SQL Wenn eine Anwendung auf einer Client-Maschine läuft, wird normalerweise jede SQL-Anweisung einzeln vom Client an den Server gesandt, und jedes Ergebnistupel wird einzeln

Mehr

Lizenzierung von System Center 2012

Lizenzierung von System Center 2012 Lizenzierung von System Center 2012 Mit den Microsoft System Center-Produkten lassen sich Endgeräte wie Server, Clients und mobile Geräte mit unterschiedlichen Betriebssystemen verwalten. Verwalten im

Mehr

Seite 1 von 14. Cookie-Einstellungen verschiedener Browser

Seite 1 von 14. Cookie-Einstellungen verschiedener Browser Seite 1 von 14 Cookie-Einstellungen verschiedener Browser Cookie-Einstellungen verschiedener Browser, 7. Dezember 2015 Inhaltsverzeichnis 1.Aktivierung von Cookies... 3 2.Cookies... 3 2.1.Wofu r braucht

Mehr

Einfache und effiziente Zusammenarbeit in der Cloud. EASY-PM Office Add-Ins Handbuch

Einfache und effiziente Zusammenarbeit in der Cloud. EASY-PM Office Add-Ins Handbuch Einfache und effiziente Zusammenarbeit in der Cloud EASY-PM Office Add-Ins Handbuch Inhaltsverzeichnis 1. Einführung... 3 2. Ribbonmenü... 4 3. Dokument... 5 3.1 Öffnen... 5 3.2 Speichern... 6 3.3 Speichern

Mehr

Abamsoft Finos im Zusammenspiel mit shop to date von DATA BECKER

Abamsoft Finos im Zusammenspiel mit shop to date von DATA BECKER Abamsoft Finos im Zusammenspiel mit shop to date von DATA BECKER Abamsoft Finos in Verbindung mit der Webshopanbindung wurde speziell auf die Shop-Software shop to date von DATA BECKER abgestimmt. Mit

Mehr

Programmiersprachen und Übersetzer

Programmiersprachen und Übersetzer Programmiersprachen und Übersetzer Sommersemester 2010 19. April 2010 Theoretische Grundlagen Problem Wie kann man eine unendliche Menge von (syntaktisch) korrekten Programmen definieren? Lösung Wie auch

Mehr

Kurzeinführung LABTALK

Kurzeinführung LABTALK Kurzeinführung LABTALK Mit der Interpreter-Sprache LabTalk, die von ORIGIN zur Verfügung gestellt wird, können bequem Datenmanipulationen sowie Zugriffe direkt auf das Programm (Veränderungen der Oberfläche,

Mehr

Data Mining: Einige Grundlagen aus der Stochastik

Data Mining: Einige Grundlagen aus der Stochastik Data Mining: Einige Grundlagen aus der Stochastik Hagen Knaf Studiengang Angewandte Mathematik Hochschule RheinMain 21. Oktober 2015 Vorwort Das vorliegende Skript enthält eine Zusammenfassung verschiedener

Mehr

BUILDNOTES TOPAL FINANZBUCHHALTUNG

BUILDNOTES TOPAL FINANZBUCHHALTUNG BUILDNOTES TOPAL FINANZBUCHHALTUNG VERSION 7.5.11.0 Inhaltsverzeichnis 1. EINFÜHRUNG... 2 1.1. Zweck... 2 1.2. Neuerungen... 2 1.2.1. Import... 2 1.2.2. Importvorlagen... 3 1.2.3. Sicherheitseinstellungen...

Mehr

Task: Nmap Skripte ausführen

Task: Nmap Skripte ausführen Task: Nmap Skripte ausführen Inhalt Einfache Netzwerkscans mit NSE Ausführen des Scans Anpassung der Parameter Einleitung Copyright 2009-2015 Greenbone Networks GmbH Herkunft und aktuellste Version dieses

Mehr

Anti-Botnet-Beratungszentrum. Windows XP in fünf Schritten absichern

Anti-Botnet-Beratungszentrum. Windows XP in fünf Schritten absichern Windows XP in fünf Schritten absichern Inhalt: 1. Firewall Aktivierung 2. Anwendung eines Anti-Virus Scanner 3. Aktivierung der automatischen Updates 4. Erstellen eines Backup 5. Setzen von sicheren Passwörtern

Mehr

SharePoint Demonstration

SharePoint Demonstration SharePoint Demonstration Was zeigt die Demonstration? Diese Demonstration soll den modernen Zugriff auf Daten und Informationen veranschaulichen und zeigen welche Vorteile sich dadurch in der Zusammenarbeit

Mehr

Ist Excel das richtige Tool für FMEA? Steve Murphy, Marc Schaeffers

Ist Excel das richtige Tool für FMEA? Steve Murphy, Marc Schaeffers Ist Excel das richtige Tool für FMEA? Steve Murphy, Marc Schaeffers Ist Excel das richtige Tool für FMEA? Einleitung Wenn in einem Unternehmen FMEA eingeführt wird, fangen die meisten sofort damit an,

Mehr

SDD System Design Document

SDD System Design Document SDD Software Konstruktion WS01/02 Gruppe 4 1. Einleitung Das vorliegende Dokument richtet sich vor allem an die Entwickler, aber auch an den Kunden, der das enstehende System verwenden wird. Es soll einen

Mehr

Upgrade auf die Standalone Editionen von Acronis Backup & Recovery 10. Technische Informationen (White Paper)

Upgrade auf die Standalone Editionen von Acronis Backup & Recovery 10. Technische Informationen (White Paper) Upgrade auf die Standalone Editionen von Acronis Backup & Recovery 10 Technische Informationen (White Paper) Inhaltsverzeichnis 1. Über dieses Dokument... 3 2. Überblick... 3 3. Upgrade Verfahren... 4

Mehr

IBIS Professional. z Dokumentation zur Dublettenprüfung

IBIS Professional. z Dokumentation zur Dublettenprüfung z Dokumentation zur Dublettenprüfung Die Dublettenprüfung ist ein Zusatzpaket zur IBIS-Shopverwaltung für die Classic Line 3.4 und höher. Dubletten entstehen dadurch, dass viele Kunden beim Bestellvorgang

Mehr

2.11 Kontextfreie Grammatiken und Parsebäume

2.11 Kontextfreie Grammatiken und Parsebäume 2.11 Kontextfreie Grammatiken und Parsebäume Beispiel: Beispiel (Teil 3): Beweis für L(G) L: Alle Strings aus L der Länge 0 und 2 sind auch in L(G). Als Induktionsannahme gehen wir davon aus, dass alle

Mehr

Dynamisches SQL. Folien zum Datenbankpraktikum Wintersemester 2009/10 LMU München

Dynamisches SQL. Folien zum Datenbankpraktikum Wintersemester 2009/10 LMU München Kapitel 4 Dynamisches SQL Folien zum Datenbankpraktikum Wintersemester 2009/10 LMU München 2008 Thomas Bernecker, Tobias Emrich unter Verwendung der Folien des Datenbankpraktikums aus dem Wintersemester

Mehr

Mengenvergleiche: Alle Konten außer das, mit dem größten Saldo.

Mengenvergleiche: Alle Konten außer das, mit dem größten Saldo. Mengenvergleiche: Mehr Möglichkeiten als der in-operator bietet der θany und der θall-operator, also der Vergleich mit irgendeinem oder jedem Tupel der Unteranfrage. Alle Konten außer das, mit dem größten

Mehr

OP-LOG www.op-log.de

OP-LOG www.op-log.de Verwendung von Microsoft SQL Server, Seite 1/18 OP-LOG www.op-log.de Anleitung: Verwendung von Microsoft SQL Server 2005 Stand Mai 2010 1 Ich-lese-keine-Anleitungen 'Verwendung von Microsoft SQL Server

Mehr

Wie wird ein Jahreswechsel (vorläufig und endgültig) ausgeführt?

Wie wird ein Jahreswechsel (vorläufig und endgültig) ausgeführt? Wie wird ein (vorläufig und endgültig) ausgeführt? VORLÄUFIGER JAHRESWECHSEL Führen Sie unbedingt vor dem eine aktuelle Datensicherung durch. Einleitung Ein vorläufiger Jahresabschluss wird durchgeführt,

Mehr

SANDBOXIE konfigurieren

SANDBOXIE konfigurieren SANDBOXIE konfigurieren für Webbrowser und E-Mail-Programme Dies ist eine kurze Anleitung für die grundlegenden folgender Programme: Webbrowser: Internet Explorer, Mozilla Firefox und Opera E-Mail-Programme:

Mehr

Microsoft PowerPoint 2013 Folien gemeinsam nutzen

Microsoft PowerPoint 2013 Folien gemeinsam nutzen Hochschulrechenzentrum Justus-Liebig-Universität Gießen Microsoft PowerPoint 2013 Folien gemeinsam nutzen Folien gemeinsam nutzen in PowerPoint 2013 Seite 1 von 4 Inhaltsverzeichnis Einleitung... 2 Einzelne

Mehr

Second Steps in eport 2.0 So ordern Sie Credits und Berichte

Second Steps in eport 2.0 So ordern Sie Credits und Berichte Second Steps in eport 2.0 So ordern Sie Credits und Berichte Schritt 1: Credits kaufen, um Zugangscodes generieren zu können Wählen Sie Credits verwalten und klicken Sie auf Credits kaufen. Geben Sie nun

Mehr

Integration mit. Wie AristaFlow Sie in Ihrem Unternehmen unterstützen kann, zeigen wir Ihnen am nachfolgenden Beispiel einer Support-Anfrage.

Integration mit. Wie AristaFlow Sie in Ihrem Unternehmen unterstützen kann, zeigen wir Ihnen am nachfolgenden Beispiel einer Support-Anfrage. Integration mit Die Integration der AristaFlow Business Process Management Suite (BPM) mit dem Enterprise Information Management System FILERO (EIMS) bildet die optimale Basis für flexible Optimierung

Mehr

Kostenstellen verwalten. Tipps & Tricks

Kostenstellen verwalten. Tipps & Tricks Tipps & Tricks INHALT SEITE 1.1 Kostenstellen erstellen 3 13 1.3 Zugriffsberechtigungen überprüfen 30 2 1.1 Kostenstellen erstellen Mein Profil 3 1.1 Kostenstellen erstellen Kostenstelle(n) verwalten 4

Mehr

4. BEZIEHUNGEN ZWISCHEN TABELLEN

4. BEZIEHUNGEN ZWISCHEN TABELLEN 4. BEZIEHUNGEN ZWISCHEN TABELLEN Zwischen Tabellen können in MS Access Beziehungen bestehen. Durch das Verwenden von Tabellen, die zueinander in Beziehung stehen, können Sie Folgendes erreichen: Die Größe

Mehr

AZK 1- Freistil. Der Dialog "Arbeitszeitkonten" Grundsätzliches zum Dialog "Arbeitszeitkonten"

AZK 1- Freistil. Der Dialog Arbeitszeitkonten Grundsätzliches zum Dialog Arbeitszeitkonten AZK 1- Freistil Nur bei Bedarf werden dafür gekennzeichnete Lohnbestandteile (Stundenzahl und Stundensatz) zwischen dem aktuellen Bruttolohnjournal und dem AZK ausgetauscht. Das Ansparen und das Auszahlen

Mehr

Grammatiken. Einführung

Grammatiken. Einführung Einführung Beispiel: Die arithmetischen Ausdrücke über der Variablen a und den Operationen + und können wie folgt definiert werden: a, a + a und a a sind arithmetische Ausdrücke Wenn A und B arithmetische

Mehr

Informatik 12 Datenbanken SQL-Einführung

Informatik 12 Datenbanken SQL-Einführung Informatik 12 Datenbanken SQL-Einführung Gierhardt Vorbemerkungen Bisher haben wir Datenbanken nur über einzelne Tabellen kennen gelernt. Stehen mehrere Tabellen in gewissen Beziehungen zur Beschreibung

Mehr

.htaccess HOWTO. zum Schutz von Dateien und Verzeichnissen mittels Passwortabfrage

.htaccess HOWTO. zum Schutz von Dateien und Verzeichnissen mittels Passwortabfrage .htaccess HOWTO zum Schutz von Dateien und Verzeichnissen mittels Passwortabfrage Stand: 21.06.2015 Inhaltsverzeichnis 1. Vorwort...3 2. Verwendung...4 2.1 Allgemeines...4 2.1 Das Aussehen der.htaccess

Mehr

Durchführung der Datenübernahme nach Reisekosten 2011

Durchführung der Datenübernahme nach Reisekosten 2011 Durchführung der Datenübernahme nach Reisekosten 2011 1. Starten Sie QuickSteuer Deluxe 2010. Rufen Sie anschließend über den Menüpunkt /Extras/Reisekosten Rechner den QuickSteuer Deluxe 2010 Reisekosten-Rechner,

Mehr

Artikel Schnittstelle über CSV

Artikel Schnittstelle über CSV Artikel Schnittstelle über CSV Sie können Artikeldaten aus Ihrem EDV System in das NCFOX importieren, dies geschieht durch eine CSV Schnittstelle. Dies hat mehrere Vorteile: Zeitersparnis, die Karteikarte

Mehr

Handbuch Fischertechnik-Einzelteiltabelle V3.7.3

Handbuch Fischertechnik-Einzelteiltabelle V3.7.3 Handbuch Fischertechnik-Einzelteiltabelle V3.7.3 von Markus Mack Stand: Samstag, 17. April 2004 Inhaltsverzeichnis 1. Systemvorraussetzungen...3 2. Installation und Start...3 3. Anpassen der Tabelle...3

Mehr

Anwendungshinweise zur Anwendung der Soziometrie

Anwendungshinweise zur Anwendung der Soziometrie Anwendungshinweise zur Anwendung der Soziometrie Einführung Die Soziometrie ist ein Verfahren, welches sich besonders gut dafür eignet, Beziehungen zwischen Mitgliedern einer Gruppe darzustellen. Das Verfahren

Mehr

Benutzerverwaltung Business- & Company-Paket

Benutzerverwaltung Business- & Company-Paket Benutzerverwaltung Business- & Company-Paket Gemeinsames Arbeiten mit der easyfeedback Umfragesoftware. Inhaltsübersicht Freischaltung des Business- oder Company-Paketes... 3 Benutzerverwaltung Business-Paket...

Mehr

1. Einschränkung für Mac-User ohne Office 365. 2. Dokumente hochladen, teilen und bearbeiten

1. Einschränkung für Mac-User ohne Office 365. 2. Dokumente hochladen, teilen und bearbeiten 1. Einschränkung für Mac-User ohne Office 365 Mac-User ohne Office 365 müssen die Dateien herunterladen; sie können die Dateien nicht direkt öffnen und bearbeiten. Wenn die Datei heruntergeladen wurde,

Mehr

Excel Pivot-Tabellen 2010 effektiv

Excel Pivot-Tabellen 2010 effektiv 7.2 Berechnete Felder Falls in der Datenquelle die Zahlen nicht in der Form vorliegen wie Sie diese benötigen, können Sie die gewünschten Ergebnisse mit Formeln berechnen. Dazu erzeugen Sie ein berechnetes

Mehr

Corporate Actions in epoca

Corporate Actions in epoca in epoca Einführung Die können in Bezug auf die Buchhaltung zu den komplexesten und anspruchsvollsten Transaktionen gehören. Sie können den Transfer eines Teils oder des ganzen Buchwerts einer Position

Mehr

2 Die Terminaldienste Prüfungsanforderungen von Microsoft: Lernziele:

2 Die Terminaldienste Prüfungsanforderungen von Microsoft: Lernziele: 2 Die Terminaldienste Prüfungsanforderungen von Microsoft: Configuring Terminal Services o Configure Windows Server 2008 Terminal Services RemoteApp (TS RemoteApp) o Configure Terminal Services Gateway

Mehr

AnNoText. AnNoText Online-Update. Copyright Wolters Kluwer Deutschland GmbH

AnNoText. AnNoText Online-Update. Copyright Wolters Kluwer Deutschland GmbH Copyright Wolters Kluwer Deutschland GmbH AnNoText AnNoText Online-Update Wolters Kluwer Deutschland GmbH Software + Services Legal Robert-Bosch-Straße 6 D-50354 Hürth Telefon (02 21) 9 43 73-6000 Telefax

Mehr

Barrierefreie Webseiten erstellen mit TYPO3

Barrierefreie Webseiten erstellen mit TYPO3 Barrierefreie Webseiten erstellen mit TYPO3 Alternativtexte Für jedes Nicht-Text-Element ist ein äquivalenter Text bereitzustellen. Dies gilt insbesondere für Bilder. In der Liste der HTML 4-Attribute

Mehr

Web-Kürzel. Krishna Tateneni Yves Arrouye Deutsche Übersetzung: Stefan Winter

Web-Kürzel. Krishna Tateneni Yves Arrouye Deutsche Übersetzung: Stefan Winter Krishna Tateneni Yves Arrouye Deutsche Übersetzung: Stefan Winter 2 Inhaltsverzeichnis 1 Web-Kürzel 4 1.1 Einführung.......................................... 4 1.2 Web-Kürzel.........................................

Mehr

Hilfedatei der Oden$-Börse Stand Juni 2014

Hilfedatei der Oden$-Börse Stand Juni 2014 Hilfedatei der Oden$-Börse Stand Juni 2014 Inhalt 1. Einleitung... 2 2. Die Anmeldung... 2 2.1 Die Erstregistrierung... 3 2.2 Die Mitgliedsnummer anfordern... 4 3. Die Funktionen für Nutzer... 5 3.1 Arbeiten

Mehr

geben. Die Wahrscheinlichkeit von 100% ist hier demnach nur der Gehen wir einmal davon aus, dass die von uns angenommenen

geben. Die Wahrscheinlichkeit von 100% ist hier demnach nur der Gehen wir einmal davon aus, dass die von uns angenommenen geben. Die Wahrscheinlichkeit von 100% ist hier demnach nur der Vollständigkeit halber aufgeführt. Gehen wir einmal davon aus, dass die von uns angenommenen 70% im Beispiel exakt berechnet sind. Was würde

Mehr

EasyWk DAS Schwimmwettkampfprogramm

EasyWk DAS Schwimmwettkampfprogramm EasyWk DAS Schwimmwettkampfprogramm Arbeiten mit OMEGA ARES 21 EasyWk - DAS Schwimmwettkampfprogramm 1 Einleitung Diese Präsentation dient zur Darstellung der Zusammenarbeit zwischen EasyWk und der Zeitmessanlage

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

Urlaubsregel in David

Urlaubsregel in David Urlaubsregel in David Inhaltsverzeichnis KlickDown Beitrag von Tobit...3 Präambel...3 Benachrichtigung externer Absender...3 Erstellen oder Anpassen des Anworttextes...3 Erstellen oder Anpassen der Auto-Reply-Regel...5

Mehr

Java Kurs für Anfänger Einheit 4 Klassen und Objekte

Java Kurs für Anfänger Einheit 4 Klassen und Objekte Java Kurs für Anfänger Einheit 4 Klassen und Ludwig-Maximilians-Universität München (Institut für Informatik: Programmierung und Softwaretechnik von Prof.Wirsing) 13. Juni 2009 Inhaltsverzeichnis klasse

Mehr

6. Datenintegrität. Integritätsbedingungen

6. Datenintegrität. Integritätsbedingungen 6. Integritätsbedingungen dienen zur Einschränkung der Datenbankzustände auf diejenigen, die es in der realen Welt tatsächlich gibt. sind aus dem erstellten Datenmodell ableitbar (semantisch) und können

Mehr

Neues Modul für individuelle Anlagen. Änderung bei den Postleitzahl-Mutationen

Neues Modul für individuelle Anlagen. Änderung bei den Postleitzahl-Mutationen NEWSLETTER APRIL 2015 Neues Modul für individuelle Anlagen Die LESS Informatik hat in Zusammenarbeit mit einem Kunden die Umsetzung des neuen Moduls 1e für die Anwendung von individuelle Anlagen in Angriff

Mehr

Motivation. Formale Grundlagen der Informatik 1 Kapitel 5 Kontextfreie Sprachen. Informales Beispiel. Informales Beispiel.

Motivation. Formale Grundlagen der Informatik 1 Kapitel 5 Kontextfreie Sprachen. Informales Beispiel. Informales Beispiel. Kontextfreie Kontextfreie Motivation Formale rundlagen der Informatik 1 Kapitel 5 Kontextfreie Sprachen Bisher hatten wir Automaten, die Wörter akzeptieren Frank Heitmann heitmann@informatik.uni-hamburg.de

Mehr

Anleitung E-Mail - Archivierung

Anleitung E-Mail - Archivierung Anleitung E-Mail - Archivierung Aufgrund unserer langjährigen Erfahrung, wissen wir um viele Kundenprobleme in der Bedienung von IKT-Produkten. Um solche Probleme bei der Nutzung der Net4You Produkte zu

Mehr

2.5.2 Primärschlüssel

2.5.2 Primärschlüssel Relationale Datenbanken 0110 01101110 01110 0110 0110 0110 01101 011 01110 0110 010 011011011 0110 01111010 01101 011011 0110 01 01110 011011101 01101 0110 010 010 0110 011011101 0101 0110 010 010 01 01101110

Mehr

Nachricht der Kundenbetreuung

Nachricht der Kundenbetreuung Cisco WebEx: Service-Pack vom [[DATE]] für [[WEBEXURL]] Sehr geehrter Cisco WebEx-Kunde, Cisco WebEx sendet diese Mitteilung an wichtige Geschäftskontakte unter https://[[webexurl]]. Ab Samstag, 1. November

Mehr

AGROPLUS Buchhaltung. Daten-Server und Sicherheitskopie. Version vom 21.10.2013b

AGROPLUS Buchhaltung. Daten-Server und Sicherheitskopie. Version vom 21.10.2013b AGROPLUS Buchhaltung Daten-Server und Sicherheitskopie Version vom 21.10.2013b 3a) Der Daten-Server Modus und der Tresor Der Daten-Server ist eine Betriebsart welche dem Nutzer eine grosse Flexibilität

Mehr

TECHNISCHE INFORMATION LESSOR LOHN/GEHALT BEITRAGSNACHWEIS-AUSGLEICH BUCH.-BLATT MICROSOFT DYNAMICS NAV

TECHNISCHE INFORMATION LESSOR LOHN/GEHALT BEITRAGSNACHWEIS-AUSGLEICH BUCH.-BLATT MICROSOFT DYNAMICS NAV MICROSOFT DYNAMICS NAV Inhaltsverzeichnis TECHNISCHE INFORMATION: Einleitung... 3 LESSOR LOHN/GEHALT Beschreibung... 3 Prüfung der Ausgleichszeilen... 9 Zurücksetzen der Ausgleichsroutine... 12 Vorgehensweise

Mehr

Objektorientierte Programmierung

Objektorientierte Programmierung Objektorientierte Programmierung 1 Geschichte Dahl, Nygaard: Simula 67 (Algol 60 + Objektorientierung) Kay et al.: Smalltalk (erste rein-objektorientierte Sprache) Object Pascal, Objective C, C++ (wiederum

Mehr

pro4controlling - Whitepaper [DEU] Whitepaper zur CfMD-Lösung pro4controlling Seite 1 von 9

pro4controlling - Whitepaper [DEU] Whitepaper zur CfMD-Lösung pro4controlling Seite 1 von 9 Whitepaper zur CfMD-Lösung pro4controlling Seite 1 von 9 1 Allgemeine Beschreibung "Was war geplant, wo stehen Sie jetzt und wie könnte es noch werden?" Das sind die typischen Fragen, mit denen viele Unternehmer

Mehr

How to do? Projekte - Zeiterfassung

How to do? Projekte - Zeiterfassung How to do? Projekte - Zeiterfassung Stand: Version 4.0.1, 18.03.2009 1. EINLEITUNG...3 2. PROJEKTE UND STAMMDATEN...4 2.1 Projekte... 4 2.2 Projektmitarbeiter... 5 2.3 Tätigkeiten... 6 2.4 Unterprojekte...

Mehr

In diesem Tutorial lernen Sie, wie Sie einen Termin erfassen und verschiedene Einstellungen zu einem Termin vornehmen können.

In diesem Tutorial lernen Sie, wie Sie einen Termin erfassen und verschiedene Einstellungen zu einem Termin vornehmen können. Tutorial: Wie erfasse ich einen Termin? In diesem Tutorial lernen Sie, wie Sie einen Termin erfassen und verschiedene Einstellungen zu einem Termin vornehmen können. Neben den allgemeinen Angaben zu einem

Mehr

HANDBUCH ÜBERNAHME BANKLEITZAHLEN

HANDBUCH ÜBERNAHME BANKLEITZAHLEN HANDBUCH ÜBERNAHME BANKLEITZAHLEN KIGST-GMBH SYSTEMHAUS MIT TRADITION UND INNOVATION STAND: AUGUST 2010 KIGST GmbH 2010 Seite 1 von 13 Inhalt Inhalt... 2 Allgemeine Hinweise... 3 Grundlegendes... 4 Bankleitzahlen

Mehr

50. Mathematik-Olympiade 2. Stufe (Regionalrunde) Klasse 11 13. 501322 Lösung 10 Punkte

50. Mathematik-Olympiade 2. Stufe (Regionalrunde) Klasse 11 13. 501322 Lösung 10 Punkte 50. Mathematik-Olympiade. Stufe (Regionalrunde) Klasse 3 Lösungen c 00 Aufgabenausschuss des Mathematik-Olympiaden e.v. www.mathematik-olympiaden.de. Alle Rechte vorbehalten. 503 Lösung 0 Punkte Es seien

Mehr

4. Jeder Knoten hat höchstens zwei Kinder, ein linkes und ein rechtes.

4. Jeder Knoten hat höchstens zwei Kinder, ein linkes und ein rechtes. Binäre Bäume Definition: Ein binärer Baum T besteht aus einer Menge von Knoten, die durch eine Vater-Kind-Beziehung wie folgt strukturiert ist: 1. Es gibt genau einen hervorgehobenen Knoten r T, die Wurzel

Mehr

Zur Konfiguration werden hierbei das Setup-Tool und die Shell verwendet.

Zur Konfiguration werden hierbei das Setup-Tool und die Shell verwendet. 1. Konfiguration von Event Scheduler 1.1 Einleitung Im Folgenden wird die Konfiguration von Event Scheduler beschrieben. Sie erlauben den Zugriff auf das Internet werktags von 8-17:00 Uhr. Da Sie eine

Mehr

Tapps mit XP-Mode unter Windows 7 64 bit (V2.0)

Tapps mit XP-Mode unter Windows 7 64 bit (V2.0) Tapps mit XP-Mode unter Windows 7 64 bit (V2.0) 1 Einleitung... 2 2 Download und Installation... 3 2.1 Installation von WindowsXPMode_de-de.exe... 4 2.2 Installation von Windows6.1-KB958559-x64.msu...

Mehr

Bedienungsanleitung. Matthias Haasler. Version 0.4. für die Arbeit mit der Gemeinde-Homepage der Paulus-Kirchengemeinde Tempelhof

Bedienungsanleitung. Matthias Haasler. Version 0.4. für die Arbeit mit der Gemeinde-Homepage der Paulus-Kirchengemeinde Tempelhof Bedienungsanleitung für die Arbeit mit der Gemeinde-Homepage der Paulus-Kirchengemeinde Tempelhof Matthias Haasler Version 0.4 Webadministrator, email: webadmin@rundkirche.de Inhaltsverzeichnis 1 Einführung

Mehr

Inventur. Bemerkung. / Inventur

Inventur. Bemerkung. / Inventur Inventur Die beliebige Aufteilung des Artikelstamms nach Artikeln, Lieferanten, Warengruppen, Lagerorten, etc. ermöglicht es Ihnen, Ihre Inventur in mehreren Abschnitten durchzuführen. Bemerkung Zwischen

Mehr

GEORG.NET Anbindung an Ihr ACTIVE-DIRECTORY

GEORG.NET Anbindung an Ihr ACTIVE-DIRECTORY GEORG.NET Anbindung an Ihr ACTIVE-DIRECTORY Vorteile der Verwendung eines ACTIVE-DIRECTORY Automatische GEORG Anmeldung über bereits erfolgte Anmeldung am Betriebssystem o Sie können sich jederzeit als

Mehr

WS 2002/03. Prof. Dr. Rainer Manthey. Institut für Informatik III Universität Bonn. Informationssysteme. Kapitel 1. Informationssysteme

WS 2002/03. Prof. Dr. Rainer Manthey. Institut für Informatik III Universität Bonn. Informationssysteme. Kapitel 1. Informationssysteme Informationssysteme Informationssysteme WS 2002/03 Prof. Dr. Rainer Manthey Institut für Informatik III Universität Bonn 2002 Prof. Dr. Rainer Manthey Informationssysteme 1 DB und/oder IS: terminologischer

Mehr

Erstellen von x-y-diagrammen in OpenOffice.calc

Erstellen von x-y-diagrammen in OpenOffice.calc Erstellen von x-y-diagrammen in OpenOffice.calc In dieser kleinen Anleitung geht es nur darum, aus einer bestehenden Tabelle ein x-y-diagramm zu erzeugen. D.h. es müssen in der Tabelle mindestens zwei

Mehr

(1) Mit dem Administrator Modul werden die Datenbank, Gruppen, Benutzer, Projekte und sonstige Aufgaben verwaltet.

(1) Mit dem Administrator Modul werden die Datenbank, Gruppen, Benutzer, Projekte und sonstige Aufgaben verwaltet. 1 TimeTrack! TimeTrack! Ist ein Softwareprodukt von The Project Group, welches der Erfassung von Ist- Aufwänden von Projekten dient. Voraussetzung hierfür ist allerdings, dass das Projekt vorher mit Microsoft

Mehr

Informationen zur IBAN-Pflicht ab 2014

Informationen zur IBAN-Pflicht ab 2014 Informationen zur IBAN-Pflicht ab 2014 Inhalt: 1. Einleitung 2. Automatische Berechnung von IBAN und BIC 3. Zahlungen per SEPA ausführen 4. Was Sie außerdem noch beachten sollten 1. Einleitung Ab dem 1.

Mehr

Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.

Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch. Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.pdf Nachdem die Projekt-Vision und die Stakeholder bekannt sind,

Mehr

ISA Server 2004 Protokollierung - Von Marc Grote. Die Informationen in diesem Artikel beziehen sich auf:

ISA Server 2004 Protokollierung - Von Marc Grote. Die Informationen in diesem Artikel beziehen sich auf: ISA Server 2004 Protokollierung - Von Marc Grote Die Informationen in diesem Artikel beziehen sich auf:? Microsoft ISA Server 2004 Im Artikel Übersicht Monitoring wurde eine Zusammenfassung aller Überwachungsfunktionen

Mehr