Architektur von DBMS - Praktische...

Architektur von DBMS

Udo Kelter

26.11.2013

Zusammenfassung dieses Lehrmoduls

Dieses Lehrmodul gibt eine erste Einfuhrung in die Architekturvon DBMS. Einleitend betrachten wir ein DBMS aus einer Gesamt-sicht und konzentrieren uns dann auf zwei wichtige Aspekte desDBMS-Kerns: (a) wir zeigen, daß i.d.R. der Datenbankkern als eige-ner Hintergrundprozeß ausgefuhrt werden muß, und wir diskutierendie Konsequenzen hinsichtlich der Performanceoptimierung. (b) Wirskizzieren, in welchen Stufen die Datenobjekte, mit denen das Da-tenbankmodell operiert, auf Datenstrukturen im Hauptspeicher undletztlich auf Magnetplatten oder anderen persistenten Speichermedienabgebildet werden.

Vorausgesetzte Lehrmodule:

obligatorisch: – Datenverwaltungssysteme

empfohlen: – 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 Ubersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84.2 Ebene 0: physische Blocke . . . . . . . . . . . . . . . . . . . . 104.3 Ebene 1: DB-Segmente und DB-Seiten . . . . . . . . . . . . . 104.4 Ebene 2: Zugriffsmethode fur Satze . . . . . . . . . . . . . . . 12

4.4.1 Zugriffsstrukturen . . . . . . . . . . . . . . . . . . . . 124.4.2 Realisierung von Satzen auf Seiten . . . . . . . . . . . 154.4.3 Indexe . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.5 Ebene 3: Einzelobjekt-Operationen . . . . . . . . . . . . . . . 174.6 Ebene 4: Mengen-Schnittstelle . . . . . . . . . . . . . . . . . 184.7 Beziehung zur 3-Ebenen-Schema-Architektur . . . . . . . . . 18

Literatur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Glossar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

c©2013 Udo Kelter Stand: 26.11.2013

Dieser Text darf fur nichtkommerzielle Nutzungen als Ganzes und unverandert in elektronischer odergedruckter Form beliebig weitergegeben werden und in WWW-Seiten, CDs und Datenbanken aufgenom-men werden. Jede andere Nutzung, insb. die Veranderung und Uberfuhrung in andere Formate, bedarfder expliziten Genehmigung. Die jeweils aktuellste Version ist uber http://kltr.de erreichbar.


1 Einleitung

Dieses Lehrmodul gibt einen ersten Einblick in den Aufbau und dieStruktur eines DBMS.

Der Begriff Architektur ist mehrdeutig (eine allgemeinere Diskus-sion dieses Begriffs findet sich in [SAR]); wir werden hier primardie Software-Komponenten betrachten, aus denen ein DBMS besteht.Hierbei kann es sich sowohl um selbstandig lauffahige Programme alsauch um Schichten innerhalb von Programmen, insb. dem Laufzeit-kern, 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 gleichartiganzutreffen ware, noch nicht einmal bei einer vergroberten Betrach-tung. Die Architektur eines DBMS hangt ganz erheblich von mehrerenFaktoren ab:

– naturlich vom Datenbankmodell, hier insb. davon, ob ein navigie-rendes oder ein mengenorientiertes Datenbankmodell vorliegt

– von der Art, wie Applikationen technisch an das DBMS angebundenwerden

– von den ggf. vorhandenen Verteilungskonzepten

– von der “Großenklasse” und damit zusammenhangend den Opti-mierungszielen.

2 Produkt vs. Laufzeitkern

Wenn man ein DBMS-Produkt kauft, wird man auf der Installations-CD eine (erschreckend) hohe Zahl von Programmen finden, die manwie folgt gruppieren kann:

– Laufzeitkern: diese Programme und Programmteile (Bibliotheken)werden wahrend der “produktiven” Nutzung des DBMS ausgefuhrt.

– Administrations- und Dienstprogramme (s. auch Bild 3 in [DVS])fur diverse Zwecke:

– Installation



– Uberwachung des laufenden Betriebs und Gewinnung von stati-stischen Daten

– Performance-Tuning

– Sicherheitsuberwachung

– Backup der Datenbank, Verwaltung von Tertiarspeichermedien,Prufen und ggf. Reparieren der Datenbank

– Benutzeradministration

– Verwaltung registrierter Anwendungen

– Accounting

– Programme, die das Entwickeln von Applikationen unterstutzen;man kann diese als eine angepaßte Software-Entwicklungsumge-bung ansehen. Beispiele sind Praprozessoren, die in Quelltexteeingebettete Anweisungen vorubersetzen, oder Editoren, mit denenman die Datenbankschemata spezifizieren kann.

Die Abgrenzung zwischen den Dienstprogrammen und den Ent-wicklungswerkzeugen ist nicht ganz scharf. Wenn separate Entwick-lungs- und “Produktions”rechner benutzt werden, sind die Entwick-lungswerkzeuge typischerweise nur auf dem Entwicklungsrechner in-stalliert.

