.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 () auf 12 Bytes verl\o'a"'ngert; .br dabei wird das erste in 2. bis 11. Position gefundene "_" () durch "/" () 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 im Relationennamen die Verteilung der Relationen auf das Wurzel-directory dbname oder in sub-directories von dbname steuern kann.