Die Prüfung materialisierter Ansichten umfasst die Ermittlung der vorhandenen materialisierten Ansichten, die benutzt werden können, um die Abfrage teilweise oder ganz zu berechnen.
Sobald eine materialisierte Ansicht mit Teilen einer Abfrage verglichen wurde, wird entschieden, ob die Ansicht im endgültigen Abfrageausführungsplan verwendet wird. Diese Entscheidung beruht auf den Kosten. Die Rolle der Enumerationsphase besteht im Generieren von Plänen, welche die Ansichten enthalten, die vom Algorithmus für die Ansichtenübereinstimmung empfohlen wurden. Außerdem besteht die Rolle darin, aufgrund der geschätzten Kosten des Plans den besten Zugriffsplan auszuwählen, der möglicherweise einige der materialisierten Ansichten enthält.
Falls die materialisierte Ansicht als eine "grouped-select-project-join"-Abfrage definiert ist (auch bezeichnet als gruppierte Abfrage bzw. eine Abfrage, die eine GROUP BY-Klausel enthält), kann der Algorithmus für die Ansichtenübereinstimmung sie mit gruppierten Abfrageblöcken vergleichen. Falls eine materialisierte Ansicht als eine "select-project-join"-Abfrage definiert ist (also keine gruppierte Abfrage ist), kann der Algorithmus für die Ansichtenübereinstimmung sie mit Abfrageblöcken eines beliebigen Typs vergleichen.
In der folgenden Aufstellung werden die Bedingungen aufgeführt, die der Algorithmus für die Ansichtenübereinstimmung benötigt, um zu ermitteln, ob eine Ansicht (V) mit einem Teil des Abfrageblocks (QB) übereinstimmt, der zu einer Abfrage (Q) gehört. Allgemein muss V eine Teilmenge der Tabellen des QB der Anfrage enthalten. Die einzige Ausnahme sind die Erweiterungstabellen von V. Eine Erweiterungstabelle von V ist eine Tabelle, die genau eine Zeile mit dem Rest der Tabellen von V verknüpft. Eine Primärschlüsseltabelle ist beispielsweise eine Erweiterungstabelle, wenn ihr einziges Prädikat ein Equi-Join zwischen einer NOT-NULL-Fremdschlüsselspalte und ihrer Primärschlüsselspalte ist. Ein Beispiel einer materialisierten Ansicht, die eine Erweiterungstabelle enthält, finden Sie unter Beispiel 2: Übereinstimmende "grouped-select-project-join"-Ansichten.
Die beim Erstellen der materialisierten Ansicht V benutzten Optionswerte stimmen mit den Optionswerten der Verbindung überein, welche die Abfrage ausführt. Eine Liste der Optionen, die übereinstimmen müssen, finden Sie unter Einschränkungen bei materialisierten Ansichten.
Die letzte Aktualisierung der materialisierten Ansicht V überschreitet den Veraltungsschwellenwert nicht, der durch die Datenbankoption "materialized_view_optimization" oder durch die Klausel MATERIALIZED VIEW OPTIMIZATION, falls angegeben, in der SELECT-Anweisung festgelegt wurde. Siehe Veraltungsschwellenwert des Optimierers für materialisierte Ansichten einstellen.
Alle in V verwendeten Tabellen, möglicherweise mit der Ausnahme einiger Erweiterungstabellen von V, sind im QB vorhanden. Diese Gruppen gemeinsamer Tabellen werden ab jetzt als CT abgekürzt.
Keine der Tabellen in den CT ist in der Abfrage Q aktualisierbar.
Alle Tabellen in den CT gehören zur gleichen Seite eines Outer-Joins in QB (das heißt, sie befinden sich alle auf der bewahrten Seite des Outer-Joins oder alle auf der Nullwert-liefernden Seite eines Outer-Joins von QB).
Es ist entscheidbar, dass die Prädikate in V eine Untermenge jener Prädikate in QB bilden, die nur CT referenzieren. In anderen Worten, die Prädikate in V sind weniger restriktiv als diejenigen in QB. Ein Prädikat in QB, das genau mit einem Prädikat in V übereinstimmt, wird als übereinstimmendes Prädikat bezeichnet.
Jeder Ausdruck von QB, der Tabellen in CT referenziert, die nicht in einem übereinstimmenden Prädikat benutzt werden, muss in der Auswahlliste von V vorkommen.
Wenn sowohl V als auch QB gruppiert sind, enthält QB keine anderen Tabellen als diejenigen in CT. Außerdem muss die Menge von Ausdrücken in der GROUP BY-Klausel von V gleich der Menge von Ausdrücken in der GROUP BY-Klausel von QB oder eine Obermenge davon sein.
Falls sowohl V als auch QB nach einer identischen Menge von Ausdrücken gruppiert sind, müssen alle Aggregatfunktionen in QB auch in V berechnet werden. Es ist jedoch auch möglich, sie aus den Aggregatfunktionen von V zu berechnen. Falls QB beispielsweise AVG(x) enthält, dann muss V ebenfalls AVG(x) enthalten oder es muss sowohl SUM(x) als auch COUNT(x) enthalten.
Falls die GROUP BY-Klausel von QB eine Teilmenge der GROUP BY-Klausel von V ist, müssen die einfachen Aggregatfunktionen von QB in den Aggregatfunktionen von V vorhanden sein, während die zusammengesetzten Aggregatfunktionen von QB aus einfachen Aggregatfunktionen von V berechnet werden müssen. Die einfachen Aggregatfunktionen sind:
Aus den einfachen Aggregatfunktionen können folgende zusammengesetzte Aggregatfunktionen berechnet werden:
Die statistischen Aggregatfunktionen:
können aus folgenden einfachen Aggregatfunktionen berechnet werden:
wobei x1 = CAST(IFNULL(x, x,y) AS DOUBLE)) und y1 = CAST(IFNULL(y,y,x) AS DOUBLE) sind.
 |
Kommentieren Sie diese Seite in DocCommentXchange.
|
Copyright © 2010, iAnywhere Solutions, Inc. - SQL Anywhere 12.0.0 |