Datenbanken in Kommunikationsnetzen

Datenbanken in Kommunikationsnetzen Datenbanken in Kommunikationsnetzen 2002 Prof. Dr. Rainer Manthey Informationssysteme 1 Verteilte Datenbanken DB in Kommunikationsnetzen 9.1 Verteilte Datenbanken 2002 Prof. Dr. Rainer Manthey Informationssysteme 2

Verteilte Datenbanksystem: Prinzip Verteiltes DBS: Kemper/Eickler: Kapitel 16 Kooperation autonomer, kommunizierender DBMS mit lokalen Datenbanken zur Durchführung einer globalen Aufgabe DB 1 Station S 1 DB 2 DB 3 2002 Prof. Dr. Rainer Manthey Informationssysteme 3 Verteilte Datenbanksystem: Beispiel Beispiel: Verteilte Datenhaltung in einer Universität (leider hypothetisch) DB 1 Kommunikationsnetz Studentensekretariat persönliche Daten aller Studierenden Daten über Promotionen Dekanat Kommunikationsnetz Station S Station S 2 3 Daten über Diplome Institut DB 2 DB 3 2002 Prof. Dr. Rainer Manthey Informationssysteme 4

Entwurf und Aufbau einer verteilten DB globales Schema Fragmentierungsschema Allokationsschema lokales Schema... lokales Schema lokales DBMS... lokales DBMS lokale DB Station S 1...... lokale DB Station S n 2002 Prof. Dr. Rainer Manthey Informationssysteme 5 Fragmentierung und Allokation: Prinzip Fragmentierung Allokation R R 1 R 1 1 R 1 2 Station S 1 R 2 R 2 1 Station S 2 R 3 R 2 3 R 3 Station S 3 2002 Prof. Dr. Rainer Manthey Informationssysteme 6

Horizontale und vertikale Fragmentierung In der Fragmentierungsphase werden die Relationen des globalen Schemas in disjunkte Fragmente (Teile, Unterrelationen) zerlegt. Ziel ist es dabei, gemeinsam angefragte Daten in dasselbe Fragment zu gruppieren, um dann die Fragmente den einzelnen Stationen zuordnen zu können. Fragmentierung erfolgt aufgrund von Anwendungswissen über die Art und Weise der zu erwartenden Interaktion mit der verteilten DB. Es gibt zwei prinzipielle Arten der Fragmentierung: horizontale Fragmentierung: Zerteilen der Relation in disjunkte Teilrelationen unter Beibehaltung des Schemas vertikale Fragmentierung: Zerlegen der Relation in disjunkte Projektionskomponenten kombinierte vertikal-horizontale oder horizontal-vertikale Fragmentierung 2002 Prof. Dr. Rainer Manthey Informationssysteme 7 Fragmentierung (2) Jede Fragmentierung muss drei Korrektheitforderungen erfüllen: Rekonstruierbarkeit: Die fragmentierte Relation lässt sich aus den Fragmenten rekonstruieren. Vollständigkeit: Jedes Tupel ist mindestens einem Fragment zugeordnet. Disjunktheit: Jedes Tupel ist höchstens einem Fragment zugeordnet. Horizontale Fragmentierung erfolgt durch Anwendung von Selektionsprädikaten, die definieren, welche Tupel einer Relation zusammengehören. Vertikale Fragmentierung erfolgt durch Projektion auf die zusammengehörenden Attribute. Um bei vertikaler Fragmentierung die Rekonstruierbarkeit sicherzustellen, muss man jedem Fragment den Primärschlüssel der Ausgangsrelation mitgeben (und damit "ein wenig" die Disjunktheitsforderung verletzen). Idealerweise sollte die Fragmentierung für die Nutzer einer verteilten DB nicht erkennbar ("transparent") sein; sie arbeiten also mit dem globalen Schema. 2002 Prof. Dr. Rainer Manthey Informationssysteme 8

