Rheinische Friedrich-Wilhelm-Universität Bonn · (Listenfelder, Radio-Buttons etc.). Jeder Wert eines Fremdschlüssels muss als Jeder Wert eines Fremdschlüssels muss als Schlüsselwert

Rheinische Friedrich-Wilhelm-Universität Bonn

Institut für Informatik III

Prof. Dr. Rainer Manthey

Diplomarbeit

Entwurf und Realisierung eines Tools zur Spezialisierung von SQL-Sichten

Olga Berman

06.06.2005

iii

Danksagung Hiermit möchte ich mich bei Prof. Dr. Rainer Manthey und den Herren Oliver Speidel für die viele Zeit, die sie der Betreuung dieser Arbeit gewidmet haben, bedanken. Ich bedanke mich auch bei meinen Eltern und Freunden für die Unterstützung. Erklärung Hiermit erkläre ich, Olga Berman, dass ich diese Arbeit selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitate kenntlich gemacht habe. Bonn, den 06. Juni 2005

Inhaltsverzeichnis

iv

Inhaltsverzeichnis

1 Einführung ........................................................................1

2 Relationale Datenbanken .................................................3 2.1 Grundlagen relationaler Datenbanken........................................................................ 3 2.2 SQL ............................................................................................................................ 6

2.2.1 DDL.................................................................................................................... 6 2.2.2 DML................................................................................................................... 7 2.2.3 Sichten.............................................................................................................. 11

3 MS ACCESS - ein DBMS und JET-SQL .....................13 3.1 Komponenten einer Datenbankanwendung ............................................................. 13 3.2 Beziehungen zwischen Tabellen .............................................................................. 15 3.3 Datenzugriffsschnittstellen....................................................................................... 17 3.4 Datenzugriff mit DAO-Objekten ............................................................................. 17 3.5 Jet-SQL..................................................................................................................... 19 3.6 VBA (Visual Basic for Applications) ...................................................................... 22

3.6.1 Visual Basic-Entwicklungsumgebung ............................................................. 22 3.6.2 Objekte, Methoden, Eigenschaften .................................................................. 22 3.6.3 VBA-Grundlagen ............................................................................................. 23

4 Deduktive Datenbanken.................................................25 4.1 Deduktive Datenbanken ........................................................................................... 25 4.2 Datalog ..................................................................................................................... 26

4.2.1 Grundlagen ....................................................................................................... 26 4.2.2 Auswertung von Datalog-Regeln ..................................................................... 28

4.3 Änderungspropagierung........................................................................................... 30 4.3.1 Motivation ........................................................................................................ 30 4.3.2 Delta-Regeln..................................................................................................... 31 4.3.3 Transitionsregeln.............................................................................................. 33

5 Änderungspropagierung in SQL...................................37 5.1 Das Prinzip ............................................................................................................... 37 5.2 Effektivitätstest......................................................................................................... 41 5.3 Besonderheiten, Schwierigkeiten ............................................................................. 43 5.4 Duplikate .................................................................................................................. 50 5.5 Aggregatfunktionen.................................................................................................. 51 5.6 Algorithmen ............................................................................................................. 53

Inhaltsverzeichnis

v

6 Implementierung.............................................................57 6.1 Compiler................................................................................................................... 57

6.1.1 Parser................................................................................................................ 58 6.1.2 Analyser ........................................................................................................... 60 6.1.3 Code Generator ................................................................................................ 61

6.2 Einbettung in MS Access ......................................................................................... 66 6.3 Compiler-Testbeispiele ............................................................................................ 72

6.3.1 Test 1 ................................................................................................................ 72 6.3.2 Test 2 ................................................................................................................ 75

6.4 Schlussfolgerung ...................................................................................................... 80

7 Zusammenfassung und Perspektiven............................81

Literaturverzeichnis.............................................................83

Kapitel 1

1

1 Einführung

Durch Änderungsoperationen in einer Datenbank, genauer gesagt durch Tabellenänderungen, können sich auch die Einträge einer Sicht ändern. Eine naive Möglichkeit der Aktualisierung ist die Rematerialisierung der Sichten. Dabei wird der gesamte Inhalt der Sicht neu berechnet. Wenn sich nur ein kleiner Teil der Daten geändert hat, so ist die Rematerialisierung sehr ineffizient. Wenn die Änderungen im Verhältnis zu den enthaltenen Daten insgesamt relativ gering sind, so ist die inkrementelle Anpassung hingegen viel effizienter. Bei dieser wird zunächst festgestellt, wie sich die Änderungen von Basisdaten auf die Sichten auswirken, und nur noch die induzierten Änderungen der Sichten berechnet. Es gibt viele inkrementelle Verfahren zur effizienten Sichtenaktualisierung in Datalog. In relationalen Datenbanksystemen mit der Anfragesprache SQL sind diese Konzepte jedoch noch nicht implementiert worden. Ziel dieser Arbeit ist es, einen Algorithmus zu entwicklen und zu implementieren, der das Konzept der inkrementellen Sichtanpassung in einer relationalen Datenbank realisiert. MS Access 2002 ist ein kommerzielles relationales, SQL-basiertes DB-System, das von der Firma Microsoft herstellt und vertrieben wird. In dieser Arbeit wird eine Erweiterung für MS Access 2002 geschrieben, deren Hauptteil ein Compiler ist. Der Compiler übersetzt die SQL-Sichten in so genannte Delta-Sichten, die nur die echten Faktenänderungen jener Sichten enthalten, die durch die Basisfaktenänderungen verursacht wurden. Um die induzierten Faktenänderungen einer Sicht zu ermitteln, müssen nur ihre Delta-Sichten ausgewertet werden. Die Sicht selbst muss dabei nicht neu berechnet werden. Bei dieser Arbeit wird nicht eine Teil-Sprache von SQL betrachtet, sondern es wird in erster Linie darauf geachtet, dass die von dem Compiler bearbeiteten Sichten die Möglichkeiten von Access-SQL zum größten Teil ausnutzen können. Abbildung 1-1 zeigt eine grobe Skizze des hier zu entwickelnden Compilers, der eine Access Erweiterung darstellt. Die Diplomarbeit ist wie folgt aufgebaut: Im ersten Teil der Ausarbeitung werden die erforderlichen Grundlagen definiert. SQL wird in Abschnitt 2 vorgestellt. In Kapitel 3 werden die Grundlagen der MS Access Datenbank und der darin integrierten Programmiersprache VBA erläutert. Hierbei werden die Unterschiede in der Syntax zwischen dem ANSI-SQL Standard und Jet-SQL (MS Access SQL) aufgezeigt. In Abschnitt 4 werden relationale, deduktive Datenbanken und deren Anfragesprache

Einführung

2

Datalog sowie das Konzept der inkrementellen Sichtenanpassung, soweit dies für die Entwicklung eines Compilers erforderlich ist, vorgestellt. Die Darstellung orientiert sich dabei an der Vorlesung „Deduktive Datendanken“ von Professor Dr. Rainer Manthey [Man00]. In Abschnitt 5 wird dann ein Algorithmus entwickelt, der die Delta-Sichten für die SQL-Sichten erstellt, ohne dass diese in eine datalogähnliche Form überführt werden müssen.

Abbildung 1-1 Der praktische Teil dieser Arbeit beginnt mit Abschnitt 6. Dort werden die Implementierung des Compilers in VBA sowie das Programm, in welches der Compiler integriert ist, vorgestellt. Das Programm erlaubt es dabei dem Benutzer, auf bequeme Weise für die ausgewählten Sichten die Delta-Sichten zu generieren, Basisänderungen einzugeben, die induzierten Änderungen anzusehen und gegebenenfalls die Änderungen in der Datenbank zu speichern. Die Korrektheit des Compilers wird anhand von zwei Beispielsichten in Abschnitt 6.3 demonstriert.

Kapitel 2

3

2 Relationale Datenbanken

Eine Datenbank ist eine Sammlung von Daten, die aus der Sicht des Benutzers zusammengehören, wie z.B. bei einer Personaldatenbank oder einer Lagerinventardatenbank. Es gibt hierarchische, relationale, multidimensionale und objektorientierte Datenbanken. Die meisten der heute kommerziell hergestellten Datenbanken basieren auf dem relationalen Datenbankmodell. Dieses Kapitel gibt eine allgemeine Einführung in das Thema relationale Datenbanken ([Man02],[KE01]). In Abschnitt 2.2 wird die Anfragesprache SQL mit DDL-Befehlen (Data-Definition-Language) und DML -Befehlen (Data-Manipulation-Language) vorgestellt. Außerdem wird in Abschnitt 2.2.3 das für die Problematik der Änderungspropagierung grundlegende Element − das Konzept der Sichten − erläutert.

2.1 Grundlagen relationaler Datenbanken

In der Fachliteratur wird zwischen den Begriffen "Datenbank" (DB; Engl.: Database), "Datenbank-Management-System" (DBMS; Engl.: Database Management System) und "Datenbanksystem" (DBS; Engl.: Database System) unterschieden ([Man02], [KE01]). Unter einem DBMS versteht man ein Softwarepaket, welches in der Lage ist, unabhängig vom Anwendungssystem, (Anwender-)Daten in einem Computersystem zu verwalten, sprich: aus einer Datenbank zu lesen oder etwas hineinzuschreiben. Das DBMS stellt dabei Funktionalitäten zur Datenverwaltung und Bearbeitung (Lesen, Ändern, Einfügen oder Löschen von Daten) zur Verfügung. Ein DBS ermöglicht es mehreren Benutzern, gleichzeitig mit demselben physischen Datenbestand zu arbeiten. Benutzer greifen dabei nicht direkt auf den Datenbestand zu, sondern die Datenbanksoftware erledigt die lesenden und schreibenden Zugriffe auf die Daten. Der Begriff Datenbanksystem beschreibt den Verbund einer nicht leeren Menge von Datenbanken mit einem Datenbank-Management-System: DBS = DB + DBMS. Das Relationenmodell wurde im Jahre 1970 von Dr. Edgar F. Codd [Cod70] formuliert und dient seitdem als Grundlage für die meisten Datenbanksysteme. Die Basis dafür bildet die mathematische Relationentheorie. Die Relationen (hier im Sinne einer zweidimensionalen Tabelle) sind die einzigen Strukturelemente, die man dazu braucht.

Relationale Datenbanken _

4

Relationale Datenbanken, wie etwa MS-Access, werden heutzutage in den meisten Fällen bevorzugt, und zwar besonders dort, wo auf schnelle und einfache Bedienung Wert gelegt wird. Zur Beschreibung von Daten verwenden relationale Datenbanken das relationale Datenmodell. Hierbei werden Datenobjekte zu einer Tabelle zusammengefasst. Eine solche Tabelle besteht aus einem Tabellenkopf und einem Tabellenrumpf. Der Tabellenkopf wiederum setzt sich aus einer festen Anzahl von Spalten zusammen, die man im Allgemeinen Attribute nennt. Der Wertebereich eines Attributs heißt Domäne; eine einzelne Zeile hingegen nennt man ein Tupel. Attribute kann man auch als Spalten einer Tabelle bezeichnen, welche die Eigenschaften der Objekte beschreiben. Die Werte des Tabellenrumpfes stellen die Attributwerte der zu beschreibenden Objekte dar. Der Tabellenrumpf enthält eine variable Anzahl von Tupeln, welche Datenobjekte darstellen. Die Gesamtheit aller Tupeln einer Tabelle, also die Daten, werden als Relation bezeichnet. Relationen sind Mengen. Diese Mengen können als zweidimensionale Tabellen dargestellt werden. Die Anzahl der Attribute im Relationskopf gibt den Grad einer Relation an, während die aktuelle Anzahl der Tupeln im Rumpf die Kardinalität definiert. Da eine Datenbankrelation keine doppelten Elemente enthalten darf, gibt es auch keine identischen Tupeln. Daher wird jedem Tupel ein individueller Schlüssel zugewiesen. Durch diesen Schlüssel kann ein Tupel eindeutig identifiziert werden. Normalerweise verwendet man hierfür eine minimale Menge an Attributen, deren Werte sich zusammengenommen von den Werten anderer Tupel definitiv unterscheiden. Aus Performancegründen und zur besseren Handhabung sollte ein Schlüssel möglichst wenig Attribute beinhalten und auch nur solche, bei deren Wegnahme die Schlüsseleigenschaft verloren geht. Jedes Attribut, das zu einem Schlüssel gehört, heißt Schlüsselattribut; alle anderen Attribute sind Nichtschlüsselattribute. Häufig existieren zu einem Relationstyp mehrere mögliche Schlüssel. Diese werden dann als Schlüsselkandidaten bezeichnet. Ein Schlüssel, der aus mehreren Attributen besteht (Attributkombination), heißt zusammengesetzter Schlüssel. Die Festlegung eines (Primär-)Schlüssels ist eine Designentscheidung. Bei mehreren Schlüsselkandidaten wird oft der kürzeste als Primärschlüssel ausgewählt. Im Falle eines zusammengesetzten Schlüssels sollte über die Einführung eines künstlichen Attributs zur Indentifizierung nachgedacht werden. Manchmal geht dies auf Kosten des Speicherbedarfs, bringt aber auch mehr Klarheit mit sich. Dabei ist jeder Primärschlüssel ein Schlüsselkandidat, aber nur ein einziger Schlüsselkandidat ist ein Primärschlüssel. Primärschlüssel sind deshalb von großer Bedeutung, weil sie das einzige Mittel zur Identifizierung eines gegebenen Tupels einer Relation sind. Die Kombination aus dem Namen einer Relation und ihrem Primärschlüssel reicht aus, um den Zugriff auf ein bestimmtes Tupel innerhalb einer Relation zu garantieren. Da Primärschlüssel für Relationen eine besondere Bedeutung haben, müssen sie sich von anderen Schlüsseln durch die Operationen unterscheiden, die man an ihnen ausführen kann. So sollte der Primärschlüssel z.B. niemals den Nullwert annehmen. Der Nullwert ist ein Platzhalter für einen unbekannten oder nicht anwendbaren Wert. Er entspricht nicht der numerischen Null oder einer leeren Zeichenkette, welche oft gültige Attributwerte sein können. Er stellt vielmehr ein Hilfsmittel zur Wahrung der Integrität dar. Neben Relationen, die den Einheiten der realen Welt entsprechen, enthalten Datenbanken in der Regel auch Relationen über Relationen (Beziehungsrelationen). Besteht eine Datenbank aus mehreren Relationen, dann werden die Beziehungen zwischen den

Kapitel 2

5

einzelnen Relationen dadurch hergestellt, dass der Primärschlüssel einer Relation in die Attributmenge einer anderen Relation aufgenommen wird. Der Schlüssel dient dort der Identifizierung von Tupeln einer „fremden“ Relation und wird als Fremdschlüssel (Engl.: Foreign Key) bezeichnet. Im Allgemeinen dient ein Fremdschlüssel in einer Relation als Mechanismus, um auf eine andere Relation zu verweisen. Die Fremdschlüssel einer Relation zeigen also an, dass diese Relation mit einer anderen Relation über den Inhalt ihrer Fremdschlüssel verbunden ist. Ein Beispiel: Relation Mann Name Alter Prinz 300 Tony 30

Relation Frau Name Alter Schneewittchen 400 Angela 30

Beziehungsrelation Ehe Ehemannname Ehefrauname Ehedauer Schneewittchen Prinz 200 Tony Angela 2

Unter dem Begriff der Integrität bzw. Konsistenz versteht man die Widerspruchsfreiheit von Datenbanken. Eine Datenbank ist integer bzw. konsistent, wenn die gespeicherten Daten fehlerfrei erfasst sind und den gewünschten Informationsgehalt korrekt wiedergeben. Relationale Integritätsregeln dienen der Gewährleistung der Integrität und werden durch das Datenbankschema umgesetzt. Bei relationalen Datenbanken existieren zwei Integritätsregeln bzw. Bedingungen: Die Entity-Integrität und die Referentielle Integrität. Jede Relation besitzt einen Primärschlüssel (Attribut oder Attributskombination), der jedes Tupel der Relation eindeutig bestimmt. Für jede Relation wird ein Schlüssel zwingend verlangt. Falls mehrere Schlüsselkandidaten vorkommen, muss einer davon als Primärschlüssel definiert werden. Die Eindeutigkeit von Primärschlüsselinhalten wird vom Datenbanksystem geprüft. Diesen Sachverhalt nennt man Entity-Integrität (Eindeutigkeit). Die Attribute einer Relation können nur Werte aus einem vordefinierten Wertebereich annehmen. Das nennt man Wertebereichsbedingung. Dies kann nicht durch das Datenbanksystem selbst gewährleistet werden, die Validierung bleibt weitgehend dem Anwender überlassen. Eine Unterstützungsmöglichkeit bilden Eingabemasken, welche bei der Datenerfassung dem Anwender fest definierte Attributwerte für die Attribute vorgeben (Listenfelder, Radio-Buttons etc.). Jeder Wert eines Fremdschlüssels muss als Schlüsselwert in der referenzierten Relation existieren. Die Einhaltung dieser Bedingung nennt man referentielle Integrität. Werden Daten verändert (Ändern, Löschen oder Einfügen), können die Integritätsbedingungen verletzt werden. In diesem Fall spricht man von Datenbankanomalien, da die Daten in sich widersprüchlich sind. Man unterscheidet drei Arten von Anomalien: Einfügeanomalie, Änderungsanomalie und Löschanomalie. Manchmal kann ein Sachverhalt nur dann eingefügt werden, wenn ein anderer Sachverhalt ebenfalls mit aufgenommen wird. Es könnte jedoch sein, dass zum zweiten Sachverhalt entweder noch keine Daten zur Verfügung stehen, oder die Erfassung nicht gewünscht wird. Normalerweise überwacht das Datenbankmanagementsystem die Abläufe und hindert den Benutzer daran, eine Einfügeanomalie zu verursachen. Daher kommt sie in der Praxis selten vor. Die


6

Änderungsanomalie hingegen entsteht dann, wenn durch den Austausch eines einzigen Sachverhaltes die Relation an mehreren Stellen angepasst werden muss, dies aber nicht geschieht. Eine solche unvollständige Anpassung wiederum führt zu inkonsistenten Datenbeständen. Eine Löschanomalie schließlich entsteht, wenn ein Sachverhalt ungewollt verloren geht.

2.2 SQL

Nach der Einführung des relationalen Modells Anfang der 70er Jahre wurde von IBM ein DBMS-Prototyp namens "System R" entwickelt. Die Anfragesprache, die System R benutzte, wurde "SEQUEL" (Structured English Query Language) genannt und später in SQL umbenannt. Im Laufe der Jahre hat sich SQL als Abfragesprache für relationale Datenbanken wie Oracle, MS-Access, MySQL, PostgreSQL oder MaxDB etabliert, die von den größten kommerziellen Datenbankherstellern wie Oracle oder IBM angeboten werden. Die erste SQL-Norm wurde 1986 von der ANSI-Kommision (American National Standards Institute) verabschiedet. 1989 wurde der Standard das erste Mal revidiert und 1992 entstand der stark erweiterte SQL-92, auch SQL 2 genannt. Der heute gültige Standard ist SQL:1999 (SQL-3) ([ANSI99I], [ANSI99II]). Er wurde erst im Dezember 1999 veröffentlicht. Die Anfragesprache beinhaltet die Werkzeuge, mit deren Hilfe man Informationen über den Inhalt einer Datenbank erfragen, Daten manipulieren und definieren kann. SQL zählt zu den deklarativen Anfragesprachen. D.h. die Benutzer geben nur an, welche Daten sie interessieren, und nicht, wie die Auswertung der Daten vorgenommen werden soll. Bei SQL unterscheidet man: DDL-Befehle (Data-Definition-Language): Mit den Befehlen dieser Klasse werden Datenstrukturen (Tabellen, Indices,...) erzeugt, verändert oder gelöscht. DML -Befehle (Data-Manipulation-Language): Mit diesen Befehlen werden die Abfragen und Änderungen der Datenbank durchgeführt.

2.2.1 DDL

Die zu einer Datenbank gehörenden Tabellendefinitionen werden als Schema der Datenbank bezeichnet. Sie werden automatisch im Datenwörterbuch gespeichert. Das Datenwörterbuch beschreibt den Zustand der Datenbank, enthält also Metadaten. DDL CREATE TABLE (Tabelle erzeugen) DROP TABLE (Tabelle löschen) ALTER TABLE (Tabelle modifizieren) CREATE INDEX (Index für Tabellen anlegen) CREATE VIEW (Erzeugen einer Sicht) RENAME (Tabellen, Spalten umbenennen) ADD/DROP COLUMN (Spalte einfügen/ löschen)

Kapitel 2

7

So wird eine neue Tabelle mit dem Befehl CREATE TABLE erzeugt. Dem Namen der Tabelle folgt in Klammern eine Liste der Attribute und ihrer Typen, durch Komma(ta) getrennt. Nach einer Typeneingabe kann zusätzlich noch die Einschränkung NOT NULL folgen. In SQL gibt es einen speziellen Wert mit dem Namen NULL, der in jedem Datentyp vorhanden ist. Ein NULL -Wert wird z.B. dann gespeichert, wenn der korrekte Wert nicht bekannt ist. Dadurch wird erzwungen, dass alle in die Tabelle eingetragenen Tupel an dieser Stelle einen definierten Wert haben. In Beispiel 2.1 ist es also nicht möglich, Autoren ohne Namen einzutragen. Die Spezifikation NOT NULL ist eine Integritätsbedingung und sollte für alle Primärschlüsselattribute angegeben werden. Beispiel 2.1 CREATE TABLE Autoren ( Name CHARAKTER (50) NOT NULL, Land CHARAKTER (50) ); CREATE TABLE Bücher ( Autor CHARAKTER(50) NOT NULL, Titel CHARAKTER (100) NOT NULL, Art CHARAKTER (50) ); CREATE TABLE Fachliteratur ( Autor CHARAKTER (50) NOT NULL, Titel CHARAKTER (100) NOT NULL, );

2.2.2 DML

Die Datenmanipulationssprache DML dient zur Anfrage, zum Einfügen, Ändern und Löschen von Datensätzen. DML SELECT (Tabellen abfragen) INSERT (Tabellenzeilen hinzufügen) UPDATE (Daten einer Tabelle verändern) DELETE (Tabellenzeilen löschen)

Seien A1 bis An Attribute der R1 bis Rk Relationen. SELECT A1, ..., A n

FROM R1, ..., R k

WHERE P;


8

