· (c) schmiedecke 06 DB1 - 2 - Architekturen 3 DBMS-Anforderungen Codd 1982 1. Daten-Integration...
Transcript of · (c) schmiedecke 06 DB1 - 2 - Architekturen 3 DBMS-Anforderungen Codd 1982 1. Daten-Integration...
(c) schmiedecke 06 DB1 - 2 - Architekturen 2
Bestandteile eines Datenbanksystems
Datenbanksystem
Datenbank
(DB)
System-schnittstelle
Datenbanksystem
Datenbank-management-
system (DBMS)
Speicher für Software zur VerwaltungDatenbestände der Datenbestände
Oberbegriff
(c) schmiedecke 06 DB1 - 2 - Architekturen 3
DBMS-AnforderungenCodd 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 4
ArchitekturmodelleZwei grundsätzlich Aufgaben,
beantwortet durch zwei Referenz-Architekturen1. 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 5
"Schema"-Ebenen ohne DB
Anwendungsdateien
Datenspeicher
Abbildungs-konzepte
Anw.1 Anw.2 Anw.3externeEbene
(konzeptuelleEbene)
physischeEbene
Schema: Abbildung einer Datenmenge auf Datenstrukturen
(c) schmiedecke 06 DB1 - 2 - Architekturen 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 7
Drei-Ebenen-Schema-Architektur
Anw.a Anw.b Anw.m Anw.n
externes Schema 1 externes Schema n
Logisches Schema
Internes Schema
Konzeptuelles Schema
Log. Schema 2
externeEbene
konzep-tuelleEbene
interneEbene
(c) schmiedecke 06 DB1 - 2 - Architekturen 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 9
Aufgabe der Schemata�Externes Schema (ES):
definiert (logische) Benutzersicht auf DB-Struktur für einAnwendungsprogramm / 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 10
Wer braucht welches Schema?
DB-Designer/Entwickler
DB-Nutzer
DB-Administrator
(c) schmiedecke 06 DB1 - 2 - Architekturen 11
Drei-Ebenen-Systemarchitektur
Quelle:http://www.kreissl.info/diggs/db_01.php
(c) schmiedecke 06 DB1 - 2 - Architekturen 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 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 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 Schnitt-stellen sind in konkreten Systemarchitekturen wiedererkennbar.
(c) schmiedecke 06 DB1 - 2 - Architekturen 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 16
Welche Aufgaben haben die einzelnen Komponenten?
DataDictionary
interne Definition
interne Transformation
logische Definition
logische Transformation
externeDefinition
externe Transformation
(c) schmiedecke 06 DB1 - 2 - Architekturen 17
...und wie passt die 3-Schichten-Architektur der Softwaretechnik dazu?
Präsentation(Benutzerschnittstelle, Client)
Fachlogik(Kern des Anwendungsprogramms, Server)
Datenhaltung(Datenbank, Datenserver)
Programmier-komponenten
des DBMS
(c) schmiedecke 06 DB1 - 2 - Architekturen 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 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 20
Unteranfragen mit Aggregatfunktionen
Einfache Anfrage:��������������� � ���� ��
������������� � ������ ��� �! " �
Geschachtelte Anfrage:������ �������� � ���� ��
������������� � ������ ��� �
����������� ������������������
(c) schmiedecke 06 DB1 - 2 - Architekturen 21
Quantifizierte Anfragen
• Ein Quantor bewirkt, dass ein Kriterium auf alle Elementeeiner 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 22
Quantifizierte Anfragen: IN
��������������� � ��# �$ $ �
������������
� � ����% ����&# '���( ) '��'� �( ) � *'��
��������������� � ���� ��
������������
� � ����# �$ $ ��&#
��������# �$ $ ��
������ ����+ , - �� + ��.
� � ������/ + �����0 �12 � . *�1��
(c) schmiedecke 06 DB1 - 2 - Architekturen 23
Quantifizierte Anfragen: EXISTS, SOME
��������������� � ��# �$ $ ��������������3� � �����4 &���
�������5 ������� ����+ , - �� + ��.�6� � ����67# �$ $ ��0 �37# �$ $ ���
��������������� � ���� ��������������� � ����# �$ $ �� 0 �����
��������# �$ $ �������� ����+ , - �� + ��.
��
(c) schmiedecke 06 DB1 - 2 - Architekturen 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.