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-value- Classes: 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 DB- Struktur 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 DB- Operationen 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 Controller- Objekten (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 OO- Datenbanken 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 Precompiler analysiert Quelltext (Normaler Code + SQL) und wandelt SQL-Anweisungen in Prozeduraufrufe um Dynamische Einbettung 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: declare AktProdukt cursor for select Bezeichnung, Preis, Bestand from Produkt for update of Preis, Bestand Fetch-Anweisung: 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 select Bezeichnung, Preis, Bestand from Produkt for update of Preis, Bestand; //Deklaration des Cursors //Ä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: 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 Nachteile: 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 End 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 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; End; for w as WeinCurs cursor for do select Name from Weine where Weingut = erz... end for; define wliste varchar(500); call weinliste( Helena, wlist);