Hinter FROM steht der Name der Tabelle. Durch die WHERE-Klausel wird bestimmt, welche Datensätze (Zeilen einer Tabelle) ausgewählt werden sollen (Bedingungsprüfung). Formal ausgedrückt, entspricht das Ergebnis des FROM - Teils logisch dem kartesischen Produkt R1 * ... * Rk der beteiligten Relationen. Der WHERE -Teil entspricht der Selektion der relationalen Algebra. Er kann auch fehlen, dann wird als Bedingung aber implizit "True" eingesetzt und jedes Tupel des Kreuzproduktes in das Ergebnis aufgenommen. Der SELECT-Teil projiziert schließlich auf die eingegebenen Attribute A1, ... , An. Ein äquivalenter Relationenalgebra-Ausdruck sieht folgendermaßen aus: ∏A1,…, An( σP(R 1 ×…× R k))

Die folgende SQL-Anfrage liefert alle Autoren, die in Deutschland geboren wurden: SELECT Autoren.Autor FROM Autoren WHERE Autoren.Land="Deutschland"; In SQL-92 kann man den JOIN -Operator benutzen. Er stellt eine schnelle Technik zum gleichzeitigen Zugriff auf zwei Tabellen zur Verfügung. Dort können im FROM-Teil die folgenden Schlüsselwörter angegeben werden: CROSS JOIN: Kreuzprodukt, NATURAL JOIN: natürlicher JOIN, JOIN oder INNER JOIN: THETA - JOIN LEFT, RIGHT oder FULL OUTER JOIN: äußerer JOIN. Auf diese Weise kann z.B. eine Anfrage der Art: SELECT * FROM R1,R 2

WHERE R1.A=R 2.b;

explizit als JOIN formuliert werden: SELECT * FROM R1 JOIN R 2 ON R 1.A=R 2.B; Hinter dem JOIN wird mit ON die Joinbedingung explizit angegeben. Die folgende Abfrage liefert eine virtuelle Tabelle, in der die Inhalte der beiden Tabellen Bücher und Autoren miteinander kombiniert werden. SELECT Bücher.Autor, Bücher.Titel, Bücher.Art, Auto ren.Land FROM Bücher INNER JOIN Autoren ON Bücher.Autor=Autoren.Name;

Kapitel 2

9

SQL kennt die üblichen Vergleichsoperatoren: Vergleichsoperatoren Operatoren Beschreibung = gleich <> ungleich > größer < kleiner >= größer gleich <= kleiner gleich

– sowie einige zusätzliche wie BETWEEN, IN, LIKE, AND, OR oder NOT. Bei dem Operator BETWEEN Wert1 AND Wert2 liegt der Vergleichswert zwischen Wert1 und Wert2. Bei der IN Werteliste ist der Vergleichswert in der angegebenen Werteliste enthalten. Sehr nützlich ist der Vergleich von Zeichenketten in Hinblick auf Ähnlichkeit mit dem Operator LIKE. Der Ausdruck LIKE Zeichenfolge bedeutet, dass die Vergleichszeichen der Zeichenfolge entsprechen. Wenn eine Zeichenkette nicht genau bekannt ist, so können "%" und "_" als Platzhalter für unbekannte Teile verwendet werden. "%" steht dabei für beliebig viele und "_" für genau ein unbekanntes Zeichen. Vergleichsoperatoren können mit den logischen Operatoren AND, OR und NOT verknüpft werden. Eine SQL-Anfrage mit zusätzlichen Operatoren: SELECT [DISTINCT] {Feldname, Feldname,..*} FROM Tabelle [, Tabelle, Tabelle....] [WHERE {Bedingung}] [ORDER BY Feldname [ASC|DESC]...] [GROUP BY Feldname [HAVING {Bedingung}]] Werden alle Attribute benötigt, so kann zur Abkürzung einfach ein "*" anstelle der Attributsnamen angegeben werden. Da die Eliminierung der Duplikate aus Effizienzgründen in einer Tabelle nicht automatisch vorgenommen wird, kann dies mit dem Schlüsselwort DISTINKT erzwungen werden. Mit Hilfe von ORDER BY werden Daten nach einem oder mehreren Feldnamen sortiert ausgegeben. Die vorgegebene Sortierreihenfolge ist aufsteigend ASC (ascending). Soll absteigend sortiert werden, so muss DESC (descending) eingegeben werden. Mit der GROUP BY -Klausel kann man die Zeilen einer Tabelle nach bestimmten Feldern gruppieren. Die HAVING - Klausel ist der WHERE - Klausel sehr ähnlich. Bei der HAVING - Klausel werden bestimmte Gruppen aus einer Gruppenmenge ausgewählt. Somit kann die HAVING - Klausel nur in Zusammenhang mit der GROUP BY - Klausel angewendet werden. Aggregatfunktionen führen Operationen auf den Tupelmengen durch und komprimieren eine Menge von Werten zu einem einzigen Wert. AVG bestimmt den Durchschnitt, MAX und MIN bestimmen das größte bzw. kleinste Element und SUM bildet die Summe einer Menge von Zahlen. COUNT zählt die Anzahl der Zeilen in der Tabelle. Häufig werden die Aggregatfunktionen zusammen mit dem Opertor GROUP BY kombiniert. Folgende


10

Anfrage liefert alle Autoren, die, der Tabelle Bücher nach, mehr als 3 Bücher geschrieben haben: SELECT Bücher.Autor, COUNT(*) FROM Bücher GROUP BY Autor HAVING COUNT(*) > 3 ORDER BY Autor; In SQL können SELECT-Anweisungen geschachtelt werden. Hier ein Beispiel für eine geschachtelte Abfrage: SELECT deutscher_Bücher.Autor, deutscher_Bücher.Tit el, deutscher_Bücher.Art FROM deutscher_Bücher WHERE NOT EXISTS ( SELECT * FROM Fachliteratur WHERE Fachliteratur.Autor=deutscher_Bücher.Autor AND Fachliteratur.Titel=deutscher_Bücher.Titel); Der EXIST -Operator liefert TRUE, falls die Unterabfrage mindestens ein Ergebnistupel zurückliefert, und ansonsten FALSE Der Operator IN testet auf Mengenmitgliedschaft: SELECT * FROM Autoren WHERE Name IN ( SELECT * FROM deutscher_Bücher WHERE Autoren.Name=deutscher_Bücher); Die Abfrage liefert alle Autoren, die in der Sicht deutscher_Bücher enthalten sind, also alle deutschen Autoren. Wie schon gesagt wurde, gibt es in SQL einen speziellen Wert mit dem Namen NULL, der in jedem Datentyp vorhanden ist. Ein NULL-Wert wird z.B. dann gespeichert, wenn der korrekte Wert nicht bekannt ist. Bei der Abfragebearbeitung können NULL-Werte als Ergebnis von Operationen entstehen - selbst wenn die zugrunde liegenden Operationen keine NULL-Werte enthalten. Die Aggregatfunktion MAX, angewendet auf eine leere Tabelle, liefert zum Beispiel einen NULL-Wert zurück. IS NULL(Feld) liefert TRUE falls das Vergleichsfeld einen NULL-Wert hat. SQL enthält eine dreiwertige Logik, d.h. SQL kennt nicht nur TRUE und FALSE, sondern auch UNKNOWN. Diesen Wert liefert der Vergleich zweier Argumente zurück, wenn mindestens einer von ihnen NULL ist. Die Operationen der Mengenlehre – Vereinigung, Durchschnitt und Differenz – heißen in SQL UNION, INTERSECT und EXCEPT. Da das Ergebnis einer Abfrage wieder eine sinnvolle Tabelle darstellen soll, müssen die Ergebnistypen der Teilanfragen übereinstimmen. IN ist äquivalent zum Ausdruck =ANY. Es gibt folgende Ausdrücke in

Kapitel 2

11

SQL: Vergleichsoperatoren (=, >, <, ...) sowie ALL oder ANY. ANY prüft, ob es mindestens ein Element im Ergebnis der Unterabfrage gibt, für das der Vergleich mit dem linken Argument des Operators erfüllt wird. ALL testet, ob alle Ergebnisse der Unterabfrage den Vergleich erfüllen. Die Studenten mit der größten Semesterzahl können mit folgendem Ausdruck gefunden werden: SELECT Name FROM Studenten WHERE Semester>=all (SELECT Semester FROM Studenten ); Mit Hilfe von SQL kann man die Daten auch ändern, modifizieren oder löschen. Mit dem INSERT - Befehl ist es möglich, der Datenbank Daten hinzuzufügen. Ein Beispiel: INSERT INTO Fachliteratur SELECT FROM Bücher WHERE ART="Fachliteratur"; Zum Löschen wird der DELETE-Befehl verwendet. Es werden nur Einträge gelöscht, die der Bedingung des WHERE-Teils genügen: DELETE FROM Bücher WHERE Art="Fachliteratur"; Bestehende Zeilen können mit dem UPDATE- Befehl verändert werden: UPDATE Bücher SET Art="Belletristik";

2.2.3 Sichten

Die Möglichkeit, Basisrelationen mit dem CREATE TABLE Befehl zu erzeugen, wurde bereits erwähnt. Neben den so gebildeten Basisrelationen existieren noch weitere Relationen, die so genannten Sichten (im Englischen: Views). Dies sind von Basisrelationen abgeleitete Relationen, wobei in der Datenbank nicht deren Inhalt, sondern nur die Ableitungsregeln, also Sichtdefinitionen, abgespeichert werden. Somit werden die Sichten bei jedem Zugriff neu berechnet Der Sinn von Sichten liegt darin, dem Benutzer einen Datenausschnitt zu zeigen, ohne dass die Daten in dieser Konstellation in der Datenbank tatsächlich gespeichert sind. Auch im Falle von Zugriffsschutz gibt es wichtige Anwendungen, wenn zum Beispiel nur auf einen Teil einer Relation durch Dritte zugegriffen werden darf. Sichten können sich auf Datenbankrelationen und/ oder auf andere Sichten stützen. Beispiel 2.2 (Sichten, die auf den Tabellen aus dem Beispiel 2.1 aufbauen) CREATE VIEW deutscher_Bücher AS ( SELECT Bücher.Autor, Bücher.Titel, Bücher.Art


12

FROM Bücher, Autoren WHERE Bücher.Autor=Autoren.Name AND Autoren.Land="Deutschland"; ); und CREATE VIEW deutsche_Belletristik AS ( SELECT deutscher_Bücher.Autor, deutscher_Bücher.Ti tel, deutscher_Bücher.Art FROM deutscher_Bücher WHERE NOT EXISTS ( SELECT * FROM Fachliteratur WHERE Fachliteratur.Autor=deutscher_Bücher.Autor AND Fachliteratur.Titel=deutscher_Bücher.Titel) ); Der neueste SQL Standard SQL:1999 erlaubt die Definition rekursiver Sichten, aber nur mit der Beschränkung, dass die Relation in der rekursiven Unterabfrage im FROM-Teil nur einmal auftreten darf. Mehr Information über Rekursion in SQL können dem [ANSI99II] entnommen werden.

Kapitel 3

13

3 MS ACCESS - ein DBMS und JET-SQL

Microsoft Access ist ein Datenbanksystem, welches die Verwaltung von Daten und die Entwicklung von Datenbankanwendungen ermöglicht. Access ist ein relationales Datenbank-Management-System (RDBMS) ([HS02], [Bro99]). Es wird zusammen mit dem Microsoft Office Professional-Paket vertrieben. Die bisher aktuellste Version ist MS Access 2003. In dieser Arbeit wird allerdings MS Access XP verwendet. Im Gegensatz zu den anderen Office-Programmen von Microsoft läuft Access nur unter Windows. Dieses Programm speichert die Daten in einem so genannten *.mdb-Format ab. Ferner kann auf Access-Datenbanken auch mit anderen Programmiersprachen wie z.B. Delphi oder Visual Basic zugegriffen werden. Die Schreibzugriffe erfolgen in einer Access-Datenbank immer am Dateiende. Dieses Vorgehen ist nötig, um einen Mehrbenutzerzugriff zu ermöglichen. Gelöschte oder abgeänderte Elemente bleiben als "Löcher" in der Datei vorhanden, bis die Access-Datei als Ganzes komprimiert wird. Mit VBA (Visual Basic for Applications) kann man benutzerdefinierte Erweiterungen für MS Access[Sta99] erstellen. Der in dieser Arbeit entwickelte Compiler stellt eine solche Erweiterung dar. Dieses Kapitel gibt eine allgemeine Einführung in das relationale DBMS MS Access. In Abschnitt 3.1 werden kurz Komponenten wie z.B. Formulare, Berichte oder Abfragen vorgestellt. Abschnitt 3.2 gibt eine kurze Anleitung dazu, wie man in Access referentielle Integrität definieren kann. In den Abschnitten 3.3 und 3.4 werden die für die Compilerimplimentierung interessanten Datenzugriffsmodelle DAO (Data AccessObjects) erläutert. Abschnitt 3.5 vergleicht Jet-SQL mit der Standard-SQL. Abschnitt 3.6 gibt eine allgemeine Einführung in VBA.

3.1 Komponenten einer Datenbankanwendung

Nach dem Start einer neuen MS Access-Anwendung wird das Datenbankfenster (Abbildung 3.1) eingeblendet. Es ist das Hauptfenster dieses Systems,, von dem aus man mit Tabellen, Abfragen, Formularen, Berichten, Datenzugriffsseiten, Makros und Modulen arbeiten kann. Im Folgenden werden diese Komponenten nur in einfacher Form vorgestellt, da eine detaillierte Erläuterung den Rahmen dieser Arbeit sprengen würde. Die Daten einer Access-Datenbank werden in Tabellen gespeichert. Bei Access können die Daten sehr unterschiedlicher Art sein, so etwa als Texte, Zahlen, Wahrheitswerte,

MS ACCESS - ein DBMS und JET-SQL _

14

Hyperlinks, Bilder etc. Tabellen und Abfragen stellen die Daten in tabellarischer, standardisierter Form dar. Der Benutzer hat dabei kaum Möglichkeiten, die Art der Darstellung zu beeinflussen. In Formularen kann der Benutzer dagegen selber bestimmen, wie die Daten auf dem Bildschirm dargestellt werden. Dies geschieht durch die Anordnung und Gestaltung von Eingabefeldern (bei Access heißen sie Textfelder) und ihren Bezeichnungen, Auswahlfeldern, Unterformularen, grafischen Elementen etc. Die Formulare erlauben dabei eine derartige Gestaltung der Datenbank, dass diese auch von Anwendern ohne Access-Kenntnisse bearbeitet werden kann, und zwar lesend wie schreibend. Die Berichte haben eine große Ähnlichkeit mit den Formularen. Sie unterscheiden sich aber von den Formularen vor allem in zwei Punkten:

1.

Berichte sind nicht für den Bildschirm, sondern für die Druckausgabe gedacht.

2.

In Berichten können Daten in gruppierter Weise ausgegeben und berechnet werden. In Formularen ist es dies hingegen nicht möglich.

Berichte sind besonders nützlich, wenn eine große Datenmenge in übersichtlicher Form ausgedruckt werden soll.

Abbildung 3.1 Datenbankfenster Stellen Tabellen die Datenbasis einer Datenbank dar, so sind Abfragen das wichtigste Instrument der Datenverwaltung. Mit einer Abfrage können aus der Gesamtheit der Daten die Informationen zusammengestellt werden, die für einen bestimmten Zweck benötigt werden. Eine Sicht kann man in Access als eine Abfrage definieren. Man kann Abfragen annähernd so einsetzen wie Tabellen. Zum Beispiel kann ein Formular oder ein Bericht ebenso gut auf einer Abfrage basieren wie auf einer Tabelle. Abfragen können in der Datenbank gespeichert werden. Normalerweise enthält eine

Kapitel 3

15

Datenbank eine Vielzahl von gespeicherten Abfragen, die aufgerufen oder als Datenquelle für Formulare oder Berichte dienen können. Wenn Daten in einem Formular, einer Tabelle oder im Datenblatt einer Abfrage geändert oder eingeben werden, speichert Access die Veränderung automatisch und ohne Meldung, sobald es sie als abgeschlossen erkennt. Diese Verfahrensweise hat den großen Vorteil, dass der Benutzer sich um das Speichern von Daten im Allgemeinen überhaupt nicht zu kümmern braucht. In einer Mehrbenutzerumgebung sind dadurch veränderte Datensätze sofort für andere Benutzer aktualisiert. Außerdem trägt diese Tatsache zur Datensicherheit bei Systemabstürzen bei, da ungesicherte Datenänderungen praktisch nicht vorkommen. Mit Makros werden die wichtigsten Access-Aktionen, die sonst manuell mittels Menübefehlen oder durch Anklicken von Symbolschaltflächen veranlasst werden, automatisch ausgeführt. Makros werden auf bequeme Weise in tabellarisch angeordneten Makrofenstern erstellt. So können die Programmabläufe automatisiert werden, ohne dass man sie dafür programmieren muss. Zur Vereinfachung häufig vorkommender komplexer Aufgaben (Erstellen einer Tabelle, Abfrage etc.) stellt Access mehrere Assistenten zur Verfügung. Diese Assistenten führen den Anwender Schritt für Schritt weiter und bieten dabei geeignete Auswahlalternativen und Hinweise an. Auf Module gehen wir später in Kapitel 3.6.2 ein.

3.2 Beziehungen zwischen Tabellen

Da diese Arbeit sich mit dem Problem der Sicht-/ Tabellenänderungen beschäftigt, wird das Thema der referentiellen Integrität nicht umgangen werden können. Bei Tabellen, die in Beziehung zu anderen Tabellen stehen, können einige Daten nicht gelöscht und andere wiederum nicht eingefügt werden. Daher ist es von enormer Wichtigkeit, sich jetzt schon ein Bild davon zu machen, wie dies funktioniert. Microsoft Access bietet mit dem Beziehungsfenster die Möglichkeit, Beziehungen zwischen einzelnen Tabellen anzugeben. Das Beziehungsfenster (Abbildung 3.2) kann von der Menüleiste aus geöffnet werden. Um eine Beziehung aufzubauen, klickt man mit der Maus auf das gewünschte Feld der einen Tabelle und zieht bei gedrückter Maustaste zum gewünschten Feld der anderen Tabelle (Abbildung 3.3). Beziehungen zwischen einzelnen Tabellen werden dadurch hergestellt, dass der Primärschlüssel einer Tabelle in die Attributmenge einer anderen Tabelle aufgenommen wird. Der Schlüssel dient dort der Identifizierung von Datensätzen einer „fremden“ Tabelle und wird als Fremdschlüssel bezeichnet. Access legt die Beziehungen automatisch fest: Bei 1:N-Beziehungen wird der Tabelle mit dem Primärschlüssel der “1-Teil“ zugewiesen (Mastertabelle), der Tabelle mit dem Fremdschlüssel der „N-Teil“ (Detailtabelle).


16

Abbildung 3.2 Beziehungsfenster 1:1-Beziehungen (sehr selten) werden dadurch hergestellt, dass eine Beziehung zwischen zwei Primärschlüsseln definiert wird. M:N-Beziehungen können in Access nicht definiert werden.

Abbildung 3.3 - Beziehungen zwischen Tabellen Wenn zwischen zwei Tabellen die „referentielle Integrität“ aktiviert wird, ändert sich das Verhalten der Tabelle beim Löschen und Ändern von Datensätzen. Bei der referentiellen Integrität können keine Datensätze in die Detailtabelle eingegeben werden, wenn kein entsprechender Datensatz in der Mastertabelle existiert. Ebenso darf das Feld in der

Kapitel 3

17

Mastertabelle nicht verändert werden, wenn dadurch in der Detailtabelle “verwaiste“ Datensätze entstehen. Falls die Aktualisierungsweitergabe aktiviert wird, wird eine Änderung des verknüpften Feldes in der Mastertabelle automatisch an alle verknüpften Datensätze der Detailtabelle weitergegeben. Bei aktivierter Löschweitergabe werden alle verknüpften Datensätze der Detailtabelle gelöscht, wenn ein Datensatz in der Mastertabelle gelöscht wird.

3.3 Datenzugriffsschnittstellen

Datenzugriffsschnittstellen werden für den Zugriff auf Tabellen und Abfragen benötigt. In diesem Abschnitt wird eine Übersicht über die verschiedenen Schnittstellen von MS Microsoft Access gegeben. Formulare, Berichte und Steuerelemente, Tabellen und Abfragen können als Objekte betrachtet werden, auf die mit Hilfe einer Objektvariablen zugegriffen werden kann. Access XP unterstützt zwei verschiedene Datenzugriffsmodelle: DAO (Data AccessObjects) und ADO (Active(X) Data Objects). Ursprünglich gab es nur die DAO-Bibliothek. Sie wurde entwickelt, um einen möglichst schnellen und sicheren Zugriff auf Access-Datenbanken zu ermöglichen. Die DAO-Bibliothek stellt alles zur Verfügung, was zur Manipulation der Datenbanken benötigt wird. Access 2000 erhielt zusätzlich die zuvor mit dem Internet Explorer 4 eingeführte ADO-Bibliothek. Dabei handelte es sich um eine neue Bibliothek, die mit DAO zwar stark verwandt war, aber vor einem völlig anderen Hintergrund entwickelt wurde. ADO wurde nicht gezielt für Access entworfen (wie etwa DAO), weil DAO etwa irgendwelche Nachteile gehabt hätte und nun durch eine neue Bibliothek ersetzt werden sollte. Stattdessen ist ADO ein von Access unabhängiger Bestandteil von Microsofts Datenbankstrategie. Dabei wird das Ziel verfolgt, eine einheitliche Schnittstelle zu unterschiedlichen Datenbanken zu schaffen (wie z.B. Access-, Oracle- oder MS SQL-Datenbanken), die mit beliebigen Programmiersprachen (wie etwa Java, VB oder C++) auf die immer gleiche Art und Weise zum Datenzugriff verwendet werden könnte. Diese Schnittstelle sollte auch den Zugriff auf Datenbanken an unterschiedlichsten Orten (auf lokale PC-Datenbanken genauso wie auf weit entfernte Datenbanken auf Unix- oder anderen Serversystemen im Netzwerk) ermöglichen. Aufgrund seiner Vielseitigkeit ist ADO für den Umgang mit Access-Datenbanken allerdings unnötig kompliziert und schwierig. Außerdem fehlen ADO sogar Features, die DAO zum Umgang mit Access-Datenbanken besitzt. Um lokale Access-Datenbanken zu erzeugen und zu programmieren, sollte man daher das hierfür besser geeignete DAO verwenden. Da es sich bei der im Rahmen dieser Diplomarbeit geleisteten Implementierung um eine Access-Datenbankerweiterung handelt, haben wir ebenfalls die DAO-Objekte benutzt. Daher gehen wir hier ein wenig gründlicher auf sie ein.

3.4 Datenzugriff mit DAO-Objekten

Abbildung 3.4-1 enthält die Objekte, die für einen DAO-Datenzugriff mit Access relevant sind.


18

