Datenbanksysteme. Prof. Dr.-Ing. Sebastian Michel TU Kaiserslautern. Wintersemester 2017/18.

Transkript

1 Datenbanksysteme Wintersemester 2017/18 Prof. Dr.-Ing. Sebastian Michel TU Kaiserslautern

2 Wiederholung VL Informationssysteme Abbilden eines Teilaspekts der realen Welt Was wollen wir abbilden? Welcher Grad an Details? Welche Entitäten spielen eine Rolle? Und welche Rolle spielen sie? Wie sind Entitäten miteinander verbunden? Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 2 / 63

3 Anforderungsanalyse und ER-Modellierung Anforderungsanalyse Reale Welt: Universität Anforderungsanalyse Pflichtenheft Studenten hören Vorlesungen Professoren halten Vorlesungen Studenten könnten anhand ihrer Matrikelnummer eindeutig identifiziert werden... Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 3 / 63

4 Anforderungsanalyse und ER-Modellierung Entity/Relationship-Modellierung Quelle: Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 4 / 63

5 Anforderungsanalyse und ER-Modellierung Entity/Relationship-Modellierung Quelle: Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 5 / 63

6 Anforderungsanalyse und ER-Modellierung Entity/Relationship-Modellierung 1. Entität Entitätstyp Semester MatrNr Name 2. Beziehung Beziehungstyp Studenten 3. Attribut (Eigenschaft) hören 4. Schlüssel (Identifikation) Vorlesungen 5. Rolle SWS VorlNr Titel Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 6 / 63

7 Anforderungsanalyse und ER-Modellierung Beispiel: Universitätsschema Fachgebiet Assistenten PersNr Name arbeitet für Name PersNr Professoren Studenten MatrNr lesen hören Name voraussetzen Vorlesungen VorlNr Titel Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 7 / 63

8 Relationen Relationales Modell Abbilden des ER-Modells in Relationen: Zum Beispiel: Kunden(ID, Telefon, Adresse, Name) Kaufen(Wert, Datum, Preis, Verkäufer, Auto, Kunde) Verkaufen(Datum, Wert, Kommission, Kunde, Verkäufer, Auto)... oder... Studenten (MatrNr, Name) Hören (MatrNr, VorlNr) Vorlesungen (VorlNr, Titel) Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 8 / 63

9 Relationen Beispiel: Die relationale Uni-DB Professoren PersNr Name Rang Raum 2125 Sokrates C Russel C Kopernikus C Popper C Augustinus C Curie C Kant C4 7 voraussetzen Vorgänger Nachfolger prüfen MatrNr VorlNr PersNr Note Studenten Vorlesungen MatrNr Name Semester VorlNr Titel SWS gelesen Xenokrates 18 von Jonas Grundzüge Fichte Ethik Aristoxenos Erkenntnistheorie Schopenhauer Mäeutik Carnap Logik Theophrastos Wissenschaftstheorie Feuerbach Bioethik hören 5259 Der Wiener Kreis MatrNr VorlNr 5022 Glaube und Wissen Die 3 Kritiken Assistenten PerslNr Name Fachgebiet Boss Platon Ideenlehre Aristoteles Syllogistik Wittgenstein Sprachtheorie Rhetikus Planetenbewegung Newton Keplersche Gesetze Spinoza Gott und Natur Prof Dr.-Ing. S. 2Michel TU Kaiserslautern 5022 Datenbanksysteme, WS 17/18 9 / 63

10 Relationale Algebra Die Operatoren der relationalen Algebra Selektion σ Projektion π Kreuzprodukt Join (Verbund) Umbenennung ρ Differenz Division Aggregation γ Duplikateliminierung δ Sortierung τ Vereinigung Schnitt Semi-Join (linker) Semi-Join (rechter) linker äußerer Join rechter äußerer Join äußerer Join Anti-Join Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 10 / 63

