Kapitel 1: Einführung

Transkript

1 Ludwig Maximilians Universität München Institut für Informatik Lehr- und Forschungseinheit für Dsteme Skript zur Vorlesung tenbanks Wintersemester 2010/2011 pitel 1: Ei Vorlesung: PD Dr. Matthias Schubert Übungen: Thomas Bernecker, Andreas Züfle Skript 2005 Christian Böhm de/cms/dsteme Literaturliste Die Vorlesung orientiert sich nicht an einem bestimmten Lehrbuch. Empfehlenswert sind aber u.a.: 2 A. Kemper, A. Eickler: Dsteme Oldenbourg, 7. Auflage (2009). 39,80 R. Elmasri, S. B. Navathe: Grundlage von Dstemen Pearson Studium, 3. Auflage (2004). 39,95 A. Heuer, G. Saake, K.-U. Sattler: tenbanken kompakt mitp, 2. Auflage (2003). 19,95 A. Heuer, G. Saake: tenbanken: Konzepte und Sprachen mitp, 2. Auflage (2000). 35,28 R. Ramakrishnan, J. Gehrke: tabase Management Systems McGraw Hill, 3. Auflage (2002).

2 s Team Vorlesung Übungsbetrieb PD Dr. Matthias Schubert 3 Thomas Bernecker Andreas Züfle Wovon handelt die Vorlesung? Bisher (Eisvorlesung): Nur Betrachtung des Arbeitsspeichers. Objekte werden im Arbeitsspeicher erzeugt und nach dem Programmlauf wieder entfernt Warum ist dies nicht ausreichend? Viele Anwendungen müssen ten permanent speichern Arbeitsspeicher ist häufig nicht groß genug, um z.b. alle Kundendaten einer Bank oder Patientendaten einer Klinik zu speichern 4

3 Permanente tenspeicherung ten können auf dem sog. Externspeicher (auch Festplatte genannt) permanent gespeichert werden Arbeitsspeicher: Externspeicher: rein elektronisch (Transistoren und Kondensatoren) flüchtig schnell: 10 ns/zugriff * wahlfreier Zugriff teuer: für 1 GByte * Speicherung auf magnetisierbaren Platten (rotierend) nicht flüchtig langsam: 5 ms/zugriff * blockweiser Zugriff wesentlich billiger: 100 für ca. 200 GByte * * Oktober Aufbau einer Festplatte Mehrere magnetisierbare Platten rotieren z.b. mit Umdrehungen * pro Minute um eine gemeinsame Achse ( * z. Z. 5400, 7200, upm) Ein mm mit je zwei Schreib- /Leseköpfen pro Platte (unten/oben) bewegt sich in radialer Richtung. 6

4 Einteilung der Plattenoberflächen Spuren Sektoren 7 (interne) Adressierung einer Information: [Platten-Nr Oberfl.-Nr Spur-Nr Sektor-Nr Byte-Nr] Berechnung der pazität: # Platten * 2 * # Spuren * # Sektoren * Bytes pro Sektor Lesen/Schreiben eines Sektors Positionieren des mms mit den Schreib-/Leseköpfen auf der Spur Warten bis die Platte so weit rotiert ist, dass der Beginn des richtigen Sektors unter dem Schreib-/Lesekopf liegt Übertragung gder Information von der Platte in den Arbeitsspeicher (bzw. umgekehrt) Achtung: Es ist aus technischen Gründen nicht möglich, einzelne Bytes zu lesen bzw. zu schreiben, sondern mindestens einen ganzen Sektor 8

5 Speicherung in teien Adressierung mit Platten-Nr., Oberfl.-Nr. usw. für den Benutzer nicht sichtbar Arbeit mit teien: teinamen Verzeichnishierarchien Die Speicherzellen einer tei sind byteweise von 0 aufsteigend durchnummeriert. Die Ein-/Ausgabe in teien wird gepuffert, damit nicht der Programmierer verantwortlich ist, immer ganze Sektoren zu schreiben/lesen. 9 Beispiel: teizugriff in Java 10 public static void main (String[] args) { try { RandomAccessFile f1 = new RandomAccessFile("test.file","rw"); int c = f1.read() ; long new_position =... ; f1.seek (new_position) ; f1.write (c) ; f1.close () ; } catch (IOException e) { System.out.println ("Fehler: " + e) ; } } tei-handle tei öffnen ein Byte lesen auf neue Position ein Byte schreiben tei schließen Fehlerbehandlung

