Teil II. Was sind Datenbanken?

Transkript

1 Teil II Was sind Datenbanken?

2 Was sind Datenbanken? Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 1

3 Motivation & Historie Charakteristika von Datenbanken Eine Datenbank hat die (langfristige) Aufbewahrung von Daten als Aufgabe. Die Sicherheit vor Verlusten ist eine Hauptmotivation, etwas auf die Bank zu bringen. Eine Bank bietet Dienstleistungen für mehrere Kunden an, um effizient arbeiten zu können. Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 2

4 Motivation & Historie Anwendungsbeispiel: Musikversand Titel Musiker Jahr Preis Rezension(en) Tracks Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 3

5 Motivation & Historie Daten in Tabellenform (SQL) Albumtabelle speichert relevante Informationen zu CD-Alben (Titel, Erscheinungsjahr, Genre, etc.); jedes Album wird über die Albumnummer identifiziert Musikertabelle mit Informationen zu den Künstlern (Name, ggf. Vorname, Herkunftsland,...); Identifikation erfolgt durch eine Personennummer die einzelnen Songs werden mit Titel, Position auf dem Album und Laufzeit in der Tracktabelle gespeichert weitere Tabelle(n) mit Bewertungen, Kritiken usw. Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 4

6 Motivation & Historie Daten in Tabellenform Beispiel Musiker MNr Name Land 103 Apocalyptica Finnland 104 Subway To Sally Deutschland 105 Rammstein Deutschland Album ANr Titel Jahr Genre MNr 1014 Amplified 2006 Rock Nord Nord Ost 2005 Rock Rosenrot 2005 Rock Engelskrieger 2003 Rock 104 Track ANr Pos Titel Zeit Enter Sandmann 3: Haramgeddon 4: Nothing Else Matters 4: Saraband de Noir 0:55 Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 5

7 Motivation & Historie Ohne Datenbanken: Datenredundanz Basis- oder Anwendungssoftware verwaltet ihre eigenen Daten in ihren eigenen (Datei-)Formaten, z.b. in Unternehmen: 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 Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 6

8 Motivation & Historie Ohne Datenbanken: Datenredundanz /2 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 Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 7

9 Motivation & Historie Mit Datenbanken: Datenintegration Die gesamte Basis- und Anwendungssoftware arbeitet auf denselben Daten, z.b. Adressen und Artikel werden 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 Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 8

10 Motivation & Historie Historie Anfang 60er Jahre: elementare Dateien, anwendungsspezifische Datenorganisation (geräteabhängig, redundant, inkonsistent) Ende 60er Jahre: Dateiverwaltungssysteme (SAM, ISAM) mit Dienstprogrammen (Sortieren) (geräteunabhängig, aber redundant und inkonsistent) 70er Jahre: Datenbanksysteme (Geräte- und Datenunabhängigkeit, redundanzfrei, konsistent) Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 9

11 Motivation & Historie Historie von RDBMS 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, : Oracle Version 2 Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 10

12 Motivation & Historie Prinzipien DBMS: Datenbankmanagementsystem DBS: Datenbanksystem (DBMS + Datenbank) Anwendung... Anwendung DBMS Datenbank Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 11

13 Motivation & Historie Begriffsbildung Kürzel Begriff Erläuterung DB Datenbank Strukturierter, von DBMS verwalteter Datenbestand DBMS Datenbank- Software zur Verwaltung managementsystem von Datenbanken DBS Datenbanksystem DBMS plus Datenbank(en) Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 12

14 Motivation & Historie Prinzipien /2 Grundmerkmale von DBMS verwalten persistente (langfristig zu haltende) Daten verwalten große Datenmengen effizient Datenbankmodell, mit dessen Konzepten alle Daten einheitlich beschrieben werden (Integration) Operationen und Sprachen sind deskriptiv, getrennt von einer Programmiersprache Transaktionskonzept, Concurrency Control: logisch zusammenhängende Operationen atomar (unteilbar), Auswirkungen langlebig, können parallel durchgeführt werden Datenschutz, Datenintegrität (Konsistenz), Datensicherheit Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 13

