chapter02.pdf

Anwendersoftware (AS) 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

2

Architektur

Datenbanksystem (DBS) Zentrales Hilfsmittel fr Informationssysteme

Eine Datenbank (DB) 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).

3

DBS = DB + DBMS

Anwendungssysteme

Datenbanksysteme

Betriebssystem

Hardware

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.

4

Architektur

DBS und Datenmodelle

5

relationale DBS (RDBMS) hierarchische DBS

Netzwerk-DBS

XML-DBS

objektorientierte DBS (ODBMS)

Relationen/Tabellen

Abteilung

Projekt

Mitarbeiter

Datenstze

Hierarchie: Eltern/Kind-Beziehungen

Objekte u. Methoden

Datenstze

OWNER/MEMBER

Abteilung

Projekt

Dokument

hierarchisch strukturierte Elemente

Architektur

DBS: Weitere Klassifikationskriterien

6

Anzahl der Nutzer

Anzahl der Rechner

allgemein/aufgabenspezifisch

allgemein aufgabenspezifisch Einbenutzersysteme Mehrbenutzersysteme

zentrales DBMS verteiltes DBMS

homogene DBMS heterogene DBMS

Fderative DBMS (FDBMS)

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

8

DBS

Anforderungen an ein DBS

Kontrolle der D

atenintegritt

Kontrolle ber die operationalen Daten

Hoher Grad an Datenunabhngigkeit

Architektur

9

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

10

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

Architektur

11


Beispiel im Relationenmodell: DB-Schema

FBNR FBNAME DEKAN

PNR PNAME FBNR FACHGEB MATNR SNAME FBNR STUDBEG

PNR MATNR FACH DATUM NOTE

PROF

FB

STUDENT

PRFUNG

DB-Schema

Architektur

12


Beispiel im Relationenmodell: Ausprgungen

PRFUNG PNR MATNR FACH PDATUM NOTE 5678 123 766 BWL 22.10.97 4 4711 123 766 OR 16.01.98 3 1234 654 711 DV 17.04.97 2 1234 123 766 DV 17.04.97 4 6780 654 711 SP 19.09.97 2 1234 196 481 DV 15.10.97 1 6780 196 481 BS 23.12.97 3

FB FBNR FBNAME DEKAN FB 9 WIRTSCHAFTSWISS 4711 FB 5 INFORMATIK 2223

PROF PNR PNAME FBNR FACHGEB 1234 HRDER FB 5 DATENBANKSYSTEME 5678 WEDEKIND FB 9 INFORMATIONSSYSTEME 4711 MLLER FB 9 OPERATIONS RESEARCH 6780 NEHMER FB 5 BETRIEBSSYSTEME

STUDENT MATNR SNAME FBNR STUDBEG 123 766 COY FB 9 01.10.95 225 332 MLLER FB 5 15.04.87 654 711 ABEL FB 5 15.10.94 226 302 SCHULZE FB 9 01.10.95 196 481 MAIER FB 5 23.10.95 130 680 SCHMID FB 9 01.04.97

Architektur

13


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

oder Auswertungsrichtung Anfragebeispiele:

1. Finde alle Studenten aus Fachbereich 5, die ihr Studium vor 1995 begonnen haben. SELECT * FROM STUDENT WHERE FBNR = FB5 AND STUDBEG < 1.1.95

Architektur

14


2. Finde alle Studenten des Fachbereichs 5, die im Fach Datenverwaltung eine Note 2 oder besser erhalten haben.

SELECT * FROM STUDENT WHERE FBNR = FB5 AND MATNR IN (SELECT MATNR FROM PRFUNG WHERE FACH = DV AND NOTE 2)

3. Finde die Durchschnittsnoten der DV-Prfungen fr alle Fach- bereiche 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

Architektur

15


Beispiel im Hierarchiemodell: DB-Schema

FACH PDATUM NOTE

FBNR FBNAME DEKAN

PNR PNAME FACHGEB MATNR SNAME STUDBEG

MATNR PNR FACH PDATUM NOTE

FB

PROF STUDENT

ABGEHALTENE-PRFUNG

ABGELEGTE-PRFUNG

DB-Schema

Architektur

16


Beispiel im Hierarchiemodell: Ausprgungen

FB 9 WIRTSCHAFTSWISS 4711

226 302 SCHULZE 1.10.95