6 Beispiel: teizugriff in Java Werden die Objekte einer Applikation in eine tei geschrieben, hib ist das teiformat vom Programmierer festzulegen: Name (10 Zeichen) Vorname (8 Z.) Jahr (4 Z.) F r a n k l i n A r e t h a Wo findet man dieses tei-schema im Quelltext z.b. des Java-Programms? s teischema wird nicht explizit it durch den Quelltext t beschrieben, sondern implizit in den Ein-/Auslese- Prozeduren der tei 11 Logische tenabhängigkeit g Konsequenzen bei einer Änderung des teiformates (z.b. durch zusätzliche Objektattribute in einer neuen Programmversion): Alte tendateien Dt dti können nicht ihtmehr verwendet dtwerden oder müssen z.b. durch extra Programme konvertiert werden Die Änderung muss in allen Programmen nachgeführt werden, die mit den ten arbeiten, auch in solchen, die logisch von Änderung gar nicht betroffen sind 12

7 Physische tenabhängigkeit g Meist werden die tensätze anhand ihrer Position adressiert/separiert: i z.b. jeder Satz hat 22 Zeichen: 1. Satz: Adresse 0; 2. Satz: Adresse 22 usw. Suche gemäß bestimmten Attributwerten (z.b. Namen des Kunden) muss im Programm codiert werden Soll die tei z.b. mit einem Suchbaum unterstützt werden, dann gleiche Konsequenzen wie bei logischer Änderung 13 Informationssysteme Große Software-Systeme Viele einzelne Programme Programme arbeiten teils mit gemeinsamen ten, teils mit unterschiedlichen Beispiele für die Programme: Buchhaltung: Artikel- und Adressinformation Lagerverwaltung: Artikel und Aufträge Auftragsverwaltung.: Aufträge, Artikel, Adressen CAD-System: Artikel, techn. ten, Bausteine Produktion, Bestelleingang, g, lkulation:... 14

8 Redundanz ten werden meist mehrfach gespeichert Buchhaltung Artikel Adressen Lagerverw. Auftragsverw. Artikel Aufträge Aufträge Artikel Adressen Konsequenz: u.a. Änderungs-Anomalien Bei Änderung einer Adresse müssen viele teien nach den Einträgen durchsucht werden (hierzu später mehr) 15 Schnittstellenproblematik Alternative Implementierung Applikation 1 tei 1 Applikation 2 tei 2 Applikation 3 tei 3 Nachteile: unübersichtlich bei logischen oder physischen Änderungen des teischemas müssen viele Programme angepasst werden 16

9 Weitere Probleme von teien In großen Informationssystemen arbeiten viele Benutzer gleichzeitig mit den ten: teisysteme bieten zu wenige Möglichkeiten, um diese Zugriffe zu synchronisieren teisysteme schützen nicht in ausreichendem Maß vor tenverlust im Fall von Systemabstürzen und Defekten teisysteme bieten nur unflexible Zugriffskontrolle (tenschutz) 17 Von teien zu tenbanken Um diese Probleme mit einheitlichem Konzept zu behandeln, setzt man tenbanken ein: Mit teisystem: Mit Dstem: Anwendung 1 Anwendung 2 Anwendung 1 Anwendung 2 Dti tei 1 Dti tei 2 Dti tei 3 Dstem t 18

10 Komponenten eines DBS Man unterscheidet zwischen DB-Anwendungen Anw i Anw (kommunizieren mit DBMS) 1 2 DBS: Dstem (DB + DBMS) DBMS: tenbank- Management-System (Software zur Verwaltung) DB: tenbank (eigentliche tensammlung) DBMS DB Typische Einsatzbereiche Im betriebswirtschaftlichen Bereich: Banken (Kontoführung) Buchhaltung und Rechnungswesen Flugbuchungssysteme Telefongesellschaften (Abrechnung) Lagerverwaltung g Im technisch-wissenschaftlichen Bereich: CAD/CAM/CIM Medizin Molekularbiologie (Gendatenbanken) 20