Allokation Bei der Allokation (Zuordnung) der Fragmente an die Stationen des verteilten Systems spielen vor allem zwei Gesichtspunkte eine entscheidende Rolle: Wo entstehen die Daten? Wo werden die Daten am häufigsten (oder überhaupt) gebraucht? Man unterscheidet zwei Arten der Allokation: redundanzfreie Allokation: Jedes Fragment wird genau einer Station zugeordnet. Allokation mit Replikation: Fragmente dürfen repliziert und mehreren Stationen zugeordnet werden. Replikation erlaubt mehr Freiheitsgrade bei der Allokation und verbessert den lesenden Zugriff, macht aber gleichzeitig Änderungen aufwändiger. Auch die Allokation der Daten im Kommunikationsnetz sollte für die Nutzer weitgehend transparent sein. 2002 Prof. Dr. Rainer Manthey Informationssysteme 9 Anfrageverarbeitung in verteilten Datenbanken Bei der Bearbeitung von Anfragen, die an das globale Schema gestellt werden, muss im Rahmen der logischen Optimierung dafür gesorgt werden, dass möglichst viele der durchzuführenden Algebra-Operationen lokal absolviert werden. Bei horizontaler Fragmentierung ist mit einer größeren Anzahl von Vereinigungsoperationen zu rechnen, um die Fragmente wieder zusammen zusetzen. Dabei ist es wichtig, dass möglichst keine globale Rekonstruktion vorgenommen wird. Im Rahmen der logischen Optimierung lassen sich Joins über Fragmenten mit einem speziellen Distributivgesetz auf die Stationen verteilen: (R 1 R 2 ) p (S 1 S 2 ) = (R 1 p S 1 ) (R 1 p S 2 ) (R 2 p S 1 ) (R 2 p S 2 ) In vielen Fällen sind die Teil-Joins leer. Der gezielte Einsatz von Semi-Joins ermöglicht dabei weitere Optimierungen (s. Kemper 16.5) Bei vertikaler Fragmentierung muss durch genaue Analyse der jeweiligen Anfrage sichergestellt werden, dass nur diejenigen Fragmente zusammengeführt werden, deren Attribute auch tatsächlich benötigt werden. 2002 Prof. Dr. Rainer Manthey Informationssysteme 10

Transaktionskontrolle in verteilten Datenbanken In einem verteilten DBS gibt es zwei Stufen von Transaktionen: lokale Transaktionen: T. bezieht sich nur auf eine der lokalen DBs globale Transaktionen: T. bezieht sich auf mehrere, kooperierende DBs Lokale Transaktionen werden wie bisher dargestellt vom lokalen T.manager bewältigt. Globale Transaktionen bringen das Problem mit sich, dass jede der beteiligten Stationen "für sich" ausfallen kann. In einem solchen Fall muss die globale T. in allen beteiligten Stationen zurück gesetzt werden. Auch die zu einer globalen T. nebenläufig lokal ablaufenden T. müssen in diesem Fall aus Gründen der Synchronisation zurückgesetzt werden. Um ein frühzeitiges, unkoordiniertes Festschreiben der lokalen Änderungen zu verhindern, muss das Transaktionsende global koordiniert werden. Dazu gibt es ein eigenes Protokoll, das durch eine separate, globale Komponente - genannt Koordinator - überwacht wird: Zwei-Phasen-Commit-Protokoll (2PC-Protokoll) 2002 Prof. Dr. Rainer Manthey Informationssysteme 11 EOT-Behandlung beim 2PC-Protokoll (für 4 Agenten) Haben alle teilnehmenden Stationen ("Agenten") das Ende der Transaktion (EOT) an den Koordinator signalisiert, laufen folgende Koordinationsschritte ausgeführt: Agenten A 1 A 1 Koordinator K A 2 K A 2 K A 3 A 3 A 4 A 4 PREPARE FAILED/READY COMMIT/ABORT ACK (acknowledge) "Wie ist Dein Teil der T. ausgegangen?" 2002 Prof. Dr. Rainer Manthey Informationssysteme 12

2PC-Protokoll: Verhalten des Koordinators Koordinator: initial EOT: Sende PREPARE an alle Agenten! Timeout oder FAILED von irgendjemand empfangen: - abort ins Log - ABORT senden bereit READY von allen Agenten empfangen: - commit ins Log - COMMIT senden abgebrochen festschreibend ACK von allen empfangen fertig 2002 Prof. Dr. Rainer Manthey Informationssysteme 13 2PC-Protokoll: Verhalten der Agenten wartend Agenten: Timeout oder lokaler Fehler entdeckt: - abort ins Log - sende FAILED PREPARE empfangen und lokal alles okay: - Log-Einträge ausschreiben - ready ins Log - sende READ bereit ABORT empfangen: - abort ins Log - sende ACK COMMIT empfangen: - commit ins Log - sende ACK abgebrochen festgeschrieben PREPARE empfangen: sende FAILED 2002 Prof. Dr. Rainer Manthey Informationssysteme 14

