pdf (1820 Kb) - Fachgebiet Datenbanken und Informationssysteme ...

Leibniz Universität Hannover
Fakultät für Elektrotechnik und Informatik
Institut für Praktische Informatik
Fachgebiet Datenbanken und Informationssysteme
Bachelorarbeit
im Studiengang Informatik
Relationenalgebra als Datenbankanfragesprache
Stefanie Bernhardt
Matr.-Nr. 2517460
12. Mai 2009
Prüfer und Betreuer: Prof. Dr. Udo Lipeck
Zweitprüfer: Dr. Hans Hermann Brüggemann

Inhaltsverzeichnis
1 Einleitung 3
1.1 Zielsetzung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Grundlagen 4
2.1 Die Relationenalgebra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Grundoperationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2 Ableitbare Operationen . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.3 Erweiterung der Relationenalgebra . . . . . . . . . . . . . . . . . . 6
2.2 Prinzipieller Aufbau eines Compilers . . . . . . . . . . . . . . . . . . . . . 7
2.3 JavaCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.4 Die JavaCC-Grammatikdatei . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3 Anforderungen im Detail 12
3.1 Mindestanforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2 Verbesserungsmöglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4 Entwurf 14
4.1 Syntax der Anfragesprache . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 Analyse der Eingabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.1 Lexikale Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.2 Syntaktische Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.3 Semantische Analyse: . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.4 Die Symboltabelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3 SQL-Code-Erzeugung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5 Implementierung 48
5.1 Package-Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.2 Die Grammatikdatei und generierte Klassen . . . . . . . . . . . . . . . . . 48
5.3 Beschreibung der nicht generierten Klassen . . . . . . . . . . . . . . . . . . 49
6 Die Benutzerschnittstelle 56
Abbildungsverzeichnis 58
Tabellenverzeichnis 59
2

Kapitel 1
Einleitung
1.1 Zielsetzung der Arbeit
Ziel dieser Arbeit ist die Entwicklung einer Datenbankanfragesprache auf Basis der Relationenalgebra.
Dazu soll eine graphische Benutzerschnittstelle bereitgestellt werden, die
auf komfortable Weise die Eingabe von Anfragen in der Relationenalgebra ermöglicht,
sowie Ausgaben und ggf. Fehlermeldungen anzeigt. Die Anfragen werden intern in ihrer
Struktur analysiert und auf Fehler geprüft. Im Fall eines Fehlers soll eine aussagekräftige
Fehlermeldung ausgegeben werden. Ist die Anfrage fehlerfrei, so wird sie vereinfacht, in
SQL übersetzt und an das Oracle-DBS gesendet. Die Ergebnistabellen sollen dem Nutzer
in einem Ausgabebereich angezeigt werden.
Der Hauptteil dieser Arbeit wird sich mit der Analyse, der Vereinfachung und der Übersetzung
von Anfragen beschäftigen. Daneben spielen die Bereitstellung der Benutzerschnittstelle,
die Verbindung zum Datenbanksystem und die Erweiterbarkeit eine große
Rolle.
Nach seiner Fertigstellung soll das Programm Studenten als Lernmittel dienen, um den
sonst nur theoretischen Umgang mit der Relationenalgebra durch praktische Anwendung
besser verinnerlichen zu können.
1.2 Gliederung der Arbeit
Im Anschluss an diese kleine Einleitung sollen zunächst die nötigen Grundlagen erläutert
werden, bevor etwas detaillierter auf die Anforderungen eingegangen wird. Im vierten Kapitel
soll der Entwurf vorgestellt werden. Hier wird zunächst die Anfragesprache entworfen.
Die folgenden Unter-Kapitel beschäftigen sich mit dem Entwurf der einzelnen Analyseund
Übersetzungs-Komponenten. Kapitel 5 gibt einen Überblick über die implementierten
Klassen. Abschließend wird die Benutzeroberfläche vorgestellt.
3

Kapitel 2
Grundlagen
2.1 Die Relationenalgebra
Die Relationenalgebra ist die Menge aller endlichen Relationen zusammen mit Operationen.
Durch Kombination von Operationen lassen sich Terme formulieren, die man als
prozedurale Datenbank-Anfragesprache auffassen kann.
Im Folgenden werden die einzelnen relationalen Operationen beschrieben. Dabei sei jeweils
für die Relation R das Schema (A 1 : D 1 , ..., A n : D n ), sowie für die Relation S das
Schema (B 1 : D 1 , ..., B m : D m ) mit Attributen A i , B j und Datentypen D k vorausgesetzt.
2.1.1 Grundoperationen
• R ∪ S
Die Vereinigung R ∪ S vereinigt alle Tupel zweier Relationen R und S unter der
Vorraussetzung, dass beide Relationen die gleichen Schemata besitzen.
Voraussetzung: Schema(R)=Schema(S)=(A 1 , ..., A n )
Ergebnis-Schema: (A 1 , ..., A n )
Ergeibnis-Relation: {t | t ∈ R ∨ t ∈ S}
• R − S
Die Differenz R − S liefert alle R-Tupel, die nicht in S enthalten sind.
Voraussetzung: Schema(R)=Schema(S)=(A 1 , ..., A n )
Ergebnis-Schema: (A 1 , ..., A n )
Ergebnis-Relation: {t | t ∈ R ∧ t /∈ S}
• σ ϕ (R)
Die Selektion σ ϕ (R) liefert eine Teilmenge aller Tupel einer Relation R entsprechend
der Selektionsformel ϕ. Dabei ist ϕ entweder eine atomare Selektionsformel
oder eine Zusammensetzung atomarer Selektionsformeln mit den logischen Operatoren
∧, ∨, ¬, ⇒, ⇔. Eine atomare Selektionsformel sei ϕ = θ (α 1 , ..., α n ) mit θ:
n-stelliger Vergleichsoperator und α k : Attributterm aus R-Attributen, Datentyp-
Operationen und Datentyp-Konstanten.
Ergebnis-Schema: Schema(R)=(A 1 , ..., A n )
Ergebnis-Relation: {t | t ∈ R ∧ t erfüllt ϕ}
4

• π Ā (R)
Die Projektion π Ā (R) liefert alle Spalten einer Relation R entsprechend der Attributliste
Ā. Die Attributliste besteht aus R-Attributtermen und jeweils einem
optionalen Aliasnamen.
Voraussetzung: Ā = (α 1 C 1 , ..., α k C k )) α i : Attributterm, C i : Aliasname
Ergebnis-Schema: (C 1 , .., C k )
Ergebnis-Relation: {t : (C 1 , .., C k ) | r ∈ R, t = (π α1 (r) , ..., π αk (r))}
• R × S
Das Kartesische Produkt R×S bildet alle möglichen Kombinationen von Tupeln
aus R und S. Vorraussetzung ist, dass die Attributmengen von R und S disjunkt
sind.
Voraussetzung: {A 1 , ..., A n } ∩ {B 1 , ..., B m } = ∅
Ergebnis-Schema: (A 1 , ..., A n , B 1 , ..., B m )
Ergebnis-Relation: {t | r ∈ R, s ∈ S, t = r · s}
2.1.2 Ableitbare Operationen
• R ∩ S = R − (R − S)
Der Durchschnitt R ∩ S liefert alle Tupel, die in R und S enthalten sind.
Voraussetzung: Schema(R)=Schema(S)=(A 1 , ..., A n )
Ergebnis-Schema: (A 1 , ..., A n )
Ergebnis-Relation: {t | t ∈ R ∧ t ∈ S}
• R ⊲⊳ ϕ
S = σ ϕ (R × S)
Der Verbund bzw. Join liefert alle Kombinationen von R- und S-Tupeln bei denen
die Verbundsbedingung ϕ erfüllt ist. Dabei ist die Verbundsbedingung ϕ eine
Mengen von ∧-verknüpften Vergleichen A i θB j von Attributtermen von R und S mit
Vergleichsoperator θ. Für θ ≡= handelt es sich um einen Equijoin.
Ergebnis-Schema: (A 1 , ..., A n ) · (B 1 , ..., B m )
Ergebnis-Relation: {r · s | r ∈ R ∧ s ∈ S ∧ r, s erfüllen ϕ}
• R ⊲⊳ S = R ⊲⊳ ϕ S mit ϕ = ∧ A i = B j S, wobei A i , B j jeweils namensgleiche
Attribute von R und S sind. Der Natural Join ist somit ein Equijoin über alle
namensgleichen Attribute von R und S.
Ergebnis-Schema: {A 1 , ..., A n } ∪ {B 1 , ..., B m }
Ergebnis-Relation: {t mit Attributen {A 1 , ..., A n } ∪ {B 1 , ..., B m } |
π A1 ,...,A n
(t) ∈ R ∧ π B1 ,...,B m
(t) ∈ S
• R ⊲< S
Der Semijoin R ⊲< ϕ S = π Attribute(R) (R ⊲⊳ ϕ S) liefert alle R-Tupel, die mindestens
einen Joinpartner in S haben.
Ergebnis-Schema: Schema(R)=(A 1 , ..., A n )
Ergebnis-Relation: {t ∈ R | ∃ (s ∈ S) t, s erfüllen ϕ}
5

• R ⊲< ϕ
S
Der Anti-Semijoin R ⊲< ϕ S = R − (R ⊲< ϕ S) liefert alle R-Tupel, die keine
Joinpartner in S haben.
Ergebnis-Schema: Schema(R)=(A 1 , ..., A n )
Ergebnis-Relation: {t ∈ R | ¬∃ (s ∈ S) t, s erfüllen ϕ}
• R ⊐⊲⊳⊏ ϕ S
Der Outerjoin liefert alle Tupel aus dem Join zwischen R und S mit zusätzlich
allen R und S-Tupeln, die keinen Joinpartner haben (mit Nullwerten aufgefüllt)
Ergebnis-Schema: (A 1 , ..., A n ) · (B 1 , ..., B m )
Ergebnis-Relation: {t · s | t ∈ R , s ∈ S , t, s erfüllen ϕ}
∪ { t · (⊥, · · · , ⊥) | t ∈ R , t /∈ (R ⊲⊳ S) t erfüllt ϕ}
∪ { (⊥, · · · , ⊥) · s | s /∈ (R ⊲⊳ S) s erfüllt ϕ}
Varianten:Left Outer Join, Right Outer Join
Hierbei werden nur die Tupel der linken (bzw rechten) Relation mit Nullwerten
aufgefüllt.
• Division R ÷ S
Für R(A 1 , ..., A n ) und S(B 1 , ..., B m ) und unter der Voraussetzung (B 1 , ..., B m ) =
(A n−m+1 , ..., A n ) selektiert die Division R ÷ S alle (A 1 , ..., A n−m )-Tupel aus R die
mit allen S-Tupeln in R auftreten.
Voraussetzung: Schema(S) ⊆ Schema(R), S ≠ ∅
Ergebnis-Schema: (A 1 , . . . , A n−m ),
Ergebnis-Relation: { t: (A 1 , . . . , A n−m ) | ∃(r ∈R) ( t=π A1 ,...,A n−m
(r) ∧ ∀(s∈S) t·s ∈
R ) }
• Umbenennungen
Jeder Relationsoperand darf mit einem Alias versehen werden. Für eine Relation
R und ein Alias X, ist die Schreibweise (R X). Auf die Attribute der umbenannten
R-Relation wird mit X.A i zugegriffen.
2.1.3 Erweiterung der Relationenalgebra
• Γ Ḡ# ¯F (R)
Die Gruppierung Γ Ḡ# ¯F (R) liefert alle Spalten entsprechend ¯F von Tupel-Gruppen
mit gleichen Ḡ-Werten. ¯F enthält eine Liste von gruppeninvarianten R-Attributtermen
und auf R-Attributterme angewendete Aggregatfunktionen wie count, min,
max, sum, avg. Für Ḡ = ∅ bilden alle Tupel eine Gruppe.
Beispiel: Γ ∅#count(∗) (ST UDENT EN)
Voraussetzung: ¯F = (α1 C 1 , ..., α k C k )) α i : Attributterm oder Aggr.-Funktion, C i :
Aliasname
Ergebnis-Schema: (C 1 , .., C k )
6

2.2 Prinzipieller Aufbau eines Compilers
Im Allgemeinen bestehen Compiler aus sechs Funktionseinheiten mit klar abgegrenzten
Aufgabenbereichen. Dieses Vorgehen ermöglicht eine hohe Wiederverwendbarkeit einzelner
Komponenten und vereinfacht nachträgliche Änderungen durch Austauschen einzelner
Einheiten. In der Praxis gibt es durchaus Abweichungen in der Anzahl der Komponenten,
sowie in der Verteilung ihrer Aufgaben, was aber an der grundlegenden Funktionsweise
nichts ändert. Im folgenden Abschnitt werden kurz die typischen Funktionseinheiten
erläutert.
Lexikale Analyse
Die aktive Komponente der lexikalen Analyse ist der Scanner bzw. Lexer. Der Scanner liest
den zu übersetzenden Code zeichenweise ein und erzeugt daraus eine Tokenfolge. Jedes
Token besteht dabei aus einer Tokenklasse und ggf. einem Tokenwert. Ein Tokenwert ist
ein Zeiger auf den entsprechenden Eintrag in der Symboltabelle, in welcher Informationen
über die auftretenden Tokens abgespeichert werden.
Syntaktische Analyse
Die aktive Komponente der syntaktischen Analyse ist der Parser. Er analysiert die vom
Scanner erzeugte Tokenfolge anhand einer Grammatik, die die Syntax der Quellsprache
beschreibt, und erzeugt daraus einen Syntaxbaum.
Semantische Analyse
Die letzte Analysephase ist die semantische Analyse. Die Hauptaufgaben der semantischen
Analyse sind die Datentypprüfung und die Untersuchung von Gültigkeitsbereichen. Bei
behebbaren Typfehlern kann ggf. eine Typanpassung vorgenommen werden.
Zwischencodeerzeugung
Damit ist die Analyse der Eingabe abgeschlossen. In manchen Fällen wird an dieser Stelle
schon direkt der Zielcode erzeugt. Im Allgemeinen wird jedoch zunächst ein Zwischencode
erzeugt, der sich leicht produzieren lässt und sich leicht in die Zielsprache übersetzen lässt.
Der Zwischencode kann als Basis für verschiedene Übersetzungen in ähnliche Sprachen
dienen und soll Optimierungen vereinfachen.
Codeoptimierung
Der Zwischencode wird nun in Hinblick auf Laufzeitverhalten und Speicherplatzbedarf
optimiert. Dazu werden zum Beispiel überflüssige Berechnungen entfernt oder Anweisungen
verschoben, sofern sie im Zielcode dadurch seltener ausgeführt werden müssen und
die Verschiebung semantisch nichts verändert.
Zielcodeerzeugung
In der letzten Phase wird nun aus dem optimierten Zwischencode der Zielcode erzeugt.
7

