chapter02.pdf

Anwendersoftware (AS)
Datenbanken und
Informationssysteme
Kapitel 2: Architekturen von Datenbanksystemen
Bernhard Mitschang
Universitt Stuttgart
Wintersemester 2013/2014
Teile zu diesem Folienskript beruhen auf einer hnlichen Vorlesung, gehalten von Prof. Dr. T. Hrder am
Fachbereich Informatik der Universitt Kaiserslautern und Prof. Dr. N. Ritter am Fachbereich Informatik der
Universitt Hamburg. Fr dieses Skriptum verbleiben alle Rechte (insbesondere fr Nachdruck) bei den
Autoren.
Architektur
bersicht
Anforderungen
Drei-Schema-Architektur nach ANSI-SPARC
5-Schichten-Modell
Prinzipien der Schichtenbildung
Schichten-Modell
Weitere Komponenten: Metadatenverwaltung, Transaktionsverwaltung
Dynamischer Ablauf
Weitere Architekturszenarien
Verteilte DBS: Einsatz von Mehrrechner-DBS und FDBMS
Schichtenmodelle fr Client/Server-DBS
Architektur von Transaktionssystemen
Architektur
Datenbanksystem (DBS)
Zentrales Hilfsmittel fr Informationssysteme
Anwendungssysteme
DBS = DB + DBMS
Datenbanksysteme
Betriebssystem
Eine Datenbank (DB)
Hardware
ist eine Sammlung gespeicherter Daten,

die von Anwendungssystemen bentigt werden.
Ein Datenbankverwaltungssystem (DBVS, engl. DBMS)

ist ein standardisiertes Softwaresystem zur Definition, Verwaltung,
Verarbeitung und Auswertung der Daten in einer DB.
Es kann mittels geeigneter Parametrisierung an die speziellen
Anwendungsbedrfnisse angepasst werden
(hochgradig generisches System).
Architektur
Datenmodell
Ein Datenmodell legt Regeln (Typen, Operatoren,
Konsistenzbedingungen) fest, nach denen
die Objekte von DBs (fr die Reprsentation beliebiger Miniwelten) erzeugt
und
verndert werden (Konstruktionsregeln fr die Zustandsrume der Modelle)
knnen.
Jedes DBS implementiert somit ein Datenmodell, das die Art der
Datenstrukturen und generische Operationen zu deren Manipulation
bereitstellt.
Architektur
DBS und Datenmodelle

relationale DBS (RDBMS)
hierarchische DBS
XML-DBS
Abteilung
Projekt
Mitarbeiter
Relationen/Tabellen
Datenstze
Hierarchie: Eltern/Kind-Beziehungen
objektorientierte DBS (ODBMS)
<Abteilung>
<Projekt>
<Mitarbieier>
</Mitarbeiter>
<Mitarbeiter>
</Mitarbeiter>
</Projekt>
<Projekt>
</Projekt>
</Abteilung>
Netzwerk-DBS
Abteilung
Dokument
hierarchisch strukturierte
Elemente
Projekt
Datenstze
OWNER/MEMBER
Objekte u. Methoden
5
Architektur
DBS: Weitere Klassifikationskriterien

Anzahl der Nutzer
Einbenutzersysteme
allgemein/aufgabenspezifisch
allgemein
Mehrbenutzersysteme
aufgabenspezifisch
Anzahl der Rechner
zentrales DBMS
verteiltes DBMS
homogene DBMS
heterogene DBMS
Fderative DBMS (FDBMS)

6
Architektur
Datenbanktechnologie
Konzepte, Methoden, Werkzeuge und Systeme fr die
dauerhafte
Lebensdauer Daten > Dauer Erzeugungsprozess
zuverlssige
Integritt, Konsistenz, Verlustsicherheit
unabhngige
wechselseitige nderungsimmunitt AWP-DB
Verwaltung und
komfortable
"hhere", abstrakte Schnittstelle
flexible
Ad-hoc Zugriffsmglichkeit
Benutzung von
groen
Gre Daten >> Gre Hauptspeicher
integrierten
von/fr mehrere Anwendungen,

kontrollierte Redundanz
mehrfachbenutzbaren
zeitgleicher Zugriff und Mehrbenutzerbetrieb
Datenbasen
7
Architektur
Anforderungen an ein DBS
Kontrolle der
Datenintegritt
Kontrolle ber die

operationalen Daten
Hoher Grad an
Datenunabhngigkeit
DBS
Architektur
Kontrolle ber die operationalen Daten
Alle Daten knnen/mssen gemeinsam benutzt werden

keine verstreuten privaten Dateien
Querauswertungen aufgrund inhaltlicher Zusammenhnge
symmetrische Organisationsformen
(keine Bevorzugung einer Verarbeitungs- und Auswertungsrichtung)
Entwicklung neuer Anwendungen auf der existierenden DB
Erweiterung/Anpassung der DB (nderung des Informationsbedarfs)
Redundanzfreiheit (aus Sicht der Anwendung)
keine wiederholte Speicherung in unterschiedlicher Form fr verschiedene
Anwendungen
Vermeidung von Inkonsistenzen
zeitgerechter nderungsdienst, keine unterschiedlichen nderungsstnde
Datenbankadministrator (DBA):
zentrale Verantwortung fr die operationalen Daten
Architektur
Leichte Handhabbarkeit der Daten

Einfache Datenmodelle
Beschreibung der logischen Aspekte der Daten

Benutzung der Daten ohne Bezug auf
systemtechnische Realisierung
Logische Sicht der

Anwendung
zugeschnitten auf ihren Bedarf

lokale Sicht auf die DB
Leicht erlernbare
Sprachen
deskriptive Problemformulierung
hohe Auswahlmchtigkeit
Untersttzung der Problemlsung des Anwenders im
Dialog
Durchsetzung von
Standards
unterschiedliche DBS bieten einheitliche Schnittstelle

