Hallo, in diesem Video geht es um das Fünf-Ebenen-Modell eines Datenmark-Management-Systems. Das Fünf-Ebenen-Modell beschreibt die Funktion der einzelnen Komponenten eines Datenmark-Management-Systems. Die einzelnen Komponenten können diesen Ebenen zugeordnet werden,

ausgehend von der Benutzerschnittstelle über das Zugriffssystem bis hin zum Speichersystem und damit zur Schnittstelle zum Betriebssystem. Bei der Verarbeitung eines SQL-Befehls werden alle fünf Ebenen durchlaufen. Beginnen wir mit der obersten der Benutzerschnittstelle.

Die erste Ebene beinhaltet vier Komponenten. Der Input-Out-Prozessor nimmt die SQL-Befehle des Benutzers entgegen. In der Regel liegt ein SQL-Befehl als Zeichenkette vor. Der PASA ist dann dafür zuständig, diese Zeichenkette zu analysieren

und die zugehörigen Schlüsselwörter zu identifizieren. Dadurch kann die Syntax des SQL-Befehls überprüft werden. Wenn beispielsweise das Schlüsselwort from nicht gefunden wird, dann meldet der PASA eine Fehlermeldung,

die durch den Input-Out-Prozessor an den Nutzer weitergegeben wird. Syntaktisch korrekte SQL-Befehle werden an den Precompiler weitergereicht. Der Precompiler prüft dann, ob die auftretenen Attribute und Tabellenbezeichnungen auch im Data Dictionary vorhanden sind.

Falls nicht, wird auch wieder über den Input-Output-Prozessor eine Fehlermeldung generiert. Nach Passierenden des Precompilers erfolgt die Autorisierungskontrolle. In dem Fall wird geprüft, ob der Nutzer die Zugriffsrechte hat

auf die angefragten Relationen und Tabellen. Ist diese nicht erfolgreich, beispielsweise wenn eine Lageraushilfe einen Kunden ändern möchte, so wird auch wieder eine Fehlermeldung generiert und an den Nutzer zurückgemeldet. Änderungsoperationen werden im Update-Prozessor in der zweiten Ebene weiterverarbeitet,

während Anfragen in dem Queer-Prozessor weiterverarbeitet werden. Beide Prozessoren lösten Sichten auf und transformieren die SQL-Statements in die Relationale Algebra. Dieses Beispiel zeigt die Überführung einer deklarativen Anfrage

auf einem View Kunden-Video Dortmund in einem algebraischen Ausdruck. Als erstes wird die zugehörte Sicht aufgelöst durch Nutzung der Basistabellen. Wir halten damit eine Join-Operation auf dem beiden Tabellen Kunden- und Warenkorb.

Anschließend wird diese Anfrage in die Relationale Algebra überführt. Der Projektion entspricht die Aufnahme eines Attributs in die Select-Klausel, während der Selektion in der Relationale Algebra eine Bedingung in der Wehrklausel entspricht.

Im Anschluss an die Transformation in die Relationale Algebra werden die Integritätsregeln überprüft. Das können sowohl statische Integritätsbedingungen sein wie eine Checkklausel oder auch dynamische Integritätsbedingungen in einem Trigger.

Nun ist geklärt, was gemacht werden soll. Im nächsten Schritt geht es jetzt darum zu entscheiden, wie der SQL-Befehl umgesetzt werden soll. Als erstes werden Zugriffspläne erstellt. Durch einen Zugriffsplan wird beschrieben, wie auf ein Datenbankobjekt zugegriffen werden kann,

beispielsweise über die Nutzung von Indexen oder eines Instead-of-Triggers. Im Anschluss daran erfolgt die Optimierung. Darauf aufbauend wird ein Ausführungsplan erstellt für die Umsetzung des SQL-Befehl.

Die Optimierung ledet sich in zwei Schritten. Einmal die logische Optimierung und einmal die physische Optimierung, die nacheinander ausgeführt werden. Bei der logischen Optimierung wird eine möglichst optimale Ausführungsreihenfolge der relationalen Operationen gesucht.

Soll beispielsweise zuerst eine Projektion erfolgen oder erst die Selektion ausgeführt werden. Bei der physischen Optimierung geht es darum, eine möglichst effiziente Umsetzung dieser relationalen Operationen zu finden.

