1. Eigenschaften und Architektur von DB-Systemen

Transkript

1 Eigenschaften und Architektur von DB-Systemen 1.1. Wozu Datenbanken? Warum nicht File Systeme? Bisher kannten Sie: - Programme (flüchtige Verarbeitung) - Files im Filesystem (für persistente Ablage von Daten) Das führt zu Problemen, wenn 1. sehr viele Daten vorhanden sind (z. B. Telefonbuch für ganz Deutschland). Dann sequentielle Suche auf Dateien ineffizient. 120 Mio Anschlüsse, 1 Eintrag ca. 100 Byte ==> 120 x 10 6 x 10 2 = 12 GByte ==> Nicht mehr schnell genug darin suchbar. (Stichwort: Effizienz) 2. zwei Benutzer gleichzeitig dieselben Daten ändern. Bsp.: Kontoänderung Benutzer 1 Benutzer 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) 4. Rücksetzen nach Systemabsturz Daten auf Datei: letzte Sicherungsdiskette / -band (ca. 1 x pro Tag erstellt) wiedereinlesen, alles andere nochmal machen! Bei Bankanwendung indiskutabel! Korrektes Rücksetzen direkt auf Situation vor Absturz nötig! (Stichwort: Recovery) 5. 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) und vieles mehr. read 1000 read 1000 add 200 write 1200 sub 500 write 500 (Stichwort: Serialisierung) ==> Lösung: Einsatz von Datenbanksystemen

2 zum Sprachgebrauch: Datenbank (DB) = konkrete Anwendung mit konkreten Daten (z.b. Zugauskunft, Bibliotheksystem), läuft immer auf einem Datenbanksystem. [Anfrage Suche nach Information, daher:] 1.2. Information und Daten Datenbanksystem (DBS) = stellt die Speicherstrukturen, Zugriffsoperationen, Datenverwaltung und Schutzmechanismen zur Verfügung Zusammenfassung: 2 Hauptunterschiede zwischen DBS und anderen Programmsystemen (Sprachen u. Dateisysteme): - sichere Verwaltung langlebiger Daten - effiziente Verwaltung sehr großer Datenbestände Information: Daten: Problem: Beispiel: ÖBB Kenntnis von Fakten und Wissen. Nicht notwendigerweise formalisiert. formalisierte Darstellung der Information, geeignet für angestrebten Gebrauch Welche Darstellung der Daten ist die Geeignetste? Oft verschiedenartige Anfragen (wenn Daten falsch repräsentiert (modelliert) sind, kann die Antwort ineffizient werden) Information über: Fahrpläne Tarife Lokomotiven Wagenstand Personalbestand Personaleinsatz Streckennetz usw.

3 - 5 - Bsp.: Fahrplan am Hauptbahnhof ist nach Abfahrt und Ankunft organisiert, nach Zeit geordnet Verschiedene Benutzergruppen Abfahrt Ankunft Aufgaben des DB-Designers - geeignete Modellierung der Information wählen (vgl. Kap. 2) Die Darstellung der Daten ist nach Häufigkeit der Anfragen optimiert. Beantwortung häufiger Fragen möglichst schnell / effizient Forderung nach Kostenminimierung Aber die Frage: Zug von Graz nach Klosterneuburg Abfahrt [8-10] kürzeste Fahrzeit ist damit nicht lösbar. Dafür gibt es das Kursbuch (Information geordnet nach Strecken) (andere Modellierung derselben Information). - Formalisierung und interne Ablage der Daten im DBS festlegen. (Welche Daten habe ich? Welche Anfragen werden gestellt werden?) - Definition verschiedener Sichten für mehrfache Nutzung der Daten unter verschiedenen Aspekten. - effiziente Zugriffsstrukturen festlegen - Spezifikation von Operationen für Anfragen Vorsicht: Nachträgliche Änderungen kommen teuer! Zusammenfassung: Es gibt also für verschiedene Benutzer verschiedene Sichten (views) auf den Gesamtbestand der Daten. Die Information sollte aber nur einmal in der DB gespeichert sein (sonst Probleme mit Redundanz, Inkonsistenz bei Updates). Aufgaben des DB-Anwendungsprogrammierer Erstellt Programme (meist mit Web-Oberfläche) in Java, C, C++, PHP, etc., die mit der Datenbank arbeiten. z.b. zum Suchen, Einfügen, Löschen, Ändern (meist über JDBC, ADO.net oder einen E-SQL-Anschluß). DB-Applikationsprogramm in C DB-Aufruf DBS DB

