1. Einführung: 1.3 Aufbau und Architektur von DBMS

Transkript

1 1. Einführung: 1.3 Aufbau und Architektur von DBMS

2 Bestandteile eines Datenbanksystems Datenbanksystem Datenbanksystem Oberbegriff Datenbank (DB) Systemschnittstelle Datenbankmanagementsystem (DBMS) Speicher für Software zur Verwaltung Datenbestände der Datenbestände (c) schmiedecke 06 DB1-2 - Architekturen 2

3 DBMS-Anforderungen Codd Daten-Integration incl. Metadaten 2. Operationen einheitliche DB-Sprache 3. Katalog (Ort für Metadaten) 4. Benutzersichten in DB-Sprache definierbar 5. Konsistenz-Erhaltung DB-Sprache sichert logische Korrektheit 6. Datenschutz DB-Sprache zur Rechte-Differenzierung 7. Transaktionen Zusammenfassung von Operationsfolgen zu nicht unterbrechbaren Einheiten 8. Synchronisation Parallele Transaktionen 9. Datensicherung bei Systemfehlern Rückführung der Daten in einen konsistenten Zustand (c) schmiedecke 06 DB1-2 - Architekturen 3

4 Architekturmodelle Zwei grundsätzlich Aufgaben, beantwortet durch zwei Referenz-Architekturen 1. Datenorganisation Abbildung der Daten auf Datenträger Modellierung, Strukturierung und Speicherung Beschreibung von Konsistenzbedingungen Drei-Ebenen-Schema-Architektur (1975) 2. Funktionen Spezifikation und Zusammenhang der Systemkomponenten Außen- und Innen-Schnittstellen Drei-Ebenen-System-Architektur (1978) (c) schmiedecke 06 DB1-2 - Architekturen 4

5 "Schema"-Ebenen ohne DB Anw.1 Anw.2 Anw.3 Anwendungsdateien externe Ebene Abbildungskonzepte (konzeptuelle Ebene) Datenspeicher physische Ebene (c) schmiedecke 06 DB1-2 - Architekturen 5 Schema: Abbildung einer Datenmenge auf Datenstrukturen

6 Stufen der Datenunabhängigkeit Anwendungsunabhängigkeit / logische Datenunabhängigkeit: Anwendungsprogramm arbeitet nur mit dem Teil des Datenbestandes, den es benötigt (Datenbestand ist unabhängig von Änderungen der AP) Implementierungsunabhängigkeit / physische Datenunabhängigkeit: Datensicht des Anwendungsprogrammes ist unabhängig von der Datenstruktur der gespeicherten Daten Architektur-Vorschlag nach ANSI/X3/SPARC: Aufteilung eines DB-Schemas in 3 aufeinander aufbauende Ebenen Datenbeschreibung 3fach (Schemata je Ebene) (c) schmiedecke 06 DB1-2 - Architekturen 6

7 Drei-Ebenen-Schema-Architektur Anw.a Anw.b Anw.m Anw.n externe Ebene externes Schema 1 externes Schema n konzeptuelle Ebene Logisches Schema Konzeptuelles Schema Log. Schema 2 interne Ebene Internes Schema (c) schmiedecke 06 DB1-2 - Architekturen 7

8 Kleines Glossar UoD (Universe of Discourse): betrachteter Realweltausschnitt Datenmodell: Konzepte für die Abbildung der Realwelt in Datenstrukturen Datenbankschema: Abbild des UoD in Datenstrukturen auf Basis eines Datenmodells, Ergebnis und Ziel des Abbildungsvorganges = Datenbeschreibung für einen Realweltausschnitt (unabhängig von einzelnen Programmen und Benutzern) Datenbankausprägung: zu einem Zeitpunkt logisch widerspruchsfreie Belegung der Modellelemente des Datenmodells mit Daten der Anwendung Integritätsbedingung: Bedingung für die logische Widerspruchsfreiheit des Schemas Ebene (der Modellierung): Abstraktionsniveau (der Modellierung) (c) schmiedecke 06 DB1-2 - Architekturen 8

9 Aufgabe der Schemata Externes Schema (ES): definiert (logische) Benutzersicht auf DB-Struktur für ein Anwendungsprogramm / einen Benutzer -> anwendungsspezifischer Ausschnitt des konzeptuellen Schemas Konzeptuelles Schema (KS): logische Gesamtsicht auf die Struktur der DB -> implementierungsunabhängige Beschreibung mit einem DBMS-unabhängigen (abstrakten) Datenmodell Logisches Schema (LS): logische Gesamtsicht auf die Struktur der DB -> von Datenmodell eines DBMS abhängiges Abbild des konzeptuellen Schemas, unabhängig von physischer Realisierung Internes Schema (IS): physische Struktur der DB (Satzformate, Zugriffspfade, Speicherformate) physische Gesamtsicht -> abhängig vom konkreten DBMS (c) schmiedecke 06 DB1-2 - Architekturen 9

10 Wer braucht welches Schema? DB-Nutzer DB-Administrator DB-Designer/Entwickler (c) schmiedecke 06 DB1-2 - Architekturen 10

11 Drei-Ebenen-Systemarchitektur (c) schmiedecke 06 DB1-2 - Architekturen 11 Quelle:

12 Verarbeitungsschritte einer Anfrage (Transformation) 1. Syntax prüfen (Integritätscheck) 2. Prüfen, ob Daten (Tabellen) in Schema bekannt 3. Zugriffsrechte prüfen 4. Festellen welche Operationen intern auszuführen sind und wie der Anfrage-Operand intern gespeichert ist 5. Erstellung eines effizienten Codestückes zur Antwortberechnung 6. Operanden aus Datenbank lesen 7. Aufbereiten der Operanden (Optimieren) 8. Sicherstellen, dass Operanden nicht während Ausführung durch andere Anfragen geändert werden (Synchronisation) (c) schmiedecke 06 DB1-2 - Architekturen 12