1234 DV 417.4.974711 OR 316.1.98

5678 BWL 422.10.97

4711 MLLER5678 WEDEKIND

123 766 22.10.97

OR

4BWL

INF

123 766 16.1.98 3OR

123 608 SCHMID 1.4.97123 766 COY 1.10.95

Ausprgungen (1)

Ausprgungen (2) FB 5 INFORMATIK 2223

225 332 MLLER 15.4.87

6780 SP 219.9.971234 DV 217.4.97

6780 NEHMER1234 HRDER

196 481 15.10.97

BS

1DV

DBS

196 481 23.12.97 3BS

196 481 MAIER 23.10.95654 711 ABEL 15.10.94

654 711 19.9.97 2SP

654 711 17.4.97 2DV123 766 17.4.97 4DV

6780 BS 323.12.971234 DV 115.10.97

Architektur

17


Anfragebeispiele 1. Finde alle Studenten aus Fachbereich 5, die ihr Studium vor 1990 begonnen

haben. GU FB (FBNR = FB5); NEXT_STUDENT: 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. GU FB (FBNR = FB5); NEXT_STUDENT: 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;

Architektur

18


Prozedurale DB-Sprachen bei hierarchischen Datenmodellen Programmierer als Navigator satzweiser Zugriff ber vorhandene Zugriffspfade unnatrliche Organisation bei komplexen Beziehungen (n:m) Auswertungsrichtung ist vorgegeben

Architektur

Kontrolle der Datenintegritt

Automatisierte Zugriffskontrolle logische Datenintegritt logischer Einbenutzerbetrieb physische Datenintegritt

19

Transaktionskonzept

Architektur

20


Automatisierte Zugriffskontrollen (Datenschutz) separat fr jedes Datenobjekt unterschiedliche Rechte fr verschiedene Arten des Zugriffs Idealziel: least privilege principle

gewnschte Autorisierung

gewnschte Systemleistung

Autorisierungs- system

berwachungs- system

Schreiben Lesen

Vergabe und Entzug von Zugriffsrechten

Annahme oder Abweisung von Auftrgen

Schutz- info.

Architektur

21


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

Architektur

22

Klassische Transaktionsverarbeitung

Transaktionssystem

UPDATE accounts SET balance = balance - 1000 WHERE K# = 03874; UPDATE accounts SET balance = balance + 1000 WHERE K# = 01099;

900

0387

4

# Kontostand

OK EOT

BOT

Tran

sakt

ions

- Pr

ogra

mm

e

Datenbanksystem

Karte ? PIN ? Konto ? Buchung Ausgabe

0109

9

1500

-100

2500

Architektur

23

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

Architektur

24

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

Architektur

25

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

Architektur

26

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)

Schnittstelle zwischen Anwendungsprogramm (AP) und DBS

SAVEPOINT Definiert einen Sicherungspunkt

innerhalb der Transaktion ROLLBACK [WORK]

TO SAVEPOINT Setzt die aktive Transaktion auf

einen Sicherungspunkt zurck

Architektur

27

Mgliche Ausgnge einer Transaktion

BOT BOT BOT

DML1

DML2

DML3

DMLn

COMMIT

normales Ende

DML1

DML2

DML3

DMLn

ROLLBACK

abnormales Ende

DML1

DML2

DML3

abnormales Ende

Systemausfall, Programmfehler, usw.

erzwungenes ROLLBACK

erzwungenes

Architektur

Einbenutzer-/Mehrbenutzerbetrieb

Mgliche Anomalien im unkontrollierten Mehrbenutzerbetrieb Dirty Read Lost Update Inkonsistente Analyse Phantom-Problem


Mehrbenutzer- betrieb

T1

T2

T3

t

Einbenutzer- betrieb

T1

T2

T3

Architektur

29

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

Schmutzige Daten drfen von anderen TAs nicht benutzt werden

T1 T2

Read (A); A := A + 100; Write (A);

Read (A); Read (B); B := B + A; Write (B); Commit;

Rollback;

Zeit

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.

T1

T2 T4 T7

T6

T3 T5

System- absturz A A' B B'

C C'

A B' C' A B C

31

Architektur

32


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)

Architektur

33

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

Architektur

34

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

Architektur

35

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

Leistungsverhaltens 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

Architektur

36


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

Architektur

37


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

Architektur

bersicht



38

Architektur