Portierbarkeit von Anwendungen
erleichterter Datenaustausch
Erweiterung der
Benutzerklassen
Systempersonal, Anwendungsprogrammierer
anspruchsvolle Laien, parametrische Benutzer/
gelegentliche Benutzer
10
Architektur
Beispiel im Relationenmodell: DB-Schema
DB-Schema
FB FBNR FBNAME
PROF
PNR
PNAME
FBNR
DEKAN
STUDENT
FACHGEB
MATNR
SNAME
FBNR
STUDBEG
PRFUNG
PNR
MATNR
FACH
DATUM
NOTE
11
Architektur
Beispiel im Relationenmodell: Ausprgungen

FB
FBNR FBNAME
DEKAN
FB 9 WIRTSCHAFTSWISS 4711
FB 5 INFORMATIK
2223
STUDENT
MATNR
123 766
225 332
654 711
226 302
196 481
130 680
SNAME
COY
MLLER
ABEL
SCHULZE
MAIER
SCHMID
FBNR
FB 9
FB 5
FB 5
FB 9
FB 5
FB 9
PROF
PNR
1234
5678
4711
6780
STUDBEG
01.10.95
15.04.87
15.10.94
01.10.95
23.10.95
01.04.97
PNAME
HRDER
WEDEKIND
MLLER
NEHMER
FBNR
FB 5
FB 9
FB 9
FB 5
PRFUNG
PNR MATNR
5678 123 766
4711 123 766
1234 654 711
1234 123 766
6780 654 711
1234 196 481
6780 196 481
FACH
BWL
OR
DV
DV
SP
DV
BS
FACHGEB
DATENBANKSYSTEME
INFORMATIONSSYSTEME
OPERATIONS RESEARCH
BETRIEBSSYSTEME
PDATUM
22.10.97
16.01.98
17.04.97
17.04.97
19.09.97
15.10.97
23.12.97
NOTE
4
3
2
4
2
1
3
12
Architektur
Deskriptive DB-Sprachen (wie SQL)

hohes Auswahlvermgen und Mengenorientierung
leichte Erlernbarkeit auch fr den DV-Laien
RM ist symmetrisches Datenmodell, d.h., es gibt keine bevorzugte Zugriffsoder Auswertungsrichtung
Anfragebeispiele:
1. Finde alle Studenten aus Fachbereich 5, die ihr Studium vor 1995 begonnen
haben.
SELECT
FROM
WHERE
*
STUDENT
FBNR = FB5 AND STUDBEG < 1.1.95
13
Architektur

2. Finde alle Studenten des Fachbereichs 5, die im Fach Datenverwaltung eine
Note 2 oder besser erhalten haben.
SELECT
FROM
WHERE
AND
*
STUDENT
FBNR = FB5
MATNR IN (SELECT MATNR
FROM
PRFUNG
WHERE FACH = DV AND NOTE 2)
3. Finde die Durchschnittsnoten der DV-Prfungen fr alle Fachbereiche mit mehr als 1000 Studenten.
SELECT S.FBNR, AVG (P.NOTE)
FROM
PRFUNG P, STUDENT S
WHERE P.FACH = DV AND P.MATNR = S.MATNR
GROUP BY S.FBNR
HAVING (SELECT COUNT(*)
FROM
STUDENT T
WHERE T.FBNR = S.FBNR) > 1000
14
Architektur
Beispiel im Hierarchiemodell: DB-Schema
DB-Schema
PROF
PNR
PNAME
ABGEHALTENEPRFUNG
MATNR FACH
FB
FBNR
FACHGEB
PDATUM
NOTE
FBNAME
DEKAN
STUDENT
MATNR SNAME
ABGELEGTEPRFUNG
PNR FACH
STUDBEG
PDATUM
NOTE
15
Architektur
Beispiel im
Hierarchiemodell:
Ausprgungen
Ausprgungen (1)
FB 9
WIRTSCHAFTSWISS
1.10.95
226 302
SCHULZE
1.4.97
123 608
SCHMID
123 766
COY
1.10.95
OR
4711
MLLER
INF
WEDEKIND
5678
OR
123 766
123 766
BWL
22.10.97
4711
16.1.98
3
17.4.97
DV
1234
16.1.98 3
OR
4711
5678 BWL 22.10.97 4
Ausprgungen (2)
FB 5
INFORMATIK
BS
6780
NEHMER
DBS
1234
HRDER
BS 23.12.97 3
196 481
SP
654 711
19.9.97 2
DV
196 481
15.10.97 1
DV
654 711
17.4.97 2
DV
123 766
17.4.97 4
2223
225 332
MLLER
15.4.87
196 481
MAIER
23.10.95
654 711
ABEL
15.10.94
23.12.97 3
BS
6780
15.10.97 1
DV
1234
19.9.97
SP
6780
17.4.97 2
DV
1234
16
Architektur
Anfragebeispiele
1. Finde alle Studenten aus Fachbereich 5, die ihr Studium vor 1990 begonnen
haben.
NEXT_STUDENT:
GU FB (FBNR = FB5);
GNP STUDENT (STUDBEG < 1.1.90);
IF END_OF_PARENT THEN EXIT;
PRINT STUDENT RECORD;
GOTO NEXT_STUDENT;
2. Finde alle Studenten des Fachbereichs 5, die im Fach Datenverwaltung eine

Note 2 oder besser erhalten haben.
NEXT_STUDENT:
GU FB (FBNR = FB5);
GNP STUDENT;
IF END_OF_PARENT THEN EXIT;
GNP ABGELEGTE_PRFUNG (FACH = DV) AND (NOTE 2);
IF END_OF_PARENT THEN GOTO NEXT_STUDENT;
PRINT STUDENT RECORD;
GOTO NEXT_STUDENT;
17
Architektur
Prozedurale DB-Sprachen
bei hierarchischen Datenmodellen
Programmierer als Navigator
satzweiser Zugriff ber vorhandene Zugriffspfade
unnatrliche Organisation bei komplexen Beziehungen (n:m)
Auswertungsrichtung ist vorgegeben
18
Architektur
Kontrolle der Datenintegritt
Automatisierte Zugriffskontrolle
logische Datenintegritt
logischer Einbenutzerbetrieb
physische Datenintegritt
Transaktionskonzept
19
Architektur
Automatisierte Zugriffskontrollen (Datenschutz)