Dazu gehört, dass entschieden wird, ob über ein Index auf einen Tupel zugegriffen werden soll oder nicht. Das Ergebnis der Optimierung ist der Ausführungsplan. Der Ausführungsplan kann mit dem Schlüsselwort Explain angezeigt werden.

Im SQL-Developer kann der Ausführungsplan über ein Icon abgefragt werden. Alternativ kann der Ausführungsplan auch über den Befehl Explain Plan 4 erzeugt werden. Dieser wird in einer separaten Tabelle gespeichert und kann über einen zweiten Select-Befehl abgefragt werden.

In beiden Fällen erhalten Sie eine Übersicht, wie dieses Statement ausgeführt werden soll. In diesem Beispiel sollen alle Kunden gefunden werden, deren Nachname mit M beginnt. Der Ausführungsplan zeigt, dass dafür ein Full-Table-Scan durchgeführt wird.

Jedes Tupel der Tabelle Kunde wird ausgelesen und geprüft, ob dieses Tupel die Selektionsbedingung erfüllt, also ob der Nachname mit M beginnt. Mit den Informationen aus dem Ausführungsplan kann jetzt der zugehörige Zugriffscode erzeugt werden,

die ursprünglich deklarative Anweisung ist damit überführt worden in eine prozedurale Algorithmus. Die Ausführung eines solchen Programms erfolgt durch die SQL Execution Engine des Datenbank-Management-Systems.

Die Ausführung eines Datenbank-Programms ist noch etwas komplexer, weil neben dem SQL-Compiler auch der zugehörige PLSQL-Compiler für das Datenbank-Programm benötigt wird. Das Datenbank-Programm wird durch den PLSQL-Compiler übersetzt in einen Bytecode.

Bei der Übersetzung wird gleichzeitig der SQL-Compiler aufgerufen, um die Befehle zu passen. Zur Laufzeit wird dann aus der PLSQL-Laufzeitumgebung wiederum der SQL-Compiler aufgerufen und der SQL-Ausführungsplan durch die SQL Execution Engine ausgeführt

und die Ergebnisse an die PLSQL-Laufzeitumgebung zurückgegeben. In der dritten Ebene haben wir Mengen von Tupeln betrachtet. Der Zugriff auf die einzelnen Tupeln erfolgt aber über den Zugriff auf Datensätze.

Deshalb ist die vierte Ebene rekordorientiert. Ein Rekord ist nichts anderes als ein Datensatz. In der vierten Ebene finden sich einmal die Transaktionsverwaltung. Die Transaktionsverwaltung stellt sicher, dass Änderungen parallel ausgeführt werden können, ohne dass es zu Fehlern kommt.

Der Scheduler bestimmt den nächsten Auftrag, das heißt, welche Transaktion darf als nächstes eine Änderung durchführen. Und der Recovery Manager ist für das Logging und das Recovery nach Systemausfällen zuständig.

In der fünften Ebene sind wir dann auf der Ebene der einzelnen Datenseiten. Der Puffer Manager entscheidet, welche Seiten benötigt werden, um eine Abfrage auszuführen. Während der Data Manager den Pufferinhalt physikalisch in die Datenbasen, also in die zugrunde liegenden Dateien, hineinschreibt oder per rausholt.

Zusammenfassend haben wir die fünf Ebenen betrachtet eines Datenbankmanagementsystems. Jede dieser Ebenen beschreibt bestimmte Funktionalitäten, die durch das Datenbankmanagementsystem ausgeführt werden,

um aus einem deklarativen SQL-Befehl eine Folge von Datenoperationen zu erhalten. Hier sehen Sie noch eine Übersicht der verwalteten Objekte in der jeweiligen Ebene, bei der mengenorientierten Schnittstelle.

Da geht es dann um Relation und Sichten. Während in der satzorientierten Schnittstelle, das wäre dann die vierte Ebene, es darum geht, welche Sätze gesucht und gespeichert werden. Hier finden sich dann auch die Indexstrukturen. In der fünften Ebene geht es dann um die zugehörenden Seiten, mit denen der Data Manager und der Puffer Manager arbeiten.

Der Data Manager verwaltet damit dann auch die Schnittstelle zum Betriebssystem bei dem Zugriff auf die Dateien und die Blöcke in den Datenbasen,

während die einzelnen Zylinder und Spuren auf den Sekundärspeicher durch das Betriebssystem selber verwaltet werden.