Materialisierte-Sicht

Das Konzept der materialisierten Sichten (engl. Materialized View oder Summary Table) gehört zu dem Konzept der Sichten, die sich, wenn nach der Persistenz der abgeleiteten Daten klassifiziert wird, in die beiden Varianten virtuelle und materialisierte Sichten differenzieren. Bei den materialisierten Sichten werden die abgeleiteten Sichtdaten explizit persistent gespeichert. Im Prinzip sind materialisierte Sichten normale Tabellen, in denen das Ergebnis der Sichtanfrage abgelegt wird. Beim Erstellen oder auch später vor der ersten Anfrage werden die Ableitungsvorschriften (SELECT-Ausdruck, Berechnungsvorschrift) der materialisierten Sichten ausgewertet und die materialisierte Sicht mit Daten gefüllt. Nach diesem ersten Füllen stehen dann verschiedene Wege offen, wie diese redundant gespeicherten Daten aktualisiert werden können: entweder durch eine vollständige Rematerialisierung des gesamten Datenbestands oder auf inkrementellen Wege durch eine sogenannte Änderungspropagierung, bei der nur die Änderungen der Tabellendaten auf den redundaten Sichtdaten fortgeschrieben werden.

  • Von Vorteil ist, dass Anfragen an die materialisierte Sicht genauso schnell sind wie Anfragen an eine Tabelle. Bei den virtuellen Sichten ist das anders. Dort wird bei jeder Anfrage die SELECT-Anfrage der Sichtdefinition erneut ausgewertet, was unter Umständen sehr viel Zeit beanspruchen kann.
  • Entscheidender Nachteil materialiserter Sichten ist die redundante Datenspeicherung, einmal in den der Sichtdefinition zugrunde liegenden Tabellen und einmal in der materialisierten Sicht. Es treten Konsistenzprobleme in beiden Richtungen auf. Zum Einen müssen Manipulationen (INSERT, UPDATE, DELETE?) auf den Tabellendaten fortgeschrieben werden auf die Daten der materailisierten Sicht. Dieses Problem wird als Änderungspropagierung bezeichnet (s.u.). Da in SQL aber auch Manipulationsanweisungen auf Sichten ausgeführt werden können, tritt zum Anderen auch das umgekehrte Problem auf, dass Änderungen von Sichtdaten übetragen werden müssen auf die zugehörigen Änderungen von Tabellendaten. Dieses Problem wird auch als View Updating-Problem bezeichnet.

Erstellt werden materialisierte Sichten mittels des CREATE-MATERIALIZED-VIEW (Oracle).

Teilweise sehr unterschiedliche Konzepte der MVs sind bei ORACLE als MATERIALIZED VIEW bzw. bei DB2 als SUMMERIZED TABLE realisiert, bei denen nur sehr eingeschränkte SELECT-Anfragen zugelassen sind. lm SOL-Standard ist kein MV-Konzept definiert.

Materialisierte Sichten im Data Warehouse (DWH)

Materialisierte Sichten bieten sich zur Vereinfachung der Anfrageformulierung an. Vor allem für Anfragen, die eine Vielzahl gleicher oder ähnlicher Anfragen auf immer denselben Relationen durchführen, wie z.B. bei einem Data Warehouse, empfiehlt sich die Einführung von Sichten zur Vereinfachung der Anfrageformulierung. Bei einem Data Warehouse beinhalten die Anfragen weiterhin zu einem großen Teil lesenden Zugriff auf einen stabilen Datenbestand, so dass eine Materialisierung der Sichten dadurch als sinnvoll erscheint, weil demzufolge der Berechnungsaufwand für häufig wiederkehrende Anfrageteile reduziert werden kann. Der Aufwand für eine Aktualisierung der Sichten ist aus dem Grund, dass die die Daten eher selten geändert werden, eher gering. Mit materialisierten Sichten sind drei bedeutende Problembereiche verbunden:

  • die Anfrageersetzung: das Umschreiben der originalen Anfrage muss derart erfolgen, dass anstelle der ursprünglich genutzten Basisrelationen eine oder mehrere materialisierte Sichten genutzt werden.
  • die Auswahl materialisierter Sichten: es muss abgewogen werden, ob der Nutzen der reduzierten Antwortzeiten durch materialisierte Sichten den Aufwand von zusätzlichem Speicherbedarf für redundante Daten sowie Verwaltungsaufwand rechtfertigt.
  • die Wartung materialisierter Sichten: Änderungen der Basisrelationen durch eine Neuberechnung oder Propagierung der Änderungen müssen in die Sichten eingepflegt werden.