separat fr jedes Datenobjekt
unterschiedliche Rechte fr verschiedene Arten des Zugriffs
Idealziel: least privilege principle
gewnschte
Autorisierung
Autorisierungssystem
Vergabe und Entzug
von Zugriffsrechten
gewnschte
Systemleistung
Schreiben
Schutzinfo.
Lesen
berwachungssystem
Annahme oder Abweisung
von Auftrgen
20
Architektur
Erhaltung der logischen Datenintegritt (system enforced integrity)
Beschreibung der Richtigkeit von Daten durch Prdikate und Regeln

Qualittskontrollen bei nderungsoperationen
aktive Manahmen des DBS erwnscht (Trigger, ECA-Regeln)
Transaktionskonzept
21
Architektur
Klassische Transaktionsverarbeitung
UPDATE accounts
SET balance = balance - 1000
WHERE K# = 03874;
UPDATE accounts
SET balance = balance + 1000
WHERE K# = 01099;
TransaktionsProgramme
Transaktionssystem
EOT
Karte ?
PIN ?
Konto ?
Buchung
Ausgabe
Datenbanksystem
#
Kontostand
01099 03874
BOT
-100
900
1500
2500
OK
22
Architektur
Ablaufkontrollstruktur: Transaktion (TA)

Eine Transaktion ist eine ununterbrechbare Folge von DML-Befehlen, die
die Datenbank von einem logisch konsistenten in einen (neuen) logisch
konsistenten Zustand berfhrt.
Beispiel eines TA-Programms:
BOT
UPDATE Konto
...
UPDATE Schalter
...
UPDATE Zweigstelle
...
INSERT INTO Ablage (...)
EOT
23
Architektur
ACID-Eigenschaften von Transaktionen

Atomicity (Atomaritt)
TA ist kleinste, nicht mehr weiter zerlegbare Einheit
Entweder werden alle nderungen der TA festgeschrieben oder
gar keine (alles-oder-nichts-Prinzip)
Consistency
TA hinterlsst einen konsistenten DB-Zustand, sonst wird sie komplett
(siehe Atomaritt) zurckgesetzt
Endzustand muss alle definierten Integrittsbedingungen erfllen
Zwischenzustnde whrend der TA-Bearbeitung drfen inkonsistent
sein
24
Architektur
ACID-Eigenschaften von Transaktionen

Isolation
Nebenlufig (parallel, gleichzeitig) ausgefhrte TA drfen sich nicht
gegenseitig beeinflussen
Parallele TA bzw. deren Effekte sind nicht sichtbar
(logischer Einbenutzerbetrieb)
Durability (Dauerhaftigkeit)
Wirkung erfolgreich abgeschlossener TA bleibt dauerhaft in der DB
TA-Verwaltung muss sicherstellen, das dies auch nach einem
Systemfehler (HW- oder System-SW) gewhrleistet ist
Wirkung einer erfolgreich abgeschlossenen TA kann nur durch eine
sog. kompensierende TA aufgehoben werden
25
Architektur
Schnittstelle zwischen
Anwendungsprogramm (AP) und DBS
START TRANSACTION
Kennzeichnet Beginn einer
Transaktion (BOT)
nach SQL-Standard auch implizit
mglich
COMMIT [WORK]
Kennzeichnet Ende einer
Transaktion (EOT)
nderungen der Transaktion
werden festgeschrieben
ROLLBACK [WORK]
Selbstabbruch der Transaktion
(Abort)
SAVEPOINT <name>
Definiert einen Sicherungspunkt
innerhalb der Transaktion
ROLLBACK [WORK]
TO SAVEPOINT <name>
Setzt die aktive Transaktion auf
einen Sicherungspunkt zurck
26
Architektur
Mgliche Ausgnge einer Transaktion

BOT
BOT
BOT
DML1
DML1
DML1
DML2
DML2
DML2
DML3
DML3
DML3
DMLn
DMLn
COMMIT
ROLLBACK
normales Ende
abnormales Ende
Systemausfall,
Programmfehler,
usw.
erzwungenes ROLLBACK
erzwungenes
abnormales Ende
27
Architektur
Einbenutzer-/Mehrbenutzerbetrieb
Einbenutzerbetrieb
T1
T2
T3
t
Mehrbenutzer- T1
betrieb
T2
T3
Mgliche Anomalien im unkontrollierten Mehrbenutzerbetrieb
Dirty Read
Lost Update
Inkonsistente Analyse
Phantom-Problem
Architektur
Dirty Read
Abhngigkeit von nicht-freigegebenen nderungen (Dirty Read)
schmutzig Daten (dirty data):
- Genderte, aber noch nicht
freigegebene Daten
- die TA kann ihre
nderungen bis Commit
(einseitig) zurcknehmen
T1
T2
Read (A);
A := A + 100;
Write (A);
Schmutzige Daten drfen

von anderen TAs nicht
benutzt werden
Read (A);
Read (B);
B := B + A;
Write (B);
Commit;
Rollback;
Zeit
29
Architektur
Logischer Einbenutzerbetrieb
Notwendigkeit des kontrollierten Mehrbenutzerbetriebs:
Logischer Einbenutzerbetrieb fr jeden von n parallelen
Benutzern/Transaktionen (Leser + Schreiber)
Jede der parallel aktiven Transaktionen den Eindruck, als liefe sie alleine ab,
d. h., logisch bilden alle Transaktionen eine serielle Ablauffolge
Synchronisationskomponente des DBMS