4 Endbenutzer interagiert mit DBS über Applikationsprogramme und Benutzerschnittstellen (Masken, Menüs,...) - weiß nichts mehr vom Datenmodell, Zugriffstrukturen, etc Anforderung an ein DB-System 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 muß definiert sein!) Aufgaben des DB-Administrators (priviligierter Benutzer) - Einspoolen von Daten - Systempflege - Vergabe von Rechten - Sicherung - neue Benutzer eintragen - DB tunen (z. B. durch Anlegen weiterer Zugriffsstrukturen) - aber auch verantwortlich für Datenschutz,... super user bei BS 4. Unterstützung von problemadäquaten DB-Sprachen - DDL: Data Definition Language - DML: Data Manipulation Language - DRL: Data Retrieval Language, Querysprache 5. Datenschutz / Datensicherheit: Datenschutz: Schutz vor Manipulation und unbefugtem Zugriff (Maßnahme: Hierarchie an Zugriffsrechten, Views, etc.) 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 (Bsp.: Schufa) 6. Simultanzugriff: Parallele Ausführung von DB-Programmen notwendig. -> korrekte Synchronisation durch DBS selbst Konsistente Ablaufsteuerung (Transaktionskonzept vgl. nächster Abschnitt)

5 Forderung nach großer Verfügbarkeit, hohem Durchsatz (= großer Transaktionsrate) besonders im online-betrieb: hohe Transaktionsraten Bsp.: DBS Amadeus Flugbuchungen in Erding: 1000 Transaktionen pro sec.! 8. Recovery (Zurücksetzen, Wiederanlauf): Reperaturmaßnahmen bei - Integritätsverletzungen, TA-Fehler (mehrmals pro Minute) - Verlust von Daten nach Systemfehler (z.b. BS-Fehler, Hauptspeicherausfall, Platte noch ok, alle Puffer leer) (1x pro Monat) - Plattencrash (1x pro Jahr) Das Transaktionskonzept DB-Applikationen werden mittels einer Folge von Transaktionen (TA) erstellt. Definition: Eine Transaktion (TA) T ist eine endliche Folge von DB-Operationen (Lesen, Schreiben, Löschen), mit folgenden Eigenschaften: T führt einen korrekten DB-Zustand wieder in einen korrekten DB- Zustand über. Die Änderungen von T sind atomar = entweder alle oder keine. z.b.: Überweisen = Abbuchung + Gutschrift (auch keine Aktion ist korrekter Zustand) Jeweils konsistenter Zustand muß wieder erreicht werden. -> log-file mitschreiben, regelmäßig sichern, Extremfall: Spiegelplatten (Tandem) -> Spezielle Algorithmen für Undo oder Redo 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, d.h. steht auf Platte, nicht im Puffer. Daher spricht man oft von ACID-Transaktionen A = Atomicity C = Consistency I = Isolation D = Durability

6 wichtig: Das TA-Konzept ist ein anwendungsunabhängiger Mechanismus zur Strukturierung und Kontrolle von Datenbankaktionen. verbirgt die Synchronisation u. Recovery Aspekte (code!) vor dem DB-Anwendungsprogrammierer. realisiert virtuellen Einbenutzerbetrieb damit ist das TA-Konzept der entscheidende Unterschied zwischen DBS und konventionellem Filesystem. boot DB Konten login db_user_1 ( connect) : TA1.1 TA1.2 : TA1.n logout ( disconnect) [shutdown DB Konten ] Schematisches Beispiel: Anwenderprogramm Geldüberweisung Zustandsübergangsgraph:... start TA T 1 : Fehler - Zustand Lesen Kto.-stand X Abbuchen Betrag B von X if X < Dispositionskredit then abort TA T 1 fi abort TA retrieval update Operation Schreiben Kto.-stand Y :=Y + B commit TA T 1 start begin TA interner Zustand commit TA neuer Zustand... mit Konsistenzbedingung: Xalt + Yalt = Xneu + Yneu sichtbar für Andere sichtbar für Andere größerer Kontext:

7 Forderung: Serialisierbarkeit paralleler TAs: Def.: {T 1,..., T n } parallele TAs (T 1,..., T n ) serielle TAs Def.: Ablaufsteuerung ist konsistent (i 1,..., i n ): Architektur eines DBS Abstraktionsebenen (3-Schichten-Modell) DB wird auf unterschiedlichen Abstraktionsniveaus gesehen 3-Schichten-Architektur (ANSI / X3 / SPARC) Wirkung von {T 1,..., T n } Wirkung von (T i1,..., T in ). {T 1,..., T n } heißen dann serialisierbar. Benutzergruppe 1 Benutzergruppe n Externe Sichten der DB D.h. jetzt Beispiel aus Einleitung Kontofalschbuchung (Kap. 1.1, Problem 2) nicht mehr möglich: View 1... View n Externe Schemata Sei x = 1000 start TA 1 start TA 2 read X -> a read X -> b a := a write (a) commit TA b := b-500 write (b) commit TA Transformation Konzeptuelle / Logische DB Transformation Transformation Konzeptuelle / Logische Sicht der DB Konzeptuelles/ Logisches Schema Das Datenbanksystem sorgt dafür, daß entweder (TA1, TA2) oder (TA2, TA1), kein Mix! durchgeführt wird. jeweils korrektes Ende: x = 700 Der Benutzer braucht sich, da er im DBS nur unter Transaktionsschutz arbeiten kann, darum nicht mehr zu kümmern. Physische DB Interne Sicht der DB Internes Schema

8 Physische / interne Schicht Konkrete Implementation der DB DB als Kollektion von Feldern mit ihren Größen Recordstrukturen Dateien, Seiten Zugriffspfade, d.h. Indexen, Hashtabellen, B-Bäumen, B*-Bäumen und Zeigerstrukturen Daten werden auf Sekundärspeicher (Platte, CD-ROM) abgelegt. Die Peformance einer DB hängt wesentlich von der Auslegung der physischen DB ab! b) eine logische Datenunabhängigkeit: => Repräsentation der Daten unabhängig von externer Schicht. D.h. neuer Benutzer kann neue Views nötig haben, ohne daß sich deshalb die konzeptuelle Schicht und die interne Schicht ändern! 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. DB-Queries und DB-Updates werden implementiert mittels DRL und DML Konzeptuelle / logische Schicht - modelliert den gesamten Anwendungsbereich - integrierte, einheitliche Darstellung aller Daten ohne Redundanz - implementiert mittels DDL Die konzeptuelle / logische Schicht bietet: a) 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 der DB)), ohne konzeptuelle Schicht zu ändern.

9 Grobarchitektur eines DBS Geschichtliche Entwicklung wichtiger DB-Modelle Endbenutzer Queries (interaktiv) Synchronisation DB- Schemadesigner DML/DRL- Compiler Konzept. DB-Manager Phys. DB-Manager DB- Administrator Appl.-prog. DDL- Compiler Data Dictionary Metainformation Schema-Tabellen Zugriffsrechte Integritätsbedingungen Historische Modelle : Erste DBS entstanden aus Dateisystemen. Hierarchische DBS: IMS von IBM, 60er Jahre Netzwerk DBS (= CODASYL DBS) Entwicklung in den 60er Jahren UDS von Siemens, Anfang der 70er Jahre Heutiges Modell: Relationale DBS Prototypen seit 70er Jahre (System R, IBM) Kommerzielle Produkte seit 80er Jahre: Heutige Marktanteile: (bei einem Umsatz von 15,2 Mrd $ /Jahr DB-Cache Arbeitsspeicher DB-Instanzen (Platte) DBS Hersteller Marktanteil - Oracle (Oracle) 47,1 % - DB/2 (IBM) 21.1 % - SQL-Server (Microsoft) 17,4 % - Sybase (Sybase) 3,3 % - andere 11,1 % MySQL und Postgres sind frei und tauchen daher hier nicht auf. MySQL ca. 29 % (vor allem mittlere und kleinere Proj)

10 weitere Zwischenentwicklungsschritte: enf 2 -Systeme (AIM-P, IBM Heidelberg; DASDBS, ETH Zürich) Deduktive DBS (LDL, Nail, LOLA, Coral,...) Objektorientierte DBS (Objectstore (Object Design), Versant (Versant), O 2 (O 2 Technology), Itasca (Itasca), Ontos (Ontos DB), Gemstone (Servios), Montage (= Postgres),...) Heutige DBS: Objekt-relationale Datenbanksysteme (DB/2, Oracle, SQL-Server, Informix Universal Server, Illustra,...) Neue Entwicklungen: Audio und Video DBS, Bild-DBS Mobile DBS Suchmaschinen Web-Archive Data Warehouse Systeme auch alle Einträge, Postings etc. in Sozialen Netzwerken erden über DB verwaltet. Neueste Entwicklungen: NonSQL DBS Key-Value DBS Spaltenorientierte DBS Graph-DBS