Synchronisation und Deadlockerkennung in verteilten DB Transaktionen in einem verteilten DBS müssen global serialisiert werden. Die in Kap. 7 vorgestellten Synchronisationsverfahren lassen sich entsprechend auf den verteilten Fall verallgemeinern. Einrichten einer globalen Sperrverwaltung (beim 2PL) würde einerseits zum "bottleneck" würde das ganze System werden (und könnte selbst ausfallen), andererseits würden die lokalen DB dann ihre Autonomie verlieren. Anmelden von Sperrwünschen der globalen T. bei den lokalen T.managern ist daher vorzuziehen, auch wenn lokale T. dadurch bevorzugt werden. Auch die Deadlock-Erkennung ist im verteilten Fall deutlich schwieriger als in zentralisierten DBS. Wieder kann die Erkennung entweder lokal oder global geschehen. Globale D.-Erkennung bringt die Gefahr des Auftretens von "Phantom- Deadlocks" mit sich. Lokale D.erkennung (und -vermeidung) ist wesentlich aufwändiger. Viele DBMS-Produkte setzen die einfachere, wenn auch "drastischere" Methode des "Timeout" ein: T., die innerhalb eines bestimmten Zeitintervalls keine Fortschritte machen, werden zurückgesetzt. 2002 Prof. Dr. Rainer Manthey Informationssysteme 15 Bücher über verteilte Datenbanken Peter Dadam "Verteilte Datenbanken und Client/Server-Systeme: Grundlagen, Konzepte, Realisierungsformen" Springer-Verlag, 1996, ISBN 3-540-61399-4 http://www.informatik.uni-ulm.de/dbis/papers/vdb-buch/vdb-buch.html Erhard Rahm "Mehrrechner-Datenbanksysteme. Grundlagen der verteilten und parallelen Datenbankverarbeitung" Addison-Wesley-Verlag 1994 seit 1997: Oldenbourg-Verlag, ISBN 3-486-24363-2 http://dbs.uni-leipzig.de/de/buecher/mrdbs.html 2002 Prof. Dr. Rainer Manthey Informationssysteme 16

Internet und Datenbanken DB in Kommunikationsnetzen 9.2 Internet und Datenbanken 2002 Prof. Dr. Rainer Manthey Informationssysteme 17 Internet: verteiltes System mit Client-Server-Architektur Die Verwendung von Datenbanken im Internet stellt einen Spezialfall eines verteilten DBS dar: Nur eine Station enthält die Daten, die anderen Stationen fordern von dort Daten an: Client-Server-Architektur Client C 1 Client C 2 Kommunikationsnetz Server DB 2002 Prof. Dr. Rainer Manthey Informationssysteme 18

