598 lines
19 KiB
Plaintext
598 lines
19 KiB
Plaintext
.ds LH Anwendung
|
|
.ds RH \f3ZUGRIFF\f1
|
|
.ds CH - % -
|
|
.bp
|
|
.NH 2
|
|
.ft B
|
|
Zugriffsmethoden und **
|
|
.br
|
|
Datenlokalisierung
|
|
.ft R
|
|
.LP
|
|
.sp 10
|
|
.NH 3
|
|
.ft B
|
|
Einleitung
|
|
.ft R
|
|
.LP
|
|
\*(yy\ unterst\o'u"'tzt mehrere Zugriffsmethoden,
|
|
deren sinnvoller Einsatz dem Projektanten
|
|
und dem Datenbankadministrator \o'u"'berlassen wird
|
|
und die Zuordnung von Datenbanken
|
|
und Relationen in eine hierarchische \*(xx\-File-Struktur.
|
|
.LP
|
|
Diese Kapitel beschreibt die Funktionsweise
|
|
der Zugriffsmethoden und gibt damit ,weiterf\o'u"'hrend
|
|
zum vorangegangenen, eine
|
|
Anleitung zu ihrem effektiven problembezogenem Einsatz.
|
|
Ausserdem werden die Teile des \*(yy\-Filesystems
|
|
beschrieben, die den anwendungsbezogenen Aufbau
|
|
mountbarer Filesysteme erm\o'o"'glichen.
|
|
.NH 3
|
|
.ft B
|
|
Grundkonzepte von \*(yy
|
|
.ft R
|
|
.NH 4
|
|
.ft B
|
|
Seitenkonzept und Tupeldarstellung
|
|
.ft R
|
|
.LP
|
|
Alle Zugriffsmethoden legen den Datenbestand
|
|
einer Relation in \*(xx\-Files ab.
|
|
Das File ist generierungsabh\o'a"'ngig in Seiten von 512-Byte
|
|
(\*(xx\ Version 7) oder 1KByte L\o'a"'nge
|
|
unterteilt. Jedes File f\o'u"'r eine
|
|
Relation besteht aus einer ganzen Anzahl von Seiten,
|
|
mindestens aber aus einer.
|
|
.LP
|
|
Jede Seite enth\o'a"'lt Tupel der Relation
|
|
und zwar so, dass jedes Tupel vollst\o'a"'ndig auf einer Seite
|
|
untergebracht ist.
|
|
.LP
|
|
Ein Tupel kann gew\o'o"'hnlich oder komprimiert gespeichert
|
|
werden:
|
|
Als gew\o'o"'hnlich gespeichertes Tupel wollen wir eine Speicherung verstehen,
|
|
wo jedes Attribut des Tupel genau soviele Bytes
|
|
belegt, wie beim create der Relation
|
|
als Formatl\o'a"'nge f\o'u"'r die entsprechenden Dom\o'a"'nen
|
|
definiert wurde.
|
|
Bei den Dom\o'a"'nen des Typs c (character) wird h\o'a"'ufig der
|
|
Fall eintreten, dass deren Attribute den verf\o'u"'gbaren Speicherplatz
|
|
nicht voll ausf\o'u"'llen, indem sie ab einer bestimmten
|
|
Position nur noch Leerzeichen enthalten.
|
|
Als eine komprimierte Speicherung eines Tupel
|
|
verstehen wir eine solche,
|
|
bei der Attribute von c-Dom\o'a"'nen um diese rechten Leerstellen
|
|
verk\o'u"'rzt werden (das Ende des relevanten Teils
|
|
des Attributes wird durch ein zus\o'a"'tzliches '\e0'-Byte markiert ! ).
|
|
Als Spreizen einer Relation wollen wir die Transformation
|
|
einer komprimierten in die gew\o'o"'hnliche Darstellung
|
|
verstehen.
|
|
.LP
|
|
F\o'u"'r gew\o'o"'hnlich dargestellte Relationen kann man die auf einer
|
|
Seite unterbringbaren Tupel berechnen als
|
|
.DS I
|
|
|
|
512 - 12
|
|
Tupel pro Seite = ggZ (--------------------)
|
|
Tupell\o'a"'nge + 2
|
|
|
|
(Tupell\o'a"'nge in Byte,
|
|
ggZ: gr\o'o"'sste ganze Zahl von )
|
|
.DE
|
|
Man sieht, dass pro Seite generell 12
|
|
Bytes und pro Tupel 2 Byte Verwaltungsplatz
|
|
ben\o'o"'tigt werden.
|
|
.LP
|
|
Analog kann man sich ausrechnen, wieviel Restplatz
|
|
auf jeder Seite frei bleibt, wenn die Tupell\o'a"'nge
|
|
so gew\o'a"'hlt wird, dass ein ganzes Vielfaches von
|
|
ihr ( + 2 ! ) die Seite nicht ausf\o'u"'llt.
|
|
Maximal darf die Tupell\o'a"'nge 498 Bytes betragen
|
|
(pro Seite dadurch also ein Tupel !).
|
|
Die Beziehungen f\o'u"'r 1024-Byte-Seiten k\o'o"'nnen
|
|
mit den gleichen absoluten Werten berechnet werden.
|
|
.LP
|
|
Aus der Anzahl der Tupel und den auf einer Seite unterbringbaren,
|
|
kann der, f\o'u"'r eine Relation insgesamt n\o'o"'tige Speicherplatz
|
|
ausgerechnet werden.
|
|
.LP
|
|
F\o'u"'r komprimiert dargestellte Relationen
|
|
muss man eigene Absch\o'a"'tzungen verwenden.
|
|
.LP
|
|
Wir bezeichnen eine Seite mit minimalem Restplatz
|
|
als (100 %-tig) gef\o'u"'llt.
|
|
Der F\o'u"'llfaktor einer Seite entspricht dem
|
|
durch Tupel belegten Platz
|
|
im Verh\o'a"'ltnis zum Gesamtplatz.
|
|
.NH 4
|
|
.ft B
|
|
Schl\o'u"'sselbegriff von \*(yy
|
|
.ft R
|
|
.LP
|
|
In der Relationentheorie bezeichnet
|
|
man als Schl\o'u"'ssel einer Relation
|
|
eine derartige Dom\o'a"'ne (oder Gruppe von Dom\o'a"'nen),
|
|
deren Attribute allein das Tupel charakterisieren.
|
|
Beliebige zwei Tupel einer Relation unterscheiden sich also
|
|
mindestens in ihren Schl\o'u"'sseln.
|
|
.LP
|
|
Wenn in der \*(yy\-Dokumentation von Schl\o'u"'sseln
|
|
gesprochen wird, ist ein anderer, schw\o'a"'cherer Begriff
|
|
gemeint.
|
|
Bei \*(yy\ kann eine Dom\o'a"'ne
|
|
(oder eine Gruppe von in ihrer Reihenfolge
|
|
ge\%kennzeichneter Dom\o'a"'nen)
|
|
f\o'u"'r die Sortierung oder Zugriffsunterst\o'u"'tzung
|
|
herangezogen werden.
|
|
F\o'u"'r diese Dom\o'a"'ne(n) wird dann vom Schl\o'u"'ssel
|
|
der Relation gesprochen.
|
|
\*(yy\ unterstellt f\o'u"'r den Schl\o'u"'ssel nicht
|
|
unbedingt die o.g. unifizierende Eigenschaft,
|
|
dass sich zwei Tupel mindestens in ihren Schl\o'u"'sseln
|
|
unterscheiden m\o'u"'ssen.
|
|
.LP
|
|
F\o'u"'r \*(yy\ sind zwei Tupel genau dann gleich,
|
|
wenn sie in allen paarigen Attributen
|
|
\o'u"'bereinstimmen. An den Stellen,
|
|
wo \*(yy\ doppelte Tupel ausschliesst, wird nicht
|
|
nur auf Unterschiede in den Schl\o'u"'sselattributen,
|
|
sondern auf solche in allen paarigen
|
|
Attributen getestet.
|
|
.NH 4
|
|
.ft B
|
|
Seitenketten
|
|
.ft R
|
|
.LP
|
|
Wir wollen eine Gruppe von Seiten, die aus einer Hauptseite besteht,
|
|
an der ggf. weitere Seiten durch Verweisungen angekettet sind,
|
|
als Seitenkette bezeichnen.
|
|
Im Extrem besteht die Sei\%tenkette nur aus der Hauptseite.
|
|
Die Verweisungen erfolgen linear aus der Hauptseite
|
|
auf deren nachfolgende, aus dieser auf deren nachfolgende u.s.w.
|
|
In der Regel werden die der Hauptseite folgenden
|
|
Seiten als \o'U"'berlaufseiten bezeichnet.
|
|
Wir bezeichnen die in der Seitenkette enthaltenen Tupel als
|
|
Tupel\%kette der Seiten\%kette.
|
|
.DS L
|
|
Seitenkette ___________
|
|
| |
|
|
| Haupt |
|
|
| Seite |
|
|
| |
|
|
~~~~~~~~~~~
|
|
| ....................
|
|
___________ \o'U"'berlaufseiten
|
|
| |
|
|
| Folge |
|
|
| Seite |
|
|
| |
|
|
~~~~~~~~~~~
|
|
|
|
|
:
|
|
:
|
|
:
|
|
.DE
|
|
.LP
|
|
Gemeinsam bei allen Zugriffsmethoden ist:
|
|
.IP \ \ \ - 5
|
|
Die Suche eines Tupels in einer Seitenkette erfolgt
|
|
sequentiell.
|
|
.sp1
|
|
Sieht man von den hier nicht darzustellenden
|
|
Dekompositionsverfahren bei retrieve-Anweisungen
|
|
mit Aggregaten oder \o'u"'ber mehrere Relationen ab,
|
|
erfolgt die Anzeige aufgefundener Tupel
|
|
unmittelbar in der Reihenfolge der Tupelkette.
|
|
.sp1
|
|
.IP
|
|
Das Anf\o'u"'gen (append) eines Tupel in einer Seitenkette
|
|
erfolgt hinten an die Tupel der laufenden Seite;
|
|
wenn daf\o'u"'r kein Platz mehr ist,
|
|
wird die Seitenkette um eine neue Seite verl\o'a"'ngert.
|
|
.sp1
|
|
Dadurch geht die anfangs bestehende Reihenfolgeordnung
|
|
der Tupel in einer Seite und auch in der Seitenkette verloren.
|
|
.sp1
|
|
.IP
|
|
Beim Streichen (delete) eines Tupel wird der Platz des Tupel
|
|
freigegeben und die Seite komprimiert;
|
|
die Seitenkette wird nicht komprimiert.
|
|
.LP
|
|
Unterschiede zwischen den Zugriffsmethoden
|
|
bestehen darin:
|
|
.sp1
|
|
.IP \ \ \ - 5
|
|
bei der heap-Technik wird die gesamte Relation in einer
|
|
einzigen Seitenkette abgelegt, bei den Direktzugriffsmethoden
|
|
hash und isam besteht die Relation aus mehreren Seitenketten.
|
|
Die Unterschiede bei letzteren Techniken
|
|
bestehen in der Art der Zuordnung von
|
|
Schl\o'u"'sselwerten zu den verschiedenen Seitenketten
|
|
der Relation.
|
|
.sp1
|
|
.IP
|
|
Bei der heap-Technik werden doppelte Tupel in der Seiten\%kette
|
|
zugelassen, bei den Direktzugriffstechniken nicht.
|
|
.sp1
|
|
Daraus ergeben sich Unterschiede beim Anf\o'u"'gen neuer Tupel:
|
|
.br
|
|
Bei heap erfolgt die Einspeicherung
|
|
am Ende der Tupel\%kette,
|
|
bei hash und isam muss die gesamte Seiten\%kette
|
|
durchsucht werden, um doppelte Tupel auszuschliessen,
|
|
das Anf\o'u"'gen erfolgt
|
|
auf dem ersten ausreichenden freien Platz der Seitenkette.
|
|
Bei heap wird dadurch der durch delete entstandene
|
|
freie Platz nicht wieder ausgenutzt.
|
|
.sp1
|
|
Daraus ergeben sich auch Unterschiede beim Ersetzen (replace)
|
|
in komprimierten Relationen in solchen F\o'a"'llen,
|
|
wo das Ersetzen ggf. nicht inplace erfolgen kann.
|
|
Dann wird replace in delete und append aufgel\o'o"'st.
|
|
Beachten sie, dass jedes gefundene Tupel ersetzt wird,
|
|
replace also die Anzahl der Tupel einer Relation nicht \o'a"'ndert.
|
|
.NH 3
|
|
.ft B
|
|
Zugriffstechniken von \*(yy
|
|
.ft R
|
|
.NH 4
|
|
.ft B
|
|
Heap
|
|
.ft R
|
|
.LP
|
|
Eine als heap dargestellte Relation belegt
|
|
eine Seitenkette.
|
|
Bis auf die letzte Seite sind
|
|
bei Erzeugung der Relation
|
|
durch modify, copy from oder sukzessives append
|
|
alle Seiten
|
|
(100 %-tig) gef\o'u"'llt.
|
|
Die Tupel sind unsortiert.
|
|
Die Relation enth\o'a"'lt ggf. doppelte Tupel.
|
|
.LP
|
|
append f\o'u"'gt Tupel hinten an
|
|
(ggf. werden weitere Seiten angekettet !).
|
|
delete gibt Speicherplatz auf der jeweiligen Seite frei;
|
|
um die zu l\o'o"'schenden Tupel zu finden,
|
|
muss die gesamte Relation durchsucht werden.
|
|
Der freigegebene Platz kann durch append nicht wiederbenutzt werden,
|
|
da neue Tupel hinten angelegt werden.
|
|
retrieve durchsucht die gesamte Relation
|
|
und zeigt die sich qua\%lifizierenden
|
|
Tupel in der gefundenen, unsortierten Reihenfolge.
|
|
.LP
|
|
heap und cheap sind geeignete Zugriffstechniken,
|
|
um aus einer leeren Relation durch sukzessives Anf\o'u"'gen oder copy from
|
|
eine Relation aufzubauen.
|
|
Eine effektive Arbeit mit dieser Zugriffstechnik
|
|
ist aber nur bei kleinen Relationen denkbar.
|
|
.NH 4
|
|
.ft B
|
|
Heapsort
|
|
.ft R
|
|
.LP
|
|
heapsort ist keine Speichertechnik
|
|
sondern Zustand einer Relation
|
|
nach Ausf\o'u"'hrung eines entsprechenden modify-Statements;
|
|
die Relation ist in der Folge ein heap.
|
|
.LP
|
|
Bei der Ausf\o'u"'hrung eines modify to heapsort
|
|
wird die Relation nach den angesprochenen Dom\o'a"'nen
|
|
sortiert, werden doppelte Tupel gestrichen
|
|
und wird die Relation als heap abgelegt.
|
|
.LP
|
|
Zur Durchf\o'u"'hrung der Sortierung wird die Relation
|
|
gespreizt, falls sie komprimiert gespeichert war.
|
|
Es werden Sortierarbeitspl\o'a"'tze
|
|
als Files im SYS-directory angelegt.
|
|
.NH 4
|
|
.ft B
|
|
Hash
|
|
.tf R
|
|
.LP
|
|
F\o'u"'r eine als hash dargestellte Relation besteht ein
|
|
Direktzugriff auf ein Tupel,
|
|
wenn der Wert seines(r) Schl\o'u"'sselattribute(s)
|
|
vollst\o'a"'ndig angegeben wird.
|
|
Dieser Zugriff wird wie folgt vollzogen:
|
|
.LP
|
|
Durch eine hash-Funktion wird aus dem Schl\o'u"'sselattribut
|
|
die Adresse (der hash-Code) einer Hauptseite
|
|
berechnet.
|
|
Die hash Funktion berechnet also nach einem besonderen
|
|
Verfahren aus einem irgendwie strukturiertem Schl\o'u"'ssel
|
|
eine Zahl, die in einem Intervall
|
|
.DS C
|
|
0 <= Hauptseite <= N-1
|
|
.DE
|
|
liegt.
|
|
N bezeichnen wir als Spreizungsbreite der hash-Funktion.
|
|
Diese dadurch jeweils errechnete Hauptseite ist Anfangsseite
|
|
einer Seitenkette, die alle die Tupel der Relation enth\o'a"'lt,
|
|
deren Schl\o'u"'ssel den gleichen hash-Code haben.
|
|
In diesen Seitenketten werden keine doppelten Tupel zugelassen.
|
|
Die Relation kann insgesamt als unsortiert aufgefasst werden,
|
|
da die hash-Funktion keinen "nat\o'u"'rlichen" Wert
|
|
aus dem Schl\o'u"'ssel bildet.
|
|
.DS I
|
|
0
|
|
1
|
|
hash(Schl\o'u"'sselwert) = :
|
|
:
|
|
N-1
|
|
|
|
|
|
0 1 ......... N-1
|
|
________ ________ ________
|
|
| | | | | |
|
|
|Seiten| |Seiten| ......... |Seiten|
|
|
|kette | |kette | |kette |
|
|
| | | | | |
|
|
~~~~~~~~ ~~~~~~~~ ~~~~~~~~
|
|
|
|
.DE
|
|
.LP
|
|
Beim modify einer Relation zu hash
|
|
kann die Spreizungsbreite
|
|
der hash-Funktion durch die geforderte Anzahl von
|
|
Hauptseiten
|
|
(minpages/maxpages als minimale/maximale Anzahl)
|
|
beeinflusst werden.
|
|
Die Ausf\o'u"'hrung des modify erfolgt durch sukzessives insert
|
|
in eine neue Relation.
|
|
Die alte Relation wird aus Sicherheitsgr\o'u"'nden erst
|
|
freigegeben, wenn die neue erzeugt ist.
|
|
Beim create einer leeren Relation
|
|
kann man mit
|
|
modify
|
|
eine gew\o'u"'nschte Spreizungsbreite einstellen.
|
|
.LP
|
|
hash und chash sind geeignete Zugriffstechniken,
|
|
um aus einer leeren Relation durch sukzessives Anf\o'u"'gen
|
|
oder durch copy from eine Relation aufzubauen.
|
|
.LP
|
|
\*(yy\ unterst\o'u"'tzt nur eine hash-Funktion.
|
|
Es kann nicht garantiert werden,
|
|
dass die durch die Spreizungsbreite definierte Anzahl
|
|
von Seitenketten schon bei Erzeugung der Relation jeweils
|
|
mindestens ein Tupel und maximal nicht mehr als auf der Hauptseite
|
|
unterbringbar enthalten.
|
|
Allerdings wird f\o'u"'r jede Seitenkette mindestens
|
|
eine Hauptseite reserviert.
|
|
.LP
|
|
Die Suche in einer hash-Relation f\o'u"'r einen einzelnen Schl\o'u"'sselwert
|
|
f\o'u"'hrt \o'u"'ber dessen hash-Code
|
|
auf die Hauptseite, wo sequentiell weiter gesucht wird.
|
|
Die Suche nach einem Schl\o'u"'sselintervall zwingt zum Durchsuchen
|
|
der gesamten Relation.
|
|
Deshalb ist die hash-Technik ungeeignet,
|
|
wenn h\o'a"'ufig Suchpfade \o'u"'ber
|
|
Schl\o'u"'sselintervalle benutzt werden m\o'u"'ssen.
|
|
.LP
|
|
Das \o'A"'ndern in einer Relation erfolgt einschliesslich
|
|
der Suche und dem Ausschluss der Anlage doppelter Tupel.
|
|
Beim Erg\o'a"'nzen neuer Tupel wird die betroffene Seitenkette
|
|
ggf. durch \o'U"'berlaufseiten erg\o'a"'nzt, die an die
|
|
vorherigen Seiten der Seitenkette angekettet werden.
|
|
.NH 4
|
|
.ft B
|
|
Isam
|
|
.ft R
|
|
.LP
|
|
F\o'u"'r eine als isam dargestellte Relation
|
|
besteht ein Direktzugriff auf ein Tupel,
|
|
wenn der Wert seines(r) Schl\o'u"'sselattribute(s)
|
|
angegeben wird und besteht dar\o'u"'ber hinaus die M\o'o"'glichkeit,
|
|
Schl\o'u"'sselintervalle in einer ann\o'a"'hernden
|
|
Sortierung abzugreifen.
|
|
.LP
|
|
F\o'u"'r isam ist ein aus mehreren Komponenten
|
|
bestehender Schl\o'u"'ssel soweit definiert und ggf.
|
|
f\o'u"'r einen direkten Zugriff nutzbar,
|
|
wie seine ersten Komponenten l\o'u"'ckenlos
|
|
definiert sind.
|
|
.LP
|
|
Der Zugriff wird wie folgt organisiert:
|
|
.LP
|
|
Durch einen Adress-B*-Baum wird aus dem Schl\o'u"'sselattribut
|
|
die Adresse einer Hauptseite berechnet.
|
|
.LP
|
|
Ein B*-Adressbaum enth\o'a"'lt in jeder Baumebene
|
|
eine Folge von Seiten. Eine derartige Folge von Seiten
|
|
enth\o'a"'lt aufsteigend geordnete Schl\o'u"'ssel
|
|
von Seiten der darunter liegenden Baum\%ebene, also der
|
|
Nachfolgeebene.
|
|
Aus der Position des Schl\o'u"'ssels kann die betreffende Seite
|
|
der Nachfolgeebene bestimmt werden.
|
|
Diese enth\o'a"'lt ab dem sie definierenden Anfangsschl\o'u"'ssel
|
|
alle, die kleiner als der Anfangsschl\o'u"'ssel
|
|
ihrer, in gleicher Baumebene liegenden, Nachbarseite sind.
|
|
Der B*-Baum wird nach unten durch Hauptseiten
|
|
von Seitenketten abgeschlossen,
|
|
die zu den Schl\o'u"'sseln auch alle weiteren Attribute
|
|
als vollst\o'a"'ndige Tupel enthalten.
|
|
Der B*-Baum erh\o'a"'lt nach oben soviele Ebenen, bis die
|
|
Wurzelebene ganz auf einer Seite darstellbar ist.
|
|
.LP
|
|
Nehmen wir als Beispiel Schl\o'u"'ssel von ganzen Zahlen an und nehmen wir weiter an, dass auf
|
|
einer Seite der Seitenkette der Relation 5 Tupel unterbringbar w\o'a"'ren,
|
|
auf einer Seite des B*-Baumes aber 25 Adressen.
|
|
Dann w\o'a"'re folgender B*-Baum mit zwei Baumebenen denkbar:
|
|
.DS L
|
|
|
|
______________________________
|
|
| 5 130 |
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
________________________ ________________________
|
|
| 5 10 .... 125| |130 135 .... 255|
|
|
~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
_____ _____ _____ _____ _____ _____ _____
|
|
| | | | | | | | | | | | | |
|
|
| 0 | | 5 | | 10| |125| |130| |135| |255|
|
|
| : | | : | | : | ..... | : | | : | | : | ..... | : |
|
|
| : | | : | | : | | : | | : | | : | | : |
|
|
| 4 | | 9 | | 14| |129| |134| |139| | : |
|
|
| | | | | | | | | | | | | |
|
|
~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~ ~~~~~
|
|
|
|
.DE
|
|
Die Genauigkeit des B*-Baumes w\o'u"'rde gew\o'a"'hrleisten,
|
|
dass im Schl\o'u"'sselintervall 0 ... 254
|
|
maximal 5 Tupel sequentiell gesucht werden m\o'u"'ssten,
|
|
dass in diesem Intervall keine \o'U"'berlaufseiten auftreten
|
|
und dass bei der Ausgabe Sortierabweichungen
|
|
nur in 5-er Schritten auftreten k\o'o"'nnten:
|
|
.br
|
|
z.B.
|
|
.DS I 12
|
|
9, 11, 13, 12, 14, 10, 17
|
|
aber nie 9 nach 10, 11, 12, 13, 14
|
|
oder nie 15 vor 10, 11, 12, 13, 14
|
|
.DE
|
|
Allerdings w\o'u"'rden alle Tupel mit Schl\o'u"'sselwerten ab 255
|
|
in die letzte Seitenkette eingeordnet werden.
|
|
.LP
|
|
Beenden wir hiermit das Beispiel.
|
|
.LP
|
|
Der B*-Baum ist Bestandteil der Relation.
|
|
.sp1
|
|
.ti +5
|
|
.ne 8
|
|
(seine L\o'a"'nge ist berechenbar:
|
|
.IP \ \ \ \ \ - 8
|
|
Tupell\o'a"'nge der Adresse:
|
|
.br
|
|
gespreizter Schl\o'u"'sselcode
|
|
.IP
|
|
jede Baumebene ganz in Seiten)
|
|
.LP
|
|
Die durch den B*-Baum ermittelten Hauptseiten
|
|
sind Anfangsseiten von Seitenketten,
|
|
die unsortiert alle Tupel enthalten und deren Schl\o'u"'ssel den
|
|
gleichen Baumpfad nehmen.
|
|
In diesen Seitenketten werden keine doppelten Tupel zugelassen.
|
|
Die B*-Baum-Struktur gew\o'a"'hrleistet f\o'u"'r gewisse
|
|
Schl\o'u"'sselintervalle
|
|
eine Sortierung untereinander.
|
|
.LP
|
|
Der B*-Baum wird bei der Erzeugung der Relation
|
|
angelegt und bleibt \o'u"'ber deren gesamte Lebensdauer fest.
|
|
Es ist unsinnig, eine leere Relation
|
|
als isam zu gr\o'u"'nden, der B*-Baum w\o'a"'re entartet,
|
|
man w\o'u"'rde eine einzige Seitenkette erzeugen,
|
|
bei dem bei jedem Einf\o'u"'gen eines neuen Tupel
|
|
eine Duplikatkontrolle \o'u"'ber alle bereits
|
|
vorhandenen Tupel erfolgen w\o'u"'rde.
|
|
.LP
|
|
Bei der Erzeugung der isam Relation durch modify
|
|
kann man die Genauigkeit des B*-Baumes
|
|
durch den F\o'u"'llfaktor der Hauptseiten
|
|
bestimmen.
|
|
Die alte Relation wird zun\o'a"'chst in eine Speicherungsform analog
|
|
heapsort \o'u"'berf\o'u"'hrt, diese wird danach, entsprechend dem
|
|
F\o'u"'llfaktor, gespreizt
|
|
und \o'u"'ber den so entstandenen Hauptseiten
|
|
wird der B*-Baum aufgebaut.
|
|
.LP
|
|
Die Suche in einer isam Relation kann f\o'u"'r die Angabe
|
|
von einzelnen Schl\o'u"'sselwerten, als auch f\o'u"'r
|
|
Intervalle von ihnen unterst\o'u"'tzt werden.
|
|
Das Anf\o'u"'gen erfolgt zun\o'a"'chst in den
|
|
Hauptseiten - soweit der F\o'u"'llfaktor des
|
|
erzeugenden modify vorausschauend gen\o'u"'genden Restplatz
|
|
definiert - danach werden der jeweiligen Seitenkette
|
|
\o'U"'berlaufseiten angef\o'u"'gt.
|
|
Das \o'A"'ndern in der Relation erfolgt einschliesslich
|
|
der Suche und dem Ausschluss der Anlage doppelter Tupel.
|
|
.NH 3
|
|
.ft B
|
|
Die Gestaltung des Datenbankfilesystems
|
|
.br
|
|
f\o'u"'r \*(yy
|
|
.ft R
|
|
.NH 4
|
|
.ft B
|
|
Einordnung einer Datenbank
|
|
.ft R
|
|
.LP
|
|
\*(yy\ wird installationsabh\o'a"'ngig
|
|
unter einem Anfangspfadnamen
|
|
.DS C
|
|
Pathname
|
|
.DE
|
|
installiert. Zum Beispiel ist
|
|
.DS C
|
|
Pathname = /mnt/ing_db
|
|
.DE
|
|
eingerichtet.
|
|
.LP
|
|
Unter diesem Pathname liegen eine Reihe hier nicht behandelter
|
|
Files und directories.
|
|
Die Datenbanken sind unter
|
|
.DS C
|
|
Pathname/data/base
|
|
.DE
|
|
eingerichtet, jede Datenbank erh\o'a"'lt ein directory ihres Namens:
|
|
.DS C
|
|
Pathname/data/base/dbname
|
|
.DE
|
|
In jedem directory dbname liegen
|
|
.sp1
|
|
.IP \ \ \ - 5
|
|
dbname/admin
|
|
.br
|
|
das s.g. admin-File mit allgemeinen Datenbankinformationen,
|
|
.sp1
|
|
.IP
|
|
die Systemkataloge
|
|
(die Relationen relation, references, attributes, integrity, protect, indexes),
|
|
die Relationen (Relationen schlechthin, Indizes)
|
|
.LP
|
|
Durch diese Struktur sind insbesondere
|
|
.DS B
|
|
base oder
|
|
dbname oder
|
|
SYS
|
|
.DE
|
|
mountbar.
|
|
.LP
|
|
Bei Erzeugung einer Datenbank mittels creatdb
|
|
wird das directory dbname
|
|
angelegt und werden die Systemkataloge eingerichtet.
|
|
.NH 4
|
|
.ft B
|
|
Bewertung des Relationennamens
|
|
.ft R
|
|
.LP
|
|
\*(yy\ speichert alle Daten einer Relation in einem \*(xx\-File
|
|
unter dem directory dbname.
|
|
Der File-Name wird aus dem vom Anwender
|
|
bei create oder retrieve into angegebenem Relationennamen
|
|
gebildet.
|
|
Dazu wird der Relationenname
|
|
.IP \ \ \ - 5
|
|
ggf. durch Leerzeichen (<blank>) auf 12 Bytes
|
|
verl\o'a"'ngert;
|
|
.br
|
|
dabei wird das erste in 2. bis 11. Position
|
|
gefundene "_" (<underscore>) durch "/" (<slash>)
|
|
ersetzt;
|
|
.IP
|
|
den 12 Bytes werden 2 Bytes als Code des
|
|
arbeitenden Nutzers (s. auch
|
|
-u-Flag bei quel(unix) im Referenz-Manual)
|
|
angef\o'u"'gt.
|
|
.LP
|
|
Dadurch wird es m\o'o"'glich, dass
|
|
.IP -
|
|
verschiedene Nutzer private Relationen gleichen
|
|
Namens in der gleichen Datenbank anlegen k\o'o"'nnen;
|
|
.IP -
|
|
ein Nutzer durch sinnvolle Verwendung des <underscore>
|
|
im Relationennamen die Verteilung der Relationen
|
|
auf das Wurzel-directory dbname oder in sub-directories
|
|
von dbname steuern kann.
|