13 Komponentenklassen: Externe Tansformationskomponenten: Benutzerkomponenten: interaktive Anfrage- und Änderungswerkzeuge für anspruchsvolle Laien, vorgefertigte DB-Anwendungsprogramme: E/A-Prozessor (mit Parser) Update-Prozessor (mit Integritätsprüfung) Query-Prozessor Externe Tansformationskomponenten: Programmierkomponenten: Einbettung höherer PL, 4GL oder graphischer Sprache, Vorübersetzer für eingebettete Kommandos DB-Operationen Werkzeuge zur Definition von Menüs, Masken etc. Logische Transformationskomponenten: Umwandlung zwischen Anfrage- und Updateoperationen und Plattenzugriffen (und zurück) Optimierer Auswerter Codegenerator (c) schmiedecke 06 DB1-2 - Architekturen 13

14 Komponentenklassen: Interne Transformationskomponenten Transaktionsmanager Geräte- und Puffer-Manager Definitionskomponenten: ermöglichen Daten-, Sichtdefinition, Definition der Zugriffspfade und Dateiorganisationsformen extern: Sichtdefinition logisch: Datendefinition intern: Dateiorganisation Data Dictionary: verwaltet die Metadaten aus den Definitionskomponenten Administrationskomponenten Autorisierungskontrolle Recoverymanager "Logbuch" Die Komponentenklassen der Referenz-Architektur und ihre Schnittstellen sind in konkreten Systemarchitekturen wiedererkennbar. (c) schmiedecke 06 DB1-2 - Architekturen 14

15 ... nochmal Datenunabhängigkeit Physische Datenunabhängigkeit: Bei Änderungen des internen Schemas sind nur die Transformationsvorschriften zu ändern. Externe Sichten bleiben unbeeinflusst. Die Anwendungen sind von der physischen Dateiorganisation isoliert. Logische Datenunabhängigkeit: Die Anwendungen werden von der konzeptuellen Ebene der Modellierung isoliert. In Abhängigkeit von der Flexibilität der Transformationen können ggf. unterschiedliche Interpretationen der Daten in den externen Schemata erfolgen. Statische Datenunabhängigkeit: Die Anwendung muss bei Änderungen im konzeptuellen oder internen Modell neu gebunden werden. (Binden zur Übersetzungszeit) Dynamische Datenunabhängigkeit: Anwendungen sind von allen Änderungen völlig unabhängig. (Erreicht durch Binden zur Zugriffszeit) (c) schmiedecke 06 DB1-2 - Architekturen 15

16 Welche Aufgaben haben die einzelnen Komponenten? externe Transformation logische Transformation interne Transformation Data Dictionary externe Definition logische Definition interne Definition (c) schmiedecke 06 DB1-2 - Architekturen 16

17 ...und wie passt die 3-Schichten- Architektur der Softwaretechnik dazu? Präsentation (Benutzerschnittstelle, Client) Fachlogik (Kern des Anwendungsprogramms, Server) Datenhaltung (Datenbank, Datenserver) Programmierkomponenten des DBMS (c) schmiedecke 06 DB1-2 - Architekturen 17

18 ... und nun noch ein bisschen SQL- Praxis Wir kennen Projektion (Select) Selektion (Where) Verbund (Join) Aggregation Es fehlen noch Unteranfragen (Geschachtelte Anfragen) (c) schmiedecke 06 DB1-2 - Architekturen 18

19 Unteranfragen Geschachtelte Anfragen: SFW-Block enthält einen oder mehrere SFB- Blöcke. Üblichste Schachtelung: In der WHERE-Klausel Das Ergebnis eines SFW-Blocks kann sein Ein Wert (oder eine Zeile) Aggregatfunktionen Eine Spalte oder eine Tabelle (c) schmiedecke 06 DB1-2 - Architekturen 19

20 Unteranfragen mit Aggregatfunktionen Einfache Anfrage:! " Geschachtelte Anfrage: (c) schmiedecke 06 DB1-2 - Architekturen 20

21 Quantifizierte Anfragen Ein Quantor bewirkt, dass ein Kriterium auf alle Elemente einer Menge angewendet wird Quantoren ermöglichen also die Anwendung von Vergleichsoperationen auf tabellenwertige Ergebnisse von Unterabfragen ALL Vergleich muss auf alle Elemente zutreffen SOME, ANY Vergleich muss auf mind. ein Elem. zutreffen EXISTS Menge darf nicht leer sein IN Vergleichswert muss Element der Menge sein (c) schmiedecke 06 DB1-2 - Architekturen 21

22 Quantifizierte Anfragen: IN # $ $ % &# '( ) '' ( ) *' # $ $ &# # $ $ +, - +. / *1 (c) schmiedecke 06 DB1-2 - Architekturen 22

23 Quantifizierte Anfragen: EXISTS, SOME # $ $ 3 4 & 5 +, # $ $ 0 37# $ $ # $ $ 0 # $ $ +, - +. (c) schmiedecke 06 DB1-2 - Architekturen 23

24 Wie sage ich's meiner Datenbank? Es gibt meist verschiedene Möglichkeiten, dasselbe auszudrücken Oft lassen sich Subqueries durch Joins ersetzen und umgekehrt. Gut ist, was lesbar ist. Effizienz: die erste WHERE-Klausel sollte möglichst viele Daten eliminieren. (c) schmiedecke 06 DB1-2 - Architekturen 24

25 genug für heute Nächstes Mal: Wie entwickelt man eine gute Datenbank?