11 Aufgaben eines DBS Primäre Aufgabe eines DBS ist die... Beschreibung Speicherung und Pflege und Wiedergewinnung umfangreicher tenmengen, die von verschiedenen Anwendungsprogammen dauerhaft (persistent) genutzt werden 21 Anforderungen an ein DBS Liste von 9 Anforderungen (Edgar F. Codd, 1982) Integration Einheitliche Verwaltung aller von Anwendungen benötigten ten. Redundanzfreie tenhaltung des gesamten tenbestandes Operationen Operationen zur Speicherung, zur Recherche und zur Manipulation der ten müssen vorhanden sein ta Dictionary Ein talog erlaubt Zugriffe auf die Beschreibung der ten Benutzersichten Für unterschiedliche Anwendungen unterschiedliche Sicht auf den Bestand Konsistenzüberwachung s DBMS überwacht die Korrektheit der ten bei Änderungen 22

12 Anforderungen an ein DBS Zugriffskontrolle Ausschluss unautorisierter Zugriffe Transaktionen Zusammenfassung einer Folge von Änderungsoperationen zu einer Einheit, deren Effekt bei Erfolg permanent in DB gespeichert wird Synchronisation Arbeiten mehrere Benutzer gleichzeitig mit der tenbank dann vermeidet das DBMS unbeabsichtigte gegenseitige Beeinflussungen Dt tensicherung ih Nach Systemfehlern (d.h. Absturz) oder Medienfehlern (defekte Festplatte) wird die Wiederherstellung ermöglicht (im Ggs. zu tei-backup Rekonstruktion des Zustands der letzten erfolgreichen TA) 23 Inhalte von tenbanken Man unterscheidet zwei Ebenen: Intensionale Ebene: tenbankschema beschreibt möglichen Inhalt der DB Struktur- und Typinformation der ten (Metadaten) Art der Beschreibung vorgegeben durch tenmodell Änderungen möglich, aber selten (Schema-Evolution) Extensionale Ebene: Ausprägung der tenbank tatsächlicher Inhalt der DB (DB-Zustand) Objektinformation, Attributwerte Struktur vorgegeben durch tenbankschema Änderungen häufig (Flugbuchung: TA/min) 24

13 Inhalte von tenbanken Einfaches Beispiel: Schema: Name (10 Zeichen) Vorname (8 Z.) Jahr (4 Z.) DB-Zustand: F r a n k l i n A r e t h a R i t c h i e L i o n e l Nicht nur DB-Zustand, sondern auch DB-Schema wird in DB gespeichert. Vorteil: Sicherstellung der Korrektheit der DB 25 Vergleich bzgl. des Schemas tenbanken Explizit modelliert (Textdokument oder grafisch) In tenbank abgespeichert Benutzer kann Schema-Informationen auch aus der tenbank ermitteln: ta Dictionary, Metadaten DBMS überwacht Übereinstimmung zwischen DB-Schema und DB-Zustand Änderung des Schemas wird durch DBMS unterstützt (Schema-Evolution, Migration) 26

14 Vergleich bzgl. des Schemas teien Kein Zwang, das Schema explizit zu modellieren Schema implizit in den Prozeduren zum Ein-/Auslesen Sh Schema gehört hötzur Programm-Dokumentation Dk tti oder es muss aus Programmcode herausgelesen werden. Hacker-Jargon: Entwickler-Doku, RTFC (read the f...ing code) Fehler in den Ein-/Auslese-Prozeduren können dazu führen, dass gesamter tenbestand unbrauchbar wird: F r a n k l i n A r e t h a R i t c h i e L i o n e l Bei Schema-Änderung müssen Migrations-Prozeduren programmiert werden, um bestehende teien auf das neue Format umzustellen 27 tenmodelle Formalismen zur Beschreibung des DB-Schemas Objekte der tenbank Beziehungen zwischen verschiedenen Objekten Integritätsbedingungen Verschiedene tenmodelle unterscheiden sich in der Art und Weise, wie Objekte und Beziehungen dargestellt werden: Hierarchisch: Baum Relational: Tabellen Firma Abteilung 1 Abteilung 2 Mitarbeiter Abteilungen 28 Mitarb 1 Mitarb 2 Mitarb 3

