93kB - Praktische Informatik

Architektur von DBMS
Udo Kelter
26.11.2013
Zusammenfassung dieses Lehrmoduls
Dieses Lehrmodul gibt eine erste Einführung in die Architektur
von DBMS. Einleitend betrachten wir ein DBMS aus einer Gesamtsicht
und konzentrieren uns dann auf zwei wichtige Aspekte des
DBMS-Kerns: (a) wir zeigen, daß i.d.R. der Datenbankkern als eigener
Hintergrundprozeß ausgeführt werden muß, und wir diskutieren
die Konsequenzen hinsichtlich der Performanceoptimierung. (b) Wir
skizzieren, in welchen Stufen die Datenobjekte, mit denen das Datenbankmodell
operiert, auf Datenstrukturen im Hauptspeicher und
letztlich auf Magnetplatten oder anderen persistenten Speichermedien
abgebildet werden.
Vorausgesetzte Lehrmodule:
obligatorisch:
empfohlen:
– Datenverwaltungssysteme
– Schnittstellen zu Datenbankinhalten
Stoffumfang in Vorlesungsdoppelstunden: 1.0
1

Architektur von DBMS 2
Inhaltsverzeichnis
1 Einleitung 3
2 Produkt vs. Laufzeitkern 3
3 Prozeßarchitektur von Informationssystemen 4
4 Eine Abstraktionshierarchie von Datenbankobjekten 8
4.1 Übersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2 Ebene 0: physische Blöcke . . . . . . . . . . . . . . . . . . . . 10
4.3 Ebene 1: DB-Segmente und DB-Seiten . . . . . . . . . . . . . 10
4.4 Ebene 2: Zugriffsmethode für Sätze . . . . . . . . . . . . . . . 12
4.4.1 Zugriffsstrukturen . . . . . . . . . . . . . . . . . . . . 12
4.4.2 Realisierung von Sätzen auf Seiten . . . . . . . . . . . 15
4.4.3 Indexe . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.5 Ebene 3: Einzelobjekt-Operationen . . . . . . . . . . . . . . . 17
4.6 Ebene 4: Mengen-Schnittstelle . . . . . . . . . . . . . . . . . 18
4.7 Beziehung zur 3-Ebenen-Schema-Architektur . . . . . . . . . 18
Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
c○2013 Udo Kelter Stand: 26.11.2013
Dieser Text darf für nichtkommerzielle Nutzungen als Ganzes und unverändert in elektronischer oder
gedruckter Form beliebig weitergegeben werden und in WWW-Seiten, CDs und Datenbanken aufgenommen
werden. Jede andere Nutzung, insb. die Veränderung und Überführung in andere Formate, bedarf
der expliziten Genehmigung. Die jeweils aktuellste Version ist über http://kltr.de erreichbar.

Architektur von DBMS 3
1 Einleitung
Dieses Lehrmodul gibt einen ersten Einblick in den Aufbau und die
Struktur eines DBMS.
Der Begriff Architektur ist mehrdeutig (eine allgemeinere Diskussion
dieses Begriffs findet sich in [SAR]); wir werden hier primär
die Software-Komponenten betrachten, aus denen ein DBMS besteht.
Hierbei kann es sich sowohl um selbständig lauffähige Programme als
auch um Schichten innerhalb von Programmen, insb. dem Laufzeitkern,
handeln. Wir werden hier ebenfalls auf die Prozeßarchitektur,
also die Struktur der Prozesse zur Laufzeit, eingehen.
Es gibt keine Einheitsarchitektur, die bei allen DBMS gleichartig
anzutreffen wäre, noch nicht einmal bei einer vergröberten Betrachtung.
Die Architektur eines DBMS hängt ganz erheblich von mehreren
Faktoren ab:
– natürlich vom Datenbankmodell, hier insb. davon, ob ein navigierendes
oder ein mengenorientiertes Datenbankmodell vorliegt
– von der Art, wie Applikationen technisch an das DBMS angebunden
werden
– von den ggf. vorhandenen Verteilungskonzepten
– von der “Größenklasse” und damit zusammenhängend den Optimierungszielen.
2 Produkt vs. Laufzeitkern
Wenn man ein DBMS-Produkt kauft, wird man auf der Installations-
CD eine (erschreckend) hohe Zahl von Programmen finden, die man
wie folgt gruppieren kann:
– Laufzeitkern: diese Programme und Programmteile (Bibliotheken)
werden während der “produktiven” Nutzung des DBMS ausgeführt.
– Administrations- und Dienstprogramme (s. auch Bild 3 in [DVS])
für diverse Zwecke:
– Installation
c○2013 Udo Kelter Stand: 26.11.2013

