Warum Datenbank-Vorlesung? Überblick

Transkript

1 Warum Datenbank-Vorlesung? /2 große Herausforderungen: Verwaltung von Daten im TB-Bereich, viele Nutzer weltweit verteilte Datenbestände Multimedia-Inhalte Hochverfügbarkeit, Sicherheit DB-Kenntnisse unverzichtbar für *Informatik-Berufe: Administration, Planung/Entwurf, Entwicklung, Nutzung Vorlesung Datenbanken Martin-Luther-Universität Halle, WS 02/03 Kai-Uwe Sattler nken I 0 2 Überblick Warum Datenbank-Vorlesung? 1. Grundlegende Konzepte und Architekturen 2. Datenbankmodelle für den Entwurf 3. Datenbankmodelle für die Realisierung 4. Datenbankentwurf und Datendefinition 5. Anfrage- und Änderungsoperationen 6. Relationale Datenbanksprachen 7. Datenbank-Anwendungsprogrammierung 8. Integrität und Trigger 9. Sichten, Datenschutz 10. Transaktionsverwaltung 11. Dateiorganisation und Indexstrukturen Datenbanksysteme als Basis moderner Softwaresysteme: Web-basierte Systeme (ebay, Amazon, ) ERP-Systeme (SAP R/3), CRM-Systeme, Finanzsysteme administrative Anwendungen wiss. Anwendungen (Sloan Sky Survey, NASA Ear Observation System, Human Genom Project, ) Querbezüge zu anderen Bereichen der Informatik: Modellierung, Datenstrukturen, Theorie, Betriebssysteme/Verteilte Systeme, Sicherheit, Multimedia, nken I 0 3

2 Ohne Datenbanken: Datenredundanz Literatur Basis- oder Anwendungssoftware verwaltet ihre eigenen Daten in ihren eigenen (Datei-)Formaten Textverarbeitung: Texte, Artikel und Adressen Buchhaltung: Artikel, Adressen Lagerverwaltung: Artikel, Aufträge Auftragsverwaltung: Aufträge, Artikel, Adressen CAD-System: Artikel, Technische Bausteine Daten sind redundant: mehrfach gespeichert; Probleme: Verschwendung von Speicherplatz, Vergessen von Änderungen; keine zentrale, genormte Datenhaltung Heuer, A., Saake, G.: Datenbanken Konzepte und Sprachen. 2. Aufl., mitp-verlag, Bonn, Januar 2000 Vossen, G.; Datenbankmodelle, Datenbanksprachen und Datenbankmanagement-Systeme. Oldenbourg, München, 2000 Heuer, A., Saake, G., Sattler, K.; Datenbanken kompak mitp-verlag, Bonn, 2001 Elmasri, R.; Navathe, S.B.; Fundamentals of Database Systems. Addison-Wesley, 1999 Date, C.J.; An Introduction to Database Systems Addison-Wesley, Reading, 1999 nken I 1 2 Ohne Datenbanken: Datenredundanz II 1. Grundlegende Konzepte Andere Software-Systeme können große Mengen von Daten nicht effizient verarbeiten Mehrere Benutzer oder Anwendungen können nicht parallel auf den gleichen Daten arbeiten, ohne sich zu stören Anwendungsprogrammierer / Benutzer können Anwendungen nicht programmieren / benutzen, ohne interne Darstellung der Daten Speichermedien oder Rechner zu kennen (Datenunabhängigkeit nicht gewährleistet) Datenschutz und Datensicherheit sind nicht gewährleistet Motivation und Historie Komponenten und Funktionen Einsatzgebiete und Grenzen Entwicklungslinien Schema-Architektur System-Architekturen nken I 1 3