An oberster Stelle befindet sich das DBEngine-Objekt. Dieses Objekt ist keine Auflistung, sondern ein von Access fest vorgegebenes Objekt. Alle anderen Objekte repräsentieren Auflistungen und sind in Abbildung 3.4 deshalb grau gefärbt. Das DBEngine-Objekt repräsentiert die JET-Datenbank-Engine (JET = Joint Engine Technologie) von Access, die für die Verwaltung aller Daten zuständig ist. Die dritte Ebene stellen die Database-Objekte dar, die jeweils eine bestimmte Datenbank repräsentieren. Da es mit VBA möglich ist, mehrere Datenbanken gleichzeitig zu öffnen, können sich in der dazugehörigen Databases-Auflistung auch mehrere Database-Objekte befinden. An erster Position (Positionsnummer 0) befindet sich immer die aktuelle Datenbank, mit der gerade in Access gearbeitet wird. Dasselbe gilt für die aktuelle Arbeitsumgebung (Workspace-Objekt). Die aktuelle Arbeitsumgebung befindet sich in der Workspaces-Auflistung ebenfalls an Positionsnummer 0. Um auf die aktuelle Benutzerdatenbank zuzugreifen, kann der folgende Ausdruck verwendet werden: Dbengine.Workspaces(0).Databases(0) . oder kürzer: DBEngine(0)(0). Noch mehr verkürzt wird der Zugriff auf die aktuelle Datenbank durch den Einsatz der Funktion Currentdb . Auch in dieser Arbeit wird diese Funktion verwendet. Dies ist auch die offizielle Empfehlung von Microsoft. Mit der Currentdb- Methode kann auf Daten von verschiedenen Tabellen zugegriffen werden, ohne Tabellen oder Formulare sichtbar öffnen zu müssen. Nur die Datenbank selbst muss geöffnet sein. Die Methode gibt ein DataBase-Objekt zurück, auf das sich unter anderem die folgenden Eigenschaften und Methoden anwenden lassen: Eigenschaften und Methoden Funktion Beschreibung CreateQueryDef erzeugt eine neue Abfrage. CreateTableDef erzeugt eine neue Tabelle. Execute führt eine Abfrage durch, soweit es sich nicht um eine

Auswahlabfrage handelt. OpenRecordSet erzeugt eine neue Datensatzgruppe. QueryDefs liefert die Auflistung aller Abfragen der aktuellen Datenbank. TableDefs liefert die Auflistung aller Tabellen der aktuellen Datenbank. Im Folgenden werden die Methoden genauer vorgestellt, die für das in dieser Arbeit entwickelte Programm benötigt werden .Mit den Eigenschaften Querydefs und Tabledefs erhält man die Auflistungen der in der aktuellen Datenbank enthaltenen Abfragen und Tabellen. Für die Definition einer Abfrage ist ein SQL_String erforderlich. Der String wird dann als zweites Argument der CreateQueryDef-Methode übergeben. Im ersten Argument befindet sich der Name der Abfrage. Diese Methode ist sehr wichtig, da mit ihrer Hilfe Delta- und Transitionssichten angelegt werden (siehe Kapitel 5).

Kapitel 3

19

Abbildung 3.4 - Die DAO-Objekthierarchie[HS02]

3.5 Jet-SQL

Die verschiedenen Datenbankhersteller haben die SQL-Normen meist nur teilweise in ihren Produkten umgesetzt. Fast alle haben dabei ihre Implementierung von SQL durch eigene Erweiterungen ergänzt, sodass sich die SQL-Varianten der einzelnen Produkte stark voneinander unterscheiden. Microsoft Access 2002 unterstützt ANSI-89 SQL sowie ANSI-92 SQL [KE01] und arbeitet standardmäßig mit Jet-SQL, also ANSI-89 SQL. Die Datenzugriffsschnittstelle DAO verwendet ANSI-89 SQL, ADO benutzt hingegen ANSI-92 SQL. In Access 2002 ist es auch möglich, den ANSI SQL-Abfrage-Modus zu wechseln und auf ANSI-92-SQL umzuschalten. Dazu muss man im Menü EXTRAS das Dialogfeld Optionen öffnen und


20

auf dem Registerblatt „Tabellen/Abfragen“ unter „SQL-Server kompatible Syntax“ ein Häkchen vor „In dieser Datenbank benutzen“ setzen. Es ist aber nicht empfehlenswert, mit in unterschiedlichen Abfragemodi erstellten Abfragen gleichzeitig zu arbeiten, da hierdurch Laufzeitfehler oder unerwartete Ergebnisse auftreten können. In der Datenbank, die für diese Arbeit erstellt wurde, wird der Standardmodus ANSI-89 SQL belassen und auf die Datenbank mit Hilfe von DAO-Objekten zugegriffen. Im Folgenden wird auf die Anfragen/ Sichtdefinitionen in Jet-SQL genauer eingegangen, da sie für diese Arbeit von großer Bedeutung sind. Der grundlegendste und am häufigsten verwendete SQL-Ausdruck ist das SELECT-Statement. Das SELECT-Statement wird verwendet, um Daten aus einer Datenbank zu lesen. Das Resultat erscheint üblicherweise als eine Menge von Einträgen (Zeilen) mit einer variablen Anzahl von Spalten. Die Basisstruktur eines SELECT-Statements ist uns schon aus Kapitel 2.2.2 bekannt: SELECT [DISTINCT/DISTINCTROW/TOP n] {Feldname, Feld name,..*} FROM Tabelle [, Tabelle, Tabelle....] [WHERE {Bedingung}] [ORDER BY Feldname [ASC|DESC]...] [GROUP BY Feldname [HAVING {Bedingung}]]; In Access ist es möglich, Datensätze einer Abfrage, auch wenn diese auf mehreren Tabellen oder anderen Abfragen basiert, zu verändern. In vielen anderen SQL-Datenbanken können immer nur Tabellen oder Abfragen bearbeitet werden, die auf nur einer Tabelle aufbauen. Microsoft nennt diese bearbeitbaren Abfragen Dynasets. Das Access-eigene Prädikat DISTINCTROW hat eine ähnliche Wirkung wie DISTINCT Der Unterschied zu DISTINCT besteht aber darin, dass mit DISTINCTROW immer ganze Datensätze verglichen werden. Mit dem DISTINCTROW-Prädikat werden Wiederholungen in Abfragen mit 1:N-Verknüpfungen unterdrückt. DISTINCTROW liefert im Gegensatz zu DISTINCT eine bearbeitbare Abfrage zurück, also ein Dynaset. Access-SQL verwendet das Schlüsselwort TOP, um die Anzahl der Ergebniszeilen zu beschränken. Standard-SQL verwendet hier im Gegensatz zu Access-SQL den Befehl LIMIT TO N ROWS . SQL kennt die logischen Operatoren AND (UND), OR (ODER) und NOT (NICHT), die in WHERE-Bedingungen verwendet werden können. Access-SQL erlaubt bis zu 40 ANDs in einer WHERE-Klausel. Um einen Mustervergleich auszuführen, benutzt man den Operator LIKE . Die von Jet-SQL verwendeten Platzhalterzeichen entsprechen nicht dem ANSI-SQL-Standard. Man kann zusätzlich anstelle von „%“ das Zeichen „*“, beziehungsweise „?“ für „_“ verwenden. Dies gilt aber nur, wenn man in ANSI-89 SQL arbeitet. Access besitzt außer den Standard-Aggregatfunktionen SUM, AVG, MIN, MAX und COUNT

Kapitel 3

21

noch folgende weitere: Aggregatfunktionen Funktion Beschreibung First ([Spalte]) Spaltenwert der ersten Zeile des Ergebnisses, kann Null sein Last ([Spalte]) Spaltenwert der letzten Zeile des Ergebnisses Stdev ([Spalte]) Standardabweichung einer Stichprobe der Spaltenwerte Stdevp ([Spalte]) Standardabweichung der Grundgesamtheit der Spaltenwerte Var ([Spalte]) Varianz der Stichprobe der Spaltenwerte Varp ([Spalte]) Varianz der Grundgesamtheit der Spaltenwerte JET-SQL kennt INNER und RIGHT /LEFT (OUTER) JOIN . Man kann bis zu 32 Tabellen mit Hilfe von JOINs miteinander verknüpfen. Dabei sollte man beachten, dass bei der Verknüpfung mehrerer Tabellen INNER JOIN s und LEFT bzw. RIGHT JOIN s nicht beliebig verschachtelt werden können. Es ist zwar möglich, einen LEFT oder RIGHT JOIN innerhalb eines INNER JOIN s zu verwenden, aber nicht umgekehrt. Die klassischen Operatoren der Mengenlehre wie Durchschnitt oder Differenz kennt Jet-SQL nicht. Jet-SQL unterstütz nur UNION als einzigen Mengenoperator. Außerdem können Access-Abfragen Parameter enthalten. Parameter ermöglichen die Eingabe von Werten während der Auswertung einer SQL-Abfrage, ohne die Abfragedefinitionen zu verändern. Parameter können sowohl in der WHERE-Bedingung als auch in der HAVING-Klausel eingesetzt werden. SELECT A.name FROM a WHERE Parameter=a.name; Wird die Abfrage ausgeführt, erscheint das folgende Dialogfeld (Abbildung 3.5), um einen Wert für den Parameter entgegenzunehmen.

Abbildung 3.5

Eine in Abfragen sehr hilfreiche Funktion ist IIF() . Diese Funktion besitzt drei Argumente: IIF(Bedingung, Wahr, Falsch) . Falls die Bedingung erfüllt ist, wird der Wahr-Teil ausgeführt, ansonsten der Falsch-Teil. Darüber hinaus kennt Jet-SQL weder materialisierte noch rekursive Sichten. Ein Jet-SQL-String darf nicht größer als 64 KB sein. Access erlaubt es, die SELECTs bis zu 50 Ebenen tief zu schachteln. In JET-SQL fehlt die Anweisung CREATE VIEW, das SELECT-


22

Statement wird einfach in das Auswahlabfragefenster der entsprechenden Sicht geschrieben.

3.6 VBA (Visual Basic for Applications)

VBA (Visual Basic for Applications) [Sta99] ist die objektorientierte Programmiersprache von Microsoft, die nicht nur in Access, sondern in allen Office-Anwendungen dem Anwender zur Verfügung steht. VBA erlaubt es dem Anwender nicht nur, Funktionen zu programmieren oder Berechnungen durchführen, sondern sogar Tabellen und Datenbanken anzulegen und zu manipulieren. Allerdings steht in Access kein Makro-Recorder wie z.B. in Excel oder Word zur Verfügung, der Aktionen von Access aufzeichnen und damit das Entwerfen von Programmcode erleichtern würde.

3.6.1 Visual Basic-Entwicklungsumgebung

Projekte, Formulare und Module Die Organisierung von VBA ist mit Access so geändert worden, dass sie derjenigen in Visual Basic als Einzelversion und in den anderen Office-Anwendungen gleicht. Das heißt: VBA ist in Projekten organisiert. Jedes Projekt enthält die Module und Klassenobjekte (Code-Module von Formularen und Berichten) der geöffneten Datenbank. VBA-Code wird als Text geschrieben und in Modulen abgelegt. Es gibt drei Arten von Modulen: Formular- und Berichtsmodule: Sie werden im Visual Basic-Editor als Klassenobjekte angezeigt. Alle Ereignisprozeduren eines bestimmten Formulars oder Berichts werden in einem Modul festgehalten, welches in das Formular bzw. den Bericht integriert ist. Prozeduren dieser Module können nicht von anderen Access-Objekten aus aufgerufen werden. Globale Standardmodule sind nicht an ein Formular oder einen Bericht gebunden. Globale Module werden zusammen mit der Datenbank gespeichert. Man kann alle benötigten Funktionen und Sub-Prozeduren in einem globalen Standardmodul hinterlegen. Davon wird aber abgeraten. Die Prozeduren eines Modul, die nicht explizit als privat deklariert sind, können von allen Prozeduren aus aufgerufen werden, egal in welchen Modulen sie sich befinden. Ein globales Standardmodul wird im Datenbankfenster durch das links daneben stehende Symbol gekennzeichnet. Globale Klassenmodule: In einem Klassenmodul werden benutzerdefinierte Objekte erstellt. Die Prozeduren des Klassenmoduls werden dabei zu Methoden und Eigenschaften des Objekts. Ein globales Klassenmodul wird im Datenbankfenster durch das links daneben stehende Symbol gekennzeichnet.

3.6.2 Objekte, Methoden, Eigenschaften

Die meisten Access-Elemente können als Objekte betrachtet und angesprochen werden. Ein Beispiel für ein Objekt ist Form (Formular). Objekte besitzen Eigenschaften und Methoden, über die sie gesteuert werden. Beispielsweise hat ein Objekt Form die Eigenschaft Visible , welche wiederum verschiedene Einstellungen besitzen kann. Wird

Kapitel 3

23

diese Eigenschaft eines bestimmten Formulars auf den Wert False gesetzt, so wird das Formular ausgeblendet; durch die Eigenschaftseinstellung True wird es hingegen angezeigt. Die meisten Eigenschaften von Objekten lassen sich mit VBA verändern. Bestimmte Eigenschaften können aber nur gelesen werden. Objekte besitzen außer Eigenschaften auch Methoden. Die Methode eines Objekts führt im Allgemeinen eine Aktion aus. Beispielsweise besitzt das Objekt Form die Methode Requery. Diese Methode aktualisiert die zugrunde liegenden Daten des angegebenen Formulars durch erneutes Abfragen der Datenherkunft des Formulars. Das Objektmodell stellt gleiche Objekte als ein Objekt dar. Dieses Objekt wird Auflistungs-Objekt bezeichnet. So werden etwa alle geöffneten Berichte im Objekt Reports gesammelt (siehe Abbildung 3.4-1). Um auf ein bestimmtes Objekt des Auflistungs-Objekts zuzugreifen muss es hinter dem Namen des Auflistungs-Objekts angeben werden. Dabei kann dieses bestimmte Objekt dann durch seinen Namen oder über seine fortlaufende Nummer im Auflistungs-Objekt identifiziert werden. Es ist hier zu beachten, dass die fortlaufende Nummerierung der Objekte in einem Auflistungs-Objekt mit 0 beginnt. Will man alle Objekte eines Auflistungs-Objekts ansprechen, so sollte man am besten eine For Each ... Next-Schleife verwenden.

3.6.3 VBA-Grundlagen

Variablen können implizit oder explizit deklariert werden. Bei expliziter Deklaration kann der Datentyp, der Gültigkeitsbereich sowie die Lebensdauer der Variablen festgelegt werden. Variablen werden explizit mit einer der Anweisungen Dim, Public , Private oder Static deklariert. Alle implizit oder explizit in einer Prozedur deklarierten Variablen gelten nur für diese Prozedur – es sind lokale Variablen. Damit eine Variable für alle Prozeduren desselben Moduls (aber nicht für andere Module) sichtbar ist, muss sie im Deklarationsteil des Moduls mit der Anweisung Dim deklariert werden. Auf Variablen kann von allen Prozeduren und allen Modulen aus zugegriffen werden, wenn sie im Deklarationsteil eines Moduls mit der Anweisung Public deklariert werden. Der Gültigkeitsbereich hat Einfluss auf die Lebensdauer. Lokale Variablen verlieren ihre Werte, sterben also, wenn die Prozedur, in der sie deklariert sind, beendet ist. Variablen mit einem modularen oder öffentlichen Gültigkeitsbereich bleiben dagegen erhalten, bis die Datenbank geschlossen wird oder ein Laufzeitfehler auftritt. Man kann die Lebensdauer einer lokalen Variablen verlängern, indem man sie als Static deklariert. Die Variable wird so lange gültig bleiben, wie die Datenbank geöffnet ist. Den Konstanten wird bei der Deklaration ein Wert zugewiesen. Sie werden durch das Schlüsselwort Const als Konstante deklariert. Programme in VBA werden entweder als Funktionen oder als Sub-Prozeduren geschrieben. Die Syntax der Sub- und Function -Anweisungen lautet: [Public | Private ] [Static ] Sub Prozedurname [(Argumentliste)] [Public | Private ] [Static ] Function Prozedurname [(Argumentliste)] As Typ


24

Soll eine Prozedur von allen Prozeduren aus aufgerufen werden können – egal in welchen Modulen sie sich befinden –, so muss man sie als Public deklarieren. Prozeduren werden aber auch implizit als öffentlich deklariert. Eine Ausnahme bilden die Ereignisprozeduren, die automatisch als privat deklariert werden. Als Private deklarierte Prozeduren lassen sich nur aus Prozeduren des gleichen Moduls heraus aufrufen. Unabhängig davon, ob eine Prozedur als Public oder als Private deklariert ist, darf sie in jedem Fall zusätzlich auch als Static deklariert werden. Dies hat zur Folge, dass die Inhalte aller lokalen Prozedurvariablen bis zum nächsten Prozeduraufruf erhalten bleiben und nicht wie sonst nach dem Beenden der Prozedur gelöscht werden. Funktionen und Prozeduren unterscheiden sich in den folgenden Punkten:

• Funktionen können einen Wert ausgeben, Prozeduren dagegen nicht. • Funktionen können auf allen Access-Ebenen, etwa in Formularen, aufgerufen

werden, Prozeduren dagegen nur von VBA-Prozeduren. VBA kennt Schleifen und Verzweigungen. Die Schleifen werden durch Do ... Loop , While ... Wend und For [Each ] ... Next realisiert. Für die Verzweigungen existieren If ... Then und Select Case ... End Select .

Kapitel 4

25

4 Deduktive Datenbanken

Dieses Kapitel gibt eine allgemeine Einführung in das Thema Deduktive Datenbanken mit der Anfragesprache Datalog und geht detailliert auf die Problematik der Änderungspropagierung ein. Die Darstellung orientiert dabei sich an der Vorlesung „Deduktive Datendanken“ von Professor Dr. Rainer Manthey [Man01]. Hierbei werden Beispiele aus einer speziell für diese Diplomarbeit erstellten Datenbank überall dort eingesetzt, wo dies für das Verständnis und die Veranschaulichung der wichtigsten Vorgänge erforderlich ist.

4.1 Deduktive Datenbanken

Bei deduktiven Datenbankensystemen ([Man00], [KE01]) handelt es sich um eine Erweiterung eines im Prinzip beliebigen Datenmodells um ein Regelkonzept. Es gibt deduktive und normative Regeln. Deduktive Regeln entsprechen dabei den Sichtdefinitionen, normative Regeln (Integritätsbedingungen) hingegen den Assertions in SQL. In dieser Arbeit versuche ich, einige der Datalog-Konzepte in eine MS Access Datenbank zu implementieren. Da Access eine relationale Datenbank ist, die das Assertions-Konzept nicht unterstützt, werden hier nur deduktive relationale Datenbanken und keine normativen Datalog-Regeln betrachtet. Eine deduktive Regel wird durch einen deklarativen Ausdruck spezifiziert und beschreibt durch eine allgemeine Gesetzmäßigkeit eine Menge von impliziten (intensionalen, ableitbaren) Daten (IDB), welche aus einer Menge expliziter (extensionaler, Basis-) Daten (EDB) herleitbar sind. Die Anfragesprache für deduktive Datenbanken heißt Datalog – abgeleitet vom Wort "Data" sowie dem Namen der Logikprogrammiersprache Prolog. Es gibt jedoch auch bei herkömmlichen relationalen Datenbanken mit der Abfragesprache SQL eine Analogie zu EDB und IDB:

• Die Basisrelationen entsprechen der EDB. • Die in SQL mittels des CREATE VIEW-Konstruktes definierten Sichten entsprechen

der IDB.

Deduktive Datenbanken _

26

4.2 Datalog

Datalog basiert auf einem relationalen Bereichskalkül (DRC) [KE01]. Die Syntax von Datalog-Regeln ist stark von der logischen Programmiersprache Prolog beeinflusst. Obwohl die Semantik von Prolog instanzenorientiert ist, verfügt sie jedoch auch wie andere DB-Sprachen über eine mengenorientierte Semantik.

4.2.1 Grundlagen

Die Grundbausteine der deduktiven Regeln sind atomare Formeln (auch Literale genannt), die folgende Gestalt haben: q(A1, ..., Am).

q ist entweder der Name einer Basisrelation (EDB-Relation), der Name einer abgeleiteten (IDB-)Relation oder ein eingebautes Prädikat (≠, >, <, <= usw.), auch Vergleichsliteral genannt [Man00]. Bei den eingebauten Vergleichsprädikaten benutzt man häufig die gebräuchlichere Infixnotation, also X<Y anstatt <(X,Y). Bei Ai(1<=i <=m) handelt es sich entweder um Variablen oder Konstanten. Variablen sind Buchstaben oder Zeichenreihen, die in Anlehnung an die Prolog-Konventionen mit einem Großbuchstaben beginnen. Konstanten sind Ziffern, Kleinbuchstaben oder Zeichenreihen, die mit Kleinbuchstaben oder Ziffern beginnen. Relationsnamen sind Zeichenreihen, die mit Kleinbuchstaben beginnen. Fakten werden als atomare Formeln dargestellt, deren Parameter lauter Konstanten sind. Eine Datalog-Regel hat folgende Form: p(X1,…,Xm) ← q1(A11,…,A1m1

),..,qn(An1,..,Anmn).

Es muss hierbei gelten:

• Jedes qj(...) ist eine atomare Formel. Die qj werden oft auch als Subgoals bezeichnet.

• X1,…,Xm sind Variablen, die mindestens einmal auch auf der rechten Seite des

Zeichens ← vorkommen müssen. Den linken Teil der Regel, also p(...), bezeichnet man als den Kopf (Engl. head) und den rechten Teil als den Rumpf (Engl. body). Diese Form von Regeln bezeichnet man auch als Horn-Klausel. Die Bedeutung dieser Regel ist: Wenn q1(...) und q2(...) und ... und qn(...) wahr sind, dann ist auch p(...) wahr.

Man kann die oben vorgestellte Formel auch wie folgt schreiben: p(...) ∨ ¬ q1( A11,…A1m1

) ∨ ...∨ ¬ qn( An1,..Anmn ).

Kapitel 4

27