Architektur von DBMS 4
– Überwachung des laufenden Betriebs und Gewinnung von statistischen
Daten
– Performance-Tuning
– Sicherheitsüberwachung
– Backup der Datenbank, Verwaltung von Tertiärspeichermedien,
Prüfen und ggf. Reparieren der Datenbank
– Benutzeradministration
– Verwaltung registrierter Anwendungen
– Accounting
– Programme, die das Entwickeln von Applikationen unterstützen;
man kann diese als eine angepaßte Software-Entwicklungsumgebung
ansehen. Beispiele sind Präprozessoren, die in Quelltexte
eingebettete Anweisungen vorübersetzen, oder Editoren, mit denen
man die Datenbankschemata spezifizieren kann.
Die Abgrenzung zwischen den Dienstprogrammen und den Entwicklungswerkzeugen
ist nicht ganz scharf. Wenn separate Entwicklungs-
und “Produktions”rechner benutzt werden, sind die Entwicklungswerkzeuge
typischerweise nur auf dem Entwicklungsrechner installiert.
Dienstprogramme und Entwicklungswerkzeuge sind zwar für die
praktische Nutzung von DBMS sehr wichtig, auf sie wird aber in Vorlesungen
und Lehrbüchern über Datenbanken fast nicht eingegangen
– so auch hier. Allgemeine Kenntnisse über Datenmodelle und Kenntnisse
über die Laufzeitkerne haben insofern höhere Priorität, als sie
bei der Behandlung der Dienstprogramme und Entwicklungswerkzeuge
stets vorausgesetzt werden müssen.
3 Prozeßarchitektur von Informationssystemen
Informationssysteme kann man i.d.R. in 3 Softwareschichten strukturieren
(s. Bild 1 in [DVS]):
c○2013 Udo Kelter Stand: 26.11.2013

Architektur von DBMS 5
– GUI / Benutzerinteraktion
– Realisierung der Fachkonzepte, Applikationssemantik
– Datenverwaltung
Im einfachsten Fall kann man die zugehörigen Module zu einem
einzigen Programm zusammenbinden, d.h. diese Module würden in
den virtuellen Hauptspeicher eines Betriebssystemprozesses geladen
und dort gemeinsam ausgeführt. Hinsichtlich der Ziele, die durch den
Einsatz von DBMS angestrebt werden, hätte eine solche 1-Prozeß-
Architektur aber gravierende Nachteile:
– Das DBMS kann aus Performancegründen nicht nur auf den persistenten
Medien (also Platten) arbeiten, sondern muß große Teile der
Datenbank in Puffer in den Hauptspeicher laden und primär auf diesen
Pufferinhalten arbeiten. Nun war es ein Ziel von DBMS, vielen
Benutzern und Applikationen gleichzeitig Zugriff auf die Datenbank
zu ermöglichen. Dies würde bei einer 1-Prozeß-Architektur bedeuten,
daß jede Applikation eigene Puffer hätte und daß dort Teile der
Datenbank lägen, die ggf. schon gegenüber dem Zustand auf der
Platte verändert worden sind. Wollte eine andere Applikation jetzt
auf diese Teile der Datenbank zugreifen, müßte sie herausfinden, ob
eine und ggf. welche andere Applikation diese Teile der Datenbank
gerade puffert und sich an diese Applikation wenden. Jedes Applikationsprogramm
müßte also gleichzeitig als Server für die zufällig
gerade in seinen Puffern befindlichen Teile der Datenbank arbeiten.
Dies ist völlig inpraktikabel.
– Ein weiteres Ziel von DBMS bestand darin, Zugriffskontrollen zu
realisieren, d.h. nicht autorisierten Benutzern den Zugang auf bestimmte
Daten zu verwehren. Bei einer 1-Prozeß-Architektur können
solche Dienste aber nicht sicher implementiert werden (zumindest
bei allgemein verfügbaren Programmiersprachen und Betriebssystemen).
In fast allen gängigen höheren Programmiersprachen
und erst recht in maschinennahen Sprachen können Zeiger manipuliert
werden, und es kann im Prinzip auf beliebige Adressen im
(virtuellen) Hauptspeicher zugegriffen werden. Dies bedeutet, daß
die Applikation auch direkt auf die Inhalte der Datenbankpuffer
c○2013 Udo Kelter Stand: 26.11.2013

Architektur von DBMS 6
zugreifen und dort Daten auslesen und verändern könnte, d.h. die
Zugriffskontrollmechanismen sind umgehbar.
– Unkontrollierte Zugriffe des Applikationsprogramms könnten darüber
hinaus interne Datenstrukturen des DBMS zerstören und so
zu Programmabstürzen führen.
Die einzige praktikable Alternative, das DBMS und die Datenbankpuffer
vor direkten Zugriffen durch die Applikation zu schützen,
besteht darin, diese Programme bzw. Daten in einen separaten Betriebssystemprozeß
zu laden, s. Bild 1. Aus der Sicht von Applikationen
ist diese Verlagerung des DBMS-Laufzeitkerns in einen anderen
Prozeß i.w. nicht sichtbar, denn das API zum DBMS bleibt völlig
unverändert. “Hinter dem API” liegt aber jetzt keine Implementierung
mehr, sondern eine Bibliothek oder ein RPC- (remote procedure
call) Mechanismus, der die Operationsaufrufe i.w. unverarbeitet an
den Serverprozeß sendet, welcher die eigentliche Operation ausführt
und die Ergebnisse zurücksendet.
[G]UI der
Applikation
Server
Applikations-
DBMS-
Server
Appl-API
Bibliothek
DBMS-API
Bibliothek
Datenbank
Abbildung 1: Prozeßarchitektur von Informationssystemen
Aus Performance-Gründen kann es sinnvoll sein, auch das GUI und
die Applikationssemantik verschiedenen Prozessen zuzuordnen; es ergibt
sich dann die in Bild 1 gezeigte Struktur mit 3 Prozessen.
Für die technische Realisierung eines solchen entfernten Operationsaufrufs
gibt es diverse Alternativen, die nicht hier, sondern im
c○2013 Udo Kelter Stand: 26.11.2013

