DB3-DBMS-Architektur
Werbung
1. Einführung: 1.3 Aufbau und Architektur von DBMS Bestandteile eines Datenbanksystems Datenbanksystem Datenbanksystem Datenbank (DB) Speicher für Datenbestände (c) schmiedecke 06 Datenbankmanagementsystem (DBMS) Oberbegriff Systemschnittstelle Software zur Verwaltung der Datenbestände DB1 - 2 - Architekturen 2 DBMS-Anforderungen Codd 1982 1. 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 Architekturmodelle Zwei grundsätzlich Aufgaben, beantwortet durch zwei Referenz-Architekturen 1. Datenorganisation • • • 2. • • Abbildung der Daten auf Datenträger Modellierung, Strukturierung und Speicherung Beschreibung von Konsistenzbedingungen Drei-Ebenen-Schema-Architektur (1975) Funktionen Spezifikation und Zusammenhang der Systemkomponenten Außen- und Innen-Schnittstellen Drei-Ebenen-System-Architektur (1978) (c) schmiedecke 06 DB1 - 2 - Architekturen 4 "Schema"-Ebenen ohne DB Anw.1 Anw.2 Anw.3 externe Ebene Anwendungsdateien Abbildungskonzepte Datenspeicher (konzeptuelle Ebene) physische Ebene (c) schmiedecke 06 DB1 - 2 - Architekturen 5 Schema: Abbildung einer Datenmenge auf Datenstrukturen 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 Drei-Ebenen-Schema-Architektur Anw.a externe Ebene Anw.b Anw.m externes Schema 1 konzeptuelle Ebene interne Ebene (c) schmiedecke 06 Anw.n externes Schema n Konzeptuelles Schema Logisches Schema Log. Schema 2 Internes Schema DB1 - 2 - Architekturen 7 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 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 (c) schmiedecke 06 DB1 - 2 - Architekturen 9 -> abhängig vom konkreten DBMS Wer braucht welches Schema? DB-Nutzer DB-Administrator DB-Designer/Entwickler (c) schmiedecke 06 DB1 - 2 - Architekturen 10 Drei-Ebenen-Systemarchitektur (c) schmiedecke 06 DB1 - 2 - Architekturen 11 Quelle:http://www.kreissl.info/diggs/db_01.php Verarbeitungsschritte einer Anfrage (Transformation) 1. 2. 3. 4. 5. 6. 7. 8. Syntax prüfen (Integritätscheck) Prüfen, ob Daten (Tabellen) in Schema bekannt Zugriffsrechte prüfen Festellen welche Operationen intern auszuführen sind und wie der Anfrage-Operand intern gespeichert ist Erstellung eines effizienten Codestückes zur Antwortberechnung Operanden aus Datenbank lesen Aufbereiten der Operanden (Optimieren) Sicherstellen, dass Operanden nicht während Ausführung durch andere Anfragen geändert werden (Synchronisation) (c) schmiedecke 06 DB1 - 2 - Architekturen 12 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 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 Schnitt(c) schmiedecke 06 DB1 - 2 - Architekturen 14 stellen sind in konkreten Systemarchitekturen wiedererkennbar. ... 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 Welche Aufgaben haben die einzelnen Komponenten? externe Transformation logische Transformation interne Transformation (c) schmiedecke 06 Data Dictionary DB1 - 2 - Architekturen externe Definition logische Definition interne Definition 16 ...und wie passt die 3-SchichtenArchitektur der Softwaretechnik dazu? Präsentation (Benutzerschnittstelle, Client) Fachlogik (Kern des Anwendungsprogramms, Server) Datenhaltung (Datenbank, Datenserver) (c) schmiedecke 06 DB1 - 2 - Architekturen Programmierkomponenten des DBMS 17 ... und nun noch ein bisschen SQLPraxis • Wir kennen – Projektion (Select) – Selektion (Where) – Verbund (Join) – Aggregation • Es fehlen noch – Unteranfragen (Geschachtelte Anfragen) (c) schmiedecke 06 DB1 - 2 - Architekturen 18 Unteranfragen • Geschachtelte Anfragen: – SFW-Block enthält einen oder mehrere SFBBlö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 Unteranfragen mit Aggregatfunktionen Einfache Anfrage: !" Geschachtelte Anfrage: (c) schmiedecke 06 DB1 - 2 - Architekturen 20 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 SOME, ANY EXISTS IN (c) schmiedecke 06 Vergleich muss auf alle Elemente zutreffen Vergleich muss auf mind. ein Elem. zutreffen Menge darf nicht leer sein Vergleichswert muss Element der Menge sein DB1 - 2 - Architekturen 21 Quantifizierte Anfragen: IN # $ $ % &# ' ( ) ' ' ( ) *' # $ $ &# # $ $ +, /+ (c) schmiedecke 06 + 0 12 . . * 1 DB1 - 2 - Architekturen 22 Quantifizierte Anfragen: EXISTS, SOME # $ $ 3 4& 5 +, - + .6 67# $ $ 0 37# $ $ # $ $ 0 # $ $ +, - (c) schmiedecke 06 + . DB1 - 2 - Architekturen 23 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 genug für heute Nächstes Mal: Wie entwickelt man eine gute Datenbank?