Eine IDB-Relation p wird im Algemeinen durch mehrere Regeln mit dem Kopf p(...)←... definiert. Die EDB-Relation kommt dabei nicht auf der linken Seite einer Regel, sondern nur als Subgoal auf der rechten Seite vor, welche die IDB-Relation definiert. IDB-Relationen können aber durchaus – sogar rekursiv – aufeinander aufbauen, so dass sie auch als Subgoals auf der rechten Seite einer Regel auftreten können. Mit Hilfe des so genannten Abhängigkeitsgraphen kann man feststellen, ob eine Datalog-Regel rekursiv ist. Hierfür wird für jede in der Datalog-Regel vorkommende Relation ein Knoten des Graphen gebildet. Die Vergleichsprädikate (wie ≠, >, <, <= usw.) können dabei vernachlässigt werden. Für jede Regel der Form p(...)← q1(...),....,qn(...) werden n Kanten der Form q1→ p ,..., qn→ p eingefügt – falls sie nicht schon vorhanden waren. Eine Datalog-Regel ist genau dann rekursiv, wenn der Abhängigkeitsgraph zyklisch ist – falls also mindestens ein Zyklus vorhanden ist. Um das Pendant zur Mengendifferenz in der Relationenalgebra in Datalog ausdrücken zu können, benötigt man die Negation der Prädikate im Regelrumpf. Eine Regel mit einem negierten Prädikat im Rumpf ist: p(...) ←q1(...),...,not qi(...),...,qn(...). Dabei geht man von der Annahme aus, dass ein Fakt, der weder in der Datenbank gespeichert noch durch die Regeln von den Basisfakten abgeleitet werden kann, den Wahrheitswert false hat. Alle ableitbaren sowie in der Datenbank gespeicherten Fakten haben hingegen den Wahrheitswert true. Diese Annahme wird „close world assumption“ (CWA) genannt. Das dazugehörige Auswertungsprinzip für negative Literale heißt „Negation as failure“. Das heißt, ein negierter Fakt hat nur dann den Wahrheitswert true, wenn der entsprechende positive Fakt weder in der IDB noch in der EDB enthalten ist. Ein weiterer wichtiger Aspekt, den man hier unbedingt erwähnen sollte, ist die Sicherheit von Datalog-Regeln. Es gibt unsichere Regeln, wie z.B.: ungleich(X, Y) ← X ≠ Y, die unendliche Relationen definieren. Es gibt unendlich viele Paare, die ungleich sind. Eine Datalog-Regel ist nur dann sicher, wenn alle Variablen eingeschränkt sind. Eine Variable X ist in einer bestimmten Regel eingeschränkt, falls

• die Variable im Rumpf der Regel in mindestens einem positiven Literal – also nicht nur in eingebauten Vergleichsprädikaten – vorkommt,

• ein Prädikat der Form X = c mit einer Konstante c im Rumpf der Regel existiert;

• ein Prädikat der Form X = Y im Rumpf vorkommt, und man bereits nachgewiesen hat,

dass Y eingeschränkt ist. Aus der oben gegebenen Definition einer sicheren Regel folgt auch, dass eine Regel mit Negation nur dann sicher ist, wenn alle Variablen aus einem negierten Literal auch in mindestens einem positiven Literal vorkommen


28

4.2.2 Auswertung von Datalog-Regeln

Auswertung von nicht-rekursiven Datalog-Programmen Wie geht man systematisch vor, um IDB-Relationen herzuleiten? Die Grundidee besteht darin, für den zyklenfreien Abhängigkeitsgraphen eine topologische Sortierung der Knoten zu finden, so dass in der Sortierreihenfolge der Knoten q vor einem Knoten p steht, falls es im Abhängigkeitsgraphen eine (gerichtete) Kante von q nach p (also q→p) gibt. IBD-Relationen werden dann in der Reihenfolge der topologischen Sortierung hergeleitet (materialisiert). Auswertung rekursiver Regeln Die Grundidee bei der Auswertung von rekursiven Regeln besteht darin, die IDB-Relationen schrittweise zu bestimmen. Man fängt dabei mit leeren IDB-Relationen an und generiert sukzessive neue Tupel dafür. Bei der Herleitung neuer Tupel werden Tupel verwendet, die in vorhergehenden Schritten generiert wurden. Der Vorgang wird abgebrochen, sobald sich keine neuen Tupel mehr generieren lassen. Formal gesehen wird bei dieser Vorgehensweise auf der Basis gegebener EDB-Relationen der kleinste Fixpunkt für die IDB-Relationen bestimmt. Eine Regel mit einem negierten Prädikat im Rumpf, wie z.B.: r ≡ p(...) ←q1(...),...,not qi(...),...,qn(...). kann nur dann sinnvoll ausgewertet werden, wenn alle Regeln mit dem Kopf qi(...)←... schon vorher ausgewertet wurden. Dies ist aber nur möglich, wenn qi nicht abhängig vom Prädikat p ist und der Abhängigkeitsgraph keinen Pfad von p nach qi enthält. Wenn dies für alle Regeln und alle negierten Subgoals (Literale im Rumpf) gewährleistet ist, so ist die gegebene Regelmenge stratifizierbar. Die Bezeichnung "stratifizieren" entstammt dem lateinischen Wort strata (Schicht). Demnach werden die Regeln bei dem Vorgang in verschiedene Schichten unterteilt, sodass die Negation sich stets auf die Relation der tieferen Ebene bezieht. Jetzt lässt sich die iterierte Fixpunktberechnung für jede Schicht einzeln durchführen. Die Schichten werden dabei von unten nach oben abgearbeitet. Hier werden nun formale Definitionen für eine deduktive Datenbank und deren Semantik gegeben [Man00]: Definition 4.1( Deduktive Datenbank) Eine deduktive Datenbank ist ein Tupel D = <F,R> mit F – eine endliche Menge der Basisfakten und R – eine endliche Regelmenge. Definition 4.2 (Ableitungsoperator) Sei D = <F,R> eine deduktive Datenbank mit F – eine endliche Faktenmenge und R – eine endliche, nichtleere Regelmenge mit

Kapitel 4

29

Ri ≡ A ← B1,…,Bn, not C1,…,not Cm. Dann ist die Menge der durch R aus F ableitbaren Fakten durch den Ableitungsoperator T gegeben: 1. T[Ri](F ) := { Aσ | σ ist eine konsistente Variablensubstitution, so dass ∀ 1≤ j ≤ n: Bj σ ∈F und ∀ 1≤ k ≤ m: Ck σ ∈F gilt }, wobei F eine Faktenmenge ist mit F ≠ F. 2. T[R](F ) :=

iR R∈∪ T[Ri](F ) ist das Resultat der Anwendung aller Regeln der

Regelmenge R auf dieselbe Menge F. 3. T*[R] (F ) := T[R](F ) ∪ F ist das Resultat der Anwendung mehrstufiger Ableitungsregeln, wobei die jeweilige Inputmenge auch ein Teil der Inputmenge der nächsten Sicht ist. Unter einer konsistenten Variablensubstitution versteht man die Ersetzungen aller Variablen durch Konstanten, so dass jedes Vorkommen derselben Variablen durch dieselbe Konstante ersetzt wird. Definition 4.3 ( Stratifikation) Sei D = <F,R> eine deduktive Datenbank mit F – eine endliche Faktenmenge und R – eine endliche, nichtleere Regelmenge . Unter einer Stratifikation λ bezüglich der Regelmenge R versteht man eine Abbildung der Menge der Relationsnamen der Datenbank D RelD auf die Menge der natürlichen Zahlen (Schichtnummern) IN0 : λ: RelD→ IN0. Dabei muss gelten: p eine Basisrelation ⇔ λ(p) = 0 p eine abgeleitete Relation ⇔ λ(p) ≥ 1 p,q ∈ RelD und p hängt positiv von q ab ⇔ λ(q)≤ λ(p) p,q ∈ RelD und p hängt negativ von q ab ⇔ λ(q) < λ(p). Eine deduktive Datenbank heißt stratifizierbar, wenn mindestens eine Stratifikation von Relationen der Datenbank existiert. Eine deduktive Datenbank heißt nichtstratifizierbar, wenn keine Stratifikation von Relationen der Datenbank existiert. Definition 4.4 (Fixpunksemantik deduktiver Datenbanken)

• Ist = <F,R> eine (semi-) positive Datenbank. Dann ist die Bedeutung von D der kleinste Fixpunkt F* := lfp(T*[R] (F) )

• Ist D = <F,R> eine stratifizierbare Datenbank und {R1,…,Rm} eine Stratifikation von D. Dann ist die Bedeutung von D der kleinste Fixpunkt F* := Fm, wobei gilt:

F0:= F Fi := lfp(T*[Ri] (Fi-1) ) mit 1≤ i ≤ m


30

Wobei Lfp(F, M) („least fix point“) für den kleinsten Fixpunkt einer Funktion f steht, der Argument M enthält. Bottom-Up oder Top-Down Auswertung Die beschriebene Auswertungsmethode für Datalog-Programme wird auch Bottom-Up Auswertung genannt, weil man, ausgehend von den EDB-Relationen (also der Faktenbasis), die gesamte intensionale Datenbasis in einem Stück berechnet. Diese Methode der Auswertung hat allerdings einen Nachteil: Wenn man nur an einem kleinen bestimmten Teil der IDB-Relation(en) interessiert ist, wird bei der Bottom-Up Auswertung trotzdem und unnötigerweise die gesamte intensionale Datenbasis berechnet und erst danach der relevante Teil aus der IDB extrahiert. Dieser Nachteil wird bei der so genannten Top-Down Auswertung vermieden. Um das Ziel zu beweisen, geht man dabei von der Anfrage aus und geht rückwärts zu den Fakten der EDB. Eine nicht weniger effektive Vorgehensweise für die Datalog-Anfragenbearbeitung bietet die Magic Sets Methode [BMS86] an. Ein nicht zu verkennender Punkt ist die Ausdruckskraft des Datalogs. Die Sprache Datalog, beschränkt auf nicht-rekursive Programme, dafür aber erweitert um die Negation, hat die gleiche Ausdruckskraft wie die relationale Algebra. Mit Negation und Rekursion geht Datalog sogar über die Ausdruckskraft der relationalen Algebra hinaus. Beispiel 4.1 So sehen die Sichten aus dem Beispiel 2.2 deutscher_Bücher und deutsche_Belletristik aus, niedergeschrieben in Form einer Datalog-Regel: deutscher_Bücher(Autor,Titel,Art) ← bücher(Autor,Titel,Art), autor(Autor,“Deutschland“). deutsche_Belletristik[Autor,Titel,Art] ← deutscher_Bücher[Autor,Titel,Art], not fachliteratur[Autor,Titel].

4.3 Änderungspropagierung

Eine deduktive Datenbank enthält virtuelle und materialisierte (also gespeicherte) Sichten. Virtuelle Sichten werden für jeden Zugriff neu berechnet. Bei materialisierten Sichten wird der Inhalt in der Datenbank gespeichert. Diese Sichten werden bei Erstellung einmal berechnet und gespeichert. Auf sie kann man jederzeit zugreifen, ohne sie jedes Mal neu zu berechnen. Zugriffe auf materialisierte Sichten sind somit, aufgrund der ausbleibenden Neuberechnung, effizienter als Zugriffe auf virtuelle Sichten.

4.3.1 Motivation

Durch Änderungsoperationen auf der Datenbank können sich die Einträge einer Sicht ändern. Im Falle von virtuellen Sichten stellt dies kein Problem dar, da die Sichten bei jedem Zugriff neu berechnet werden. Bei den materialisierten Sichten ergibt sich jedoch

Kapitel 4

31

manchmal die Schwierigkeit, da die gespeicherten Daten nicht mehr der aktuellen Datenbasis entsprechen und deshalb aktualisiert werden müssen. Eine naive Möglichkeit der Aktualisierung ist die Rematerialisierung der Sichten. Dabei wird der gesamte Inhalt der materialisierten Sicht gelöscht und dann neu berechnet. Wenn sich nur ein kleiner Teil der Daten geändert hat, dann ist die Rematerialisierung sehr ineffizient. Wenn die Änderungen im Verhältnis zu den enthaltenen Daten insgesamt relativ gering ausfallen, so ist die inkrementelle Anpassung hingegen viel effizienter. Bei dieser wird zunächst festgestellt, wie sich die Änderungen von Basisdaten auf die materialisierten Sichten auswirken und nur noch die induzierten Änderungen der materialisierten Sichten berechnet. Änderungspropagierung ist somit ein Prozess der „Fortschreibung“ von Änderungen an Basisrelationen auf die davon abhängigen abgeleiteten Relationen.

4.3.2 Delta-Regeln

Unabhängig von den gegebenen Basisfakten und deren Änderungen werden die Propagie-rungsregeln (auch Delta-Regeln genannt) aus den gegebenen deduktiven Regeln erstellt. Wie schon in Abschnitt 3.1 erwähnt, werden in dieser Arbeit nur deduktive Regeln betrachtet. Die erstellten Propagierungsregeln sind die so genannten „Delta-Relationen". Die durch Delta-Regeln definierten Relationen (Delta-Relationen) stellen die echten Faktenänderungen der abgeleiteten Relationen, die durch die Basisfaktenänderungen verursacht wurden. Ein Fakt wird als echte Einfügung betrachtet, wenn er im neuen, aber nicht im alten Datenbankzustand ableitbar ist. Analog dazu wird ein Fakt echt aus der aktuellen Datenbank gelöscht, wenn er im alten Zustand ableitbar war, jedoch im jetzigen, neuen Zustand nicht mehr ableitbar ist. Definition 4.5(Propagierungsregeln für echte Änderungen) Sei R eine stratifizierbare deduktive Regelmenge. Für jede Regel A ← L1, ... , Ln aus R und für jedes Rumpfliteral Li mit i in [1,...,n] haben die positiven und negativen Propagierungsregeln folgende Form: A+ ← L +i , new(L 1,.., L i-1 , L i+1 ,.., L n), not A old mit L i ≡L

A+ ← L -i , new(L 1,.., L i-1 , L i+1 ,.., L n), not A old mit L i ≡not L

A- ← L -i , old(L 1,.., L i-1 , L i+1 ,.., L n), not A new mit L i ≡L

A- ← L +i , old(L 1,.., L i-1 , L i+1 ,.., L n), not A new mit L i ≡not L

Aus der Tatsache, dass für jedes Rumpfliteral eine Delta-Plus-Regel und eine Delta-Minus-Regel erstellt wird, ergibt sich der Fakt, dass für eine Regel mit n Rumpfliteralen insgesamt 2n Delta-Regeln existieren.


32

Es kann passieren, dass durch die Delta-Regeln einige schon bekannte Fakten noch einmal hergeleitet werden. Dabei versteckt sich die Quelle der Fehler stets in einer Konstellation, bei der Duplikate bei den Ableitungen entstehen und damit Mehrfachableitungen ein und desselben Fakts möglich werden. Um solche Mehrfachableitungen, die schon vor der Einfügung existiert haben können, zu entdecken und damit eine fehlerhafte Herleitung von Deltafakten zu vermeiden, ist es erforderlich, in die Deltaregeln zusätzlich einen Test auf Ableitbarkeit einzubauen. Der Effektivitätstest auf Aold bzw. Anew prüft nach, ob der durch die Delta-Regeln gewonnene Fakt nicht im alten bzw. neuen Datenbankzustand alternativ herleitbar bzw. überhaupt noch herleitbar ist. Diese Maßnahme ist aber nur dann erforderlich, wenn die jeweilige Relation durch mehrere Regeln definiert ist (Vereinigung) oder wenn sie definierende Regeln lokaler Variablen enthält (Projektion). Um unseren Algorithmus für die Herleitung der Delta-Regeln zu vereinfachen, wird ein Effektivitätstest in jede Delta-Regel eingebaut. Beispiel 4.2- (Kodierung eines Propagierungsschritts mittels Delta-Regeln, Delta-Regeln für Relationen aus dem Beispiel 4.1) deutscher_Bücher +[Autor,Titel,Art] ← bücher +[Autor,Titel,Art], autoren new[Autor,“Deutschland“], not deutscher_Bücher old [Autor,Titel,Art] deutscher_Bücher +[Autor,Titel,Art] ← bücher new[Autor,Titel,Art], autoren +[Autor,“Deutschland“], not deutscher_Bücher old [Autor,Titel,Art] deutscher_Bücher - [Autor,Titel,Art] ← bücher - [Autor,Titel,Art], autoren old[Autor,“Deutschland“], not deutscher_Bücher new[Autor,Titel,Art] deutscher_Bücher - [Autor,Titel,Art] ← bücher old[Autor,Titel,Art], autoren - [Autor,“Deutschland“], not deutscher_Bücher new[Autor,Titel,Art] deutsche_Belletristik + [Autor,Titel,Art] ← deutscher_Bücher +[Autor,Titel,Art], not fachliteratur new[Autor,Titel], not deutsche_Belletristik old [Autor,Titel,Art] deutsche_Belletristik + [Autor,Titel,Art] ← deutscher_Bücher new[Autor,Titel,Art], fachliteratur - [Autor,Titel], not deutsche_Belletristik old [Autor,Titel,Art] deutsche_Belletristik - [Autor,Titel,Art] ← deutscher_Bücher - [Autor,Titel,Art],

Kapitel 4

33

not fachliteratur old[Autor,Titel], not deutsche_Belletristik new[Autor,Titel,Art] deutsche_Belletristik - [Autor,Titel,Art] ← deutscher_Bücher old[Autor,Titel,Art], fachliteratur +[Autor,Titel], not deutsche_Belletristik new[Autor,Titel,Art]

4.3.3 Transitionsregeln

Die im vorigen Abschnitt behandelten Propagierungsregeln für echte Änderungen haben den Nachteil, dass für die Herleitung der Delta-Relationen sowohl der alte als auch der neue Datenbankzustand notwendigerweise vorhanden sein muss. Bei Einfügungen werden Effektivitätstests im "alten" Zustand der DB ausgeführt (vor der Ausführung der jeweiligen Änderungen). Die Effektivitätstests bei Löschungen werden hingegen im "neuen" Zustand ausgeführt (nach den Änderungen). Sollte man beides vorhaben, also Einfügungen und Löschungen gleichermaßen benötigen, so müssten beide Zustände gleichzeitig zur Verfügung stehen. Dieses Problem löst man, indem man sich dazu entscheidet, einen der benötigen Datenbankzustände zu simulieren. "Simulieren" bedeutet dabei, dass zunächst für jede Basisrelation der neue Zustand durch eine abgeleitete Hilfsrelation definiert wird. Der Vorteil einer solchen „Simulation" ist, dass der aktuelle Zustand dann vollkommen ausreicht. Die deduktiven Regeln, welche für diese Simulation von Zuständen gebildet werden, nennt man Transitionsregeln. Die Entscheidung darüber, welcher Zustand simuliert wird, ist eine Designfrage und hängt von der gegebenen Datenbank und ihren Restriktionen in Form von Integritätsbedingungen ab. Die Simulation des alten Zustands bezeichnet man als „optimistischen" Ansatz. Der optimistische Ansatz trägt die gewünschten Basisdatenänderungen direkt in die Datenbank ein. Dabei nimmt man an, dass die danach berechneten Folgeänderungen keine Integritätsbedingungen der Datenbank verletzen. Im Falle von Verletzungen muss ein Rollback durchgeführt werden. Die Simulation des neuen Zustands wird dagegen als „pessimistischer" Ansatz bezeichnet. Der pessimistische Ansatz trägt die gewünschten Basisdatenänderungen nicht in die Datenbank ein. Die Änderungen der Basisdaten und abgeleiteten Relationen werden erst dann in die Datenbank übertragen, wenn man sicher ist, dass sie keine der vorhandenen Integritätsbedingungen verletzen. Im Falle von Verletzungen werden die berechneten Änderungen dann verworfen. Da in dieser Arbeit versucht wird, die Änderungspropagierung in den SQL-Kontext am Beispiel der MS Access Datenbank zu übertragen, und Access solche Restriktionen wie die referentielle Integrität unterstützt, werden dort die möglichen Integritätsverletzungen bei den Datenänderungen erwartet. Somit wird schon an dieser Stelle entschieden, den neuen Zustand zu simulieren. Sei U eine Transaktion, dann erhält man Fnew (neuer Datenbankzustand) aus Fold (alter Datenbankzustand), auf die man die Transaktion U angewendet hat (Abbildung 4.1).


34

Abbildung 4.1 [Man00] Dabei enthält F+ alle Einfügungen durch U, während sich in F- alle Löschungen mittels U befinden, und es gilt: Alle Änderungen sind echt: F + ∩ F old = ∅∅∅∅ F - ∩ F old = F - Nettoeffekte sind bereits bestimmt: F + ∩ F - = ∅∅∅∅ Dann besteht folgender Zusammenhang: Fnew = (Fold –F-) U F+. Diese Gleichung auf der Faktenebene für die Basisrelation Autoren (Autor, Land) aus Beispiel 4.2 kann man wie folgt darstellen: autoren new (Autor, Land) ← autoren old (Autor, Land), not autoren - (Autor, Land). autoren new (Autor, Land) ← autoren + (Autor, Land) Diese beiden Transitionsregeln in Bezug auf die ursprüngliche Basisrelation nennt man auch inkrementelle Transitionsregeln. Der neue Zustand Autorennew (Autor, Land) wird aus dem alten Zustand Autorenold (Autor, Land) gebildet, indem die zu löschenden Fakten Autoren- (Autor, Land) vom alten Zustand abgezogen werden. Zusätzlich sind durch die Vereinigung im neuen Zustand die einzufügenden Fakten aus Autoren+ (Autor, Land) enthalten. Basierend auf den Annahmen, dass erstens immer der neue Zustand der Datenbank simuliert wird, und zweitens der aktuelle materialisierte Zustand der Datenbank der alte ist, werden im Folgenden die Kennzeichnungen der alten Zustände in den Prädikatssymbolen weggelassen. Verwendet man die inkrementellen Transitionsregeln für die abgeleiteten Relationen, so sieht es für die Relation deutsche_Belletristik[Autor,Titel,Art] samt den Delta-Regeln folgendermaßen aus:

Kapitel 4

35

deutsche_Belletristik new[Autor,Titel,Art] ← deutsche_Belletristik[Autor,Titel,Art], not deutsche_Belletristik - [Autor,Titel,Art] deutsche_Belletristik new[Autor,Titel,Art] ← deutsche_Belletristik +[Autor,Titel,Art] deutsche_Belletristik + [Autor,Titel,Art] ← deutscher_Bücher +[Autor,Titel,Art], not fachliteratur new[Autor,Titel], not deutsche_Belletristik[Autor,Titel,Art] deutsche_Belletristik + [Autor,Titel,Art] ← deutscher_Bücher new[Autor,Titel,Art], fachliteratur - [Autor,Titel], not deutsche_Belletristik[Autor,Titel,Art] deutsche_Belletristik - [Autor,Titel,Art] ← deutscher_Bücher - [Autor,Titel,Art], not fachliteratur[Autor,Titel], not deutsche_Belletristik new[Autor,Titel,Art] deutsche_Belletristik - [Autor,Titel,Art] ← deutscher_Bücher [Autor,Titel,Art], fachliteratur +[Autor,Titel], not deutsche_Belletristik new[Autor,Titel,Art] In diesem Beispiel ist zu erkennen, dass die alleinige Verwendung von inkrementellen Transitionsregeln zu resultierenden, nichtstratifizierbaren Regeln führt: deutsche_Belletristik - [Autor,Titel,Art] ← …, not deutsche_Belletristik new[Autor,Titel,Art] deutsche_Belletristik new[Autor,Titel,Art] ← …, not deutsche_Belletristik[Autor,Titel,Art] Die Relation deutsche_Belletristik- ist, über den negativ referenzierten Effektivitätstest not deutsche_Belletristiknew und die inkrementelle Transitionsregel, von sich selbst negativ abhängig. Glücklicherweise gibt es auch noch einen anderen Weg, Transitionsregeln für abgeleitete Relationen zu definieren – der neue Zustand des Kopfliterals ergibt sich dabei einfach aus den neuen Zuständen der Rumpfliterale.


