Data Warehouse Technologien

SELECT ... FROM ...

WHERE kklasse=1 AND geschlecht=’m’ AND beruf=’Dozent’

Wird in der Anfrage einfach die Reihenfolge der Attribute geändert, hängt es

von der Güte des Optimierers ab, ob der Index genutzt werden kann oder nicht:

SELECT ... FROM ...

WHERE geschlecht=’m’ AND beruf=’Dozent’ AND kklasse=1

Deutlicher wird es bei Bereichsanfragen. Die Anfrage

SELECT ... FROM ...

WHERE kklasse=1 AND geschlecht=’m’ AND beruf>’Dozent’

kann effizient unterstützt werden, die folgende ähnliche Anfrage allerdings

nicht:

SELECT ... FROM ...

WHERE geschlecht=’m’ AND beruf=’Dozent’ AND kklasse>1

2

Ähnliches gilt für partielle Anfragen, wenn also nur zwei der drei Attribu-

te mit einem Suchwert belegt sind. Nur der Fall, dass die beruf unbekannt ist,

kann effizient unterstützt werden. In einem symmetrischen mehrdimensiona-

len Index würden diese Unterschiede nicht auftreten.

7.2.4 B

+

-Baum-Tricks: Oversized Index

Schon aus den klassischen relationalen Datenbank-Management-Systemen ist

bekannt, dass sich gewisse Anfragen effizient beantworten lassen, wenn alle

benötigten Daten aus dem Index ohne Zugriff auf die Hauptdatei gewonnen

werden können. Dort ist das Beispiel die Beantwortung von Projektionen auf

Basis von Indexen, die alle Projektionsattribute umfassen.

Eine ähnliche Technik liegt dem oversized index, auf Deutsch etwa „über-

großer Index“, zugrunde. Betrachten wir hierzu die folgende Anfrage:

SELECT AVG(alter)

FROM Kunde

WHERE kklasse=1 AND geschlecht=’m’ AND beruf=’Dozent’

Eine Indexnutzung würde klassischerweise das Suchen des Wertes

„1||m||Dozent“ mittels des bereits definierten Index csp

_

idx unterstützen,

um dann einen Zugriff auf den zugehörigen Block der Relation Kunde über die

TID auszuführen, um den Wert von alter zu lesen.

Besser wäre es, den folgenden „oversized“ Index anzulegen:

202 7 Indexstrukturen