Sie haben vielleicht Anwendungen, die Abfragen enthalten, die mit Verknüpfungen konstruiert sind, die mehr als ein Verknüpfungsvergleichselement zum Verknüpfen zweier Tabellen haben. Das mag zwar kompliziert klingen, aber eine solche Situation ist nicht ungewöhnlich, wenn Sie versuchen, die Abhängigkeiten zwischen ähnlichen, in Beziehung stehenden Spalten zwischen Tabellen festzustellen.
Zum Beispiel produziert ein Hersteller Produkte aus Rohmaterial verschiedener Farben, Elastizitäten und Qualitäten. Das fertige Produkt hat dieselbe Farbe und Elastizität wie das Rohmaterial, aus dem es hergestellt ist. Der Hersteller führt die folgende Abfrage aus:
SELECT PRODUCT.NAME, RAWMATERIAL.QUALITY FROM PRODUCT, RAWMATERIAL WHERE PRODUCT.COLOR = RAWMATERIAL.COLOR AND PRODUCT.ELASTICITY = RAWMATERIAL.ELASTICITY
Diese Abfrage liefert die Namen und die Qualität des Rohmaterials aller Produkte. Zwei Vergleichselemente werden für die Verknüpfung verwendet:
PRODUCT.COLOR = RAWMATERIAL.COLOR PRODUCT.ELASTICITY = RAWMATERIAL.ELASTICITY
Beim Auswählen eines Plans zur Ausführung dieser Abfrage berechnet das DB2-UDB-Optimierungsprogramm die Selektivität der beiden Vergleichselemente und nimmt an, daß die Vergleichselemente unabhängig sind, d. h., daß alle Variationen von Elastizität für jede Farbe vorkommen und umgekehrt für jede Elastizitätsstufe Rohmaterial in jeder Farbe verfügbar ist. Anschließend verwendet es Statistiken über die Anzahl der in jeder Tabelle vorhandenen Elastizitätsstufen und verschiedenen Farben, um die Gesamtselektivität des Vergleichselementpaares zu berechnen. Aufgrund dieser Berechnungen kann es beispielsweise eine Verknüpfung über Verschachtelungsschleife (Nested Loop Join) einer Mischverknüpfung (Merge Join) vorziehen oder umgekehrt.
Es kann jedoch vorkommen, daß diese beiden Vergleichselemente nicht unabhängig sind. Zum Beispiel könnte es der Fall sein, daß die hochelastischen Materialien nur in wenigen Farben verfügbar sind und die sehr wenig elastischen Materialien nur in einigen anderen Farben (die sich von den elastischen unterscheiden) verfügbar sind. In diesem Fall ist die kombinierte Selektivität der Vergleichselemente geringer (eliminiert weniger Zeilen), so daß die Abfrage mehr Zeilen liefert. Betrachten Sie zum besseren Verständnis dieses Sachverhalts einmal den extremen Fall, daß es nur eine Stufe von Elastizität für jede Farbe gibt und umgekehrt. Hier könnte jedes der beiden Vergleichselemente logisch ganz weggelassen werden, da es vom jeweils anderen impliziert wird. Die Planauswahl des Optimierungsprogramms ist vielleicht nicht mehr optimal. Es ist beispielsweise möglich, daß ein Plan mit Verknüpfung über Verschachtelungsschleife ausgewählt wird, aber die Mischverknüpfung schneller wäre.
Bei anderen Datenbankprodukten versuchten Datenbankadministratoren dieses Leistungsproblem dadurch in den Griff zu bekommen, daß sie Statistiken im Katalog aktualisierten, um eines der Vergleichselemente weniger selektiv erscheinen zu lassen, jedoch kann dieses Vorgehen zu unerwünschten Nebeneffekten bei anderen Abfragen führen.
Das Optimierungsprogramm von DB2 UDB versucht, eine Korrelation von Verknüpfungsvergleichselementen zu entdecken und zu kompensieren, wenn Sie folgende Maßnahmen ergreifen:
Im obigen Beispiel sollten Sie einen eindeutigen Index definieren, der folgende Spaltenpaare abdeckt. Entweder:
PRODUCT.COLOR, PRODUCT.ELASTICITY
oder
RAWMATERIAL.COLOR, RAWMATERIAL.ELASTICITY
oder beide.
Damit eine Korrelation erkannt werden kann, müssen die Nicht-INCLUDE-Spalten dieses Index ausschließlich korrelierte und keine anderen Spalten sein. Der Index kann wahlfrei INCLUDE-Spalten enthalten.
Im allgemeinen kann es mehr als 2 korrelierte Spalten in Vergleichselementen zur Verknüpfung geben, so daß sicherzustellen ist, daß ein eindeutiger Index für alle von ihnen definiert wird.
In vielen Fällen bilden korrelierte Spalten innerhalb einer Tabelle den Primärschlüssel der Tabelle. Ein Primärschlüssel ist immer eindeutig, so daß bei Vorhandensein eines Primärschlüssels über die korrelierten Spalten kein weiterer eindeutiger Index mehr definiert werden muß.
Stellen Sie anschließend sicher, daß die Tabellenstatistiken aktuell sind und nicht aus irgendeinem Grund (z. B., um das Optimierungsprogramm zu beeinflussen) von den wahren Werten abweichend geändert wurden.
Das Optimierungsprogramm verwendet die FIRSTnKEYCARD- und FULLKEYCARD-Informationen der Statistikdaten für eindeutige Indizes, um Fälle von Korrelation zu erkennen und die errechneten kombinierten Selektivitäten der korrelierten Vergleichselemente dynamisch anzupassen, um so eine realistischere Schätzung der Größe und des Aufwands der Verknüpfung zu erhalten.
Zusätzlich zur JOIN-Vergleichselementkorrelation ist das Optimierungsprogramm auch für die Korrelation mit einfachen gleichen Vergleichselementen der Art COL = "constant" (konstant) verantwortlich. Stellen Sie sich beispielsweise eine Tabelle mit verschiedenen Arten von Fahrzeugen vor, die alle über die Spalten HERSTELLER, MODELL, AUSFÜHRUNG (d. h. Limousine, Kombi, Sport- oder Nutzfahrzeug), JAHR und FARBE verfügen. Vergleichselemente in der Spalte FARBE sind wahrscheinlich von denen in den Spalten HERSTELLER, MODELL, AUSFÜHRUNG oder JAHR unabhängig, da die meisten Hersteller dieselben Standardfarben für alle ihre Modelle und Ausführungen in jedem Jahr verfügbar machen. Die Vergleichselemente HERSTELLER und MODELL sind jedoch in keinem Fall unabhängig voneinander, da nur jeweils ein Fahrzeughersteller ein Modell mit einem bestimmten Namen produziert. Identische Modellnamen, die von zwei oder mehr Fahrzeugherstellern verwendet werden, sind sehr unwahrscheinlich und mit Sicherheit von den Fahrzeugherstellern nicht gewollt. Wenn für die beiden Spalten HERSTELLER und MODELL ein Index vorhanden ist, verwendet das Optimierungsprogramm die Statistikdaten aus diesem Index, um die kombinierte Zahl an unterschiedlichen Werten festzustellen und die Selektivitäts- oder Kardinalitätsschätzung für die Korrelation zwischen diesen beiden Spalten anzupassen. Für Vergleichselemente, die keine Verknüpfungsvergleichselemente sind, muß kein eindeutigen Index vorhanden sein, damit das Optimierungsprogramm Anpassung vornehmen kann.