Anfrageprogrammierung mit materialisierten Sichten

Durch die Bereitstellung vorberechneter (Teil-)Ergebnisse sollen die Antwortzeiten verkürzt werden. Daher ist es die Aufgabe bei einer vorhandenen materialisierten Sicht (M), eine Anfrage (A) derart in eine andere äquivalente Anfrage (A‘) umzuformulieren, die zwar das gleiche Ergebnis liefert wie die Anfrage (A), dabei jedoch eine materialisierte Sicht (M) nutzt. Dabei ist es nicht zwingend notwendig, dass die materialisierte Sicht genau der eigentlichen Anfrage entspricht. Sie kann auch eine Obermenge der Daten oder auch erst durch einen nachträglichen Verbund die geforderten Daten liefern. Hierbei ergeben sich zwei grundlegende Problemstellungen:

  • Query Containment: die Frage nach der Existenz einer Anfrageersetzung
  • Query Rewriting: die eigentliche Anfrageumformulierung

Eine materialisierte Sicht ist grundsätzlich durch eine Anfrage definiert. Daher kann die Frage der Ersetzbarkeit auf das Problem des Enthaltenseins (Query-Containment-Problem) von Anfragen zurückgeführt werden. Für die Ersetzung von materialisierten Sichten genügt offensichtlich das Enthaltensein-Kriterium, da nachfolgende Anfrageoperationen auf der materialisierten Sicht (sogenannte Kompensationsanfragen) durchaus möglich sind. Ein Nachteil des Query-Containment-Problems ist es aber, dass es für beliebige relationale Kalküle bzw. Anfragen in Relationenalgebra nicht entscheidbar ist. Für die Ersetzbarkeit muss eine Reihe von Bedingungen erfüllt sein, die für die Auswahl und Definition geeigneter Materialisierungen von Bedeutung sind:

  • Kompatibilität der Prädikate: bei einer Anfrage darf das Selektionsprädikat (z.B. <, ≤, >, ≥) nicht restriktiver (einschränkender) sein als das Prädikat aus der Sichtdefinition.
  • Verträglichkeit von Gruppierungen: im Fall von GROUP BY-Anfragen sollte es keine funktionalen Abhängigkeiten zwischen den Gruppierungsattributen geben sollte (Ableitbarkeit der Gruppierungskombinationen).
  • Verträglichkeit von Aggregatfunktionen: materialisierte Sichten sollen nur distributive Aggregatfunktionen beinhalten, z.B. additive Funktionen wie SUM und COUNT sowie semi-additive Funktionen wie MIN und MAX). Eine Anfrage könnte dann z.B. die in einer materialisierten Sicht über sum gebildete Summe oder die mit count errechnete Anzahl mit der AVG–Funktion nutzen.
  • Menge der Basisrelationen: im Allgemeinen gilt, dass mindestens die Relationen, die in der materialisierten Sicht verwendet werden, auch in der Anfrage mit identischen Verbundbedingungen referenziert werden.

Berücksichtigt man die oben angegebenen Kriterien für die Ersetzbarkeit, so ist das eigentliche Umschreiben im Wesentlichen ein Such- bzw. Optimierungsproblem.

Die richtige Auswahl der zu materialisierenden Anfrageteile ist eine weitere wichtige Aufgabe bei der Verwendung materialisierter Sichten. Zu berücksichtigen ist hierbei, dass einerseits ein Gewinn durch das Einsparen der erneuten Berechnung erzielt werden kann, andererseits aber ein zusätzlicher Aufwand in Form von Speicherplatz aufgrund der Redundanzen sowie der Aktualisierung bei Änderungen der Basisrelationen entstehen kann. Dies erfordert aber auf der einen Seite Kenntnisse über die auszuführenden Anfragen (den Workload) und auf der anderen Seite die Berücksichtigung der Ersetzbarkeit bzw. Ableitbarkeit der einzelnen Anfrageteile (z.B. die Additivität von Aggregatfunktionen oder die Ableitbarkeit von Gruppierungskombinationen).