Dienstprogramme und Entwicklungswerkzeuge sind zwar fur diepraktische Nutzung von DBMS sehr wichtig, auf sie wird aber in Vor-lesungen und Lehrbuchern uber Datenbanken fast nicht eingegangen– so auch hier. Allgemeine Kenntnisse uber Datenmodelle und Kennt-nisse uber die Laufzeitkerne haben insofern hohere Prioritat, als siebei der Behandlung der Dienstprogramme und Entwicklungswerkzeu-ge stets vorausgesetzt werden mussen.

3 Prozeßarchitektur von Informationssyste-

men

Informationssysteme kann man i.d.R. in 3 Softwareschichten struktu-rieren (s. Bild 1 in [DVS]):



– GUI / Benutzerinteraktion– Realisierung der Fachkonzepte, Applikationssemantik– Datenverwaltung

Im einfachsten Fall kann man die zugehorigen Module zu einemeinzigen Programm zusammenbinden, d.h. diese Module wurden inden virtuellen Hauptspeicher eines Betriebssystemprozesses geladenund dort gemeinsam ausgefuhrt. Hinsichtlich der Ziele, die durch denEinsatz von DBMS angestrebt werden, hatte eine solche 1-Prozeß-Architektur aber gravierende Nachteile:

– Das DBMS kann aus Performancegrunden nicht nur auf den persi-stenten Medien (also Platten) arbeiten, sondern muß große Teile derDatenbank in Puffer in den Hauptspeicher laden und primar auf die-sen Pufferinhalten arbeiten. Nun war es ein Ziel von DBMS, vielenBenutzern und Applikationen gleichzeitig Zugriff auf die Datenbankzu ermoglichen. Dies wurde bei einer 1-Prozeß-Architektur bedeu-ten, daß jede Applikation eigene Puffer hatte und daß dort Teile derDatenbank lagen, die ggf. schon gegenuber dem Zustand auf derPlatte verandert worden sind. Wollte eine andere Applikation jetztauf diese Teile der Datenbank zugreifen, mußte sie herausfinden, obeine und ggf. welche andere Applikation diese Teile der Datenbankgerade puffert und sich an diese Applikation wenden. Jedes Appli-kationsprogramm mußte also gleichzeitig als Server fur die zufalliggerade in seinen Puffern befindlichen Teile der Datenbank arbeiten.Dies ist vollig inpraktikabel.

– Ein weiteres Ziel von DBMS bestand darin, Zugriffskontrollen zurealisieren, d.h. nicht autorisierten Benutzern den Zugang auf be-stimmte Daten zu verwehren. Bei einer 1-Prozeß-Architektur kon-nen solche Dienste aber nicht sicher implementiert werden (zumin-dest bei allgemein verfugbaren Programmiersprachen und Betriebs-systemen). In fast allen gangigen hoheren Programmiersprachenund erst recht in maschinennahen Sprachen konnen Zeiger mani-puliert 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



zugreifen und dort Daten auslesen und verandern konnte, d.h. dieZugriffskontrollmechanismen sind umgehbar.

– Unkontrollierte Zugriffe des Applikationsprogramms konnten dar-uber hinaus interne Datenstrukturen des DBMS zerstoren und sozu Programmabsturzen fuhren.

Die einzige praktikable Alternative, das DBMS und die Daten-bankpuffer vor direkten Zugriffen durch die Applikation zu schutzen,besteht darin, diese Programme bzw. Daten in einen separaten Be-triebssystemprozeß zu laden, s. Bild 1. Aus der Sicht von Applikatio-nen ist diese Verlagerung des DBMS-Laufzeitkerns in einen anderenProzeß i.w. nicht sichtbar, denn das API zum DBMS bleibt volligunverandert. “Hinter dem API” liegt aber jetzt keine Implementie-rung mehr, sondern eine Bibliothek oder ein RPC- (remote procedurecall) Mechanismus, der die Operationsaufrufe i.w. unverarbeitet anden Serverprozeß sendet, welcher die eigentliche Operation ausfuhrtund die Ergebnisse zurucksendet.

[G]UI der

Applikation Server

Applikations-

Server

DBMS-

BibliothekBibliothek Datenbank

Appl-API DBMS-API

Abbildung 1: Prozeßarchitektur von Informationssystemen

Aus Performance-Grunden kann es sinnvoll sein, auch das GUI unddie Applikationssemantik verschiedenen Prozessen zuzuordnen; es er-gibt sich dann die in Bild 1 gezeigte Struktur mit 3 Prozessen.

Fur die technische Realisierung eines solchen entfernten Opera-tionsaufrufs gibt es diverse Alternativen, die nicht hier, sondern im



Rahmen von Vorlesungen uber Rechnernetze behandelt werden. DieMerkmale dieser Mechanismen sind fur unsere Diskussion weitgehendirrelevant bis auf die beiden folgenden Punkte:

