Databases Reference
In-Depth Information
oder
Proj[artikel_nr, bezeichnung] (
Sel[lagerplatz = 2](artikel)
Join[artikel_nr]Position
Join[bestell_nr]Bestellung
Join[kunden_nr] Sel[ort = 'Kayhude' ] (Kunde)
)
Artikel_nr
Bezeichnung
K002
Hose
K003
Damenhut
Alle drei Ausdrücke liefern dasselbe Ergebnis - allerdings ist der Rechenauf-
wand unterschiedlich. Am höchsten ist er für die erste Formulierung, da hier erst
alle Tupel verknüpft werden und die Selektion am Schluss erfolgt. Für die zweite
und dritte Formulierung ist a priori nicht klar, welche Formulierung weniger
Rechenaufwand erfordert - es ist dort nur die Reihenfolge der Verbundopera-
tion unterschiedlich - , möglicherweise ergibt sich daraus überhaupt kein Unter-
schied.
Dieses Beispiel zeigt auch, dass ein Datenbanksystem sinnvollerweise einen
Abfrage-Optimierer benötigt. Dieser soll in der Lage sein, eine gegebene Abfrage
so in eine äquivalente Abfrage (d.h. eine Abfrage mit derselben Ergebnismenge)
umzuformen, dass der Rechenaufwand möglichst gering wird. Hierzu stehen dem
Abfrage-Optimierer Informationen über die physikalische Speicherorganisation
sowie über die Anzahl der Tupel in den beteiligten Relationen und gegebenenfalls
Erfahrungen aus vergangenen Abfragen zur Verfügung. Meistens sind die auto-
matisch erzeugten Abfragepläne relativ gut - bei komplexen Anfragen kann gege-
benenfalls ein manuelles Tuning überlegen sein.
Beispiel
Im Folgenden soll eine Liste der Bestellungen mit dem Bestelldatum, Lieferdatum
und der Kundennummer sowie dem Rechnungsbetrag ausgegeben werden.
Grp[bestell_nr, bestelldatum, lieferdatum, kunden_nr |
rechnungsbetrag ::= SUM (gesamtpreis * (1+ MWSt))] (
Bestellung Join[bestell_nr] Position
Join[artikel_nr] Artikel
)
