Sie sind auf Seite 1von 72

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

Leichte Handhabbarkeit der Daten

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

Leichte Handhabbarkeit der Daten

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

Leichte Handhabbarkeit der Daten

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

Leichte Handhabbarkeit der Daten


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

Leichte Handhabbarkeit der Daten

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

Leichte Handhabbarkeit der Daten

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

Leichte Handhabbarkeit der Daten

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

Leichte Handhabbarkeit der Daten

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

Kontrolle der Datenintegritt

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

Kontrolle der Datenintegritt

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

Kontrolle der Datenintegritt

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

Kontrolle der Datenintegritt

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

Kontrolle der Datenintegritt

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
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

38

Architektur

Drei-Schema-Architektur nach ANSI-SPARC

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

Drei-Schema-Architektur nach ANSI-SPARC

Abstraktionsebenen
individuelle
Sichten

Externe
Ebene

Konzeptionelle
Ebene

gemeinschaftliche
Sicht

Interne
Ebene

Reprsentationssicht

40

Architektur

Drei-Schema-Architektur nach ANSI-SPARC


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

Drei-Schema-Architektur nach ANSI-SPARC


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=BYTE(20), OFFSET=12
TYPE=BYTE(4), OFFSET=32
TYPE=FULLWORD, OFFSET=36

42

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

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

Transaktionsprogramme
Adressierungseinheiten:
Blcke, Dateien
Hilfsstrukturen:
Dateikataloge, Freispeicher-Info, ...
Adressierungseinheiten:
Spuren, Kanle, Zylinder

Logische Datenstrukturen
Logische Zugriffspfade
Speicherungsstrukturen
Seitenzuordnungsstrukturen

Dateischnittstelle
Lies/Schreibe Block

Speicherzuordnungsstrukturen

Gerteschnittstelle
Kanalprogramme

Externspeichermedien
48

Architektur

5-Schichten-Modell

Transaktionsprogramme
Adressierungseinheiten:
Seiten; Segmente
Hilfsstrukturen:
Seitentabellen, Blocktabellen, ...

Logische Datenstrukturen

Adressierungseinheiten:
Blcke, Dateien

Logische Zugriffspfade
Speicherungsstrukturen

DB-Puffer-Schnittstelle

Stelle Seite bereit / gib Seite frei

Seitenzuordnungsstrukturen
Speicherzuordnungsstrukturen
Externspeichermedien
49

Architektur

5-Schichten-Modell

Transaktionsprogramme

Logische Datenstrukturen
Logische Zugriffspfade
Interne Satz-Schnittstelle

Speichere Satz (in B*-Baum), ...

Speicherungsstrukturen

Adressierungseinheiten:
Interne Stze, B*-Bume, Hash-Tabellen, ...

Seitenzuordnungsstrukturen

Hilfsstrukturen:
Seitenindices, Adresstabellen, ...

Speicherzuordnungsstrukturen

Adressierungseinheiten:
Seiten; Segmente

Externspeichermedien
50

Architektur

5-Schichten-Modell

Transaktionsprogramme

Logische Datenstrukturen
Satzorientierte DB-Schnittstelle
FIND NEXT/STORE ...

Logische Zugriffspfade

Adressierungseinheiten:
Externe Stze, Sets, Schlssel, Zugriffspfade, ...

Speicherungsstrukturen

Hilfsstrukturen:
Zugriffspfaddaten

Seitenzuordnungsstrukturen

Adressierungseinheiten:
Interne Stze, B*-Bume, Hash-Tabellen, ...

Speicherzuordnungsstrukturen
Externspeichermedien
51

Architektur

5-Schichten-Modell

Transaktionsprogramme
Mengenorientierte DB-Schnittstelle
SQL, QBE ...

Logische Datenstrukturen
Logische Zugriffspfade

Adressierungseinheiten:
Relationen, Sichten, Tupel

Speicherungsstrukturen

Hilfsstrukturen:
externe Schemabeschreibung

Seitenzuordnungsstrukturen

Adressierungseinheiten:
Externe Stze, Sets, Schlssel, Zugriffspfade, ...

Speicherzuordnungsstrukturen
Externspeichermedien
52

Architektur

5-Schichten-Modell

Relationen,
Sichten

ab

...

rec. 1
Externe Stze

rec. 2

aa

xyz

bb

xyz

xyz

rec. 3

ab

bb

xyz

Transaktionsprogramme
Interne Stze

aa

Logische Datenstrukturen
Logische Zugriffspfade

record 1
123

record 2
1

ab

456

record 3
2

bb

789

A
record1
DB-Puffer

record3
record2

Speicherungsstrukturen
Seitenzuordnungsstrukturen
Speicherzuordnungsstrukturen

C
A

Segment

A
1

Datei

A'
2

B
3

C
4

C'
5

Externspeichermedien

3
Externer Speicher

53

Architektur

Datenunabhngigkeit im 5-Schichtenmodell
Ebene

Was wird verborgen?

Logische Datenstrukturen

Positionsanzeiger und
explizite Beziehungskonstrukte im
Schema

Logische Zugriffspfade

Zahl und Art der physischen


Zugriffspfade;
interne Satzdarstellung

Speicherungsstrukturen

Pufferverwaltung;
Recovery-Vorkehrungen

Seitenzuordnungstrukturen

Dateiabbildung,
Recovery-Untersttzung durch das BS

Speicherzuordnungsstrukturen

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

Transaktionsverwaltung

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, ...

Transaktionsverwaltung

Realisierung der ACID-Eigenschaften


Synchronisation
Logging/Recovery
Integrittssicherung
56

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

57

Architektur

Bearbeitung einer DB-Anfrage


Anwendungsprogramm 1

logische
Datenstrukturen

Abbildung der Segmente auf Dateien, die aus Blcken fester Lnge be-

Speicherzuordnungsstrukturen

logische
Zugriffspfade

Seitenzuordnung

Speicherungsstrukturen

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

Bearbeitung einer DB-Anfrage

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

Bearbeitung einer DB-Anfrage


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
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

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

Schichtenmodelle fr Client/Server-DBS
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

Schichtenmodelle fr Client/Server-DBS
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

Schichtenmodelle fr Client/Server-DBS
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

Schichtenmodelle fr Client/Server-DBS
- 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