Architektur von DBMS 7
Rahmen von Vorlesungen über Rechnernetze behandelt werden. Die
Merkmale dieser Mechanismen sind für unsere Diskussion weitgehend
irrelevant bis auf die beiden folgenden Punkte:
– Wenn ein Applikationsprogramm gestartet wird, muß es herausfinden
können, ob schon ein Serverprozeß für die Datenbank läuft und
wie es Kontakt zu diesem Serverprozeß aufnehmen kann. Hierzu
müssen Hilfssysteme verfügbar sein, die entsprechende Auskünfte
geben können und den Verbindungsaufbau teilweise automatisieren.
Die Struktur dieser Hilfssysteme hängt stark von der Kommunikationstechnologie
ab, die eingesetzt wird. Insgesamt ist die
Installation und Benutzung eines DBMS im Vergleich zu Dateien
dadurch wesentlich komplizierter und erfordert Kenntnisse in der
gewählten Kommunikationstechnologie.
– Ein entfernter Operationsaufruf ist deutlich ineffizienter als ein lokaler.
Ein lokaler Operationsaufruf innerhalb eines Programms verursacht
einen Aufwand, der je nach Umfang der Parameter in der
Größenordnung von einigen Dutzend oder hundert Maschineninstruktionen,
bei heutigen Prozessoren also in der Größenordnung
von Mikrosekunden liegt. Bei einem entfernten Operationsaufruf
sind zwei Fälle zu unterscheiden:
1. Der Serverprozeß läuft auf dem gleichen Rechner: in diesem
Fall werden zuerst die Parameter geeignet codiert, der aufrufende
Prozeß wird stillgelegt, der wartende Serverprozeß wird
aktiviert, er entpackt die Parameter und führt die gewünschte
Operation aus. Nach Beendigung der Operationsausführung
werden umgekehrt die Ergebnisse an den aufrufenden Prozeß
zurücktransferiert. Die beiden Prozeßwechsel und die beiden
Datenübertragungen kosten typischerweise Rechenzeit in der
Größenordnung von 0.1 Millisekunden.
2. Der Serverprozeß läuft auf einem anderen Rechner. In diesem
Fall kommt bei beiden Kommunikationen der Kommunikationsaufwand
hinzu; hier muß mit einem Mindestaufwand in der
Größenordnung von 1 Millisekunde (bei langsamen Netzen auch
mehr) gerechnet werden, ferner ist die Übertragungsbandbreite
c○2013 Udo Kelter Stand: 26.11.2013

Architektur von DBMS 8
signifikant kleiner.
Hieraus folgt bereits, daß ein entfernter Aufruf bedeutend teurer
(Faktor: ca. 1000 bis 10000) ist als ein lokaler und daß man
sich in interaktiven Systemen, die gute Antwortzeiten haben sollen,
nur wenige (Größenordnung 10 bis 100) Datenbankzugriffe pro
Interaktion leisten kann.
Sofern die Menge der als Eingabeparameter oder Rückgabewerte
übertragenen Daten in der Größenordnung von einigen kB liegt, hat
sie auf diese Zeiten praktisch keinen Einfluß, erst bei deutlich größeren
Datenmengen oder sehr langsamen Netzwerken beeinflußt sie
die Gesamtzeit proportional zum Übertragungsvolumen. Hieraus
folgt als weitere Erkenntnis, daß es performanter ist, wenige umfangreichere
Operationen aufzurufen als viele kleine.
4 Eine Abstraktionshierarchie von Datenbankobjekten
4.1 Übersicht
Jedes DBMS muß letztlich die Datenstrukturen seines Datenbankmodells
auf Basis des unterliegenden Dateisystems oder, bei direktem Zugriff
auf die Hardware, der Platten realisieren. Die Diskrepanz dieser
beiden Denkwelten ist erheblich, daher wird diese Realisierung typischerweise
in mehrere Schritte eingeteilt, bei denen - von unten nach
oben gesehen - jeweils ein neuer Typ von internen Speichereinheiten
realisiert wird. Man kann sich diese Schichtung durch mehrere aufeinander
aufbauende Pakete veranschaulichen (s. Bild 2) 1 . Wir skizzieren
i.f. ein derartiges Schichtenmodell für interne Speichereinheiten bzw.
Datenbankobjekte und gehen anschließend im Detail auf die Schichten
ein:
– Die unterste Ebene operiert mit Blöcken, die über Medienadressen
1 Reale DBMS-Kerne sind deutlich komplizierter, insofern ist dieses Bild keine
exakte, sondern allenfalls eine partielle und vereinfachende Darstellung der Architektur
eines DBMS-Kerns.
c○2013 Udo Kelter Stand: 26.11.2013