Drei-Schema-Architektur nach ANSI-SPARC

Schichtenmodell aus Benutzungssicht

ANSI: American National Standards Institute, SPARC-Komitee: Study Group on Database Management Systems, http://www.ansi.org

Quelle: [TK78]

Daten- Definition

Daten- Manipulation

Daten- Administration

Externe Ebene

Ext. Schema 1

Ext. Schema n . . .

Konzeptionelle Ebene

Konz. Schema

Interne Ebene

Int. Schema

39

Architektur

Abstraktionsebenen


Konzeptionelle Ebene

Interne Ebene

Externe Ebene

gemeinschaftliche Sicht

Reprsentations- sicht

individuelle Sichten

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 PERS, 2 PNR CHAR(6), 3 GEH FIXED BIN(31) 4 NAME CHAR(20)

Extern (COBOL)

01 PERSC. 02 PERSNR PIC X(6). 02 ABTNR PIC X(4).

Konzeptionelles Schema

ANGESTELLTER ANG_NUMMER CHARACTER (6) NAME CHARACTER (20) ABT_NUMMER CHARACTER (4) GEHALT NUMERIC (5)

Internes Schema

SPEICHERUNG_PERS LENGTH=40 PREFIX TYPE=BYTE(6), OFFSET=0 PNR TYPE=BYTE(6), OFFSET=6, INDEX=PNR NAME TYPE=BYTE(20), OFFSET=12 ANR TYPE=BYTE(4), OFFSET=32 GEHALT TYPE=FULLWORD, OFFSET=36

42

Architektur

bersicht



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:

benutzt-Relation: A benutzt B, wenn A B aufruft und die korrekte Ausfhrung von B fr die vollstndige Ausfhrung von A notwendig ist

Schicht i

Operatoren: Oi,1, Datenobjekte: ti,1,

realisiert

Schicht i + 1 benutzt

+ Implementierungs- sprache

Qi+1,p (ti+1, q)

Operatoren: Oi+1,1, Datenobjekte: ti+1,1,

Oi,r(ti, 1,,ti,k), , Oi,s(ti,1,,ti,n)

45

Architektur

Schichtenbildung im Schichtenmodell

Vorteile als Konsequenzen der Nutzung hierarchischer Strukturen und der benutzt-Relation 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

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

Externspeichermedien Gerteschnittstelle

Kanalprogramme

Dateischnittstelle Lies/Schreibe Block

DB-Puffer-Schnittstelle Stelle Seite bereit / gib Seite frei

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

Satzorientierte DB-Schnittstelle FIND NEXT/STORE ...

Mengenorientierte DB-Schnittstelle SQL, QBE ...

Speicherzuordnungsstrukturen

Seitenzuordnungsstrukturen

Speicherungsstrukturen

Logische Zugriffspfade

Logische Datenstrukturen

Transaktionsprogramme

47

Architektur

Externspeichermedien







Dateischnittstelle Lies/Schreibe Block

Adressierungseinheiten: Blcke, Dateien

Hilfsstrukturen: Dateikataloge, Freispeicher-Info, ...

Adressierungseinheiten: Spuren, Kanle, Zylinder

Gerteschnittstelle Kanalprogramme

5-Schichten-Modell

48

Architektur








Adressierungseinheiten: Seiten; Segmente

Hilfsstrukturen: Seitentabellen, Blocktabellen, ...

Adressierungseinheiten: Blcke, Dateien

DB-Puffer-Schnittstelle Stelle Seite bereit / gib Seite frei

5-Schichten-Modell

49

Architektur








Adressierungseinheiten: Seiten; Segmente

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

5-Schichten-Modell

Hilfsstrukturen: Seitenindices, Adresstabellen, ...

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

50

Architektur








Satzorientierte DB-Schnittstelle FIND NEXT/STORE ...

5-Schichten-Modell

Hilfsstrukturen: Zugriffspfaddaten

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

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

51

Architektur








Mengenorientierte DB-Schnittstelle SQL, QBE ...

5-Schichten-Modell

Adressierungseinheiten: Relationen, Sichten, Tupel

Hilfsstrukturen: externe Schemabeschreibung

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

52

Architektur








5-Schichten-Modell Relationen, Sichten rec. 2 rec. 1 rec. 3

Externe Stze

Interne Stze

... ab 2 xyz a bb 3 xyz b