11 Relationale Algebra Grundlagen der relationalen Algebra Achtung: Es gibt Relationen (Ausprägungen: R D 1 D 2... D n ) und Relationenschema:{[ attributname1: datentyp1, attributname2: datentyp2,...]}. Das Schema einer Relation wird auch mit sch(r) oder R beschrieben. Die Operatoren und ihre Verwendung: Eingabe eines Operators ist eine oder mehrere Relationen. Ausgabe ist auch wieder eine Relation. D.h., Operatoren sind kombinierbar (mit gewissen Regeln). Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 11 / 63

12 Relationale Algebra Z.B. Selektion Selektion σ Semester>10 (Studenten) σ Semester>10 (Studenten) MatrNr Name Semester Xenokrates Jonas 12 Allgemein: σ F Selektionsprädikat F besteht aus Operatoren: (oder) (und) (nicht) Arithmetischen Vergleichsoperatoren: <,, =, >,,... und natürlich aus Attributnamen der Argumentrelation oder Konstanten als Operanden Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 12 / 63

13 Relationale Algebra Kartesisches Produkt (Kreuzprodukt) Gegeben zwei Relationen R und S: R S beinhaltet ALLE! R S möglichen Paare von Tupeln aus R und S. Enthält viele (oft auch viele unsinnige) Kombinationen! Das resultierende Schema sch(r S) = sch(r) sch(s) = R S. Beim Referenzieren der Attribute des resultierenden Schemas wird R.X und S.Y verwendet, insbesondere bei Überlappungen der Attributnamen der einzelnen Schemata (=keine Unklarheiten was gemeint ist). Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 13 / 63

14 Joins Der natürliche Verbund (Join) Gegeben zwei Relationen ( + Schemata) R(A 1,..., A m, B 1,..., B k ) S(B 1,..., B k, C 1,..., C n ) R S = π A1,...,A m,r.b 1,...,R.B k,c 1,...,C n (σ R.B1 =S.B 1... R.B k =S.B k (R S)) R S R S R S S R A 1 A 2... A m B 1 B 2... B k C 1 C 2... C n Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 14 / 63

15 Joins Mehrere Joins zusammen Es können beliebig viele Relationen durch Join-Operatoren verknüpft werden. Die Reihenfolge spielt dabei keine Rolle (Joins sind kommutativ und assoziativ). (Studenten hoeren) V orlesungen (Studenten hoeren) V orlesungen MatrNr Name Semester VorlNr Titel SWS gelesenvon Fichte Grundzüge Jonas Glaube und Wissen Carnap Wissenschaftstheorie Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 15 / 63

16 Joins Allgemeiner Join (Theta-Join) Gegeben zwei Relationen ( + Schemata) R(A 1,..., A n ) S(B 1,..., B m ) θ ist ein beliebiges Prädikat über den beteiligten Attributen. R θ S = σ θ (R S) R S R S A 1 A 2... A n B 1 B 2... B m Equi-Join: Join-Prädikat θ darf nur auf Gleichheit (=) prüfen. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 16 / 63