– Wenn ein Applikationsprogramm gestartet wird, muß es herausfin-den konnen, ob schon ein Serverprozeß fur die Datenbank lauft undwie es Kontakt zu diesem Serverprozeß aufnehmen kann. Hierzumussen Hilfssysteme verfugbar sein, die entsprechende Auskunftegeben konnen und den Verbindungsaufbau teilweise automatisie-ren. Die Struktur dieser Hilfssysteme hangt stark von der Kom-munikationstechnologie ab, die eingesetzt wird. Insgesamt ist dieInstallation und Benutzung eines DBMS im Vergleich zu Dateiendadurch wesentlich komplizierter und erfordert Kenntnisse in dergewahlten Kommunikationstechnologie.

– Ein entfernter Operationsaufruf ist deutlich ineffizienter als ein lo-kaler. Ein lokaler Operationsaufruf innerhalb eines Programms ver-ursacht einen Aufwand, der je nach Umfang der Parameter in derGroßenordnung von einigen Dutzend oder hundert Maschinenin-struktionen, bei heutigen Prozessoren also in der Großenordnungvon Mikrosekunden liegt. Bei einem entfernten Operationsaufrufsind zwei Falle zu unterscheiden:

1. Der Serverprozeß lauft auf dem gleichen Rechner: in diesemFall werden zuerst die Parameter geeignet codiert, der aufru-fende Prozeß wird stillgelegt, der wartende Serverprozeß wirdaktiviert, er entpackt die Parameter und fuhrt die gewunsch-te Operation aus. Nach Beendigung der Operationsausfuhrungwerden umgekehrt die Ergebnisse an den aufrufenden Prozeßzurucktransferiert. Die beiden Prozeßwechsel und die beidenDatenubertragungen kosten typischerweise Rechenzeit in derGroßenordnung von 0.1 Millisekunden.

2. Der Serverprozeß lauft auf einem anderen Rechner. In diesemFall kommt bei beiden Kommunikationen der Kommunikations-aufwand hinzu; hier muß mit einem Mindestaufwand in derGroßenordnung von 1 Millisekunde (bei langsamen Netzen auchmehr) gerechnet werden, ferner ist die Ubertragungsbandbreite



signifikant kleiner.

Hieraus folgt bereits, daß ein entfernter Aufruf bedeutend teu-rer (Faktor: ca. 1000 bis 10000) ist als ein lokaler und daß mansich in interaktiven Systemen, die gute Antwortzeiten haben sol-len, nur wenige (Großenordnung 10 bis 100) Datenbankzugriffe proInteraktion leisten kann.

Sofern die Menge der als Eingabeparameter oder Ruckgabewerteubertragenen Daten in der Großenordnung von einigen kB liegt, hatsie auf diese Zeiten praktisch keinen Einfluß, erst bei deutlich große-ren Datenmengen oder sehr langsamen Netzwerken beeinflußt siedie Gesamtzeit proportional zum Ubertragungsvolumen. Hierausfolgt als weitere Erkenntnis, daß es performanter ist, wenige um-fangreichere Operationen aufzurufen als viele kleine.

4 Eine Abstraktionshierarchie von Daten-

bankobjekten

4.1 Ubersicht

Jedes DBMS muß letztlich die Datenstrukturen seines Datenbankmo-dells auf Basis des unterliegenden Dateisystems oder, bei direktem Zu-griff auf die Hardware, der Platten realisieren. Die Diskrepanz dieserbeiden Denkwelten ist erheblich, daher wird diese Realisierung typi-scherweise in mehrere Schritte eingeteilt, bei denen - von unten nachoben gesehen - jeweils ein neuer Typ von internen Speichereinheitenrealisiert wird. Man kann sich diese Schichtung durch mehrere aufein-ander aufbauende Pakete veranschaulichen (s. Bild 2)1. Wir skizziereni.f. ein derartiges Schichtenmodell fur interne Speichereinheiten bzw.Datenbankobjekte und gehen anschließend im Detail auf die Schichtenein:

– Die unterste Ebene operiert mit Blocken, die uber Medienadressen

1Reale DBMS-Kerne sind deutlich komplizierter, insofern ist dieses Bild keine

exakte, sondern allenfalls eine partielle und vereinfachende Darstellung der Archi-

tektur eines DBMS-Kerns.



Ebene 0: physische Blöcke

Ebene 1: Segmente/Seiten

Ebene 2: Speichersätze

Ebene 3: 1-Tupel/Objekt

Ebene 4: n-Tupel/Objekte

Abbildung 2: Vereinfachte Schichtenarchitektur eines Laufzeitkernsund resultierende Abstraktionshierarchie von Datenbankobjekten

identifiziert werden und die zwischen den persistente Medien unddem Arbeitsspeicher ubertragen werden.