Kommunikation im Internet "Klassische" Kommunikationsform bei Client-Server-Architekturen: pull-mechanismus (Klient muss Daten vom Server "ziehen"= Alternative (im Internet inzwischen immer häufiger): Abonnieren von Daten, automatisches Weiterleiten von Änderungen durch Server (push) Klient (Web-Browser) Server (Web-Server) GET() Auswahl() Lesen() Ressourcen Response() z.b. Datenbank 2002 Prof. Dr. Rainer Manthey Informationssysteme 19 Formen der Web-Anbindung von relationalen DB Relationale Datenbanken bilden heute die Grundlage einer Vielzahl kommerzieller Anwendungen im Internet. Insbesondere im Sektor E-Commerce ist diese Konstellation von essentieller Wichtigkeit (Produktkataloge mit Web-Suchschnittstellen). Die Anbindung von Datenbanken an Webapplikationen erfolgt inzwischen fast ausschließlich über Java-Programme und java-spezifische Infrastruktur. Für hochgradig dynamische Zugriffe auf Datenbanken gibt es inzwischen ein eigenes, standardisiertes Schnittstellenprotokoll für Java-Programme (s. Kemper 4.21): Java Data Base Connectivity (JDBC) JDBC akzeptiert dabei SQL-Anweisungen als Text-Strings, die an beliebige DBMS auf dem Server weitergeleitet werden. Eine heute oft gebrauchte Form der Organisation solcher Web-DB-Kommunikation über die JDBC-Schnittstelle sind sog. Java-Servlets, spezielle Programme, die auf einer Servlet-Engine in einem separaten Prozess entweder auf dem Klienten oder dem Server abgewickelt werden. 2002 Prof. Dr. Rainer Manthey Informationssysteme 20

Web-Anbindung von Datenbanken via Servlets Browser Internet Webserver Vorlesungs- Verzeichnis.html Servlet-Engine Servlet VrlVrz Servlet VrlVrz Servlet VrlVrz JDBC (Java Database Conn.) Kemper/Eickler: Kapitel 18 Datenbank 2002 Prof. Dr. Rainer Manthey Informationssysteme 21 Browser-Darstellung Servlets sind aus drei Teilen aufgebaut: Aufbau einer Verbindung zu einer DB mittels JDBC Auswertung der Anfrage auf dem DB-Server Generierung einer HTML-Seite für die Antwortpräsentation im Client. im folgenden: Diskussion eines Beispiel-Servlets zum Zugriff auf die Uni-DB im Kemper-Buch (Details s. Kemper 18). Browser-Fenster, aus dem heraus eine spezielle Anfrage an die DB mit Parametern versorgt und abgesetzt werden kann: 2002 Prof. Dr. Rainer Manthey Informationssysteme 22

HTML-Seite zum Anfragefenster zugehörige HTML-Seite (VorlesungsVerzeichnis.html): <HTML> <HEAD> <TITLE>Vorlesungs-Verzeichnis mittels Servlet</TITLE> </HEAD> <BODY> <CENTER> <FORM ACTION="http://www.db.fmi.uni-passau.de/servlets-buch/VrlVrz" METHOD="GET"> Bitte geben Sie den Namen einer Professorin bzw. eines Professors ein:<br> <INPUT TYPE=TEXT NAME="professor_name"></INPUT><BR> <INPUT TYPE=SUBMIT VALUE="Abfrage starten"></input> </FORM> </CENTER> </BODY> </HTML> 2002 Prof. Dr. Rainer Manthey Informationssysteme 23 Beispiel-Servlet (1) 2002 Prof. Dr. Rainer Manthey Informationssysteme 24

Beispiel-Servlet (2) 2002 Prof. Dr. Rainer Manthey Informationssysteme 25 import javax.servlet.*; import javax.servlet.http.*; import java.io.*; import java.sql.*; import java.text.*; public class VrlVrz extends HttpServlet { public void doget (HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { Connection conn = null; Statement stmt = null; ResultSet rs = null; JDBC-Datenbankresponse.setContentType("text/html"); Verbindungsaufbau PrintWriter out = response.getwriter(); try { Class.forName("oracle.jdbc.driver.OracleDriver"); conn = DriverManager.getConnection( "jdbc:oracle:oci8:@lsintern-db", "nobody", "Passwort"); stmt = conn.createstatement(); 2002 Prof. Dr. Rainer Manthey Informationssysteme 26

String query = "select v.vorlnr, v.titel, v.sws " + "from Vorlesungen v, Professoren p " + "where v.gelesenvon = p.persnr and p.name = '" + request.getparameter("professor_name") + "'"; rs = stmt.executequery(query); out.println("<html>"); out.println("<head> <TITLE> Vorlesungen von Prof. " + request.getparameter("professor_name") + "</TITLE></HEAD>"); out.println("<body>"); out.println("<h1> Vorlesungen von Prof. " + request.getparameter("professor_name") +": </H1>"); out.println("<ul>"); Generierung der HTML- Seite aus dem Anfrageergebnis 2002 Prof. Dr. Rainer Manthey Informationssysteme 27 while (rs.next()) out.println("<li>" + rs.getint("vorlnr") + ": " + rs.getstring("titel") + " (mit " + rs.getint("sws") + " SWS)"); out.println("</ul>"); out.println("</body> </HTML>"); } catch(classnotfoundexception e) { out.println("datenbanktreiber nicht gefunden:" + e.getmessage()); } catch (SQLException e) { out.println("sqlexception: " + e.getmessage()); } finally { try { if (conn!= null) conn.close(); } catch (SQLException ignorieren) {} } } } Ausnahme- Behandlung 2002 Prof. Dr. Rainer Manthey Informationssysteme 28

Antwortseite (Browser-Darstellung) Anfrage Antwort 2002 Prof. Dr. Rainer Manthey Informationssysteme 29 Alternativen zu Servlets Grosser Nachteil der Servlet-Lösung: Vollständige Generierung der HTML-Seiten durch das Servlet führt bei Einbindung von dynamisch generierten Anteilen zu Ineffizienz und Unübersichtlichkeit des Codes. von SUN entwickelte Alternative zur Einbettung von Java-Codefragementen in HTML-Seiten: Java Server Pages (JSP). vergleichbare Technologie von Microsoft: Active Server Pages (ASP) Server Pages leiden noch unter dem Nachteil mangelnder Wiederverwendbarkeit. Dies kann durch Einsatz von Java-Komponenten verhindert werden, die ausserhalb der JSP-Seite definiert wurden: Java Beans weitere Diskussion des Uni-Beispiels mit JSP und Java Beans in Kemper 18 Vorlesung, in der beide Techniken vertieft behandelt wird: Softwaretechnologie (Prof. Cremers) 2002 Prof. Dr. Rainer Manthey Informationssysteme 30

Literatur und Ausblick Erhard Rahm, Gottfried Vossen (Hrsg.) "Web & Datenbanken: Konzepte, Architekturen, Anwendungen" Dpunkt Verlag, Heidelberg, Sep. 2002 506 Seiten, Gebunden, 54 Euro, ISBN 3-89864-189-9 http://dbs.uni-leipzig.de/webdb/kapitel.html weiteres wichtiges, neues Thema im Kontext Web&DB: XML als neue Sprache für das Web mit DB-Varianten XSchema und XQuery im SS 2003 hier an der Uni Bonn: Vorlesung "XML - Grundlagen und Anwendungen" Dr. Stefan Lüttringhaus-Kappel Do 13-15 Fr 11-13 A 207 (3 V + 1 Ü) 2002 Prof. Dr. Rainer Manthey Informationssysteme 31