umfasst geeignete Synchronisationsmanahmen zur Sicherstellung der
Ablaufintegritt (Isolation der parallelen Transaktionen)
angepasste Synchronisationseinheiten (z.B. Sperrgranulate) mit
abgestuften Zugriffsmglichkeiten (z.B. Sperrmodi)
Ziel: mglichst geringe gegenseitige Behinderung
30
Architektur
DBMS garantiert physische Datenintegritt:

Bei jedem Fehler wird eine korrekte Datenbank rekonstruiert.
Automatische Wiederherstellung des jngsten transaktionskonsistenten Zustands nach
dem Neustart des Systems.
Transaktionskonsistenter Zustand: Zustand, in dem alle nderungen von TA enthalten
ist, die vor dem Zeitpunkt des Fehlers erfolgreich beendet waren und sonst keine.
A
A'
T1
Systemabsturz
B'
T6
T2
T4
T7
C'
T3
T5
B'
C'
31
Architektur
Erhaltung der physischen Datenintegritt

Periodisches Erstellen von Datenkopien
Fhren von nderungsprotokollen fr den Fehlerfall (Logging)
Bereitstellen von Wiederherstellungsalgorithmen im Fehlerfall (Recovery)
Garantie nach erfolgreichem Neustart: jngster transaktionskonsistenter DB-Zustand
Manahmen der Recoverykomponente beim Wiederanlauf

Ermittlung der beim Absturz aktiven Transaktionen (T5, T6, T7)
UNDO:
Rcksetzen der nderungen der aktiven Transaktionen in der Datenbank (B B)
REDO:
Wiederholen der nderungen von abgeschlossenen Transaktionen, die vor dem Absturz
nicht in die Datenbank zurckgeschrieben waren (A A)
32
Architektur
Transaktionsverwaltung
Wesentliche Abstraktionen (aus Sicht der DB-Anwendung) zur Gewhrleistung einer
fehlerfreien Sicht auf die Datenbank im logischen Einbenutzerbetrieb
koordiniert alle DBMS-seitigen Manahmen, um ACID zu garantieren
soll Transaktionsschutz fr heterogene Komponenten bieten
kann zentralisiert oder verteilt realisiert sein
besitzt zwei wesentliche Komponenten
- Synchronisation
- Logging und Recovery
Failure Transparency
Alle Auswirkungen auftretender Fehler bleiben der Anwendung verborgen
Concurrency Transparency
Es sind keine anwendungsseitigen Vorkehrungen zu treffen, um Effekte der
Nebenlufigkeit beim DB-Zugriff auszuschlieen
33
Architektur
Leistung und Skalierbarkeit
DBS-Implementierung gewhrleistet
Effizienz der Operatoren (mglichst geringer Ressourcenverbrauch)
Verfgbarkeit der Daten (Redundanz, Verteilung usw.)
Effizienz des Datenzugriffs
Zugriffsoptimierung durch das DBS, nicht durch den Anwender
Anlegen von Zugriffspfaden durch den DBA,
Auswahl idealerweise durch das DBS
Ausgleich von Leistungsanforderungen, die im Konflikt stehen
globale Optimierung durch den DBA (Rolle des internen Schemas)
ggf. Nachteile fr einzelne Anwendungen
34
Architektur
Leistung und Skalierbarkeit
Leistungsbestimmung
Mazahlen fr Leistung
- Durchsatz: Anzahl abgeschlossener TA pro Zeiteinheit
(meist Sekunde)
- Antwortzeit: Zeitbedarf fr die Abwicklung einer TA
Rolle von Benchmarks: TPC-C, TPC-H, TPC-E, TPC-App, . . .
Skalierbarkeit
Software- und Hardware-Architektur sollen hinsichtlich des DBSLeistungsverhaltens automatisch durch Hinzufgen von Ressourcen (CPUs,
Speicher) skalieren
- Scaleup: bei Wachstum der Anforderungen (DB-Gre, Transaktionslast)
- Speedup: zur Verringerung der Antwortzeit
Quelle: www.tpc.org
35
Architektur
Hoher Grad an Datenunabhngigkeit
Konventionelle Anwendungsprogramme (AP) mit Dateizugriff

Nutzung von Kenntnissen der Datenorganisation und Zugriffstechnik
gutes Leistungsverhalten, aber . . . ?
datenabhngige Anwendungen
Ziel: Datenunabhngige Anwendungen:
Rolle des Datenmodells:
Vergleiche relationales und hierarchisches Datenmodell
Verschiedene Anwendungen brauchen verschiedene Sichten auf
dieselben Daten
nderungen im Informationsbedarf sowie bei Leistungsanforderungen
erzwingen Anpassungen bei Speicherungsstrukturen und Zugriffsstrategien
deshalb: mglichst starke Isolation der APs von den Daten
sonst: extremer Wartungsaufwand fr die APs
36
Architektur
Hoher Grad an Datenunabhngigkeit
Realisierung verschiedener Arten von Datenunabhngigkeit:

Minimalziel:
physische Daten-Unabhngigkeit (durch das BS/DBS)
- Gerteunabhngigkeit
- Speicherungsstruktur-Unabhngigkeit
logische Daten-Unabhngigkeit (vor allem durch das Datenmodell!)
- Zugriffspfad-Unabhngigkeit
- Datenstruktur-Unabhngigkeit
37
Architektur
bersicht
Anforderungen
5-Schichten-Modell
Schichten-Modell
Dynamischer Ablauf
38
Architektur
Schichtenmodell aus Benutzungssicht

Externe Ebene
Ext.
Ext.
Schema 1 . . . Schema n
Konzeptionelle Ebene
Konz. Schema
DatenDefinition
DatenManipulation
Interne Ebene
Int. Schema
DatenAdministration
ANSI: American National Standards Institute, SPARC-Komitee:

Study Group on Database Management Systems, http://www.ansi.org
Quelle: [TK78]
39
Architektur
Abstraktionsebenen
individuelle
Sichten
Externe
Ebene
Konzeptionelle
Ebene
gemeinschaftliche
Sicht
Interne
Ebene
Reprsentationssicht
40
Architektur