15 Motivation & Historie Prinzipien /3 Grundprinzip moderner Datenbanksysteme 3-Ebenen-Architektur (physische Datenunabhängigkeit, logische Datenunabhängigkeit) Trennung zwischen Schema (etwa Tabellenstruktur) und Instanz (etwa Tabelleninhalt) angelehnt an 9 Codd sche Regeln Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 14

16 Motivation & Historie Die neun Codd schen Regeln 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: Ausschluss unauthorisierter Zugriffe 7 Transaktionen: mehrere DB-Operationen als Funktionseinheit 8 Synchronisation: parallele Transaktionen koordinieren 9 Datensicherung: Wiederherstellung von Daten nach Systemfehlern Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 15

17 Architektur System-Architekturen Beschreibung der Komponenten eines Datenbanksystems Standardisierung der Schnittstellen zwischen Komponenten Architekturvorschläge ANSI-SPARC-Architektur Drei-Ebenen-Architektur Fünf-Schichten-Architektur beschreibt Transformationskomponenten im Detail in weiterführenden Büchern und Vorlesungen Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 16

18 Architektur ANSI-SPARC-Architektur 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 Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 17

19 Architektur ANSI-SPARC-Architektur /2 Externe Ebene Konzeptuelle Ebene Interne Ebene Anfragen Updates Optimierer Auswertung Plattenzugriff P 1... DB- Operationen Einbettung Data Dictionary P n Masken Sichtdefinition Datendefinition Dateiorganisation Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 18

20 Architektur Klassifizierung der Komponenten 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 Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 19

21 Datenunabhängigkeit Datenunabhängigkeit und Schemata Basierend auf DBMS-Grobarchitektur Entkopplung von Benutzer- und Implementierungssicht Ziele u.a.: Trennung von Modellierungssicht und interner Speicherung Portierbarkeit Tuning vereinfachen standardisierte Schnitstellen Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 20

22 Datenunabhängigkeit Schema-Architektur Zusammenhang zwischen Konzeptuellen Schema (Ergebnis der Datendefinition) Internen Schema (Festlegung der Dateiorganisationen und Zugriffspfade) Externen Schema (Ergebnis der Sichtdefinition) Anwendungsprogrammen (Ergebnis der Anwendungsprogrammierung) Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 21

23 Datenunabhängigkeit Schema-Architektur /2 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) Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 22

24 Datenunabhängigkeit Schema-Architektur /3 externes Schema 1... externes Schema N Anfragebearbeitung Konzeptuelles Schema internes Schema Datendarstellung Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 23

25 Datenunabhängigkeit Datenunabhängigkeit /2 Stabilität der Benutzerschnittstelle gegen Änderungen physisch: Änderungen der Dateiorganisationen und Zugriffspfade haben keinen Einfluss auf das konzeptuelle Schema logisch: Änderungen am konzeptuellen und gewissen externen Schemata haben keine Auswirkungen auf andere externe Schemata und Anwendungsprogramme Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 24

26 Datenunabhängigkeit Datenunabhängigkeit /3 mögliche Auswirkungen von Änderungen am konzeptuellen Schema: eventuell externe Schemata betroffen (Ändern von Attributen) eventuell Anwendungsprogramme betroffen (Rekompilieren der Anwendungsprogramme, eventuell Änderungen nötig) nötige Änderungen werden jedoch vom DBMS erkannt und überwacht Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 25

27 Datenunabhängigkeit Ebenen-Architektur am Beispiel Konzeptuelle Sicht: relationale Darstellung Musiker MNr Name Land 103 Apocalyptica Finnland 104 Subway To Sally Deutschland 105 Rammstein Deutschland Album ANr Titel Jahr Genre MNr Musiker 1014 Amplified 2006 Rock Nord Nord Ost 2005 Rock Rosenrot 2005 Rock Engelskrieger 2003 Rock Reflections 2006 Rock 103 Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 26