36

Definition 4.6 (Transitionsregeln für echte Änderungen) Sei R eine stratifizierbare deduktive Regelmenge, dann haben die Transitionsregeln für echte Änderungen bezüglich der Simulation des neuen Zustands folgende Form: 1.(inkrementelle Transitionsregeln) Für jede Basisrelation A gibt es zwei Transitionsregeln der Form: A new ← A, not A –. A new ← A +. 2. (naive Transitionsregel) Für jede abgeleitete Regel A ← L1, ... , Ln ∈ R gibt es eine Transitionsregel der Form: A new ← L new1, ... , L newn Naive Transitionsregeln für die Relationen aus dem Beispiel 4.2: deutscher_Bücher new[Autor,Titel,Art] ← bücher new [Autor,Titel,Art], autoren new [Autor,“Deutschland“] deutsche_Belletristik new[Autor,Titel,Art] ← deutscher_Bücher new[Autor,Titel,Art], not fachliteratur new[Autor,Titel] Als Letztes sei noch gesagt, dass es mehrere Möglichkeiten gibt, Propagierungsregeln auszuwerten. Eine sehr effiziente Vorgehensweise stellt dabei die „Magic Updates"-Methode [Man00] dar.

Kapitel 5

37

5 Änderungspropagierung in SQL

Ähnlich wie in Datalog, führen auch Basisfaktenänderungen in SQL zu induzierten Sichtänderungen. In kommerziellen Datenbanken wie MS Access muss man normalerweise die Sicht komplett neu berechnen, um die induzierten Änderungen festzustellen. Die SQL-Sichtdefinitionen weisen eine gewisse Äquivalenz zu den Datalogregeln auf. Mit diesem Kapitel wird der Übergang von der Theorie zur Praxis vollzogen und gezeigt, wie mithilfe der Kenntnisse über Datalog-Propagierungsregeln eine Propagierungssicht in SQL erstellt werden kann. Die Hauptaufgabe dieser Arbeit ist die Konzeption und Programmierung einer Access-Datenbankerweiterung, welche die Sichtenänderungen zu bestimmen vermag, ohne die Sicht komplett ausrechnen zu müssen. Eine Vorgehensweise, bei der die SQL-Sichten erst in Datalog umgewandelt und dann, ausgestattet mit den Propagierungsregeln, in die SQL-Umgebung zurückgeholt werden, ist aber mühsam und uneffektiv. Daher wäre es nützlich, einen Algorithmus zu entwickeln, der die Delta-Sichten für die SQL-Sichten erstellt, ohne dass diese in eine datalogähnliche Form überführt werden müssen. Der Ausdruck "Delta-Sicht" im Kontext mit sichtbasierter Änderungspropagierung entspricht in dieser Arbeit dem Begriff "Deltaregel" im Datalogkontext. In diesem Kapitel wird die Theorie erklärt, die hinter dem Compiler steht. Abschnitt 5.1 stellt das Prinzip der Änderungspropagierung in einer SQL-Umgebung vor. In den Abschnitten 5.2 und 5.3 werden die Schwierigkeiten aufgeführt, die bei einer Änderungspropagierung in SQL auftreten können. In Abschnitt 5.4 wird das SQL-spezifische Konzept der Aggregatfunktionen bei der Änderungspropagierung erläutert. In Abschnitt 5.5 wird ein eigens für diese Arbeit erstellter Algorithmus zur Bildung der SQL-Propagierungssichten formuliert und an einem komplexeren Beispiel erklärt.

5.1 Das Prinzip

Zunächst soll hier versucht werden, Delta-/Transitionssichten für eine einfache SQL-Sicht zu entwickeln. Dabei geht man – in Anlehnung an die Datalog-Delta-/Transitionsregeln – intuitiv vor. Später werden die aus einfachen Beispielen gewonnenen Erkenntnisse auf komplexere Beispiele übertragen.

Änderungspropagierung in SQL _

38

Beispiel 5.1 (Die Sicht q ) In SQL SELECT a.Name FROM a, b, c WHERE a.Name=b.Name AND a.Name=c.Name; Die Sicht q in Datalog: q(y) ← a(y),b(y),c(y). In diesem Beispiel wird ein neuer Datenbankzustand nach der "pessimistischen" Methode simuliert. Wie bereits beschrieben, wird die Methode immer dann eingesetzt, wenn mögliche Integritätsverletzungen erwartet werden, und davon ausgegangen wird, dass die Änderungen wahrscheinlich gar nicht anwendbar sind. Für die relevanten Basisrelationen (Tabellen) (hier a, b und c) werden der Datenbank Hilfstabellen mit den Schlüsselwörtern Plus und Minus im Namen hinzugefügt (a_Plus, a_Minus, b_Plus, b_Minus, c_Plus, c_Minus). Dies sind Tabellen, bei denen man die Änderungen – in Plus-Tabellen die einzufügenden, in Minus-Tabellen die zu löschenden Fakten – zwischenspeichert. Außerdem wird für jede relevante Basisrelation eine inkrementelle Transitionssicht erstellt (a_New, b_New c_New). Für die betrachtete Sicht (hier q) werden zusätzliche Delta-Plus- und Delta-Minus-Sichten (q_Plus, q_Minus) sowie eine naive Transitionssicht (q_New) erstellt. Delta-Sichten in SQL entsprechen dabei den Delta-Regeln in Datalog. In Delta-Sichten werden nur die geänderten Fakten (in den Delta_Plus die Einfügungen, in Delta-Minus die Löschungen) angezeigt. Diese Fakten werden ermittelt, ohne die ursprüngliche Sicht (hier q) komplett zu berechnen. Delta-Plus/-Minus-Sichten sowie die Transitionssichten für q werden analog zu den Definitionen 5 und 6 verfasst: In Datalog q+(y) ← a +(y),b new(y),c new (y), not q(y). q+(y) ← a new (y),b +(y),c new (y) ,not q(y). q+(y) ← a new (y),b new (y),c +(y) ,not q(y). q- (y) ← a - (y),b(y),c(y), not q new (y). q- (y) ← a(y),b - (y),c(y), not q new (y). q- (y) ← a(y),b(y),c - (y), not q new (y) qnew(y) ← a new(y),b new(y),c new(y). anew (y) ← a(y), not a - (y). anew (y) ← a +(y) . bnew (y) ← b(y), not b - (y). bnew (y) ← b +(y). cnew (y) ← c(y), not c - (y). cnew (y) ← c +(y). Die Basisrelationen a, b und c haben dabei positive Polarität. Hier, wie auch im späteren Verlauf des Kapitels, wird der immer gleiche Ausdruck CREATE VIEW AS bei den Sichtdefinitionen weggelassen (was im Übrigen ja auch mit dem Operator CREATE VIEW bei der Sichtdefinition in Access-SQL geschieht, und das SELECT-Statement stattdessen einfach in das Auswahlabfragefenster der entsprechenden Sicht geschrieben).

Kapitel 5

39

Dasselbe in SQL: q_Plus: SELECT a_Plus.Name FROM a_Plus, b_New, c_New WHERE a_Plus.Name=b_New.Name AND a_Plus.Name = c_Ne w.Name UNION ALL SELECT a_New.Name FROM a_New, b_Plus, c_New WHERE a_New.Name=b_Plus.Name AND a_New.Name = c_New .Name UNION ALL SELECT a_New.Name FROM a_New, b_New, c_Plus WHERE a_New.Name=b_New.NameAND a_New.Name = c_Plus.Name; q_Minus: SELECT a_Minus.Name FROM a_Minus , b , c WHERE a_Minus.Name = b.Name AND a_Minus.Name = c.Na me UNION ALL SELECT a.Name FROM a , b_Minus , c WHERE a.Name = b_Minus.Name AND a.Name = c.Name UNION ALL SELECT a.Name FROM a , b , c_Minus WHERE a.Name = b.Name AND a.Name = c_Minus.Name; Dort, wo in Datalog mehrere Delta-Regeln mit dem gleichen Kopf stehen (q+ bzw. q-), werden in SQL die entsprechenden SELECT-Anweisungen durch den Operator UNION ALL in eine Sicht (q_Plus bzw. q_Minus) eingebunden. Der Operator UNION ALL eliminiert im Gegensatz zu UNION Duplikate aus der Ergebnismenge nicht. Hier wird der Operator UNION ALL verwendet, da SQL eine multimengenorientierte Sprache ist, und Sichten in SQL auch Duplikate enthalten können. Wo in Datalog für eine Regel mit n Rumpfliteralen jeweils n Delta_Plus- bzw. Delta_Minus-Regeln entstehen, entsteht in SQL nur eine Delta_Plus- Bzw. Delta_Minus-Sicht mit n SELECT-Anweisungen, die durch den Operator UNION ALL miteinander verbunden sind. Transitionsichten für q. q_New: SELECT a_New.Name FROM a_New, b_New, c_New WHERE a_New.Name=b_New.Name AND a_New.Name=c_New.Name;


40

a_New: SELECT * FROM a WHERE NOT EXISTS ( SELECT a_Minus.Name FROM a_Minus WHERE a.Name = a_Minus.Name ) UNION All SELECT * from a_Plus; Die c_New- und b_New-Sichten werden nach dem gleichem Muster gebildet. Was passiert, wenn der Operator OR im Where-Teil vorkommt ? Dieses Problem wird anhand einer Beispielsicht/ Regel r zuerst in Datalog, dann in SQL erläutert. Wie man weiß, wird der Operator OR in Datalog durch mehrere Regeln mit dem gleichen Kopf realisiert, was für die Delta-Regelerstellung kein Problem darstellt. r(y) ← a(y),b(y). r(y) ← a(y),c(y). r +(y) ← a +(y),B new(y),not r. r +(y) ← A new(y),B new(y), not r. r +(y) ← a +(y),C new(y), not r. r +(y) ← A new(y),C new(y), not r. r - (y) ← a - (y),b(y), not r new. r - (y) ← a(y),b - (y), not r new. r - (y) ← a - (y),c(y), not r new. r - (y) ← a(y),c - (y), not r new. Ziel ist es, SQL_Delta-Sichten für r zu erstellen, ohne r in eine Datalog-ähnliche Form zu transformieren (etwa mit Hilfe des Operators UNION die WHERE-Bedingung umzuformen). Der Vorschlag für die Delta_Plus-Sicht der Sicht r mit der Definition SELECT a.Name FROM a, b, c WHERE a.Name=b.Name OR a.Name=c.Name; lautet: r_Plus: SELECT a_Plus.Name FROM a_Plus , b_New , c_New WHERE a_Plus.Name = b_New.Name OR

Kapitel 5

41

a_Plus.Name = c_New.Name UNION ALL SELECT a_New.Name FROM a_New , b_Plus , c_New WHERE a_New.Name = b_Plus.Name OR a_New.Name = c_New.Name UNION ALL SELECT a_New.Name FROM a_New , b_New , c_Plus WHERE a_New.Name = b_New.Name OR a_New.Name = c_Plus.Name; Man sieht, dass hier die folgenden Kombinationen aus Relationen enthalten sind: a_Plus und b_New a_Plus und c_New a_New und b_Plus a_New und c_New a_New und b_New a_New und c_Plus Dies sind alle Kombinationen, die in Analogie zur Datalog Delta_Plus-Regel r+ vorhanden sein sollten, plus zusätzlich a_New und c_New sowie a_New und b_New. Da man, wie in Abschnitt 4.2 gezeigt wurde, aber auch im SQL-Kontext einen Effektivitätstest benötigt, stellen diese zusätzlichen Kombinationen kein Problem dar. Der Effektivitätstest wird dabei falsche Delta-Fakten, die solche überflüssigen Kombinationen eventuell produziert haben werden, ausfiltern. Diese Vorgehensweise wird aber den Algorithmus zur Delta-Sichterstellung nicht unnötig verkomplizieren. Wie man den SQL-Beispielen in diesem und auch vorigem Kapitel ansieht, fehlt hier der Effektivitätstest. Dadurch wird an dieser Stelle die Komplexität, welche der Effektivitätstest mit sich bringt, vermieden. Er kann eben einfach nicht ohne weiteres in Jet-SQL implementiert werden, weil Jet-SQL den Mengenoperator Minus nicht kennt. Der nächste Abschnitt wird die Implementierung des Effektivitätstests in SQL erläutern.

5.2 Effektivitätstest

Im Datalogkontext wird der Effektivitätstest zum einen bei Einfügungen verwendet, um zu prüfen, ob die neu abgeleiteten Fakten nicht schon im alten Datenbankzustand vorhanden waren. Zum anderen wird der Effektivitätstest bei Löschungen eingesetzt, um herauszufinden, ob die gelöschten Fakten nicht trotz der durchgeführten Löschungsmaßnahme durch alternative Ableitungsmöglichkeiten vorhanden geblieben, oder aber durch die Einfügungen hinzugekommen sind. In beiden Fällen gilt es die echten Änderungen herauszufiltern. Echte Einfügungen sind neue Fakten minus schon vorhandener. Echte Löschungen sind gelöschte Fakten minus der übrig gebliebenen bzw. hinzugekommenen. Also gilt für eine Regel p:


42

p +← ..., not p und p -

← ..., not p new. Man könnte eventuell annehmen, da SQL eine multimengenorientierte Sprache ist und Sichten in SQL Duplikaten enthalten sein können, bräuchte man den Test im SQL-Kontext nicht. In dem in dieser Arbeit vorgestellten Algorithmus für die Delta-Sichterstellung benötigt man den Effektivitätstest jedoch sehr wohl, denn es könnten falsche Delta-Fakten entstehen.So zum Beispiel bei der Sicht mit der Definition: SELECT x.Name FROM x WHERE (x.Name) NOT IN (SELECT y.Name FROM y where y.Name NOT IN (SELECT z.Name FROM z )); Für diese Sicht wird die Delta_Plus-Sicht nach dem hier entwickelten Algorithmus folgendermaßen aussehen (hier wird ein wenig vorgegriffen, denn erst in Kapitel 4.3 wird erklärt, wie und weshalb man diese Delta-Sicht so aufbaut): Beispiel 5.2: 1 SELECT x_Plus.Name FROM x_Plus WHERE (x_Plus.Nam e) NOT IN (SELECT y_New.Name FROM y_New WHERE y_New.Name NOT IN (SELECT z_New.Name FROM z_New)) UNION ALL 2 SELECT x_New.Name FROM x_New WHERE ( x_New.Name ) NOT IN (SELECT y_New.Name FROM y_New WHERE y_New.Name NOT IN (SELECT z_Plus.Name FROM z_Plus)) UNION ALL 3 SELECT x_New.Name FROM x_New WHERE ( x_New.Name ) IN (SELECT y_Minus.Name FROM y_Minus WHERE y_Minus.Na me NOT IN (SELECT z_New.Name FROM z_New)); In der zweiten SELECT-Anweisung können falsche Delta-Fakten auftreten. Wenn zum Beispiel die Relationen z und z_Plus leer sind, dann kommen dort Delta-Fakten vor, die schon in der ursprünglichen Relation enthalten waren. Also ist der Effektivitätstest in diesem Algorithmus notwendig. MS Access unterstürzt keinen MINUS-Operator, daher wird MINUS durch NOT EXISTS simuliert. Die Verwendung des Ausdruck NOT EXISTS führt zur Notwendigkeit, zwei zusätzlichen Sichten – die Anfragen für die Implementierung des Effektivitätstests – einzuführen. Diese, hier Delta2-Sichten genannt, werden jeweils auf die Delta_Plus- bzw. Delta_Minus-Sichten angewendet. Somit wird Sichtname_Plus2 für Sichtname_Plus einerseits sowie Sichtname_Minus2 für Sichtname_Minus andererseits in die aktuelle Datenbank eingefügt. Der Effektivitätstest für die Delta_Plus-/ Delta_Minus-Sichten aus Beispiel 5.1 lautet: Effektivitätstest für Delta_Plus-Regel : SELECT DISTINCT r_PLUS.NAME FROM r_PLUS WHERE NOT EXISTS

Kapitel 5

43

( SELECT * FROM q WHERE IIF ( ISNULL (q.NAME), IIF (ISNULL (q_PLUS.NAME), TRUE, FALSE), IIF(ISNULL(q_PLUS.NAME), FALSE,q.NAME = q_PLUS.NAME) ) ); Effektivitätstest für Delta_Minus-Regel : SELECT DISTINCT q_MINUS.NAME FROM q_MINUS WHERE NOT EXISTS (SELECT * FROM q_NEW WHERE IIF ( ISNULL (q_NEW.NAME), IIF(ISNULL(q_MINUS.NAME),TRUE,FALSE), IIF(ISNULL(q_MINUS.NAME), FALSE,q_NEW.NAME = q_MINUS.NAME) ) ); Der komplizierte Vergleich in der WHERE-Bedingung des SELECT-Statements von Ebene 2 ist notwendig, um NULL-Werte zu vergleichen. Wie schon in Abschnitt 2.2.2 erwähnt, benutzt SQL eine dreiwertige Logik und liefert so durch einen direkten Vergleich der NULL-Werte UNKNOWN zurück. Durch die oben vorgestellte Erweiterung der WHERE-Klausel wird erreicht, dass der Vergleich der beiden NULL-Werte TRUE sowie der des NULL -Werts mit dem Nicht-NULL-Wert FALSE zurückliefert. Somit handelt es sich bei den Delta-Fakten um echte Änderungen. Falls also ein Fakt n-mal hinzugekommen ist, so wird er nur einmal als neuer Eintrag angezeigt. Falls ein Fakt schon k-mal im alten Zustand vorhanden war und nun m-mal hinzugekommen ist, so wird er überhaupt nicht als neuer Fakt ausgewiesen. Ein Fakt wird nur dann als gelöscht angezeigt, wenn er überhaupt nicht in der Sicht in neuem Zustand enthalten ist.

5.3 Besonderheiten, Schwierigkeiten

In diesem Abschnitt wird versucht, für Sichten mit verschiedenen SQL-Operatoren Delta-Sichten zu erstellen sowie bereits gewonnene Erkenntnisse über die Änderungspropagierung in SQL an etwas komplexeren Beispielen zu vertiefen.


44

Wie schon in Kapitel 5.1 erwähnt: Wo in Datalog für eine Regel mit N Rumpfliteralen jeweils N Delta_Plus- bzw. Delta_Minus-Regeln entstehen, entsteht in SQL jeweils nur eine Delta_Plus- bzw. Delta_Minus-Sicht mit N SELECT-Anweisungen, welche durch den Operator UNION ALL miteinander verbunden sind. Das heißt, bei einer Sicht, die auf mehr als einer Basistabelle aufbaut, ist der Operator UNION ALL in den Delta-Sichten unvermeidbar. Aus diesem Grund stellt der Operator ORDER BY ein Problem bei der Auswertung der Delta-Sichten dar, da JET-SQL nicht mehr als einen ORDER BY-Operator bei der Abfrage mit dem Operator UNION duldet. Das Problem wird gelöst, indem der Operator ORDER BY ganz aus den Delta-Sichten entfernt wird. Diese Vorgehensweise verfälscht das Ergebnis nicht – die Delta-Fakten werden nur nicht sortiert angezeigt. Ein anderer wichtiger und interessanter Operator, der ebenfalls Probleme verursachen kann, ist GROUP BY. Dieser Operator wird häufig mit dem Zusatz HAVING verwendet. HAVING stellt eine Bedingung an die selektierte Zeile und wird oft in Kombination mit Aggregatfunktionen eingesetzt. Auf die Probleme mit Aggregatfunktionen wird in Abschnitt 5.4 noch genauer eingegangen. Wenn der Operator GROUP BY ...HAVING jedoch ohne Aggregatfunktionen benutzt wird, so stellt er kein Problem dar. Denn die GROUP BY - und HAVING -Zeilen werden unverändert in die Delta-Sichten übernommen, und durch die Verwendung des Effektivitätstests werden die Duplikate eliminiert. Für die Sicht mit der Definition SELECT Artikel.Beschreibung, Artikel.Nr FROM Artikel GROUP BY Artikel.Beschreibung, Artikel.Nr HAVING Artikel.Nr between 1 and 10; sehen Delta-sichten wie folgt aus: Delta_Plus: SELECT Artikel_Plus.Beschreibung, Artikel_Plus.Nr FROM Artikel_Plus GROUP BY Artikel_Plus.Beschreibung, Artikel_Plus.Nr HAVING Artikel_Plus.Nr between 1 and 10; Delta_Minus: SELECT Artikel_Minus.Beschreibung, Artikel_Minus.Nr FROM Artikel_Minus GROUP BY Artikel_Minus.Beschreibung, Artikel_Minus. Nr HAVING Artikel_Minus.Nr between 1 and 10; Der Operator INNER JOIN ist ebenso problemlos einzusetzbar: Beispiel - INNER JOIN: SELECT a.Nr, a.Artikel, D.Anzahl FROM a INNER JOIN D ON a.Nr=D.Nr;

Kapitel 5

45

