Relationale Algebra und Anfragesprachen

Die oben dargestellte reltionale Algebra als Anfragesprache ist operational. Das heißt, man kann an den Formeln ablesen, wie die Anfrage zu berechnen ist. In der Theorie relationaler Datenbanken gibt es mindestens drei weitere, formale Anfragesprachen, die von Bedeutung sind,

• Der Bereichskalkül,
• der Tupelkalkül und
• Datalog, (eine eingeschränkte Prädikatenlogik erster Stufe).

Auf die ersten beiden gehen wir hier nicht näher ein. Datalog wird im nächsten Abschnitt noch näher erläutert. Wichtig zu wissen ist folgendes:

• Sowohl der Bereichskalkül als auch der Tupelkalkül sind nicht operational in obigen Sinne.
• Zwischen Teilmengen dieser Anfragesprachen herrscht Äquivalenz hinsichtlich der berechneten Antworten, in ihrer jeweils vollen Form sind sie aber unvergleichbar.
• Sql als die Anfragesprache schlechthin basiert auf dem Tupelkalkül, Qbe (Query by Example) auf dem Bereichskalkül. Die Performanz relationaler Datenbanken beruht zu einem sehr großen Teil darauf, das Anfragen optimiert werden können, d.h. die Reihenfolge der Operationen kann günstig vertauscht werden. Fast alle Algorithmen hierzu beruhen auf der relationalen Algebra als Anfragesprache. Kurz, es wird zwischen den Sprachen und ihren zugrunde liegenden Formalismen hin und her übersetzt, was dazu führt, daß das reale, beobachtbare Verhalten der Datenbank nicht im Einklang mit der Theorie stehen muß.
• Erschwerend für eine formale Beschreibung des Verhaltens einer Datenbank kommt hinzu, daß z.B. Sql zusätzliche Befehle enthält, die in diesen Anfragesprachen gar nicht beschrieben werden können, z.B. Aggregationen oder die Berechnung der Standardabweichung. Hier sind wieder andere Formalismen nötig.

Die typischste Sql-Anfrage ist wohl:

       SELECT  <Attribut_Liste>
       FROM    <Relationen_Liste>
       WHERE   <Pr"adikats_Liste>

Diese übersetzt sich verbal wie folgt in relationale Algebra:

1. Selektiere die Attribute mittels der Prädikate aus dem WHERE Teil
2. über dem kartesischen Produkt der Relationen aus dem FROM Teil
3. und projeziere das Ergebnis auf die Attribute aus dem SELECT Teil.

Hier haben wir die Möglichkeit der Optimierung völlig außen vor gelassen! Wenn die FROM Anweisung nur eine Tabelle enthält, ist das kartesische Produkt überflüssig. Andernfalls sollte es immer auch einen WHERE Teil geben, damit das kartesische Produkt möglichts durch einen Join ersetzt werden kann. Die Ausdrucksmächtigkeit von Sql beruht nun zum einen auf der Möglichkeit der Schachtelung von weiteren SELECT Anweisungen innerhalb des WHERE Teils und zum anderen auf der Möglichkeit, die Egebnisse mehrerer SELECT Anweisungen mittels der Mengenoperationen wie z.B. Vereinigung zu verknüpfen.