Die Redundanz der Sprache SQL (Structured Query Language) ist ein Hindernis fuer die Verbesserung der Performanz von relationalen Datenbanksystemen. Hagen Cyrus* weiss Abhilfe: Unzulaenglichkeiten bereinigen, Klarheit schaffen und relationale Unvollstaendigkeit beseitigen.

SQL ist eine extrem redundante Sprache. Abgesehen von ganz einfachen Abfragen lassen sich alle Probleme auf verschiedene Weise formulieren. Doch nicht alle moeglichen Formulierungen werden gleich schnell verarbeitet. So sind die Benutzer dazu gezwungen, die jeweils "beste" Formulierung erst zu suchen.

Das aber widerspricht dem relationalen Modell, das auf die Entlastung von solchen Ueberlegungen zielt. Damit ergibt sich eine Diskrepanz zwischen dem relationalen Modell mit seinen produktivitaetssteigernden Eigenschaften und der von der IBM gefoerderten Abfragesprache SQL.

Relationale Datenbanksysteme steigern die Produktivitaet spuerbar in dem Masse, in dem sie den Benutzer bei Abfragen von Performanz- Ueberlegungen befreien. Darum muss das Datenbankdesign redundante Formulierungen moeglichst ausschliessen; sie belasten den Anbieter, ohne dem Benutzer effektivere Ausdrucksmoeglichkeiten zu bieten.

Das folgende Beispiel verdeutlicht, wie unterschiedlich sich ein einziges Problem in SQL formulieren laesst: Die beiden Tabellen der Datenbank, Mitarbeiter und Gehalt, haben je 9 900 Zeilen. Es besteht eine 1:1-Beziehung zwischen ihnen (siehe Abbildung 2).

Die Frage, welche der Angestellten 13 Einheiten verdienen, kann auf mindestens sieben verschiedene Weisen gestellt werden (siehe Abbildung 1).

Die aufgezaehlte Reihenfolge duerfte der Wahrscheinlichkeit der Verwendung fuer diese Abfrage entsprechen. Die beiden IN- und ANY- Versionen entsprechen sich in der Weise, wie sie die Tabellen in der Haupt- und Unterabfrage benutzen. COUNT ist wohl die am wenigsten direkte Abfragemoeglichkeit. Die IN- und ANY-Abfragen sind die deutlichsten Beispiele fuer Redundanz; denn sie koennen identisch benutzt werden.

IN ist Teil von IBMs anfaenglichem Versuch, direkte relationale Ausdruecke in SQL zu vermeiden, wurde dann aber im Inventa4 belassen, obwohl die Idee aufgegeben werden musste. IN erweitert die Funktionalitaet der Sprache in keiner Weise, findet aber haeufiger Anwendung als gleichwertige Ausdruecke. SQL-Systeme unterstuetzen ueber Optimierungsmassnahmen die Unabhaengigkeit physischer Daten; daher werden alle sieben Versionen ausgefuehrt, und zwar unabhaengig davon, welche Indizes gesetzt wurden. Dennoch koennen die Entscheidungen des Optimizers - und damit die jeweilige Performanz - von der Art, wie die Indices in der Datenbank gesetzt sind, beeinflusst werden.

Bei der JOIN-Vorgabe:

WHERE gehalt.Persno = mitarbeiter.persno

werden Optimizer hoechstwahrscheinlich Persno benutzen. Einige der Versionen (JOIN; IN1, ANY1, EXISTS, COUNT) scheinen von einem Index in der Spalte "Gehalt" zu profitieren, denn die Funktion eines Optimizers ist es, die effizienteste Verarbeitungsart sicherzustellen; das heisst hier: Die Anzahl der Zeilen muss sich auf ein Minimum beschraenken lassen, bevor ein JOIN durchgefuehrt wird.

Aus der Angabe

Gehalt = 13

resultieren nur elf Zeilen, bei

Gehalt.Persno =

Mitarbeiter.Persno

werden aufgrund der 1:1-Beziehung dagegen alle 9 900 Zeilen ausgegeben. Ein guter Optimizer wird den Index auf "Gehalt" dazu nutzen, die Gehaltstabelle zunaechst auf elf Zeilen zu reduzieren, anstatt alle 9 900 Zeilen per JOIN mit allen Mitarbeiter-Zeilen zu verknuepfen.

Wenn ein Index existiert, der Optimizer die Zeilenstatistik hinter den verschiedenen Bedingungen in der WHERE-Klausel ausmachen kann und die notwendigen statistischen Informationen im System- Verzeichnis verfuegbar sind, wird der Index benutzt. Dadurch wird der Zugriff auf die Mitarbeiter-Tabelle verbessert. Durch die Minimierung der Anzahl der verknuepften Zeilen und das Erzeugen entsprechender Tabellen fuer den JOIN laesst sich zugleich die Performanz optimieren.