17 Joins Weitere Join-Typen: Äußere Joins Diese Join-Typen spezifizieren wie mit Tupeln umgegangen wird, die keinen Joinpartner gefunden haben. linker äußerer Join ): auch partnerlose Tupel der linken ( Relation bleiben erhalten rechter äußerer Join ( ): auch partnerlose Tupel der rechten Relation bleiben erhalten vollständiger äußerer Join ( ): die partnerlosen Tupel beider Relationen bleiben erhalten Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 17 / 63

18 Wiederholung aus InSy Joins Natürlicher Join und linker äußerer Join Natürlicher Join L A B C a 1 b 1 c 1 a 2 b 2 c 2 Linker äußerer Join R C D E c 1 d 1 e 1 = c 3 d 2 e 2 Resultat A B C D E a 1 b 1 c 1 d 1 e 1 L A B C R C D E Resultat A B C D E a 1 b 1 c 1 a 2 b 2 c 2 c 1 d 1 e 1 = c 3 d 2 e 2 a 1 b 1 c 1 d 1 e 1 a 2 b 2 c 2 Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 18 / 63

19 Wiederholung aus InSy Joins Rechter äußerer und äußerer Join Rechter äußerer Join L A B C a 1 b 1 c 1 a 2 b 2 c 2 Äußerer Join R C D E c 1 d 1 e 1 = c 3 d 2 e 2 Resultat A B C D E a 1 b 1 c 1 d 1 e 1 c 3 d 2 e 2 L A B C a 1 b 1 c 1 a 2 b 2 c 2 R C D E c 1 d 1 e 1 = c 3 d 2 e 2 Resultat A B C D E a 1 b 1 c 1 d 1 e 1 a 2 b 2 c 2 c 3 d 2 e 2 Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 19 / 63

20 Joins Weitere Join-Typen: Semi Joins Idee: Finde alle Tupel der linken Relation, die Joinpartner in der rechten Relation haben. L R = π L (L R) L R ist analog definiert. Es gilt: L R = R L Allerdings sind Semi-Joins sowie die linken und rechten äußeren Joins nicht kommutativ! Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 20 / 63

21 Joins Semi-Joins Semi-Join von L mit R L A B C a 1 b 1 c 1 a 2 b 2 c 2 R C D E c 1 d 1 e 1 = c 3 d 2 e 2 Resultat A B C a 1 b 1 c 1 Semi-Join von R und L L A B C a 1 b 1 c 1 a 2 b 2 c 2 R C D E c 1 d 1 e 1 = c 3 d 2 e 2 Resultat C D E c 1 d 1 e 1 Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 21 / 63

22 Operatorbaum Operatorbaum-Darstellung Alternative Darstellung von Ausdrücken der relationalen Algebra. Gerade für größere Ausdrücke viel übersichtlicher. Beispiel: σ T itel=insy hören σ Semester>10 Vorlesungen Studenten Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 22 / 63

23 SQL SQL deklarative Anfragesprache ( was nicht wie ) setzt sich aus drei Sprachen zusammen: Datendefinitions (DDL)-Sprache: erstellt/ändert das Schema create, alter, drop Datenmanipulations (DML)-Sprache ändert Ausprägungen insert, update, delete Anfragesprache: berechnet Anfragen auf den Ausprägungen select * from where... Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 23 / 63

24 SQL Relationen vs. Tabellen In der Regel werden bei relationaler Algebra Relationen als Mengen betrachtet Erweiterung dazu durch Multimengensemantik (siehe InSy) In SQL betrachten wir aber Tabellen (= Bags) Was ist der Unterschied? Relationen versus Tabellen: Tabellen können Duplikate enthalten Tabellen können eine Ordnung haben Tabellen haben nicht unbedingt einen Schlüssel Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 24 / 63

25 SQL Einfache Datendefinitionen in SQL Datentypen character (n), char (n) character varying (n), varchar (n) numeric (p,s), integer blob oder raw für sehr große binäre Daten clob für sehr große String-Attribute date für Datumsangaben xml für XML-Dokumente Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 25 / 63

26 SQL Datendefinitions (DDL) Sprache Tabellen erstellen: create table Professoren( PersNr integer not null, Name varchar (10) not null Rang character (2) ); Tabellen verändern: alter table Professoren add (Raum integer); alter table Professoren modify (Name varchar(30)); Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 26 / 63

27 SQL Datendefinitions (DDL) Sprache Tabellen löschen: drop table Professoren; Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 27 / 63

28 SQL Datenmanipulationssprache: insert insert into Studenten (MatrNr, Name) values (28121, Archimedes ); insert into Studenten (Name) values ( Meier ); insert into hören select MatrNr, VorlNr from Studenten, Vorlesungen where Titel = Logik ; Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 28 / 63

29 SQL Anfragesprache select <Liste von Spalten> from <Liste von Tabellen> where <Bedingung>; select * wählt alle verfügbaren Spalten aus! Relationale Algebra SQL Projektion π select Kreuzprodukt from Selektion σ where Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 29 / 63

30 SQL Select from where... select PersNr, Name from Professoren where Rang = C4 ; Professoren PersNr Name 2125 Sokrates 2126 Russel 2136 Curie 2137 Kant Professoren PersNr Name Rang Raum Sokrates C Russel C Kopernikus C Popper C Augustinus C Curie C Kant C4 7 Anmerkung: SQL legt nicht fest, in welcher Reihenfolge Selektion, Projektion oder Join ausgeführt werden. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 30 / 63

31 SQL Anfragen über mehrere Relationen Welcher Professor liest Mäeutik? select Name, Titel from Professoren, Vorlesungen where PersNr = gelesenvon and Titel = Mäeutik In der relationalen Algebra sieht das wie folgt aus: π Name,T itel (σ P ersnr=gelesenv on T itel= Mäeutik (P rofessoren V orlesungen)) Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 31 / 63

32 SQL Übersetzung von SQL in die relationale Algebra Allgemeine Form einer (ungeschachtelten) SQL-Anfrage: Übersetzung in die relationale Algebra: π A1,...,A n (σ P (R 1... R k )) select A 1,..., A n from R 1,..., R k where P ; π A1,...,A n σ P R k R 3 R 1 R 2 Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 32 / 63

33 SQL Anfragen über mehrere Relationen Welche Studenten hören welche Vorlesungen? select Name, Titel from Studenten, hören, Vorlesungen where Studenten.MatrNr=hören.MatrNr and hören.vorlnr = Vorlesungen.VorlNr; Alternativ: select s.name, v.titel from Studenten s, hören h, Vorlesungen v where s.matrnr=h.matrnr and h.vorlnr = v.vorlnr; Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 33 / 63

34 Transaktionsverwaltung Eigenschaften von Transaktionen: ACID Atomicity (Atomarität): Alles oder nichts Consistency: Konsistenter Zustand der DB konsistenter Zustand Isolation: Jede Transaktion hat die DB für sich allein Durability (Dauerhaftigkeit): Änderungen erfolgreicher Transaktionen dürfen nie verloren gehen. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 34 / 63

35 Transaktionsverwaltung Mehrbenutzersynchronisation Das I in ACID. Ausführung der drei Transaktionen T 1, T 2 und T 3 : (a) im Einzelbetrieb (b) im (verzahnten) Mehrbenutzerbetrieb Man möchte, dass die verzahnte Ausführung semantisch äquivalent zu einer seriellen Ausführung (d.h. z.b. t 1 t 3 t 2 ) ist. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 35 / 63

36 Transaktionsverwaltung Transaktionen bei System-Crash Absturz T 1 T 2 t 1 t 2 t 3 Zeit Wie verhält sich solch ein Szenario mit ACID? Was muss beachtet werden? Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 36 / 63

37 Übersicht Übersicht Vorlesung Datenbanksysteme Übersicht, Wiederholung Motivation, Wiederholung aus InSy (Tabellen, relationale Algebra, SQL) Organisation der VL und Regeln zum Übungsbetrieb Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 37 / 63

38 Übersicht Übersicht Anfrageverarbeitung Zugriffskosten Datenbankpuffer-Verwaltung (LRU-k, CLOCK,...) Indexe Index-Tuning Implementierung von Operatoren (Joins, externes Sortieren,...) Histogramme, Sketches Performance-Tuning Schema Denormalisierung Entschachtelung von Anfragen Multi-Query-Optimierung Materialisierte Sichten Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 38 / 63

39 Übersicht Übersicht Anfrageoptimierung Prinzip und regelbasierte Optimierung (Wiederholung InSy) Kostenmodelle für Joins Join-Ordering: Dynamische Programmierung, Greedy Algorithmen Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 39 / 63

40 Übersicht Übersicht Indexstrukturen und Hashing Mehrdimensionale Objekte (R-Baum) Hohe Dimensionen (LSH) Quad-Tree,... Indexierung im metrischen Raum (M-Baum) Erweiterbares/Lineares Hashing Nächste-Nachbar-Anfragen, Skylines und Top-k Algorithmen Nächste-Nachbarn-Anfragen im R-Baum Fagin s Algorithmus, Schwellwert-Algorithmen Skyline Operator Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 40 / 63

41 Übersicht Übersicht Transaktionsverwaltung Transaktionskonzept, Ablauf von Transaktionen Commit-Protokolle Serialisierbarkeit Anomalien im Mehrbenutzerbetrieb Theorie der Serialisierbarkeit Klassen von Historien Synchronisation und Sperrverfahren Sperrprotokolle Nicht-sperrende Protokolle Zweiphasen-Sperrprotokolle Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 41 / 63

42 Übersicht Übersicht Logging und Recovery Fehlermodelle und Recovery-Arten Logging-Strategien Sicherungspunkte Probabilistische Datenbanken Konzept der möglichen Welten Intensionale vs. Extensionale Auswertung und Komplexität Neuere Entwicklungen im Bereich Datenbanksysteme Column-Stores In-Memory-Datenbanken Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 42 / 63

43 Übersicht Übersicht MapReduce MapReduce Grundlagen Joinberechnung in MapReduce evtl. Datenschutz und Zugriffskontrolle Technische Probleme des Datenschutzes Konzepte der Zugriffskontrolle, Zugriffskontrolle in SQL Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 43 / 63

44 Übersicht Literaturliste A. Kemper und A. Eickler. Datenbanksysteme. Oldenbourg-Verlag, T. Härder und E. Rahm. Datenbanksysteme. Springer H. Garcia-Molina, J. Ullman, J. Widom. Database Systems - The Complete Book. Pearson Prentice Hall R. Elmasri, S. Navathe. Fundamentals of database systems. Pearson R. Ramakrishnan und J. Gehrke. Database Management Systems H. Samet. Foundations of Multidimensional and Metric Data Structures. Morgan Kaufmann Publishers G. Weikum und G. Vossen. Transactional Information Systems. Morgan Kaufmann Publishers Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 44 / 63

45 Organisatorisches Organisatorisches Vorlesung 4 SWS Vorlesung: Wöchentlich, Dienstags und Donnerstags. Dienstags, Raum , 11:45 bis 13:15 Uhr Donnerstags, Raum , 15:30 bis 17:00 Uhr 2 SWS Übung: Wöchentlich, Mittwochs. 8:15 bis 9:45. Raum : Übungsgruppenleiter: Manuel Hoffmann. 15:30 bis 17:00. Raum : Übungsgruppenleiter: Marc Dörr. Klausur Abschlussklausur am 19. Februar 2017 (Stand der Planung) Zweite Klausur am 26. März 2017 (Stand der Planung) Für die Zulassung zur Klausur bedarf es einer erfolgreichen Teilnahme am Übungsbetrieb. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 45 / 63

46 Organisatorisches Regeln zum Übungsbetrieb Melden Sie sich im OLAT für die Übung an. Zugangscode: force-nosteal Zulassungskriterien Es gibt insgesamt 50 Aufgaben verteilt auf 12 Blätter. Mit dem korrekten und vollständigen Bearbeiten jeder Aufgabe können Sie jeweils einen Punkt erreichen. Um die Zulassung zur Abschlussklausur zu bekommen, müssen Sie 35 der insgesamt 50 Punkte erhalten (Bearbeitungspunkte). 15 der 50 Aufgaben müssen Sie in der Übung vorstellen können (Präsentationspunkte). Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 46 / 63

47 Organisatorisches Regeln zum Übungsbetrieb (2) Abgabe Für jedes Übungsblatt gibt es eine Frist - in der Regel Montag 16:00 Uhr MEZ - zu der die Aufgaben als PDF in OLAT abgegeben werden müssen. Die Abgabe erfolgt in Zweiergruppen und besteht aus einem PDF pro Übungsblatt. Darüber hinaus müssen Sie individuell markieren, ob Sie für diese Aufgabe einen Präsentationspunkt erhalten möchten. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 47 / 63

48 Organisatorisches Regeln zum Übungsbetrieb (3) Bepunktung Die Bearbeitungspunkte werden von uns zeitnah nach der Abgabe vergeben, wenn Sie die jeweilige Aufgabe vollständig und korrekt bearbeitet haben. Um einen Präsentationspunkt zu erhalten, müssen Sie die entsprechende Aufgabe im OLAT markieren. In der nächsten Übung zeichnen Sie auf einer Liste gegen, dass Sie diese Aufgabe vorrechnen wollen, und unter allen Kandidaten wählt Ihr Tutor einen aus, welcher dann seine Lösung präsentiert, falls diese komplett richtig bearbeitet wurde. Wurde die Aufgabe nicht komplett richtig bearbeitet, wird der Präsentationspunkt nicht anerkannt. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 48 / 63

49 Organisatorisches Vorlesungsfolien und Übungsblätter Vorlesungsfolien Ein in der Regel recht vollständiger Draft wird einen Tag vor der Vorlesung online gestellt. Stabile Version folgt dann nach der VL (bzgl. Typos, Anmerkungen,...). Übungsblätter Ausgabe in der Regel Dienstags in der Vorlesung. Abgabe via OLAT bis Montag der darauffolgenden Woche (Abgabetermin ist auf Übungsblatt angegeben) Besprechung in den folgenden Übungen. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 49 / 63

50 Anfrageverarbeitung Postgresql Einschub In dieser Vorlesung wird Postgresql verwendet/betrachtet The world s most advanced open source database Einfach zu installieren Gute SQL-Unterstützung Transaktionen Gute Dokumentation (es gibt auch Bücher dazu) Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 50 / 63

51 Anfrageverarbeitung Postgresql Einschub Beispieldatenbanken zum Üben Installieren Sie eine aktuelle Version von Postgresql. Folgende Daten stellen wir Ihnen als Postgresql-Dump bereit: 1. Die Universitäts-Datenbank 2. Eine bereits generierte Version des TPC-H Benchmark-Datensatzes können Sie hier herunterladen: dbs/protected/tpch.dmp.gz dbs/protected/uni_db.dmp Login wird benötigt (außerhalb der Uni): Benutzername: dbs1718 Passwort 1 : 1 Wird/Wurde in der VL bekannt gegeben Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 51 / 63

52 Anfrageverarbeitung Postgresql Einschub PSQL: Command Line Interface Anfragen ausführen, Schema anlegen, Daten aus CVS-Dateien laden, Skripte ausführen,... siehe Befehlsübersicht via \? Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 52 / 63

53 Anfrageverarbeitung Postgresql Einschub Beispiel: Datenbank erzeugen und Dump einspielen Datenbank erzeugen In GUI oder via command line: createdb university Daten einspielen Mit GUI oder via command line (und psql Kommando): psql university < uni db.dmp Achtung: es gibt auch backup/restore. Dumps sind reine SQL Statements und Daten, werden erzeugt mit pg dump databasename Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 53 / 63

54 Anfrageverarbeitung Postgresql Einschub PGAdmin3 User Interface: Download unter Features Query Builder Sehr anschauliche Darstellung von Ausführungplänen (explain plan) Komfortable Administration (Benutzer, Rechteverwaltung,...) Im OLAT gibt es ein paar Videos zu pgadmin bzw. Import von Daten-Dumps in Postgresql. Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 54 / 63

55 Anfrageverarbeitung Postgresql Einschub PGAdmin3 (2) Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 55 / 63

56 Anfrageverarbeitung Postgresql Einschub PGAdmin3: query builder (1) Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 56 / 63

57 Anfrageverarbeitung Postgresql Einschub PGAdmin3: query builder (2) Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 57 / 63

58 Anfrageverarbeitung Postgresql Einschub PGAdmin3: query builder (3) Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 58 / 63

59 Anfrageverarbeitung Postgresql Einschub PGAdmin3: query builder (4) Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 59 / 63

60 Anfrageverarbeitung Postgresql Einschub PGAdmin3: query builder (5) Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 60 / 63

61 Anfrageverarbeitung Postgresql Einschub PGAdmin3: query builder (6) Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 61 / 63

62 Anfrageverarbeitung Postgresql Einschub Postgresql/PGAdmin3: Explain Plan (1) Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 62 / 63

63 Anfrageverarbeitung Postgresql Einschub Postgresql/PGAdmin3: Explain Plan (2) Prof. Dr.-Ing. S. Michel TU Kaiserslautern Datenbanksysteme, WS 17/18 63 / 63