exec SQL

4104
Aufgabe 1 (25 Punkte)
Ein relationales DBMS soll automatisch Änderungen an der Tabelle pruefungsergebnisse mit den
Schlüsselspalten matrikelnr, datum, fachnr und der einzigen weiteren Spalte zensur protokollieren. Es
soll festgehalten werden, wer wann welchen Datensatz wie ändert bzw. einfügt bzw. löscht.
Beschreiben Sie das verwendete Konzept, wählen Sie die für das Protokoll notwendige
Tabellenstruktur, die Rechte, die alle Benutzer an dieser Tabelle besitzen sollten und versuchen Sie,
das Konzept auch als SQL-Anweisung weitgehend angemessen umzusetzen.
Die Einträge können durch einen Trigger gespeichert werden. Trigger können dazu benutzt
werden, zusammen mit Einschränkungen Integritätsregeln zu unterstützen, automatisch
Datenkonvertierungen vorzunehmen, Warnungen zu erzeugen, Daten zugleich in andere
Tabellen (z.B. aggregierte Werte) einzutragen usw. Veränderungen sind INSERT, UPDATE,
DELETE.
Die Rechtevergabe erfolgt durch die Anweisung GRANT:
GRANT INSERT, UPDATE, DELETE ON pruefungsergebnisse
TO benutzer1
Sollen die Rechte an alle Benutzer vergeben werden, so werden sie an public statt
benutzer1 vergeben.
CREATE TABLE demo_protokoll
(
user
CHARACTER (10),
datum
date,
aenderung CHARACTER (6))
CREATE TRIGGER pruefungsergebnisse
AFTER UPDATE, INSERT, DELETE ON demo
oder or
FOR EACH ROW
WHEN INSERTED
BEGIN INSERT INTO demo_protokoll
VALUES (USER, CURRENT TIMESTAMP,"insert")
END
WHEN UPDATED
BEGIN INSERT INTO demo_protokoll
VALUES (USER, CURRENT TIMESTAMP,"update")
END
WHEN DELETED
BEGIN INSERT INTO demo_protokoll
VALUES (USER, CURRENT TIMESTAMP,"delete")
END
evtl. Achilles schicken, fragen, ob update, insert und delete-Trigger in einem geht.
Aufgabe 2 (15 Punkte)
Welche Vorteile bietet Hash als Zugriffsunterstützung, welche Nachteile sind mit dieser Methode
verbunden?
Hashing ist eine gut bekannte Technik für Direkt-Zugriffs–Dateien. Die Methode ist sehr
einfach und die Zeit zum Wiederauffinden eines Datensatzes ist sehr gering.
Grundoperationen, wie Einfügen und Löschen, sind keine aufwendigen und komplizierten
Verfahren und können zur Laufzeit im Normalfall auch sehr schnell durchgeführt werden.
Einer der großen Nachteile der statischen Hashverfahren ist die statische
Speicherplatzverwaltung. Die Größe der Datei muss im Voraus bekannt sein oder beurteilt
werden können, um einen physikalischen Speicher für die Datei zu reservieren. Die Größe
1
des bereitgestellten Speichers ist von einer festen Länge und kann nicht ohne
Reorganisation des gesamten schon bestehenden Files verändert werden. Wenn die
Speichernachfrage eines Files bei der Erstellung zu gering eingeschätzt wurde, dann gibt es
zwangsläufig eine hohe Zahl von Overflow–Einträgen, was die Suche nach einem Record
oder das Einfügen eines Records verlangsamt. Bei zu geringer Ausnutzung des Speichers
wird andererseits Speicherplatz verschwendet. So kommen wir zu dem Schluß, dass es sehr
schwer ist, eine angemessene Größe für ein File zu bestimmen, wenn die Größe dieses
Files großen Schwankungen in der Anzahl der Records unterlegen ist, d.h. die Größe sehr
dynamisch ist.
Der schnelle Zugriff ist möglich dadurch, dass durch eine einfache Berechnung des Schlüssels (z.B. i
mod 10) sofort zum Speicherplatz geführt wird.
[http://www.informatik.uni-ulm.de/dbis/f&l/lehre/SS99/ProseminarSS99/dynamicHashing.pdf]
Aufgabe 3 (15 Punkte)
Sie sollen eine Anwendung erstellen, die große Datenmengen in einer relationalen DB verändert. Diese Anwendung kann
nachts ohne weitere manuelle Eingriffe gefahren werden zu einer Zeit, wenn nur wenige weitere DB-Zugriffe erfolgen.
Wie können Sie diese Anwendung gegen Deadlock schützen?
Diskutieren Sie zunächst den Begriff "Deadlock". Wie kann ein Deadlock entstehen? Was bieten die DBMSe zum Schutz
gegen Deadlock an? Wie müssen Sie diese Vorkehrungen einsetzen?
Mit der Benutzung von Sperren ist ein Problem verbunden: wird in einer Transaktion ein
Objekt verändert und damit gesperrt, so kann eine andere Transaktion auf dieses Objekt erst
nach dem Ende der ersten Transaktion zugreifen. Was passiert aber, wenn eine andere
Transaktion auch ein Objekt ändert und somit sperrt und wenn die Transaktionen
wechselseitig auf die gesperrten Objekte der jeweils anderen Transaktion zugreifen wollen?
Dies ist die typische Verklemmung, auch Deadlock genannt. Erst das Abbrechen einer der
beteiligten Transaktionen mit der ROLLBACK-Anweisung gibt die vormals gesperrten Objekte
wieder frei, die verbleibenden Transaktionen können nun weiterarbeiten.
Die abgebrochene Transaktion muss zu einem späteren Zeitpunkt wiederholt werden.
Normalerweise sind Sperrmechanismen nicht notwendig, da SQL die Sperren automatisch
anfordert. Der Benutzer kann aber auch manuell Sperren setzen. Dies ist gerade bei
umfangreichen Transaktionen sehr nützlich. Eine Sperre kann vom Benutzer durch die
Anweisung
LOCK TABLE table_name [IN EXCLUSIVE MODE | IN SHARE MODE]
anfordern. Mit dem Zusatz IN EXCLUSIVE MODE ist Tabelle bis zur COMMIT- bzw.
ROLLBACK-Anweisung für alle anderen Benutzer gesperrt. Soll die Tabelle hingegen nur
zum Lesen gesperrt werden, so wird das bewirkt durch IN SHARE MODE.
Gerade bei eingebetteten SQL-Anweisungen in Programmen, in denen lange Transaktionen
aufgebaut werden, ist eine sorgfältige Prüfung des Zeitpunktes, zu dem die Sperren gesetzt
werde, und eine Analyse, welche Sperren aufgebaut werden müssen, zwingend erforderlich.
Zur schnelleren Ausführung der Abarbeitungen empfiehlen sich Batches.
Zum Schutz gegen Deadlocks bieten die DBMS'e weiterhin das optimistische
Synchronisationsverfahren an. Diese Systeme gehen von der Annahme aus, dass
Konflikte zwischen Transaktionen seltene Ereignisse darstellen und somit das präventive
Sperren der Objekte unnötigen Aufwand verursacht. Daher greifen diese Verfahren zunächst
nicht in den Ablauf einer Transaktion ein, sondern erlauben ein nahezu beliebig paralleles
Arbeiten auf der Datenbank. Erst bei Transaktionende wird überprüft, ob Konflikte mit
anderen Transaktionen aufgetreten sind. Gemäß dieser Vorgehensweise unterteilt man die
Ausführung einer Transaktion in drei Phasen:
- Lesephase
- Validierungsphase
2
- Schreibphase
In der Lesephase wird die eigentliche Transaktionsverarbeitung vorgenommen, d.h. es
werden Objekte der Datenbank gelesen und modifiziert. Jede Transaktion führt dabei ihre
Änderungen auf private Kopien in einem ihr zugeordneten Transaktionspuffer durch, der für
keine andere Transaktion zugänglich ist.
Validierungsphase
Im Gegensatz zu Sperrverfahren, bei denen Blockierungen das primäre Mittel zur
Behandlung von Synchronisationskonflikten sind, werden hier Konflikte stets durch
Zurücksetzen einer oder mehrerer beteiligter Transaktionen aufgelöst. Es ist so mit mehr
Rücksetzungen als bei Sperrverfahren zu rechnen; andererseits können bei
optimistischen Verfahren keine Deadlocks entstehen.
Hat die Transaktion die Validierungsphase erfolgreich durchlaufen - und nur in diesem Falle
- werden die gepufferten Änderungen zurückgeschrieben; Schreibphase! Dadurch werden
die Änderungen für andere Transaktionen erst sichtbar.
Aufgabe 4 (25Punkte)
Eine kleine Firma betreibt eine verteilte Datenbank. Das Lager ist auf zwei Orte aufgeteilt, die Lagerverwaltung wird
durch die Datenbank unterstützt. Die Arbeitsvorbereitung muss genau so wie die Abteilung Einkauf lesend auf diese Daten
zugreifen können. Alle vier Stellen sind örtlich getrennt und betreiben auf vernetzten Rechnern Datenbankknoten.
Während lesende und ändernde Zugriffe in den Lagern sehr hoch sind, ist in der Arbeitsvorbereitung zwar mit hohen
lesenden, jedoch wenigen ändernden Zugriffen zu rechnen, im Einkauf nur mit seltenen lesenden Zugriffen.
Schlagen Sie Maßnahmen zur Verteilung der Daten vor und begründen Sie Ihre Aussagen.
 Daten dort speichern, wo die meiste Bewegung ist. Lagerverwaltung als Server.
 2 Tabellen, die zum Gesamt-Lager zusammengeführt werden.
Punkt Verteilung
Vordergründig kann als Entwicklungsziel angesehen werden, die Fragementation und
Allokation so zu gestalten, dass bei der geplanten Applikation ein möglichst geringer
Datenstrom das Netz belastet, da in der Regel das Netz der limitierende Faktor sein wird.
Faktoren:
Art und Häufigkeit der Transaktionen an den verschiedenen Datenbankknoten,
die aufgrund der Transaktionen an den einzelnen Datenbankknoten benötigten
Daten – insbesondere auch Tabellenteile
limitierende Faktoren eines bestimmten Knotens: CPU-Leistung, Auslastung und
Größe des Hauptspeichers und Plattenplatz,
die Geschwindigkeit der Netzverbindungen,
die Zuverlässigkeit der Netzverbindungen,
Konsequenzen bei Ausfall eines bestimmten Knotens
Unterstützung der Einhaltung von Integritätsregeln bei verteilten Daten
Unterstützung verteilter Anfragen durch das VDBMS, insbesondere die Frage, ob
das verwendete VDBMS es erlaubt, dass Transaktionen automatisch
Subtransaktionen an entfernten Knoten starten können.
Punkt Replikation
Replikation verstößt gegen das Prinzip der Redundanzfreiheit. Man muss sich also fragen,
welche Gründe für eine Replikation bei verteilten DB-Anwendungen sprechen, d. h. für eine
redundante Datenhaltung, bei der Änderungen an die Knoten (transparent für den Benutzer
durch die beteiligten DBMS) weitergegeben werden. Im wesentlichen sprechen folgende
Gründe dafür:
die Lokalität von Anwendungen kann gewahrt bleiben, wenn alle Daten, die die
Anwendungen brauchen, vor Ort vorhanden sind; damit entfällt der langsame
Zugriff übers Netz,
3
-
-
die Verfügbarkeit des Gesamtsystems wird erhöht; auch wenn ein Knoten ausfällt,
können die Anwendungen auf den anderen Knoten weiterlaufen, da die benötigten
Daten repliziert sind,
die Performance des Gesamtsystems wird erhöht, da die Lese- und
Schreibzugriffe entzerrt werden (können)
Eine Aenderung dauert um ein Mehrfaches laenger als in einer lokalen Datenbank. Deshalb gilt die
Regel, dass nur Daten mit geringer Aenderungshaeufigkeit fuer eine redundante Speicherung
(Replikation) geeignet sind.
Aufgabe 5 (25 Punkte)
An einer Tabelle demo mit den Spalten
regal, ebene, fach, material, anzahl
sollen wiederholt innerhalb eines Programmlaufes bei vorgegebenen Werten für den Primärschlüssel regal, ebene,
fach Änderungen an der Anzahl oder auch an den Werten material, anzahl vorgenommen werden sowie bei
vorgegebenem Material die zugehörige Gesamtanzahl oder die Orte, an denen das Material vorkommt, bestimmt werden.
Dazu soll eine Java-Anwendung erstellt werden.
Ihre Aufgabe ist es, die wesentlichen Konzepte zu diskutieren sowie die Anwendung in ihren Grundzügen zu skizzieren.
Schnittstelle JDBC:
Da häufig dieselben Anfragen und Änderungen durchgeführt werden, empfiehlt sich die
wiederkehrenden SQL-Befehle in PreparedStatements zu formulieren. Der SQL-String wird
genau ein Mal vom Datenbanksystem geparst und auf seine Korrektheit geprüft. Bei jeder
Anfrage oder Änderung wird der Befehl nur noch mit konkreten Werten gefüllt.
Class.forName("jdbc.TreiberName");
Connection conn = DriverManager (url, "userid", "passwort");
PreparedStatement aendereDemo = conn.prepareStatement(
"UPDATE demo " +
"SET
material = ?
anzahl
= ?" +
WHERE
regal
= ?
AND ebene
= ?
AND fach
= ?
//Parameter mit Werten belegen
aendereDemo.setString
(1, "Schrauben");
aendereDemo.setInt
(2, 300);
aendereDemo.setString
(3, "Hochregal");
aendereDemo.setString
(4, "5");
aendereDemo.setString
(5, "07");
//update ausführen
int n = aendereDemo.executeUpdate();
-------------------------------------------------------PreparedStatement bestimmeDemo = conn.prepareStatement(
"SELECT SUM(anzahl) "+
"FROM demo" +
"WHERE Material = ?");
//Parameter 1 bestimmen
bestimmeDemo.setString(1, "Schrauben");
//SELECT ausführen
ResultSet ergebnisse = bestimmeDemo.executeQuery();
-------------------------------------------------------PreparedStatement bestimmeDemo = conn.prepareStatement(
4
"SELECT * FROM demo" +
"WHERE Material = ?");
//Parameter 1 bestimmen
bestimmeDemo.setString(1, "Schrauben");
//SELECT ausführen
ResultSet ergebnisse = bestimmeDemo.executeQuery();
-------------------------------------------------------//Auslesen der ergebnisse
while(ergebnisse.next())
int gesamtanzahl = ergebnisse.getInt(1); ???
System.out.println(gesamtanzahl);
-------------------------------------------------------while (ergebnisse.next())
String
regal
= ergebnisse.getString("regal");
String
ebene
= ergebnisse.getString("ebene");
String
fach
= ergebnisse.getString("fach");
System.out.println(regal +"; "+ ebene +"; "+fach);
Aufgabe 6 (25 Punkte)
Es gilt die gleiche Problematik wie in der vorherstehenden Aufgabe. Diesmal soll die Lösung jedoch mit Embedded SQL
erfolgen.
Ihre Aufgabe ist es, die wesentlichen Konzepte zu diskutieren sowie die Anwendung in ihren Grundzügen zu skizzieren.
An einer Tabelle demo mit den Spalten regal, ebene, fach, material, anzahl sollen wiederholt innerhalb
eines Programmlaufes bei vorgegebenen Werten für den Primärschlüssel regal, ebene, fach Änderungen an der
Anzahl oder auch an den Werten material, anzahl vorgenommen werden sowie bei vorgegebenem Material die
zugehörige Gesamtanzahl oder die Orte, an denen das Material vorkommt, bestimmt werden.
Sollen SQL-Anweisungen im Quelltext eingebettet werden, so muss ein Precompiler
verwendet werden, um daraus den entsprechenden Code zu generieren, der anschließend
vom Compiler verarbeitet werden kann. Die Einleitung (EXEC SQL) sowie das
Endekennzeichen (;) der SQL-Anweisung sind sprachabhängig. Um Datenübertragungen
zwischen SQL und Hostsprache möglich zu machen, werden Hostvariablen angelegt. Der
Precompiler erkennt sie durch denjenigen Programmabschnitt, der durch BEGIN DECLARE
SECTION eingeleitet wird und durch END DECLARE SECTION beendet wird. Der Precompiler
bearbeitet die Programmdatei mit den eingebetteten SQL-Anweisungen sequentiell. Trifft er
auf eine SQL-Anweisung, die er aufgrund der Einleitung erkennt, so liest er zunächst die
gesamte SQL-Anweisung bis zum Endekennzeichen ein und überprüft sie in
Zusammenhang mit dem Datenbanksystem. Die Aufgaben des Precompiler sind:




Syntaktische Prüfung der eingebetteten SQL-Anweisungen
(durch Übermittlung an das DBMS, das die Prüfung soweit möglich vorab vollzieht)
Logische Überprüfung der eingebetteten SQL-Anweisungen
(ebenfalls durch das DBMS): sind alle verwendeten Objekte (Tabellen, Indexe, Views
usw.) vorhanden?
Rechteüberprüfung, soweit zur Übersetzungszeit möglich
derjenige, der das Programm ausführt, ist in der Regel nicht derselbe, der das
Programm erstellt und übersetzt.
Ermittlung des optimalen Zugriffspfades und Speicherung in der DB
dies ist stark abhängig vom jeweiligen DBMS; eine Optimierung zur Übersetzungszeit
beschleunigt die Programmausführung solange die Objekte und die Verteilung der
Daten einigermaßen stabil bleiben; treten hier jedoch stärkere Schwankungen auf, so
sind Optimierungen zur Laufzeit trotz der anfallenden Kosten günstiger.
5

Übersetzung der eingebetteten SQL-Anweisungen in die entsprechenden
Quellcode-Anweisungen.
Da die Änderungen während des Programmlaufes erfolgen sollen, ist dynamisches SQL
einzusetzen. Möglich wäre z.B. eine interaktive Oberfläche in der die Änderungen vom
Benutzer eingegeben werden. Embedded SQL setzt aber normalerweise voraus, dass alle
Variablen während der Programmierung festgelegt wurden.
Es müssen daher Methoden bereitgestellt werden, Anweisungen, deren Quelltext erst
während der Programmausführung ermittelt wird, an das DBMS zu übergeben und
ausführen zu lassen. Die Ermittlung eines Zugriffspfades durch den Precompiler ist
ausgeschlossen, da der Wert nicht vor der Übersetzungszeit bekannt ist. Die Überprüfung
der Syntax sowie der Zugriffsrecht und Ermittlung des Zugriffspfades müssen vom DBMS
während der Laufzeit ausgeführt werden.
Zusätzlich sollen die Änderungen wiederholt möglich sein, d.h. dynamisch wird eine SQLAnweisung erzeugt, die ggf. Ein- oder Ausgabevariablen enthalten und mehrfach aufgerufen
werden soll. In diesem Fall muss die Vorbereitung von der Ausführung getrennt werden.
Hierzu sind die Anweisungen PREPARE zur Vorbereitung, EXECUTE zur Ausführung und
DELLOCATE PREPARE zur Freigabe der Ressourcen vorgesehen.
EXEC SQL BEGIN DECLARE SECTION;
material
char(10);
anzahl
Int;
regal char(10);
ebene char(10);
fach
char(10);
sumanzahl Int;
prep
char(18);
descriptorOut
char(18);
descriptorIn
char(18);
c1
char(18);
satz
char(512);
EXEC SQL END DECLARE SECTION;
…
EXEC SQL
UPDATE demo '
SET material = :material
anzahl
= :anzahl
WHERE
regal = :regal
AND
ebene = :ebene
AND
fach
= :fach;
satz = "SELECT material, anzahl, regal, ebene, fach
FROM demo
where material = ?";
EXEC SQL PREPARE prep FROM :satz;
EXEC SQL DECLARE c1 CURSOR FOR prep;
//Anlegen Descriptoren
EXEC SQL ALLOCATE DESCRIPTOR :descriptorOut;
EXEC SQL ALLOCATE DESCRIPTOR :descriptorIn
//Initialisieren Descriptoren
EXEC SQL DESCRIBE OUTPUT prep USING SQL DESCRIPTOR :descriptorOut;
EXEC SQL DESCRIBE INPUT prep USING SQL DESCRIPTOR :descriptorIn;
//die Eingabewerte in Descriptor Area füllen
material = "Schrauben";
EXEC SQL SET DESCRIPTOR :descriptorIn COUNT = 1;
EXEC SQL SET DESCRIPTOR :descriptorIn VALUE 1 TYPE 4???
6
EXEC SQL SET DESCRIPTOR :descriptorIn VALUE 1 DATA = :material;
//Cursor öffnen und einlesen
EXEC SQL OPEN c1 USING SQL DESCRIPTOR descriptorIn
/* Lese- und Verarbeitungsschleife mit: */
EXEC SQL FETCH c1 INTO SQL DESCRIPTOR descriptorOut;
EXEC SQL GET DESCRIPTOR descriptorOut VALUE 1 :material =
EXEC SQL GET DESCRIPTOR descriptorOut VALUE 2 :anzahl
=
EXEC SQL GET DESCRIPTOR descriptorOut VALUE 3 :regal
=
EXEC SQL GET DESCRIPTOR descriptorOut VALUE 4 :ebene
=
EXEC SQL GET DESCRIPTOR descriptorOut VALUE 5 :fach
=
;
...
; /* Ende der Lese- und Verarbeitungsschleife */
EXEC SQL CLOSE c1;
EXEC SQL DEALLOCATE PREPARE : prep;
EXEC SQL DEALLOCATE DESCRIPTOR descriptorOut;
EXEC SQL DEALLOCATE DESCRIPTOR descriptorIn;
EXEC SQL
DATA,
DATA,
DATA,
DATA,
DATA,
Eine mit PREPARE aufbereitete Anweisung wird mit EXECUTE zur Ausführung gebracht.
Dabei sind Ein- und Ausgabevariablen an die positionalen Parameter zu übergeben.
Was muss geschehen, um z.B. eine mit einem Cursor verbundene dynamisch
erzeugte SELECT-Anweisung auszuführen? Das Problem hierbei ist, dass die Struktur
der Ergebnistabelle und damit die Struktur der FETCH-Anweisung erst zur Laufzeit
bekannt ist.
In diesem Fall muss die durch PREPARE vorbereitete SQL-Anweisung mittels
DESCRIBE ausgewertet und ein "Descriptor" erstellt werden, der dann für die
Umsetzung und Auswertung der Struktur verwendet werden kann.
Mit ALLOCATE DESCRIPTOR wird im Programm ein Speicherbereich reserviert, der der
Kommunikation zwischen Programm und DBMS dient. Dieser Speicherbereich besteht im
wesentlichen aus einem Zähler, der die Anzahl der folgenden Datenstrukturen angibt, sowie
einem Array von Datenstrukturen, wobei jede Datenstruktur einen Wert – z.B. eine Spalte
einer Ergebniszeile oder einer Hostvariablen – übertragen kann. Jede Datenstruktur enthält
zumindest folgende Information, wobei nicht alle Informationen in jedem Falle gültige
Informationen tragen:
NAME
enthält als Zeichenkette den Spaltennamen
UNNAMED
ist 1, falls die Spalte unbenannt ist, 0 sonst
TYPE
spezifiziert den übertragenen Datentyp
LENGTH
gibt die Länge an
DATA
enthält die übertragenen Daten
PRECISION
gibt bei Zahlentypen die "Precision" an
SCALE
beschreibt bei Zahltypen die "Scale"
INDICATOR
ist negativ, falls der NULL-Wert übertragen wurde
Um den Deskriptor zu initialisieren, wird die Anweisung DESCRIBE OUTPUT
prep_name USING SQL DESCRIPTOR desc_name aufgerufen. Damit wird Anzahl
der Spalten sowie die Datentypen ermittelt.
Mit jedem FETCH ... INTO SQLDESCRIPTOR desc_name wird die entsprechende
Zeile aus der Ergebnistabelle ausgelesen und die Werte in die Felder DATA und
INDICATOR in den entsprechenden Datenstrukturen des Descriptors gefüllt. Dann
können sie mit entsprechenden GET DESCRIPTOR-Anweisungen ausgelesen
werden.
7
Aufgabe 7 (20 Punkte)
Wozu dient die als Optimizer bezeichnete Komponente in einem DBMS? Zunächst waren die Optimizer regelbasiert
aufgebaut, inzwischen arbeiten viele Optimizer kostenbasiert. Wie läßt sich das Ergebnis eines regelbasierten Optimizers
beeinflussen? Diskutieren Sie, was typischerweise in die Entscheidungen mit einfließt.
Die Aufgabe des Optimizers ist es, bei einer SQL-Anweisung den "besten" Zugriffspfad auf
die in der Datenbank gespeicherten Daten zu ermitteln. Hierzu verwenden die Hersteller
Informationen, die spezifisch für ihre jeweiligen DBMS sind. Die Qualität der Optimizer ist in
den letzten Jahren wesentlich gestiegen.
 ermöglichen eine effiziente Ausführung der Anfragen durch das DBMS
 Beispiel: Finde einen Relationenalgebra-Ausdruck, der äquivalent ist ("das gleiche
Ergebnis liefert") zu einem vorgegebenen, der aber effizienter auszuwerten ist.
Eine Möglichkeit der Optimierung ist die sogenannte algebraische Optimierung. Hierbei
werden Algebra-Ausdrücke nach "Rechenregeln" in äquivalente Ausdrücke umgeformt
 Es gibt regel- und kostenbasierte Optimizer. Regelbasierte Optimizer versuchen im
wesentlichen aufgrund von Regeln einen guten Zugriffspfad zu ermitteln; kostenbasierte
Optimizer versuchen hingegen, möglichst viele Strategien anhand der entstehenden I/O-,
Speicher-, Transport- und CPU-"Kosten" zu bewerten und die kostengünstigste Strategie zu
ermitteln.
Um dem Optimizer zu helfen, können neben den oben erwähnten Überlegungen
typischerweise noch Hilfen angegeben werden. So ermöglicht es
Oracle, dem Optimizer einen HINT – einen Vorschlag – mitzugeben, gewisse
Aspekte besonders zu beachten,
IBM in dem Produkt DB2, durch die Anweisung SET CURRENT QUERY
OPTIMIZATION nr den Optimizer mehr oder weniger Zugriffspfade bewerten zu
lassen.
 Optimierungspunkte (manuell), Hinderungspunkte des Optimizers:
Angaben von Spaltennamen in der Select-Anweisung statt select *
Problematische SQL-Anfragen, Umformulierungen besser?
Verwendung von LIKE, Suche nach Bruchstücken zu vermeiden (z.B. "%110")
Unsinnige Verwendung des Index
OR-Prädikat, evtl. OR durch UNION ersetzen
Verneinung, möglichst vermeiden
Falsche Datentypen, Index wird vom Optimizer nicht gesetzt, da Typ nicht klar ist
Verwendung von Null, verhindert Einsatz Index
Reihenfolge in der WHERE-Klausel, Tabellen mit den meisten Trefferzeilen vorn
Benutzung von DISTINCT, Sortierung ist zu vermeiden
Unteranfragen, möglichst Einsatz von JOIN
Qualifizierung von Namen, keine zusätzliche Ermittlung der Tabelle zu den
Spaltennamen
Mehrspaltige Indexe, Index genau wie where-Bedingung(mehrere Bedingungen)
formulieren
Aufgabe 8 (15 Punkte)
Warum ist der objekt-relationale Ansatz von Oracle nicht objekt-orientiert zu nennen?
Oracle weist schon einige Merkmale des objektorientierten Ansatzes auf, ist
aber immer noch kompatibel zu älteren SQL-Versionen. Die Erweiterung von
Oracle hinsichtlich des objektorientierten Ansatzes sind:
Konzept benutzerdefinierter Datentypen (ADT)
8
Funktionen der ADT werden analog zu Methoden durch das DBMS
verwaltet
Tupeltypen (row)
auf ADT ist Subtypkonzept mit Vererbung realisiert
Redefinition von Attributen und Funktionen ist erlaubt
Typkonstruktoren list, set, multiset
nicht-atomare Wertebereiche für Attribute, können zusammen mit row
verwendet werden
Identifikatoren können für Tupel vergeben werden und können als
Referenzen verwendet werden
Allerdings besitzt Oracle keine Möglichkeit Attribute zu vererben und ist auf
einen Kollektionstyp (Tabelle) beschränkt.
Das eigentliche Konstrukt ist trotz vieler objektorientierter Konzepte im
Datenbankmodell (z.B. Tabellenhierarchie, Methoden, Vererbung von
Strukturen und Methoden) immer noch die Relation oder Tabelle. ...
"Unterstützt ein System komplexe Daten und Anfragen, so ist es
objektrelational.
Unterstützt ein System komplexe Daten, aber keine Anfragen, so ist es
objektorientiert. " nach Stonebraker
Muss-Kriterien für objektorientierte Datenbanksysteme sind:
Typkonstruktoren
Objektidentität
Strukturvererbung
generischer Operationenteil
Methoden
Vererbung
Overriding
9