1 aa 2 ab 3 bb 2 xyz a 3 xyz b

aa 123 1 ab 456 2 bb 789 3

record 1 record 2 record 3

DB-Puffer

Datei

Segment

Externer Speicher

record1

record2

record3

A

B

C

A

1 2 3 4 5

B C

A A' B C C'

1

2

3

4

5

53

Architektur

Datenunabhngigkeit im 5-Schichtenmodell

Ebene Logische Datenstrukturen



Seitenzuordnungstrukturen


Was wird verborgen? Positionsanzeiger und

explizite Beziehungskonstrukte im Schema

Zahl und Art der physischen Zugriffspfade; interne Satzdarstellung

Pufferverwaltung; Recovery-Vorkehrungen

Dateiabbildung, Recovery-Untersttzung durch das BS

Technische Eigenschaften und Betriebsdetails der externen Speichermedien

54

Architektur

Weitere Komponenten in der DBS-Architektur

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:

Transaktions- verwaltung

Datensystem

Zugriffssystem

Speichersystem

Metadaten- verwaltung

55

Architektur

Weitere Komponenten in der DBS-Architektur

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



57

Architektur

Bearbeitung einer DB-Anfrage

logische Daten- strukturen

logische Zugriffs- pfade

Speiche- rungs- strukturen

Speicherzu- ordnungs- strukturen

Seiten- zuordnung

Pufferverwaltung

Datenbankpuffer: jeder Pufferrahmen kann eine Seite aufnehmen

Abbildung der Segmente auf Datei- en, die aus Blcken fester Lnge be- stehen

UWA 1

Arbeitsbereich zur Bearbeitung der diesem Programm zugng-

lichen Daten- objekte

UWA n

Arbeitsbereich zur Bearbeitung der diesem Programm zugng-

lichen Daten- objekte

Anwendungsprogramm 1

Anwendungsprogramm n

58

Architektur


Anwendungs- programm n

Statusinformation

Arbeitsbereich 1

Statusinformation

Arbeitsbereich n

Anwendungs- programm 1

Internes Schema

Konzep- tionelles Schema

Externes Schema A1

Externes Schema An

Betriebssystem

Hauptspeicher

Datenbankver-

DB-Puffer

Datenbank

Externspeicher

1

waltungssystem

3 4

5

6

6

7

8

9

2

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



61

Architektur

Klassifikation verteilter Datenbanksysteme

Vorgehensweise bei der Verteilung - Partitionierung der Daten

(ggf. mit Replikation) - Kommunikation zwischen Prozessen

zum Zugriff auf jeweils lokale Daten

Homogenes Systemmodell

Lokale Benutzersicht

Globale Systemsicht: Verteilung

lokale Systemsicht

lokale Systemsicht

DB

MS

- S

chic

hten

Datensystem

Zugriffssystem

Speichersystem

D B M S

1

2

3

Datensystem

Zugriffssystem

Speichersystem

Gewnschte Sichtbarkeit

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

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

DB - P1

DBMS

DB - P3

DBMS

DB - P2

DBMS

AP AP AP

63

Architektur

Fderierte Datenbanksysteme (FDBS)

Transparenter Zugriff auf mehrere heterogene und weitgehend autonome Datenquellen

Vollstndiges DBMS Kompensiert Funktionalitt, die in

einzelnen Datenquellen fehlt globale Anfrageoptimierung

Katalog Daten

Daten

Daten

Datenquelle

Datenquelle

Fderiertes Datenbank System

SQL API

Benutzer

Wrapper

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


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 - Skalierbarkeit des Systems

wird verbessert

Client/Server-Architektur: Prinzip - Lokale Platten fr private DB und Log-Daten - Steigerung der Leistungsfhigkeit: - verteiltes Server-System, parallele DB-Verarbeitung

WDBMS

SDBMS Server

Work- stations

Server-DB

Tools

WDBMS

Tools

WDBMS

Tools

private DB

67

Architektur


Client/Server-Architekturen fr objektorientierte DBS

- File-Server, Page-Server - Object-Server - Query-Server

- Im Objektpuffer erfolgt

typischerweise navigierende Verarbeitung!

Zugriffssystem

Seitenpuffer

Kommunikation

Seitenpuffer

Kommunikation

Seitenpuffer

Anwendung

Kommunikation

Seitenpuffer

Clie

ntS e

rver