15 tenmodelle Weitere Unterschiede zwischen tenmodellen: angebotene Operationen (insbes. zur Recherche) Integritätsbedingungen Die wichtigsten tenmodelle sind: Hierarchisches tenmodell Netzwerk-tenmodell Relationales l tenmodell Objektorientiertes tenmodell Objekt-relationales tenmodell 29 Relationales Modell Alle Informationen werden in Form von Abteilungen Tbll Tabellen gespeichert ih Die tenbank besteht aus einer Menge von Tabellen (Relationen) Im Beispiel enthält die Tabelle Mitarbeiter Mitarbeiter Informationen über die Mitarbeiter des Betriebes In jeder Zeile (Tupel) Information über einen Mitarbeiter (die Zeilen sind strukturell gleich) Die Spalten (Attribute) haben einen Namen (z.b. Personalnr, Name, Vorname, Geburtsdatum, etc.). Sie sind strukturell (Typ, Anzahl Zeichen) verschieden. 30

16 Relationales Modell Die Attribute der Tupel haben primitive tentypen wie z.b. String, Integer oder te Komplexe Sachverhalte werden durch Verknüpfung mehrerer Tabellen dargestellt Beispiel: Mitarbeiter PNr Name Vorname ANr 001 Huber Erwin Mayer Hugo Müller Anton 02 Abteilungen ANr Abteilungsname 01 Buchhaltung 02 Produktion 03 Marketing Später ausführliche Behandlung 31 Hierarchisches tenmodell Schema + ten werden durch Baum strukturiert Der gesamte tenbestand muss hierarchisch repräsentiert werden (oft schwierig) Beispiel Lehrveranstaltungen: Schema: Vorlesung VNr Titel Beschreibung Vorauss VNr Titel Veranst Semester Ort Format Inhalt: Informatik I Informatik II DBS I Dozent PNr Name Student MNr Name Note Inf I Inf II SS V SS V 32

17 Netzwerk-tenmodell Schema und ten werden durch Graphen (Netzwerke) repräsentiert 33 Schema: Filiale FilAbt Abteilung AbtAng Angest DB-Inhalt: Filiale München FilAbt Filiale Hamburg FilAbt Abteilung Abteilung Abteilung Abt 1 AbtAng Abt 2 AbtAng Abt 3 AbtAng Angest Angest Angest Angest Angest Angest Meier Huber Müller Michl Jansen Schulz Objekt-Orientiertes tenmodell In der tenbank werden Objekte, d.h. Ausprägungen von Klassen, die zueinander in verschiedenen Beziehungen stehen (z.b. auch Vererbungsbeziehung), persistent gespeichert. Rein objektorientierte tenbanken haben sich kaum durchgesetzt Relationale tenbanken haben die Idee aufgenommen und erlauben jetzt auch Speicherung komplexer Objekte (incl. Vererbung) in Relationen Objekt-Relationale tenbanken 34

18 Produkte (Objekt-) Relationale tenbanken: Oracle (Marktführer) IBM DB2 Microsoft SQL Server MySQL (Open Source) PostgreSQL (Open Source) keine vollwertigen Dsteme: dbase, FoxPro, ACCESS Nicht-Relationale tenbanken IMS: Hierarchisches Dstem (IBM) UDS: Netzwerk-Dstem (Siemens) Verschiedene objektorientierte DB-Produkte 35 Verwendung eines DBS public class Personalverw { public static void main () {... insert(mitarbeiter,"müller");... }} Anwendungs-Programm (Software-Entwickler) select * from Mitarbeiter ; P-Nr. Name Vorname 001 Huber Erwin 002 Mayer Hugo 003 Müller select DBS DBAdmin x Which Backup? Full ily Partial Weekly OK Cancel 36 Interaktive Oberfläche für Ad-Hoc-Anfragen Benutzung vorgegebener Anwendungen Aus technischer Sicht ist die interaktive Oberfläche ebenfalls ein Anwendungsprogramm, das auf dem DBS aufsetzt

19 tenbank-sprachen ta Definition Language (DDL) Deklarationen zur Beschreibung des Schemas Bei relationalen tenbanken: Anlegen und Löschen von Tabellen, Integritätsbedingungen usw. CREATE TABLE Mitarbeiter ( PNr NUMBER (3), Name CHAR (20), Vorname CHAR (20), Anr NUMBER (2) ) PNr Name (leer) Vorname ANr 37 tenbank-sprachen ta Manipulation Language (DML) Anweisungen zum Arbeiten mit den ten in der tenbank (tenbank-zustand) lässt sich weiter unterteilen in Konstrukte zum reinen Lesen der DB (Anfragesprache) zum Manipulieren (Einfügen, Ändern, Löschen) des tenbankzustands Beispiel: SQL für relationale tenbanken: SELECT * FROM Mitarbeiter WHERE Name = 'Müller' 38