28 Datenunabhängigkeit Ebenen-Architektur am Beispiel /2 Externe Sicht: Daten in einer flachen Relation ANr Titel Jahr Genre Musiker 1014 Amplified 2006 Rock Apocalyptica 1015 Nord Nord Ost 2005 Rock Subway To Sally 1016 Rosenrot 2005 Rock Rammstein 1021 Engelskrieger 2003 Rock Subway To Sally 1025 Reflections 2006 Rock Apocalyptica Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 27

29 Datenunabhängigkeit Ebenen-Architektur am Beispiel /3 Externe Sicht: Daten in einer hierarchisch aufgebauten Relation Musiker Album Titel Jahr Genre Apolcalyptica Amplified 2006 Rock Reflections 2003 Rock Subway To Sally Nord Nord Ost 2005 Metal Engelskrieger 2003 Rock Rammstein Rosenrot 2005 Rock Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 28

30 Datenunabhängigkeit Ebenen-Architektur am Beispiel /4 Interne Darstellung Baumzugriff über Albumnummer 1014 Amplified 2006 teilweises Speichern der Datensätze im Baum 1015 Nord Nord Ost Rock Rock Überlaufbereich für Datensätze Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 29

31 Datenunabhängigkeit Transaktionen Transaktion: Einheit der Verarbeitung im Mehrbenutzerbetrieb Commit: erfolgreicher Abschluss Abort: Abbruch zu synchronisierende Einheit im Mehrbenutzerbetrieb Einheit für Datenwiederherstellung (keine partiellen Effekte) Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 30

32 Einsatzgebiete Eigenschaften aktueller DBMS Drei-Ebenen-Architektur nach ANSI-SPARC, einheitliche Datenbanksprache (SQL; Structured Query Language), Einbettung dieser Sprache in kommerzielle Programmiersprachen, diverse Werkzeuge für die Definition, Anfrage und Darstellung von Daten und den Entwurf von Datenbank-Anwendungsprogrammen und der Benutzer-Interaktion, sowie kontrollierter Mehrbenutzerbetrieb, Zugriffskontrolle und Datensicherheitsmechanismen Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 31

33 Einsatzgebiete Einige konkrete Systeme (Objekt-)Relationale DBMS Oracle10g, IBM DB2 V.9, Microsoft SQL Server 2005 MySQL ( PostgreSQL ( FireBird ( Pseudo-DBMS MS Access Objektorientierte DBMS Poet, Versant, ObjectStore XML-DBMS Tamino (Software AG), excelon Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 32

34 Einsatzgebiete Einsatzgebiete 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 Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 33

35 Einsatzgebiete Datenbankgrößen Yahoo! Data Warehouse 100 TB Oracle DBMS, Unix, SMP WalMart Data Warehouse 0,5 PB(?) NCR TeraData; Produktinfos (Verkäufe etc.) von Märkten; Anfragen/Woche Amazon.com 25 TB Oracle RAC DBMS, Linux US Library of Congress TB nicht digitalisiert Google Index?? TB > 8 Mrd. Einträge (Dokumente) Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 34

36 Einsatzgebiete Datenbankgrößen /2 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) Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 35

37 Einsatzgebiete Entwicklungslinien: 60er Jahre DBS basierend auf hierarchischem Modell, Netzwerkmodell Zeigerstrukturen zwischen Daten Schwache Trennung interne / konzeptuelle Ebene Navigierende DML Trennung DML / Programmiersprache Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 36

38 Einsatzgebiete Entwicklungslinien: 70er und 80er Jahre Relationale Datenbanksysteme Daten in Tabellenstrukturen 3-Ebenen-Konzept Deklarative DML Trennung DML / Programmiersprache Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 37

39 Einsatzgebiete Entwicklungslinien: (80er und) 90er Jahre 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 Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 38

40 Einsatzgebiete Entwicklungslinien: heute 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,...) Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 39

41 Einsatzgebiete Zusammenfassung Motivation für Einsatz von Datenbanksystemen Codd sche Regeln 3-Ebenen-Schema-Architektur & Datenunabhängigkeit Einsatzgebiete Sattler / Saake Datenbanksysteme Wintersemester 2006/7 2 40