Delta_Plus: SELECT a_Plus.Nr , a_Plus.Artikel , D_New.Anzahl FROM a_Plus INNER JOIN D_New ON a_Plus.Nr = D_New.N r UNION ALL SELECT a_New.Nr , a_New.Artikel , D_Plus.Anzahl FROM a_New INNER JOIN D_Plus ON a_New.Nr = D_Plus.N r; Delta_Minus: SELECT a_Minus.Nr , a_Minus.Artikel , D.Anzahl FROM a_Minus INNER JOIN D ON a_Minus.Nr = D.Nr UNION ALL SELECT a.Nr , a.Artikel , D_Minus.Anzahl FROM a INNER JOIN D_Minus ON a.Nr = D_Minus.Nr; Bei RIGHT/ LEFT OUTER JOIN verhält es sich dagegen anders: Beispiel (Delta-Sichten für die Sicht s, die den Operator LEFT OUTER JOIN beinhaltet): SELECT E.Name, F.Name FROM E LEFT OUTER JOIN F ON E.Name=F.Name; Der hier entwickelte Algorithmus würde die Delta-Sichten wie folgt erstellen: r_Plus: SELECT E_Plus.Name , F_New.Name FROM E_Plus LEFT OUTER JOIN F_New ON E_Plus.Name = F_New.Name UNION ALL SELECT E_New.Name , F_Plus.Name FROM E_New LEFT OUTER JOIN F_Plus ON E_New.Name = F_Plus.Name; r_Minus: SELECT E_Minus.Name , F.Name FROM E_Minus LEFT OUTE R JOIN F ON E_Minus.Name = F.Name UNION ALL SELECT E.Name , F_Minus.Name FROM E LEFT OUTER JOIN F_Minus ON E.Name = F_Minus.Name; Im zweiten SELECT-Statement der r-Plus-Sichtdefinition werden für alle Einträge der Tabelle E_New neue Fakten gebildet, und zwar sogar für den Fall, dass die Tabelle F_Plus leer ist. Somit entstehen falsche Delta-Fakten, das heißt, an dieser Stelle tritt ein Fehler auf. Ein ähnlicher Fehler tritt auch bei der r_Minus-Sicht, im Join zwischen E und F_Minus, auf Auch bei den Sichten mit RIGHT OUTER JOIN gibt es eine ähnliche Schwierigkeit. Aus diesem Grund wird der Operator OUTER JOIN von dem in dieser Arbeit entwickelten Compiler nicht bearbeitet.


46

Man kann das Problem aber dadurch lösen, dass man LEFT durch RIGHT und RIGHT durch LEFT ersetzt. Es müssen unbedingt alle Einträge der Plus-/Minus-Tabellen komplett in den Join übernommen werden, und nicht die der New (/Old)-Tabellen. Im Beispiel muss LEFT OUTER JOIN zwischen E_New und F_Plus sowie E und F_Minus durch RIGHT OUTER JOIN ersetzt werden. Für SELECT-Anfragen, die den Operator UNION enthalten, also diejenigen, die aus mehreren SELECT-Statements bestehen, können ganz einfach Delta-Regeln gebildet werden. Für jeden dieser SELECTs werden eigene Delta-Sichten erstellt, die, verknüpft durch den Operator UNION, in einer gemeinsamen Delta-Sicht in die Datenbank eingefügt werden. SELECT a.NAME FROM a UNION SELECT b.NAME FROM b; Delta_Plus: SELECT a_Plus.Name FROM a_Plus UNION ALL SELECT b_Plus.Name FROM b_Plus; Delta_Minus: SELECT a_Minus.Name FROM a_Minus UNION ALL SELECT b_Minus.Name FROM b_Minus; Wo Datalog Hilfsregeln kennt, bedient sich SQL der Verschachtelungen, die mehrere Ebenen tief reichen können. Der folgende Ausdruck hat z.B. Tiefe 2: SELECT deutscher_Bücher.Autor, deutscher_Bücher.Tit el, deutscher_Bücher.Art FROM deutscher_Bücher WHERE not exists ( SELECT * FROM Fachliteratur WHERE Fachliteratur.Autor = deutscher_Bücher.Autor AND Fachliteratur.Titel = deutscher_Bücher.Titel). Die Verschachtelungen stellen dabei große Schwierigkeiten bei der Polaritätsbestimmung dar. An dieser Stelle sei bemerkt, dass alle Relationen aus den vorherigen Beispielen eine positive Polarität besitzen. Natürlich lassen sich die verschachtelten SQL-Ausdrücke vereinfachen, indem sie in mehrere SELECT-Anfragen aufgesplittet werden. Dennoch nimmt die Auswertung von mehreren, aufeinander basierenden SQL-Anfragen bedeutend mehr Zeit in Anspruch als diejenige eines verschachtelten Ausdrucks. Somit wäre die trügerische Einfachheit aus der Sicht der Performance unvorteilhaft. Es wird daher

Kapitel 5

47

versucht, die Propagierungssichten zu erstellen, ohne die Sicht in die Hilfssichten aufzusplitten. Zuerst ein einfaches Beispiel: Beispiel 5.3 : SELECT x.Nr, x.Name FROM x WHERE EXISTS (SELECT * FROM y WHERE y.Name=x.Name); Alle Basisrelationen besitzen eine positive Polarität. Somit steht der Bildung der Delta-Regeln nichts im Wege: Delta_Plus: SELECT x_Plus.Nr , x_Plus.Name FROM x_Plus WHERE EXISTS ( SELECT * FROM y_New WHERE y_New.Name = x_Plus.N ame ) UNION ALL SELECT x_New.Nr , x_New.Name FROM x_New WHERE EXISTS ( SELECT * FROM y_Plus WHERE y_Plus.Name = x_New.N ame ); Delta_Minus: SELECT x_Minus.Nr , x_Minus.Name FROM x_Minus WHERE EXISTS ( SELECT * FROM y WHERE y.Name = x_Minus.Name ) UNION All SELECT x.Nr , x.Name FROM x WHERE EXISTS ( SELECT * FROM y_Minus WHERE y_Minus.Name = x.Nam e ); Beispiel (mit Negation) Zuerst in Datalog: t(NR,Name) ← x(Nr,Name) , not y(Nr,Name). t +(NR,Name) ← x +(Nr,Name) ,not y new(Nr,Name), not t. t +(NR,Name) ← x new(Nr,Name) , y - (Nr,Name), not t. t - (NR,Name) ← x - (Nr,Name) , not y(Nr,Name), not t new. t - (NR,Name) ← x(Nr,Name) , y +(Nr,Name), not t new. Zur Erinnerung: Die Änderungspropagierung in Datalog durch Literale mit negativer Polarität erfolgt im Prinzip genauso. Der einzige Unterschied besteht darin, dass der ursprünglich negative Literal mit den invertierten Vorzeichen in die Formel eingeht.


48

Nun die gleiche Sicht t in SQL, wobei die Negation durch den Operator NOT EXISTS ausgedrückt wird: SELECT x.Nr, x.Name FROM x WHERE NOT EXISTS (SELECT * FROM y WHERE y.Name=x.N ame); Die Basissicht y hat eine negative Polarität. Wie in Datalog, so geht auch hier bei SQL die ursprünglich negierte Basisrelation (hier y) mit den invertierten Vorzeichen in die Delta-Sicht ein: Delta_Plus: SELECT x_Plus.Nr , x_Plus.Name FROM x_Plus WHERE NOT EXISTS ( SELECT * FROM y_New WHERE y_New.Name=x_Plus.Name ) UNION ALL SELECT x_New.Nr , x_New.Name FROM x_New WHERE EXISTS ( SELECT * FROM y_Minus WHERE y_Minus.Name=x_New.N ame ); Delta_Minus: SELECT x_Minus.Nr , x_Minus.Name FROM x_Minus WHERE NOT EXISTS ( SELECT * FROM y WHERE y.Name=x_Minus.Name ) UNION ALL SELECT x.Nr , x.Name FROM x WHERE EXISTS ( SELECT * FROM y_Plus WHERE y_Plus.Name=x.Name ); Man sieht, dass die Relation y als y_Minus in der Delta_Plus-Regel und als y-Plus in die Delta_Minus-Regel eingegangen ist. Außerdem wird der Operator NOT EXISTS durch den EXISTS-Operator ersetzt. Diese Vorgehensweise für negierte SELECT-Statements entspricht der Vorgehensweise bei negativen Literalen in Datalog. Aber was passiert, wenn man einen Ausdruck der Tiefe 3 oder mehr betrachtet? Falls alle Relationen positive Polarität besitzen und somit keine Negation in der Anfrage vorkommt, so spielt die Tiefe bekanntermaßen keine Rolle – die Delta-Sichten werden ähnlich dem oben betrachteten Beispiel 5.3 gebildet. Falls aber doch Negationen vorkommen, so wird die Polaritätsbestimmung schwieriger. Beispiel mit Operator NOT IN der Tiefe 3: SELECT x.Name FROM x

Kapitel 5

49

WHERE x.Name NOT IN (SELECT y.Name FROM y WHERE y.Name NOT IN (SELECT z.Name FROM z WHERE y.Name=z.Name)); Delta_Plus: SELECT x_Plus.Name FROM x_Plus WHERE x_Plus.Name NOT IN ( SELECT y_New.Name FROM y_New WHERE y_New.Name NO T IN ( SELECT z_New.Name FROM z_New WHERE y_New.Name=z_New.Name)) UNION ALL SELECT x_New.Name FROM x_New WHERE x_New.Name NOT IN ( SELECT y_New.Name FROM y_New WHERE y_New.Name NO T IN ( SELECT z_Plus.Name FROM z_Plus WHERE y_New.Name = z_Plus.Name )) UNION ALL SELECT x_New.Name FROM x_New WHERE x_New.Name IN ( SELECT y_Minus.Name FROM y_Minus WHERE y_Minus.Name NOT IN ( SELECT z_New.Name FROM z_New WHERE y_Minus.Name = z_New.Name )); Delta_Minus: SELECT x_Minus.Name FROM x_Minus WHERE x_Minus.Name NOT IN ( SELECT y.Name FROM y WHERE y.Name NOT IN ( SELECT z.Name FROM z WHERE y.Name=z.Name )) UNION ALL SELECT x.Name FROM x WHERE x.Name NOT IN ( SELECT y.Name FROM y WHERE y.Name NOT IN ( SELECT z_Minus.Name FROM z_Minus WHERE y.Name=z_Minus.Name )) UNION ALL SELECT x.Name FROM x WHERE x.Name IN ( SELECT y_Plus.Name FROM y_Plus WHERE y_Plus.Name NOT IN ( SELECT z.Name FROM z WHERE y_Plus = z.Name ));


50

Die Relation x besitzt positive Polarität. Die Relation y wurde dagegen negiert und besitzt daher negative Polarität. Die Relation z wird zweimal negiert und erhält wiederum positive Polarität. Das ist auch logisch, denn wie man es aus der Algebra kennt: zweimal Minus ergibt Plus. Bei y_Plus in Delta_Minus und y_Minus in Delta_Plus wird NOT IN durch IN ersetzt. Somit haben Relationen, welche sich in Verschachtelungen mit gerader Anzahl von NOT EXISTS- oder NOT IN -Ausdrücken befinden, eine positive Polarität,– die mit ungerader Anzahl dagegen eine negative. NOT IN und NOT EXISTS sind die einzigen Negationsoperatoren in Access. Darüber hinaus werden weder MINUS noch EXCEPT akzeptiert. Wenn eine Sicht (z.B. Sicht1) von einer anderen (z.B. Sicht2) abhängt, so wird Sicht2 wie eine Basisrelation gehandhabt, jedoch mit dem Unterschied, dass, anders als bei einer Basisrelation, Sicht2_Plus und Sicht2_Minus keine Tabellen, sondern Delta-Sichten sind. Was die Sicht Sicht2_New angeht, so handelt es sich dabei um eine naive und nicht um eine inkrementelle Transitions-Sicht. Unbedingt beachtet werden muss hier Folgendes: Bevor man die Propagierungssichten für Sicht1 generiert, muss man die entsprechende Delta- und Transitionssichten für Sicht2 erzeugen. Ein Beispiel einer von einer anderen Sicht abhängigen Sicht wird in Abschnitt 6.3.2 näher behandelt. Die Operatoren ANY/SOME/ALL, die Unteranfragen einleiten, werden in der Praxis selten benutzt. Aus diesem Grund, und um eine unnötige Komplexität zu vermeiden, werden diese Operatoren vom Compiler auch nicht bearbeitet. Operatoren und Schlüsselwörter wie IN, BETWEEN, LIKE, IS (NOT) NULL, IIF (<Expr>, True, False) oder AS, die in der WHERE-Bedingung oder in der SELECT-Klausel auftreten können, stellen kein Problem dar, da die WHERE-Bedingung und die SELECT-Klausel unverändert in die Delta-Sichten übernommen werden. Schlüsselwörter wie DISTINCT, DISTINCTROW stellen auch keine Schwierigkeiten dar, da die Duplikate durch den Effektivitätstest eliminiert werden. Access-Abfragen können außerdem Parameter enthalten. Aber auch sie stellen kein Problem dar. Werden Delta-Abfragen/Sichten ausgeführt, so sollte man einfach einmal den Parameter eingeben. Rekursionen treten bei Access gar nicht auf und werden deshalb hier auch nicht betrachtet. Der Konstruktor With, mit dessen Hilfe lokale Anfragen eingeleitet werden können, kennt Jet-SQl ebenfalls nicht.

5.4 Duplikate

In dieser Arbeit wird das Problem der Duplikate nur bedingt gelöst. In Abschnitt 4.2 wurde die Notwendigkeit eines Effektivitätstests gezeigt; also wird dieser angewendet.

Kapitel 5

51

Somit handelt es sich bei Delta-Fakten um echte Änderungen. Falls also ein Fakt n-mal hinzugekommen ist, wird er nur einmal als neuer Eintrag angezeigt. Falls ein Fakt bereits k-mal im alten Zustand vorhanden war und m-mal hinzugekommen ist, wird er überhaupt nicht als neuer Fakt ausgewiesen. Ein Fakt wird nur dann als gelöscht angezeigt, wenn er überhaupt nicht in neuem Zustand in der Sicht enthalten ist. Die Ausnahme bilden hier die Sichten, deren Attribute auf Aggregatfunktionen basieren. Bei solchen Sichten wird in dieser Arbeit kein Effektivitätstest durchgeführt. Somit werden alle Duplikate als Delta-Fakten erhalten, um die Aggregatfunktionen richtig auswerten zu können. Allerdings darf man dabei nicht vergessen, dass eventuell auch Einträge als Delta-Fakten ausgewertet werden, die überhaupt nicht (nicht mal als Duplikate) eingefügt/ gelöscht wurden (siehe Beispiel 5.2). Wie Aggregatfunktionen genau behandelt werden, wird im nächsten Abschnitt erläutert.

5.5 Aggregatfunktionen

Die Änderungspropagierung bei Sichten mit Aggregatfunktionen stellt ein großes Problem dar, das in dieser Arbeit nur teilweise gelöst wird. Kommen Aggregatfunktionen in Selektions- und Gruppierungsbedingungen (wie WHERE- oder HAVING-Klauseln) vor, so können Modifikationen einer oder mehrerer Gruppen oder auch Einfügungen oder Löschungen von Gruppen die Folge von Basisänderungen sein. Treten die Aggregatfunktionen ausschließlich in Haupt-SELECT-Klauseln auf, so müssen bestehende Gruppen geändert werden. In dieser Arbeit werden nur die ANSI Standard SQL-Aggregatfunktionen MIN/MAX, COUNT, SUM und AVG behandelt, die in der Haupt-SELECT-Klausel auftreten. Sichten mit Aggregatfunktionen in den Selektions- und Gruppierungsbedingungen (wie WHERE- oder HAVING-Klauseln) werden in dieser Arbeit nicht behandelt. Die Sichten, deren Attribute auf Aggregatfunktionen wie COUNT, MIN, MAX, SUM oder AVG basieren, brauchen spezielle Delta-Sichten zur Auswertung von Aggregatfunktionen. Zuerst werden die Aggregatfunktionen SUM, COUNT und AVG betrachtet. Wie schon in Abschnitt 5.1 gesagt, werden für jede Sicht eine Delta-Plus- und eine Delta-Minus-Sicht, die Delta-Fakten enthalten, gebildet. Um zum Beispiel die geänderte SUMME (bzw. COUNT-Werte) zu finden, braucht man nur die Summe (bzw. die Count-Werte) der ursprünglichen Sicht zu jenen der Delta_Plus-Sicht zu addieren und davon die der Delta_Minus-Sicht zu subtrahieren. Fast das Gleiche gilt auch für den Durchschnitt, nur dass man das Ergebnis noch durch 3 dividieren muss. Man beachte, dass, obwohl man zwei Sichten (Delta_Plus und Delta_Minus) hat, nur eine Sicht, hier Delta2-Sicht genannt, generiert wird, und zwar auf folgende Weise:


52

Für die Sicht u mit SELECT COUNT / SUM (AVG)(id) FROM a; sieht u_Delta2 wie folgt aus: SELECT (a2.a1+a3.a1-a4.a1) (/3 falls AVG) AS Ausdr1 FROM [ SELECT SUM(EXPR1000) AS a1 FROM uq]. AS a2, [ SELECT SUM(EXPR1000) AS a1 FROM u_Plus ]. AS a3, [ SELECT SUM(EXPR1000) AS a1 FROM u_Minus ]. AS a4 ; Wobei Expr1000 der Name jener Sichtattribute ist, die auf Aggregatfunktionen basieren. Dieser Name wird den Spalten automatisch von Access gegeben, falls sie nicht explizit in der Anfrage benannt werden. Die Funktionen MIN und MAX stellen allerdings ein Problem dar. Man kann zwar ohne Probleme MIN/MAX für die Sicht und die Delta-Plus-Sicht wie folgt herausfinden: SELECT MIN/MAX (EXPR1000) AS ausdr1 FROM [SELECT * FROM q UNION SELECT * FROM q_Plus]; Wie kann man aber MIN/MAX ermitteln, wenn Löschungen stattgefunden haben? Eine Teillösung besteht hier darin, die Aggregatfunktionen MIN/MAX nicht für die ursprüngliche Ausgangssicht und Delta-Fakten auszuwerten, sondern nur für die Delta-Fakten. Wie schon in Kapitel 5.1 erwähnt, entsteht, wo in Datalog für eine Regel mit N Rumpfliteralen jeweils N Delta_Plus- bzw. Delta_Minus-Regeln entstehen, in SQL nur eine Delta_Plus- bzw. Delta_Minus-Sicht mit N SELECT-Anweisungen, die durch den Operator UNION ALL miteinander verbunden sind. Das heißt, bei einer Sicht, die auf mehr als einer Basistabelle aufbaut, ist der Operator UNION ALL in Delta-Sichten unvermeidbar. Auch wenn die Attribute dieser Sicht auf Aggregatfunktionen basieren, werden die Delta-Sichten mehrere Tupel als Ergebnis zurückliefern, nämlich für jede SELECT-Anweisung eines. Man erwartet aber nur ein Tupel als Ergebnis der Aggregatfunktionen. Man kann dieses Problem lösen, indem man auf die Delta_Plus- bzw. Delta_Minus-Sichten jeweils eine Sicht (hier Delta2-Sicht genannt) anwendet, welche die entsprechenden Aggregatfunktionen auf Ergebnisse der Delta-Sichten anwendet. Für die Sicht v mit: SELECT min(id) FROM a; sehen die Delta2_Sichten wie folgt aus:

Kapitel 5

53

v_Plus2 : SELECT Min(expr1000) AS Ausdr1 FROM v_Plus; v_Minus2: SELECT Min(expr1000) AS Ausdr1 FROM v_Minus; Da die richtige Behandlung von Duplikaten im Compiler nicht garantiert ist, so ist auch die Korrektheit der Auswertung von Aggregatfunktionen nicht garantiert.

5.6 Algorithmen

Der Kern der Bemühungen war es, einen Algorithmus zur Delta-Sichterstellung zu entwickeln. Zunächst einige Fakten, die in den vorigen Kapiteln entwickelt oder festgelegt wurden: Da MS Access keinen MINUS-Operator unterstützt, können nur Relationen in Ausdrücken mit NOT EXIST oder NOT IN negative Polarität besitzen. Bei den Propagierungsbeispielen wird grundsätzlich ein neuer Datenbankzustand simuliert. Die "optimistische" Methode, bei der ein alter Zustand simuliert wird, kommt hier eher nicht in Frage, weil MS Access mit Integritätsbedingungen arbeitet, und daher mögliche Integritätsverletzungen erwartet werden. Im Folgenden werden Regel und Algorithmen vorgestellt, die der hier zu entwickelnde Compiler zur Generierung von Delta-Sichten benutzen wird. Regel zur Polaritätbestimmung: Relationen, die sich in Verschachtelungen mit einer geraden Anzahl von NOT EXISTS- oder NOT IN -Ausdrücken befinden, besitzen positive Polarität, jene mit einer ungerader Anzahl hingegen eine negative. Alle anderen Relationen besitzen positive Polarität. Gegeben sei eine nicht-rekursive Sicht, die auf R1 bis Rn Relationen aufbaut, mit einer Sichtdefinition, die als SQL-String gegeben wird. Teile die Relationen mit Hilfe der Regel zur Polaritätbestimmung in zwei Mengen auf: S1 – Menge der Relationen mit positiver Polarität und S2 – Menge der Relationen mit negativer Polarität. Algorithmus für die Delta_Plus-Sicht: Eingabe: S1 ,S2 , Sichtdefinition als String; Ausgabe: Delta_Plus-Sicht als String;


54

Methode: While S 1 is not empty:

nehme eine Relation R i aus S1

lege String-Kopie(i) der Sichtdefinition ersetze R i durch R i _Plus in der String-Kopie(i)

lösche R i aus S 1

ersetze alle R j aus (R 1,..., R i-1 , R i+1 ,...R n) durch

R j _New in String- Kopie(i)

füge UNION ALL zu String- Kopie(i) While S 2 is not empty: nehme Relation R i aus S 2 lege String-Kopie(i) der Sichtdefinition ersetze R i durch R i_Minus in der String-Kopie(i) lösche R i aus S 2. ersetze NOT EXISTS bzw. NOT IN, die die Relation R i einleiten durch EXISTS bzw. IN ersetze alle R j aus (R 1,..., R i-1, R i+1,...R n) durch R j_New in String- Kopie(i) falls S 2 is not empty, füge UNION ALL zu String- Kopie(i) Füge alle n veränderter String-Kopie der Sichtdefin ition zu einer Delta_Plus-Sicht. Algorithmus für die Delta_Minus-Sicht: Eingabe: S1 ,S2 , Sichtdefinition als String; Ausgabe: Delta_Minus-Sicht als String; Methode: While S 1 is not empty: nehme Relation R i aus S 1

lege String-Kopie(i) der Sichtdefinition ersetze R i durch R i _Minus in der String-Kopie(i)

lösche R i aus S 1

füge UNION ALL zu String- Kopie(i) While S 2 is not empty:

nehme Relation R i aus S 2

lege String-Kopie(i) der Sichtdefinition ersetze R i durch R i _Plus in der String-Kopie(i)

lösche R i aus S 2.

ersetze NOT EXISTS bzw. NOT IN, die die Relation R i

einleiten durch EXISTS bzw. IN falls S 2 is not empty, füge UNION ALL zu String- Kopie(i)

Füge alle n veränderten String-Kopie der Sichtdefi nition zu

Kapitel 5

55