– Auf Ebene 1 wird die durch die Hardware vorgegebene Menge derBlocke zu Segmenten gruppiert. Segmente ahneln insofern Dateien,als sie angelegt und geloscht werden konnen und ihre Große (al-so die Menge der zugeordneten Blocke) wachsen oder schrumpfenkann.

– In Ebene 2 wird der Inhalt einzelner Segmente, der sich auf Ebe-ne 1 noch als Folge von Seiten darstellt, feinkorniger strukturiert,typischerweise als Folge oder Verzeichnis von (Speicher-) Satzen.Integriert hierin sind (primare) Indexe, z.B. B*-Baume.

– In Ebene 3 wird der Inhalt einzelner Satze, der sich auf Ebene 2noch als unstrukturiertes Bytefeld darstellt, in Felder strukturiert,die den Attributen von Tupeln oder Objekten entsprechen. Aufdieser Ebene werden die konzeptuellen Schemata in konkrete Spei-cherstrukturen umgesetzt.

– Wahrend Ebene 3 Operationen realisiert, die mit einzelnen Tupelnoder Objekten arbeiten, realisiert Ebene 4 Operationen mit Men-



gen von Objekten. Dieser Ebene ist u.a. der Problemkomplex derOptimierung zuzuordnen.

Wir betrachten i.f. die Ebenen detaillierter und beginnen bei derHardware als unterster Ebene.

4.2 Ebene 0: physische Blocke

Ein physischer Block ist ein Datenbereich auf einem Permanentspei-cher wie Magnetplatte, optische Platte, Band usw., dessen (Netto-)Inhalt von der Hardware und den zugehorigen Treibern zwischen demSpeichermedium und dem Hauptspeicher transportiert werden kann.Normalerweise werden physische Blocke nur durch das Dateimanage-mentsystem des Betriebssystems verwaltet, d.h. Anwendungsprogram-me konnen uberhaupt nicht direkt damit arbeiten, sondern arbeitennur mit Dateien, die bereits eine eigene Abstraktionsschicht oberhalbder physischen Blocke darstellen. Die von Betriebssystemen realisier-ten Dateisysteme sind allerdings nicht optimal angepaßt an den Bedarfvon DBMS, daher umgehen manche DBMS das Betriebssystem undgreifen “direkt” auf die Platte zu.

Fur uns sind nur zwei Operationen mit physischen Blocken rele-vant, namlich der Transport vom Medium in einen Hauptspeicherbe-reich und umgekehrt. Fur die Speicherung einer Datenbank eignensich nur solche Medien, bei denen man direkt, also schnell, auf je-den vorhandenen physischen Block zugreifen kann. Hierzu hat jederBlock, der auf dem Medium vorhanden ist, eine eindeutige Medie-

nadresse. Die Gesamtmenge der Blocke auf einem Medium hangtvon dessen Hardware-Eigenschaften und ggf. von Parametern bei derFormatierung des Mediums ab.

4.3 Ebene 1: DB-Segmente und DB-Seiten

Aus Sicht der hoheren Schichten besteht der auf Ebene 1 realisiertepersistente Speicher aus mehreren Segmenten. Jedes Segment bestehtaus einer Folge von Seiten. Man kann Segmente anlegen und loschen.



Typischerweise wird z.B. beim Erzeugen einer Relation oder eines In-dex ein Segment angelegt, das die zugehorigen Daten aufnimmt.

Die Seiten haben eine feste Große, z.B. 2 kB, diese Große kannggf. beim Anlegen des Segments gewahlt werden. Im einfachsten Fallentspricht eine Seite einem Block, eine Seite kann aber auch mehrereBlocke groß sein. Innerhalb eines Segments wird eine Seite durch einelaufende Nummer identifiziert (Medienadressen sind hier nicht mehrsichtbar). Segmente konnen “hinten” seitenweise wachsen oder gekurztwerden.

Uber die Seitenummer zusammen mit dem Segmentidentifiziererkann direkt auf die Seite zugegriffen werden. Hierzu mussen die Blocke,die der Seite entsprechen, vorher geladen, d.h. in den Arbeitsspeicherubertragen werden.

Ein Segment ahnelt einer Datei, wobei ganze Seiten statt einzel-ner Bytes oder Satze Ubertragungseinheiten sind. Im Gegensatz zuDateisystemen kann aber die Identifizierung in einem DBMS weitauseinfacher gestaltet werden, d.h. wir benotigen hier keine Dateiverzeich-nisse oder Zugriffskontrollen.

Zu jedem Segment verwaltet das DBMS einen Segmentdeskriptor,der alle relevanten Administrationsdaten enthalt. Innerhalb derselbenwird vermerkt, wie Seitennummern und Medienadressen einander zu-geordnet sind; diese Zuordnung kann sich dynamisch andern. Fernerwerden die freien Blocke auf den Medien verwaltet. Fur die hoherenSchichten ist nicht mehr erkennbar, an welcher konkreten Medienadres-se eine Seite steht.