Relationale Systeme bringen es auf Antwortzeiten von einer bis sieben Sekunden bei einem JOIN von zwei Tabellen mit fast 10000 Zeilen. Das widerlegt die Behauptung, die Performanz von relationalen Systemen sei schlecht. Welches nicht-relationale System erledigt Vergleichbares in dieser Zeit? Welches nicht- relationale System schafft dies ohne Programmieraufwand, physikalische Spezifikationen in der Abfrage, vordefinierte physikalische Verbindungen von Tabellen und ohne obligatorisches Tuning? Darueber hinaus bieten die meistens relationalen Systeme zusaetzliche Tuning-Moeglichkeiten fuer eine noch hoehere Leistungsfaehigkeit.

Performanz-Probleme

belasten auch Anwender

Die Tatsache, dass relationale Systeme aequivalente Abfragen heute unterschiedlich verarbeiten, ist auf SQL zurueckzufuehren und nicht darauf, dass Produkte relational sind. Der redundante Charakter von SQL, mit dem man heute noch leben muss, macht es Anbietern unmoeglich, den Benutzer bei der Auswahl einer Anweisungsformulierung ganz von Ueberlegungen zur Performanz zu entlasten. Allerdings zeigen die meistbenutzten Abfrageformulierungen sehr gute Leistungen. Nur die seltener verwendeten Formulierungen beduerfen erhoehter Aufmerksamkeit.

Das Ingres-System ist allerdings in der Lage, die ungleiche Performanz bei aequivalenten SQL-Abfragen anzugleichen. Warum sollte dies nicht auch bei anderen relationalen Systemen moeglich sein? Strategien wie die folgende minimieren Differenzen in Sachen Performanz aequivalenter SQL-Ausdruecke. Hier ein Beispiel fuer dynamisches SQL:

query

parsing

name validation

QUERY TRANSFORMATION

OPTIMIZATION

execution

Wie der Optimierungsaufwand beeinflussen auch Transformationsroutinen die Leistungsfaehigkeit aequivalenter Formulierungen. Bei der Transformation werden SQL-Ausdruecke analysiert, in eine "Standard"-Version uebersetzt und an den Optimizer uebergeben. Dieser waehlt dann die beste Zugriffsform aus.

Wie auch immer dieser Vorgang in den verschiedenen Systemen genannt wird, er stellt sicher, dass der Optimizer die geeignetste Zugriffsmethode auswaehlt. Ohne eine Transformation koennte ein Optimizer einen Index zum Beispiel nur bei einigen, nicht aber bei allen redundanten Formulierungen benutzen. Dies gilt besonders, wenn die dem Optimizer verfuegbaren statistischen Informationen begrenzt sind.

Nicht nur die Nutzung des Speichers und der Zeilenzaehlung, auch die Verteilung von Spaltenwerten im Katalog fuehren zu effektiveren Entscheidungen des Optimizers; die Analyse der statistischen Implikationen von Restriktionen und die Evaluation der vorhandenen Indizes lassen sich praeziser vornehmen.

Ausser Hardware- und Designaspekten beeinflussen auch Speicherstrukturen, die Strukturen des Katalogs und die Zugriffsmethode, Statistiken und physische Mechanismen, die vom Optimizer benutzt werden koennen, Joining-Methoden sowie die Ausfuehrungsform selbst die Antwortzeiten.

Ohne Kenntnis der exakten Zugriffsstrategie fuer jedes DBMS-System ist es allerdings schwierig festzustellen, inwieweit jeweils ein einzelner Faktor zu Leistungsabweichungen beitraegt. DB/2 loest das Problem mit der Funktion EXPLAIN, die Informationen ueber die jeweilige Zugriffsstrategie ausgibt. Ingres und Sybase verfuegen ueber aehnliche Funktionen. PC-DBMS enthalten derartige Moeglichkeiten allerdings noch nicht. Je mehr Benutzer das relationale Modell und dessen Philosophie hinsichtlich der Produktivitaet verstehen, desto lauter werden sie vom Anbieter einheitliche Performanz und dokumentierte Ausfuehrungsplaene verlangen. Einig sind sich Anbieter und Anwender in der Forderung nach einfacher Implementierung und Benutzerfreundlichkeit von relationalen DB-Systemen. Je eher relationale Datenbanksysteme die Redundanz von SQL ueberwinden, desto schneller kann der Mythos von der schlechten Performance zerschlagen werden.