Aktualisierung materialisierter Sichten

Um die Anfrageperformance zu verbessern, werden mit materialisierten Sichten ganz bewusst Redundanzen eingeführt. Damit ergeben sich jedoch vorrangig Probleme bei Manipulationen auf den Basisrelationen (Tabellen), so dass eigentlich semantisch gleiche Anfragen, mal auf Tabellen und mal auf materialisierten Sichten formuliert, durchaus unterschiedliche Ergebnisse liefern können. Jede Änderung der Basisrelation kann eine Neuberechnung anstoßen, was allerdings sehr aufwändig ist und was ja gerade durch die Einführung materialisierter Sichten möglichst verhindert werden soll. Aus diesem Grund werden effiziente Aktualisierungsverfahren benötigt, die auf einer inkrementellen Änderungspropagierung basieren. Grundannahme bei einer inkrementellen Änderungspropagierung ist, dass der gegebene Datenbestand korrekt ist und dass nur die Änderungen nachgepflegt werden. Eine Basisänderung wird also direkt in eine Änderung der Sicht umgerechnet.

Art der Aktualisierung:

Somit stehen zwei Varianten der Aktualsierung der Sichtdaten zur Verfügung:

  • Vollständige Aktualisierung: eine vollständige Neuberechnung ist der naheliegende Ansatz einer Aktualisierung materialisierter Sichten, was leider sehr aufwändig werden kann. Die gemeinsame Aktualisierung mehrerer Sichten kann eine Verbesserungsmöglichkeit sein: man versucht zunächst einen gemeinsamen Vorgänger mit einer minimalen Extension zu finden und anschließend darauf aufbauend die eigentlichen Sichten zu berechnen.
  • Inkrementelle Aktualisierung: das Ziel ist die Vermeidung des Aufwandes für eine Neuberechnung der Sicht. Zwei Schritte sind hier notwendig:
1. Identifizierung der geänderten Detaildaten, z.B. über Trigger oder deren Protokollierung speziellen in LOG-Dateien.
2. Änderungen sind anschließend in den materialisierten Sichten nachzuvollziehen.

Es werden vier möglichen Zeitpunkte für eine Aktualisierung der Sichtdaten diskutiert, wobei sich die Zeitpunkte "sofort", "zum COMMIT", "auf Anfrage" aufgrund des großen Aufwands nicht wirklich eigenen für eine vollständige Aktualisierung. Somit bleibt als einziger sinnvoller Zeitpunkt eine vollständige Aktualisierung der zu einem konkreten Termin "verzögerte" Zeitpunkt. Für die inkrementelle Aktualisierung sind drei der vier Zeitpunkte gut geeigent und je nach Anforderung aus der Anwendung heraus zu wählen.

Vier Zeitpunkte möglicher Aktualisierungen:

  • sofort (synchron): Hier würde unmittelbar nach einer Manipulationsanweisung die geänderten Daten propagiert, was zur Folge hätte, dass auch Manipulationen, die noch nicht "commited" wurden, die also noch nicht mittels COMMIT-Anweisung persistent in der Datenbasis gespeichert wurden, in die Sicht übertragen würde. (vgl. Transaktion) Dies ist vor allem dann problematisch, wenn die Transaktion mit einem ROLLBACK abgeschlossen wird.
  • zum COMMIT-Zeitpunkt: Wird eine Transaktion mit COMMIT persist in den Tabellen gespeichert, dann werden die Änderungen zu den Sichten übertragen.
  • verzögert: Hierbei wird ein Termin für die Aktualisierung angegeben, der dann periodisch wiederholt werden kann. Z.B. die erste Aktualsierung am Sonntag 08.08.2010 um 5:00h und eine Wiederholung alles 7 Tage.
  • auf Anfrage: Stellt ein Anwender eine Anfrage an die Sicht, wird erst einmal nachgeschaut, ob die Sichtdaten noch aktuell sind, wenn ja, dann wird die Anfrage ausgewerte auf den Sichtdaten, wenn nicht, dann werden erst die Sichtdaten aktualisiert und dann die Anfrage erst beantwortet. Diese Variante ist sicherlich nicht so praktikabel, da materialisierte Sichten ja eigentlich deshalb eingesetzt werden, um Anfragen zu beschleunnigen, und hier muss dann erst noch die Aktualisierung abgewartet werden.