Die vorstehend beschriebene Struktur nennt man auch Zugriffs-

methode fur Seiten2.

2In manchen Betriebssystemen wird eine solche Zugriffsmethode direkt fur An-

wendungen nutzbar angeboten, in anderen Betriebssystemen existiert sie nur intern,

wahrend auf ihrer Basis fur Anwendungen Zugriffsmethoden fur Zeichen oder Satze

angeboten werden.



4.4 Ebene 2: Zugriffsmethode fur Satze

Diese Schicht simuliert sozusagen die Speichereinheit Satz bzw. Zei-chen auf der Speichereinheit Seite. Eine Seite enthalt i.a. mehrereSatze.

Satze sind als Speichereinheit in DBMS deutlich wichtiger als Zei-chen (bei Zugriffsmethoden in Betriebssystemen ist es umgekehrt).Aus Sicht der hoheren Schichten besteht ein Segment nunmehr auseiner Menge von Satzen bzw. Zeichen und einer Zugriffsstruktur.

4.4.1 Zugriffsstrukturen

Eine Zugriffsstruktur bestimmt, wie einzelne Speichereinheiten iden-tifiziert und lokalisiert werden konnen und wie die Menge der Speicher-einheiten des Segments verandert werden kann. Eine Zugriffsstruktursollte man als generischen abstrakten Datentyp (ahnlich wie Liste,Array, Baum, Hash-Tabelle usw.) ansehen. Eine konkrete Zugriffsme-thode ist also ein abstrakter Datentyp, der aus einer generischen Zu-griffsstruktur durch Wahl einer bestimmten Speichereinheit entsteht.Unter einer Speichereinheit verstehen wir i.f. einen Satz oder ein Zei-chen.

Zugriffsstrukturen verstehen wir hier nur als Spezifikationen; fureine bestimmte Spezifikation kann es unterschiedliche Implementierun-gen geben. Die Literatur enthalt eine unubersehbare Vielfalt konkre-ter Datenstrukturen und Algorithmen, die einzelne Zugriffsstrukturenimplementieren. Aus Platzgrunden konnen wir hier nur Beispiele skiz-zieren.

Sequentielle Zugriffsstruktur: Diese Zugriffsstruktur entsprichteiner einfach verketteten Liste von Speichereinheiten. Sie ist auch aufsequentiellen Medien (Bandern, Bandkassetten) realisierbar.

Nur eine einzige Speichereinheit des Segments ist “aktuell lokali-siert” und damit direkt les- oder schreibbar. Von dort aus kann nurschrittweise zum nachsten (und ggf. vorigen) Element navigiert wer-den. Der (effiziente) Direktzugriff zum n-ten Satz ist nicht moglich.Nur die erste Speichereinheit kann direkt lokalisiert werden, manchmal



auch das Ende, also die Position hinter der letzten Speichereinheit.Die Folge der Speichereinheiten kann nur am Ende verlangert oder

gekurzt werden, Einfugen oder Loschen in der Mitte ist nicht moglich.Die wesentlichen Operationen sind somit:

– beim Schreiben eines Segments:

– Uberschreiben der aktuell lokalisierten Speichereinheit– Anhangen einer Speichereinheit am Ende

– beim Lesen eines Segments:

– Abfrage, ob Segmentende erreicht

– Kopieren der lokalisierten Speichereinheit in einen Puffer

Direktzugriffsstrukturen: Bei Direktzugriffsstrukturen konneneinzelne Speichereinheiten durch eine Nummer oder einen Schlussel-wert identifiziert werden und “direkt”, d.h. fur beliebige Satze in un-gefahr gleicher Zeit, lokalisiert und dann gelesen oder uberschriebenwerden, ferner ggf. erzeugt oder geloscht werden.

Neben dem direkten Zugriff muß naturlich immer auch ein effizi-enter sequentieller Zugriff durch alle Satze moglich sein, bei dem jedeSeite nur einmal ubertragen werden muß; hier interessiert, ob hierbeidie Satze in der Reihenfolge geliefert werden, die der aufsteigendenReihenfolge ihrer Schlusselwerte entspricht.

Es gibt i.w. zwei Formen von Direktzugriffsstrukturen: die array-artige Direktzugriffsstruktur und die Verzeichnisstruktur.

Arrayartige Direktzugriffsstruktur: Diese Zugriffsstruktur ent-spricht einem hinten dynamisch erweiterbaren Array. Speichereinhei-ten werden durch laufende Nummern identifiziert. Es gibt Operatio-nen, mit denen man die aktuelle Lange des Arrays abfragen und dieseherauf- oder heruntersetzen kann. Nicht moglich ist das Einfugen ei-ner Speichereinheit zwischen zwei vorhandenen Speichereinheiten. Dalaufende Nummern naturlicherweise sortiert sind, kann man zusatzlichsehr leicht eine sequentielle Zugriffsstruktur anbieten.