Architektur von DBMS 9
Ebene 4: n-Tupel/Objekte
Ebene 3: 1-Tupel/Objekt
Ebene 2: Speichersätze
Ebene 1: Segmente/Seiten
Ebene 0: physische Blöcke
Abbildung 2: Vereinfachte Schichtenarchitektur eines Laufzeitkerns
und resultierende Abstraktionshierarchie von Datenbankobjekten
identifiziert werden und die zwischen den persistente Medien und
dem Arbeitsspeicher übertragen werden.
– Auf Ebene 1 wird die durch die Hardware vorgegebene Menge der
Blöcke zu Segmenten gruppiert. Segmente ähneln insofern Dateien,
als sie angelegt und gelöscht werden können und ihre Größe (also
die Menge der zugeordneten Blöcke) wachsen oder schrumpfen
kann.
– In Ebene 2 wird der Inhalt einzelner Segmente, der sich auf Ebene
1 noch als Folge von Seiten darstellt, feinkörniger strukturiert,
typischerweise als Folge oder Verzeichnis von (Speicher-) Sätzen.
Integriert hierin sind (primäre) Indexe, z.B. B*-Bäume.
– In Ebene 3 wird der Inhalt einzelner Sätze, der sich auf Ebene 2
noch als unstrukturiertes Bytefeld darstellt, in Felder strukturiert,
die den Attributen von Tupeln oder Objekten entsprechen. Auf
dieser Ebene werden die konzeptuellen Schemata in konkrete Speicherstrukturen
umgesetzt.
– Während Ebene 3 Operationen realisiert, die mit einzelnen Tupeln
oder Objekten arbeiten, realisiert Ebene 4 Operationen mit Menc○2013
Udo Kelter Stand: 26.11.2013

Architektur von DBMS 10
gen von Objekten. Dieser Ebene ist u.a. der Problemkomplex der
Optimierung zuzuordnen.
Wir betrachten i.f. die Ebenen detaillierter und beginnen bei der
Hardware als unterster Ebene.
4.2 Ebene 0: physische Blöcke
Ein physischer Block ist ein Datenbereich auf einem Permanentspeicher
wie Magnetplatte, optische Platte, Band usw., dessen (Netto-)
Inhalt von der Hardware und den zugehörigen Treibern zwischen dem
Speichermedium und dem Hauptspeicher transportiert werden kann.
Normalerweise werden physische Blöcke nur durch das Dateimanagementsystem
des Betriebssystems verwaltet, d.h. Anwendungsprogramme
können überhaupt nicht direkt damit arbeiten, sondern arbeiten
nur mit Dateien, die bereits eine eigene Abstraktionsschicht oberhalb
der physischen Blöcke darstellen. Die von Betriebssystemen realisierten
Dateisysteme sind allerdings nicht optimal angepaßt an den Bedarf
von DBMS, daher umgehen manche DBMS das Betriebssystem und
greifen “direkt” auf die Platte zu.
Für uns sind nur zwei Operationen mit physischen Blöcken relevant,
nämlich der Transport vom Medium in einen Hauptspeicherbereich
und umgekehrt. Für die Speicherung einer Datenbank eignen
sich nur solche Medien, bei denen man direkt, also schnell, auf jeden
vorhandenen physischen Block zugreifen kann. Hierzu hat jeder
Block, der auf dem Medium vorhanden ist, eine eindeutige Medienadresse.
Die Gesamtmenge der Blöcke auf einem Medium hängt
von dessen Hardware-Eigenschaften und ggf. von Parametern bei der
Formatierung des Mediums ab.
4.3 Ebene 1: DB-Segmente und DB-Seiten
Aus Sicht der höheren Schichten besteht der auf Ebene 1 realisierte
persistente Speicher aus mehreren Segmenten. Jedes Segment besteht
aus einer Folge von Seiten. Man kann Segmente anlegen und löschen.
c○2013 Udo Kelter Stand: 26.11.2013

Architektur von DBMS 11
Typischerweise wird z.B. beim Erzeugen einer Relation oder eines Index
ein Segment angelegt, das die zugehörigen Daten aufnimmt.
Die Seiten haben eine feste Größe, z.B. 2 kB, diese Größe kann
ggf. beim Anlegen des Segments gewählt werden. Im einfachsten Fall
entspricht eine Seite einem Block, eine Seite kann aber auch mehrere
Blöcke groß sein. Innerhalb eines Segments wird eine Seite durch eine
laufende Nummer identifiziert (Medienadressen sind hier nicht mehr
sichtbar). Segmente können “hinten” seitenweise wachsen oder gekürzt
werden.
Über die Seitenummer zusammen mit dem Segmentidentifizierer
kann direkt auf die Seite zugegriffen werden. Hierzu müssen die Blöcke,
die der Seite entsprechen, vorher geladen, d.h. in den Arbeitsspeicher
übertragen werden.
Ein Segment ähnelt einer Datei, wobei ganze Seiten statt einzelner
Bytes oder Sätze Übertragungseinheiten sind. Im Gegensatz zu
Dateisystemen kann aber die Identifizierung in einem DBMS weitaus
einfacher gestaltet werden, d.h. wir benötigen hier keine Dateiverzeichnisse
oder Zugriffskontrollen.
Zu jedem Segment verwaltet das DBMS einen Segmentdeskriptor,
der alle relevanten Administrationsdaten enthält. Innerhalb derselben
wird vermerkt, wie Seitennummern und Medienadressen einander zugeordnet
sind; diese Zuordnung kann sich dynamisch ändern. Ferner
werden die freien Blöcke auf den Medien verwaltet. Für die höheren
Schichten ist nicht mehr erkennbar, an welcher konkreten Medienadresse
eine Seite steht.
Die vorstehend beschriebene Struktur nennt man auch Zugriffsmethode
für Seiten 2 .
2 In manchen Betriebssystemen wird eine solche Zugriffsmethode direkt für Anwendungen
nutzbar angeboten, in anderen Betriebssystemen existiert sie nur intern,
während auf ihrer Basis für Anwendungen Zugriffsmethoden für Zeichen oder Sätze
angeboten werden.
c○2013 Udo Kelter Stand: 26.11.2013

