DBPR1

Datenbankprogrammierung 1
Die Folien basieren auf:
Datenbanken: Konzepte und Sprachen, Andreas Heuer und Gunter Saake,
mitp-Verlag, 2. Auflage, 2000, http://wwwiti.cs.uni-magdeburg.de/biber/
Datenbanken kompakt, Andreas Heuer und Gunter Saake, mitp-Verlag, 2003
Studienbriefe zu Datenbankprogrammierung, Karl M. Göschka, Jürgen Falb
Datenbanksysteme – Eine Einführung, Alfons Kemper und Andre Eickler,
Oldenbourg Verlag, München, 6. Auflage, 2006. http://wwwdb.in.tum.de/research/publications/books/DBMSeinf
OO Programmierung &
Relationale Datenbanken
OO Programmierung und Relationale DB


Grundproblem: Abbildung der objektorientierten auf die relationale Struktur
Abbildung einfacher Klassen?





direkt auf Tabellen
Attribut  Spalte
Instanz  Zeile (Tupel)
Primärschlüssel  Primärschlüssel
Komplexere Strukturen?

Beziehungen zwischen Klassen?
Abbildung komplexerer OO
Strukturen: Ansätze

Schwache Struktur mit Dependent-valueClasses:


Objekte abhängiger Werte-Klassen werden als BLOB
(Binary Large Object) in einem einzigen Attribut
gespeichert
Nachteile:



Daten können nicht durchsucht werden
Keine Beziehungen auf diese Daten darstellbar
Starke Struktur


Jede Klasse in eine eigene Tabelle
Tabellen werden (wie die Klassen) über Attribute in
Beziehung gesetzt
 Datenbankstruktur spiegelt Klassenstruktur wider
Abbildung komplexerer OO
Strukturen: Ansätze

Hybride Struktur
Instanzen der Objekte werden serialisiert
 Referenzen werden jedoch in eindeutige
Schlüsselbeziehungen umgeformt
 Strukturinformation bleibt erhalten,
spiegelt sich aber nicht in relationaler DBStruktur wider

Persistenzansätze


Was bedeutet Persistenz eigentlich?
Die Lebensdauer eines persistenten
Objektes übersteigt die Lebensdauer der
Applikation, die das Objekt erzeugt hat.
D.h., Zustand der Objekte wird auf einem
nicht-flüchtigen Medium gespeichert, sodass
das Objekt weiter existiert, auch wenn die
Anwendung beendet wird.
Persistenzansätze
1. Objekt-Serialisierung






Umwandlung eines Objektes (und aller davon erreichbaren
Objekte) in einen Bytestrom
Für Persistenz im „kleinen Bereich“ nutzvoll bzw. auch für
Kommunikation über Sockets, RMI, CORBA, etc.
Ablegung der serialisierten Objekte in der DB natürlich auch
möglich
DB hat keine Struktur sondern ist nur Lager für serialisierte
Objekte
Bereits in Java eingebaut
Banane-Gorilla-Problem:

Um auf ein Objekt (Banane) zuzugreifen, müssen erst alle
assozierten Objekte (Gorilla) instanziert werden.
Objekt-Serialisierung

Vorteile:
Leicht zu implementieren, auch ohne DB möglich

Sehr schnell, wenn Daten nur selten geschrieben/gelesen werden
 Spiele


Nachteile:



Hohe Last für Instanzierung
Gröbere Granularität für Persistierung
Zuverlässigkeit nicht gewährleistet, wenn es während der
Serialisierung zu einem Systemabsturz kommt
 schlecht geeignet bei großen Datenmengen, wenn Objekte
oft verändert werden, zuverlässige Persistenz benötigt wird
2. Spezifische Persistenz


Jedes Objekt hat eigene Verbindung zur DB für seine
eigenen Zwecke
Anwendung:




Nur für kleine Projekte mit geringer Funktionalität
 Informationssysteme, die nur die wesentlichsten DBOperationen brauchen
D.h. für einfache Struktur, aber durchaus für große
Datenmengen
Vorteil: sehr einfach, wenn man Transaktionen
braucht
Nachteile:


Starke wechselseitige Abhängigkeit jedes Objektes von der
gesamten Datenstruktur
Erweiterungen schwierig
3. Gekapselter
Datenbankzugriff





DB-Zugriff wird in einigen wenigen ControllerObjekten (database access objects) gekapselt
Controller ist für bestimmte Tabellen und bestimmte
Klassen verantwortlich
Abhängigkeit DB/Applikation auf wenige Objekte
reduziert
Andere Objekte weitgehend von Persistenzaufgaben
befreit
Eignet sich auch schon für komplexere Strukturen
4. Persistenzframeworks




Grundidee: Business Objects sollen ohne
Rücksicht auf Persistenz entwickelt werden
( Transparenz)
DB-Zugriff weitgehend in Framework
gekapselt
Für größere Projekte bzw. mehrere ähnliche
Projekte geeignet
Nicht die Datenmenge ist entscheidend,
sondern die Struktur!
Orthogonale Persistenz in OODatenbanken

Drei Hauptströmungen:



Erweiterung OO Programmiersprachen um
Persistenz (z.B. PJama)
Erweiterung relationaler DB um objektorientierte Kernels
Komplett neu entwickelte Systeme (z.B.
Multimedia-DB)
UML Klassendiagramm vs. ER
Diagramm



Sehr viele Gemeinsamkeiten, kaum Unterschiede
Im Prinzip ist es Geschmackssache, ob man für den
DB-Entwurf UML oder ER verwendet.
Unterschiede:




Methoden im Klassendiagramm, aber nicht im ERD
Kein Schlüssel in UML
Assoziationen in UML können eine Richtung haben, im ERD
nicht
...
Programmiersprachenanbindung



SQL: Anfrage und Manipulationssprache
für relationale DB
Implementierung von
Anwendungssystemen: Java, C#, C++,
etc.
Wie kann man SQL-Anweisungen in
anderen Programmiersprachen
gestatten?
Programmiersprachenanbindung
Call Level Interface (CLI)
Einbettung
dynamisch
statisch
Call-Level Interface (CLI)




Ziel: Nutzung von SQL-Anweisungen in einer
Programmiersprache
Bibliothek ermöglicht Zugriff und Manipulation der DB
Kann aus Programmiersprache heraus aufgerufen werden
Beispiele für Implementierungen des SQL/CLI Standards



JDBC
ODBC (Open Database Connectivity)
Weitere Beispiele:


OCI (Oracle Call Interface)
MySQL ++
Einbettung von Datenbanksprachen
in Programmiersprachen


Verbindet DB-Sprache (SQL) mit Programmiersprache
Statische Einbettung


Dynamische Einbettung



Precompiler analysiert Quelltext (Normaler Code + SQL) und
wandelt SQL-Anweisungen in Prozeduraufrufe um
Ermöglicht Konstruktion von SQL-Anweisungen zur Laufzeit
SQL-Anfragen sind Zeichenketten aus Sicht der
Programmiersprache
Grundproblem bei der Kopplung SQL/Programmiersprache?
Menge von Tupeln vs. Tupeln
 Cursor

Cursor

Problem bei der Kopplung imperativer Programmiersprachen mit SQL:
Unterschiedliche Datenstrukturen




Imperative Programmiersprache: Tupel
SQL: Relation = Menge von Tupeln
 Impedance mismatch
Cursor = ITERATOR über eine Liste von Tupeln
Cursor (Forts.)

Beispiel:

Fetch-Anweisung:




declare AktProdukt cursor for
select Bezeichnung, Preis, Bestand
from Produkt
for update of Preis, Bestand
Zugriff auf einzelne Tupeln einer Relation
Bewirkt weitersetzen des Cursor-Zeigers
Realisiert Datentransfer in das Anwendungsprogramm
Muss in modernen Call Level Interfaces nicht immer explizit
deklariert werden, z.B. nur interne Verwendung in JDBC
Static Embedded SQL





SQL Anweisungen werden in den Quelltext eingebettet
Statisch  SQL Anweisung zur Übersetzungszeit bekannt
Vorübersetzer analysiert SQL-Anweisung und setzt sie in
Prozeduraufruf um
 nicht nötig bei CLI