Effizient realisiert werden kann eine arrayartige Direktzugriffs-struktur in Zugriffsmethoden fur Zeichen oder Satze fester Lange, beivariabler Satzlange treten Probleme auf. Zugriffsmethoden fur Seitenrealisieren ubrigens ebenfalls eine arrayartige Direktzugriffsstruktur.

Verzeichnisstruktur: Diese Zugriffsstruktur tritt nur bei Satzenals Speichereinheit auf. Jeder Satz hat hier einen zugeordnetenSchlusselwert3. Die Schlusselwerte stammen aus einem Schlussel-

wertbereich. Beispiele fur Schlusselwertbereiche sind die ganzen Zah-len von 0 bis 232-1 oder alle Texte von 8 Zeichen Lange uber einem ge-gebenen Alphabet. Der Schlusselwertbereich ist i.a. in der Schnittstel-le und in der Implementierung der Zugriffsmethode “hart verdrahtet”;die Schlusselwerte mussen ja in diversen Operationen als Parameterubergeben werden. Die Verzeichnisstruktur wirkt auf den ersten Blicksehr ahnlich wie die arrayartige Direktzugriffsstruktur, dieser Eindrucktauscht aber. Der entscheidende Unterschied besteht darin,

– daß immer der gesamte, sehr große Schlusselwertbereich verfugbarist, es gibt also keine variable Obergrenze fur die gultigen Schlussel-werte, und

– daß es sein kann, daß zu einem Schlusselwert aktuell kein Satzvorhanden ist. I.a. ist sogar nur fur einen winzigen Bruchteil derzulassigen Schlusselwerte ein Satz vorhanden.

Ein Schlusselwert identifiziert entweder keinen oder genau einenSatz in einem Segment. Wahrend bei einer arrayartigen Direktzugriffs-struktur die Nummern der aktuell vorhandenen Speichereinheiten eingeschlossenes Intervall bilden, konnen die Schlusselwerte der aktuellvorhandenen Satze bei einer Verzeichnisstruktur beliebig verstreut imSchlusselwertbereich liegen.

Daher kommen fur Verzeichnisstrukturen keine Implementierungenin Frage, bei denen sich der Schlusselwert implizit durch die Positiondes Satzes im Segment ergibt, sondern nur solche Implementierun-gen, bei denen der Schlusselwert jedes Satzes explizit gespeichert wird.

3Oft wird die Bezeichnung “Schlussel” als Synonym zu Schlusselwert benutzt;

dies vermeiden wir hier ganz bewußt.



Binare Suchbaume und Hash-Tabellen sind bekannte Beispiele fur der-artige Datenstrukturen im Hauptspeicher. Von diesen grundlegendenDatenstrukturen gibt es diverse angepaßte und erweiterte Varianten,die auf die Besonderheiten einer seitenorientierten Speicherung abge-stimmt sind, z.B. B-Baume oder B*-Baume.

Da B-Baume auch ein effizientes sequentielles Durchlaufen allerSatze in aufsteigender Reihenfolge der vorhandenen Schlusselwerte er-lauben, spricht man hier auch von einer indexsequentiellen Zugriffs-methode (ISAM; index sequential access method).

Verzeichnisstruktur mit Intervallabfrage: Hier ist im Vergleichzur normalen Verzeichnisstruktur eine zusatzliche (effizient realisier-te) Operation vorhanden, die alle Speichereinheiten liefert, derenSchlusselwert zwischen einer unteren und einer oberen Schranke liegt.

4.4.2 Realisierung von Satzen auf Seiten

Wir betrachten hier beispielhaft einige einfache Verfahren, wie die se-quentielle Zugriffsstruktur und die arrayartige Direktzugriffsstrukturauf Seiten effizient realisiert werden konnen. Die Verzeichnisstrukturerfordert komplizierte Verfahren, auf die wir hier nicht eingehen.

Die Varianten der Zugriffsmethoden fur Satze unterscheiden sichdarin, ob alle Satze des Segments gleiche bzw. unterschiedliche Langehaben. Die zugehorigen Angaben, z.B. die feste Satzlange oder diemaximale Satzlange bei variabler Satzlange, werden innerhalb des Seg-mentdeskriptors gespeichert.

Anordnung von Satzen fester Lange. Bei fester Satzlangebraucht die Lange eines Satzes nicht bei jedem Satz gespeichert zuwerden. Die Speicherabschnitte fur je einen Satz konnen einfach hin-tereinandergelegt werden. Bild 3 zeigt zwei prinzipielle Alternativen:

1. Man bildet gedanklich aus den Inhalten der Seiten einen durchge-henden Adreßraum und legt die Satze dicht in diesen Adreßraum (s.Bild 3 oben). Nachteilig ist hier, daß ein Satz ggf. nicht komplettin einer Seite liegt und daß, um einen solchen Satz zu lesen oder zu