Architektur von DBMS 12
4.4 Ebene 2: Zugriffsmethode für Sätze
Diese Schicht simuliert sozusagen die Speichereinheit Satz bzw. Zeichen
auf der Speichereinheit Seite. Eine Seite enthält i.a. mehrere
Sätze.
Sätze sind als Speichereinheit in DBMS deutlich wichtiger als Zeichen
(bei Zugriffsmethoden in Betriebssystemen ist es umgekehrt).
Aus Sicht der höheren Schichten besteht ein Segment nunmehr aus
einer Menge von Sätzen bzw. Zeichen und einer Zugriffsstruktur.
4.4.1 Zugriffsstrukturen
Eine Zugriffsstruktur bestimmt, wie einzelne Speichereinheiten identifiziert
und lokalisiert werden können und wie die Menge der Speichereinheiten
des Segments verändert werden kann. Eine Zugriffsstruktur
sollte man als generischen abstrakten Datentyp (ähnlich wie Liste,
Array, Baum, Hash-Tabelle usw.) ansehen. Eine konkrete Zugriffsmethode
ist also ein abstrakter Datentyp, der aus einer generischen Zugriffsstruktur
durch Wahl einer bestimmten Speichereinheit entsteht.
Unter einer Speichereinheit verstehen wir i.f. einen Satz oder ein Zeichen.
Zugriffsstrukturen verstehen wir hier nur als Spezifikationen; für
eine bestimmte Spezifikation kann es unterschiedliche Implementierungen
geben. Die Literatur enthält eine unübersehbare Vielfalt konkreter
Datenstrukturen und Algorithmen, die einzelne Zugriffsstrukturen
implementieren. Aus Platzgründen können wir hier nur Beispiele skizzieren.
Sequentielle Zugriffsstruktur: Diese Zugriffsstruktur entspricht
einer einfach verketteten Liste von Speichereinheiten. Sie ist auch auf
sequentiellen Medien (Bändern, Bandkassetten) realisierbar.
Nur eine einzige Speichereinheit des Segments ist “aktuell lokalisiert”
und damit direkt les- oder schreibbar. Von dort aus kann nur
schrittweise zum nächsten (und ggf. vorigen) Element navigiert werden.
Der (effiziente) Direktzugriff zum n-ten Satz ist nicht möglich.
Nur die erste Speichereinheit kann direkt lokalisiert werden, manchmal
c○2013 Udo Kelter Stand: 26.11.2013

Architektur von DBMS 13
auch das Ende, also die Position hinter der letzten Speichereinheit.
Die Folge der Speichereinheiten kann nur am Ende verlängert oder
gekürzt werden, Einfügen oder Löschen in der Mitte ist nicht möglich.
Die wesentlichen Operationen sind somit:
– beim Schreiben eines Segments:
– Überschreiben der aktuell lokalisierten Speichereinheit
– Anhängen einer Speichereinheit am Ende
– beim Lesen eines Segments:
– Abfrage, ob Segmentende erreicht
– Kopieren der lokalisierten Speichereinheit in einen Puffer
Direktzugriffsstrukturen: Bei Direktzugriffsstrukturen können
einzelne Speichereinheiten durch eine Nummer oder einen Schlüsselwert
identifiziert werden und “direkt”, d.h. für beliebige Sätze in ungefähr
gleicher Zeit, lokalisiert und dann gelesen oder überschrieben
werden, ferner ggf. erzeugt oder gelöscht werden.
Neben dem direkten Zugriff muß natürlich immer auch ein effizienter
sequentieller Zugriff durch alle Sätze möglich sein, bei dem jede
Seite nur einmal übertragen werden muß; hier interessiert, ob hierbei
die Sätze in der Reihenfolge geliefert werden, die der aufsteigenden
Reihenfolge ihrer Schlüsselwerte entspricht.
Es gibt i.w. zwei Formen von Direktzugriffsstrukturen: die arrayartige
Direktzugriffsstruktur und die Verzeichnisstruktur.
Arrayartige Direktzugriffsstruktur: Diese Zugriffsstruktur entspricht
einem hinten dynamisch erweiterbaren Array. Speichereinheiten
werden durch laufende Nummern identifiziert. Es gibt Operationen,
mit denen man die aktuelle Länge des Arrays abfragen und diese
herauf- oder heruntersetzen kann. Nicht möglich ist das Einfügen einer
Speichereinheit zwischen zwei vorhandenen Speichereinheiten. Da
laufende Nummern natürlicherweise sortiert sind, kann man zusätzlich
sehr leicht eine sequentielle Zugriffsstruktur anbieten.
c○2013 Udo Kelter Stand: 26.11.2013