20 tenbank-sprachen Wird das folgende Statement (Mitarbeiter-Tab. S. 29) SELECT * FROM Mitarbeiter WHERE ANr = 01 in die interaktive DB-Schnittstelle eingegeben, dann ermittelt das Dstem alle Mitarbeiter, die in der Buchhaltungsabteilung (ANr = 01) arbeiten: PNr Name Vorname ANr 001 Hb Huber Erwin Mayer Hugo Ergebnis einer Anfrage ist immer eine (neue) Tabelle Verbindung zur Applikation Verwendung einer Programmierbibliothek Dem Programmierer wird eine Bibliothek von Prozeduren/Funktionen zur Verfügung gestellt (Application Programming Interface, API) DDL/DML-Anweisungen als Parameter übergeben Beispiele: OCI: Oracle Call Interface ODBC: Open tabase Connectivity it gemeinsame Schnittstelle an alle Dsteme JDBC: Java tabase Connectivity 40

21 Verbindung zur Applikation Beispiel: JDBC String q = SELECT * FROM Mitarbeiter + WHERE Name = 'Müller' ; Statement s = con.createstatement () ; ResultSet r = s.executequery (q) ; Die Ergebnistabelle wird an das Java-Programm übergeben. Ergebnis-Tupel können dort verarbeitet werden 41 Verbindung zur Applikation Einbettung in eine Wirtssprache DDL/DML-Anweisungen gleichberechtigt neben anderen Sprachkonstrukten Ein eigener Übersetzer (Precompiler) wird benötigt, um die Konstrukte in API-Aufrufe zu übersetzen Beispiele: Embedded SQL für verschiedene Wirtssprachen, z.b. C, C++, COBOL, usw. SQLJ oder JSQL für Java 42

22 Verbindung zur Applikation Beispiel in SQLJ: public static void main () { System.out.println ( Hallöchen ) ; #sql {SELECT * FROM Mitarbeiter WHERE Name = 'Müller'}... } Die Ergebnistabelle b wird an das Java-Programm übergeben. Ergebnis-Tupel können dort verarbeitet t werden 43 Architektur eines DBS 44 Drei-Ebenen-Architektur zur Realisierung von physischer und logischer tenunabhängigkeit (nach ANSI/SPARC) A 1 A 2 A 3 A 4 A 5 Anwendungsgruppen Ext. Schema 1 Ext. Schema 2 Ext. Schema 3 Externe Ebene Logische tenunabhängigkeit Logisches Schema Konzeptionelle Ebene Physische tenunabhängigkeit Internes Schema Interne Ebene

23 Konzeptionelle Ebene Logische Gesamtsicht aller ten der DB unabhängig von den einzelnen Applikationen Niedergelegt in konzeptionellem (logischem) Schema Ergebnis des (logischen) tenbank-entwurfs (siehe pitel 6) Beschreibung aller Objekttypen und Beziehungen Keine Details der Speicherung Formuliert im tenmodell des Dstems Spezifiziert mit Hilfe einer ten-definitionssprache (ta Definition Language, DDL) 45 Externe Ebene Sammlung der individuellen Sichten aller Benutzer- bzw. Anwendungsgruppen in mehreren externen Schemata Ein Benutzer soll keine ten sehen, die er nicht sehen will (Übersichtlichkeit) oder nicht sehen soll (tenschutz) Beispiel: s Klinik-Pflegepersonal benötigt andere Aufbereitung der ten als die Buchhaltung tenbank wird damit von Änderungen und Erweiterungen der Anwenderschnittstellen abgekoppelt (logische tenunabhängigkeit) 46

24 Interne Ebene s interne Schema beschreibt die systemspezifische Realisierung der DB-Objekte (physische Speicherung), z.b. Afb Aufbau der gespeicherten ih tensätze Dt Indexstrukturen wie z.b. Suchbäume s interne Schema bestimmt maßgeblich das Leistungsverhalten des gesamten DBS Die Anwendungen sind von Änderungen des internen Schemas nicht betroffen (physische tenunabhängigkeit) 47