einer Delta_Minus-Sicht Zusätzlich werden noch die Delta2-Sichten gebildet. Delta2-Sichten implementieren entweder den Effektivitätstest oder stellen spezielle Sichten für die Auswertung der Aggregatfunktion dar (siehe 5.2 und 5.5). Delta_Plus2- / Delta_Minus2-Sichten (Effektivitätstest) für die Delta_Plus(/_Minus)-Sicht: SELECT DISTINCT (alle) Sicht.Attribute FROM Sichtname_Plus WHERE NOT EXISTS (SELECT * FROM Sichtname WHERE IIF (ISNULL((alle)Sichtname.Attribute), IIF (ISNULL ((alle)Sichtname_Plus(Minus).Attribute ), TRUE, FALSE), IIF(ISNULL(((alle)Sichtname_Plus(Minus).Attribute) ,FALSE, (alle)Sichtname.Attribute= (alle)Sichtname_Plus(Minus).Attribute))); Spezielle Delta2-Sicht für die Aggregatfunktionen COUNT, AVG, SUM: SELECT (a2.a1+a3.a1-a4.a1) (/3 falls AVG) AS Ausdr1 FROM [ SELECT SUM( Sicht.Attribut) AS a1 FROM u]. AS a 2, [ SELECT SUM(Sicht.Attribut) AS a1 FROM u_Plus ]. AS a3, [ SELECT SUM(Sicht.Attribut) AS a1 FROM u_Minus ] . AS a4; Spezielle Delta_Plus(/_Minus)2-Sichten für die Aggregatfunktionen Min /Max: SELECT MIN/MAX_Aggregatfunktion (Sicht.Attribut ) A S Ausdr1 FROM Sichtname_Plus(Minus). Die naive Transitionssicht erhält man, indem in der ursprünglichen Definition alle Basisrelationen einfach durch Basisrelation_New ersetzt werden. Die inkrementellen Transitionssichten für die Basisrelationen : (SELECT * FROM Basisrelation WHERE NOT EXISTS (SELECT * FROM Basisrelation_Minus WHERE (alle)Basisrelation.Attribute= Basisrelation_Minus.Attribute)) UNION (SELECT * FROM Basisrelation_Plus)


56

Kapitel 6

57

6 Implementierung

Mit diesem Kapitel beginnt der praktische Teil dieser Arbeit. In Abschnitt 6.1 werden die Implementierung des Compilers in VBA und in Abschnitt 6.2 das Programm, in welches der Compiler integriert ist, vorgestellt. Das Programm erlaubt es dabei dem Benutzer, auf bequeme Weise für die ausgewählten Sichten die Delta-Sichten zu generieren, Basisänderungen einzugeben, die induzierten Änderungen anzusehen und gegebenenfalls die Änderungen in der Datenbank zu speichern. Die Korrektheit des Compilers wird anhand von zwei Beispielsichten in Abschnitt 6.3 demonstriert.

6.1 Compiler

„Ein Compiler ist ein Programm, das ein in einer bestimmten Sprache – der Quell-Sprache – geschriebenes Programm liest und es in ein äquivalentes Programm einer anderen Sprache – der Ziel-Sprache – übersetzt“ ([ASU88]). Während der Übersetzung festgestellte Fehler im Quellprogramm werden als Fehlermeldungen ausgegeben. Abbildung 6.1 zeigt eine einfache Vorstellung eines Compilers.

Abbildung 6.1 Compiler [ASU88] Der in dieser Arbeit entwickelte Compiler hat die Aufgabe, Delta-Sichten zu erstellen. Somit übersetzt er Sichten in Delta-Sichten. Falls er in der ursprünglichen Sichtdefinition

Implementierung _

58

Operatoren oder Schlüsselwörter findet, die er nicht bearbeiten kann, so gibt er eine Fehlermeldung aus. Abbildung 6.2 zeigt eine einfache Skizze des Compilers.

Abbildung 6.2 Delta-Sichten-Compiler Der hier beschriebene Compiler besteht aus folgenden Teilen: 1. Parser 2. Analyser 3. Code Generator Im Parser werden die Zeichen des Quellprogramms von Links nach Rechts gelesen und in Tokens aufgesplittet. Dabei wird geprüft, ob das Quellprogramm Zeichen enthält, die vom Compiler nicht bearbeitet werden. Der Analyser hat die Aufgabe, einen Code zu erzeugen, der leicht in ein Zielprogramm übersetzt werden kann. Die Endphase − der Code Generator − bei der Arbeit des Compilers besteht in der Codeerzeugung. Diese Phase wandelt die Zwischendarstellung des Quellprogramms in ein äquivalentes Zielprogramm um. Eine detailliertere Beschreibung folgt in den nächsten Abschnitten.

6.1.1 Parser

In diesem Abschnitt wird die erste Komponente des Compilers – der Parser – erläutert. Der Anwender gibt dem Programm (siehe Kapitel 6.2), in welchem der Compiler aufgerufen wird, den Sichtnamen einer der Sichten der aktuellen Datenbank. Die Sichtdefinition wird aus dem Access-Datenbankschema gelesen. Der Parser erhält als einzigen Inputparameter die SQL-Sichtdefinition als Zeichenkette der in der aktuellen Datenbank enthalten Sicht. Die Richtigkeit der Syntax und der Semantik der Sichtdefinition wird nicht geprüft, da dies überflüssig ist. Denn das Access-DBMS führt diese Prüfung durch, noch bevor die Sichtdefinition im Datenbankschema gespeichert wird. Der SQL-String wird zuerst in eine einheitliche Form gebracht. Dafür werden alle Zeilenumbrüche eliminiert sowie zwischen einzelnen Operatoren und Relationen und deren Attributen Leerzeichen platziert. Der String, wie zum Beispiel Fachliteratur.Autor, wird durch das Leerzeichen in Fachliteratur und .Autor

Kapitel 6

59

aufgesplittet. Diese Vorgehensweise erlaubt es dem Compiler später, zwischen dem Relationsnamen und dessen Attributen zu unterscheiden. Dabei wird geprüft, ob in der Sichtdefinition eventuell SQL-Operatoren vorkommen, die vom Compiler nicht ausgewertet werden können. Dies sind zum einen Operatoren, die zwar in der Sichtdefinition vorkommen können, aber von dem für diese Arbeit entwickelten Compiler nicht ausgewertet werden. Dies sind OUTER JOINS, SOME/ ANY / ALL -Unterabfragen sowie Access-eigene Aggregatfunktionen (siehe Abschnitt 3.5) und Aggregatfunktionen in Selektions- und Gruppierungsbedingungen. Zum anderen müssen – da in Access Sichten als Abfragen gespeichert werden – jene Abfragen, die keine Sichten im Sinne von virtuellen Relationen darstellen, ausgefiltert werden. Dies sind Abfragen mit den Schlüsselworten: CREATE/ ALTER / DROP TABLE (INDEX), DELETE/UPDATE/INSERT INTO / SELECT INTO TABLE, TOP . Ursprünglicher SQL-String der Sicht deutsche_Belletristik: SELECT deutscher_Bücher.Autor, deutscher_Bücher.Tit el, deutscher_Bücher.Art FROM deutscher_Bücher WHERE NOT EXISTS (SELECT * FROM Fachliteratur WHERE Fachliteratur.Autor=deutscher_Bücher.Autor AND Fachliteratur.Titel=deutscher_Bücher.Titel); SQL-String in einheitlicher Form: SELECT deutscher_Bücher .Autor, deutscher_Bücher .T itel , deutscher_Bücher .Art FROM deutscher_Bücher WHERE NOT EXISTS ( SELECT * FROM Fachliteratur WHERE Fachliteratur .Autor = deutscher_Bücher .Autor AND Fachliteratur .Titel = deutscher_Bücher .Titel ); Erst jetzt kann der SQL-String an die Funktion String_Tokenizer (Text As String) As Liste übergeben werden, wo er in einzelne Tokens – einzelne Wörter der SELECT-Anweisung – gesplittet wird. Die Funktion nimmt dabei an, dass zwischen zwei Leerzeichen genau ein Token liegt. Diese Tokens werden in Form einer Liste zurückgegeben.

Implementierung _

60

Beispiel : (für die dem Leser schon bekannte Sicht deutsche_Belletristik sieht die Tokenliste folgendermaßen aus) [ 'SELECT', 'deutscher_Bücher', '.Autor', ',', 'deutscher_Bücher', '.Titel', ',', 'deutscher_Bü cher', '.Art', 'FROM', 'deutscher_Bücher', 'WHERE', 'N OT', 'EXISTS', '(', 'SELECT', '*', 'FROM', Fachlite ratur', 'WHERE', 'Fachliteratur', '.Autor', '=', 'deutscher_Bücher', '.Autor', 'and', 'Fachlitera tur', '.Titel', '=', 'deutscher_Bücher', '.Titel', ')' ]

6.1.2 Analyser

Der Analyser ist der wichtigste Teil des gesamten Compilers. Als Eingabe für den Analyser dient die Tokenliste, die vom Parser zurückgeliefert wird. Die Tokensliste wird an die Prozedur Polaritaet_bestimmen (Tokenliste, Neg_Pol, Pos_Pol, Alle_rel) zusammen mit den leeren Mengen Neg_Pol (für die Relationen mit negativer Polarität), Pos_Pol (für die Relationen mit positiver Polarität) und Alle_Rel (Gesamtliste aller vorkommenden Relationen) übergeben. Dabei sind Neg_Pol , Pos_Pol und Alle_Rel Mengen von Objekten der benutzerdefinierten Klasse „Relation“ mit den Attributen: Name - Relationsname Index - Positionsnummer der Relation in der Tokenliste Index_Not - Position von NOT (aus NOT EXISTS- oder NOT IN-

Ausdrücken), falls vorhanden, sonst leer Die Prozedur Polarität_bestimmen liest die Tokenliste von Anfang bis zum Ende, was der Leserichtung der ursprünglichen Sichtdefinition von Rechts nach Links entspricht. Die Aufgabe der Methode ist es, anhand der Sichtdefinition die Relation und deren Polarität festzustellen. Dabei erkennt sie die Relation als Wörter, die zwischen FROM- und WHERE-Schlüsselwörtern stehen und durch Kommata getrennt sind. Da die negierten Relationen nur in Verschachtelungen auftreten können, die durch NOT EXISTS/ NOT IN eingeleiteten werden, ist es wichtig, die Verschachtelungstiefe sowie die Anzahl der NOT EXISTS / NOT IN -Ausdrücke zu bestimmen. Dies wird mit Hilfe eines Stacks realisiert. Die Polaritätsbestimmung geschieht nach dem Prinzip aus der Regel zur Polaritätbestimmung in Abschnitt 4.6. Für alle Relationen aus der Output-Menge Alle_Rel der Methode Polaritaet_Bestimmen wird geprüft, ob es sich um eine Tabelle oder eine Sicht handelt. Bei einer Sicht wird der Hauptprozess angehalten und der Compiler zwecks kompletter Verarbeitung der gefundenen Sicht neu gestartet. Sobald er damit fertig ist – wenn also die Delta- und Transitionssichten für diese Sicht erstellt wurden – wird der

Kapitel 6

61

Hauptprozess fortgesetzt. Dank der Rekursivität des Compilers lassen sich selbst solche Sichten, die auf anderen Sichten aufbauen, verarbeiten. Die Mengen für das Beispiel deutsche_Belletrisktik sehen wie folgt aus: Pos_Pol enthält nur ein Objekt der Klasse „Relation “ mit Name = deutscher_Bücher Index = 11 Neg_Pol enthält nur ein Objekt der Klasse „Relation “ mit Name = Fachliteratur Index =19 Index_not =13 Alle_Rel enthält beide Objekte.

6.1.3 Code Generator

Der Code Generator ist der letzte Teil des Compilers. Nachdem im Parser eine SQL-Sicht in eine Liste von Tokens zerlegt wurde, und im Analyser diese Liste bearbeitet und die weiteren Listen erzeugt wurden, besteht die Aufgabe des Code Generators nun darin, die in den Parser- und Analyse-Teilen erzeugten Listen/ Mengen in Delta-Sichten und Delta2-Sichten – Sichten für den Effektivitätstest beziehungsweise spezielle Sichten zur Behandlung der Aggregatfunktionen – sowie Transitionssichten umzuwandeln und in der Datenbank abzuspeichern. Der Code Generator wird in vier Schritten ausgeführt. Im ersten Schritt werden für alle Tabellen aus der Menge Rel-Alle die Tabellen Plus und Minus sowie die inkrementellen Transitionssichten mittels der Methode Transitionssicht_Inkrementell (Tabellenname) in die Datenbank eingefügt. Im zweiten Schritt wird die naive Transitionssicht für die bearbeitete Sicht durch die Methode Transitionssicht_Naiv(Tokenliste, Sichtname, Alle_R el) erstellt und im Datenbankschema gespeichert. Für eine Sicht, die von n Relationen abhängt, geschieht dies durch den n-maligen Aufruf der Methode Sub Ersetzen (Byref Tokenliste, Objekt Der Klasse „Relation“, Zeichenkette Durch). Der Methode wird eine Liste der Token der Sichtdefinition übergeben. Sie ändert die Liste und gibt die geänderte Version zurück, wobei der Relationsname, der mit dem Objekt der Klasse „Relation“ an die Methode übergeben wurde, überall durch die Zeichenkette Durch ersetzt wird. Beim ersten Aufruf wird der Methode die Kopie der Tokenliste übergeben. Bei n-1 Aufrufen wird dieselbe Kopie weiter verändert. Bei jedem der n Aufrufe wird eine der Relationen, auf welchen die Sicht aufbaut, durch die entsprechende Relation mit dem

Implementierung _

62

Schlüsselwort new im Namen ersetzt. Diese Liste wird dann durch die Methode SQLstring_Aufbauen( Listenkopien) zu einer SQL-Zeichenkette zusammengesetzt und durch die Access Standard-Methode (dem Leser bekannt aus Abschnitt 3.4) Currentdb.Createquerydef unter dem Namen „Sichtname_new“ in die aktuelle Datenbank eingefügt. Im dritten Schritt werden dann die Delta-Sichten kreiert. Diese Aufgabe übernehmen die Prozeduren Delta_Sicht_Plus(Tokenliste, Sichtname) und Delta_Sicht_Minus(Tokenliste, Sichtname) . Diese Prozeduren implementieren den „Algorithmus für die Delta-Minus-Sicht“ sowie den „Algorithmus für die Delta-Plus-Sicht“ – dem Leser beide aus Abschnitt 4.6 bekannt. Die Zeile „ersetze…“ aus den Algorithmen wird durch die Methode Sub Ersetzen(Byref Tokenliste, Objekt Der Klasse „Relation“, Zeichenk ette Durch) realisiert. Die Zeichenkette Durch ist „Relationsname_New“, „Relationsname_Plus“ oder „Relationsname_Minus“. Falls es sich um eine Relation mit negativer Polarität handelt, die durch „Relationsname_Plus“ oder „Relationsname_Minus“ ersetzt wird, so wird der entsprechende NOT EXISTS- bzw. NOT IN -Ausdruck durch EXISTS bzw. IN ersetzt, indem das entsprechende NOT, dessen Position wiederum in dem Objekt der Klasse „Relation“ im Attribut Not_Index steckt, aus der Listenkopie gelöscht wird. Für eine Sicht, die auf n Relationen aufbaut, werden jeweils für die Delta-Sichten n SELECT-Statements generiert. Diese SELECT-Statements werden mit Hilfe des Operators UNION ALL zu den Delta_Plus/_Minus-Sichten verbunden. Für jedes der SELECT-Statements der Delta_Plus-Sicht wird durch den n-maligen Aufruf der Methode Ersetzen eine Tokenliste erstellt. Beim ersten Aufruf wird der Methode die Kopie der Tokenliste sowie die Relation übergeben, die durch Relationsname_Plus oder Relationsname_Minus (im Falle einer negativen Polarität der Relation) ersetzt werden soll. Bei anderen n-1 Aufrufen wird der Methode dieselbe – bereits von ihr geänderte – Liste übergeben sowie andere Relationen, die durch Relationsname_New ersetzt werden müssen. Für jedes der SELECT-Statements der Delta_Minus-Sicht wird durch den 1-maligen Aufruf der Methode Ersetzen eine Tokenliste erstellt. Beim Aufruf wird der Methode die Kopie der Tokenliste übergeben sowie die Relation, die durch Relationsname_Plus oder Relationsname_Minus (im Falle einer negativen Polarität der Relation) ersetzt werden soll. Die anderen n-1 Aufrufe benötigt man in diesen Fall nicht, da in dieser Arbeit ein neuer Datenbankzustand simuliert wird, und die Relationen nicht durch die Relationen mit dem Schlüsselwort Old im Namen ersetzt zu werden brauchen. Somit werden für jede Delta-Sicht der Sicht, die auf n Relationen aufbaut, n solcher Listen generiert. Diese n Listen werden dann an die Methode SQLstring_Aufbauen( Listenkopien) übergeben, wo sie Token für Token eine nach der anderen, verknüpft durch den Operator UNION ALL, als Zeichenkette aufbereitet werden. Diese Zeichenkette wird an die Access Standard-Methode Currentdb.Createquerydef (dem Leser bekannt aus Abschnitt 3.4) zusammen mit dem neuen Sichtnamen (wie z.B Sichtname + _Plus /_Minus) übergeben.

Kapitel 6

63

Beispiel: generierte Listen für die Sicht deutsche_Belletristik_Plus 1 Liste: (ersetze Relation deutscher_Bücher durch deutscher_Bücher_Plus in der Kopie der Tokenliste) [ 'SELECT', 'deutscher_Bücher_Plus', '.Autor', ', ', 'deutscher_Bücher_Plus', '.Titel', ',', 'deutscher_Bücher_Plus', '.Art', 'FROM', 'deutscher_Bücher_Plus', 'WHERE', 'NOT', 'EXISTS ', '(', 'SELECT', '*', 'FROM', 'Fachliteratur', 'WHERE', 'Fachliteratur', '.Autor', '=', 'deutscher_Büche r_Plus', '.Autor', 'and', 'Fachliteratur', '.Titel', '=' , 'deutscher_Bücher_Plus', '.Titel', ')' ] 1.Liste: (ersetze Relation Fachliteratur durch Fachliteratur_new in Liste 1) [ 'SELECT', 'deutscher_Bücher_Plus', '.Autor', ',' , 'deutscher_Bücher_Plus', '.Titel', ',', 'deutscher_Bücher_Plus', '.Art', 'FROM', 'deutscher_Bücher_Plus', 'WHERE', 'NOT', 'EXISTS ', '(', 'SELECT’, '*', 'FROM', 'Fachliteratur_new', 'WH ERE', 'Fachliteratur_new', '.Autor', '=', 'deutscher_Bücher_Plus', '.Autor', 'and', 'Fachliteratur_new', '.Titel', '=', 'deutscher_Bücher_Plus', '.Titel', ')' ] 2 Liste (ersetze Relation Fachliteratur durch Fachliteratur_Minus in der Kopie der Tokenliste) [ 'SELECT', 'deutscher_Bücher’, '.Autor', ',', 'deutscher_Bücher’, '.Titel', ',', 'deutscher_Bü cher’, '.Art', 'FROM', 'deutscher_Bücher’, 'WHERE', 'E XISTS', '(', 'SELECT', '*', 'FROM', 'Fachliteratur_Minus', 'WHERE', 'Fachliteratur_Mi nus', '.Autor', '=', 'deutscher_Bücher’, '.Autor', 'and', 'Fachliteratur_Minus', '.Titel' , '=', 'deutscher_Bücher’, '.Titel', ')', ] 2 Liste (ersetze Relation deutscher_Bücher durch deutscher_Bücher_new in Liste 1) [ 'SELECT', 'deutscher_Bücher_new', '.Autor', ',', 'deutscher_Bücher_new', '.Titel', ',', 'deutscher_Bücher_new', '.Art', 'FROM', 'deutscher_Bücher_new', 'WHERE', 'EXISTS', '(', 'SELECT', '*', 'FROM', 'Fachliteratur_Minus', ' WHERE', 'Fachliteratur_Minus', '.Autor', '=', 'deutscher_Bücher_new', '.Autor', 'and', 'Fachliteratur_Minus', '.Titel', '=', 'deutscher_Bücher_new', '.Titel', ')', ]

Implementierung _

64

Abbildung 6.3 Compileraufbau

Kapitel 6

65

Abbildung 6.4 Compileraufbau

Liste 1 und Liste 2 werden durch den Operator UNION ALL zu der – dem Leser schon aus dem Beispiel 4.2 bekannten – Delta-Sicht deutsche_Belletristik_Plus zusammengesetzt. Dabei sei angemerkt, dass die virtuelle Relation deutsche_Belletristik selbst auf der Sicht deutscher_Bücher basiert. Hierbei wird die Sicht deutscher_Bücher genauso wie eine Basisrelation behandelt, nur dass deutscher_Bücher_Plus und deutscher_Bücher_Minus keine Tabellen, sondern Delta-Sichten sind. Im vierten und letzten Schritt schließlich werden in Abhängigkeit davon, ob die Aggregatfunktionen in der Haupt-Select -Klausel auftreten oder nicht, Aggregatfunktion_Min_Max_First_Last(Tokenliste,Sichtname), Aggregatfunktion_Count_Sum_Avg(Tokenliste,Sichtname) oder

Implementierung _

66

Effektivitätstest(Sichtname) aufgerufen. Diese Methoden wiederum bilden und fügen die Delta2-Sichten, die entweder den Effektivitätstest oder spezielle Auswertungen für die Aggregatfunktionen darstellen, der aktuellen Datenbank hinzu(siehe Kapiteln 5.2 und 5.5). Die Abbildungen 6.3 und 6.4 zeigen das Aktivitätsdiagramm des in der Diplomarbeit entwickelten Compilers.

6.2 Einbettung in MS Access

Der Compiler wurde durch mehrere benutzerdefinierte Prozeduren und Funktionen realisiert. Für die Testzwecke – und um den Compiler bequem benutzen zu können – wurde ein Programm geschrieben, das es erlaubt, für eine ausgewählte Sicht die Delta-Sichten zu generieren, Änderungen in die Plus-/Minus-Tabellen einzutragen und die geänderten Fakten in den Delta-Sichten anzusehen. Für einen anwenderfreundlichen Umgang mit dem Programm werden insgesamt vier Formulare benötigt: „Start“, „Sichten_Generieren“, „Tabellen_Ändern“ und „Sichten_Ansehen“.

Compiler

MS Access

DBMS

Formular

DBMeta-DB

Anwender

Abbildung 6.5 Systemarchitektur

Kapitel 6

67

Abbildung 6.6 Formular „ Start“

Abbildung 6.5 zeigt, wie das Programm und der Compiler in die MS Access-Datenbank integriert wurden. Der Anwender arbeitet nur mit den Formularen. Das Formular übergibt dem Compiler die SQL-Definition der Sicht, für die die Delta-Sichten generiert werden müssen, und der Compiler legt die dafür generierten Delta- und Transitionssichten sowie die Hilfstabellen in die aktuelle Datenbank. Aus dem Formular heraus kann der Anwender die Plus-/Minus-Tabellen ändern und die Delta-Sichten ansehen. Der Compiler wird aus dem Formular „Start“ (Abbildung 6.6) gestartet. Beim ersten Aufruf des Formulars ist nur eine Option auswählbar: „Sichten generieren“. Bei Auswahl dieser Option wird das Formular „Sichten_generieren“ aufgerufen (Abbildung 6.7). Dort werden dem Anwender die Sichten zur Auswahl vorgeschlagen, die in der aktuellen Datenbank enthalten sind. Für die ausgewählte Sicht wird deren SQL-Definition aus der aktuellen Datenbank gelesen und an den Compiler übergeben. Der Compiler wird nun gestartet. Falls die Sichtattribute auf den Aggregatfunktionen aufbauen, wird die Meldung aus Abbildung 6.8 angezeigt.

Implementierung _

68

Abbildung 6.7 Formular „Sichten_generieren“

Abbildung 6.8 Warnung

Bei Sichten, die keine Aggregatfunktionen in der Haupt-Select -Klausel enthalten, werden in dieser Arbeit Duplikate grundsätzlich ignoriert. Wie schon in Kapitel 5.5 dargelegt, werden die Duplikate bei Sichten, deren Attribute auf Aggregatfunktionen basieren, nicht immer richtig ausgewertet. Ich habe mich aber trotzdem dazu entschieden, solche Sichten – auch wenn die Richtigkeit der Duplikatenauswertung nicht immer garantiert ist – zu bearbeiten. Der Anwender wird an dieser Stelle auf die dadurch möglicherweise entstehenden Fehler hingewiesen. Falls die Sichtdefinition Konstruktionen enthält, die der Compiler nicht auswertet, erscheint die Fehlermeldung aus Abbildung 6.9, und die Verarbeitung wird abgebrochen.

Kapitel 6

69

Abbildung 6.9 Fehlermeldung

Falls in der Sicht Aggregatfunktionen in Selektions- und Gruppierungsbedingungen vorkommen, wird die Verarbeitung mit der Meldung aus Abbildung 6.10 abgebrochen.

Abbildung 6.10 Fehlermeldung 2

Falls der Anwender fälschlicherweiseweise den Compiler für dieselbe Sicht mehrmals startet, erscheint die Meldung aus Abbildung 6.11

Abbildung 6.11 Infomeldung

Wenn der Compiler seine Arbeit beendete hat, so sind alle benötigten Tabellen und Sichten, die in Kapitel 4 beschrieben wurden, angelegt. Der Compiler kann für mehrere Sichten gestartet werden. Erst jetzt sind auch andere Optionen auswählbar. Mit der Option „Tabellen ändern“ wird das Formular „Tabellen_ändern“ (Abbildung 6.12) gestartet. Im Formular kann der Anwender Plus-/Minus-Tabellen aufrufen und Änderungen (Einfügungen oder Löschungen) darin zwischenspeichern. Dabei handelt es sich um die Plus-/Minus-Tabellen jener Tabellen, auf denen die Sichten aufbauen, und für die vorher im Formular „Sichten_generieren“ der Compiler gestartet wurde. Wenn man vorher die Delta-Sichten für die Sicht „Deutsche_Belletristik“ generiert hat, so werden dem Anwender die folgenden Tabellen – genauer gesagt: deren Plus-/Minus-Tabellen – zum Ändern vorgeschlagen: Bücher, Autoren und Fachliteratur. Dabei werden einfach die noch leeren Formulare der Plus-/Minus-Tabellen aufgerufen und zum Ändern bereitgestellt. Durch Klick auf den Button „Verwerfen“ kann man die Änderungen in den Plus-/Minus-Tabellen der gerade ausgewählten Tabelle wieder löschen.

Implementierung _

70

Abbildung 6.12 Formular „Tabellen_ändern“ Die Option „Sichten ansehen“ startet das Formular „Sichten_ansehen“ (Abbildung 6.13). Im Formular kann man die Delta-Sichten, also die geänderten Fakten der ursprünglichen Sicht, ansehen. Dabei werden für die Sichten, für die entweder der Effektivitätstest oder die speziellen Sichten für die MIN/MAX/FIRST/LAST -Aggregatsfunktionen-Auswertung generiert wurden, die Delta2_Sichten aufgerufen, welche separat die eingefügten und die gelöschten Fakten anzeigen. Für die Sichten, deren Attribute auf Aggregatfunktionen wie COUNT, SUM oder AVG basieren, wird nur eine Delta3-Sicht aufgerufen, bei der man die neuen Wert der ursprünglichen Sicht und nicht die Delta-Fakten sieht. Jedes der drei Formulare verfügt über einen „Zurück“-Button, der das betroffene Formular schließt und den Fokus wieder auf das Hauptformular „Start“ setzt. Der Anwender kann die Änderungen speichern oder aber verwerfen. Das Formular „Start“ verfügt über zwei entsprechende Knöpfe. Das heißt, die Änderungen aus den Plus-/Minus-Tabellen werden entweder in die Basistabellen übertragen oder unwiderruflich gelöscht. Alle Änderungen, die der Benutzer in die vorhandenen Plus-/Minus-Tabellen eingegeben hat, werden INNERHALB EINER Transaktion an die Datenbank übergeben. Falls eine der geänderten Fakten die Datenbankintegrität verletzt und nicht eingefügt/ gelöscht werden kann, werden alle Änderungen an den Basistabellen verworfen, und der Benutzer wird durch die Nachricht aus Abbildung 6.14 davon unterrichtet. Die Änderungen werden dabei in Plus-/Minus-Tabellen enthalten bleiben. Dem Anwender wird somit die Möglichkeit gegeben, die Daten zu korrigieren. Die Daten können eventuell nicht eingefügt/ gelöscht werden, falls dadurch die Entity-Integrität oder die

Kapitel 6

71

referentielle Integrität (falls die Tabellen in Beziehung zueinander stehen und die referentielle Integrität aktiviert ist – siehe Abschnit 2.3.3) verletzt werden, oder man versucht, nicht vorhandene Fakten zu löschen, oder die Tabellen von anderen Programmen oder Prozessen geblockt werden. Werden Daten erfolgreich in die Datenbank übertragen, so erscheint die Meldung aus Abbildung 6.15.

Abbildung 6.13 Formular „Sichten_ansehen“

Abbildung 6.14 Fehlermeldung 3

Falls der Benutzer versucht, das Programm – also in diesem Fall das Formular “Start“ – zu schließen, ohne vorher die Änderungen zu speichern oder zu verwerfen, so wird er vom Programm gefragt, wie er mit den Änderungen verfahren möchte. Bei Programmende werden alle generierten Sichten und neu angelegten Tabellen gelöscht. Alle Datenbankschema-Änderungen werden zurückgenommen.

Implementierung _

72

Abbildung 6.2-15 Infomeldung 2

6.3 Compiler-Testbeispiele

Da es leider nicht möglich ist, den Compiler über eine formale Spezifikation zu prüfen, wurde der Compiler durch das systematische Testen geprüft. Die Tests sollen aufgrund der tatsächlichen Sichtänderungen und der Änderungen, welche die Delta-Sichten anzeigen, überprüfen, ob die Delta-Sichten richtig erstellt wurden und der Compiler eine korrekte Übersetzung leistet. Alle Testbeispiele zu zeigen, in denen der Compiler geprüft wurde, würde den Rahmen dieser schriftlichen Arbeit sprengen. Im Folgenden werden nur zwei der komplexeren Beispielfälle gezeigt. Der jeweilige Test wird auf folgende Weise durchgeführt: Zuerst wird die Sicht für den Test ausgewählt und der Inhalt der relevanten Basistabellen festgehalten. Der Compiler wird für die ausgewählte Sicht gestartet. Als nächstes werden die Änderungen in die entsprechenden Plus-/Minus-Tabellen eingetragen und festgehalten. Die Delta-Sichten werden ausgeführt und deren Ergebnisse protokolliert. Die Änderungen werden aus den Plus-/Minus-Tabellen mit Hilfe des Formulars "Start" in die entsprechenden Tabellen übertragen. Als letzter Schritt wird die ausgewählte Sicht nochmals, diesmal im neuen Datenbankzustand, ausgeführt. Die Inhalte der ausgewählten Sicht im alten Datenbankzustand und der Inhalt der Delta-Sichten werden zusammengerechnet und mit dem Inhalt der Sicht im neuen Datenbankzustand verglichen. Falls die Mengen übereinstimmen, arbeitet der Compiler korrekt.

6.3.1 Test 1

Die Sicht hat keine bestimmte Bedeutung. Sie wird an dieser Stelle lediglich benutzt, um zu demonstrieren, welche Konstruktionen mit dem Compiler ausgewertet werden können. Sichtdefinition: SELECT DISTINCT A.Name FROM AAA as A, BBB as B WHERE A.Name=B.Name AND EXISTS (SELECT * FROM CCC AS C WHERE A.Name<>C.Name ) OR A.Name NOT IN (SELECT NAME FROM DDD AS D ) UNION SELECT E.Name FROM EEE AS E

Kapitel 6

73

WHERE EXISTS ( SELECT * FROM FFF AS F WHERE e.Name = F.Name) OR e.name NOT IN (SELECT G.Name FROM GGG as G INNER JOIN HHH as H ON G.Name=H.Name WHERE G.Name NOT IN (SELECT A.NAME FROM AAA AS A WHERE A.Name IS NOT NULL )); Relevante Basistabellen im alten Datenbankzustand:

Implementierung _

74

Sicht im alten Datenbankzustand:

Relevante Plus-/Minus-Tabellen:

Kapitel 6

75

Delta-Sichten:

Sicht im neuen Datenbankzustand:

Der Inhalt der ausgewählten Sicht im alten Datenbankzustand und der Inhalt der Delta-Sichten zusammengerechnet, stimmt mit dem Inhalt der Sicht im neuen Datenbankzustand überein.

6.3.2 Test 2

Die beiden Sichten deutscher_Bücher und deutsche_Belletristik aus Beispiel 2.2.3, welche bei diesem Test zum Einsaz kommen, wurden schon mehrmals in dieser Arbeit erwähnt. Dieser Test hier soll zeigen, dass sogar Sichten, die von anderen Sichten abhängen, durch den Compiler auswertbar sind. In diesem Fall hängt die Sicht Deutsche_Belletristik von der Sicht Deutscher_Bücher ab. Man braucht lediglich die Sicht Deutsche_Belletristik an

Implementierung _

76

den Compiler zu übergeben – die Sicht Deutscher_Bücher dagegen kann, muss aber nicht explizit übergeben werden. Die Delta-Sichtenfür die beiden Sichten sehen wie folgt aus: Delta_Plus-Regel für deutscher_Bücher: SELECT Bücher_Plus.Autor , Bücher_Plus.Titel , Bücher_Plus.Art FROM Bücher_Plus , Autoren_New WHERE Bücher_Plus.Autor = Autoren_New.Autor And Autoren_New.Land = "Deutschland" UNION ALL SELECT Bücher_New.Autor , Bücher_New.Titel , Bücher _New.Art FROM Bücher_New , Autoren_Plus WHERE Bücher_New.Autor = Autoren_Plus.Autor And Autoren_Plus.Land = "Deutschland"; Delta_Minus-Regel für deutscher_Bücher: SELECT Bücher_Minus.Autor , Bücher_Minus.Titel , Bücher_Minus.Art FROM Bücher_Minus , Autoren WHERE Bücher_Minus.Autor = Autoren.Autor And Autoren.Land = "Deutschland" UNION ALL SELECT Bücher.Autor , Bücher.Titel , Bücher.Art FROM Bücher , Autoren_Minus WHERE Bücher.Autor = Autoren_Minus.Autor And Autoren_Minus.Land = "Deutschland"; Delta_Plus-Regel für deutsche_Belletristik: SELECT deutscher_Bücher_Plus.Autor , deutscher_Bücher_Plus.Titel , deutscher_Bücher_Plu s.Art FROM deutscher_Bücher_Plus WHERE NOT EXISTS ( SELECT * FROM Fachliteratur_New WHERE Fachliteratur_New.Autor=deutscher_Bücher_Plus.Auto r AND Fachliteratur_New.Titel=deutscher_Bücher_Plus.Tite l ) UNION ALL SELECT deutscher_Bücher_New.Autor , deutscher_Bücher_New.Titel , deutscher_Bücher_New. Art FROM deutscher_Bücher_New WHERE EXISTS ( SELECT * FROM Fachliteratur_Minus WH ERE Fachliteratur_Minus.Autor = deutscher_Bücher_New.A utor AND Fachliteratur_Minus.Titel = deutscher_Bücher_New.T itel); Delta_Minus-Regel für deutsche_Belletristik:

Kapitel 6

77

SELECT deutscher_Bücher_Minus.Autor , deutscher_Bücher_Minus.Titel ,deutscher_Bücher_Minu s.Art FROM deutscher_Bücher_Minus WHERE NOT EXISTS ( SELECT * FROM Fachliteratur WHER E Fachliteratur.Autor = deutscher_Bücher_Minus.Autor AND Fachliteratur.Titel = deutscher_Bücher_Minus.Titel ) UNION ALL SELECT deutscher_Bücher.Autor , deutscher_Bücher.Ti tel , deutscher_Bücher.Art FROM deutscher_Bücher WHERE EXISTS ( SELECT * FROM Fachliteratur_Plus WHE RE Fachliteratur_Plus.Autor = deutscher_Bücher.Autor AND Fachliteratur_Plus.Titel = deutscher_Bücher.Titel ); Relevante Basistabellen im allten Datenbankzustand:

Implementierung _

78

Sicht im alten Datenbankzustand:

Relevante Plus-/Minus-Tabellen:

Kapitel 6

79

Delta-Sichten:

Implementierung _

80

Sichten im neuen Datenbankzustand:

Der Inhalt der ausgewählten Sicht im alten Datenbankzustand und der Inhalt der Delta-Sichten zusammengerechnet, stimmt mit dem Inhalt der Sicht im neuen Datenbankzustand überein.

6.4 Schlussfolgerung

Die Überprüfung der Testdaten war erfolgreich. Daraus lässt sich schließen, dass die Übersetzung der SQL-Sichten in die Delta-Sichten mit Hilfe des Compilers korrekt ist. Durch die Tests wurde festgestellt, dass die Performance der Übersetzungsalgorithmen gut ist. Sogar bei verschachtelten Sichten wurden die Definitionen ohne Verzögerungen übersetzt. Alle Übersetzungen dauerten weniger als 1 Sekunde. Die Dauer der Auswertung der Delta-Sichten hängt von der benutzten Hardware und der Komplexität der zugrunde liegenden Sichten und Datenmengen ab – im Average-Case dauert es nur wenige Sekunden, im Worst-Case dagegen kann es bis zu einigen Minuten dauern.

Kapitel 7

81

7 Zusammenfassung und Perspektiven

In der vorliegenden Arbeit wurde eine inkrementelle Sichtanpassung in einer relationalen Datenbank, MS Access 2002, realisiert. Dafür wurde ein Compiler für die Übersetzung der SQL-Sichten in Delta-Sichten entworfen und implementiert. Zusammenfassung Zu Beginn wurden die Grundlagen dieser Arbeit erläutert. SQL wurde in Abschnitt 2 vorgestellt. In Kapitel 3 wurden die Grundlagen der MS Access Datenbank sowie der Programmiersprache VBA erklärt. In Abschnitt 4 wurden relationale deduktive Datenbanken und deren Anfragesprache Datalog sowie das Konzept der inkrementellen Sichtenanpassung erläutert.. In Abschnitt 5 wurde ein Algorithmus entwickelt, der Delta-Sichten für SQL-Sichten erstellt, ohne dass erstere in datalogähnliche Form überführt werden müssten. Bei dieser Arbeit wurde nicht eine Teil-Sprache von SQL betrachtet, sondern es wurde in erster Linie darauf geachtet, dass die von dem Compiler bearbeiteten Sichten die Möglichkeiten von Access-SQL zum größten Teil ausschöpfen können. Es wurde festgestellt, dass der Compiler SELECT-Statements mit Verschachtelungen beliebiger Tiefe, die durch Operatoren (NOT) EXISTS und (NOT) IN eingeleitet werden, bearbeiten kann. Operatoren und Schlüsselwörter wie DISTINCT , DISTINCTROW, IN , BETWEEN, LIKE , IS (NOT) NULL, IIF (<Expr>, True, False) oder AS, welche in der WHERE-Bedingung oder in der SELECT-Klausel auftreten können, stellen dabei kein Problem dar. Der einzige Mengenoperator – UNION – und der INNER JOIN -Operator werden vom Compiler ebenfalls richtig übersetzt. Es haben sich aber Beschränkungen für die SQL-Anweisungen, die vom Compiler bearbeitet werden, herausgestellt. Es wurde festgestellt, dass der für diese Arbeit entwickelte Compiler die LEFT/RIGHT (OUTER) JOINs nicht richtig auswerten kann. Es wurde allerdings auch eine Lösung für dieses Problem vorgeschlagen. Außerdem wurde festgestellt, dass das Problem der Duplikate in dieser Arbeit nur bedingt gelöst wurde. Standard-Aggregatfunktionen wie MIN, MAX, COUNT, SUM oder AVG, die in der Haupt-SELECT-Klausel auftreten, werden zwar vom Compiler bearbeitet – allerdings ist, da die richtige Behandlung von Duplikaten durch den Compiler nicht garantiert ist, auch die Korrektheit der Auswertung der Aggregatfunktionen nicht garantiert.

Zusammenfassung und Perspektiven _

82

In Abschnitt 6 wurde die Implementierung des Compilers im VBA-Kontext vorgestellt sowie das Programm und die dabei verwendeten Formulare erläutert und abgebildet. Für die Testzwecke – und um den Compiler bequem benutzen zu können – wurde ein Programm geschrieben, das es erlaubt, für die ausgewählte Sicht die Delta-Sichten zu generieren, Änderungen in die Plus-/Minus-Tabellen einzutragen sowie die geänderten Fakten in den Delta-Sichten anzusehen. Die Überprüfung der Testdaten war erfolgreich. Daraus lässt sich schließen, dass die Übersetzung der SQL-Sichten in die Delta-Sichten mit Hilfe des Compilers korrekt ist. Alle Übersetzungen dauerten weniger als 1 Sekunde. Perspektiven Der Compiler kann leicht um eine Verarbeitung der OUTER JOIN-Operatoren ergänzt werden, indem man LEFT durch RIGHT sowie RIGHT durch LEFT ersetzt, so dass unbedingt alle Einträge der Plus-/Minus-Tabellen komplett in den Join übernommen werden – und nicht die der New-(/Old-)Tabellen (siehe Abschnitt 5.3). Als mögliche Weiterentwicklung des in dieser Arbeit beschriebenen Compilers kann eine Verarbeitung der Aggregatfunktionen in den Selektions- und Gruppierungsbedingungen und eine Garantie für die Richtigkeit der Duplikatenverarbeitung genannt werden. Bis jetzt wurde die Änderungspropagierung nur in Bezug auf Einfügungen und Löschungen betrachtet; sie kann aber auch auf Modifikationen, also auf Änderungen schon existierender Fakten, übertragen werden. Man kann schon jetzt die Modifikationen durch die vom Compiler erstellten Delta-Sichten auswerten lassen. Dazu muss man die Änderungen schon existierender Fakten als Löschung und Wiedereinfügung betrachten. Allerdings wird ein so modifizierter Fakt einmal als gelöschter Fakt in der alten Konstellation sowie einmal als neu eingefügter Fakt in der neuen Konstellation angezeigt.

Literaturverzeichnis

83

Literaturverzeichnis

[ANSI99I] ANSI/ISO/IEC 9075-1-1999: Database Languages - SQL – Part l:Framework. ANSI American National Standards Institute, New York, 1999. http://www.cse.iitb.ac.in/dbms/Data/Papers-Other/SQL1999/ansi-iso-9075-1-1999.pdf

[ANSI99II] ANSI/ISO/IEC 9075-2-1999: Database Languages - SQL – Part 2: Foundation. ANSI American National Standards Institute, New York, 1999. http://www.cse.iitb.ac.in/dbms/Data/Papers-Other/SQL1999/ansi-iso-9075-2-1999.pdf

[ASU88] Aho, A.V., Sethi, R. & Ullmann, J.D.: Compilerbau. Teil 1, Teil 2. Addison-Wesley, Deutschland, 1988

[BMS86] Bancilhon, F., Maier, D., Ullman, J., Sagiv, Y.: "Magic Sets and other strange ways to implement logic programs"

[Bro99] Brosius, G.: “Access 2000 professionell: Datenbank-Management mit Office 2000”. Addison-Wesley-Longman, 1999

[Cod70] Codd,. E.F. “A Relational Model of Data for Large Shared Data Banks”. Communications of the ACM, 13(6),June 1970.

[Cal04] Calí, V.. Erweiterungskonzepte für das aktive Datenbanksystem ARTA. Rheinische Friedrich-Wilhelms-Universität Bonn, 2004

[GMS93] Gupta, A., Mumick, I.S., Subrahmanian, V.S.: Maintaining Views Incrementally. Proc. SIGMOD 1993, Washington/DC, USA, S. 157-166.

[HS02] Hoffbauer, M/ Spielmann, C. Access XP Version 2002 Programmierung – das Buch. SYBEX-Verlag , Düsseldorf , 1. Auflage, 2001

[KE01] Kemper, A. Eicker, A. Datenbanksysteme. Oldenburg Verlag, München, 4.Auflage, 2001

Literatursverzeichnis

84

[Jet] Microsoft Access Hilfe http://msdn.microsoft.com/library/default.asp?url=/library/ens/dnacc2k/html/acfundsql.asp

[Man00] Manthey, R.: Skript zur Vorlesung Deduktive Datenbanken WS00/01, Universität Bonn, Institut für Informatik III.

[Man02] Manthey, R.: Skript zur Vorlesung Informationssysteme WS02/03, Universität Bonn, Institut für Informatik III

[Mar01] Martini,R.:Effiziente Implementierung des alternierenden Fixpunktoperators unter Verwendung von Änderungspropagierung. Rheinische Friedrich-Wilhelms-Universität Bonn, 2001

[Mul03] Mullere, P.: Entwurf und Implementierung eines Compilers zur Übersetzung von SQL-Anfragen nach Datalog. Rheinische Friedrich-Wilhelms-Universität Bonn, 2003

[ Sta99] Staas, D.: VBA Programmierung mit Office 2000. Carl Hanser Verlag, München/ Wien, 1999

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

Documents

Rheinische Friedrich-Wilhelm-Universität Bonn · (Listenfelder, Radio-Buttons etc.). Jeder Wert eines Fremdschlüssels muss als Jeder Wert eines Fremdschlüssels muss als Schlüsselwert