Vorteil: Geringere Fehleranfälligkeit durch Überprüfung zur
Übersetzungszeit
Nachteil: Alle SQL Anweisungen müssen bereits ausformuliert
sein.


Z.B. kann die Bedingung im WHERE Teil nicht erst zur Laufzeit vom
Anwender bestimmt werden.
Nur Variablen der Wirtssprache können mit Werten belegt werden.
Beispiel: Einsatz der Cursor-Technik
exec sql declare AktProdukt cursor for
//Deklaration des Cursors
select Bezeichnung, Preis, Bestand
from Produkt
for update of Preis, Bestand;
//Ändern von Preis,Bestand erlaubt
exec sql open AktProdukt; //Öffnen des Cursors
exec sql fetch AktProdukt //Transfer eines Tupels in Variablen der Anwendung
into :bezeichnung, :preis, :bestand;
exec sql close AktProdukt; //Schließen des Cursors
Dynamic Embedded SQL



SQL Anweisungen werden zur Laufzeit
zusammengestellt und als Zeichenkette zum
DB-Server gesendet.
 in der Laborübung verwendet
Nachteil: Fehlerhafte Anweisungen und
Typkonflikte können erst zur Laufzeit erkannt
werden.
(CLI unterstützen dynamisches SQL, z.B.
JDBC bettet dynamisches SQL in Java ein)
Beispiel
exec sql begin declare section;
Anfragestring char(256) varying;
exec sql declare section;
exec sql declare AnfrageObjekt statement;
Anfragestring:= „delete from Bestellposten where
BestNr=1013‟
exec sql prepare AnfrageObjekt from:Anfragestring;
exec sql execute AnfrageObjekt
Beispiel: Übergabe von Variablen der Wirtssprache als
Parameter
Anfragestring:= „delete from Bestellposten where
BestNr=?‟
exec sql prepare AnfrageObjekt from :Anfragestring;
exec sql execute AnfrageObjekt
using :loeschBestNr
Stored Procedures

SQL wird um Konstrukte erweitert, die man aus
Programmiersprachen kennt:





Schleifen
Funktionen/Prozeduren
...
Funktionalität der Anwendung kann in der DB
realisiert werden
Beispiele:



Oracle PL/SQL
Microsoft Transact SQL
Standard: SQL/PSM (Persistent Stored Modules)
Stored Procedures (Forts.)

Vorteile:




Nachteile:



Schnell, da die Optimierung durch das DBMS erfolgt
( Daten müssen nicht aus der DB geholt werden!)
Prozeduren sind nur von DBMS abhängig nicht von externen
Programmiersprachen bzw. Betriebssystem
Prozeduren können in der Integritätssicherung verwendet werden,
z.B. in Aktionsteil von Triggern
Fehlersuche deutlich aufwendiger
Benutzerinteraktion schwer realisierbar
Besonders nutzvoll wenn


Client-Applikationen, die in verschiedenen Sprachen geschrieben
sind, auf die gleichen DB-Operationen zugreifen sollen
Security wichtig ist: Zugriff nur über stored procedures, kein
direkter Zugriff auf Tabellen
Stored Procedures vs. Stored
Functions


SQL/PSM unterstützt Prozeduren und
Funktionen
Funktion:



Liefert Wert zurück
Kann nur Eingabeparameter haben
Stored Procedure

Unterstützt sowohl Eingabe- als auch
Ausgabeparameter
Definition und Verwendung
der Stored Function
Create function geschmack (rz int)
Returns varchar(20)
Begin
return case
when rz <= 9 then “Trocken”
when rz < 9 and rz <= 18 then “Halbtrocken”
when rz > 18 and rz <= 45 then “Lieblich”
else “Süß”
end
End
SELECT Name, Weingut
FROM Weine
WHERE Farbe = “Rot” AND geschmack(Restzucker)=“Trocken”
Definition und Verwendung
der Stored Procedure
Create procedure weinliste (in erz varchar(30), out wliste varchar(500))
Begin
declare pos integer default 0;
for w as WeinCurs cursor for
select Name from Weine where Weingut = erz
do
...
end for;
End;
define wliste varchar(500);
call weinliste(“Helena”, wlist);