2.3 JavaCC
JavaCC steht für Java Compiler Compiler und ist gleichzeitig Scanner- und Parsergenerator,
der in Java implementiert ist und Java-Code erzeugt. JavaCC ist Open Source und
unter den Bedingungen der BSD-Lizenz herausgegeben. Optional kann statt Scanner und
Parser auch nur eine der Komponenten erzeugt werden. Ein einfacher generierter Scanner
(TokenManager) erzeugt eine Tokenfolge und speichert für jedes Token den Tokenwert, die
Tokenklasse und die Position. Der Tokenmanager wirft Fehler vom Typ TokenMgrError,
die die Fehlerquelle gut beschreiben. Für Fehler in der Eingabe wird eine Fehlermeldung
mit der genauen Position des unerwarteten Zeichens und einigen zusätzlichen Informationen
ausgegeben. Auch interne Fehler, wie Endlosschleifen oder der Versuch einer zweiten
Instanzierung des Tokenmanagers werden identifiziert. Der generierte Parser ist ein LL(n)-
Parser, wobei standardmäßig n=1 ist. Das Lookahead kann aber nicht nur optional größer
eingestellt werden, sondern auch dynamisch während des Parsens angepasst werden. (ParseException
noch erklären )
Einfache Scanner und Parser können mit wenig Aufwand erzeugt werden. JavaCC bietet
aber auch zahlreiche Möglichkeiten komplexere Strukturen zu scannen und zu parsen.
Für den Tokenmanager können verschiedene Zustände (lexical states) definiert werden,
in denen er unterschiedliche Token erkennt, was zum Beispiel zur Handhabung von Kommentaren
hilfreich sein kann. Neben normalen Token und zu überlesenden Zeichenketten
lassen sich SpecialTokens definieren, die an jeder beliebigen Stelle im Programm unabhängig
von der Grammatik auftreten dürfen und keinen Einfluss auf den Parsingvorgang
haben. Um dies zu gewährleisten tauchen die SpecialToken in der normalen Tokenfolge
nicht auf. Stattdessen besitzt jedes Token einen zweite Referenz, auf ein SpecialToken
unmittelbar vor dem Token. Jedes SpecialToken besitzt eine Referenz zum nächsten SpecialToken.
Somit kann bei Bedarf auf die normale Tokenfolge ohne Specialtokens, auf die
Specialtokenfolge und auf die Position der SpecialTokens innerhalb der Tokenfolge zugegriffen
werden. Zusätzlich gibt es noch eine vierte Möglichkeit mit gescannten Zeichen
umzugehen, dabei wird die eingelesene Zeichenkette zunächst zwischengespeichert und
dem nächsten erkannten Token zugefügt. Auch diese Funktion kann zum Beispiel beim
Umgang mit Kommentaren hilfreich sein.
Die Token für die Lexikale Analyse, sowie die Grammatik für den Parser, Einstellungen
des Compilers und Javacode-Fragmente werden zusammen in einer Grammatikdatei
definiert. Dabei werden die Token entweder als Strings oder als reguläre Ausdrücke notiert.
Die Parser-Produktionen werden in EBNF oder in Javacode angegeben. Aus der
Grammatikdatei erzeugt der JavaC-Compiler alle nötigen Dateien. Die erzeugten Klassen
umfassen dabei die Klassen für den Parser, den Scanner (TokenManager) und eine
Constants-Klasse, welche die definierten Token auf Konstanten abbildet. Diese Klassen
werden bei jedem Kompiliervorgang neu erzeugt. Zusätzlich werden, sofern sie nicht bereits
vorhanden sind, vier weitere Klassen erzeugt: Token.java, SimpleCharStream.java,
TokenMgrError.java und ParseException.java.
Ein großer Vorteil von JavaCC ist, dass man sehr viele Möglichkeiten hat die Erzeugung
von Klassen und deren Verhalten zu beeinflussen. Beispielsweise bietet JavaCC verschiedene
Optionen, die zu Beginn in der Grammatikdatei auf die gewünschten Werte gesetzt
werden können. Zum Beispiel lässt sich mit den Optionen USER_CHAR_STREAM und
USER_TOKEN_MANAGER die Erzeugung der konkreten Charstream- und TokenManager-
Klassen unterbinden und stattdessen Interfaces erzeugt. Über die Option BUILD_PARSER
8

lässt sich die Erzeugung des Parsers abstellen. COMMON_TOKEN_ACTION ist eine
Option die standardmäßig false ist. Setzt man sie auf true, so wird nach jedem gescannten
Token die Methode CommonTokenActen(Token t) aufgerufen, die man selbst definieren
kann. Dies eignet sich zum Beispiel sehr gut um die Symboltabelle mit den verschiedenen
Token zu füllen. Natürlich gibt es noch eine Vielzahl weiterer Optionen, auf die ich aber
an dieser Stelle aber nicht weiter eingehen möchte.
Zusätzlich lässt sich die Grammatikdatei an vielen Stellen mit Javacode anreichern. Das
Grundgerüst der Parserklasse wird standardmäßig in der Grammatikdatei definiert. Für
den Scanner lassen sich neben der CommonTokenAction auch lexikale Aktionen definieren:
Jedem regulärem Ausdruck kann ein Java-Block folgen, in dem die Aktion definiert
wird, die nach Erkennung eines Wortes des Ausdrucks ausgeführt werden soll. Ähnlich
können für den Parser parser_actions definiert werden, die bei Anwendung einer Produktion
ausgeführt werden, dies könnten zum Beispiel Anweisungen zum Konstruieren eines
Syntaxbaumes sein. Zum Erstellen eines Syntaxbaumes kann auch optional ein Präprozessor
wie JJTree oder JTB vorgeschaltet werden. In diesem Fall wird die eigentliche
.jj-Grammatikdatei aus einer, im Fall von JJTree, .jjt-Grammatikdatei generiert. JJTree
ergänzt den Code dabei um den Aufbau des Syntaxbaumes.
Man erkennt schnell dass sich JavaCC sowohl für einfache, sowie auch für komplexe
Scanner und Parser eignet. Die von vorne herein vorhandene gute Fehlererkennung, die
zahlreichen Einstellmöglichkeiten und vor Allem die Möglichkeit einzelne Produktion mit
Javacode anzureichern, machen die Nutzung dieses Tools für diese Arbeit möglich. Wie
bereits oben erwähnt, bringt die Nutzung eines Generators erhebliche Vorteile in Punkt
Erweiterbarkeit mit sich, weswegen JavaCC hier auf jeden Fall benutzt werden soll.
2.4 Die JavaCC-Grammatikdatei
Der Aufbau der Grammatikdatei soll hier nur grob erläutert werden. Eine ausführliche
Beschreibung findet sich unter https://javacc.dev.java.net/doc/javaccgrm.html .
Die Grammatikdatei beginnt bei Bedarf mit einem Optionenblock. Einige der möglichen
Optionen habe ich oben bereits erwähnt, JavaCC bietet aber eine Vielzahl weiterer möglicher
Optionen zur Anpassung der generierten Klassen an die jeweiligen Bedürfnisse des
Entwicklers. Der Optionenblock wird mit dem Schlüsselwort options eingeleitet. Zwischen
geschweiften Klammern werden dann den Optionen die gewünschten Werte zugewiesen.
Ein Optionenblock könnte also wie folgt aussehen:
options
{
LOOKAHEAD=2;
IGNORECASE=true;
COMMON_TOKEN_ACTION=true;
}
Möchte man die Standardeinstellungen beibehalten, kann der Optionenblock weggelassen
werden.
Als nächstes folgt compiliation_unit, eingeschlossen in die Schlüsselwörter
PARSER_BEGIN(parser_name) und PARSER_END(parser_name). Hier erfolgt die
Definition der Parser-Klasse, die beim Kompiliervorgang von JavaCC mit Code gefüllt
werden soll. Außerdem kann hier eine Package-Deklaration angegeben sein, die für alle ge-
9

nerierten Klassen gelten soll, so wie Import-Anweisungen für die Parser und TokenManger-
Klassen. Ein Beispiel für eine compilation_unit:
PARSER_BEGIN(TestParser)
package foo;
public class TestParser {
public static void main(String args[]) throws ParseException {
eg1 parser = new eg1(System.in);
try {
TestParser.StartSymbol();
System.out.println("Thank␣you.");
} catch (Exception e) {
System.out.println(e.getMessage());
TestParser.ReInit(System.in);
}
}
}
PARSER_END(TestParser)
Anschließend müssen die Produktionen für den Scanner und den Parser definiert werden.
Der gesamte Aufbau der Grammatikdatei ist auf der javacc-Homepage in EBNF dokumentiert.
Da die Produktionen sehr unterschiedlich aufgebaut sein können, ist die Definition
in EBNF hier auch sehr sinnvoll, weswegen ich diese übernehme.
Eine regular_expression_production wird durch eins der vier Schlüsselwörter TOKEN,
SKIP, SPECIAL_TOKEN oder MORE eingeleitet, die den Umgang mit Wörtern dieses
Ausdrucks festlegen. Gegebenenfalls wird dem Schlüsselwort eine Liste der Zustände, in
denen der reguläre Ausdruck erkannt werden soll, vorangestellt.
regular_expression_production ::=
["" | ""]
( TOKEN | SKIP | SPECIAL_TOKEN | MORE ) [IGNORE_CASE]":"
"{" regexpr_spec ( | regexpr_spec )∗ "}"
regexpr_spec ::=
regular_expression [java_block_for_lexical_action][":" identifier_for_lexical_state ]
regular_expression ::=
java_string_literal
| ""
| ""
| ""
complex_regular_expression_choices ::=
complex_regular_expression ( "|" complex_regular_expression )∗
complex_regular_expression ::=
( complex_regular_expression_unit )∗
complex_regular_expression_unit ::=
java_string_literal
| ""
| character_list
| "(" complex_regular_expression_choices ")" [ "+" | "∗" | "" ]
Beispiel:
10

TOKEN :
{
|
|
|
|
}
Das für die regular_expression angegebene Symbol "#"dient der Markierung von privaten
regulären Ausdrücken, die nur zur Hilfe definiert werden und selbst kein Token darstellen.
Die Methode CommonTokenAction sowie Variablen und Methoden, die für lexikale Aktionen
benötigt werden an einer zentralen Stelle definiert, eingeleitet durch das Schlüsselwort
TOKEN_MGR_DECLS.
token_manager_decls ::= "TOKEN_MGR_DECLS" ":" java_block
Die Produktionen der Grammatik für den Parser werden in BNF notiert. Da jedes nichtterminale
Symbol nach der Generierung des Parsers durch eine Methode dargestellt wird,
ist es durchaus möglich für Nichtterminale Übergabeparameter und Rückgabewerte zu definieren,
weswegen die Nichtterminalen in der Grammatikdatei mit einem Java-Methodenkopf
inklusive Rückgabewert und Parameterliste definiert werden. Nach einem ":"folgt ein
Java-Block, der entweder leer ist oder Deklarationen und Anweisungen enthält, die bei
jeder Anwendung der Produktion ausgeführt werden sollen. Die Deklarationen gelten für
alle Produktionen. Im Methodenrumpf ist die rechte Seite der BNF-Produktion definiert.
Nichtterminale, die hier auftreten, werden wie Methodenaufrufe notiert, Terminale sind
entweder einzelne Zeichen oder Tokens. An jeder beliebigen Position der Produktion kann
ein weiterer Java-Block definiert werden, der ausgeführt wird, sobald er passiert wird.
bnf_production ::=
java_access_modifier java_return_type java_identifier "(" java_parameter_list ")" ":"
java_block
"{" expansion_choices "}"
expansion_choices ::= expansion ( "|" expansion )∗
expansion ::= ( expansion_unit )∗
expansion_unit ::= local_lookahead
| java_block
| "(" expansion_choices ")" [ "+" | "∗" | "" ]
| "[" expansion_choices "]"
| [ java_assignment_lhs "=" ] regular_expression
| [ java_assignment_lhs "=" ] java_identifier "(" java_expression_list ")"
Es gibt noch eine zweite Möglichkeit Produktionen für den Parser anzugeben. Die Produktion
wird dabei komplett in Javacode notiert und durch das Schlüsselwort JAVACODE
eingeleitet. Da diese Variante aber für Grammatiken gedacht ist, die mit der kontextfreien
Darstellung der BNF nicht auskommen, wird sie für diese Arbeit nicht benötigt.
11

Kapitel 3
Anforderungen im Detail
3.1 Mindestanforderungen
Die Benutzerschnittstelle
Die graphische Benutzerschnittstelle soll dem Nutzer eine bequeme Eingabe der Anfragen
ermöglichen und muss in der Lage sein, Fehlermeldungen und die Ergebnistabellen anzuzeigen.
Dazu soll sie jeweils ein eigenes Teilfenster bereitstellen, wobei die Fenster für
die Ergebnistabellen und die Eingabe natürlich entsprechend groß sein müssen. Ist der
dargestellte Inhalt zu groß für den Anzeigebereich, so soll der Überlauf über Scrollbalken
erreichbar sein. Außerdem soll die Copy&Paste-Funktion unterstützt werden.
Die Sprache
Die zu entwerfende Anfragesprache soll sich an der Relationenalgebra orientieren, wie
sie in der Vorlesung „Grundlagen der DBS“ im Sommersemester 08 eingeführt wurde.
Dabei können griechische Symbole durch Schlüsselwörter ersetzt werden und die Eingabe
linear, also ohne Tiefstellung von Parametern, erfolgen. Die Sprache sollte natürlich
unter der Voraussetzung, dass man die Relationenalgebra kennt, möglichst intuitiv sein.
Zu implementieren sind zunächst alle Grundoperationen, der Gamma-Operator, sowie
alle abgeleiteten Operationen mit Ausnahme des Outerjoins und der Division. Die relationenalgebraische
Definition der Attributterme, lässt einen sehr komplexen Aufbau zu,
weswegen diese zunächst nur eingeschränkt implementiert werden sollen. Es soll mit Zeichenketten
und Zahlen umgegangen werden können. Die Syntax der Anfragesprache ist
über eine kontextfreie Grammatik zu definieren.
Das Ausführungssystem
Eine eingegebene Anfrage soll korrekt analysiert und in SQL übersetzt werden. Bei Fehlern
in der Anfrage sind aussagekräftige Fehlermeldungen auszugeben, die dem Nutzer
eine schnelle Korrektur ermöglichen. Die Übersetzung sollte mindestens nach dem Prinzip
geschachtelter From-Klauseln erfolgen, wobei für jeden Operanden einer Operation
eine Unteranfrage in der From-Klausel des jeweiligen SQL-Blocks ausgeführt wird. Da
dieses Vorgehen zu einer stark verschachtelten SQL-Anfrage führt, die nicht nur schwer
lesbar, sondern auch für das DBMS schwer optimierbar ist, ist ein besserer Übersetzungsalgorithmus
natürlich wünschenswerter. Es soll zunächst ausreichen, wenn der erzeugte
12

SQL-Code nur auf kleine Datenbanken angewendet werden kann. Neben der Analyse und
der Übersetzung ist noch die Zusammenarbeit mit dem Datenbanksystem zu regeln. Es
muss möglich sein, eine Verbindung per Login aufzubauen, die Anfrage auszuführen und
das Ergebnis entgegen zu nehmen. Außerdem muss es möglich sein, Fehlermeldungen von
Oracle entgegen zu nehmen und dem Nutzer als Laufzeitfehler anzuzeigen.
3.2 Verbesserungsmöglichkeiten
Der Umgang mit großen Datenmengen muss ermöglicht werden. Außerdem klammert die
in den Mindestanforderungen festgelegte Funktionalität klammert noch einige Möglichkeiten
der Relationenalgebra aus. Die Operationen Division und Outerjoin (damit auch
der Left- und Right-Outerjoin) müssen noch integriert werden. Der Umgang mit dem
Datentyp Date fehlt und die Attributterme sind bisher nur eingeschränkt implementiert.
Außerdem muss der Umgang mit großen Datenmengen ermöglicht werden. Diese Erweiterungen
sollten natürlich die höchste Priorität erhalten.
In SQL gibt es durch die Order-By-Klausel die Möglichkeit Ergebnistabellen nach beliebigen
Spalten sortieren zu lassen, was sich auch auf die zu entwickelnde Relationenalgebra-
Anfragesprache übertragen lässt. Hierbei wäre es denkbar am Ende einer Anfrage die
textuelle Eingabe einer Order-by-Anweisung zuzulassen oder stattdessen eine Order-by-
Option auf der Benutzeroberfläche zur Verfügung zu stellen, bei der die jeweiligen Spalten
eingetragen oder eventuell sogar ausgewählt werden könnten.
Durch einen frühzeitigen Verbindungsaufbau zum DBS, wäre es auch möglich den Nutzer
allgemein bei der Eingabe von Relationen- und Spaltennamen zu unterstützen.
Zur besseren Bedienbarkeit und Lesbarkeit kann eine Syntaxunterstützung eingebaut
werden. Es wäre in einigen Situationen auch Vorteilhaft, wenn die Möglichkeit besteht,
den erzeugten SQL-Code auf der Benutzerschnittstelle auszugeben.
Desweiteren bietet es sich an, dem Nutzer die Möglichkeit der Übungsabgabe und eine
Benutzungshistorie zur Verfügung zu stellen. Auch die Bereitstellung einer englischen
Version der Benutzeroberfläche wäre denkbar.
Die Relationenalgebra sieht allgemein nur lesende Zugriffe auf Datenbanken vor, daher
würde es zu weit gehen über eine Integrierung von Create/Update-Kommandos nachzudenken.
Um Datenbank-Relationen zu erzeugen oder zu ändern ware also eine SQL-
Schnittstelle nötig. Die Benutzerfreundlichkeit könnte hier allerdings dadurch erhöht werden,
dass ein SQL-Modus angeboten wird, in dem der Nutzer statt Relationenalgebra-Anfragen,
SQL-Anweisungen eingeben kann. Dies würde die Nutzung einer zweiten Schnittstelle
für schreibende Zugriffe auf die Datenbank unnötig machen.
13

