Einführung und Überblick Kapitel I Vorlesung Datenbanksysteme Univ.-Prof. Dr. Günther Specht Universität Innsbruck Institut für Informatik Datenbanken und Informationssysteme (DBIS) Vorlesungsinhalt 1. Einführung und Überblick Motivation Definitionen Verschiedene Benutzergruppen Anforderung an ein Datenbanksystem Transaktionsprinzip Life Demo Database Architektur eines DBS (3-Schichten-Modell) Historische Entwicklung 2 G. Specht: Datenbanksysteme 1-1
Motivation 3 Motivation Bisher bekannt: Programme (flüchtige Verarbeitung) Dateien im Dateisystem (für persistente Ablage von Daten) Problem: In bestimmten Situationen kann das Arbeiten mit Dateien im Dateisystem zu Problemen führen 4 G. Specht: Datenbanksysteme 1-2
Motivation Führt zu Problemen: 1. wenn sehr viele Daten vorhanden sind (z. B. Telefonbuch für EU). Dann ist die sequentielle Suche auf Dateien ineffizient. 900 Mio. Anschlüsse, 1 Eintrag ca. 1000 Byte 900 x 10 6 x 10 3 = 900 Gbyte Nicht mehr vernünftig als Datei realisierbar. (Stichwort: Effizienz) 5 Motivation Führt zu Problemen: 1. Stichwort: Effizienz 2. wenn zwei Benutzer gleichzeitig dieselben Daten ändern. Beispiel: Kontoänderung Benutzer 1 Benutzer 2 read Konto -> 1000 add 200 write Konto 1200 read Konto -> 1000 sub 400 write Konto 600 (Stichwort: Serialisierung) 6 G. Specht: Datenbanksysteme 1-3
Motivation Führt zu Problemen: 1. Stichwort: Effizienz 2. Stichwort: Serialisierung 3. wenn zwei Änderungen auf zwei Dateien nur gemeinsam oder gar nicht für andere sichtbar sein sollen,. z.b. Überweisung = Abbuchung + Gutschrift (Saldo muß stimmen) (Stichwort: Transaktion) 7 Motivation Führt zu Problemen: 1. Stichwort: Effizienz 2. Stichwort: Serialisierung 3. Stichwort: Transaktionen 4. beim Rücksetzen nach Systemabsturz (ca. 2 x pro Jahr). Daten auf Datei: letzte Sicherung (ca. 1 x pro Tag erstellt) wiedereinlesen, alles andere nochmal machen! Bei Bank-Anwendung indiskutabel! Korrektes Rücksetzen direkt auf Situation vor Absturz nötig! (Stichwort: Recovery) 8 G. Specht: Datenbanksysteme 1-4
Motivation Führt zu Problemen: 1. Stichwort: Effizienz 2. Stichwort: Serialisierung 3. Stichwort: Transaktionen 4. Stichwort: Recovery 5. beim Datenschutz (z.b.: Sekretärin darf nur Adressen sehen, nicht Spalte mit Einkommen.) Bei Dateien nur eingeschränkter Lesezugriff auf die ganze Datei möglich, nicht auch auf einzelne Datensätze. (Stichwort: Views) 9 Motivation Weitere typische Probleme bei Informationsverarbeitung ohne DBMS sind: Redundanz und Inkonsistenz Verlust von Daten Integritätsverletzung Sicherheitsprobleme hohe Entwicklungskosten für Anwendungsprogramme Lösung: Einsatz von Datenbanksystemen 10 G. Specht: Datenbanksysteme 1-5
Definitionen 11 Definitionen Datenbank (DB) Konkrete Anwendung mit konkreten Daten (z.b. Zugauskunft, Bibliotheksystem, Flugbuchungen). Läuft immer auf einem Datenbanksystem. Datenbanksystem (DBS) Stellt die Speicherstrukturen, Zugriffsoperationen, Datenverwaltung und Schutzmechanismen zur Verfügung. 12 G. Specht: Datenbanksysteme 1-6
Definitionen cont. Zusammenfassung Zwei Hauptunterschiede zwischen DBS und anderen Programmsystemen (z.b. Dateisystemen) Sichere Verwaltung langlebiger Daten Effiziente Verwaltung sehr großer Datenbestände 13 Information und Daten Information: Kenntnis von Fakten und Wissen. Nicht notwendigerweise formalisiert. Daten: Formalisierte Darstellung der Information, geeignet für angestrebten Gebrauch Problem der Datendarstellung: Welche Darstellung der Daten ist am besten? Oft verschiedenartige Anfragen (wenn Daten falsch modelliert sind, kann die Antwort ineffizient werden) 14 G. Specht: Datenbanksysteme 1-7
Information und Daten cont. Beispiel: Österreichische Bundesbahnen ÖBB, Information über Fahrpläne Tarife Lokomotiven Wagenstand Personalbestand / Personaleinsatz Streckennetz usw. Fahrplan ist nach Abfahrt und Ankunft organisiert und nach Zeit geordnet Aber: Abfahrt Zug von St. Wendel nach Innsbruck Abfahrt [8-10] kürzeste Fahrzeit ist damit nicht lösbar Ankunft Dafür gibt es das Kursbuch (Information geordnet nach Strecken andere Modellierung derselben Information) 15 Information und Daten cont. Zusammenfassung Es gibt also für verschiedene Benutzer verschiedene Sichten (Views) auf den Gesamtbestand der Daten. Die Information sollte aber nur einmal in der Datenbank gespeichert sein (sonst Probleme mit Redundanz, Inkonsistenz bei Updates). 16 G. Specht: Datenbanksysteme 1-8
Verschiedene Benutzergruppen 17 Verschiedene Benutzergruppen Aufgaben des DB-Designers Geeignete Modellierung der Information Formalisierung und interne Ablage der Daten festlegen (Welche Daten habe ich? Welche Anfragen werden gestellt werden?) Definition von Sichten (für mehrfache Nutzung der Daten unter verschiedenen Aspekten) Effiziente Zugriffsstrukturen festlegen Spezifikation von Operationen für Anfragen Vorsicht: Nachträgliche Änderungen sind teuer! 18 G. Specht: Datenbanksysteme 1-9
Verschiedene Benutzergruppen cont. Aufgaben des DB-Anwendungsprogrammierer Erstellt Programme in C, PL/I, Java, etc., die mit der Datenbank arbeiten, z.b. zum Suchen, Einfügen, Löschen, Ändern (meist über einen E-SQL-Anschluss) 19 Verschiedene Benutzergruppen cont. Aufgaben des DB-Administrators (privilegierter Benutzer) Einspoolen von Daten Vergabe von Rechten neue Benutzer eintragen Sicherung Systempflege DB tunen (z. B. durch Anlegen weiterer Zugriffsstrukturen) aber auch verantwortlich für Datenschutz,... Entspricht root - super user bei Betriebssystemen! 20 G. Specht: Datenbanksysteme 1-10
Verschiedene Benutzergruppen cont. Endbenutzer Interagiert mit DB über Applikationsprogramme und Benutzerschnittstellen (Masken, Menüs,...) Weiß nichts mehr vom Datenmodell, Zugriffstrukturen, etc. 21 Anforderung an ein Datenbanksystem 22 G. Specht: Datenbanksysteme 1-11
Anforderung an ein Datenbanksystem 1. Sichere Verwaltung langlebiger Daten 2. Effiziente Verwaltung sehr großer Datenbestände 3. Klare Semantik: Unterstützung eines mathematischen Datenmodells (z.b.: Relationen, Hierarchien, Netze, Prädikatenlogik,... Algebra dafür muss definiert sein!) 4. Unterstützung von problemadäquaten Datenbank-Sprachen Data Definition Language (DDL) Data Manipulation Language (DML) Data Retrieval Language, Querysprache (DRL) 5. Datenschutz: Schutz vor Manipulation und unbefugtem Zugriff (Maßnahme: Hierarchie an Zugriffsrechten, Views, etc.) 23 Anforderung an ein Datenbanksystem cont. 6. Datensicherheit: Daten müssen konsistent und gültig sein, keine Falscheinträge. Sollte zentral vom DBS selbst überwacht werden. Achtung: Fehler in Datensicherheit (d.h. falsche Daten) oft genauso gefährlich, wie Fehler beim Datenschutz (Beispiel: KSV 1870) 7. Simultanzugriff: Parallele Ausführung von Datenbank-Programmen notwendig korrekte Synchronisation durch DBS selbst, Konsistente Ablaufsteuerung (vgl. Abschnitt Transaktionskonzept) 8. Forderung nach großer Verfügbarkeit, hohem Durchsatz (= großer Transaktionsrate) besonders im Online-Betrieb: hohe Transaktionsraten, z.b. DBS Amadeus Flugbuchungen: 1000 Transaktionen pro Sekunde! 24 G. Specht: Datenbanksysteme 1-12
Anforderung an ein Datenbanksystem cont. 9. Recovery (Zurücksetzen, Wiederanlauf): Integritätsverletzungen, TA-Fehler (mehrmals pro Minute) Verlust von Daten nach Systemfehler, z.b. Betriebssystem-Fehler, Hauptspeicherausfall, Platte noch ok, alle Puffer leer (2x pro Jahr) Plattencrash (1x pro Jahr) Jeweils konsistenter Zustand muss wieder erreicht werden Log-Datei mitschreiben, regelmäßig sichern, Extremfall: Spiegelplatten (Tandem) Spezielle Algorithmen für Undo bzw. Redo 25 Transaktionskonzept (TA) 26 G. Specht: Datenbanksysteme 1-13
Transaktionskonzept (TA) Eine Transaktion (TA) T ist eine endliche Folge von Datenbank-Operationen (Lesen, Schreiben, Löschen), mit folgenden Eigenschaften: Die Änderungen von T sind atomar entweder alle oder keine (z.b.: Überweisen = Abbuchung + Gutschrift (auch keine Aktion ist korrekter Zustand) T führt einen korrekten Datenbankzustand wieder in einen korrekten Datenbankzustand über. Während T befindet sich der Benutzer in einem virtuellen Einbenutzerbetrieb, d.h. seine Änderungen sind für andere noch nicht sichtbar (Isolation) Wirksame Änderungen von T (commit) sind dauerhaft (auf der Festplatte, nicht im Puffer) 27 ACID-Transaktionen Auf Grund des Transaktionskonzeptes spricht man oft von ACID-Transaktionen A= Atomicity C= Consistency I = Isolation D= Durability 28 G. Specht: Datenbanksysteme 1-14
Transaktionskonzept Wichtig Das TA-Konzept ist ein anwendungsunabhängiger Mechanismus zur Strukturierung und Kontrolle von Datenbankaktionen Das TA-Konzept verbirgt die Synchronisation und Recovery Aspekte (Code!) vor dem Datenbank-Anwendungsprogrammierer Das TA-Konzept realisiert somit einen virtuellen Einbenutzerbetrieb Damit ist das TA-Konzept der entscheidende Unterschied zwischen DBS und einem konventionellen Filesystem 29 Beispiel Schematisches Beispiel: Geldüberweisung... start_ta T 1 : Lese Kontostand Konto1 x if x < Dispositionskredit then abort_ta T 1 fi Schreibe Kontostand Konto1 := Konto1 - x Schreibe Kontostand Konto2 := Konto2 + x commit_ta T 1... mit Konsistenzbedingung: Konto1 alt + Konto2 alt = Konto1 neu + Konto2 neu 30 G. Specht: Datenbanksysteme 1-15
Transaktionskonzept Größerer Kontext boot DB Konten login db_user_1 (connect) : TA 1.1 Zustandsübergangsgraph Fehler Zustand TA 1.2 : TA 1.n logout (disconnect) [shutdown DB Konten ] abort TA retrieval update Operation Start begin TA interner Zustand commit TA neuer Zustand Sichtbar Für Andere Sichtbar Für Andere 31 Transaktionskonzept Forderung: Serialisierbarkeit paralleler TAs Definition: {T 1,..., T n } Menge paralleler TAs (T 1,..., T n ) Tupel, Folge serieller TAs Ablaufsteuerung ist konsistent (i 1,..., i n ): Wirkung von {T 1,..., T n } Wirkung von (T i1,..., T in ). {T 1,..., T n } heißen dann serialisierbar [1]. 32 G. Specht: Datenbanksysteme 1-16
Transaktionskonzept Das Beispiel der Kontofalschbuchung (aus der Einleitung) ist nicht mehr möglich: Konto = 1000 start TA 1 start TA 2 read Konto -> a read Konto -> b a = a + 200 write (a) commit TA 1 b = b 400 write (b) commit TA 2 Das Datenbanksystem sorgt dafür, dass entweder (TA1, TA2) oder (TA2, TA1) aber kein Mix durchgeführt wird. Jeweils korrekter Endkontostand: 800 Der Benutzer braucht sich darum nicht zu kümmern, da er im DBS nur unter Transaktionsschutz arbeiten kann. 33 Architektur eines DBS 34 G. Specht: Datenbanksysteme 1-17
Die Abstraktionsebenen eines Datenbanksystems Sicht1 Sicht 2... Sicht 3 Konzepuelle/Logische Ebene Physische Ebene Datenunabhängigkeit Physische Unabhängigkeit Logische Datenunabhängigkeit 35 Architektur eines DBS (3-Schichten-Modell) Abstraktionsebenen Datenbank wird auf unterschiedlichen Abstraktionsniveaus gesehen 3-Schichten-Architektur (ANSI/X3/SPARC) Physische (interne) Schicht Konkrete Implementation der Datenbank als Kollektion von Feldern mit ihren Größen Recordstrukturen Dateien, Seiten Zugriffspfade, d.h. Indexen, Hashtabellen, B-Bäumen, B*-Bäumen und Zeigerstrukturen Bemerkung Benutzergruppe 1 Transformation View 1 Transformation Physische DB Daten werden auf Sekundärspeicher (z.b. Festplatte) abgelegt. View n Konzeptuelle / Logische DB Transformation Benutzergruppe n Externe Sichten der DB Externe Schemata Konzeptionelle/ Logische Sicht der DB Konzeptionelles/Logisches Schemata Interne Sicht der DB Internes Schemata Die Performance hängt wesentlich von der Auslegung der physischen Datenbank ab! 36 G. Specht: Datenbanksysteme 1-18
Architektur eines DBS cont. Konzeptuelle (logische) Schicht Modelliert den gesamten Anwendungsbereich Integrierte, einheitliche Darstellung aller Daten ohne Redundanz Implementiert mittels DDL Die konzeptuelle/logische Schicht bietet Eine physische Datenunabhängigkeit: Repräsentation der Daten unabhängig von physischer Speicherung (= interne Schicht), d.h. man kann interne Schicht ändern (z.b. B-Bäume statt Hashtabellen für schnelleren Zugriff anlegen, Tuning!), ohne konzeptuelle Schicht zu ändern. Eine logische Datenunabhängigkeit: Repräsentation der Daten unabhängig von externer Schicht, d.h. neuer Benutzer kann neue Views nötig haben, ohne dass sich deshalb die konzeptuelle Schicht und die interne Schicht ändern! 37 Architektur eines DBS cont. View (externe) Schicht Eine View repräsentiert eine spezielle Sicht einer bestimmten Benutzergruppe auf die Daten. Bezugspunkt für die View ist die logische Schicht. Datenbank-Queries und Datenbank-Updates werden implementiert mittels DRL und DML 38 G. Specht: Datenbanksysteme 1-19
Architekturübersicht eines DBMS Naive Benutzer Fortgeschrittene Benutzer Anwendungs- Programmierer Datenbank Administratoren Anwendung Interaktive Anfrage Präcompiler Verwaltungswerkzeug DML-Compiler DDL-Compiler Anfragebearbeitung DBMS Datenbankmanager Schemaverwaltung Mehrbenutzersynchr. Fehlerbehandlung Dateiverwaltung Logdateien Indexe Datenbasis Datenwörterbuch Hintergrundspeicher 39 Historische Entwicklung 40 G. Specht: Datenbanksysteme 1-20
Historische Entwicklung Historische Modelle : Erste DBS entstanden aus Dateisystemen, Hierarchische DBS: IMS von IBM, 60er Jahre Netzwerk DBS: (= CODASYL DBS), UDS von Siemens, Anfang der 70er Jahre Heutiges Modell : Relationale DBS Prototypen seit 70er Jahren (System R, IBM) Ingres, University of California, Berkeley Kommerzielle Produkte seit 80er Jahren Heute wichtigste kommerziell verfügbare Datenbankttechnologie für neue Anwendungen Inzwischen sind viele relationale DBS auf dem Markt MySQL und Postgres sind frei und tauchen daher hier nicht auf DBS Hersteller Marktanteil 05 Marktanteil 06 Oracle Oracle 46.8 % 47.1 % DB/2 IBM 22.1 % 21.1 % SQL-Server Microsoft 15.6 % 17.4 % Teradata Teradata 3.5 % 3.2 % Sybase Sybase 3.4 % 3.2 % andere 8.6 % 7.9 % Quelle: Gartner Dataquest (Juni 2007) 41 Historische Entwicklung cont. 42 G. Specht: Datenbanksysteme 1-21
Historische Entwicklung cont. Weitere Zwischenschritte Verteilte DBS enf2-systeme Hochleistungs-Transaktions-Systeme Deduktive DBS 43 Historische Entwicklung cont. Neuere Entwicklungen Bild-DBS, Musik- und Video- DBS, Mobile DBS Suchmaschinen Web-Archive Data Warehouse Systeme alle Einträge (Postings, etc.) in Sozialen Netzwerken werden über DB verwaltet Neueste Entwicklungen Key-Value DBS NonSQL DBS NewSQL DBS 44 G. Specht: Datenbanksysteme 1-22