Konzeptionelles Schema
(zeitvariante) globale Struktur; neutrale und redundanzfreie Beschreibung in
der Sprache eines spezifischen Datenmodells
Beschreibungssprache: DDL (Data Definition Language)
Externes Schema
Definition von zugeschnittenen Sichten auf Teile des konzeptionellen Schemas
fr spezielle Anwendungen (Benutzer)
Sichtenbildung
- Anpassung der Datentypen an die der Wirtssprache (DBS ist multi-lingual)
- Zugriffsschutz
- Reduktion der Komplexitt
Internes Schema
legt physische Struktur der DB fest (Satzformate, Zugriffspfade etc.)
Beschreibungssprache: SSL (Storage Structure Language)
41
Architektur

Extern (PL/1)
DCL
1
2
3
4
Extern (COBOL)
PERS,
PNR CHAR(6),
GEH FIXED BIN(31)
NAME CHAR(20)
01
PERSC.
02 PERSNR PIC X(6).
02 ABTNR PIC X(4).
Konzeptionelles Schema
ANGESTELLTER
ANG_NUMMER
NAME
ABT_NUMMER
GEHALT
CHARACTER
CHARACTER
CHARACTER
NUMERIC
(6)
(20)
(4)
(5)
Internes Schema
SPEICHERUNG_PERS
PREFIX
PNR
NAME
ANR
GEHALT
LENGTH=40
TYPE=BYTE(6), OFFSET=0
TYPE=BYTE(6), OFFSET=6, INDEX=PNR
TYPE=FULLWORD, OFFSET=36
42
Architektur
bersicht
Anforderungen
5-Schichten-Modell
Schichten-Modell
Dynamischer Ablauf
43
Architektur
Entwurfsziele fr DBS
Integration der Daten und ihre unabhngige sowie logisch zentralisierte
Verwaltung
Datenunabhngigkeit und Anwendungsneutralitt beim logischen und
physischen Datenbankentwurf
Einfache und flexible Benutzung der Daten durch geeignete
Anwendungsprogrammierschnittstellen
Zentralisierung aller Manahmen zur Integrittskontrolle
Transaktionsschutz fr die gesamte Datenbankverarbeitung
Effiziente und parallele Verarbeitung von groen Datenbasen
Hohe Verfgbarkeit und Fehlertoleranz
Skalierbarkeit bei Wachstum der Transaktionslast und der Datenvolumina
44
Architektur
Schichtenbildung im Schichtenmodell
Ziel: Architektur eines datenunabhngigen DBS

Wie viele Schichten braucht man?
Es gibt keine Architekturlehre fr den Aufbau groer SW-Systeme
Empfohlene Konzepte:
Geheimnisprinzip (Information Hiding)
Hierarchische Strukturierung
Aufbauprinzip:
Schicht i + 1
Operatoren: Oi+1,1,
Datenobjekte: ti+1,1,
Schicht i
realisiert
Operatoren: Oi,1,
Datenobjekte: ti,1,
Qi+1,p (ti+1, q)
benutzt
+ Implementierungssprache
Oi,r(ti, 1,,ti,k), , Oi,s(ti,1,,ti,n)
benutzt-Relation: A benutzt B, wenn A B aufruft und die korrekte Ausfhrung

von B fr die vollstndige Ausfhrung von A notwendig ist
45
Architektur
Schichtenbildung im Schichtenmodell
Vorteile als Konsequenzen der Nutzung hierarchischer Strukturen und der benutzt-Relation
Jede Hierarchieebene kann als abstrakte oder virtuelle Maschine aufgefasst werden
Programme der Schicht i benutzen als abstrakte Maschine die Programme der Schicht i-1, die als
Basismaschine dient
abstrakte Maschine der Schicht i dient wiederum als Basismaschine fr die Implementierung der
abstrakten Maschine der Schicht i+1
Eine abstrakte Maschine entsteht aus der Basismaschine durch Abstraktion
hhere Ebenen (Systemkomponenten) werden einfacher, weil sie tiefere Ebenen

(Systemkomponenten) benutzen knnen
nderungen auf hheren Ebenen sind ohne Einfluss auf tieferen Ebenen
hhere Ebenen knnen abgetrennt werden, tiefere Ebenen bleiben trotzdem funktionsfhig
tiefere Ebenen knnen getestet werden, bevor die hheren Ebenen lauffhig sind
einige Eigenschaften der Basismaschine werden verborgen

