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