Architektur von DBMS 14
Effizient realisiert werden kann eine arrayartige Direktzugriffsstruktur
in Zugriffsmethoden für Zeichen oder Sätze fester Länge, bei
variabler Satzlänge treten Probleme auf. Zugriffsmethoden für Seiten
realisieren übrigens ebenfalls eine arrayartige Direktzugriffsstruktur.
Verzeichnisstruktur: Diese Zugriffsstruktur tritt nur bei Sätzen
als Speichereinheit auf. Jeder Satz hat hier einen zugeordneten
Schlüsselwert 3 . Die Schlüsselwerte stammen aus einem Schlüsselwertbereich.
Beispiele für Schlüsselwertbereiche sind die ganzen Zahlen
von 0 bis 2 32 -1 oder alle Texte von 8 Zeichen Länge über einem gegebenen
Alphabet. Der Schlüsselwertbereich ist i.a. in der Schnittstelle
und in der Implementierung der Zugriffsmethode “hart verdrahtet”;
die Schlüsselwerte müssen ja in diversen Operationen als Parameter
übergeben werden. Die Verzeichnisstruktur wirkt auf den ersten Blick
sehr ähnlich wie die arrayartige Direktzugriffsstruktur, dieser Eindruck
täuscht aber. Der entscheidende Unterschied besteht darin,
– daß immer der gesamte, sehr große Schlüsselwertbereich verfügbar
ist, es gibt also keine variable Obergrenze für die gültigen Schlüsselwerte,
und
– daß es sein kann, daß zu einem Schlüsselwert aktuell kein Satz
vorhanden ist. I.a. ist sogar nur für einen winzigen Bruchteil der
zulässigen Schlüsselwerte ein Satz vorhanden.
Ein Schlüsselwert identifiziert entweder keinen oder genau einen
Satz in einem Segment. Während bei einer arrayartigen Direktzugriffsstruktur
die Nummern der aktuell vorhandenen Speichereinheiten ein
geschlossenes Intervall bilden, können die Schlüsselwerte der aktuell
vorhandenen Sätze bei einer Verzeichnisstruktur beliebig verstreut im
Schlüsselwertbereich liegen.
Daher kommen für Verzeichnisstrukturen keine Implementierungen
in Frage, bei denen sich der Schlüsselwert implizit durch die Position
des Satzes im Segment ergibt, sondern nur solche Implementierungen,
bei denen der Schlüsselwert jedes Satzes explizit gespeichert wird.
3 Oft wird die Bezeichnung “Schlüssel” als Synonym zu Schlüsselwert benutzt;
dies vermeiden wir hier ganz bewußt.
c○2013 Udo Kelter Stand: 26.11.2013

Architektur von DBMS 15
Binäre Suchbäume und Hash-Tabellen sind bekannte Beispiele für derartige
Datenstrukturen im Hauptspeicher. Von diesen grundlegenden
Datenstrukturen gibt es diverse angepaßte und erweiterte Varianten,
die auf die Besonderheiten einer seitenorientierten Speicherung abgestimmt
sind, z.B. B-Bäume oder B*-Bäume.
Da B-Bäume auch ein effizientes sequentielles Durchlaufen aller
Sätze in aufsteigender Reihenfolge der vorhandenen Schlüsselwerte erlauben,
spricht man hier auch von einer indexsequentiellen Zugriffsmethode
(ISAM; index sequential access method).
Verzeichnisstruktur mit Intervallabfrage: Hier ist im Vergleich
zur normalen Verzeichnisstruktur eine zusätzliche (effizient realisierte)
Operation vorhanden, die alle Speichereinheiten liefert, deren
Schlüsselwert zwischen einer unteren und einer oberen Schranke liegt.
4.4.2 Realisierung von Sätzen auf Seiten
Wir betrachten hier beispielhaft einige einfache Verfahren, wie die sequentielle
Zugriffsstruktur und die arrayartige Direktzugriffsstruktur
auf Seiten effizient realisiert werden können. Die Verzeichnisstruktur
erfordert komplizierte Verfahren, auf die wir hier nicht eingehen.
Die Varianten der Zugriffsmethoden für Sätze unterscheiden sich
darin, ob alle Sätze des Segments gleiche bzw. unterschiedliche Länge
haben. Die zugehörigen Angaben, z.B. die feste Satzlänge oder die
maximale Satzlänge bei variabler Satzlänge, werden innerhalb des Segmentdeskriptors
gespeichert.
Anordnung von Sätzen fester Länge. Bei fester Satzlänge
braucht die Länge eines Satzes nicht bei jedem Satz gespeichert zu
werden. Die Speicherabschnitte für je einen Satz können einfach hintereinandergelegt
werden. Bild 3 zeigt zwei prinzipielle Alternativen:
1. Man bildet gedanklich aus den Inhalten der Seiten einen durchgehenden
Adreßraum und legt die Sätze dicht in diesen Adreßraum (s.
Bild 3 oben). Nachteilig ist hier, daß ein Satz ggf. nicht komplett
in einer Seite liegt und daß, um einen solchen Satz zu lesen oder zu
c○2013 Udo Kelter Stand: 26.11.2013