zustzliche Fhigkeiten werden durch Implementierung hherer Operationen fr die abstrakte
Maschine bereitgestellt
Programme einer bestimmten Schicht knnen die der nchst tieferen Schicht genau so
benutzen, als sei die untere Schicht Hardware
46
Architektur
5-Schichten-Modell
Transaktionsprogramme
Mengenorientierte DB-Schnittstelle
SQL, QBE ...
Logische Datenstrukturen
Satzorientierte DB-Schnittstelle
FIND NEXT/STORE ...
Logische Zugriffspfade
Interne Satz-Schnittstelle
Speichere Satz (in B*-Baum), ...
Speicherungsstrukturen
DB-Puffer-Schnittstelle
Stelle Seite bereit / gib Seite frei
Seitenzuordnungsstrukturen
Dateischnittstelle
Lies/Schreibe Block
Speicherzuordnungsstrukturen
Gerteschnittstelle
Kanalprogramme
Externspeichermedien
47
Architektur
5-Schichten-Modell
Adressierungseinheiten:
Blcke, Dateien
Hilfsstrukturen:
Dateikataloge, Freispeicher-Info, ...
Spuren, Kanle, Zylinder
Dateischnittstelle
Lies/Schreibe Block
Gerteschnittstelle
Kanalprogramme
48
Architektur
5-Schichten-Modell
Seiten; Segmente
Hilfsstrukturen:
Seitentabellen, Blocktabellen, ...
Blcke, Dateien
DB-Puffer-Schnittstelle
Stelle Seite bereit / gib Seite frei
49
Architektur
5-Schichten-Modell
Interne Satz-Schnittstelle
Speichere Satz (in B*-Baum), ...
Interne Stze, B*-Bume, Hash-Tabellen, ...
Hilfsstrukturen:
Seitenindices, Adresstabellen, ...
Seiten; Segmente
50
Architektur
5-Schichten-Modell
Satzorientierte DB-Schnittstelle
FIND NEXT/STORE ...
Externe Stze, Sets, Schlssel, Zugriffspfade, ...
Hilfsstrukturen:
Zugriffspfaddaten
Interne Stze, B*-Bume, Hash-Tabellen, ...
51
Architektur
5-Schichten-Modell
Mengenorientierte DB-Schnittstelle
SQL, QBE ...
Relationen, Sichten, Tupel
Hilfsstrukturen:
externe Schemabeschreibung
Externe Stze, Sets, Schlssel, Zugriffspfade, ...
52
Architektur
5-Schichten-Modell
Relationen,
Sichten
ab
...
rec. 1
Externe Stze
rec. 2
aa
xyz
bb
xyz
xyz
rec. 3
ab
bb
xyz
Interne Stze
aa
record 1
123
record 2
1
ab
456
record 3
2
bb
789
A
record1
DB-Puffer
record3
record2
C
A
Segment
A
1
Datei
A'
2
B
3
C
4
C'
5
3
Externer Speicher
53
Architektur
Datenunabhngigkeit im 5-Schichtenmodell
Ebene
Was wird verborgen?
Positionsanzeiger und
explizite Beziehungskonstrukte im
Schema
Zahl und Art der physischen

Zugriffspfade;
interne Satzdarstellung
Pufferverwaltung;
Recovery-Vorkehrungen
Seitenzuordnungstrukturen
Dateiabbildung,
Recovery-Untersttzung durch das BS
Technische Eigenschaften und

Betriebsdetails der externen
Speichermedien
54
Architektur
Weitere Komponenten in der DBSArchitektur
Entwurfsziel:
DBS sollen von ihrem Aufbau und ihrer Einsatzorientierung her in hohem
Mae generische Systeme sein. Sie sind so zu entwerfen, dass sie flexibel
durch Parameterwahl und ggf. durch Einbindung spezieller Komponenten
fr eine vorgegebene Anwendungsumgebung konfigurierbar sind.
berblick:
Datensystem
Metadatenverwaltung
Zugriffssystem
Speichersystem
55
Architektur
Weitere Komponenten in der DBSArchitektur
Metadaten
Metadaten enthalten Informationen ber die zu verwaltenden Daten

sie beschreiben also diese Daten (Benutzerdaten) nher hinsichtlich Inhalt,
Bedeutung, Nutzung, Integrittsbedingungen, Zugriffskontrolle usw.
diese Metadaten lassen sich unabhngig vom DBVS beschreiben
(siehe internes, konzeptionelles und externes Schema)
dadurch erfolgt das Zuschneidern eines DBS auf eine konkrete
Einsatzumgebung; die Spezifikation, Verwaltung und Nutzung von Metadaten
bildet die Grundlage dafr, dass DBS hochgradig generische Systeme sind
Metadaten fallen in allen DBS-Schichten an
Metadatenverwaltung, DB-Katalog, Data-Dictionary-System, DD-System, ...
Realisierung der ACID-Eigenschaften

Synchronisation
Logging/Recovery
Integrittssicherung
56
Architektur
bersicht
Anforderungen
5-Schichten-Modell
Schichten-Modell
Dynamischer Ablauf
57
Architektur
Bearbeitung einer DB-Anfrage

Anwendungsprogramm 1
logische
Datenstrukturen
Abbildung der Segmente auf Dateien, die aus Blcken fester Lnge be-
logische
Zugriffspfade
Seitenzuordnung
Pufferverwaltung
stehen
Arbeitsbereich zur
Bearbeitung der diesem Programm zugnglichen
DatenUWA 1
objekte
Anwendungsprogramm n
Arbeitsbereich zur
Bearbeitung der diesem Programm zugnglichen
DatenUWA n
objekte
Datenbankpuffer: jeder Pufferrahmen kann

eine Seite aufnehmen
58
Architektur
Hauptspeicher
Externspeicher
Betriebssystem
6
5
Internes
Schema
2
Datenbankverwaltungssystem
Externes
Schema
A1
Konzeptionelles
Schema
Externes
Schema
An
Anwendungsprogramm n
Anwendungsprogramm 1
1
Datenbank
8
4
Statusinformation
Statusinformation
DB-Puffer
Arbeitsbereich 1
Arbeitsbereich n
59
Architektur

Interne Bearbeitungsschritte:
1. SELECT * FROM PERS WHERE PNR = 12345

2. Vervollstndigen der Verarbeitungsinformation aus konzeptionellem und
internem Schema;
Ermittlung der Seiten# (z. B. durch Hashing)
3. Zugriff auf DB-Puffer: erfolgreich oder
4. Zugriff auf DB ber DB-Pufferverwaltung/Betriebssystem
5. Durchfhren des E/A-Auftrages
6. Ablegen der Seite im DB-Puffer
7. bertragen in Arbeitsbereich
8. Statusinformation: Return-Code, Cursor-Info
9. Manipulation mit Anweisungen der Programmiersprache
60
Architektur
bersicht
Anforderungen
5-Schichten-Modell
Schichten-Modell
Dynamischer Ablauf
61
Architektur
Klassifikation verteilter Datenbanksysteme

Vorgehensweise bei der Verteilung
Gewnschte Sichtbarkeit
- Partitionierung der Daten

(ggf. mit Replikation)
- Kommunikation zwischen Prozessen
zum Zugriff auf jeweils lokale Daten
Lokale
Benutzersicht
Globale Systemsicht: Verteilung