Kapitel 4
Entwurf
4.1 Syntax der Anfragesprache
Die Syntax der Anfragesprache soll möglichst intuitiv sein, das heißt sich möglichst gut
an die Syntax der Relationenalgebra anlehnen. Da die Eingabe von den für die Relationenalgebra
typischen Symbolen und Indizes am Computer allerdings schwierig ist, soll die
Syntax hier etwas abgeändert werden.
Die relationenalgebraischen Symbole werden durch Bezeichner ersetzt, welche natürlich
der Bequemlichkeit wegen nicht zu lang sein sollten und trotzdem eindeutig und intuitiv
auf das zugeordnete Symbol schließen lassen müssen. Die definierten Bezeichner sind der
Tabelle 4.1 zu entnehmen. Der einheitlichen Darstellung wegen sind in der Tabelle alle
Schlüsselworte in Großbuchstaben dargestellt, die zu entwickelnde Sprache soll aber bezüglich
der Schlüsselworte nicht case-sensitiv sein. Die Eingaben „SEL“, „sel“ oder „Sel“
werden gleich behandelt.
Die Bedingungen und Attributlisten, die gewöhnlich im Index eines Symbols auftauchen,
werden den Symbolen nun in eckigen Klammern nachgestellt. An der syntaktischen Struktur
der Anfragen soll gegenüber der Relationenalgebra nichts verändert werden, jedoch
gibt es vorerst ein paar Einschränkungen bzgl. der Sprachmächtigkeit:
1. Es wird auf den Datentyp Date und auf die Operation Division verzichtet.
2. Es wird auf die logischen Operatoren „=>“ und „ verzichtet.
3. Ein mehr als zweistelliger Vergleich in einer Bedingung ist nur durch eine Und-
Verknüpfung von zweistelligen Vergleichsoperationen möglich. Ausdruck (a) ist damit
unzulässig, Ausdruck (b) zulässig.
(a) SEL[A

Operation Symbol Sprachelement Beispiel
Selektion σ SEL SEL[A>10](R)
Projektion π PROJ PROJ[A Aneu, C](R)
Vereinigung ∪ UNION R UNION S
Durchschnitt ∩ INTERSECT R INTERSECT S
Differenz - MINUS R MINUS S
Kartesisches Produkt × CARTESIAN R CARTESIAN S
Join ⊲⊳ JOIN R JOIN[A=B] S
Natural Join ⊲⊳ NJOIN R NJOIN S
Semijoin ⊲< SJOIN R SJOIN[A=B] S
Anti-Semijoin ⊲< ASJOIN R ASJOIN[A=B] S
Gruppierung Γ GROUP GROUP[A # A, avg(B)](R)
Logisches Und ∧ AND SEL[A>2 AND B>2](R)
Logisches Oder ∨ OR SEL[A>2 OR B>2](R)
Logisches Nicht ! NOT SEL[NOT A=B] S
Leere Menge ∅ {} GROUP[{} # count(*)](R)
Tabelle 4.1: Sprachelemente
Was an dieser Stelle noch anzumerken ist, ist die Klammerung. Die unären Operationen
Selektion, Projektion und Gruppierung klammern ihre Operanden generell. Die ist auch
aus der Relationenalgebra bekannt. Intuitiv klammert man einen Operanden einer binären
Operation, wenn es sich bei dem Operanden wieder um eine binäre Operation handelt,
um die Ausführungsreihenfolge eindeutig festzulegen. Für die zu entwickelnde Sprache soll
eine Klammerung von Operanden grundsätzlich immer möglich sein. Tritt eine zweistellige
Operation als Operand auf, so wird eine Klammerung vorausgesetzt. Ein Ausdruck der
Form ’1.’ wäre damit unzulässig und müsste geklammert werden. Die Ausdrücke 2. und
3. wären zulässig. Auch eine Klammerung der gesamten Anfrage ist möglich.
1. R ASJOIN[A=B] S UNION T
2. (R ASJOIN[A=B] S) UNION T
3. R ASJOIN[A=B] (S UNION T)
Die zu implementierenden Operatoren und Operationen können der folgenden Tabelle
entnommen werden. Syntax- und Prioritätsregeln entsprechen dabei den bekannten
Regeln aus SQL.
Gruppe
Operatoren/Operationen
logische Operatoren AND, OR, NOT
Vergleichsoperatoren =, , , >=, =

4.2 Analyse der Eingabe
4.2.1 Lexikale Analyse
Für den Scanner sind in erster Linie die regulären Ausdrücke für die Token zu definieren.
Das zeichenweise Lesen der Eingabe, die Zuordnung zu den Token und die Erstellung
der Tokenfolge, erledigt der generierte Scanner ohne weiteres Zutun. Für jedes Token
t wird dabei automatisch die Tokenklasse, die zugehörige Zeichenkette in der Eingabe,
sowie deren Position in den Variablen t.kind, t.image, t.beginLine und t.beginColumn
abgespeichert.
Definition der Tokenklassen
Es müssen zunächst alle Schlüsselwörter der Sprache in regulären Ausdrücken untergebracht
werden. Da meistens einer Operation bzw. einem Operator genau ein Schlüsselwort
zugeordnet ist, wird für den Namen der Tokenklasse einfach das zugehörige Schlüsselwort
gewählt, der jeweilige reguläre Ausdruck entspricht dem Schlüsselwort als Zeichenkette.
Der reguläre Ausdruck für die Tokenklasse CONCAT wäre zum Beispiel einfach „concat“.
Auf Groß- und Kleinschreibung muss hierbei nicht geachtet werden, da diese durch die
JavaCC-Option „IGNORE_CASE“ ignoriert wird. Auf diese Weise werden definiert:
1. Je eine Tokenklasse für jeden boolschen Operator, also and, or und not.
2. Je eine Tokenklasse für die Vergleichsoperatoren between, like und in, sowie je eine
Tokenklasse für die Schlüsselwörter is und null.
3. Je eine Tokenklasse für die Schlüsselwörter aller String-Operationen, also concat,
substr, length, instr, lpad, rpad, replace, trim, upper, lower, und initcap.
4. Ebenso für die Schlüsselwörter der numerischen und Datentyp-unabhängigen Operationen,
also für round, trunc, mod, nvl, nvl2, nullif und coalesce. .
Sowie je eine Tokenklasse für die Aggregatfunktionen count, sum, min, max, avg.
Da für die relationenalgebraischen Operationen zum Teil mehrere Schlüsselwörter zugelassen
sind, sind die zugehörigen regulären Ausdrücke nicht mehr ganz trivial. Sie sind
der Tabelle 4.3 zu entnehmen.
Die bisher nicht aufgeführten Vergleichsoperatoren verhalten sich syntaktisch völlig gleich.
Da als Operand eines Vergleichsoperators auch kein Vergleich zugelassen ist, unterscheiden
sie sich auch nicht bezüglich ihrer Priorität und können daher in einer Tokenklasse
zusammengefasst werden.
COMP: „=“ | „“ | „>=“ | „

Tokenklasse Regulärer Ausdruck
PROJ „proj“ | „pj“
SEL
„sel“
GROUP „goup“ | „gp“
JOIN „join“
NJOIN „natural join“ | „njoin“ | „nj“
SJOIN „semijoin“ | „sjoin“ | „sj“
ASJOIN „antisemijoin“ | „asjoin“ | „asj“
OJOIN „outer join“ | „ojoin“ | „oj“
ROJOIN „right outer join“ | „rojoin“ | „roj“
LOJOIN „left outer join“ | „lojoin“ | „loj“
CARTESIAN „cartesian“ | „cross join“
UNION „union “
INTERSECT „intersect“
MINUS „minus“
Tabelle 4.3: Tokenklassen-Definitionen für Relationenalgebraische Operationen
Tokenklasse Regulärer Ausdruck
APLUS „+“
AMINUS „-“
ADIV „/“
AMUL „*“
Tabelle 4.4: Tokenklassen-Definitionen für arithmetische Operatoren
INFCONCAT: “||“
PT: “.“
EMPTYSET: “{}“
Für Klammern und Kommas werden explizit keine Tokenklassen erzeugt. Sie sind wichtig
für die syntaktische Analyse der Anfrage. Da nach dem Parsing die syntaktische Struktur
der Anfrage im Syntaxbaum gespeichert ist, ist eine Speicherung dieser Zeichen über das
Parsing hinaus nicht notwendig. JavaCC erzeugt für jedes in der Grammatik auftretende
Zeichen automatisch eine anonyme Tokenklasse, die an dieser Stelle völlig ausreicht.
Es bleiben noch die Tokenklassen für Bezeichner und Literale zu definieren. Es ist wichtig,
dass sich die Definition der Bezeichner-Klasse unterhalb den Schlüsselwort-Definitionen
befindet, damit ein auftretendes Schlüsselwort auch als solches erkannt wird. Da es sich
bei Bezeichnern in relationenalgebraischen Anfragen um Namen von Tabellen- und Spalten
einer Oracle-Datenbank handelt, sind hier die Oracle-spezifischen Namenskonventionen
einzuhalten. Namen von Tabellen und Spalten im Oracle-System beginnen mit einen
Buchstaben, sind maximal 30 Zeichen lang und können neben großen und kleinen Buchstaben
die Zeichen „$“, „_“ und „#“ beinhalten. Es ist in JavaCC zwar möglich die
maximale Länge eines Ausdrucks festzulegen, dies würde bei Eingabe eines zu langen Bezeichners
aber dazu führen, dass der Scanner die ersten 30 Zeichen als Bezeichner-Token
erkennt und für die restlichen Zeichen ein neues Token erzeugt. Es ist leicht nachvollziehbar,
dass dies beim Parsing zu verwirrenden Fehlermeldungen führen würde. Die Länge
der Bezeichnern soll deshalb erst vom Parser überprüft werden, welcher dadurch in der
17

Lage ist eine aussagekräftige Fehlermeldung auszugeben.
IDENTIFIER: ([A-Z,a-z])([A-Z,a-z] | „$“ | „_“ |„#“)*
Auftretende Literale teilen sich grob in Zeichenketten und Zahlen. Beide Gruppen müssen
aber noch genauer differenziert werden. Einige Operationen wie zum Beispiel „substr“ erwarten
ganzzahlige Operanden, während es an vielen anderen Stellen durchaus möglich ist
beliebige Zahlen zu verwenden. Der Parser muss also die Möglichkeit haben beiden Klassen
zu unterscheiden, weshalb der Scanner hier unterschiedliche Tokenklassen bereitstellen
muss.
INTEGER_LITERAL: [1-9][0-9]*
NUM_LITERAL: [0-9]+ “.“ [0-9]+
Gleiches gilt für Zeichenketten. Ein Character-Literal könnte als Zeichenkette betrachtet
werden. Da aber zum Beispiel die Operationen rpad und lpad für einen Operand ein einzelnes
Zeichen und keine Zeichenkette erwarten, müssen String- und Character-Literale
definiert werden. Es wird zunächst ein Hilfsausdruck CHAR definiert, der ein beliebiges
Zeichen annehmen kann. Ein Character-Literal ist dann ein einzelnes CHAR-Zeichen in
Hochkommata, ein String ist eine Aneinanderreihung von CHAR-Zeichen in Hochkommata.
Anmerkung zur Symboltabelle
Der lexikale Scanner speichert zu Beginn implizit die Position eines Tokens in der Eingabemaske,
das Abbild des Tokens als Zeichenkette und die Tokenklasse, in der Token-
Datenstruktur. Jedoch arbeitet nur noch der Parser direkt mit den Tokens weiter, so dass
diese Informationen zusätzlich an einer anderen Stelle gespeichert werden müssen. Auch
während der syntaktischen und semantischen Analyse werden weitere Informationen gewonnen,
die in irgendeiner Form abgespeichert werden müssen. Hierzu eignet sich zum Teil
der vom Parser erzeugte Syntaxbaum und zum Teil eine globale Symboltabelle. Welche
Informationen abzuspeichern sind, und ob sich zur Speicherung die Symboltabelle oder
ein Knoten-Objekt des Syntaxbaumes besser eignet, soll an den jeweils geeigneten Stellen
diskutiert werden. Der Aufbau der Symboltabelle wird daher erst nach dem Entwurf der
Analyse-Stufen vorgestellt.
18

4.2.2 Syntaktische Analyse
Für den Parser muss eine LL(1)-Grammatik entworfen werden. Um das eigentliche Parsing
kümmert sich hier wieder der JavaCC-Generator. Die Produktionen sollen hier in Anlehnung
an Javacc in erweiterter Backus-Naur-Form angegeben werden. Token werden dabei
durch die Symbole „“ markiert. Für Klammern wurden keine Token definiert,
weswegen sie einfach als Symbole in den Produktionen vorkommen. Ein nichtterminales
Symbol entspricht in JavaCC einem Methodenaufruf und ist daher durch eine zunächst
leere Parameterliste gekennzeichnet.
Entwurf der Grammatik
Ein Ausdruck der Relationenalgebra besteht aus Verschachtelungen von unären und binären
Ausdrücken. Eine Produktion der Form
RAExpression(): UnaryRAExpression() | BinaryRAExpression()
würde die LL(1)-Bedingung verletzen, da ein Binärer Ausdruck wieder mit einem Unären
Ausdruck beginnt. Umformuliert kann man sagen, ein Ausdruck der Relationenalgebra
besteht aus einem unären Ausdruck, optional gefolgt von einer binären Operation und
einem zweiten unären Ausdruck.
RAExpression(): UnaryRAExpression() [ BinaryRAOperation() UnaryRAExpression()]
Es ist hier möglich die Binären Operationen unter einem Nichtterminal zusammenzufassen,
da festgelegt wurde, dass alle binären relationenalgebraischen Operationen die gleiche
Priorität besitzen und untereinander geklammert werden müssen. Für die binären Operationen
ergibt sich damit folgende Produktion.
BinaryRAOperation(): |
|
„[„ JoinCondition() „]“ |
„[„ JoinCondition() „]“ |
„[„ JoinCondition() „]“ |
„[„ JoinCondition() „]“ |
„[„ JoinCondition() „]“ |
„[„ JoinCondition() „]“ |
|
|
|
Ein unärer Ausdruck besteht hingegeben aus einem Tabellennamen, einem geklammerten
Ausdruck mit einer optionalen Umbenennung oder einer unären Operation, also einer
Projektion, einer Selektion oder einer Gruppierung.
19

UnaryRAExpession(): RelationIdent() |
„(„ RAExpression() [ Alias() ] „)“ |
„[„ AttList() „]“ „(„ RAExpression() „)“ |
„[„ Condition() „]“ „(„ RAExpression() „)“ |
„[„ GroupList() „“ AggrList() „]“ „(„ RAExpression() „)“
Für Selektionsbedingung muss ein anderes Nichtterminal verwendet werden als für die
Joinbedingungen, da hier nicht nur Und-Verknüpfungen, sondern beliebige boolsche Verknüpfungen
von Vergleichen erlaubt sind.
Für die Relationen- und Aliasnamen ergeben sich folgende Produktionen.
RelationIdent():
Alias():
Mit den bisher gegebenen Produktionen lassen sich auf relationenalgebraischer Ebene
bereits beliebige Ausdrücke rekursiv erstellen, es fehlen aber noch die Produktionen für
die Bedingungen und Attribut-Listen.
Eine Selektionsbedingung besteht aus logischen Verknüpfungen von Vergleichs-Ausdrücken.
Da die logischen Operatoren unterschiedliche Prioritäten besitzen, müssen hier mehrere
Produktionen erstellt werden. Stellt man sich einen Ableitungsbaum vor, so müssen sich
ganz allgemein Operatoren mit einer niedrigen Priorität möglichst weit entfernt von den
terminalen Operanden-Symbolen, also möglichst weit oben im Baum befinden. Bezogen
auf die Grammatik bedeutet dies, dass für jede Prioritätsstufe eine Produktion vorhanden
sein muss. Die Produktion werden hierarchisch durchlaufen. In der ersten Produktion
können optional Symbole mit niedrieger Priorität erkannt werden oder direkt in die
nächste Produktion gewechselt werden. Bei den logischen Operatoren besitzt die Oder-
Verknüpfung die niedrigste Priorität, eine Und-Verknüpfung eine höhere und der Not-
Operator die höchste. Zusäzlich muss die Änderung der Prioritäten durch Klammerung
mit einbezogen werden. Es ergeben sich folgende Produktionen.
Conditon(): AndExpression() ( AndExpression())∗
AndExpression(): NotExpression() (AND NotExpression)∗
NotExpression(): [] ( Comparison() | "‘("‘ Condition() "‘)"’␣)
Da keine Schachtelung von Vergleichen möglich ist, müssen hier keine Prioritäts-Regeln
beachtet werden. Es muss daher nur eine Produktion vorhanden sein.
Comparison(): AttributeTerm() ( AttriuteTerm() |
[] |
|
Literal() Literal() )
Ein Literal kann hierbei ein beliebiges Literal sein.
20

Literal(): StrLiteral() | CharLiteral() | NumLiteral() | IntLiteral()
StrLiteral():
CharLiteral():
NumLiteral():
IntLiteral():
Für die Attributterme müssen wieder die Prioritäten beachtet werden, weswegen zunächst
eine Produktion für die Addition und die Subtraktion benötigt wird und eine zusätzliche
für Multiplikation und Division.
AttributeTerm(): Term() ( ( | ) Term())*
Term(): Factor() (AND Factor())*
Ein Factor ist entweder ein Attribut, ein geklammerter Ausdruck oder eine Datentyp-
Operation.
Factor():
Attribute() |
“(“ AttributeTerm() “)“ |
( | | ) “(„ StrOperand “)“ |
“(“ StrOperand() “,“ StrOperand() “)“ |
“(“StrOperand() “,“ IntLiteral() “,“ IntLiteral() “)“ |
“(“ StrOpeand() “)“|
“(“ StrOperand() “,“ StrOperand() “)“|
“(“ StrOperand() “,“ StrOperand() “,“ StrOperand() “)“|
( | ) „(„ StrOperand() “,“ IntLiteral() “,“ CharLiteral() “)“|
....|
( | | ) “(“ NumberOperand() “,“ IntLiteral() “)“
( | | | ) “(„ AtomicElement() “,“ AtomicElement() “)“
Bei einem Datentyp-Operand kann es sich jeweils um ein Literal des jeweiligen Typs oder
um ein Attribut handeln.
StrOperand(): StrLiteral() | Attribute()
NumberOperand(): NumLiteral() | IntLiteral() | Attribute()
Ein Attribut ist ein Bezeichner, dem optional ein anderer Bezeichner als Relationennamen-
Prefix, gefolgt von einem Punkt, vorangestellt wird. Dies ist unter Einhaltung der LL(1)-
Bedingung nicht so einfach darstellbar, da der optionale, so wie auch der nicht optionale
Teil mit einem Bezeichner-Token beginnen und sich der optionale Teil am Anfang der
Produktion befindet. Der Parser könnte mit nur einem Lookahead-Symbol also nicht wissen,
ob es sich bei dem aktuellen Bezeichner um den Attributnamen oder um einen Präfix
handelt. Abhilfe schafft folgende Produktion.
Attribute(): [ ]
21

Für einen Attribut-Zugriff, der nur über den Attributnamen erfolgt, symbolisiert der
erste Bezeichner den Attributnamen. Für einen Attribut-Zugriff mit Punkt-Notation symbolisiert
der zweite Bezeichner den Attributnamen. Beide Zugriffsmöglichkeiten werden
korrekt geparst.
Auf der Basis der bisherigen Produktionen können nun beliebige Selektionsbedingungen
erkannt werden. Außerdem lässt sich sehr einfach die Produktion für eine Joinbedingung
formulieren. Joinbedingungen sind optional Und-verknüpfte Vergleiche, die Vergleichs-
Produktionen wurden bereits definiert.
JoinContition(): Comparison() ( Comparison() )*
Eine Attributterm-Liste einer Projektion besteht aus mit Komma getrennten Attribut-
Termen und jeweils einem opionalem Aliasnamen. Produktionen für Attributterme wurden
bereits definiert.
AttList(): AttributeTerm() [ Alias() ] [“,“ AttList()]
Eine Gruppierungsliste enthält durch Kommas getrennte Attributterme oder das Token
für die leere Menge.
GroupList(): ( AttributeTerm() (“,“ AttributeTerm()())* ) |
Bleibt zuletzt die Aggregierungsterm-Liste von Gruppierungen. Diese enthält aggregierte
und unaggregierte Attributterme, jeweils optional gefolgt von einem Alias. Die Aggregierungsfunktion
count kann neben einem Attributterm auch ein “*“ als Operand besitzen.
AggrList(): (AttributeTerm() | AggrTerm()) [Alias()] [“,“ AggrList()]
AggrTerm(): ( | | | ) “(“ AttributeTerm() „)“ | |
„(„ (AttributeTerm() | ) „)“
Die Produktionen der Grammatik können in der JavaCC-Grammatikdatei mit Parser-
Aktionen in Form von Java-Code angereichert werden. Auf diese Weise lassen sich neu
gewonnene Informationen über Tokens direkt in die Symboltabelle eintragen und der
Syntaxbaum aufbauen.
Aufbau des Syntaxbaumes
Die naheliegenste Variante wäre es, einen Ableitungsbaum für die eingegebene Anfrage zu
erzeugen, dieses wäre auch automatisch aus Javacc heraus möglich. Nichtterminale Symbole
in einer Grammatik dienen der Beschreibung der Struktur von Worten der Grammatik.
Aber auch ein Syntaxbaum ist eine Datenstruktur zur Speicherung von syntaktischen
Strukturen. Sofern man also im Nachhinein nicht nachvollziehen muss welche Produktionen
der Grammatik in welcher Reihenfolge angewendet wurden, ist es nicht notwendig die
Nichtterminalen Symbole der Grammatik in den Syntaxbaum mit aufzunehmen. Es wäre
sogar nachteilig diese mit aufzunehmen, da zum Einen der entstehende Baum mit Nichtterminalen
Symbolen um ein Vielfaches größer wäre als nur mit terminalen Symbolen und
zum Anderen ein zusätzlicher Schritt notwendig wäre um aus dem Ableitungsbaum einen
Nichtterminal-freien Baum als Basis für die Optimierung und SQL-Code-Erzeugung zu
erzeugen.
22

Aus der Grammatik lässt sich direkt ein Operatorbaum ableiten, also ein Baum, der
die hierarchische Struktur der Operationen in der Anfrage repräsentiert. Im Gegensatz
zum aus der Relationenalgebra bekannten Operatorbaum, müssen hier natürlich auch die
Bedingungen und Attributlisten in einer Baumstruktur abgespeichert werden.
Um Ausdrücke der Relationenalgebra repräsentieren zu können sind verschiedene Knoten-
Typen notwendig.
1. Knoten, die nur Operanden-Kindknoten besitzen. Dazu gehören Knoten für die Vereinigung,
den Durchschnitt, die Differenz, die Division, das Kartesische Produkt, den
Natürlichen Verbund, sowie alle in Bedingungen auftretende arithmetische Operatoren,
Operatoren für Zeichenketten, boolsche Operatoren und Vergleichsoperatoren.
2. Knoten, die zusätzlich zu ihren Operanden-Kindknoten Kindknoten für eine Bedingung
enthalten. Hierzu zählen der Join, der Semijoin, der Antisemijoin, der Outerjoin
und die Selektion.
3. Knoten, die Attributterm-Listen abspeichern können müssen. Hierbei muss noch
genauer differenziert werden, da für eine Gruppierung im Gegensatz zur Projektion
zwei Listen abgespeichert werden können müssen.
Beim Parsing kann einfach auf Basis des aktuell gelesen Tokens die Art des zu erzeugenden
Knotens bestimmt werden. Für jedes Token, dass im Operatorbaum gespeichert werden
soll, muss ein Knoten erzeugt und dem Baum hinzugefügt werden. Die Hierarchie der
Knoten wird durch die Reihenfolge der angewendeten Produktionen bestimmt. Es wird
ein Zeiger definiert, der immer auf das Knoten-Objekt zeigt, an dem der nächste Knoten
angefügt werden muss. Wird dem Operatorbaum ein Knoten-Objekt hinzugefügt, so wird
der Zeiger darauf gesetzt. Je nach Knotenart wird nun ggf. erst auf den Bedingungs-,
Attributterm-Listen oder Gruppierungs-Listen-Nachfolger gewartet, auf den dann wiederum
der Zeiger gesetzt wird. Dieses Vorgehen entspricht strukturell der Abarbeitung
der Produktionen in der Grammatik. Trifft der Parser auf ein nichtterminales Symbol,
wird vor der weiteren Abarbeitung der aktuellen Produktion, zunächst das nichttermiale
Symbol mit Hilfe einer passenden Produktion verarbeitet. Ist der Parser am Ende einer
Produktion angelangt, die einen vollständigen Ausdruck beschreibt, so ist im Operatorbaum
der zugehörige Teilbaum fertig aufgebaut und der aktuell zu bearbeitende Knoten
muss eine Ebene hoch navigiert werden. Parallel navigiert auch der Parser in der Hierarchie
der angewendeten Produktionen eine Ebene hoch und setzt dort die Abarbeitung
einer Produktion fort.
Bei diesem Vorgehen kommt noch eine Schwierigkeit dazu, da viele Teilausdrücke Infix-
Operatoren enthalten. Der Parser liest die Tokenfolge von links nach rechts und für jedes
Token, dass in den Baum aufgenommen werden soll, wird sofort ein Knoten erzeugt und
dem Baum hinzugefügt. Es ist daher logisch, dass ein Teilbaum für einen beliebigen Ausdruck,
der linker Operand eines Infix-Operators ist, noch nicht an der richtigen Stelle
hängen kann. Stattdessen befindet er sich an der Position an der normalerweise der Infix-
Operator-Knoten hängen müsste. Wenn der Parser das Token für den Infix-Operator liest,
befindet sich, durch die Produktions-bedingte Navigation im Operatorbaum, der Zeiger
an der richtigen Stelle, also auf dem späteren Vaterknoten des Infix-Operator-Knotens, an
dem im Moment noch der Teilbaum hängt, der den linken Operanden des Infix-Operators
repräsentiert. Der Infix-Operator-Knoten muss nun also zwischen dem aktuellen Knoten
23

und dem zuletzt eingefügten Kind-Teilbaum eingefügt werden. Der Zeiger wandert wieder
auf den zuletzt eingefügten Knoten, das heißt auf den Infix-Operator-Knoten. Um
für den Wurzelknoten keine Sonderbehandlung einfügen zu müssen wird zu Beginn des
Parsings ein leerer root-Knoten erzeugt, der nur einen Nachfolger, nämlich den eigentlichen
Wurzelknoten des Baumes, haben soll. Zusammenfassend ist der Aufbau-Prozesses
des Operatorbaumes als Flussdiagramm in Abbildung 4.1 dargestellt. Zusätzlich soll die
Funktionsweise durch folgendes Beispiel verdeutlicht werden. Die eingegebene Anfrage sei
Abbildung 4.1: Aufbau des Operatorbaumes
SEL [A+1

werden. Es existieren die folgenden Produktionen, die in Anlehnung an JavaCC in BNF
angegeben sind. Die Tokenklassen sind durch „“ markiert.
1. Start(): Expr()
2. Expr(): UnaryExpr() [ Expr() #]
3. UnaryExpr(): ( „[„ RelExpr() „]“ „(„ Expr() „)“ #) | ( #)
4. RelExpr(): Term() Term() #
5. Term(): AtomicElement() [„+“ Term() # ]
6. AtomicElement(): ( | ) #
Die #-Symbole markieren die Stellen, an den ein Ausdruck abgeschlossen ist und der
Zeiger im Operatorbaum eine Stufe hochgestellt werden muss. Sie stehen hier nur repräsentativ
für entsprechenden JavaCode zur Naviagation im Baum.
Vor Beginn des Parsings wird ein Root-Knoten erzeugt, sowie ein Zeiger, der auf Root
zeigt.
Das erste Token ist SEL. Der Parser wendet also nacheinander Produktion 1, 2 und 3 an
und verarbeitet nun das SEL-Token. Es wird ein Knoten-Objekt erzeugt, dass neben den
normalen Operanden auch einen Bedingungs-Teilbaum aufnehmen kann. Dieses wird an
die nächste frei Position im aktuellen Knoten, also im root-Knoten gehängt. Der Zeiger
wandert auf den gerade eingefügten Knoten.
Das nächste Token ist „[„. Klammern haben keinen Einfluss auf den Operatorbaum. Der
Parser liest das Token und bleibt in Produktion 3. Nun ist das Lookahead-Symbol ein
Bezeichner mit Wert „A“. Der Parser trifft in Produktion 3 auf ein nichtterminales Symbol
und kann Produktion 4, 5 und 6 anwenden um „A“ zu verarbeiten. Ist „A“ gelesen, so
wird wieder ein Knoten-Objekt erzeugt, dass an die nächste freie Position im aktuellen
Knoten-Objekt gespeichert wird. Das aktuelle Knoten-Objekt ist der Selektions-Knoten,
sein Bedingungsteilbaum muss zuerst aufgebaut werden. Der Zeiger wandert danach wieder
auf den eingefügten Knoten.
25

Das Lookahead ist nun „+“. Der Parser beendet Produktion 6 und liest dabei die, hier als
Raute gekennzeichnete Anweisung, den Zeiger eine Ebene hochzusetzen. Der Ausdruck
„A“ wurde komplett verarbeitet.
Das Lookahead ist immernoch „+“. Da der Parser Produktion 6 beendet hat kann er nun
die Bearbeitung von Produktion 5 fortsetzen. Für das „+“-Token wird ein Knoten-Objekt
erzeugt. Da „+“ ein Infix-Operator ist, wird das Knoten-Objekt nicht an die nächste freie
Position, sondern zwischen den aktuellen Knoten und den zuletzt eingefügten Teilbaum
gehängt. Der Zeiger wandert wieder mit.
Nun wird eine „1“ gelesen. Der Parser trifft auf das nichtterminale Symbol Term() und
wendet noch einmal Produktion 5 und 6 an, liest dann die „1“ und erzeugt ein Knoten-
Objekt, welches an die nächste freie Position des aktuellen Knotens gehängt wird.
26

Das Lookahead ist nun „

Der Parser trifft in Produktion 4 auf das nichtterminale Symbol Term(). Das Lookahead
ist „B“. Es werden nacheinander wieder die Produktionen 5 und 6 angewendet. Ein neuer
„B“-Knoten wird angefügt.
Die Produktion 6 kann wieder beendet werden, der Teilausdruck „B“ wurde komplett
verarbeitet, der Zeiger im Baum wird eine Ebene hoch gesetzt.
Da das Lookahead eine Klammer und kein „+“ kann auch Produktion 5 beendet werden.
Dieses Mal aber ohne Lesen einer Raute, für den erkannten Teilausdruck „B“ wurde der
Zeiger bereits versetzt. Nun kann die Verarbeitung von Produktion 4 fortgesetzt werden,
aber auch hier ist der Parser bereits am Ende angekommen. Beim Lesen der Raute wird
wieder der Zeiger eine Ebene hoch gesetzt, der Ausdruck „A+1

Die Bearbeitung von Produktion 3 wird fortgesetzt. Hierbei liest der Parser nacheinander
die beiden Token „]“ und „)“, die keinen Einfluss auf den Operatorbaum haben. Danach
trifft er auf das Expr()-Nichtterminal. Das Lookahead ist „R“. Es müssen also nach
einander die Produktionen 1, 2 und 3 angewendet werden, wobei für UnaryExpr() die
Produktion gewählt wird, deren rechte Seite mit einem Bezeichner beginnt. Für „R“ wird
wieder ein Knoten-Objekt erzeugt. Der Zeiger zeigt zur Zeit auf den Selektions-Knoten.
Da „R“ kein Infix-Operator ist, muss das neue Knoten Objekt an die nächste freie Position
im Selektions-Knoten gehängt werden, also als Operand.
Der Parser beendet Produktion 3 und setzt den Zeiger eine Ebene hoch. Der Teilausdruck
„R“ wurde komplett verarbeitet.
29

Das Lookahead ist „)“. Der Parser setzt die Verarbeitung von Produktion 2 durch Beendigung
fort, ohne dabei eine Raute zu lesen. Bei der Weiterverarbeitung von Produktion
3 kann er nun die Klammer lesen. Das neue Lookahead ist eine Vereinigung, also beendet
er Produktion 3 und setzt den Zeiger eine Ebene hoch. Der Ausdruck „SEL[A+1

Das Lookahead ist nun der Bezeichner „S“. Um S zu verarbeiten muss der Parser die
Produktionen 2 und 3 anwenden. Für „S“ wird ein Knoten-Objekt erzeugt und an die
nächste freie Position gehängt. Der Zeiger wandert wieder mit.
Die Produktion 3 wird mit hoch setzen des Zeigers beendet, da der Ausdruck „S“ komplett
verarbeitet wurde.
31

Auch Produktion 2 kann beendet werden. Der Ausdruck „SEL[A+1

Zeichenkette nicht von Bedeutung, da diese nur zur Identifikation der zugehörigen Tokenklasse
diente. Die Übersetzung muss auf Basis der Tokenklasse und der in SQL üblichen
Syntax für die jeweilige Operation erfolgen und ist daher unabhängig vom Abbild in der
Eingabe. Allgemein hängen sehr viele Entscheidungen, wie ein Element zu Prüfen oder
zu Übersetzen ist, von der jeweiligen Tokenklasse ab. Es macht also Sinn, neben der Position
auch die Tokenklasse in der Baumstruktur zu speichern und auf die Aufnahme der
Schlüsselwörter in der Symboltabelle ganz zu verzichten.
Anders ist es bei auftretenden Bezeichnern und Literalen. Das Abbild als Zeichenkette
hängt hier nicht von der Tokenklasse ab und muss zusätzlich gespeichert werden. Für
auftretende Bezeichner gibt es auch noch mehr Informationen, die abgespeichert werden
müssen. In der Anfrage
PROJ[A Aneu](R)
treten drei Bezeichner auf, die alle unterschiedliche Rollen spielen. Beim ersten Bezeichner
handelt es sich um ein Attribut bzw. einen Spaltennamen, beim zweiten um ein Alias
und beim dritten um eine Relation bzw. einen Tabellennamen. Die Symboltabelle sollte
daher in der Lage sein diese „Bezeichner-Typen“ abzuspeichern. Die unterschiedlchen
Bezeichner-Typen werden während des Parsings erkannt und können direkt in die Symboltabelle
eingetragen werden. Hierzu müssen lediglich die Produktionen
RelationIdent():
Alias():
Attribute(): [ ]
mit passenden Symboltabellen-Methoden-Aufrufen angereichert werden. Für die dritte
Produktion ist dies etwas schwieriger, da es sich beim ersten Bezeichner-Token sowohl um
ein Attribut als auch um eine Relation handeln kann. Für den ersten Bezeichner muss
der Bezeichner-Typ „Relation“ eingetragen werden falls das Lookahead ein Punkt ist,
ansonsten handelt es sich um ein Attribut. Falls der zweite Bezeichner auftritt, handelt
es sich dabei auf jeden Fall um ein Attribut, hier ist also keine Abfrage nötig. Man sieht
an dieser Stelle warum es wichtig war den Punkt explizit als Tokenklasse zu definieren,
ein Vergleich mit einer anonymen Tokenklasse wäre nicht möglich gewesen.
Da während des Parsing alle nötigen Informationen über die Tokens in der Token-
Datenstruktur gespeichert sind, ist es nicht notwendig, dass vor Beginn des Parsings schon
Einträge in der Symboltabelle vorhanden sind. Der Parser kann also die erste Eintragung
eines Bezeichners in die Symboltabelle vornehmen und gleichzeitig den Bezeichner-Typ
angeben. Natürlich müsste der Parser dann auch die erste Eintragung der Literale vornehmen.
Hierzu sind die Literal-Produktionen mit entsprechendem Code anzureichern.
Der zugehörige Ausdruck eines Aliasnamens ist nur schwer in der Symboltabelle abspeicherbar.
Die Speicherung des Ausdrucks als Zeichenkette wäre zwar möglich, für die
weitere Verarbeitung aber wenig geeignet. Die Speicherung von Teilbäumen in der Symboltabelle
wäre ebenfalls möglich, würde aber zu vielen redundanten Informationen und
im schlechtesten Fall zu einer enormen Symboltabelle führen. Der Ausdruck sollte also
aus dem Syntaxbaum abgeleitet werden und wird nicht in der Symboltabelle gespeichert.
33

4.2.3 Semantische Analyse:
Bezüglich der Ausdrücke der Relationenalgebra hat die semantische Analyse folgende
Aufgaben zu bewältigen.
1. Konsistenz-Prüfung
In der Anfrage auftretende Attribut- und Relationennamen müssen sich in der Datenbank
widerspiegeln.
2. Prüfung von Gültigkeitsbereichen
Attribut-, Relationen- und Aliasnamen sowie Gruppierungen von Attributen besitzen
innerhalb der Anfrage einen gewissen Gültigkeitsbereich. Dieser muss untersucht
werden, um einen semantisch korrekten Zugriff zu garantieren.
3. Datentyp-Prüfung
(a) Attribut-Ebene
In Selektions- und Join-Bedingungen auftretende Operatoren, müssen mit Attributen
und Literalen passender Datentypen verwendet werden.
(b) Relationen-Ebene
Operationen auf Relationen-Ebene sind ebenfalls nicht mit beliebigen Operanden
möglich. Voraussetzungen, die an die Schemata der Operanden gestellt
werden, müssen daher ebenfalls geprüft werden.
Wie man leicht sieht wird hier eine Verbindung zum Datenbanksystem notwendig. Hierzu
werden die Login-Daten des Nutzers benötigt, die von der Steuerung der Benutzeroberfläche
abgefragt werden können. Zur Interaktion mit dem Datenbanksystem bietet die
Java-Umgebung das Package java.sql. Sobald die Verbindung steht, können die benötigten
Informationen, also Tabellennamen und Spaltennamen, mit den zugehörigen Datentypen,
aller benötigter Tabellen, über die Dictionary-View „all_tab_colums“ abgerufen werden.
Das Ergebnis ist ein ResultSet, aus dem die benötigten Informationen nun gewonnen werden
können. Es wird noch eine Datenstruktur benötigt um die jeweiligen Schemata der
Tabellen abzuspeichern.
Konsistenz-Prüfung
Die Relationennamen der Anfrage, die konsistent zur Datenbank verwendet werden müssen,
und deren Attribute mit zugehörigen Datentypen benötigt werden, können von der
Symboltabelle abgefragt werden. Die Existenz der verwendeten Relationennamen in der
Datenbank kann implizit beim Abfragen der benötigten Daten erfolgen. Ist ein Relationenname
nicht als Tabelle in der Datenbank vorhanden, so muss dies dem Nutzer durch
eine Fehlermeldung mitgeteilt werden.
Zugriffe auf Attribute finden an verschiedenen Stellen im Operatorbaum statt und können
daher nicht gleich beim Abfragen der Relationen-Daten vom Datenbank-System überprüft
werden. Stattdessen werden alle Attribute einer Relation mit Datentypen in einer
Schema-Datenstruktur für jede auftretende Relation in der Symboltabelle abgespeichert.
Da den Datentypen im Oracle-System Längenangaben mitgegeben sind, müssen diese
der Typinformation der Schema-Datenstruktur ebenfalls mitgegeben und später in der
Prüfung einbezogen werden.
34

Schema-Berechnung und Typ-Prüfung auf Relationenebene
Um zu Prüfen, ob auf Attribute semantisch korrekt zugegriffen wird, muss das Schema
der Operanden der jeweiligen Operation betrachtet werden. Handelt es sich bei einem
Operanden um einen einfachen Tabellennamen, also einen Blattknoten im Operatorbaum,
so ist das Schema bekannt. Handelt es sich bei dem Operanden aber um einen komplexeren
relationenalgebraischen Ausdruck bzw um einen inneren Knoten im Operatorbaum, so
muss das Schema des Ausdrucks berechnet werden. Für die Anfrage
PROJ [A](R NJOIN S)
mit Schema(R)=(R.A:D1, R.B:D2) und Schema(S)=(S.B:D2, S.C:D3) muss zunächst das
Schema des Ausdrucks „R njoin S“ berechnet werden, bevor überprüft werden kann, ob
A darin enthalten ist.
Es gibt in der Relationenalgebra per Definition für jede Operation eine Vorschrift wie das
Ergebnis-Schema aus den Schemata der jeweiligen Operanden berechnet werden kann. Im
Beispiel gilt
Schema(R NJOIN S) = (R.A:D1, B:D2, S.C:D3)
Um für einen beliebigen Knoten ein Schema zu berechnen, müssen die Schemata seiner
Operanden bekannt sein. Die Berechnung erfolgt dabei nach den, in der Definition
der einzelnen relationenalgebraischen Operationen, festgelegten Regeln. Da zu Beginn die
Schemata der in der Anfrage aufgetretenden Tabellen, also den Blattknoten im Operatorbaum,
bekannt sind, kann die Schema-Berechnung Bottom-up durchgeführt werden.
Zusätzlich müssen Umbennenungen von Ausdrücken mit in die Schema-Berechnung einfließen.
Die Umbenennung eines Ausdrucks führt zur Umbennenung aller Relationennamen-Prefixe,
der im jeweiligen Schema enthaltenden Attribute, ohne dass ein späterer
Zugriff auf die ursprünglichen Relationennamen möglich ist. Die Anfrage 1) führt zu
einem Fehler, korrekt wären hingegen Anfrage 2) oder 3)
1. PROJ[R.A]((R NJOIN S) T)
2. PROJ[T.A]((R NJOIN S) T)
3. PROJ[A]((R NJOIN S) T)
Schema((R NJOIN S) T)= (T.A:D1, T.B:D2, T.C:D3)
Per Definition müssen die meisten Operanden von relationenalgebraischen Operationen
gewisse Voraussetzungen bezüglich ihrer Schemata erfüllen, damit die Operation möglich
ist. Bevor also eine Schema-Berechnung an einem Knoten durchgeführt werden kann,
müssen die Vorausseztungen der Schemata der Operanden überprüft werden. Für jede
Vereinigung, jeden Durchschnitt und jede Differenz muss geprüft werden, ob die Schemata
der Kindknoten identisch sind. Nach der Prüfung ergibt sich das Ergebnis-Schema direkt
aus den Schemata der Kindknoten. Für jede Projektion, Selektion, Gruppierung und für
jede Art von Join muss zunächst geprüft werden, ob Attribute, die in der Bedingung
vorkommen, auch in den Schemata ihrer Kindknoten vorhanden sind. Danach kann das
Ergebnis-Schema entsprechend den in der Definition der Operation festgelegten Regeln
berechnet werden.
35

Prüfung von Gültigkeitsbereichen und Datentyp-Prüfung auf Attributebene
Der Zugriff auf Attribute erfolgt in der Bedingung, Attributtermliste oder Gruppierungsliste
einer Operation. Um zu Prüfen, ob auf Attribute semantisch korrekt zugegriffen
wird, muss das Schema der Operanden der jeweiligen Operation betrachtet werden. Hierzu
müssen die Schemata der Operanden zwischengespeichert werden. Die Prüfung der
Attributterme erfolgt Bottom-up. Für die Blattknoten, also die Attribute, kann mittels
den zwischengespeicherten Schemata einfach überprüft werden, ob die ungruppiert im
Schema Attribute existieren, außerdem können die Datentypen ausgelesen werden. Für
die inneren Knoten muss überprüft werden, ob die Operanden passende Datentypen besitzen
und der Ergebnis-Typ abgespeichert werden. Hierzu müssen die Typ-Ausdrücke aller
möglichen Operationen definiert sein.
Attribut- und Aggregierungstermlisten von Projektionen und Gruppierungen müssen
nicht nur überprüft werden, sondern können zusätzlich ein Schema verändern. Aliasnamen
oder Gruppierungen von Attributen müssen daher im zwischengespeicherten Operanden-
Schema gespeichert werden. Natürlich müssen diese dann herangezogen werden um das
Schema des jeweiligen Gruppierungs- oder Projektions-Knotens zu berechnen. Eine Umbenennung
eines Attributes führt zur Umbenennung des Attributes im jeweiligen Schema,
nach der Umbenennung kann nicht mehr auf den ursprünglichen Namen zugegriffen werden.
Die Anfrage
PROJ [A]( PROJ [A Aneu ](R NJOIN S))
führt zu einem Fehler, da zum Zeitpunkt des äußeren Zugriffs auf A kein Attribut namens
A mehr im Schema existiert.
Schema(PROJ[A Aneu](R NJOIN S))=(R.Aneu:D1, B:D2, S.C:D3)
Auch die Gruppierung von Attributen muss im Schema vermerkt werden, da ein späterer
Zugriff auf einzelne Elemente der Gruppe nicht mehr möglich sein darf.
Schema(GROUP[A,B#A,B,C](R NJOIN S))=(group(A:D1, B:D2), S.C:D3)
Für Gruppierungen ist zusätzlich zu Prüfen, ob in der Aggregierungsterm-Liste auftretende
nicht-aggregierte Attribute den gruppierten Attributen entsprechen. Die Gruppierungsliste
muss daher zuerst durchlaufen werden.
Gesamtablauf
Zu Beginn der Prüfung werden die vorhandenen Spaltennamen mit zugehörigen Datentypen
von der Datenbank abgefragt und zunächst in die Symboltabelle eingetragen. Danach
wird der Operatorbaum bottom-up. Für jeden Knoten werden folgende Schritte durchgeführt:
1. (a) Ist der Knoten ein Blattknoten, so hole das zugehörige Schema aus der Symboltabelle
und speichere es im Knoten.
(b) Ist der Knoten ein Knoten mit Bedingung, so speichere die Schemata der Operanden
zwischen. Durchlaufe die Attributterme bottom-up. Für jeden Blattknoten
prüfe, ob das Attribut in den zwischengespeicherten Schemata ungruppiert
vorhanden ist und speichere den Datentyp im Knoten. Für die inneren
Knoten prüfe die Datentypen der Operanden und berechne Ergebnis-Typ.
36

(c) Ist der Knoten eine Projektion, so durchlaufe und prüfe die Attributterme
genau wie die Attributterme in Bedingungen, aber speichere zusätzlich Umbenennungen
von Attributen im zwischengespeichertem Schema.
(d) Ist der Knoten eine Gruppierung, so durchlaufe zuerst die Gruppierungsliste
und speichere eine Gruppierung der aufgetretenden Attribute im zwischengespeichertem
Schema. Durchlaufe dann die Aggregierungsterm-Liste genau wie
die Attributliste einer Projektion, aber prüfe zusätzlich, ob auftretende nichtaggregierte
Attribute den gruppierten Attributen des zwischengespeicherten
Operanden-Schemas entsprechen.
2. Überprüfe die Operations-bedingten Voraussetzungen, die die Schemata der Operanden
erfüllen müssen.
3. Berechne das aktuelle Schema aus den Schemata den zwischengespeicherten Operandenschemata.
Semantische Analyse während des Parsings
Allgemein lässt sich die semantische Analyse oft während des Parsings über eine attributierte
Grammatik durchführen. Die zu prüfenden Eigenschaften, hier also die Datentypen
und die Schemata, werden dabei den nichtterminalen Symbolen als Attribute mitgegeben.
Die Vorschriften, wie ein Datentyp- oder ein Schema-Attribut berechnet wird, sowie die
durchzuführenden Prüfungen, werden den Produktionen als semantische Regeln angefügt.
In einer attributierten Grammatik gibt es synthetische Attribute, die, aus der Sicht des
Ableitungsbaumes eines Ausdrucks, nur vom unteren Teilbaum eines Symbols abhängen.
In einem top-down-Parsing-Verfahren, wie in diesem Fall, können sie in einer Produktion
einfach mittels Rückgabewerten von auftretenden Nichtterminalen und den semantischen
Regeln, für das nichtterminale Symbol auf der linken Seite berechnet und als Rückgabewert
an die nächst höhere Produktion weitergegeben werden.
Daneben gibt es inherite Attribute, dich nicht vom unteren Teilbaum im Ableitungsbaum,
sondern von anderen Symbolen im Baum abhängen. Hängen die inheriten Attribute
nur von im Baum weiter links liegenden Symbolen ab, so sind sie ebenfalls bei einem
top-down-Parsing-Verfahren während des Parsings berechenbar. Da der weiter links
liegende Teil eines Ableitungsbaum immer bereits durchlaufen wurde, sind die nötigen
Attributwerte bereits bekannt und können den nichtterminalen Symbolen als Parameter
mitgegeben werden.
Diese Eigenschaft trifft auf die Relationenalgebra jedoch nicht zu. Die Schemata und die
Datentypen können zwar synthetisch berechnet werden, aber um Prüfen zu können, ob auf
Attribtnamen-Datentyp-Kombinationen, die in einer Bedingung oder Attributterm-Liste
auftreten, in den Schemata der Operanden vorhanden sind, müssen erst die Schemata
der Operanden bekannt sein. Einer der Operanden befindet sich aber im zugehörigen
Ableitungsbaum weiter rechts. Auf diese Weise wäre eine attributierte Grammatik hier
also nicht möglich.
37

4.2.4 Die Symboltabelle
Nach den vorangegangenen Überlegungen muss die Symboltabelle in der Lage sein Bezeichner
und Literale, jeweils mit der Position in der Eingabe und dem Abbild als Zeichenkette,
abzuspeichern. Außerdem muss für jeden Bezeichner der Bezeichner-Typ „Relation“,
„Attribut“ oder „Alias“ gespeichert werden können. Für Attribute und Literale
ist zusätzlich ein Datentyp, für Relationen ein Relationenschema abzuspeichern.
Position Image IdentType Datatype Schema
[1, 6] A Attribute string -
[1, 8] Aneu Alias - -
[1, 11] B Attribute int -
[1, 13] 3 - int -
[1, 16] R Relation - (R.A:string, R.C:int)
[1, 20] S Relation - (S.B:int, S.D:int)
Tabelle 4.5: Symboltabelle für die Eingabe PROJ[A Aneu, B+3](R NJOIN S)
38

4.3 SQL-Code-Erzeugung
In der SQL-Code-Erzeugung muss nun aus dem vorhandenen Operatorbaum, die SQL-
Anfrage erzeugt werden.
Der Algorithmus zur Erzeugung des SQL-Codes sollte sich nicht auf die Annahme stützen,
dass gewisse syntaktische Strukturen aufgrund von durchgeführten Optimierungen
nicht auftreten. Wenn mit Operatorbäumen beliebiger Struktur umgegannen werden kann,
ist es möglich nachträglich beliebige Optimierungsstufen zu ergänzen.
Um eine Anfrage in der Relationenalgebra in SQL zu übersetzen, müssen zunächst die
einzelnen Operationen betrachtet werden. Die Tabelle 4.6 gibt Auskunft darüber, wie sich
einzelne Operationen der Relationenalgebra in SQL-Anfragen abbilden lassen.
Operation SQL-Pendant Beispiel SQL-Code
Selektion Where-Klausel SEL[A>10](R) SELECT *
FROM R
WHERE A>10
Projektion Select-Klausel PROJ[A Aneu, C](R) SELECT A Aneu, C
FROM R
Vereinigung UNION R UNION S SELECT * FROM R
UNION
SELECT * FROM S
Durchschnitt INTERSECT R INTERSECT S analog
Differenz MINUS,
R MINUS S
analog
EXCEPT
Kart. Produkt From-Klausel R CARTESIAN S SELECT *
FROM R,S
Join From-Klausel R JOIN[A=B] S SELECT *
FROM R JOIN S
ON(A=B)
Natural Join From-Klausel R NJOIN S SELECT *
FROM R NATURAL
JOIN S
Semijoin R SJOIN[A=B] S analog
Anti-Semijoin
Gruppierung
Unteranfrage
in Where-Klausel
Group-by-/
Select-Klausel
R ASJOIN[A=B] S SELECT *
FROM R
WHERE NOT EXISTS
( SELECT *
FROM S
WHERE A=B )
GROUP[A#A,avg(B)](R)
Tabelle 4.6: Übersetzung einzelner Operationen in SQL
SELECT A, avg(B)
FROM R
GROUP BY A
Das Prinzip der verschachtelten From-Klauseln
Man könnte die in der Tabelle angegebenen Relationen R und S nun statt als Tabellennamen
als Variablen betrachten. Falls R in der Relationenalgebra-Anfrage ein nicht-trivialer
39

Ausdruck ist, wird in der SQL-Anfrage statt einem Tabellennamen eine Unteranfrage
eingetragen. Hierdurch hätte man einen sehr einfachen Algorithmus, der mit beliebig verschachtelten
Relationenalgebra-Ausdrücken umgehen kann. Als Beispiel soll die folgende
Übersetzung betrachtet werden.
Anfrage:
Übersetzung:
PROJ[B,C](SEL[A>1]()R) NJOIN PROJ[C,D](S)
SELECT ∗
FROM (SELECT B,C
FROM (SELECT ∗
FROM R
WHERE A>1))
NATURAL JOIN (SELECT C,D
FROM S)
Das Problem bei diesem Verfahren ist die stark verschachtelte Struktur. Die Anfragen
werden dadurch sehr schlecht lesbar und in den meisten Fällen weniger effizient.
Entwurf einer verbesserten Übersetzung
SQL bietet in jedem SQL-Block sechs Klauseln, die für eine Anfrage benutzt werden
können. Bei der oben angegeben Übersetzung der Relationenalgebra-Ausdrücke werden
jedoch nur zwei bis drei Klauseln von einer Operation benutzt und jede weitere Operation
erzeugt eine neue Unteranfrage der From-Klausel. Sinnvoller wäre es mit mehreren Operationen
die Klauseln eines SQL-Blocks zu füllen. Hierzu soll folgendes Beispiel betrachtet
werden.
Anfrage:
Übersetzung 1:
Übersetzung 2:
PROJ[B](SEL[A>1](R))
SELECT B
FROM (SELECT ∗
FROM R
WHERE A>1)
SELECT B
FROM R
WHERE A>1
Die zweite Übersetzungs-Variante kommt ohne Unteranfrage aus und ist deshalb der ersten
vorzuziehen. Für die beiden Übersetzungen war keine Umformung der ursprünglichen
Anfrage nötig. Da sich in einem SQL-Block mehr als eine Operation unterbringen lässt,
ist keine eindeutige Abbildung eines Relationenalgebra-Ausdrucks auf eine SQL-Anfrage
möglich. Beide Übersetzungen können daher als SQL-seitige Interpretation des selben
Relationenalgebra-Ausdrucks betrachtet werden.
Der gesuchte Algorithmus soll eine Übersetzung liefern die äquivalent zur eingegebenen
Anfrage ist, also nicht auf Umformungen beruht, also nur auf Basis unterschiedlicher
Interpretationen arbeiten.
Geht man nun davon aus, dass die Anfrage nicht weiter umgeformt werden darf, so muss
zum Beispiel die Anfrage
40

R NJOIN PROJ[A,C](S)
eine Unteranfrage enthalten. Es gäbe sonst keine Möglichkeit den Join nur auf den Spalten
A und C der Tabelle S auszuführen. Unter gewissen Umständen wäre es zwar möglich die
Projektion nach außen zu ziehen und so auf die Unteranfrage zu verzichten, aber nach
obiger Festlegung wäre dies hier nicht erlaubt. Es ergibt sich folgende SQL-Anfrage:
SELECT ∗
FROM R NATURAL JOIN (SELECT A, C
FROM S)
Das Beispiel lässt sich leicht auf ähnliche Situationen übertragen. Ersetzt man die Projektion
durch eine Selektion oder ein Gruppierung, so ist ebenfalls eine Unteranfrage nötig.
In SQL gibt es die Möglichkeit eine Folge von Joins in einer From-Klausel anzugeben, daher
würde das Ersetzen der Projektion durch eine weitere Join-Operation nicht zu einer
Unteranfrage führen. Die Anfrage „R NJOIN (S NJOIN T)“ führt zu der SQL-Anfrage:
SELECT ∗
FROM R NATURAL JOIN S
NATURAL JOIN T
An den bisherigen Beispielen lässt sich gut erkennen, dass die Entscheidung, ob eine Unteranfrage
in der From-Klausel auszuführen ist, nicht nur an der aktuell betrachteten
Operation, sondern an der Kombination von Operation und Operand hängt. Man kann
sich also vorstellen, dass der Operatorbaum Knoten für Knoten durchlaufen wird und für
jeden Knoten in Abhängigkeit seines Vaterknotens entschieden wird, ob eine Unteranfrage
stattfinden muss. Eine Projektion löst als Operand eines Joins eine Unteranfrage aus,
als Operand einer Selektion aber nicht. Einige andere Operanden des Joins, wie ein anderer
Join oder eine Tabellenname, lösen hingegen keine Unteranfrage aus. Es wäre sehr
aufwendig alle möglichen Kombinationen von Operation und Operanden zu untersuchen,
aber es lassen sich gewisse Gesetzmäßigkeiten erkennen.
Die Mengenoperationen
Die Mengenoperationen Vereinigung, Durchschnitt und Minus unterscheiden sich von den
übrigen Operationen dadurch, dass sie nicht die Klauseln eines SQL-Blocks füllen, sondern
zwei unterschiedliche SQL-Blöcke verbinden. Es ist daher nachvollziehbar, dass sobald sie
als Operand einer Nicht-Mengenoperation auftreten, eine Art Unteranfrage ausgeführt
werden muss, da die Aufteilung der Teilanfrage in zwei SQL-Blöcke sonst nicht möglich
wäre. Für die Kindknoten dieser Operationen muss hingegen nie eine Unteranfrage in der
From-Klausel ausgeführt werden, da für den linken und den rechten Operanden ein neuer
unbefüllter SQL-Block zur Verfügung steht. Die Anfrage PROJ[A]((R NJOIN S) UNION
SEL[B>1](T)) ist somit ohne Umformung nicht ohne Unteranfrage in der From-Klausel
darstellbar. Die zugehörige SQL-Anfrage wäre:
SELECT A
FROM (SELECT ∗
FROM R NATURAL JOIN S
UNION
SELECT ∗
41

FROM T
WHERE B>1)
Die Projektion ist in diesem Beispiel die erste Operation und kann daher benutzt werden
um die Select-Klausel des ersten SQL-Blocks zu füllen. Der nächste Knoten im zugehörigen
Operatorbaum wäre die Vereinigung. Da diese hier als Kindknoten einer Nicht-
Mengenoperation auftritt, ist eine Unteranfrage in der From-Klausel nötig. Die Vereinigung
verbindet zwei neue SQL-Blöcke über einen UNION-Operator. Die beiden SQL-
Blöcke werden dann von den Operanden der Vereinigung, also des Joins und der Selektion
befüllt. Auch in diesem Beispiel gilt, dass ein nach-innen-ziehen der Projektion sinnvoller
wäre, als die Anfrage direkt zu übersetzen, aber dies ist wieder die Aufgabe der Code-
Optimierung.
Der (Anti-)Semijoin
Ähnlich lassen sich auch die Semijoins und Antisemijoins untersuchen. Ein Antisemijoin
ist nicht in einem einzelnen SQL-Block darstellbar, da er eine Unteranfrage in der
Where-Klausel auslöst. Semijoins lassen sich zwar durch Umformung in einem SQL-Block
darstellen, dies soll aber wieder Aufgabe der Codeoptimierung sein. Somit wird auch hier
eine Unteranfrage in der Where-Klausel ausgelöst. Semijoins und Antisemijoins können
also wieder gleich behandelt werden. Auftretend als Operand einer Operation, die keinen
neuen SQL-Block zu Verfügung stellt, lösen sie eine Unteranfrage in der From-Klausel
aus. Die Anfrage R NJOIN (S ASJOIN[A=B] T) ist ohne Unteranfrage nicht darstellbar.
Auch als Operand von einstelligen Operationen wird für einen (Anit-)Semijoin eine
Unteranfrage erzeugt, dies kann durch Umformungen wie
PROJ[A](R ASJOIN[A=B] S) = PROJ[A](R) ASJOIN[A=B] S in der Codeoptimierungsstufe vermieden
werden. Für die Operanden eines (Anti-)Semijoins wird jeweils ein SQL-Block
zur Verfügung gestellt, in dem bereits eine Where-Bedingung existiert. Im rechten SQL-
Block ist die Where-Bedingung die Join-Bedingung, im linken besteht sie aus „(NOT)
EXISTS“ und einer Unteranfrage. Legt man nun fest, dass durch Operanden auftretende
Where-Bedingungen mit der vorhandenen Where-Bedingung Und-verknüpft werden, so
wird, abgesehen von den Mengenoperationen, für keinen Operanden eine Unteranfrage
in der From-Klausel ausgelöst. Diese Festlegung widerspricht nicht der Voraussetzung,
dass keine Umformungen in der Relationenalgebra vorgenommen werden dürfen, es handelt
sich hier lediglich um eine mögliche Interpretation. Die Anfrage R ASJOIN[A=B] (S
ASJOIN[B=C] T) führt damit zu folgendem SQL-Code.
SELECT ∗
FROM R
WHERE NOT EXISTS
(SELECT ∗
FROM S
WHERE A=B
AND NOT EXISTS
(SELECT ∗
FROM T
WHERE B=C))
42

Die Anfrage wirkt sehr verschachtelt, es handelt sich bei den Verschachtelungen aber um
die unumgänglichen Unteranfragen in der Where-Klausel. Unteranfragen in der From-
Klausel finden nicht statt. Auch ein (Anti-)Semijoin als linker Operand kommt ohne
Unteranfrage in der From-Klausel aus. Die Übersetzung der Anfrage (R ASJOIN[A=B]
S) ASJOIN[B=C] T führt zu folgendem Code.
SELECT ∗
FROM R
WHERE NOT EXISTS
(SELECT ∗
FROM S
WHERE A=B AND NOT EXISTS
(SELECT ∗
FROM T
WHERE B=C))
Der Join, der Natural Join, der Outerjoin und das kartesische Produkt
Joins, Natural Joins, Outerjoins und Kartesische Produkte können ebenfalls in einer Gruppe
von Operationen zusammengefasst werden. Sie alle sind zweistellige Operationen, die
sich auf die From-Klausel eines SQL-Blocks abbilden lassen. Sie können innerhalb einer
From-Klausel in beliebiger Kombination, beziehungsweise mehrfach auftreten. Das heißt
hintereinander ausgeführte Operationen dieser Gruppe können immer im selben SQL-
Block in der From-Klausel dargestellt werden. Sofern sie als Operand auftreten führen sie
also nie zu einer Unteranfrage, was allerdings nicht ausschließt, dass für ihre Operanden
Unteranfragen ausgeführt werden müssen. Handelt es sich bei den Operanden wieder um
Operationen dieser Gruppe oder um Tabellennamen, muss keine Unteranfrage ausgeführt
werden. Alle anderen Operationen würden hier als Operand zu einer Unteranfrage führen,
da die Unterbringung der jeweiligen Information im aktuellen SQL-Block sich auf das
Ergebnis der Operation und nicht nur auf den jeweiligen Operanden beziehen würde.
Die unären Operationen
Eine Projektion füllt die Select-Klausel eines SQL-Blocks, eine Gruppierung die Group-by
und die Select-Klausel. Da die Hintereinanderausführung mehrerer Projektion oder Gruppierungen
semantisch nicht das selbe ist wie die Aufnahme in die selbe Select-Klausel,
müssen hierbei Unteranfragen ausgeführt werden. Hintereinander ausgeführte Selektionen
könnten zwar in eine Where-Klausel aufgenommen werden, dies ist aber auch durch
eine Umformung darstellbar, in der die Selektionsbedingungen zweier Selektionen undverknüpft
werden. Somit kann in einen SQL-Block eine Projektion oder Gruppierung,
und eine Selektion aufgenommen werden, ansonsten ist eine Unteranfrage auszuführen.
Im Zusammenhang mit den anderen Operationen wurden die einstelligen Operationen
bereits diskutiert.
Die Übersetzung
Zur Übersetzung wird der gegebene Operatorbaum durchlaufen, wobei die Knoten unterschiedlichen
SQL-Block-Objekten zugeordnet werden. Ein SQL-Block enthält neben
Varibalen für die üblichen Klauseln eine zweite Where-Klausel für (Anti-)Semijoins. Bis
43

auf die From-Klausel darf jede Klausel nur einmal befüllt werden. Das Zusammenfügen
der Where-Klauseln geschieht beim Auslesen der Anfrage aus dem Block-Objekt. Da neben
normalen SQL-Blöcken auch Mengenoperationen möglich sind, müssen auch Objekte
einer Mengenoperationsklasse erzeugt werden können, die jeweils zwei Operanden und
eine Operation aufnehmen können.
Man kann sich gut vorstellen, dass Operationen, die sich nach der Übersetzung in einem
SQL-Block befinden, im Operatorbaum zusammenhängend sein müssen. Wird an einer
Stelle im Operatorbaum festgestellt, dass für einen Operanden eine Unteranfrage erzeugt
werden muss, so befinden sich alle Operationen, die die Klauseln der Unteranfrage füllen,
im Teilbaum, der den betrachteten Operand als Wurzel besitzt. Die Operationen innerhalb
dieses Teilbaumes können entweder den SQL-Block der Unteranfrage füllen, oder wieder
neue Unteranfragen erzeugen; sie können nicht (direkt) die Klauseln des äußeren SQL-
Blocks füllen.
Der Baum muss nun durchlaufen und nach den Knoten durchsucht werden, an denen
neue SQL-Blöcke beginnen. Dies wird immer aus Sicht der Operation für die jeweiligen
Operanden entschieden, da für Operationen der Mengenoperations- und der Semijoin-
Gruppe unabhängig von den Operanden neue SQL-Blöcke erzeugt werden müssen und es
von der Operation abhängt, ob die verschiedene SQL-Blöcke über eine Mengenoperation,
über die Where-Klausel oder über die From-Klausel verbunden werden.
Es soll zunächst beispielhaft der union-Knoten aus dem Beispiel-Baum 4.2 betrachtet
werden. Für seine Operanden müssen immer neue SQL-Blöcke erzeugt werden. Bei einem
rekursiven Baum-Durchlauf könnte auf der union-Ebene also für den linken Operanden
ein neuer SQL-Block erzeugt werden, der dann rekursiv den linken Teilbaum des union-
Knotens durchläuft und befüllt wird. Bei der Rückgabe des Blocks an die union-Ebene ist
dieser nach den obigen Überlegungen komplett. Er könnte also bereits als Zeichenkette
ausgelesen werden und im Mengenoperations-Block untergebracht werden. Der linke Teilbaum
wäre damit abgearbeitet und der als Zeichenkette ausgelesene SQL-Block verhält
sich im weiteren nicht anders wie eine Zeichenkette für einen Tabellennamen.
Auf dieser Basis kann eine Übersetzungs-Methode definiert werden, die rekursiv für jeden
Knoten mit einem Block-Objekt block1 aufgerufen wird und folgender Weise vorgeht:
1. Knoten=Mengenoperation: Rufe Operanden-Ebenen mit neuen SQL-Blöcken auf,
lese die Blöcke als Strings aus und führe diese in einem Mengenoperations-Block
zusammen.
2. Knoten=(Anti-)Semijoin: Rufe linke Operanden-Ebene mit übergebenen Block-Element
block1 auf. Rufe dann rechte Operanden-Ebene mit neuem Block-Element block2
auf, lese block2 als String aus und speichere ihn mit (NOT) EXISTS in der Where-
Klausel von block1.
3. Knoten=Joingruppen-Element: Rufe erst erste Operanden-Ebene auf, speichere dann
Join-Operator als Zeichenkette in der From-Klausel von block1 und rufe die zweite
Operanden-Ebene auf.
(a) Für Operanden aus Semijoin-, Mengenoperations- oder unärer Gruppe, rufe
Operanden-Ebene mit neuem Block-Element block2 auf, lese block2 als String
aus, füge zwei Klammern hinzu und speichere String in der From-Klausel von
block1
(b) Sonst: Rufe Operanden-Ebene mit block1 auf.
44

4. Knoten=Element der unären Gruppe: Lese Selektionsbedingung bzw. Attribut- oder
Gruppierungslisten in entsprechende Klauseln von block1 ein. Falls diese bereits
belegt: Erzeuge neues Block-Element block2
(a) Falls Operand aus Semijoin- oder Mengenoperations-Gruppe, rufe Operanden-
Ebene mit neuem Block-Element block3 auf. Füge block3 als String mit zusätzlichen
Klammern in der From-Klausel von, falls vorhanden block2, sonst
block1, ein.
(b) Sonst: rufe Operanden-Ebene mit, falls vorhanden block2, sonst block1, auf.
Gegebenenfalls wird block2 als String mit Klammern in block1 eingetragen.
5. Falls Operand=Tabellenname: Trage Tabellennamen in die From-Klausel von block1
ein.
Zur besseren Verdeutlichung soll das Verfahren im Folgenden durch die Übersetzung des
Beispielbaumes 4.2 angewendet werden.
Übersetzung des Beispielbaumes
1.Aufruf
Njoin1-Ebene
Union-Ebene
Proj-Ebene
Njoin2-Ebene
R-Ebene
Njoin2-Ebene
S-Ebene
Njoin2-Ebene
Proj-Ebene
Der Aufruf des Wurzelknoten-Ebene erfolgt mit einem leeren SQL-Block-
Objekt. (hier: block1)
Da es sich beim linken Operanden um eine Mengen-Operation handelt,
wird für union ein neues Mengen-Opearations-Objekt erzeugt.(hier: mengenBlock1)
Für Nachfolger von Mengenoperationen wird immer ein neuer SQL-Block
Erzeugt, daher wird die Projektions-Ebene wieder mit einem neuen Block
aufgerufen. (hier: block2)
Aus der Attributliste der Projektion wird eine Zeichenkette erstellt und in
die Select-Klausel von block2 eingetragen. Für ein Joingruppen-Element
als Operand eines Elements der unären Gruppe wird keine Unteranfrage
erzeugt. Daher wird die njoin-Ebene mit block2 aufgerufen.
Tabellennamen als Operanden führen nie zu Unteranfragen, daher wird
die R-Ebene mit block2 aufgerufen.
„R“ wird an die From-Klausel von block2 angehängt, die R-Ebene ist abgearbeitet,
block2 wird zurück gegeben.
In der Njoin-Ebene wird nun „NATURAL JOIN“ an die From-Klausel von
block2 gehängt. Da der linke Operand keine Unteranfrage erzeugt, wird
die S-Ebene mit block2 aufgerufen.
„S“ wird an die From-Klausel von block2 angehängt, die S-Ebene ist abgearbeitet,
block2 wird zurück gegeben.
Die njoin-Ebene ist abgearbeitet block2 wird zurück gegeben.
Die Proj-Ebene ist abgearbeitet, block2 wird zurückgegeben.
45

Abbildung 4.2: Beispiel-Baum für die Code-Erzeugnung
Union-Ebene
Die linke Teilanfrage der Vereinigung ist komplett und kann als String
„Select A From R NATURL JOIN S“
für den linken Operanden von mengenBlock1 eingetragen werden. Die
Mengenoperation in mengenBlock1 wird auf „UNION“ gesetzt. Für den
rechten Operand einer Mengenoperation wird wie für den linken ein neuer
SQL-Block übergeben. (hier block3)
T-Ebene
Union-Ebene
„T“ wird an die From-Klausel von block3 angehängt, die S-Ebene ist abgearbeitet,
block3 wird zurück gegeben.
Die rechte Teilanfrage der Vereinigung ist komplett und kann als String
„Select * From T“ 1
1 Dass für eine unbefüllte Select-Klausel „Select *“ ausgeben werden muss, muss in der toString-
Methode der SQL-Block-Klasse beachtet werden
46

für den rechten Operanden von mengenBlock1 eingetragen werden. Die
union-Ebene ist abgearbeitet und mengenBlock1 kann zurückgegeben werden.
Njoin1-Ebene
In der Njoin-Ebene wird mengenBlock1 als Zeichenkette mit zusätzlichen
Klammern in die From-Klausel von block1 aufgenommen. Die Zeichenkette
dazu lautet nun
„(Select A From R NATURL JOIN S
UNION
Select * From T)“
Danach wird „NATURAL JOIN“ angehängt. Der rechte Operand des
njoin-Knotens ist eine unäre Operation und löst als Operand eines Elementes
der Join-Gruppe eine Unteranfrage aus. Die Sel-Ebene wird also
mit einem neuem Block-Element block4 aufgerufen.
Sel-Ebene
U-Ebene
Sel-Ebene
Njoin1-Ebene
Der Bedinungs-Teilbaum der Selektion wird als String ausgelesen und in
die Where-Klausel von block4 eingetragen. Da Tabellennamen als Operand
von unären Operationen keine Unteranfrage auslösen, wird die U-Ebene
mit block4 aufgerufen.
„U“ wird an die From-Klausel von block4 angehängt, die U-Ebene ist
abgearbeitet, block4 wird zurück gegeben.
Die Sel-Ebene ist abgearbeitet, block4 wird zurückgegeben.
Da block4 für eine From-Unteranfrage erzeugt wurde, wird block4 als
Zeichenkette mit zusätzlichen Klammern
„( Select * FROM U WHERE A>1 )“
in die From-Klausel von block1 eingetragen. Block1 wird zurückgegeben
und enthält die gesamte Anfrage
Select ∗
From (Select A From R NATURL JOIN S
UNION
Select ∗ From T)
NATURAL JOIN
(Select ∗ From U Where A>1)
47

Kapitel 5
Implementierung
5.1 Package-Struktur
Das Projekt gliedert sich in zwei Packages
1. de.ra2sql.core
2. de.ra2sql.gui
Das core-Package enthält alle Klassen, die zur internen Verarbeitung der Anfrage nötig
sind. Hierzu gehören die Symboltabelle, der Scanner, der Parser, die Semantische-Analyse-
Einheit, die SQL-Code-Erzeugung, eine Klasse, die die Datanbank-Anfragen regelt, die
TreeBuilder-Klasse zum Aufbau des Operatorbaumes und diverse Datenstrukturen zur
Speicherung von Informationen wie zum Beispiel Datenstrukturen für die Knoten-Objekte
und die Schema-Datenstruktur.
Die Haupt-Komponenten Parser, Semantische-Analyse-Einheit und Code-Erzeugung arbeiten
unabhängig voneinander. Sie müssen von außen mit einem zu verarbeitenden Input
aufgerufen werden und geben der aufrufenden Klasse den verarbeiteten Output zurück.
Das gui-Package enthält die Klassen für die Graphische Benutzerschnittstelle. Die Haupt-
Klasse GUI ist für die Visualisierung der Benutzerschnittstelle sowie für die Ansteuerung
der Haupt-Komponenten des core-Packages zuständig.
5.2 Die Grammatikdatei und generierte Klassen
Die Grammatikdatei besteht aus einem Optionen-Block, einem Parser-Block, der zusätzlichen
Code für den generierten Parser enthalten kann, den Token-Definitionen und den
Produktionen der Grammatik.
Da die zu entwickelnde Anfrage-Sprache nicht case-sensitive sein soll, ist im Optionenblock
die Option „IGNORE_CASE“ zu setzen.
Der Parser-Block enthält neben der Package-Angabe eine statische Instanz der Klasse
TreeBuilder, zum Aufbau des Operatorbaumes, und eine parse-Methode. Die Method erwartet
die zu parsende Anfrage in einem java.io.Reader-Objekt und gibt den Wurzelknoten
des erzeugten Operatorbaumes zurück. Ihre Aufgaben bestehen darin, alle verwendeten
statischen Klassen und Instanzen zu reinitialisieren, sich selbst und damit auch implizit
48

den Scanner mit der übergebenen Anfrage zu reinitialisieren, das Start-Symbol der Grammatik
aufzurufen und den Wurzelknoten des Operatorbaumes beim TreeBuilder-Objekt
abzufragen und dem Aufrufer zurück zu liefern.
Die Token-Definitionen und die Grammatik können Kapitel 4.2.1 und 4.2.2 entnommen
werden. Zusätzlich wird innerhalb der Produktionen der Grammatik der Tree-Builder
angesteuert und Relationen, Aliase und Literale in die Symboltabelle aufgenommen.
Die generierten Klassen
Aus der Grammatik-Datei werden sieben Klassen generiert. Die Klassen
• SimpleCharStream.java
• Token.java
• TokenMgrError.java
• ParseException.java
werden nur generiert sofern sie nicht existieren, da sie unabhängig vom Inhalt der Grammatikdatei
sind. Außerdem werden die Klassen
• Parser.java
• ParserConstants.java
• ParserTokenManger.java
erzeugt. ParserConstants enthält die Konstanten für die in der Grammatikdatei definierten
Tokenklassen. Der ParserTokenManager stellt den lexikalen Scanner dar, der anhand
der in der Grammatikdatei definierten regulären Ausdrücke für die Tokenklassen, aus dem
SimpleCharStream, der die Eingabe enthält, eine Tokenfolge erstellt. Der Scanner muss
nicht expilzit aufgerufen werden, sondern wird automatisch durch den generierten Parser
angesteuert. Der Parser enthält für jede Produktion der Grammatik eine eigene Methode,
die eine ParseException werfen kann. Das aktuelle Token-Objekt ist in der Variable token
gespeichert, das Lookahead kann über die Methode jj_ntk abgefragt werden. Der Parser
ist statisch und muss daher über eine ReInit()-Methode reinitialisert werden, welche
automatisch auch den TokenManager reintialisiert.
5.3 Beschreibung der nicht generierten Klassen
Die Knoten-Datenstrukturen
Die Knoten-Datenstrukturen werden für den Operatorbaum benötigt. Von allen Knoten-
Objekten gespeichert werden müssen die Operanden, die ebenfalls wieder Knoten-Objekte
sind, der Vaterknoten, die Tokenklasse, die Position zur Identifizierung eines Symboltabellen-
Eintrags und zur Ermöglichung einer gezielten Fehler-Ausgabe, ein Relationenschema und
ein Datentyp.
Die benötigten Getter- und Setter- Methoden werden im Interface INode spezifiziert.
Die Klasse Node implementiert das Interface INode ohne zusätzliche Funktionalität. Alle
Elemente der Anfrage, die keine Attributliste oder Bedingung beinhalten, können durch
49

Node-Objekte dargestellt werden. Hierzu gehören alle Elemente innerhalb einer Attributliste
oder einer Bedingung, alle Mengenoperationen, das kartesische Produkt, der natürliche
Verbund, so wie alle Bezeichner.
Die Knoten-Datenstruktur zur Speicherung von Operationen mit Bedingung, also die
Selektion und die Joins, erweitert die Klasse Node um die Speicherung eines Bedingungs-
Knotens und die zugehörigen Getter und Setter.
Die Knoten-Datenstruktur zur Speicherung von Operationen mit Attributliste erweitert
die Node-Klasse um die Speicherung eines Arrays, welches die einzelnen Wurzelknoten
der Attributterm-Listenelemente enthält, sowie ebenfalls um die Getter- und Setter-
Methoden.
Da die Gruppierung zwei Listen enthält, erweitert die zugehörige Knoten-Datenstruktur
die Listen-Knoten-Klasse um eine zweite Liste, die Gruppierungsliste, sowie um die nötigen
Getter und Setter für die Gruppenelemente.
Das Klassendiagramm 5.1 soll die Knoten-Hierarchie verdeutlichen.
SymbolTableEntry
Objekte der Klasse SymbolTableEntry stellen Symboltabellen-Einträge dar. Sie speichern
jeweils die Position, das Abbild, den Bezeichner-Typ, ein Relationen-Schema und einen
Datentyp. Außerdem werden die nötigen Getter- und Setter-Methoden bereitgestellt.
SymbolTable
Die Klasse SymbolTable enthält eine Liste von Symboltabellen-Einträgen der Klasse SymbolTableEntry.
Die Methoden setAttribute, setAlias, setRelation und setLiteral werden
vom Parser mit einem Token-Parameter aufgerufen und legen jeweils ein neues Eintrag-
Objekt mit bekannter Position, bekanntem Abbild und Bezeichner-Typ an. Die Bezeichner-
Typen sind als Konstanten definiert. Neben den bereits genannten Methoden und den noch
fehlenden Gettern und Settern, wird noch ein Methode benötigt, die alle unterschiedlichen
Relationennamen der Tabelle zurück gibt. Diese wird benötigt um die Schemata
aller Relationen aus der Datenbank abzufragen. Alle angebotenen Methoden, sowie auch
die Liste mit Einträgen, werden statisch implementiert, daher wird noch eine Methode
ReInit() benötigt, die die Einträge der Symboltabelle entfernt um diese auf die nächste
Anfrage vorzubereiten.
TreeBuilder
Die TreeBuilder-Klasse wird vom Parser angesteuert und ist für den Aufbau des Operatorbaumes
verantwortlich.
Der TreeBuilder speichert global den root-Knoten, an welchem der Wurzel-Knoten des
eigentlichen Operatorbaumes angehängt werden soll. Außerdem muss der Zeiger auf den
aktuell zu bearbeitenden Knoten global gespeichert werden. Die, durch den Parser gesteuerte,
Navigation im Baum geschieht durch die Methoden add und up. Ob es sich bei
einem Token um eine Infix-Operation handelt, entscheidet der TreeBuilder intern. Da für
das An- oder Umhängen des ersten Knotens einer Attributliste, einer Gruppierungsliste
oder einer Bedingung spezielle Zugriffsmethoden benutzt werden müssen, muss der Tree-
Builder wissen, wann dies der Fall ist. Hierzu werden vier Modi als statische Konstanten
definiert und eine Variable, die die Position des Zeigers, als Tiefe innerhalb des aktuellen
50

Abbildung 5.1: Klassenhierarchie der Knoten-Objekte
Bedingungs-, Attributterms- oder Gruppierungslisten-Teilbaums angibt. Eine besondere
Zugriffsmethode, ist immer dann nötig, wenn der Modus nicht auf Normal steht und die
Tiefe Null ist. Die Art des gesonderten Zugriffs hängt vom Modus ab. Dieser wird vom
Parser in den jeweiligen Produktionen gesetzt.
51

Abbildung 5.2: Die Klasse TreeBuilder
Attribute
Ein Attribut speichert einen Attributnamen, einen (optional leeren) Relationennamen-
Präfix, und einen Datentyp. Es werden die nötigen Getter- und Setter-Methoden bereitgestellt,
sowie eine equals-Methode und eine isCompatibleTo-Methode bereitgestellt. Zwei
Attribute sind gleich, wenn sie den gleichen Namen, den gleichen Präfix und den gleichen
Datentyp besitzen. Sie sind kompatibel, wenn Name und Datentyp übereinstimmen. Die
Präfixe dürfen sich dabei also unterscheiden. Die Methode wird an mehreren Stellen von
der Semantischen Analyse benötigt. Zum Beispiel müssen für eine Vereinigung zweier
Relationen, alle Attribute der Schemata kompatibel sein.
RelationsSchema
Ein Relationenschema-Datenstruktur muss eine Liste von Attributen speichern können.
Außerdem müssen neben den üblichen Getter- und Setter-Methoden, Methoden bereitgestellt
werden, die ein Schema-Objekt mit einem gegebenen Schema-Objekt auf Gleichheit,
Teilmengen-Beziehungen, oder Kompatiblität überprüfen. Zwei Schema-Objekte sind
kompatibel, wenn sie gleich viele Attribute besitzen und diese zueinander kompatibel
sind. Zusätzlich beinhaltet die Schema-Datenstuktur eine toString-Methode, die es möglich
macht bei einem semantischen Fehler involvierte Schemata mit auf dem Bildschirm
auszugeben.
SchemaOperations
Die Klasse SchemaOperations bietet statische Methoden zur Berechnung von Schemata
an.
Semantische Analyse
Die Klasse SemanticalAnalysisUnit implementiert die semantische Prüfung der Schemata
und Datentypen im Operatorbaum.
52

Sie wird über die öffentliche Methode „analyse“ aufgerufen, die als Paramenter den Wurzelknoten
des zu Prüfenden Operatorbaumes erwartet und den Wurzelknoten des überarbeitenden
Baumes zurückgibt. Im Fehlerfall wird eine SemanticalException geworfen.
Bevor mit der Analyse begonnen wird, wird die Methode „readOutRelationsSchemata“
der Klasse DatabaseFrontend aufgerufen, welche die Schemata aller in der Anfrage verwendeten
Relationennamen von der Datenbank abfragt und in die Symboltabelle einträgt.
Die Analyse erfolgt rekursiv über die Methode „recursiveAnalyse“. Für die Blattknoten
werden die jeweiligen Schemata aus der Symboltabelle abgefragt und im Knoten-Objekt
eingetragen. Ist in der Symboltabelle für einen Blattknoten kein Schema-Eintrag vorhanden,
so wird eine SemanticalException geworfen. Die Schemata der inneren Knoten werden
nach den jeweiligen Prüfungen über die Methode computeSchema berechnet, die zur
Berechnung die statischen Methoden der Klasse SchemaOperations nutzt. Für jedes von
Node abgeleitete Knoten-Objekt, werden die Schemata des linken und des rechten Operanden
in den globalen Schema-Variablen currentSchemaLeft und currentSchemaRight
abgespeichert und je nach Knotentyp die passende Methode zur Prüfung der Bedingung,
der Attributliste oder der Gruppierungsliste aufgerufen.
Abbildung 5.3: Klassendiagramm für die Semantische Analyse
SQLBlock
Die Klasse SQLBlock wird für die SQL-Code-Erzeugung benötigt. Sie bietet die Methoden
setSelect, addToFrom, setWhere, setWhereExists, setGroupBy, setHaving und toString
an. Die Methode set-Methoden speichert den übergebenen String in der globalen Variable
falls dieser zuvor null war und gibt true zurück. Ist die Variable bereits initialisiert, so
wird false zurückgegeben. Auf diese Weise weiß die aufrufende ConversionUnit, ob die
Speicherung einer Klausel im aktuellen SQL-Block möglich ist oder ob ein neuer Block
53

erzeugt werden muss. Die Methode addToFrom und fügt den übergebenen String der
globalen From-Liste hinzu.
Operations
Die Klasse Operations beinhaltet die statischen Konstanten für die Einteilung der relationenalgebraischen
Operationen in Gruppen, sowie eine statische Methode zur Zuordnung
der Gruppenvariablen zu den einzelnen Operationen. Sie erwartet eine Konstante für die
Tokenklasse und gibt eine Konstante für die Gruppe zurück.
ConversionUnit
Die Klasse ConversionUnit implementiert die Übersetzung der Anfrage. Die Klasse bietet
eine öffentliche statische decodeToSQL-Methode an, die den Wurzelknoten des Operatorbaumes
als Parameter erwartet und die SQL-Anfrage als String zurückgibt. Die Übersetzung
findet dann rekursiv in der privaten Methode „decode“ statt. Diese erwartet ein
Objekt der Klasse SQL-Block, das aktuelle Knoten-Objekt und einen String, der Leerzeichen
oder Tabulatoren zur Formatierung der SQL-Anfrage enthalten kann. Die Zuordnung
der Gruppen-Variablen zu den verschiedenen Relationenalgebraischen Operationen erfolgt
über die statischen Methoden der Klasse „Operations“. Die Übersetzung der Bedingungen,
Attributlisten und Gruppierungslisten erfolgt wieder in eigenen Methoden.
Abbildung 5.4: Klassendiagramm für die Code-Erzeugnunge
54

DatabaseFrontend
Die Klasse DatabaseFrontend ist für die Datenbank-Anfragen zuständig. Sie beinhaltet
die Methoden initConnection, readOutRelationsSchemas, executeSQLQuery und close-
Connection.
Die Methode initConnection erwartet einen Benutzernamen und ein Passwort und baut
die Verbindung zur Datenbank auf. ExecuteQuery erwartet eine SQL-Anfrage als String,
führt diese aus und gibt einen java.io.Reader zurück, der die formatierte Ergebnis-Tabelle
enthält. Die Methode readOutRelationsSchemas fragt alle in der Anfrage aufgetretenden
Relationennamen über die Methode getDistinctRelationEntries von der Symboltabelle ab,
fragt alle Attribut-Datentyp-Paare von der Datenbank ab, erzeugt daraus Schema-Objekte
und speichert diese in der Symboltabelle.
55

Kapitel 6
Die Benutzerschnittstelle
Die Benutzerschnittstelle besteht im Wesentlichen aus einem Eingabe- und zwei Ausgabe-
Bereichen, zwei Toolbars und einer Menüzeile.
Abbildung 6.1: Die Benutzer-Schnittstelle
Die Eingabe
Die Eingabe der Anfrage erfolgt im oberen Teilfenster. Sie kann mehrzeilig sein und beliebig
viele Leerzeichen oder Tabulatoren enthalten. Die Schlüsselworte der Sprache können
optional händisch eingegeben, oder durch Anklicken des entsprechenden Symbols in der
linken Toolbar an der aktuellen Cursor-Position in der Eingabemaske eingefügt werden.
56

Senden der Anfrage
Eine Anfrage kann durch Anklicken des Send-Buttons gesendet werden. Da hierzu ein
Datenbank-Login nötig ist, öffnet sich, falls der Nutzer die Login-Daten nicht bereits
eingegeben hat, automatisch ein Fenster zur Entgegennahme des Benutzernamens und
des Passworts. Im Vorfeld kann die Eingabe der Login-Daten auch über einen Button in
der Toolbar oder über die Menüzeile -> Optionen -> Einstellungen erfolgen. Tritt bei
der Anfrage-Analyse ein Fehler auf, so wird dieser im unteren Ausgabe-Bereich angezeigt,
ansonsten wird die Ergebnistabelle im Ausgabebereich dargestellt.
Eine Anfrage kann durch Anklicken des ToSQL-Buttons auch optional als SQL-Anfrage
im Ausgabe-Bereich ausgegeben werden.
Bedienbarkeit
Zum besseren Verständnis werden für alle Buttons der Oberfläche Tooltips angezeigt,
die kurz die Funktionalität erläutern. Außerdem lässt sich unter dem Menüpunkt Hilfe
eine Hilfedatei anzeigen, die die Benutzeroberfläche und die Sprache noch einmal kurz
erläutert.
Weitere Funktionen
Alle Eingabe- und Ausgabe-Bereiche lassen sich scrollen sobald der dargestellte oder eingegebene
Inhalt zu groß wird. Zusätzlich können aber einzelne Teilfenster durch kleine
Pfeile in den Trennbalken ein- und ausgeblendet werden oder in der Größe durch ziehen
des Trennbalkens manuell verändert werden. Die Anordnung der Fenster lässt sich durch
zwei Buttons in der oberen Toolbar oder ober das Ansicht-Menü verändern. CopyPaste
wird in der Eingabemaske unterstützt, in den Ausgabe-Bereichen ist nur das Kopieren
des Auswahlbereiches möglich. Die Funktionen finden sich im Rechtsklick-Menü, im
Bearbeiten-Menü, oder können über die Standard-Tastenkombinationen benutzt werden.
57

Abbildungsverzeichnis
4.1 Aufbau des Operatorbaumes . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 Beispiel-Baum für die Code-Erzeugnung . . . . . . . . . . . . . . . . . . . 46
5.1 Klassenhierarchie der Knoten-Objekte . . . . . . . . . . . . . . . . . . . . . 51
5.2 Die Klasse TreeBuilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.3 Klassendiagramm für die Semantische Analyse . . . . . . . . . . . . . . . . 53
5.4 Klassendiagramm für die Code-Erzeugnunge . . . . . . . . . . . . . . . . . 54
6.1 Die Benutzer-Schnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
58

Tabellenverzeichnis
4.1 Sprachelemente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Operatoren/Operationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3 Tokenklassen-Definitionen für Relationenalgebraische Operationen . . . . . 17
4.4 Tokenklassen-Definitionen für arithmetische Operatoren . . . . . . . . . . . 17
4.5 Symboltabelle für die Eingabe PROJ[A Aneu, B+3](R NJOIN S) . . . . . 38
4.6 Übersetzung einzelner Operationen in SQL . . . . . . . . . . . . . . . . . . 39
59