Seite 1 Seite 3

Seite 1 Seite 2 Seite 3

Seite 2

Satz 1 Satz 2 Satz 3 Satz 5 Satz 6Satz 4

Satz 6Satz 5Satz 4Satz 3Satz 2Satz 1

Abbildung 3: Anordnung von Satzen fester Lange auf Seiten

schreiben, zwei Blocke ubertragen werden mussen, sofern eine Seiteeinem Block entspricht.

2. Man legt nur so viele Satze in eine Seite, wie ganz hineinpassen.Nachteil ist hier der ungenutzte Verschnitt am Ende der Seite.

Der Nachteil der doppelten Blockubertragung ist in den meistenFallen gravierender als der des Verschnitts.

Satzanordnung bei variabler Satzlange. Bei allen Zugriffsme-thoden fur variable Satzlange steht man (unabhangig von der Zugriffs-struktur) vor dem Problem, daß die Lange jedes einzelnen Satzes inirgendeiner Form erkennbar sein muß. Am einfachsten ist ein Langen-

feld vor dem Satz: Die ersten 2 oder 4 Bytes eines Satzes enthaltendessen Lange als Binarzahl. Die tatsachliche Lange des Satzes wirdi.d.R. noch auf ein ganzes Vielfaches von 4 oder 8 aufgerundet.

Die Satze konnen z.B. analog zu Satzen fester Lange hintereinanderin der Seite stehen (s. Bild 3 unten).

Bei variabler Satzlange entsteht prinzipiell das Problem, daß

– der noch freie Platz innerhalb der Seite verwaltet werden muß– wenn Satze verlangert oder neu eingefugt werden, eine Seite uber-

laufen kann

– wenn Satze verkurzt oder geloscht werden, der Fullungsgrad derSeite schlecht werden kann



– die Zahl der Satze pro Seite variabel ist und daher die Seite, in dersich der i-te Satz eines Segments befindet, nicht berechnet werdenkann.

4.4.3 Indexe

Indexe sind generell Datenstrukturen, die einen effizienten Zugriff zuDaten ermoglichen, die durch einen gegebenen Attributwert identi-fiziert werden. Bei manchen Zugriffsmethoden sind Indexe in diePrimardaten integriert; einen solchen Index bezeichnet man auch alsPrimarindex. Primarindexe sind also integraler Bestandteil einerZugriffsmethode fur Satze.

Indexe konnen auch unabhangig von den Primardaten existierenund heißen dann Sekundarindex. Ein Sekundarindex ist ein Ver-zeichnis, das zu jedem auftretenden Wert eines Attributs eine Listevon Referenzen auf die Tupel bzw. Objekte, bei denen dieser Attri-butwert auftritt, enthalt. Wahrend pro Segment nur ein Primarindexvorhanden sein kann, konnen beliebig viele Sekundarindexe angelegtwerden.

Naheliegend ist es, fur einen Sekundarindex ein eigenes Segmentmit einer Direktzugriffsstruktur anzulegen. Fur jeden auftretendenAttributwert wird ein Satz angelegt,

– dessen Schlusselwert der Attributwert ist (problematisch konnenhier Text-Attribute sein, bei denen die Lange stark variiert) und

– dessen Inhalt die Liste der Referenzen auf die primaren Daten ist.

Als Referenzen kommen Primarschlusselwerte, Surrogate von Objek-ten oder sogenannte Tupel-Identifizierer in Frage. Wenn man Se-kundarindexe auf diese Weise realisiert, bauen sie auf Primarindexenauf, konnen also als eigene (Zwischen-) Schicht betrachtet werden.

4.5 Ebene 3: Einzelobjekt-Operationen

Diese Ebene exportiert Operationen, die mit einzelnen Tupeln oderObjekten arbeiten. Ein Tupel oder Objekt wird i.d.R. als Inhalt eines



Satzes gespeichert, die Menge der Tupel einer Relation in den Satzeneines Segments.

Die Details (mogliche Attributtypen usw.) hangen vom Daten-bankmodell ab. In navigierenden Datenbankmodellen wird insb. dieNavigation zwischen Objekten auf dieser Ebene realisiert, in relatio-nalen Systemen die Behandlung von Cursors.

4.6 Ebene 4: Mengen-Schnittstelle

Diese Ebene entfallt weitgehend bei rein navigierenden Datenbankmo-dellen.

Bei textuellen Schnittstellen muß hier zunachst die textuelle For-mulierung einer Anweisung in eine interne Darstellung ubersetzt wer-den. Dies beinhaltet diverse Prufungen, u.a. der Syntax, des Vor-handenseins von referenzierten Relationen oder Typen, der Zugriffs-rechte usw. Im Erfolgsfall wird danach im Rahmen der Optimie-rung ein moglichst effizient ausfuhrbarer Plan erstellt, der den Auf-trag realisiert; entgegen der Bezeichnung “Optimierung” wird aller-dings aus Aufwandsgrunden nicht versucht, wirklich einen optimalenAusfuhrungsplan zu finden, sondern nur anhand von Heuristiken einenwahrscheinlich recht guten. Der erstellte Plan wird schließlich aus-gefuhrt. Nach Abarbeitung mussen die Ergebnisse entweder in geeig-neten Datenstrukturen bereitgestellt werden (bei einem API) oder fureine externe Darstellung aufbereitet werden.