lokale
Systemsicht
DBMSSchichten
Homogenes Systemmodell
Datensystem
Zugriffssystem
Speichersystem
D
B
M
S
Datensystem
Zugriffssystem
Speichersystem
lokale
Systemsicht
Mehrere (homogene)
Realisierungsalternativen
Globale Systemsicht wird in einer (zustzlichen)
DBMS-Schicht hergestellt
Verteilung ganzer DML-Befehle bzw. von
Teiloperationen (Schicht 1)
Verteilung von internen Satzoperationen
(Schicht 2)
Verteilung von Seitenzugriffen (Schicht 3)
Quelle: [Ra94]
62
Architektur
Mehrrechner-DBS
AP
AP
AP
DBMS
DBMS
DBMS
DB - P1
DB - P2
DB - P3
Architekturklassen
1. DB-Partitionierung (Shared Nothing , VDBS)
Jeder Knoten besitzt volle Funktionalitt und verwaltet eine DB-Partition

Datenreplikation erhht Verfgbarkeit und Zuverlssigkeit
Minimierung der Auswirkung von entfernten Fehlern,

Fehlermaskierung durch Redundanz
Verarbeitungsprinzip: Die Last folgt den Daten
2. DB-Sharing (Shared Disk )
Lokale Ausfhrung von DML-Befehlen

Verarbeitungsprinzip: Datentransport zum ausfhrenden Rechner
Lokale Erreichbarkeit der Externspeicher
63
Architektur
Fderierte Datenbanksysteme (FDBS)
Transparenter Zugriff auf mehrere

heterogene und weitgehend
autonome Datenquellen
Kompensiert Funktionalitt, die in

einzelnen Datenquellen fehlt
globale Anfrageoptimierung
Wrapper
SQL API
Vollstndiges DBMS
Datenquelle
Daten
Datenquelle
Daten
Fderiertes
Datenbank
System
Benutzer
Katalog
Daten
64
Architektur
Entscheidend fr die DB-bezogene Leistungsfhigkeit:
Art und Komplexitt der DB-Operationen (mengenorientiert, navigierend)
Nutzung der Referenzlokalitt bei den Datenzugriffen
Bisheriges Verarbeitungskonzept
Bei allen Architekturvorschlgen wurde ein Verschicken der Anfragen
zum (Server)-DBMS unterstellt (query shipping approach):
Die DML-Anweisung wird zum Server geschickt
Nach ihrer Verarbeitung wird das Ergebnis der AW (Client) zur Verfgung
gestellt
Wichtige Eigenschaft:
Es gibt keine Replikation von DB-Daten
keine Nutzung vorhandener Referenzlokalitt im Client
65
Architektur
Weiteres Verarbeitungskonzept: Folgende Vorgehensweise wird von den
meisten Objektorientierten DBS (OODBS) verfolgt (data shipping
approach):
Alle Daten, die zur Ausfhrung einer Anfrage bentigt werden,
werden zum Client geholt und dort gepuffert
Danach wird die Anfrage (oder mehrere Anfragen hintereinander) im
Client-Puffer ausgewertet
Achtung: Die Komplexitt der Anfragen ist stark eingeschrnkt
- Typisch sind Navigationsoperationen
- Anfragen mit einfachen Suchargumenten (SSA: simple search arguments) werden
manchmal untersttzt, jedoch keine Verbundoperationen, Aggregationen, ...
- Dieses Konzept ist vor allem bei hoher Referenzlokalitt vorteilhaft.
Es wird durch das Check-out/Check-in-Konzept genutzt.
66
Architektur
Vorteile des Verschickens von Daten
- Lokale Datenpufferung reduziert die Interaktionen zwischen Client und Server
(Verminderung der Netzbelastung; Vermeidung von wiederholten Server-Anfragen)
- Aggregierte Rechnerleistung und die insgesamt verfgbare Speicherkapazitt des
Systems erhht sich
- Server-Last wird reduziert
Work- Skalierbarkeit des Systems
stations
Tools
Tools
Tools
wird verbessert
WDBMS
WDBMS
WDBMS
private DB
Client/Server-Architektur: Prinzip
- Lokale Platten fr private DB und Log-Daten
- Steigerung der Leistungsfhigkeit:
- verteiltes Server-System, parallele DB-Verarbeitung
Server SDBMS
Server-DB
67
Architektur
- File-Server, Page-Server
- Object-Server
- Query-Server
Client
Client/Server-Architekturen
fr objektorientierte DBS
- Im Objektpuffer erfolgt
typischerweise navigierende
Verarbeitung!
Anwendung
Anwendung
Anwendung
Object-Manager
Object-Manager
Object-Manager
(ggf. Objektpuffer)
Objektpuffer
Objektpuffer
Zugriffssystem
Kommunikation
Kommunikation
Seitenpuffer
Kommunikation
Server
Query-Manager
Transferpuffer
Object-Manager
Datensystem
Page-Manager
Zugriffssystem
Zugriffssystem
Seitenpuffer
Seitenpuffer
Seitenpuffer
Speichersystem
Speichersystem
Speichersystem
DB
DB
DB
Page-Server
Object-Server
Query-Server
68
Architektur
Transaktionsverarbeitung
Drei Aspekte:
Mit einer Transaktion (TA) wird ein
Vorgang einer Anwendung in einem
Rechnersystem abgewickelt. Ein
solcher Vorgang bildet typischerweise
einen nicht-trivialen Arbeitsschritt in
betrieblichen Ablufen.
Eine Online-Transaktion ist die
Ausfhrung eines Programms, das
mit Hilfe von Zugriffen auf eine
gemeinsam genutzte Datenbank eine
Anwendungsfunktion erfllt.
Eine Transaktion ist eine
ununterbrechbare Folge von DBOperationen, die die Datenbank von
einem logisch konsistenten Zustand in
einen anderen logisch konsistenten
Zustand berfhrt.
Anwendungsbereich
Exemplarische
Transaktionen
Banken
Kontenbuchungen,
Zinsberechnungen
Aktienhandel
Kauf von n Aktien einer