3 Historie von RDBMS Mit Datenbanken: Datenintegration 1970: Ted Codd (IBM) Relationenmodell als konzeptionelle Grundlage relationaler DBS 1974: System R (IBM) erster Prototyp eines RDBMS zwei Module: RDS, RSS; ca LOC (PL/1, PL/S, Assembler), ca. 1,2 MB Codegröße Anfragesprache SEQUEL erste Installation : University of California at Berkeley (UCB) Ingres Anfragesprache QUEL Vorgänger von Postgres, Sybase, 1979: Oracle Version 2 Die gesamte Basis- und Anwendungssoftware arbeitet auf denselben Daten, z.b. Adressen und Artikel werde nur einmal gespeichert Datenbanksysteme können große Datenmengen effizient verwalten (Anfragesprachen, Optimierung, Interne Ebene) Benutzer können parallel auf Datenbanken arbeiten (Transaktionskonzept) Datenunabhängigkeit durch 3-Ebenen-Konzept Datenschutz (kein unbefugter Zugriff) und Datensicherheit (kein ungewollter Datenverlust) werden vom System gewährleistet nken I 1 6 Prinzipien Historie DBMS: Datenbank-Management-System DBS: Datenbanksystem (DBMS + Datenbank) Anwendung 1... Anwendung n DBMS Anfang 60er Jahre: elementare Dateien, anwendungsspezifische Datenorganisation (geräteabhängig, redundant, inkonsistent) Ende 60er Jahre: Dateiverwaltungssysteme (SAM, ISAM) mit Dienstprogrammen (Sortieren) (gerateunabhängig, aber redundant und inkonsistent) 70er Jahre: Datenbanksysteme (Geräte- und Datenunabhängigkeit, redundanzfrei, konsistent) Datenbank nken I 1 7