4.7 Beziehung zur 3-Ebenen-Schema-Architektur

In Abschnitt 5.2 in [DVS] wurde die 3-Ebenen-Schema-Architekturfur DBMS eingefuhrt. Diese korreliert lose mit der hier in Abschnitt4 eingefuhrten Abstraktionshierarchie von Datenbankobjekten.

Bei der Abstraktionshierarchie von Datenbankobjekten hatten wirunterstellt, daß es sich primar um Nutzdaten handelt. Schemadatenmussen naturlich auch persistent verwaltet werden, und die Speiche-rungsoperationen konnen hierfur im Prinzip auch ausgenutzt werden(z.B. auf der Ebene von Speichersatzen); auf dieses Thema wollen wiraber hier nicht eingehen.



Vereinfachend kann man den Zusammenhang zwischen den Hier-archien wie folgt ausdrucken:

– Die beiden oberen Schichten der Schema-Architektur (Sichten undkonzeptionelles Schema) beeinflussen die Arbeitsweise der obe-ren Schichten der Datenbankobjekt-Hierarchie (1- und n-Tupel-Schicht).

– Das interne Schema beeinflußt die Arbeitsweise der drei unterenSchichten der Datenbankobjekt-Hierarchie.

In der 1- bzw. n-Tupel-Schicht finden z.B. Prufungen statt, ob an-gegebene Typnamen (z.B. Attribute oder Relationentypen) bekanntsind; hierzu werden das externe und das konzeptuelle Schema herange-zogen. Auf der Speichersatzebene muß z.B. eine gewunschte Sortierungeingehalten werden, und es mussen Indexstrukturen bei Anderungenan 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 Speichereinheitenermoglicht, die durch einen Attributwert identifiziert werden

Laufzeitkern: Teil eines DVS, das als geladenes Programm die Funktionendes API ausfuhrt

Primarindex: in die Nutzdaten integrierter Index

Seite (Kontext: interne Architektur eines DBMS-Laufzeitkerns):Speichereinheit der Seitenebene

Sekundarindex: Verzeichnis, das zu einzelnen Werten eine Liste von Refe-renzen auf die Speichereinheiten enthalt, in denen dieser Attributwertauftritt



Speichersatz: Speichereinheit der Speichersatzebene in der internen Archi-tektur eines DBMS-Laufzeitkerns

Serverprozeß: im Betriebssystem selbstandig oder sogar auf einem separa-ten Rechner laufender Prozeß, der die Funktionen einer Schicht einesInformationssystems (z.B. Datenhaltungsschicht) ausfuhrt

Zugriffsmethode (access method): wird in Begriffen wie indexsequentielleZugriffsmethode (ISAM; index sequential access method) verwendet;bezeichnet eine Methode, wie die Speichereinheiten (Satze bzw. Sei-ten) einer bestimmten Ebene intern auf Basis der nachsttieferen Ebeneorganisiert werden und wie einzelne Einheiten lokalisiert und bearbei-tet werden konnen; beinhaltet sowohl die (abstrakten) Schnittstellenals auch die Hauptmerkmale der Implementierung

Zugriffsstruktur: abstrakte Schnittstelle, uber die eine Menge von Spei-chereinheiten (i.d.R. Satze) verwaltet wird


Index

Architektur, 3

Block, 10

Dateimanagementsystem, 10DBMS

Administration, 3Laufzeitkern, 3

Hauptspeicher, 10

Index, 17, 19

Langenfeld, 16Laufzeitkern, 3, 19

Medienadresse, 10, 11Mehrbenutzerzugriff, 5

Operationsaufrufentfernter, 7

Optimierung, 18

Primarindex, 17, 19active ssarchitektur, 4

active ss, 5von Informationssystemen, 6

remote procedure call, 6

Satz, 19feste Lange, 15Realisierung, 15variable Lange, 16

Schichtenmodell, 9Schlusselwert, 14Schlusselwertbereich, 14Segment, 9Seite, 9, 12, 15, 19

Sekundarindex, 17, 19active ss, 6, 20

Kommunikationsaufwand, 7Sicherheit, 6Speichersatz, 9, 19

Zugriffskontrollen, 5Zugriffsmethode, 11, 12, 20Zugriffsstruktur, 12, 20

Direktzugriffsstruktur, 13–15sequentielle, 12, 13Verzeichnisstruktur, 14

21

Architektur von DBMS - Praktische...

Documents

Transcript of Architektur von DBMS - Praktische...