bestimmten AG
Versicherungen
Versicherungsprmie
bezahlen
Lagerverwaltung
Wareneingang
registrieren,
Warenbestand
anpassen
Handel
Verkauf registrieren
Verwaltung
KFZ-Zulassung, Anund Abmeldung
Electronic
Commerce
Online-Bestellung,
Suche in OnlineKatalog
Telekommunikation
Verbindungsnachweise
...
69
Architektur
Transaktionssysteme
Terminals
Kommunikationssystem / TP-Monitor
Schicht 1
Transaktionsprogramme (TAP)
Schicht 2
DB-Operationen
Schicht 3
DBMS
TP-Monitor
Datensystem
Zugriffssystem
Speichersystem
Schicht 4
Schicht 5
Betriebssystem (Dateiverwaltung)
Log-Datei
Datenbank
Datenbank
Quelle: [Ra93]
70
Architektur
Zusammenfassung
Allgemeine Aspekte des Schichtenmodells
Schichtenmodell ist allgemeines Erklrungsmodell fr die DBS-Realisierung
Schichtenbildung lsst sich zweckorientiert verfeinern/vergrbern:
- Anwendbarkeit fr Verteilte DBS, Client/Server-DBS, ...
Entwurf geeigneter Schnittstellen erfordert groe Implementierungserfahrung

Konkrete Implementierungen verletzen manchmal die Isolation der
Schichtenbildung aus Leistungsgrnden
(d.h. kritische Funktionen haben Durchgriff)
Implementierungskonzepte
Die grundlegenden Implementierungskonzepte zentralisierter DBS finden sich
auch in jedem Knoten eines verteilten DBS
Die Kenntnis der Implementierungskonzepte ermglicht es, existierende DBS
objektiv zu beurteilen und zu vergleichen
Ihre genaue Kenntnis ist Voraussetzung fr Leistungsanalysen bzw.
Abschtzungen des Systemverhaltens
Durch Identifizieren weniger, grundlegender Konzepte gelangt man zu einem
tieferen Verstndnis dessen, was mit Datenunabhngigkeit gemeint ist
71
Architektur
Ergnzende Literatur zu diesem Kapitel

[H05]
[Ra93]
[Ra94]
[TK78]
Hrder, T.: DBMS Architecture - The Layer Model and its Evolution. In:
Datenbank-Spektrum, Heft 13, Mai 2005, dpunkt-Verlag.
Rahm, E.: Hochleistungs-Transaktionssysteme, vieweg, 1993
Rahm, E.: Mehrrechner-Datenbanksysteme: Grundlagen der verteilten
und parallelen Datenbankverarbeitung. Addison-Wesley, 1994.
Tsichritzis, D. C., Klug, A.: The ANSI/X3/Sparc DBMS Framework
Report of the Study Group on Database Management Systems. In:
Information Systems 3:3, 1978.
72

Sprache

Willkommen bei Scribd!

chapter02.pdf

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Beschreibung:

Copyright:

Verfügbare Formate

chapter02.pdf

Hochgeladen von

Beschreibung:

Copyright:

Verfügbare Formate

Verwandte Titel

Anwendersoftware (AS)

Eine Datenbank (DB)

ist eine Sammlung gespeicherter Daten,

Ein Datenbankverwaltungssystem (DBVS, engl. DBMS)

DBS und Datenmodelle

objektorientierte DBS (ODBMS)

DBS: Weitere Klassifikationskriterien

Anzahl der Rechner

Fderative DBMS (FDBMS)

Lebensdauer Daten > Dauer Erzeugungsprozess

Integritt, Konsistenz, Verlustsicherheit

wechselseitige nderungsimmunitt AWP-DB

"hhere", abstrakte Schnittstelle

Gre Daten >> Gre Hauptspeicher

von/fr mehrere Anwendungen,

zeitgleicher Zugriff und Mehrbenutzerbetrieb

Anforderungen an ein DBS

Kontrolle ber die

Kontrolle ber die operationalen Daten

Alle Daten knnen/mssen gemeinsam benutzt werden

Leichte Handhabbarkeit der Daten

Beschreibung der logischen Aspekte der Daten

Logische Sicht der

zugeschnitten auf ihren Bedarf

unterschiedliche DBS bieten einheitliche Schnittstelle

Leichte Handhabbarkeit der Daten

Beispiel im Relationenmodell: DB-Schema

Leichte Handhabbarkeit der Daten

Beispiel im Relationenmodell: Ausprgungen

Leichte Handhabbarkeit der Daten

Deskriptive DB-Sprachen (wie SQL)

Leichte Handhabbarkeit der Daten

Leichte Handhabbarkeit der Daten

Beispiel im Hierarchiemodell: DB-Schema

Leichte Handhabbarkeit der Daten

Leichte Handhabbarkeit der Daten

2. Finde alle Studenten des Fachbereichs 5, die im Fach Datenverwaltung eine

Leichte Handhabbarkeit der Daten

Kontrolle der Datenintegritt

Kontrolle der Datenintegritt

Automatisierte Zugriffskontrollen (Datenschutz)

Kontrolle der Datenintegritt

Erhaltung der logischen Datenintegritt (system enforced integrity)

Beschreibung der Richtigkeit von Daten durch Prdikate und Regeln

Ablaufkontrollstruktur: Transaktion (TA)

ACID-Eigenschaften von Transaktionen

ACID-Eigenschaften von Transaktionen

Mgliche Ausgnge einer Transaktion

Kontrolle der Datenintegritt

Mgliche Anomalien im unkontrollierten Mehrbenutzerbetrieb

Schmutzige Daten drfen

Synchronisationskomponente des DBMS

Kontrolle der Datenintegritt

DBMS garantiert physische Datenintegritt:

Kontrolle der Datenintegritt

Erhaltung der physischen Datenintegritt

Manahmen der Recoverykomponente beim Wiederanlauf

Leistung und Skalierbarkeit

Leistung und Skalierbarkeit