Architektur von DBMS 16
Seite 1 Seite 2 Seite 3
Satz 1 Satz 2 Satz 3 Satz 4 Satz 5 Satz 6
Seite 1 Seite 2
Seite 3
Satz 1 Satz 2 Satz 3 Satz 4 Satz 5 Satz 6
Abbildung 3: Anordnung von Sätzen fester Länge auf Seiten
schreiben, zwei Blöcke übertragen werden müssen, sofern eine Seite
einem Block entspricht.
2. Man legt nur so viele Sätze in eine Seite, wie ganz hineinpassen.
Nachteil ist hier der ungenutzte Verschnitt am Ende der Seite.
Der Nachteil der doppelten Blockübertragung ist in den meisten
Fällen gravierender als der des Verschnitts.
Satzanordnung bei variabler Satzlänge. Bei allen Zugriffsmethoden
für variable Satzlänge steht man (unabhängig von der Zugriffsstruktur)
vor dem Problem, daß die Länge jedes einzelnen Satzes in
irgendeiner Form erkennbar sein muß. Am einfachsten ist ein Längenfeld
vor dem Satz: Die ersten 2 oder 4 Bytes eines Satzes enthalten
dessen Länge als Binärzahl. Die tatsächliche Länge des Satzes wird
i.d.R. noch auf ein ganzes Vielfaches von 4 oder 8 aufgerundet.
Die Sätze können z.B. analog zu Sätzen fester Länge hintereinander
in der Seite stehen (s. Bild 3 unten).
Bei variabler Satzlänge entsteht prinzipiell das Problem, daß
– der noch freie Platz innerhalb der Seite verwaltet werden muß
– wenn Sätze verlängert oder neu eingefügt werden, eine Seite überlaufen
kann
– wenn Sätze verkürzt oder gelöscht werden, der Füllungsgrad der
Seite schlecht werden kann
c○2013 Udo Kelter Stand: 26.11.2013

Architektur von DBMS 17
– die Zahl der Sätze pro Seite variabel ist und daher die Seite, in der
sich der i-te Satz eines Segments befindet, nicht berechnet werden
kann.
4.4.3 Indexe
Indexe sind generell Datenstrukturen, die einen effizienten Zugriff zu
Daten ermöglichen, die durch einen gegebenen Attributwert identifiziert
werden. Bei manchen Zugriffsmethoden sind Indexe in die
Primärdaten integriert; einen solchen Index bezeichnet man auch als
Primärindex. Primärindexe sind also integraler Bestandteil einer
Zugriffsmethode für Sätze.
Indexe können auch unabhängig von den Primärdaten existieren
und heißen dann Sekundärindex. Ein Sekundärindex ist ein Verzeichnis,
das zu jedem auftretenden Wert eines Attributs eine Liste
von Referenzen auf die Tupel bzw. Objekte, bei denen dieser Attributwert
auftritt, enthält. Während pro Segment nur ein Primärindex
vorhanden sein kann, können beliebig viele Sekundärindexe angelegt
werden.
Naheliegend ist es, für einen Sekundärindex ein eigenes Segment
mit einer Direktzugriffsstruktur anzulegen. Für jeden auftretenden
Attributwert wird ein Satz angelegt,
– dessen Schlüsselwert der Attributwert ist (problematisch können
hier Text-Attribute sein, bei denen die Länge stark variiert) und
– dessen Inhalt die Liste der Referenzen auf die primären Daten ist.
Als Referenzen kommen Primärschlüsselwerte, Surrogate von Objekten
oder sogenannte Tupel-Identifizierer in Frage. Wenn man Sekundärindexe
auf diese Weise realisiert, bauen sie auf Primärindexen
auf, können also als eigene (Zwischen-) Schicht betrachtet werden.
4.5 Ebene 3: Einzelobjekt-Operationen
Diese Ebene exportiert Operationen, die mit einzelnen Tupeln oder
Objekten arbeiten. Ein Tupel oder Objekt wird i.d.R. als Inhalt eines
c○2013 Udo Kelter Stand: 26.11.2013

Architektur von DBMS 18
Satzes gespeichert, die Menge der Tupel einer Relation in den Sätzen
eines Segments.
Die Details (mögliche Attributtypen usw.) hängen vom Datenbankmodell
ab. In navigierenden Datenbankmodellen wird insb. die
Navigation zwischen Objekten auf dieser Ebene realisiert, in relationalen
Systemen die Behandlung von Cursors.
4.6 Ebene 4: Mengen-Schnittstelle
Diese Ebene entfällt weitgehend bei rein navigierenden Datenbankmodellen.
Bei textuellen Schnittstellen muß hier zunächst die textuelle Formulierung
einer Anweisung in eine interne Darstellung übersetzt werden.
Dies beinhaltet diverse Prüfungen, u.a. der Syntax, des Vorhandenseins
von referenzierten Relationen oder Typen, der Zugriffsrechte
usw. Im Erfolgsfall wird danach im Rahmen der Optimierung
ein möglichst effizient ausführbarer Plan erstellt, der den Auftrag
realisiert; entgegen der Bezeichnung “Optimierung” wird allerdings
aus Aufwandsgründen nicht versucht, wirklich einen optimalen
Ausführungsplan zu finden, sondern nur anhand von Heuristiken einen
wahrscheinlich recht guten. Der erstellte Plan wird schließlich ausgeführt.
Nach Abarbeitung müssen die Ergebnisse entweder in geeigneten
Datenstrukturen bereitgestellt werden (bei einem API) oder für
eine externe Darstellung aufbereitet werden.
4.7 Beziehung zur 3-Ebenen-Schema-Architektur
In Abschnitt 5.2 in [DVS] wurde die 3-Ebenen-Schema-Architektur
für DBMS eingeführt. Diese korreliert lose mit der hier in Abschnitt
4 eingeführten Abstraktionshierarchie von Datenbankobjekten.
Bei der Abstraktionshierarchie von Datenbankobjekten hatten wir
unterstellt, daß es sich primär um Nutzdaten handelt. Schemadaten
müssen natürlich auch persistent verwaltet werden, und die Speicherungsoperationen
können hierfür im Prinzip auch ausgenutzt werden
(z.B. auf der Ebene von Speichersätzen); auf dieses Thema wollen wir
aber hier nicht eingehen.
c○2013 Udo Kelter Stand: 26.11.2013