4 Die neun Codd schen Regeln Prinzipien II 1. Integration: einheitliche, nichtredundante Datenverwaltung 2. Operationen: Speichern, Suchen, Ändern 3. Katalog: Zugriffe auf Datenbankbeschreibungen im Data Dictionary 4. Benutzersichten 5. Integritätssicherung: Korrektheit des Datenbankinhalts 6. Datenschutz: Ausschluß unauthorisierter Zugriffe 7. Transaktionen: mehrere DB-Operationen als Funktionseinheit 8. Synchronisation: parallele Transaktionen koordinieren 9. Datensicherung: Wiederherstellung von Daten nach Systemfehlern Grundmerkmale verwalten persistente (langfristig zu haltende) Date verwalten große Datenmengen effizient Datenbankmodell, mit dessen Konzepten alle Daten einheitlich beschrieben werden (Integration) Operationen und Sprachen (DDL, IQL, DML, ) deskriptiv, getrennt von einer Programmiersprache Transaktionskonzept, Concurrency Control: logisch zusammenhängende Operationen atomar (unteilba Auswirkungen langlebig, können parallel durchgeführt werden Datenschutz, Datenintegrität (Konsistenz), Datensicherheit nken I 1 10 Konzeptuelle Ebene: Relationenmodell I Prinzipien III Konzeptuell ist die Datenbank eine Menge von Tabellen AUSLEIH INV.NR NAME 4711 Meyer 1201 Schulz 0007 Müller 4712 Meyer BUCH INV.NR TITEL ISBN AUTOR 0007 Dr. No James Bond 1201 Objektbanken Heuer 4711 Datenbanken Vossen 4712 Datenbanken Ullman 4717 PASCAL Wirth Tabellen = Relationen Grundprinzip moderner Datenbanksysteme 3-Ebenen-Architektur (physische Datenunabhängigkeit, logische Datenunabhängigke Trennung zwischen Schema (etwa Tabellenstruktur und Instanz (etwa Tabelleninhalt) angelehnt an 9 Codd sche Regeln: nken I 1 11

5 Anfrageoperationen I Konzeptuelle Ebene: Relationenmodell SELEKTION: Zeilen (Tupel) auswählen NAME Meyer (AUSLEIH) INVENTARNR NAME 4711 Meyer 4712 Meyer PROJEKTION: Spalten (Attribute) auswählen INVENTARNR, TITEL (BUCH) Achtung: doppelte Tupel werden entfernt! INVENTARNR TITEL 0007 Dr. No 1201 Objektbanken 4711 Datenbanken 4712 Datenbanken 4717 PASCAL Fett geschriebene Zeilen: Relationenschema Weitere Einträge in der Tabelle: Relation Eine Zeile der Tabelle: Tupel Eine Spaltenüberschrift: Attribut Relationenname R A1 An Attribute } Relationenschema Tupel Relation nken I 1 14 Anfrageoperationen II Integritätsbedingungen VERBUND (JOIN): Tabellen verknüpfen über gleichbenannte Spalten und gleiche Werte ergibt: INVENTARNR,TITEL BUCH NAME Meyer INVENTARNR TITEL NAME 4711 Datenbanken Meyer 4712 Datenbanken Meyer Weitere Operationen: Vereinigung, Differenz, Durchschnitt, Umbenennung AUSLEIH Alle Operationen beliebig kombinierbar ( Algebra ) Relationenschema lokale Integritätsbedingungen INVENTARNR ist Schlüssel für BUCH d.h. INVENTARNR darf nicht doppelt vergeben werden Datenbankschema ist Menge von Relationenschemata globale Integritätsbedingungen INVENTARNR in AUSLEIH ist Fremdschlüssel bezüglich BUCH d.h.: INVENTARNR taucht in einem anderen Relationenschema als Schlüssel auf nken I 1 15

6 Optimierer I Sprachen und Sichten I Problem: Finde einen Relationenalgebra-Ausdruck, der äquivalent ist ( das gleiche Ergebnis liefert ) wie der gegebene, aber effizienter auszuwerten ist Anfragesprache Interaktive Möglichkeit, Datenbankabfragen zu formulieren und zu starten Relationenalgebra Funktionen (SUM, MAX, MIN, COUNT, ) arithmetische Operationen eventuell graphisch verpackt SQL als Standard select BUCH.INVENTARNR, TITEL, NAME from BUCH, AUSLEIH where NAME = Meyer and BUCH.INVENTARNR = AUSLEIH.INVENTA nken I 1 18 Optimierer: Algebraische Optimierung Sprachen und Sichten II allgemeine Regel: 1. Konst ( REL1 2. Konst (REL1) sind äquivalent REL2 ) und A aus REL1 REL2 allgemeine Strategie: Selektionen möglichst früh, da sie Tupelanzahlen in Relationen verkleinern Beispiel: REL1 100 Tupel, REL2 50 Tupel intern: Tupel sequentiell abgelegt ( ) 5000 ( ) = Operationen ( ) ( ) = 600 Operationen falls 10 Tupel in REL1 die Bedingung Konst erfüllen Änderungs-Komponente: interaktive Möglichkeit Tupel einzugeben Tupel zu löschen Tupel zu ändern Lokale und globale Integritätsbedingungen werden geprüft! Definition von Benutzersichten Häufig vorkommende Datenbankabfragen können unter einem Sichtnamen als virtuelle Tabelle gespeichert werden. nken I 1 19

7 Zugriffe auf Plattenseiten Interne Strukturen Jede Operation (,,, Seitenzugriffen umgesetzt ) wird in optimale Folge von Ausnutzung von Zugriffspfaden und Dateiorganisation, wenn es dem System sinnvoll erscheint Bestimmung der Reihenfolge der Zugriffe nach vorliegenden Zugriffspfaden Beispiel: NAME Meyer INVENTARNUMMER AUSLEIH Annahme: auf NAME ist ein Zugriffspfad definiert, auf INVENTARNUMMER nicht System ändert die Reihenfolge der Selektionen!! Relation kann intern als Datei organisiert werden: Heap, ungeordnet Sequentiell, geordnet nach bestimmter Spalte Hash-organisiert, gestreut gespeichert, Adreßberechnung durch Formel Baumartig, Tupel in einem Suchbaum angeordnet Zusätzliche Zugriffspfade statischer Index, einstufig oder mehrstufig dynamischer Index beliebiger Wechsel zwischen Dateiorganisationen/ Zugriffspfaden möglich je schneller die Abfrage, desto langsamer der Update nken I 1 22 Einsatzgebiete und Grenzen Notwendigkeit für Zugriffspfade Klassische Einsatzgebiete: viele Objekte (15000 Bücher, 300 Benutzer, 100 Ausleihvorgänge pro Woche, ) wenige Objekttypen (BUCH, BENUTZER, AUSLEIHUNG) etwa Buchhaltungssysteme, Auftragserfassungssysteme, Bibliothekssysteme, Aktuelle Anwendungen: E-Commerce, entscheidungsunterstützende Systeme (Data Warehouses, OLAP), NASA s Earth Observation System (Petabyte-Datenbanken), Data Mining Beispiel: Tabelle mit 10 GB Daten, Festplattentransferrate ca. 10 MB/s Operation: Suchen eines Tupels (Selektion) Implementierung: sequentielles Durchsuchen Aufwand: sec. min. nken I 1 23

8 Datenbankgrößen (II) Einsatzgebiete und Grenzen II SAP R/3-Installation der Deutschen Telekom AG (1998) Financial Accounting: Rechnungen, Zahlungsaufforderungen, Lastschriften, Mahnungen etc. 15 SAP R/3-Systeme; jedes verarbeitet Rechnungen, Mahnungen, Änderungen von Kundendaten pro Tag bis zu jeweils 1000 Nutzer gleichzeitig über Datenbanktabellen Hardware: 51 Unix Enterprise Servern, 34 EMC-Speichersysteme (30 TB), 68 Magnetbandsysteme für Backup (Backup in 2h) Normalerweise sind herkömmliche Datenbanksysteme überfordert mit: CAD- oder andere technische Anwendungen (viele Objekte, viele Objekttypen, sehr strukturierte Objekte) ABER: Objektorientierte Datenbanksysteme Expertensysteme (wenige Objekte, viele Objekttypen, kompliziertere Operationen) ABER: Deduktive Datenbanksysteme nken I 1 26 Entwicklungslinien: 60er Jahre Datenbankgrößen DBS basierend auf hierarchischem Modell, Netzwerkmodell Zeigerstrukturen zwischen Daten Schwache Trennung interne / konzeptuelle Ebene Navigierende DML Trennung DML / Programmiersprache Sloan Digital Sky Survey 40 TB Himmelsdaten (Bilder und Objektinformationen); bis 20 WalMart Data Warehouse 24 TB Produktinfos (Verkäufe etc.) von Märkten; Anfragen/Woche US Library of Congress TB nicht digitalisiert Indexierbares WWW (1999) 6 TB ca. 800 Mill. Dokumente Microsofts TerraServer 3,5 TB unkomprimierte Bilder/Karten (komprimiert: ca. 1 TB); 174 Mill. Tupel nken I 1 27

9 Entwicklungslinien: heute Entwicklungslinien: 70er und 80er Jah Unterstützung für spezielle Anwendungen Multimediadatenbanken: Verwaltung multimedialer Objekte (Bilder, Audio, Video) XML-Datenbanken: Verwaltung semistrukturierter Daten (XML-Dokumente) Verteilte Datenbanken: Verteilung von Daten auf verschiedene Rechnerknoten Föderierte Datenbanken, Multidatenbanken, Mediatoren: Integration von Daten aus heterogenen Quellen (Datenbanken, Dateien, Web-Quellen) Mobile Datenbanken: Datenverwaltung auf Kleinstgeräten (PDA, Handy, ) Relationale Datenbanksysteme Daten in Tabellenstrukturen 3-Ebenen-Konzept Deklarative DML Trennung DML / Programmiersprache nken I 1 30 Schema-Architektur I Entwicklungslinien: (80er und) 90er Ja Zusammenhang zwischen Konzeptuellen Schema (Ergebnis der Datendefinition) Internen Schema (Festlegung der Dateiorganisationen und Zugriffspfade) Externen Schema (Ergebnis der Sichtdefinition) Anwendungsprogrammen (Ergebnis der Anwendungsprogrammierung) Wissensbanksysteme Daten in Tabellenstrukturen Stark deklarative DML, integrierte Datenbankprogrammiersprache Objektorientierte Datenbanksysteme Daten in komplexeren Objektstrukturen (Trennung Objekt und seine Daten) Deklarative oder navigierende DML Oft integrierte Datenbankprogrammiersprache Oft keine vollständige Ebenentrennung nken I 1 31

10 Datenunabhängigkeit I Schema-Architektur II Stabilität der Benutzerschnittstelle gegen Änderungen physisch: Änderungen der Dateiorganisationen und Zugriffspfade haben keinen Einfluß auf das konzeptuelle Schema logisch: Änderungen am konzeptuellen und gewissen externen Schemata haben keine Auswirkungen auf andere externe Schemata und Anwendungsprogramme Trennung Schema Instanz Schema (Metadaten, Datenbeschreibungen) Instanz (Anwenderdaten, Datenbankzustand oder -ausprägung) Datenbankschema besteht aus internem, konzeptuellen, externen Schema und den Anwendungsprogrammen im konzeptuellen Schema etwa: Strukturbeschreibungen Integritätsbedingungen Autorisierungsregeln (pro Benutzer für erlaubte DB-Zugriffe) nken I 1 34 Datenunabhängigkeit II Schema-Architektur III mögliche Auswirkungen von Änderungen am konzeptuellen Schema: externes Schema 1... externes Schema N eventuell externe Schemata betroffen (Ändern von Attributen) eventuell Anwendungsprogramme betroffen (Rekompilieren der Anwendungsprogramme, eventuell Änderungen nötig) konzeptuelles Schema Anfragebearbeitung Datendarstellung nötige Änderungen werden jedoch vom DBMS erkannt und überwacht internes Schema nken I 1 35

11 Ebenen-Architektur am Beispiel III Ebenen-Architektur am Beispiel I Externe Sicht: Daten in einer hierarchisch aufgebauten Relation Konzeptuelle Sicht: relationale Darstellung TITEL Autoren { Autor } Titel Jahr ISBN Meier Datenbasen I Ibsen Schulze UNIX X AUTOR Name Meier Schulze Ibsen Nr BuchID BUCH.BuchID BUCH BuchID Titel Jahr ISBN Datenbasen I UNIX X nken I 1 38 Ebenen-Architektur am Beispiel IV Ebenen-Architektur am Beispiel II Interne Darstellung Externe Sicht: Daten in einer flachen Relation Baumzugriff Autorname TITEL Name Nr Titel Jahr ISBN Anderson Ibsen Meier Schulze Heuer Ibsen Ibsen Jagellovsk DeMonti * * * * Hash-Tabelle Buchtitel UNIX X - Datenbasen 1 MZ4 antwortet nicht Meier Schulze Ibsen Datenbasen I UNIX X UNIX X nken I 1 39

12 ANSI-SPARC-Architektur II System-Architekturen Externe Ebene Anfragen Updates Konzeptuelle Ebene Optimierer Auswertung Interne Ebene Plattenzugriff Beschreibung der Komponenten eines Datenbanksystems Standardisierung der Schnittstellen zwischen Komponenten P1 DB-Operationen Data Dictionary Architekturvorschläge Pn Einbettung Masken Sichtdefinition Dateiorganisation ANSI-SPARC-Architektur Drei-Ebenen-Architektur Datendefinition Fünf-Schichten-Architektur beschreibt Transformationskomponenten nken I 1 42 Klassifizierung der Komponenten ANSI-SPARC-Architektur I Definitionskomponenten: Datendefinition, Dateiorganisation, Sichtdefinition Programmierkomponenten: DB-Programmierung mit eingebetteten DB-Operationen Benutzerkomponenten: Anwendungsprogramme, Anfrage und Update interaktiv Transformationskomponenten: Optimierer, Auswertung, Plattenzugriffssteuerung Data Dictionary (Datenwörterbuch): Aufnahme der Daten aus Definitionskomponenten, Versorgung der anderen Komponenten ANSI: American National Standards Institute SPARC: Standards Planning and Requirement Committee Vorschlag von 1978 Im Wesentlichen Grobarchitektur verfeinert Interne Ebene / Betriebssystem verfeinert Mehr Interaktive und Programmier-Komponenten Schnittstellen bezeichnet und normiert nken I 1 43

13 5-Schichten-Architektur: Schnittstellen II Fünf-Schichten-Architektur Pufferschnittstelle Seiten, Seitenadressen Freigeben und Bereitstellen Datei- oder Seitenschnittstelle Hole Seite, Schreibe Seite Geräteschnittstelle Spuren, Zylinder Armbewegungen basierend auf Idee von Senko 1973 Weiterentwicklung von Härder 1987 Umsetzung im Rahmen des IBM-Prototyps System R genauere Beschreibung der Transformationskomponenten schrittweise Transformation von Anfragen/Änderungen bis hin zu Zugriffen auf Speichermedien Definition der Schnittstellen zwischen Komponenten nken I Schichten-Architektur: Funktionen 5-Schichten-Architektur: Schnittstellen Mengenorientierte Schnittstelle (MOS) Datensystem Satzorientierte Schnittstelle (SOS) Zugriffssystem Interne Satz schnittstelle (ISS) Speichersystem Systempuffer schnittstelle (SPS) Pufferverwaltung Datei schnittstelle (DS) Geräte schnittstelle (GS) Betriebssystem Übersetzung, Zugriffspfadauswahl, Zugriffskontrolle, Integritätskontrolle Data Dictionary, Currency Pointer, Sortierung, Transaktionsverwaltung Record Manager, Zugriffspfadverwaltung, Sperrverwaltung, Log/Recovery Systempufferverwaltung mit Seitenwechselstrategie Externspeicherverwaltung mengenorientierte Schnittstelle deklarative DML auf Tabellen, Sichten, Zeilen satzorientierte Schnittstelle Sätze, logische Dateien, logische Zugriffspfade navigierender Zugriff interne Satzschnittstelle Sätze, Zugriffspfade Manipulation von Sätzen und Zugriffspfaden nken I 1 47

14 Oracle9i 5-Schichten-Architektur: Objekte Objektrelationales DBMS + Entwicklungswerkzeuge verfügbar für Unix, Linux, Windows, Palm, PocketPC etc. Enterprise, Personal, Mobile-Versionen Unterstützung von XML und Multimedia-Dokumenten Erweiterbarkeit über prozedurale SQL-Erweiterungen, Java Sicherheits- und Auto-Administration-Features Internet-Content-Management (HTTP-, FTP-, WebDAV-Zugriff), Application Server Data Warehouse und Business Intelligence (OLAP, Data Mining) Unterstützung von verteilten und parallelen DBS nken I 1 50 Mengenorientierte Schnittstelle (MOS) Datensystem Satzorientierte Schnittstelle (SOS) Zugriffssystem Interne Satz schnittstelle (ISS) Speichersystem Systempuffer schnittstelle (SPS) Pufferverwaltung Datei schnittstelle (DS) Geräte schnittstelle (GS) Betriebssystem Relationen Sichten externe Sätze, Scans, Index Strukturen interne Sätze, Bäume, Hashtabellen Segmente Seiten Dateien Blöcke Zylinder Spuren SQL : select from QBE, QUEL, FIND NEXT satz STORE satz Speichere internen Sa INSERT in B Baum Bereitstellen Seite j Freigeben Seite j Lies Block k Schreibe Block k Treiber Open Source DBMS (I) Einige konkrete Systeme MySQL ( weit verbreitet (Linux, Windows), speziell für Web-Datenbanken eingeschränkte SQL-Unterstützung, keine Transaktionen etc. PostgreSQL ( aus Forschungssystem Postgres (UCB) entwickelt für Unix und Linux objektrelationale Features (benutzerdefinierte Datentypen) bessere SQL-Unterstützung (Objekt-)Relationale DBMS Oracle9i, IBM DB2 V.7, Microsoft SQL Server 2000 Sybase MySQL, PostgreSQL, Firebird Pseudo-DBMS MS Access, dbase Objektorientierte DBMS Poet, Versant, ObjectStore XML-DBMS Tamino (Software AG), excelon, Xindice nken I 1 51

15 Open Source DBMS (II) FireBird ( aus InterBase (Borland) entstanden für Unix, Linux, Windows kompakt, geringer Speicherbedarf (2-3 MB) sehr gute SQL-Unterstützung