Die daraus resultierende Aufgabe ist es daher, die Sichtänderung zu bestimmen. Die Verfahren zur Ableitung der resultierenden Sichtänderungen, die Einfluss auf die Effizienz der Aktualisierung haben, lassen sich bezüglich einiger wesentlicher Faktoren klassifizieren:

  • die zur Verfügung stehenden Informationen: Welche Informationen müssen über die Sichtdefinition und den Inhalt der Sicht hinaus noch verfügbar sein?
  • die verwendeten Anfragekonstrukte zur Definition der Sicht: Bestimmung, welche Anfrageoperationen in der Sichtdefinition für eine inkrementelle Aktualisierung erlaubt sind.
  • die unterstützten Änderungsoperationen: im einfachsten Fall ist dies die Beschränkung auf Einfüge-/Löschoperationen und die Abbildung von Änderungen auf diese beiden Operationen. Dies kann allerdings zu Informationsverlust führen und teure Zugriffe auf die Basisrelation erforderlich machen.
  • die Granularität der Aktualisierung: hier wird festgelegt, ob Sichten einzeln oder isoliert voneinander aktualisiert werden bzw. ob eine gemeinsame Aktualisierung mehrerer Sichten möglich ist (letzteres ist für die Konsistenz vorteilhafter).

Für die Inkrementelle Aktualisierbarkeit von Sichten sind die verfügbaren Informationen sowie die Anfragekonstrukte von Bedeutung. Selbstverständlich kann man durch Zugriff auf die Basisrelation das Problem lösen. Allerdings sind solche Änderungen meist mit hohen Kosten, sprich Änderungsaufwand, verbunden, so dass man versucht, diese durch die Nutzung von Zusatzinformationen zu vermeiden. Hierfür geeignete Informationen sind u.a.:

  • Schemainformation wie Primär- und Fremdschlüsselbedingungen,
  • Hilfssichten, die weitere Informationen materialisieren und damit eine autonome Aktualisierbarkeit ermöglichen,
  • counter zur Bestimmung der Anzahl von Tupeln in der Basisrelation, aus denen ein Tupel in der Sicht abgeleitet wurde.

Die letzte Variante wird beispielsweise im Counting-Algorithmus genutzt, auf den aber hier nicht weiter eingegangen wird.

Quellen:

  • ANSI/ISO/IEC 9075-1:2003. Part 1 "SQL/Framework", ISO International Organization for Standardization / ANSI American National Standards Institute, September 2003
  • ANSI/ISO/IEC 9075-2:2003. Part 2 "SQL/Foundation", ISO International Organization for Standardization / ANSI American National Standards Institute, Dezember 2003
  • Elmasri, Ramez/Navathe, Shamkant B.: "Grundlagen von Datenbanksystemen" , Pearson Studium, München, 2002, ISBN 3-8273-7021-3
  • Faeskorn-Woyke, Heide/Bertelsmeier, Birgit/Riemer, Petra/Bauer, Elena: "Datenbanksysteme - Theorie und Praxis mit SQL2003, Oracle und MySQL", Pearson Education, München, 2007, ISBN 978-3-8273-7266-6
  • Kemper, Alfons/Eickler, André: "Datenbanksysteme", Oldenbourg, München, 2009, 978-3-486-59018-0
  • Melton, Jim/Simon, Alan R.: "SQL: 1999 - Understanding Relational Language Components", Morgan Kaufmann, San Francisco, 2001, ISBN 1558604561
  • Oracle® Database SQL Language Reference 11g Release 2 (11.2), E17118-03, August 2010, http://download.oracle.com/docs/cd/E11882_01/server.112/e17118.pdf
  • Saake, Gunter/Sattler, Kai-Uwe/Heuer, Andreas: "Datenbanken - Konzepte und Sprachen", mitp-Verlag, Redline GmbH, Heidelberg, 2007, ISBN 3-8266-1664-2
  • Vossen, Gottfried: "Datenmodelle, Datenbanksprachen und Datenbankmanagementsysteme", Oldenbourg, München, 2008, ISBN 978-3-486-27574-2

Kategorien: SQL, M