Architektur von DBMS 19
Vereinfachend kann man den Zusammenhang zwischen den Hierarchien
wie folgt ausdrücken:
– Die beiden oberen Schichten der Schema-Architektur (Sichten und
konzeptionelles Schema) beeinflussen die Arbeitsweise der oberen
Schichten der Datenbankobjekt-Hierarchie (1- und n-Tupel-
Schicht).
– Das interne Schema beeinflußt die Arbeitsweise der drei unteren
Schichten der Datenbankobjekt-Hierarchie.
In der 1- bzw. n-Tupel-Schicht finden z.B. Prüfungen statt, ob angegebene
Typnamen (z.B. Attribute oder Relationentypen) bekannt
sind; hierzu werden das externe und das konzeptuelle Schema herangezogen.
Auf der Speichersatzebene muß z.B. eine gewünschte Sortierung
eingehalten werden, und es müssen Indexstrukturen bei Änderungen
an den indexierten Daten gewartet werden.
Literatur
[DVS] Kelter, U.: Lehrmodul “Datenverwaltungssysteme”; 2002
[SAR] Kelter, U.: Lehrmodul “Software-Architekturen”; 2002/10
Glossar
Index: Datenstruktur, die einen effizienten Zugriff zu Speichereinheiten
ermöglicht, die durch einen Attributwert identifiziert werden
Laufzeitkern: Teil eines DVS, das als geladenes Programm die Funktionen
des API ausführt
Primärindex: in die Nutzdaten integrierter Index
Seite (Kontext: interne Architektur eines DBMS-Laufzeitkerns):
Speichereinheit der Seitenebene
Sekundärindex: Verzeichnis, das zu einzelnen Werten eine Liste von Referenzen
auf die Speichereinheiten enthält, in denen dieser Attributwert
auftritt
c○2013 Udo Kelter Stand: 26.11.2013

Architektur von DBMS 20
Speichersatz: Speichereinheit der Speichersatzebene in der internen Architektur
eines DBMS-Laufzeitkerns
Serverprozeß: im Betriebssystem selbständig oder sogar auf einem separaten
Rechner laufender Prozeß, der die Funktionen einer Schicht eines
Informationssystems (z.B. Datenhaltungsschicht) ausführt
Zugriffsmethode (access method): wird in Begriffen wie indexsequentielle
Zugriffsmethode (ISAM; index sequential access method) verwendet;
bezeichnet eine Methode, wie die Speichereinheiten (Sätze bzw. Seiten)
einer bestimmten Ebene intern auf Basis der nächsttieferen Ebene
organisiert werden und wie einzelne Einheiten lokalisiert und bearbeitet
werden können; beinhaltet sowohl die (abstrakten) Schnittstellen
als auch die Hauptmerkmale der Implementierung
Zugriffsstruktur: abstrakte Schnittstelle, über die eine Menge von Speichereinheiten
(i.d.R. Sätze) verwaltet wird
c○2013 Udo Kelter Stand: 26.11.2013

Index
Architektur, 3
Block, 10
Dateimanagementsystem, 10
DBMS
Administration, 3
Laufzeitkern, 3
Hauptspeicher, 10
Index, 17, 19
Längenfeld, 16
Laufzeitkern, 3, 19
Sekundärindex, 17, 19
active ss, 6, 20
Kommunikationsaufwand, 7
Sicherheit, 6
Speichersatz, 9, 19
Zugriffskontrollen, 5
Zugriffsmethode, 11, 12, 20
Zugriffsstruktur, 12, 20
Direktzugriffsstruktur, 13–15
sequentielle, 12, 13
Verzeichnisstruktur, 14
Medienadresse, 10, 11
Mehrbenutzerzugriff, 5
Operationsaufruf
entfernter, 7
Optimierung, 18
Primärindex, 17, 19
active ssarchitektur, 4
active ss, 5
von Informationssystemen, 6
remote procedure call, 6
Satz, 19
feste Länge, 15
Realisierung, 15
variable Länge, 16
Schichtenmodell, 9
Schlüsselwert, 14
Schlüsselwertbereich, 14
Segment, 9
Seite, 9, 12, 15, 19
21