Page-Server Object-Server Query-Server

Speichersystem

DB

Speichersystem Speichersystem

Anwendung

Object-Manager(ggf. Objektpuffer)

Object-ManagerObjektpuffer

Object-Manager

Object-Manager

Objektpuffer

Anwendung

Query-ManagerTransferpuffer

Page-Manager Zugriffssystem Zugriffssystem

Datensystem

DBDB

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 DB-Operationen, die die Datenbank von einem logisch konsistenten Zustand in einen anderen logisch konsistenten Zustand berfhrt.

Anwendungs-bereich

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, An- und Abmeldung

Electronic Commerce

Online-Bestellung, Suche in Online-Katalog

Telekommunikation Verbindungsnachweise

...

69

Architektur

Transaktionssysteme

Terminals Schicht 1 Schicht 2

Schicht 3

Schicht 4

Schicht 5

Kommunikationssystem / TP-Monitor

Transaktionsprogramme (TAP)

TP-Monitor

Datensystem Zugriffssystem Speichersystem

Betriebssystem (Dateiverwaltung)

Log-Datei Datenbank Datenbank

DB

MS

DB-Operationen

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] Hrder, T.: DBMS Architecture - The Layer Model and its Evolution. In: Datenbank-Spektrum, Heft 13, Mai 2005, dpunkt-Verlag.

[Ra93] Rahm, E.: Hochleistungs-Transaktionssysteme, vieweg, 1993 [Ra94] Rahm, E.: Mehrrechner-Datenbanksysteme: Grundlagen der verteilten

und parallelen Datenbankverarbeitung. Addison-Wesley, 1994. [TK78] 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

Datenbanken und InformationssystemebersichtDatenbanksystem (DBS)DatenmodellDBS und DatenmodelleDBS: Weitere KlassifikationskriterienDatenbanktechnologieAnforderungen an ein DBSKontrolle ber die operationalen DatenLeichte Handhabbarkeit der DatenLeichte Handhabbarkeit der DatenLeichte Handhabbarkeit der DatenLeichte Handhabbarkeit der DatenLeichte Handhabbarkeit der DatenLeichte Handhabbarkeit der DatenLeichte Handhabbarkeit der DatenLeichte Handhabbarkeit der DatenLeichte Handhabbarkeit der DatenKontrolle der DatenintegrittKontrolle der DatenintegrittKontrolle der DatenintegrittKlassische TransaktionsverarbeitungAblaufkontrollstruktur: Transaktion (TA)ACID-Eigenschaften von TransaktionenACID-Eigenschaften von TransaktionenSchnittstelle zwischen Anwendungsprogramm (AP) und DBSMgliche Ausgnge einer TransaktionKontrolle der DatenintegrittDirty ReadLogischer EinbenutzerbetriebKontrolle der DatenintegrittKontrolle der DatenintegrittTransaktionsverwaltungLeistung und SkalierbarkeitLeistung und SkalierbarkeitHoher Grad an DatenunabhngigkeitHoher Grad an DatenunabhngigkeitbersichtDrei-Schema-Architektur nach ANSI-SPARCDrei-Schema-Architektur nach ANSI-SPARCDrei-Schema-Architektur nach ANSI-SPARCDrei-Schema-Architektur nach ANSI-SPARCbersichtEntwurfsziele fr DBSSchichtenbildung im SchichtenmodellSchichtenbildung im Schichtenmodell5-Schichten-Modell 5-Schichten-Modell5-Schichten-Modell5-Schichten-Modell5-Schichten-Modell5-Schichten-Modell5-Schichten-ModellDatenunabhngigkeit im 5-SchichtenmodellWeitere Komponenten in der DBS-ArchitekturWeitere Komponenten in der DBS-ArchitekturbersichtBearbeitung einer DB-AnfrageBearbeitung einer DB-AnfrageBearbeitung einer DB-AnfragebersichtKlassifikation verteilter DatenbanksystemeMehrrechner-DBSFderierte Datenbanksysteme (FDBS)Schichtenmodelle fr Client/Server-DBSSchichtenmodelle fr Client/Server-DBSSchichtenmodelle fr Client/Server-DBSSchichtenmodelle fr Client/Server-DBSTransaktionsverarbeitungTransaktionssystemeZusammenfassungErgnzende Literatur zu diesem Kapitel

Documents

chapter02.pdf